fix(gates 22/25/28/49/54/61): a crash is not a finding, and a tag's position is not its owner

[rubenvdlinde]

What this is

Six defects across six gates (22, 25, 28, 49, 54, 61). Each was reproduced with a positive control before any line changed, and each is pinned by an acceptance arm that is demonstrably able to fail against the previous package.

Three of the six are the same disease: a checker that could not run produced a statement about the source code. A gate that sends someone to fix a defect that does not exist spends the same credit as one that hides a defect that does — and it spends it on the reader, who looks, finds nothing, and learns that this gate can be ignored.

The crash class — gates 22, 25, 28

Measured on one fixture, two runs, only the interpreter varying. Every subject in that fixture is deliberately clean or deliberately singular, so the crash arm cannot hide behind a tree that was going to be red anyway.

gate-22 clamped a measured count of zero up to one, so a validator that died on import was reported as a schema violation in a manifest that validates clean. Node indents its stack trace, so the diagnostic count was genuinely zero — and zero was read as "at least one".

gate-25 could not read a count out of its log, substituted the words "an unreported number of", and blocked the build on it. The gate said, in its own verdict line, that it had not measured the thing it was failing you for.

gate-28 is the worst of the three because it names the repository. Its helper ran inside a command substitution whose pipeline value was sed's, discarding the exit status, while sed ate the traceback so the reason was never written anywhere. Zero compared files then fell through to a branch telling the repository that not one of its files carried a licence header — with both files in scope declaring EUPL-1.2.

The guard is the one this package already documents in _helper_finished: a finding count must be measured, and the evidence that it was measured is the checker's own output. The tell differs per gate (an at <pointer> diagnostic, a FAIL — N summary, a declared_files=N line), so each gate reads its own. gate-28 additionally keeps its traceback on disk.

Worth flagging for whoever picks up the rest: gate-28's own header comment was written specifically to stop that sentence being printed, and it guards the missing-helper case only. A helper that is present and crashes walks straight past it. A guard written against one way of not-running does not cover the others, and prose describing a hazard is not the same as code testing for it.

A tag bound to something it does not describe — gates 49 and 25

gate-49's method regex opened with an unbounded lazy docblock group. Lazy is not bounded: it can expand through a comment terminator and stop at a later one, and the leftmost match in a normal controller starts at the file header. So for the first method in every file the group swallowed the span from the header down to that method's own docblock, header text included. One @throws written once at the top of a file silenced the first method in it, invisibly and fleet-wide. The tell was a finding reporting line 2 for a method on line 22.

The group is now tempered so it is exactly one comment. Deliberately not widened: a docblock separated from its declaration by a PHP attribute did not bind before and still does not. That change would remove findings, which is the opposite direction, and it does not belong behind a fix that adds them.

gate-25 asked the same question with a twenty-line window and was wrong in both directions in one file in one run — it flagged an administrator-only method by reading the previous method's attribute across a closing brace, and stayed silent about a genuinely public untested one whose own attribute sat twenty-one lines up behind its docblock. The silent half is the dangerous half, since detecting a newly-exposed endpoint is the entire purpose of the gate. The auth lookup now walks the declaration's own preamble structurally, the way the @contract lookup twenty lines below it in the same file already did.

The finding count on that fixture stayed at one. That is worth stating plainly: this is a substitution, not a narrowing. A fix that had only quieted the false positive would have dropped it to zero and looked like progress.

A verdict that does not say which diff it came from — gates 61 and 54

gate-61 passes a base unconditionally, which is deliberate. But on a full-scope run the wrapper forwards no base, so the runner's own default is used while the preamble has already announced there is none. A head commit that touches a listener therefore produces a real blocking failure under a header denying the diff exists. Controlled on one tree, full-scope both times, only the head commit varying: touching the listener gives a failure, touching only a docs file gives not-applicable. Two answers from one tree prove the verdict is diff-derived.

The verdict does not change. The gate now names the base it judged against, on unscoped runs only — a diff-scoped run already prints the base in its preamble, and the suite asserts the note is absent there. That keeps this neutral to the in-flight full-scope-by-default decision: whichever way gate-61 is classified, its output stops being readable as a whole-tree result.

gate-54's file-scoped checks stay file-scoped and stay blocking. A banned dialect in a register you edited is yours to fix, and narrowing those checks to touched lines would be making the gate green by weakening it. What was wrong was never the verdict — it was that a one-line retitle inherits every finding in the file and the output said nothing about it, so a sweep saw base-and-head findings that were byte-identical with no way to rank them. Each finding is now labelled inherited or introduced against the base, and the verdict carries the split. When no base is known nothing is labelled and the verdict says so, rather than letting the absence of labels read as "these are all yours".

