ci: require the two gates I built today and then did not require - #355
Merged
Conversation
Both new jobs in kill-criteria.yml — the composed-graph env sweep (#346) and the MPU enforcement oracle (#349) — were running on every PR and gating nothing. Every other job in that workflow is a required context; these two were not, because I added them to the workflow and never to branch protection. That is the gale#294 defect class, reintroduced by me, in the workflow built to hold that line, on the day I closed #294 saying the invariant was now watched. The check-required-contexts gate did not catch it, and correctly so: it asserts that every REQUIRED context can report, not that every gate worth requiring IS required. Those are different properties and I had only built the first. Worth stating plainly because "we have a gate for that" was exactly the reasoning that let this through. Added to protection only after confirming both complete `success` on main (kill-criteria run, all six jobs green) — requiring a context not proven producible is the deadlock #340 was about, and doing it twice would be careless. Adding them to protection first made the committed list lag at 20 against 22, and the gate's own --protection direction reported it: NOT_LISTED a denied write really faults (REQ-OS-MPU-001 kill-criterion) NOT_LISTED no raw env import survives in the composed graph FAIL: 2 required context(s) may not be produced on a PR exit 1 Second time that direction has caught real drift rather than a planted one. This commit closes it: 22 contexts, list and protection matching exactly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011QG86sovTbfnPNY9SfhSmo
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
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.
Both new jobs in
kill-criteria.yml— the composed-graphenvsweep (#346) and the MPUenforcement oracle (#349) — have been running on every PR and gating nothing.
Every other job in that workflow is a required context. These two were not, because I
added them to the workflow and never to branch protection.
That is the #294 defect class, reintroduced by me — in the workflow built to hold
that line, on the day I closed #294 saying the invariant was now watched.
Why the gate that exists for this did not catch it
check-required-contextsasserts that every required context can report. It does notassert that every gate worth requiring is required. Those are different properties and
I had only built the first.
Worth stating plainly, because "we have a gate for that" is exactly the reasoning that let
this through — the same shape as every other finding in this sweep, applied to my own
work.
Order of operations
Added to protection only after confirming both complete
successon main — thekill-criteria run there is green on all six jobs. Requiring a context not proven producible
is the deadlock #340 was about, and doing that twice would be careless.
Adding to protection first left the committed list at 20 against protection's 22, and the
gate's own
--protectiondirection reported it:That is the second time that direction has caught real drift rather than a planted
one — the first was the 20th context in #343. It is the direction CI cannot check for
itself (
GITHUB_TOKENgets HTTP 403 on branch protection), so it only works when someoneruns it locally, which is an argument for #327's residue rather than a comfort.
This PR closes it: 22 contexts, list and protection matching exactly.
Kill-criterion: a gate lands in
kill-criteria.ymland is not a required context.🤖 Generated with Claude Code
https://claude.ai/code/session_011QG86sovTbfnPNY9SfhSmo