A subject that was built and then cut to nothing reached no rule at all, and said nothing (#186)

[fdaviddpt]

scripts/pre-tool-hook.sh builds a subject full_command from the tool_input keys, then cuts it at the first ; & | " or -- to get cmd — the command words. A command that begins with one of those bytes has no command words at all: {"command":"; git push"} leaves cmd empty while full_command was non-empty the whole time. The hook printed {} and exited before the layer loop that consults any rule.

It was a short-circuit on the wrong variable, not a policy

cmd is the subject of exactly one consumer: the substring arm of the tool matcher. Three others read something else and were skipped by a test about a variable that is none of their business.

• The regex arm matches full_command, deliberately — that is what makes cd x && git push reachable at all, and it is what README.md's "What a tool rule is tested against" table has always promised. So a ~match rule would have matched and never ran, and because this is the only dimension that can refuse a call, a mode: block regex rule failed open on any command starting with a cut byte. Indexed, validated, counted by every diagnostic, reading as enforced, never run.
• The vocabulary pass lifts path tokens out of command (the whole command) and never touched cmd, so ; cat src/Billing/x.php bound nothing while true; cat src/Billing/x.php bound Billing the whole time. This one is not in the issue and is what settled the design: the question stops being "should the two matching arms agree" and becomes "why is a test about the substring arm's subject gating three consumers that do not read it".
• The per-row refusal notices need no subject at all.

The line is deleted. The substring arm needs no exit of its own: index("", term) is 0, and rebuild-tsv.sh:280 refuses a row with an empty match: column, so no row's term can be empty.

The three judgment calls the issue named

1. Should the regex arm run when the substring arm has nothing? Yes, and it is narrower than it sounds. A regex rule already matches the whole command on every other call — ~git push already fires on echo "git push" today, which is the price the README already documents for being able to anchor past a chain operator. The only calls whose verdict changes are those whose command words are empty, and on those the rule now does exactly what it does everywhere else. This is not new policy; it is the removal of an inconsistency.

2. Does this state get its own report? No, and that is a decision rather than an omission. After the fix nothing is unreached: every row is read, the regex ones are evaluated and can fire, and a substring row that does not match is an ordinary non-match — the same one true; git push has always produced silently. A notice here would fire on that entire class and would call rules unreachable that are working exactly as #7 intends. The #182 census is untouched and still gated on the whole subject; section E of the new suite drives the two states apart in one tree.

3. Is the cut itself the bug? No. Cutting at the first ; & | " is what stops a substring rule about git push firing on echo "git push" (#7). Narrowing it to keep the first command word would fix this case by reopening that one. Section C pins the cut as kept rather than quietly narrowed: git push still does not fire on ; git push, exactly as it has never fired on true; git push.

Tests

tests/test-cut-to-nothing.sh, 35 assertions across 6 sections. Every must-not-fire assertion sits beside a must-fire control in the same fixture, same tree, same hook — {} is what a dead tree, an unread layer and a hook that died all produce, and this issue is about not being able to tell those apart. Section B carries a negative control (; ls -la, a cut-to-nothing command the block rule does not describe) so it cannot pass by blocking everything. Every index is written by rebuild-tsv.sh from real frontmatter.

Red before the fix: PASS: 26 FAIL: 9, every failure a {} where a rule body was expected, every positive control green. The reviewer reproduced that count independently against 19f6c46. Green after: PASS: 35 FAIL: 0 on one-true-awk 20200816, GNU Awk 5.4.1 and mawk (PATH-shimmed, darwin 24.3.0). Full suite green, 2813 assertions, 0 skipped, exit 0.

Review

Two spawns against the committed diff. The auditor returned five classes, 0 findings, 0 could-not-check, and confirmed by reading .github/workflows/tests.yml that run-all.sh runs on ubuntu-latest, macos-latest and windows-latest — so the new suite is covered on all three legs by CI, which no local run can establish.

The reviewer found one real defect: the changelog fragment claimed 2817 full-suite assertions where the measured figure is 2813 (the first count used grep -c 'PASS:', which also counts each suite's own summary line). Corrected and amended.

Recorded rather than smoothed over: the reviewer's final message ended "beyond the one changelog number mismatch reported above" and that message contained no such statement — the item survived only because it was re-derivable. That is the partial form of the empty-return failure and it is in the report.

Not in this PR

scripts/jit-dry-run.sh:629,652 and scripts/jit-doctor.sh:553 cite line numbers in pre-tool-hook.sh that were already wrong on merged main (verified by reading them out of git show origin/main:), and this diff shifts them ~35 lines further. That is the class rather than the instance — a cross-file line-number citation convention in a repository whose files move every PR — and it wants its own issue and its own sweep.

Closes #186

Verified by the maintainer

The premise I briefed was wrong, and the author is right. I framed this as "the two matching arms disagree about a cut-to-nothing subject" and handed over the evidence for it. The author found a third consumer that exit was skipping — the vocabulary pass, which lifts path tokens out of the whole command and never read cmd at all, so ; cat src/Billing/x.php bound nothing while true; cat src/Billing/x.php bound the whole time. That reframes the defect from a disagreement between two arms into one short-circuit on a variable that is only one consumer's business, which is also why the fix is a deletion rather than a reconciliation. Nothing in my brief pointed there.

Red re-run, mine, against merged main at 19f6c46 with the fix absent: PASS: 26 FAIL: 9, every failure a {} where a rule body was expected. That is the same count the author measured and the same count their reviewer reproduced independently — three derivations, one number.

I accept the two refusals in this diff, and they are the harder half of it. Not adding a notice is right: after the deletion nothing is unreached, and a notice on this class would call working rules unreachable — it would fire on the ordinary non-match that true; git push has always produced. Keeping the cut is right for the same reason it was introduced in #7, and section C pins it as kept rather than quietly narrowed, which is the assertion I would have asked for if it were not already there.

The reviewer went partially dark again — its final message referred to "the one changelog number mismatch reported above" and contained no such statement. The item survived only because it was re-derivable by re-counting the suite log. That is the third reviewer in this session to name findings it did not state, and the author recorded it as partial rather than rounding it to clean, which is the correct call.

Filed rather than carried: #191 — the stale cross-file line-number citations in jit-dry-run.sh and jit-doctor.sh. All three were already wrong on merged main before this diff, verified by reading them out of git show origin/main:; this diff shifts them further. It is the convention that needs deciding, not the four numbers.