Make phase B able to fail - #52
Open
amrali-eg wants to merge 1 commit into
Open
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.jsonreportingDetectedCodePage: 1252— checked by hand, afterwards. Not from the test.The discriminator
The sample now carries
0x80:0x80Detection 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:
DetectedCodePage: 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 conversionDetectionMode: Explicit,SourceEncoding: iso-8859-1Exporting 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:
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'sDetectedEncodingandSourceEncodingare 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