feat(gate-6): give orphan-auth the exclusion its sibling already has - #479
Merged
Conversation
gate-57 (orphaned-write-capability) has shipped `@orphaned-write-capability exclude <reason>` since the beginning. gate-6 asks the same question about the same population — a capability that exists and nothing calls — and had no way to answer it at all. So a dormant predicate that someone had already investigated, written up and assigned an owner still failed the build, and the only ways out were to delete a deliberate near-term capability or to invent a caller for it. pipelinq#764 is exactly that case: seven dormant capabilities behind gates 6 AND 57, one pending decision, and only the gate-57 half could be marked. One of the findings even carries a docblock saying the fix is to build the flow and call it, "never to invent an account-creation endpoint just to give the predicate a caller" — the gate was pushing toward precisely what its own author warned off. `@orphan-auth exclude <reason>`, with a reason REQUIRED like every other exclude in the suite. Four tests; two of them fail against the pre-change checker, so they bite rather than describe. The docblock walk skips blanks, PHP attributes AND `//` line comments from the start. gate-25 shipped the same walk without the `//` case and a comment between the docblock and the declaration made the whole docblock read as absent; that is fixed in this same PR and should not be reimplemented here.
rubenvdlinde
added a commit
that referenced
this pull request
Aug 16, 2026
… it missed, and bound _warn by name (#481) * fix(invariants): complete the #477 demotion in the two suites it missed, and bound it `.github@main`'s `Package invariants` job has been red since 13:15 today. Both failures come from #478 (`e1fe8a4`, gate-19 demoted to advisory), and NEITHER of them is the empty-scope property itself — that property still holds and is still asserted. WHICH PR, SETTLED BY RUNNING THE TESTS RATHER THAN READING CI #476's CI run was CANCELLED (concurrency `cancel-in-progress`, #478 pushed 7s later), so it was neither passed nor failed and could not be exonerated from CI. The two suites were run directly against each merge commit's tree instead: ff66c3b pre-#476 both suites GREEN 0b2c457 #476 merged (gate-35/25) both suites GREEN <- exonerated 530a849 #478 merged (gate-19) both suites RED, 1 assertion each 6f756a8 main (#479 merged) both suites RED, same two assertions WHAT EACH ASSERTION ASSERTED, AND WHAT IT GOT 1. test_gate_empty_scope_never_passes.sh, ARM 1 asserted: `[gate-19] ...: FAIL` over a fixture carrying one planted unannotated scenario. got: `[gate-19] e2e-coverage: WARNING — 1 scenario(s) missing @e2e`. ARM 1 is the POSITIVE CONTROL for the fixture — everything after it is meaningless unless the gate demonstrably sees the planted defect. #477 deliberately moved gate-19's verdict word, not its detection. The arm matched the word rather than the property. 2. test_gate_discarded_counts_and_empty_deltas.sh, ARM P3 asserted: the literal `(PASS|FAIL|NOT APPLICABLE|SKIPPED)` appears in BOTH gate_fixture_support.sh and test_gate_acceptance_matrix.sh. got: both files now read `(PASS|FAIL|WARNING|NOT APPLICABLE|SKIPPED)` — changed IN STEP by #478, exactly as their comments require. The stated property is "the two parsers must stay in step". The implemented mechanism froze the vocabulary instead, so a correct in-step change failed it, and its own repair path was to retype a literal nobody can check against the files it polices. WHICH SIDE WAS WRONG The tests, on both counts — but only in mechanism, and the repair strengthens rather than relaxes: - ARM 1 now accepts FAIL *or* WARNING for gate-19 AND requires the line to name a non-zero count, because a demotion's real failure mode is the finding ceasing to be read. gate-25 is not demoted and keeps the strict FAIL. PASS and NOT APPLICABLE are still refused, and ARM 2 still requires NOT APPLICABLE over the empty scope, so the two remain distinguishable. - A new assertion requires the run SUMMARY to announce the advisory findings and to say that green means "nothing BLOCKING failed". - ARM P3 now extracts the alternation from each parser and requires them to be byte-identical, with the four core verdict forms as a floor so "agreement" cannot be reached by gutting both. - NEW ARM P4: the set of gates allowed to call `_warn` is an explicit allowlist (`19`, .github#477). `_warn` is otherwise one line away from being a soft-fail switch for any gate in the suite, and nothing in this package would have noticed a second one. This does not stop a demotion; it stops a silent one. The empty-scope property is untouched. ARM 2 (`NOT APPLICABLE`, never PASS) and ARM 6 (`no gate reports PASS over a diff that excludes every planted defect`, positive control: 18 gates FAIL the planted tree at full scope) pass unchanged before and after. POSITIVE CONTROLS — each mutation run against an unmodified copy of the package gate-19 `_warn` -> `_pass 19` ARM 1 FAILS: "got: PASS" gate-19 warning with the count removed ARM 1 FAILS: "named no non-zero count" WARNING added to ONE parser only ARM P3 FAILS, naming both alternations gate-18's advisory turned into `_warn` ARM P4 FAILS: "found '18 19', allowed '19'" Both suites also carry the drift/allowlist controls inline, so a future extractor that returns empty for everything cannot call that agreement. The assertion floor in the discarded-counts suite moves 34 -> 37 to match. NOT DONE, DELIBERATELY #478's demotion of gate-19 is a fleet policy decision with a stated reason and a tracking issue; reverting it is the coordinator's call, not this PR's. gate-18's advisory line is printed AFTER its verdict, so `head -1` parsers are safe today — but it is now shape-matchable as a verdict, and that safety is an ordering rather than a mechanism. * fix(invariants): the THIRD verdict parser was never taught WARNING, and it fails silently There are three verdict parsers in this package, not two. #477 taught `gf_verdict` and the acceptance matrix the new WARNING form. It left `_verdict_set` in test_gate_base_ref_delivery_channel.sh — the one that decides "every gate returned the same verdict through both channels" — matching only (PASS|FAIL|NOT APPLICABLE|SKIPPED). Nothing went red, and that is the defect. A verdict word this pattern does not know is DROPPED, not flagged. So gate-19 fell out of both channels' verdict sets, the comparison went on matching over a set that no longer contained the gate that suite exists to watch, and it reported 12 passed / 0 failed. MEASURED, on the real fixture: main @ 6f756a8 "every gate returned the same verdict ... (69 gate(s) compared)" this branch "every gate returned the same verdict ... (70 gate(s) compared)" POSITIVE CONTROL — an A/B against a REAL leak, not an argument. A copy of the runner was made to inflate gate-19's count by one when the base arrived through the environment rather than through --base, i.e. exactly the .github#416 defect this suite was built to catch, planted in gate-19: suite as on main today PASS — 12 passed, 0 failed, "(69 gate(s) compared)" suite with this commit FAIL — "THE DELIVERY CHANNEL CHANGED THE VERDICT" The main-today arm prints both arms' differing counts (`WARNING — 1` vs `WARNING — 2`) two lines above the assertion that then declares them identical. Both this and the ordinary case are now mechanised: ARM P3 of test_gate_discarded_counts_and_empty_deltas.sh compares ALL THREE parsers by name and requires one shared alternation, so a fourth parser or a fourth verdict word cannot be added to some of them. --------- Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
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.
gate-57 has shipped
@orphaned-write-capability exclude <reason>since the beginning. gate-6 asks the same question about the same population — a capability that exists and nothing calls — and had no way to answer it at all.So a dormant predicate someone had already investigated, written up and assigned an owner still failed the build, and the only ways out were to delete a deliberate near-term capability or invent a caller for it.
pipelinq#764 is exactly that case: seven dormant capabilities behind gates 6 and 57, one pending decision, and only the gate-57 half could be marked. One finding even carries a docblock saying the fix is to build the flow and call it, "never to invent an account-creation endpoint just to give the predicate a caller" — the gate was pushing toward precisely what its own author warned off.
@orphan-auth exclude <reason>, reason required like every other exclude in the suite.The docblock walk skips blanks, PHP attributes and
//line comments from the start — gate-25 shipped the same walk without the//case and a comment between docblock and declaration made the whole docblock read as absent.