A repo-wide "replace Unicode with ASCII" commit numbered the characters instead of transliterating them, and the tree records it as done

[gHashTag]

Commit 4639b38cd — "fix(l3-purity): replace all Unicode with ASCII in 160 .t27 files", on master since April, never reverted — did not transliterate anything. It overwrote each non-ASCII character with its own running index.

Proof, not inference

Two → on adjacent lines of the same file became two consecutive integers:

-    // ternary_not(a: i32) → i32
+    // ternary_not(a: i32) 256 i32
-    fn ternary_not(a: i32) → i32 {
+    fn ternary_not(a: i32) 257 i32 {

And one glyph became two different numbers, which only a counter produces — x₀ in specs/math/phi_universal_attractor.t27:

314:        measure: nanoseconds to converge from x1283 = 0.5
318:        measure: nanoseconds to converge from x1284 = 10.0

The commit message claims arrows were emitted as ->. None were.

Two kinds of damage

Loud: 7 specs stopped parsing. They are exactly the Expected LBrace, got Number ('257') cluster in t27c suite — specs/base/{ternary_encoding,ternary_memory}.t27 and specs/isa/{ternary_arithmetic,ternary_bitwise,ternary_deque,ternary_gates,ternary_shift}.t27. Note the mechanism: they do not fail because they lost an arrow (→ was never a token — the lexer discards it), they fail because they gained an integer literal.

Silent, and far larger: ~136 files and ~2,454 lines still carry the scar. A spec whose signature comment now reads // ternary_not(a: i32) 256 i32 compiles, seals, and passes every gate while no longer saying what the function does. About 104 scarred lines across 15 files sit in executable position — for example specs/vsa/jones_polynomial.t27:335:

assert jones_trefoil_at_phi() 1222 PHI + PHI * PHI within 0.1

That was an invariant with a comparison operator in it. The operator is gone.

The repository records this as a success

where	what it says
TASK.md:128	"L3 PURITY: 205,654 Unicode chars replaced in 160 .t27 files (0 non-ASCII remaining)"
docs/META_DASHBOARD.md:89	L3 PURITY 🟢 — 0 violations

Measured on master today:

файлов с не-ASCII: 320 из 747,  символов: 88033

So the claim is wrong twice over: the replacement destroyed text instead of transliterating it, and "0 remaining" is off by 88,033.

Why no gate catches it

A checker that counts non-ASCII characters gives a perfect score to a tool that replaces them with digits. The output is pure ASCII. That is the whole point of the failure: the metric was satisfied exactly, and the thing the metric stood for was destroyed.

Nothing in t27c suite can see this class either — 129 of the scarred files parse, seal and pass.

What the repair is, and why it needs an owner

No compiler change reaches this. The original characters exist only in git history, so the fix is a scripted revert-and-redo of 4639b38cd over the still-scarred files: recover each pre-image, apply a real transliteration, re-commit.

That is a mechanical operation on 136 files of the single source of truth, and it needs a decision I should not make alone:

1. Should the redo transliterate (→ → ->, φ → phi) or simply restore the original characters and drop the L3 ASCII rule for comments?
2. TASK.md and META_DASHBOARD.md state a completed milestone that did not happen. Correct them, or annotate them?
3. Is the L3 ASCII rule still wanted at all? There is no ASCII check in .githooks/pre-commit, scripts/pre-commit or scripts/githooks/pre-commit — 88,033 non-ASCII characters live in the corpus today with nothing objecting.

A regression gate is cheap once the direction is chosen: diff each file against the counter-transform of its pre-image, and fail if any line still matches.