The context protection is about to depend on reports from one trigger line

[MongLong0214]

Follows #803. Guards the assumption branch protection now rests on.

What was unguarded

lint is one of the two contexts protection requires, and it reports on pull requests only. That is correct rather than a gap — a squash produces a commit carrying no lint context, which is why check-exact-head-ci.mjs requires ten jobs and not eleven.

Measured on both surfaces before writing this:

c622db42 (main)        gate reported     lint absent
#803 head commit       gate reported     lint reported

Protection evaluates the pull request head, so both are there when it looks.

The part with nothing behind it is why lint reaches that head at all: a bare pull_request: trigger in demo-lint.yml. Delete that line and lint becomes a required context that can never report on a pull request — every PR blocks, with no failing check to explain it.

One trigger line, two directions

Another session nearly shipped the mirror image today: requiring, on main, contexts from a workflow triggered only on dev. There the workflow could not report on the protected branch; here it would not report on the protected event. Same failure, opposite direction, and nothing in this repository noticed either.

The assertion reads the parsed trigger set, not the file text, so reformatting does not move it and removal does.

This PR is also the enforcement evidence

Protection was tightened between #803 and this PR: enforce_admins true, required contexts gate + lint, pull request required. That was verified by re-reading the settings, which is not the same as watching them refuse something. This PR is the first to run under them — if gate and lint both report and the merge is allowed only after they do, that is the demonstration the settings change did not have.

Negative control

Removing the pull_request trigger fails the assertion; restored byte-identical.

Full suite 3423 passed, tsc --noEmit clean.

Limit, recorded in the commit

This guards the trigger, not the job name. Renaming the lint job leaves the trigger intact and still breaks the required context, and nothing here catches that.

[github-actions]

CommitLore — record lint

Trailers: clean — 1 commit in origin/main..7617436daa06f6d822b458f673920c59a279e28b
Active constraints: 1 limits · 2 ruled-out · 0 warnings — from 2 records over 1 changed path

Limits (1)

• r-lintpullrequesttrigger 7617436 — this guards the trigger, not the job name. Renaming the lint job leaves the trigger intact and still breaks the required context, and nothing here catches that

Ruled out (2)

• r-lintpullrequesttrigger 7617436 — asserting the trigger inside the release gate instead | that gate deliberately does not know about lint, and teaching it would blur the reason it requires ten
• r-lintpullrequesttrigger 7617436 — making lint report on pushes to main so it is visible there | it would then run on every squash for no purpose, and the release gate would have to start expecting a context it was written to do without

withheld the content of 1 record(s) graded blocked: a Limit trailer matching an injection pattern is reported, never quoted (SPEC §7)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}