[antoinetoussaint-byte]

What this fixes

The boundary gate (scripts/check-boundaries.sh) runs on every pull request and
reports green — but it is not a required status check, so nothing stops a pull
request that fails it from merging. Making it required is one API call. Doing
only that breaks the merge queue, and this PR is the other half.

How it was found, rather than reasoned about

I added boundaries to this repo's main protection ruleset at 18:30 today.
#1303 was position 1 in the merge queue, AWAITING_CHECKS, with its
merge_group CI run already completed/success. It stayed there.

Diffing the queue head's check runs against the ruleset's required contexts
named exactly one:

required but ABSENT on the queue head:
boundaries

Every other required context had reported on the queue entry. boundaries.yml
fired on pull_request and push: branches: [main] only, and the merge queue
builds each entry on a gh-readonly-queue/main/... branch and fires
merge_group. So the gate could not report there, and the entry would have sat
until check_response_timeout_minutes ejected it.

I removed the requirement to unblock #1303, which then merged. This PR makes the
gate able to carry the requirement, so it can go back on.

The change

One trigger, plus the comment explaining why it is load-bearing.
go.yml already carries merge_group with a comment making this same point —
including the observation that lint stays pull-request-only on purpose
because only-new-issues has no diff baseline in a merge group. This brings the
boundary gate to the same footing.

Why it matters beyond this repo

A gate that runs and reports is not a gate that blocks, and a required context
that cannot report is worse than no requirement at all — it converts a passing
pull request into a stranded one. Both failure modes are live on this fleet
today: only two of ten repositories checked had their security gate as a
required status check, and codefly-dev/service-python-fastapi had no branch
protection or ruleset of any kind.

The same trap has a quieter form worth stating here, since this file is where
someone will look next: a path-filtered job reports SKIPPED rather than
absent, which satisfies a required context. codefly-dev/cli's pins job
reported SKIPPED on #1289, #1288, #1286 and #1222 — all four — so requiring it
would enforce nothing while appearing to enforce everything. Before adding any
context to a ruleset, check it reports on a pull request and on a queue entry,
and that it reports a verdict rather than a skip.

After this merges

boundaries goes back on the main protection ruleset's required contexts
(16 contexts, up from the current 15). I will do that and confirm it against a
real queue entry rather than assume it.

Docs

No documented behaviour changes: the gate's rule, its script and its governing
handbook page (concepts/boundaries.md) are untouched. What changes is where
the existing gate reports, and that is recorded in the workflow comment itself —
the place the next person editing this trigger will read.

🤖 Generated with Claude Code