Correct the Zig claim: it does not drop the field, and gen-zig is not a subcommand - #3231
Merged
Merged
Conversation
… a subcommand I wrote that for `bad : 0,` the Zig backend "drops the field entirely, which is worse because nothing downstream can notice". That came from `t27c gen-zig`, which is not a subcommand -- the Zig backend is `gen` -- and the empty output of a misspelled command was read as a dropped field. `t27c` says so on stderr and I was piping only stdout. The real behaviour, measured on two four-line probes: `gen` writes `bad: 0,` and, for the empty type slot, `empty: void`, and BOTH are accepted by `zig build-obj` AND by the deeper `zig test --test-no-exec`. The corrected version is the stronger finding. Rust and C reject both shapes; Zig accepts both at both readings, so the Zig column counts these specs as generating and accepting, and no shape read from Zig output would flag `empty: void` either because `void` is a legitimate Zig type. That is the reason `tri misread` reads Rust and C, and it is now stated as a reason rather than an accident. Blast radius checked rather than assumed. service.rs:1287 invokes ["gen", &sp], so the corpus numbers 581/308/190 were never produced by the misspelling, and the fan-out agent reproduced them independently. `tri misread`'s detectors and its 22/1/0/1 reading are unaffected. Corrected here: skill §566 and the module header of cli/tri/src/misread.rs; issue #3225 carries a correction comment. Refs #3225 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 02:18
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
gHashTag
added a commit
that referenced
this pull request
Sep 5, 2026
…3251) `Documented t27c subcommands exist` reads backticked `t27c <sub>` mentions in live documents and fails on any name that does not exist, unless the document says so in words it recognises: not implemented / not built / does not exist / never existed / no such subcommand. #3231 added a paragraph explaining that `t27c gen-zig` is not a subcommand. It says the right thing and matches none of those patterns, so the gate went red. #3231 merged at 02:21:25Z and the gate's first master failure is at 02:21:28Z -- the run its own merge triggered. Seven successes before, five failures after. Worth recording: I then read three red master runs as evidence the gate was pre-existing and not mine, and `tri pr ready` said "also failing in 4 other place(s) -- pre-existing", which is true and does not mean what I took it for. A defect merged to master fails on every later pull request, which is precisely what pre-existing looks like from a branch-versus-master comparison. The separating question is one command: when did this gate last pass, and what landed between. Repair is one phrase. The checker now reports ok. Refs #3241 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
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.
I wrote — in #3225, in the
docs/nowentry of #3226, in skill §566, and inthe module header of
cli/tri/src/misread.rs— that forbad : 0,the Zig backend"drops the field entirely, which is worse because nothing downstream can notice".
That came from
t27c gen-zig, which is not a subcommand. The Zig backend isgen.The empty output of a misspelled command was read as a dropped field.
t27cprintserror: unrecognized subcommand 'gen-zig'on stderr and I was piping only stdout.What is actually true, measured on two four-line probes
zig build-objzig test --test-no-execbad: 0,empty: void,The corrected version is the stronger finding
Rust rejects both shapes and C rejects both. Zig accepts both at both readings, so
the Zig column of the corpus counts these specs as generating and accepting — and no
shape read from Zig output would flag
empty: voideither, becausevoidis alegitimate Zig type.
That is the real reason
tri misreadreads Rust and C, and it is now stated as areason rather than left as an accident.
Blast radius, checked rather than assumed
bootstrap/src/service.rs:1287invokes["gen", &sp], so 581 generate / 308 accept / 190 analyse were never produced bythe misspelling.
so its findings stand.
tri misread's detectors and its 22/1/0/1 reading are unaffected — they read Rustand C only.
Corrected here: skill §566 and the
misread.rsmodule header, plus adocs/nowentry.#3225 carries a correction comment.
Refs #3225