What proves it

Four new planted/clean bundles, with their UNCOVERED.md rows deleted as that ratchet requires; fixtured gates go from thirteen to seventeen. Two of them are built so a merely-quieter gate cannot pass: the exception-translation pair's two arms contain the same tag and differ only in which docblock holds it, and the contract-coverage pair's controller is byte-identical across arms so the planted arm demands more and the clean arm demands less, graded on the same file.

A new provenance suite covers what needs real git history, and the crashed-checker suite grows an arm for the three gates above — including an assertion by text, not only by verdict, that gate-28 makes no claim about files it could not read.

Both directions were measured by swapping only the package under the same fixtures. Against the previous package the new arms produce three acceptance failures and three provenance failures; against this branch they all pass. Ten existing suites were re-run green.

Notes for review

Gates 22, 25, 28, 49, 54 and 61 are implemented inside run-hydra-gates.sh, which is being edited concurrently by others. This branch touches only those six gate blocks — no shared helper, no preamble, no coverage accounting, and not bin/hydra-gates.

Two fixture errors of mine are recorded in the findings file and in the fixtures themselves, because both produced the answer I was expecting: a fixture that was not a git repository at all, and an explanatory comment that would have satisfied the very regex it was describing.

Please do not merge without a coordinator decision — this moves the verdict for eighteen apps at once.

[rubenvdlinde]

Follow-up: measuring this on real apps found a bigger mechanism under gate-49, and my first fixture missed it

The description above says the file-header @throws "silenced the first method in the file". That is true and it is the smaller half.

An unbounded lazy group cannot end a match at a declaration carrying a PHP attribute, because \s* cannot cross #. So the regex kept expanding to the next declaration it could end at — an attribute-free one — and since finditer returns non-overlapping matches, every method in between was consumed. Not credited with the wrong tag: never inspected at all.

On portaliq's ContributionController.php one match spans lines 167–334 and absorbs index(), inbox() and markRead(). The old regex saw 13 of that file's 24 methods, and the eleven it could not see were every routed #[PublicPage] endpoint in it. Across eight apps and 413 controller files it saw 2,754 methods of 3,120 — 366 invisible, 11.7%, and 33.9% in the worst app. The methods that carry attributes are exactly the network-reachable ones, so the gate was blindest precisely where it mattered.

The fixture in the first push did not reproduce this. The plant needs an attribute-free declaration below it, or there is no later end for the expansion to reach, the engine falls back to matching the plant directly, and the arm passes against the broken gate. The bundle now carries a third method whose only job is to be that end, and its docblock says so, so a later tidy-up does not delete the assertion.

Before/after on four real apps

Both arms run back to back on the same tree against frozen package snapshots, with the tree SHA and dirty count re-read after both arms. Full scope, no base, 57–58 of 64 gates reporting.

Portaliq goes PASS → FAIL — 2 on gate-49, naming markRead() and update() — both previously invisible. Decidesk goes PASS → FAIL — 1, naming applyCorrectionResolution(). Both were predicted by name, in writing, before the runs.

Decidesk also moves on gate-25, FAIL 25 → 24. The endpoint that stopped being flagged is settings#setPublicationConfig, whose own attribute is #[AuthorizedAdminSetting(AdminSettings::class)] — administrator-only, and it was being reported as a new public endpoint because the twenty-line window reached a neighbour's tag. That is the false-positive half on real code, with the declaration itself as the proof.

Nothing dropped to zero anywhere.

Why gate-25 does not move on openregister or opencatalogi

The sets are identical, not merely the counts, so I counted the two divergent shapes directly rather than inferring their absence — instrument positive-controlled on the fixture that has them. Across eight apps there are fourteen false-positive shapes and eight false-negative shapes. Thirteen of the fourteen are constructors, which are never routed and were never reported; the one that mattered is decidesk's.

All eight false-negative shapes are openregister, seven of them routed. They are now seen as public endpoints, and every one is judged covered — which is why the count holds at 66. Traced individually, two of them have neither a Postman URL match nor a direct call, and are matched only by gate-25's looser PHPUnit fallback, where a test file naming the controller class and mentioning the method anywhere counts as coverage.

So "gate-25 unchanged on openregister" is a fact about that coverage matcher, not about the binding fix: the fix widened what the gate looks at there by seven routed endpoints and the matcher absorbed all seven. I have not touched the matcher — it is a separate weakness and a separate decision.

One measurement I am not quoting

Openregister's shared checkout went from four to six dirty files between my two arms — another agent working in it — so the guard I built for exactly that case fired and its runner-level row is not comparable. Its per-gate lines are identical either way, and the checker-level numbers above were single-pass reads at a pinned SHA, but I would not quote the openregister runner row as evidence.