gate-48's advisory line displaces its own verdict for both of the package's verdict parsers
On the larpingapp#298 PASS branch, gate-48 prints its advisory before its verdict, with the same prefix:
[gate-48] no CSRF signal was ADDED…
[gate-48] csrf-cochange: PASS
Both parsers in the package take the first matching line:
gf_verdict filters only NOTE|WARN|INFO: — this advisory matches none of those- the acceptance-matrix
_verdict filters nothing
Consequence: the first person to author a gate-48 acceptance bundle will be told gate-48 emitted NO verdict line at all — a gate defect that does not exist. They will then debug the gate rather than the parser.
This is the same class the library's own header documents for gate-61's NOTE, and which #377 repaired there — the guard simply does not reach this shape. The general form is worth stating once: a gate's advisory output and its verdict share a prefix, so any "first line wins" parser is one advisory away from reporting silence.
Correction to a claim I have been repeating — 47 and 48 do NOT pass over an empty delta
A truly empty delta is unreachable through the wrapper. --base <sha-of-HEAD> yields NOT APPLICABLE, not PASS. Anyone reporting "gates 47/48 print a bare PASS over an empty delta" — I did, in several briefs — is describing something that cannot happen.
What does reproduce is a delta containing zero inspectable files. README-only change, one run:
COVERAGE: 4 of 65 … 4 of 4 applicable gates ran
where three of the four are delta gates that opened no candidate file (16, 47, 48 — all PASS), while 19, 29 and 61 say NOT APPLICABLE and name what was excluded.
Gates 47 and 48 are the last two in this band still printing PASS over an empty scope. Gates 46, 50, 55, 56, 58, 59, 60 and 62 were all fixed for exactly this by #242 and #268 — so the remedy already exists in-tree and has been applied eight times.
Two registries of "what has been proven" disagree with the code
Found while checking whether these gates had already been exercised:
UNCOVERED.md records no-fixture-yet · Nothing blocks authoring this for gates 46 and 50. Both already have planted-defect arms inside the package: test_gate_46_tests_scope.sh, and five gate-50 FAIL arms in test_gate_45_to_55_acceptance.sh.
So two registries of proven-ness disagreed with the code, in the same direction — both understating coverage — and neither had been cross-checked against it. That is the same shape as the finding that sent two agents to re-exercise gates that had already been exercised: prior exercise recorded in a file is invisible to a search of the corpus, and vice versa.
What the re-exercise was worth, since the premise was wrong
All ten gates (46, 47, 48, 50, 55, 56, 58, 59, 60, 62) had already been exercised in findings/gate-proof-44-64.md. The re-run was still worth doing because it drove a different layer: the prior pass and both package suites drive run-hydra-gates.sh; this drove bin/hydra-gates — the layer #347 lived in, and the one gate_fixture_support.sh's own header warns a runner-level suite would miss.
88 arms, 10 gates, 0 missed predictions on the final run. All ten WORKS; nothing failed to fire.
It also verified three #379 repairs rather than inheriting them:
- gate-50: opencatalogi
FAIL — 23, split by app-id spelling = 16 variable / 0 constant / 7 literal. The 7 were always visible; the 16 are $this->appName reads of the #86 keys. softwarecatalog: 0 blocking, 64/64 demoted with the positional reason in .notes.
- gate-60: the Tier B WARN branch is reachable (fires on
Invoice, names ReceiptTextOutline, does not fail). Its 19 arms are mutation-proven — reverting _concept_labels() turns 6 of 19 red.
- gate-62: the
type:"caption" node now passes; the gate-60/62 divergence is closed.
gate-48's advisory line displaces its own verdict for both of the package's verdict parsers
On the
larpingapp#298PASS branch, gate-48 prints its advisory before its verdict, with the same prefix:Both parsers in the package take the first matching line:
gf_verdictfilters onlyNOTE|WARN|INFO:— this advisory matches none of those_verdictfilters nothingConsequence: the first person to author a gate-48 acceptance bundle will be told
gate-48 emitted NO verdict line at all— a gate defect that does not exist. They will then debug the gate rather than the parser.This is the same class the library's own header documents for gate-61's NOTE, and which
#377repaired there — the guard simply does not reach this shape. The general form is worth stating once: a gate's advisory output and its verdict share a prefix, so any "first line wins" parser is one advisory away from reporting silence.Correction to a claim I have been repeating — 47 and 48 do NOT pass over an empty delta
A truly empty delta is unreachable through the wrapper.
--base <sha-of-HEAD>yieldsNOT APPLICABLE, notPASS. Anyone reporting "gates 47/48 print a bare PASS over an empty delta" — I did, in several briefs — is describing something that cannot happen.What does reproduce is a delta containing zero inspectable files. README-only change, one run:
where three of the four are delta gates that opened no candidate file (16, 47, 48 — all
PASS), while 19, 29 and 61 sayNOT APPLICABLEand name what was excluded.Gates 47 and 48 are the last two in this band still printing
PASSover an empty scope. Gates 46, 50, 55, 56, 58, 59, 60 and 62 were all fixed for exactly this by#242and#268— so the remedy already exists in-tree and has been applied eight times.Two registries of "what has been proven" disagree with the code
Found while checking whether these gates had already been exercised:
UNCOVERED.mdrecordsno-fixture-yet · Nothing blocks authoring thisfor gates 46 and 50. Both already have planted-defect arms inside the package:test_gate_46_tests_scope.sh, and five gate-50 FAIL arms intest_gate_45_to_55_acceptance.sh.So two registries of proven-ness disagreed with the code, in the same direction — both understating coverage — and neither had been cross-checked against it. That is the same shape as the finding that sent two agents to re-exercise gates that had already been exercised: prior exercise recorded in a file is invisible to a search of the corpus, and vice versa.
What the re-exercise was worth, since the premise was wrong
All ten gates (46, 47, 48, 50, 55, 56, 58, 59, 60, 62) had already been exercised in
findings/gate-proof-44-64.md. The re-run was still worth doing because it drove a different layer: the prior pass and both package suites driverun-hydra-gates.sh; this drovebin/hydra-gates— the layer#347lived in, and the onegate_fixture_support.sh's own header warns a runner-level suite would miss.88 arms, 10 gates, 0 missed predictions on the final run. All ten WORKS; nothing failed to fire.
It also verified three
#379repairs rather than inheriting them:FAIL — 23, split by app-id spelling = 16 variable / 0 constant / 7 literal. The 7 were always visible; the 16 are$this->appNamereads of the#86keys. softwarecatalog: 0 blocking, 64/64 demoted with the positional reason in.notes.Invoice, namesReceiptTextOutline, does not fail). Its 19 arms are mutation-proven — reverting_concept_labels()turns 6 of 19 red.type:"caption"node now passes; the gate-60/62 divergence is closed.