#6308 Required status check `PR CI Gate` is not blocking merges: three of four merges on 2026-09-15 landed before it reported, one of them turning main red

Summary

Three of the four PRs merged into main on 2026-09-15 between 22:21Z and 23:05Z landed before their required PR CI Gate status check reported, and two of them never had that check run on the merged head at all. One of those merges (#6292) put main red: the layout gate on its final head failed 18 minutes after the merge.

Protect main (ruleset 14401535, active, created 2026-03-27, last updated 2026-09-14) declares required_status_checks: [{context: "PR CI Gate", integration_id: 15368}] with bypass_actors: []. A required check that has not reported should block the merge, so this is an enforcement gap, not a workflow bug: the gate itself works correctly when it runs.

Evidence

Merges into main, in order, all by M3gA-Mind (permission maintain, not admin), none with auto-merge:

PR	head	merged at	`PR CI Gate` on that head
#6301	`930ec93a5`	22:21:19Z	success at 22:21:08Z — the only compliant merge (11 s before)
#6292	`eda7b396b`	23:01:09Z	no check run of that name exists (37 check runs on the head)
#6297	`a33d2b089`	23:01:30Z	success at 23:15:50Z — 14 minutes after the merge
#6299	`54abe8b8d`	23:04:48Z	no check run of that name exists

What it cost

crates/openhuman-core/src/skills/catalog/ops.rs was 740 lines on #6292's previous head ebc61bdd6 (whose Rust Quality passed) and 752 on its final head eda7b396b, over the 750-line limit. CI Lite run 35032860765 for that head was created 22:49:50Z; its "Rust Quality (fmt, clippy)" job (104602472090) started 23:19:36Z and failed at 23:21:27Z on step 6, "Enforce OpenHuman Rust file layout":

OpenHuman Rust layout check failed:
  - crates/openhuman-core/src/skills/catalog/ops.rs: 752 lines (limit 750)

The merge happened at 23:01:09Z, ~11 minutes into that run and ~18 minutes before the job started. main was red from 23:01Z until #6307 fixed it.

What this is not

Not a paths-filter gap. rust-quality is gated on needs.changes.outputs['rust-core'] == 'true' || rust-tauri == 'true', and the rust-core filter includes crates/openhuman-core/**. The job was correctly selected; it simply had not run yet.
Not a stale-branch policy issue. strict_required_status_checks_policy is false, which governs branch freshness, not whether the check reported.
Not the same as the earlier breach that night. harness_assembly.rs reached 751 lines through a merge interaction between #6288 and #6298, where each head was individually under the limit (fixed in #6301). This one was over the limit on the PR's own head.

Unverified

The mechanism that allowed the merge is not established. Repository rulesets list no bypass actors and the merging account is not an admin. Organization-level rulesets could grant a bypass, but GET /orgs/tinyhumansai/rulesets needs the admin:org scope and returns 404 for this token, so that path could not be checked. Someone with org admin should confirm whether an org ruleset grants maintainers a bypass of required status checks.

Why it matters

Every merge that does not wait for PR CI Gate can land a breach that the gate would have caught, and each red main then blocks every open PR rebased onto it (that night: #6297 and #6292 both failed "Rust Quality (fmt, clippy)" until #6301 merged). The cost is paid by the next worker, not the merger.

Suggested fix

Confirm whether an org-level ruleset grants a bypass; if so, remove maintainers from it for main.
Until then, do not merge a PR whose PR CI Gate has not reported success on the current head. Checking an older head's green is what let #6292 through: its earlier head ebc61bdd6 was genuinely green, before the commit that added the lines.