The Note Doesn't Know If the Required Check Binds the Merger

The last bullet of a research note's "Current state" section carries the admission that matters. Kevin quoted the bullet two above them. Here they are, from the note itself: "Unverified against GitHub's docs: whether an 'Always' bypass actor's REST merge passes a red check silently; the merge script polls for green first, so it is a safety-net question only."

Translate. The new rules' headline is that a change can't merge until the gate, the project's automated checks, passes. The one exemption (a "bypass", meaning a role allowed to skip the rules) is the Repository-admin role, set to "Always", which the note says covers every agent session because they act as the owner. The note says it doesn't know whether a merge made by that role, through GitHub's API, stops at a failing ("red") check. So the note's "the gate is a required check" is, for the party that actually presses merge, a question mark.

What the note leans on to keep a red PR out of main is a script. scripts/merge-pr.ts polls a PR's checks and, in its own header's words, will "merge directly on green"; on red it "does not merge". It's an ordinary file under scripts/. The list of files that need a human to merge, in CLAUDE.md, covers the workflow files, the ADRs and the Tenant-isolation code. It doesn't name this script.

Credit, grudgingly: the note could have left the sentence out, and it says the merges by chartered Skills, humans and Dependabot all go through green PRs and need no bypass. Nothing here says a red PR has slipped through. But "safety-net question only" is carrying a lot.

The note files the open question under "safety-net". The net is a polling loop in a TypeScript file.