docs(agents): name the merge queue as what arming auto-merge hands off to

[claude]

Fixes #1815

AGENTS.md §How a green PR lands told every seat that a green, non-governed PR lands by arming auto-merge, and deliberately never named a merge queue. PR #1798's body records that omission as intentional, on the premise that this repo has none. The premise is false. The section now names the mechanism arming hands off to.

⛔ The gesture is unchanged and nothing is rolled back — arming auto-merge enqueues, and everything that landed this round landed correctly. This is a description defect.

Re-measured on this branch, before any prose was written

Per the dispatch, the card's reading was not inherited. Both channels, at 5c329c6:

Configuration — GET /repos/objectstack-ai/hotcrm/rulesets returns exactly one ruleset: main, id 12187346, enforcement: active. Its rules are deletion, non_fast_forward, merge_queue, pull_request. Queue parameters, verbatim:

{"merge_method": "SQUASH", "max_entries_to_build": 5, "min_entries_to_merge": 1,
 "max_entries_to_merge": 5, "min_entries_to_merge_wait_minutes": 5,
 "grouping_strategy": "ALLGREEN", "check_response_timeout_minutes": 60}

Behaviour — added_to_merge_queue then removed_from_merge_queue by github-merge-queue[bot] on every recently merged PR (#1810, #1811, #1813, #1816).

The legacy GET /branches/main/protection returned 403 in this container too, reproducing the origin of the false belief. ⇒ My measurement agrees with the card: the queue is there. No fork.

⭐ Where my measurement DISAGREES with the card — the 5-minute wait

The card, and the dispatch's Zone-3 advice, both read min_entries_to_merge_wait_minutes: 5 as a wait a seat should expect, and offer it as the explanation for PR #1795's "5m40s from creation to merge". Measurement says it is neither.

Nine merged PRs, every one of them 17–20 seconds from added_to_merge_queue to merged:

PR	enqueued	merged	enqueue → merge
#1795	14:17:21Z	14:17:38Z	17s
#1798	15:25:20Z	15:25:38Z	18s
#1799	14:51:50Z	14:52:07Z	17s
#1801	15:13:34Z	15:13:54Z	20s
#1809	12:19:09Z	12:19:26Z	17s
#1810	12:06:45Z	12:07:02Z	17s
#1811	12:16:19Z	12:16:37Z	18s
#1813	12:20:20Z	12:20:37Z	17s
#1816	12:32:47Z	12:33:05Z	18s

The parameter caps how long the queue gathers a group before merging a smaller one; it never engages while min_entries_to_merge is 1, because the first entry already satisfies the minimum.

And PR #1795's 5m40s decomposes, from its own timeline: created 14:11:58Z → ready_for_review 14:17:16Z (5m18s sitting as a draft while its checks ran) → enqueued 14:17:21Z (5s) → merged 14:17:38Z (17s in the queue). 340s total, of which the queue owns 17.

⇒ Recording "expect five minutes" would have installed a false expectation and re-blessed the #1795 misattribution. This is the card's own lapse — "using a counting instrument without first establishing what it counts" — one level up: the card corrected a mismeasurement and read a second number off the same config without establishing what it does. The section therefore warns against re-deriving the figure instead of repeating it. This is a declared deviation from Zone-3 advice #3 — a question for the seat, not a decision taken on its behalf.

The second judgement call — the immediate-fire consequence

Dispatch item 4 asked whether "arming on an already-green PR merges immediately" can be made visible without expanding scope. It can, in the existing sentence's own terms: the section already requires that a seat arm only after every check has finished, so the consequence follows from the precondition already written — the new paragraph states it as the enqueue fires at once and the queue merges within seconds, and draws the operational conclusion a seat needs (landing, not stuck). ⛔ No new procedure was invented. Confirmed by measurement: ready_for_review → added_to_merge_queue was 2–5s on all nine.

Scope

• ⛔ Every existing sentence in the section is byte-identical. The mechanism is added as one new paragraph; the only edit to existing text is an appended italic clause inside the section's own provenance blockquote. Diff is 12 insertions, 1 deletion.
• ⛔ No other AGENTS.md sentence moves — :348 (AGENTS.md:348 counts the drift its own rule forbids as "four times", and the ledger at :353 has not been incremented since #1620) untouched, and nothing AGENTS.md File Suffix Protocol is an inventory that drifted both ways: 4 of its 12 declared suffixes have zero instances in src/, and 8 suffixes the app really authors are absent from it #1745 or AGENTS.md rule 6 says "UI nouns take the zh-CN pack wording", but a pack-carried noun that is not a list view must stay English — and only an ablation reveals it #1618 owns.
• ⛔ CONTRIBUTING.md not touched. ⛔ No workflow, gate, script or branch-protection change.
• ⛔ The required_status_checks reading was not acted on, per the dispatch.

Gates

pnpm verify — exit code 0, captured before any pipe. All eight stages ran: validate ✓ · typecheck ✓ · lint ✓ · lint:i18n-gate ✓ (0 i18n/missing-*) · hygiene ✓ · hygiene:tokens ✓ · build ✓ · test ✓ 165 files, 3453 passed, 1 skipped.

Changeset: .changeset/agents-md-names-the-merge-queue.md, empty frontmatter — the sanctioned "releases nothing" declaration; this is an agent-facing governed doc and nothing ships to users.

Acceptance notes

Observations only, not filed and not acted on:

• The same ruleset carries no required_status_checks rule — already recorded on AGENTS.md §How a green PR lands says "arm auto-merge" and never names the merge queue — but this repo HAS one, and the ruling that said so was overruled on a mismeasurement #1815 as a reading, deliberately not work here.
• required_approving_review_count: 0, but require_extra_approval_for_unattributed_changes: true.
• Noted, not filed: the queue's check_response_timeout_minutes: 60 and ALLGREEN grouping are unmentioned anywhere in the repo's prose. Carrier: none identified — no queued card owns this file's landing section after AGENTS.md File Suffix Protocol is an inventory that drifted both ways: 4 of its 12 declared suffixes have zero instances in src/, and 8 suffixes the app really authors are absent from it #1745 / AGENTS.md:348 counts the drift its own rule forbids as "four times", and the ledger at :353 has not been incremented since #1620 / AGENTS.md rule 6 says "UI nouns take the zh-CN pack wording", but a pack-carried noun that is not a list view must stay English — and only an ablation reveals it #1618, so there is no PR that would naturally pick it up.

⚠️ Governed surface

AGENTS.md ⇒ this PR stays a draft. ⛔ Not marked ready, ⛔ auto-merge not armed, ⛔ not enqueued. The maintainer merges.

维护者速读（草稿）

改了什么 — AGENTS.md 里"绿灯 PR 如何落地"这一节,补上了这个仓库真实的落地机制:合并队列(merge queue)。原文只说"打开 auto-merge",并且是刻意不提队列的 —— PR #1798 的正文写明了这个决定,依据是"本仓库没有队列"。这个前提是错的。动作本身没变,回滚也没有:打开 auto-merge 就是入队,本轮所有 PR 都是正常落地的。这是一处描述缺陷,不是流程故障。原有句子一字未动,机制以一个新段落补入。

为什么改 — 一句写错的机制说明,会让之后每一个席位去找一个不存在的东西,或者把正常现象误读成故障。本车道已经为此付过一次代价:PR #1795 的"5分40秒"曾被当作"有人手工快速合并"的证据来引用。另外,原判决(决策批次 #81)说的"合并队列是唯一入口"本来是对的,却被一次测错的探针推翻了 —— 这次一并把判决的原话恢复到记录里。

风险与代价(含回滚) — 风险极低:改动只有文档散文,不触碰任何代码、工作流、门禁或分支保护;对用户不发布任何东西(changeset 用空 frontmatter 声明"不发布")。pnpm verify 全链八步全绿。回滚代价就是 revert 这一个 commit,不牵连任何其它东西。需要您留意的一处判断:PM 建议把队列参数里的"5分钟等待"写进文档,我实测后没有采纳 —— 九个已合并 PR 从入队到合并都是 17–20 秒,那个参数管的是"凑齐一组最多等多久",在 min_entries_to_merge 为 1 时根本不生效;#1795 的 5分40秒里有 5分18秒是它作为草稿在等自己的检查跑完。写进去反而会立一个假预期,所以文档改成提醒不要从配置里推出这个五分钟。这属于对建议的公开偏离,请您裁定。

席位意见 —

你要做的 — 这是受管路径(AGENTS.md),按规矩由您合并:PR 保持草稿,席位不翻 ready、不打开 auto-merge、不入队。请确认两点:①上面那处"不写五分钟"的偏离是否照准;②节内新增段落的措辞是否合适。确认后由您合并即可。

---

🤖 Generated with Claude Code

https://claude.ai/code/session_017FzrA1G4U89KEMf7wfLmqq

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 9, 2026 12:48pm UTC

[zhuangjianguo]

维护者速读（终稿 · 席位复核后）

repo:hotcrm 席 · session_017FzrA1G4U89KEMf7wfLmqq · R58 · 2026-09-09T12:5xZ。本条取代 PR 正文里 dev 的草稿；席位已对着实际 diff 与 6/6 门禁读数逐条核过。

改了什么 —— AGENTS.md §How a green PR lands 加一段话，说明挂自动合并不等于合并，它是入队：本仓 main 规则集带一个合并队列，真正执行 squash 合并的是队列。另外在该节的出处引用块后面补了一句斜体，记下 PR #1798 当初为什么漏掉了队列。

⭐ 原有句子一个字都没动。 唯一对既有文本的改动是那句追加的斜体。

为什么改 —— 这一节是每个 agent 席位决定「怎么落地一个 PR」时读的那段话，而它描述的机制是错的。⚠️ 更要紧的是它错得有来历：R57 用两个探针测出「本仓没有合并队列」，据此判定您在决策批次 #81 说的「合并队列仍是唯一入口」是从别的仓搬过来的错误事实，PR #1798 于是刻意不写队列。

那两个探针测的都不是「队列存不存在」 —— 一个测的是 workflow 会不会在队列里重跑，一个测的是「此刻有没有 PR 排在队里」（那种引用是瞬时的，静息状态下任何仓都是 0）。两个零都是真零，但都不构成证据。⇒ 您当初是对的，是席位用错测量推翻了您。这一段把它改回来，并在出处里写明原委。

风险与代价（含回滚） —— 极低。纯散文，src/ 零改动，产品行为零变化，不发布任何东西（changeset 空 frontmatter）。回滚 = revert 本 PR。落地手势本身没有任何变化：本轮六张 PR 全部正确落地，这只是一处描述缺陷，不是流程坏了。

席位意见 —— ⭐ 建议原样合并。有一处我特别要向您说明，因为它是推翻我自己的指示才对的：

我原本建议在文档里写上「队列有 5 分钟等待」（依据是规则集里的 min_entries_to_merge_wait_minutes: 5），并且用它去解释 PR #1795 那个一直没解释的「5 分 40 秒」。dev 实测后拒绝了我，它是对的：九张已合并 PR 从入队到合并全部是 17–20 秒；那个参数管的是「队列攒一组等多久」，而 min_entries_to_merge 是 1，第一个进来就已满足下限，它根本不会生效。#1795 的 5 分 40 秒拆开是：5 分 18 秒在 draft 状态等自己的检查、5 秒翻 ready 到入队、17 秒在队列里。

⇒ 我差点把一个本仓行为九次否认的数字写进治理文档。现在正文改成警告后来者不要从规则集反推那个五分钟——因为那正是这张卡诞生的原因。

⚠️ 这也是我这一轮的教训：改正一个错误测量，不等于可以信任同一屏幕上的下一个数字。

你要做的 —— 本 PR 碰 AGENTS.md，是治理面 ⇒ 保持 draft、不入队、不挂自动合并、由您手工合并。席位已向 os-zhuang 与 hotlong 请审，⛔ 席位不批准、不合并任何治理面 PR。

⇒ 您只需要一个动作：合并它。 没有需要您先裁的分叉。

---

Generated by Claude Code