fix(gates 45-55): eleven gates passed over an unopened scope, eight over a dead interpreter, and three could not see the defect they exist for

[rubenvdlinde]

fix(gates 45-55): eleven gates passed over an unopened scope, eight over a dead interpreter, and three could not see the defect they exist for

Every gate in this band was given ONE textbook true positive of exactly what
it exists to catch, planted in a real fleet repo, then removed again. Where a
gate could not fail, it was repaired; where it could, the plant is now a
regression test. Measured at package sha 34370f6.

1. All eleven reported PASS over a scope they never opened (#242/#240/#258/#268)

On a README-only diff against larpingapp, gates 45-55 printed eleven PASS
lines and the summary read "53 of 53 applicable gates ran". Not one of them
had opened a file. Gates 4/6/7/19/25/28/62/63 have answered the identical
situation with NOT APPLICABLE since #268; this band never adopted it.

Gates 47 and 48 are the sharper case: they can only answer a question about a
CHANGE SET, so on every builder full-repo run in the fleet — no base ref at
all — they printed a co-change verdict they had not formed.

2. Eight reported PASS over a crashed interpreter (#147/#249/#262)

A planted defect only fires when the gate runs, so no plant can see this. With
a python3 on PATH that exits 1 on every call, on a tree carrying real
findings:

gate-46 PASS — over the 277 unresolved @SPEC findings, across 104 distinct
targets, it had reported one run earlier on the same files
gate-47 PASS — on the same diff where it had just reported FAIL
gate-45/49/50 PASS (2>/dev/null discarded status and traceback)
gate-51/54/55 PASS (|| true discarded the status)
gate-52 FAIL — "1 custom-widget finding(s)", a fabricated finding: the
helper returned its COUNT as its exit status, the same channel
Python uses for a traceback (#209). The count was also clamped to
99 to fit in a byte. It now prints findings=N on stdout and exits
boolean; no findings= line means the helper died.

gate-54 was the quietest: its advisory WARN half reads the same log, so a dead
helper silenced both halves at once.

3. gate-45 was the residue of #272's fix (.github#274)

#272 migrated gates 35/40/42/44 off [ -d src ] onto _a11y_has_markup_dir
and left the twelfth member of the family behind. On a templates-only app
gate-45 reported NOT APPLICABLE — "this repo ships no frontend" — over a
<style> block with transition: and no reduced-motion fallback, in the same
file gate-43 FAILED on in the same run. na is the one verdict that removes a
gate from coverage accounting.

The regression test was already written and gate-45 was excluded from it by
name, with a comment explaining why. Removing the name from ARM 4's skip list
in test_gate_a11y_markup_scope.sh IS the test; it fails against 34370f6.

4. gate-47: prose satisfied it, and a qualified attribute did not

_ANNOTATION_RE was an unanchored alternation of string literals, and it was
wrong in both directions from that one regex — the pairing #269 found in
gate-48 and never carried to its sibling.

FALSE POSITIVE rewording ONE docblock sentence that merely NAMES the
annotation ("becomes @NoAdminRequired again, paired with a
real ownership check") made the gate demand a test
co-change. A gate satisfiable by prose manufactures the
appearance of a security review (#191).
FALSE NEGATIVE #[\OCP\AppFramework\Http\Attribute\NoAdminRequired] was
invisible. A commit adding exactly that to a controller —
opening an admin-only endpoint to every authenticated user —
with no test in the diff reported PASS.

Now position-anchored, by the same rule check_csrf_removal.py already used.

5. gate-50: a false positive and a false negative in the same regex

FALSE NEGATIVE the app-id argument had to be a QUOTED STRING, so every read
written the fleet-standard way — getValueString( Application::APP_ID, 'listing_register', '') — was invisible.
Identical code with 'larpingapp' FAILED. Same family as
#184. 7 security-relevant reads across 5 repos sit behind a
constant today.
FALSE POSITIVE the empty-compare guard required a closing paren immediately
after the empty string, so the correct compound guard
if ($reg === '' || $sch === '') was reported as unguarded —
twice, on code the gate was asking for. A guard that is a
boolean return rather than an if was rejected too.

Both directions are now asserted, including the opencatalogi#86 shape that
mixes them: one read guarded, the next unguarded two lines later.

6. gate-53 did not block the PR that creates larpingapp#286

Reintroducing #286 exactly — the check-in tab deleted from src/manifest.json,
EventRoster left registered in src/registry.js — reported PASS. Direction 1
of the registry cross-reference stays advisory for LEGACY orphans, correctly:
the gate cannot tell "wire it" from "delete it". But when the DIFF ITSELF
removed the last reference it can, and that finding now blocks. Pre-existing
orphans are untouched (larpingapp carries one today), so this is prevention,
not a burn-down list nobody can close.

Verified working, repaired nothing

gate-46 (dangling file, dangling fragment, valid anchor), gate-48 (short and
fully-qualified attribute removal; a comment reword correctly stays green),
gate-49, gate-51 (title, description and nested items.properties independently),
gate-52's ratchet (growth fails, shrink passes), gate-54 (flat, nested and
$ref-carrying), gate-55.

Deliberately NOT enforced

title == key on a schema property is a real gate-51 defect — the renderer
uses prop.title || key, so the user sees the raw technical key. Measured
across 10 repos: 148 occurrences, ALL of them in softwarecatalog, where they
are VNG-standardised element names (identifier, type, name) that must
not be renamed. Enforcing it would produce 148 findings with no legitimate end
state in the one repo that has them. Reported rather than gated (#252).

Divergence to reconcile

gate-45 now answers an empty in-scope set with na; gate-40 answers it with
PASS, by a deliberate choice in #272 that cited the invariant test this PR
reworks. The invariant now discriminates on the REASON — the applicability
table's own phrasing must not appear once its prerequisite holds — so both
behaviours are expressible. The family should pick one.

Testing

New: hydra-gates/scripts/lib/test_gate_45_to_55_acceptance.sh — 31 arms across
six families, discovered by run-helper-suites.sh. Against the package as
merged on main it fails 20 of 31; the 11 that pass are exactly the
anti-widening and no-regression controls. Every mutation asserts its anchor is
present before it plants.

Repos used, chosen for different shapes: larpingapp (register-owning,
manifest-driven, ships registry.js), nldesign (PHP templates, no .vue, no
register), doriath (ships no phpcs SpecTagSniff — the #246 control, held at
81 findings across 46 targets before and after the plant), openconnector
(41 register files).

Full package suite: 52 discovered suites pass, 2 quarantined as documented;
60/60 entry-point invariants.

[rubenvdlinde]

Correction to a number in this PR's description

The description says the constant-app-id blind spot was measured at "7 security-relevant reads across 5 repos". That is an undercount, and the cause is mine: the loop I measured with enumerated ten repos by hand and pipelinq and hermiq were not in the list. A hand-written repo list decays exactly like a hand-written paths filter — the omission is invisible.

Recounted over twelve repos:

openconnector       1
procest             1
larpingapp          2
softwarecatalog     1
decidesk            2
pipelinq          291        <- omitted from the original count

pipelinq writes Application::APP_ID throughout, so its entire gate-50 surface was invisible: the gate reported PASS on that repo and now reports 38 findings. Spot-checked both ways:

• real — lib/Service/ContactImportService.php:65 reads client_schema with no guard and passes it straight to saveAndSerialize(). An empty schema id there is an unscoped write; this is the opencatalogi#86 shape the gate exists for.
• read-out — lib/Service/ActivityTimelineService.php:125-129 are entries in an array literal in getConfig(), the same shape fix(gate-50): the app-id widening reached settings read-outs, which have nothing to guard #282 removed for variable app-ids. About 4-6 of the 38 look like this. They are not excluded, because they use a class constant and the gate cannot yet tell a scope decision from a read-out — a limitation now stated in the helper's own comment and pinned by test arms C9/C10.

So the direction of the fix is unchanged and the finding it recovers is real, but "7 across 5 repos" should read "~298 reads across 6 repos, of which 38 are unguarded — 38 of them in pipelinq alone." Recording it here rather than leaving the smaller number to be quoted onward.

Related: the sweep I used to validate this PR compared verdicts, not counts, and that is how a 23 -> 64 regression on softwarecatalog reached main — FAIL before, FAIL after. Fixed in #282; the method note is in that PR's description.