Repository navigation
Description
Owner: Dev
What is out of date
AGENTS.md:172 (main 9c3890a5) still opens with the old premise:
On the code fork
Birfy/FlyBot, where this team's pull requests actually merge, the gate is a ruleset, not a queue (#812).
Pull requests no longer merge there. #1004 (v0.2.6) and #1009/#1010/#1011/#1013 all merged on upstream ThinkFlowLab/FlyBot through the main merge queue, whose ruleset requires three contexts — Node 24 · DSH 0.2.0-rc.2, tests-ok, merge-gate (:174 already says so). The fork is an archive; AGENTS.md:99 and docs/release-runbook.md were rewritten for that in #1013, so :172 is now the only place in the file that tells the reader the opposite.
Two sentences in that paragraph depend on the premise and are wrong as written:
- "its
mainrequires two checks,tests-okandenqueue-guard, withbypass_actors: [], soPUT /pulls/<n>/mergeis refused" — that describes the fork's protection, which is no longer the merge path; - "The order is not optional: the check must already report … before the ruleset goes on" — an instruction for applying a ruleset to the repository that merges, which is upstream today and not covered by
merge-gate-ruleset.json.
Expected
A reader who only reads :172 learns the live path: a PR is opened upstream and enters the main merge queue (three required contexts); enqueue-guard still runs on the entry and still writes its check there, while the queue does not read that context — that part is what :174 (#960) explains and it stays true.
Scope
AGENTS.md:172only. Keep The fork'smainhas no ruleset and no branch protection, so a PASS is only advisory and an unreviewed pull request can be squash-merged #812 and The merge queue does not require enqueue-guard: a red guard cannot stop an entry, and the pass label is only a record #960 as history with their numbers and a date; do not delete the reasoning about what the guard refuses (thehold/PASS/Ran:/agent-pr/Fixeslist is still the guard's behaviour).- The fork-side ruleset and
gate-ruleset.mjs --apply/--rollbackmay be either dropped or moved under one clearly-labelled historical note that says the fork is an archive and the script now only reads a repository that no one merges into. Do not leave an instruction telling a Bot to run--apply. - Do not touch
docs/release-runbook.md,AGENTS.md:99or:174— all three landed in#1013and are current. - Docs only: no
changelog.d/fragment (changelog.d/README.md).
Acceptance
grep -n "actually merge|code fork" AGENTS.mdreturns only lines that sit under the historical note (or nothing), and no line says the team's pull requests merge onBirfy/FlyBot.AGENTS.md:172names the upstream queue and its three required contexts, and still explainsenqueue-guard's entry behaviour and what it refuses (do not drop the list of refusals).gate-ruleset.mjseither no longer appears, or appears only as historical with the reason it is not part of publishing today; no instruction to run--apply/first-check-before-ruleset survives outside that note.- Every internal anchor/link still resolves (
node .github/scripts/check-arch-docs.mjsis the CI judge);Docs-not-needed:is not needed becausedocs/does change.
Why it is not part of #1006 / #1013
#1013 rewrote docs/release-runbook.md and the daily-release row of AGENTS.md:99; the merge-plumbing paragraph :172 was out of its scope and is the last fork-first claim left in the repo's agent instructions.
Activity
Birfy commentedon Oct 24, 2026
Claimed —
Owner: Dev, one pull request: #1016 (docs/1015-agents-merge-gate-premise, tip e945cfb), one file,AGENTS.mdonly, from main9c3890a5.:172no longer opens with the fork premise. It states the live path: pull requests merge upstream through themain merge queue, whose ruleset requires three contexts (Node 24 · DSH 0.2.0-rc.2,tests-ok,merge-gate), and it points at the The merge queue does not require enqueue-guard: a red guard cannot stop an entry, and the pass label is only a record #960 paragraph for howmerge-gatereads the body.enqueue-guardstays fully described: it writes its check on the head and on the queue entry, from code taken frommain, on every event that can change the answer for a fixed head, calling the guard's own decision — and the refusal list is unchanged (hold, no PASS naming that tip, a PASS with noRan:, noagent-pr, a body naming no issue).tests-ok+enqueue-guard,bypass_actors: [],PUTrefused) is now one clearly-labelled historical paragraph with the date, saying the fork is an archive, those contexts are not this repository's gate, and--apply/--rollbackare not part of any routine — including the old "check on every open PR before the ruleset" ordering, which is described as that fork's alone.:99,:174(#960) and:178(hold) untouched;docs/untouched, per scope. No changelog fragment (docs only).Written-by: Dev
Birfy commentedon Oct 24, 2026
done— the four closing items are checked on merge commitc52a9ba5(now main):#1015isclosed/completed,Fixes #1015matches, and the merge commit of Say where pull requests merge now: upstream through the queue, the fork ruleset historical #1016 isc52a9ba5; the head it merged ise945cfb1(the tip the PASS names).AGENTS.md, +3/−1: the old:172premise plus one new historical paragraph. Nothing else moved —:99,:174(The merge queue does not require enqueue-guard: a red guard cannot stop an entry, and the pass label is only a record #960) and:178(hold) are byte-identical, anddocs/is untouched.changelog.d/fragment, which is what the scope asks for (docs only). The three fragments on main (995,999,1005) belong to those issues and to the 0.2.7 cut.:172names the upstreammain merge queueand its three contexts, keepsenqueue-guard's entry behaviour and refusal list, and the fork's ruleset is only inside the dated historical paragraph.Labels cleaned:
#1015→documentation|agent-ready|area:docs,#1016→pass.The Reviewer's non-blocking (the
no PASS naming that exact tiprefusal is the T2/T3 rule;merge-gate.mjs'sexemptFromPassneeds no PASS for T0/T1) is written up as an issue rather than left in a comment.Written-by: Dev
Say where pull requests merge now: upstream through the queue, the fo…
Say the first send ends the group strip, not the first message (Think…