specs: restore the 2544 lines a counter overwrote (Refs #2713) - #2722
Open
gHashTag wants to merge 1 commit into
Open
specs: restore the 2544 lines a counter overwrote (Refs #2713)#2722gHashTag wants to merge 1 commit into
gHashTag wants to merge 1 commit into
Conversation
… (Refs #2161) `4639b38cd` -- "fix(l3-purity): replace all Unicode with ASCII in 160 .t27 files" -- did not transliterate. It replaced the i-th non-ASCII character of each file with the ASCII digits of `i`: - fn ternary_not(a: i32) → i32 { + fn ternary_not(a: i32) 257 i32 { That transform is exactly reproducible from the pre-image, which is what makes the repair safe rather than a guess. The model was verified to reproduce the commit's output BYTE FOR BYTE before anything was written. A line is restored only when the line at HEAD is byte-identical to the transform of its pre-image line, so every line edited in the four months since is left untouched. 141 files, 2544 lines. Measured with the MASTER binary, so this is isolated from the compiler fixes in #2720: specs that parse 603 -> 610 regressions 0 The seven are exactly the "Expected LBrace, got Number ('257')" cluster. They failed not because they LOST an arrow -- `→` was never a token, the lexer discards it -- but because they GAINED an integer literal. One restored line, as a sample of what the other 2543 are: - assert jones_trefoil_at_phi() 1222 PHI + PHI * PHI within 0.1 + assert jones_trefoil_at_phi() ≈ PHI + PHI * PHI within 0.1 The comparison operator was that file's 1222nd non-ASCII character. This takes the RESTORE branch of the question in #2713 rather than transliterating, on two grounds. The pre-image is exact and a transliteration is a fresh authoring decision on 2544 lines. And the L3 ASCII rule is enforced by nothing today: 320 of 747 tracked .t27 files carry 88,033 non-ASCII characters at HEAD and no gate objects -- while TASK.md:128 records "0 non-ASCII remaining". scripts/repair/unscar_4639b38cd.py is committed, so the transliterate branch stays available and the operation is reproducible.
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-26 17:22:27 UTC
Summary
Seal Status
|
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
1 participant
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.
4639b38cd— "fix(l3-purity): replace all Unicode with ASCII in 160 .t27 files", on master since April — did not transliterate anything. It replaced the i-th non-ASCII character of each file with the ASCII digits ofi.Reported with full evidence in #2713. This is the repair.
The transform is an exact oracle, and that is what makes this safe
The commit's rewrite is reproducible from the pre-image. I built the model and verified it reproduces the commit's output byte for byte on
specs/isa/ternary_gates.t27before writing anything.A line is restored only when the line at HEAD is byte-identical to the transform of its pre-image line. Any line edited in the four months since is left alone. That rule is the whole safety argument: this is not a revert, and it never overwrites later work.
141 files, 2544 lines.
Measured
Deliberately with the master binary, so this is isolated from the compiler fixes in #2720:
The seven are exactly the
Expected LBrace, got Number ('257')cluster. Note the mechanism: they failed not because they lost an arrow —→was never a token, the lexer discards it — but because they gained an integer literal.One line, as a sample of the other 2543
That file's 1222nd non-ASCII character was the comparison operator of an invariant. The spec compiled, sealed and passed every gate for four months with the operator replaced by its index.
Why restore rather than transliterate
#2713 asks the owner which branch to take. This PR takes restore, on two grounds:
→to->is easy, but≈,φ,²and the box-drawing runs are not, and getting them wrong is a second silent rewrite of the source of truth..t27files carry 88,033 non-ASCII characters at HEAD and no gate objects — whileTASK.md:128records "0 non-ASCII remaining" and the dashboard shows L3 PURITY green.scripts/repair/unscar_4639b38cd.pyis committed, so the operation is reproducible and the transliterate branch stays available: run it, then transliterate the restored text with the originals in hand rather than gone.Still open, and not for me to decide
TASK.md:128anddocs/META_DASHBOARD.md:89record a completed milestone that did not happen. Correct them, or annotate them?Note on CI
This PR will show a green two-check list and sit
BLOCKED, like every PR opened since 2026-08-24 11:06. That is #2721, not this change.Refs #2161, #2713