Skip to content

Make phase B able to fail - #52

Open
amrali-eg wants to merge 1 commit into
masterfrom
harden/smoke-phase-b
Open

Make phase B able to fail#52
amrali-eg wants to merge 1 commit into
masterfrom
harden/smoke-phase-b

Conversation

@amrali-eg

Copy link
Copy Markdown
Owner

Make phase B able to fail

Phase B's French sample used only accented letters — é à ê — on which windows-1252 and iso-8859-1 agree exactly. So "the text survived" could not show which codec had read the file, and the phase could not have failed even if the explicit choice had been ignored entirely.

The 2026-08-27 run it passed was still evidence, but the evidence came from french.txt.ecmeta.json reporting DetectedCodePage: 1252 — checked by hand, afterwards. Not from the test.

The discriminator

The sample now carries 0x80:

byte windows-1252 iso-8859-1
0x80 U+20AC € U+0080 (C1 control)

Detection settles on windows-1252 for this file, so the phase asks the tester for iso-8859-1 — the codec detection did not choose. The output then says which one was actually used, and agreement can no longer be mistaken for override.

Provenance asserted three ways

One of them was the thing that was missing, so the phase now checks all three:

  • the output text — contains U+0080, excludes U+20AC
  • the recovery recordDetectedCodePage: 28591, plus internal consistency: the backup is a copy of the original, the original is the file we created, and the decoded text is unchanged across the conversion
  • the journalDetectionMode: Explicit, SourceEncoding: iso-8859-1

Exporting the journal is now a step in the phase, which also exercises the export path #49 added — the part of that PR nothing had run.

Rehearsed in both directions

Correct path passes. Then, deliberately choosing the codec detection preferred:

french.txt: missing U+0080 - the chosen iso-8859-1 reading, not the detected windows-1252 one
french.txt record: DetectedCodePage is 1252, expected 28591
journal french.txt: SourceEncoding is 'windows-1252', expected 'iso-8859-1'

Three independent failures where the old phase had none. Skipping the journal export fails with the export to run. Phases A, C and D re-rehearsed after the sample change — all pass.

One limitation, recorded in the script

Under CLI -From, detection never runs, so the journal's DetectedEncoding and SourceEncoding are the same value. Only the GUI produces the pair differing — detection during View, then the override. The check reports whichever case it sees rather than asserting a pair the CLI cannot produce.

🤖 Generated with Claude Code

Its French sample used only accented letters, on which windows-1252 and
iso-8859-1 agree exactly. So "the text survived" could not show which codec had
read the file, and the phase could not have failed if the explicit choice had
been ignored entirely. The run it passed was still evidence - but from the
recovery record, checked by hand afterwards, not from the test.

The sample now carries 0x80: the euro sign in windows-1252, a C1 control in
iso-8859-1. Detection settles on windows-1252 for it, so the phase asks for
iso-8859-1 - the codec detection did not choose - and the output itself then says
which one was used.

Asserts the provenance three ways, since one of them is the thing that was
missing: the output text, the recovery record's code page and internal
consistency (backup is a copy of the original, decoded text unchanged), and the
journal's DetectionMode and source encoding. Exporting that journal is now part
of the phase, which also exercises the export path the journal PR added.

Rehearsed through the CLI in both directions. Choosing the wrong codec fails on
all three independently; skipping the journal export fails with the export to
run. Phases A, C and D re-rehearsed after the sample change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant