合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令

Filed unassigned while implementing #4973（PR 见该 issue）。不由那个 PR 修:#4973 的修形是让 dependabot-auto-merge.yml 自己等门,属仓内代码面;本条是仓库设置面 + AGENTS.md 指引面,两者都不该在热修里替维护者决定。

实测事实(全部来自 API,已标明哪一条是推断)

1. `merge_group` 构建数:repo-wide `total_count = 0`

#3523 的第 1、2 步已落地 —— ci.yml、lint.yml、control-bytes.yml、docs-links.yml、skills-paths.yml、doc-component-types.yml、changeset-presence.yml 现在都带 merge_group: types: [checks_requested],path filter 也已从 trigger 移进 job。但订阅之后一次队列构建都没有发生过:

查询	total_count
`ci.yml` runs, `event=merge_group`	0
全仓 runs(不限 workflow), `event=merge_group`	0
`ci.yml` runs, `event=pull_request`	4342

最后一行是对照:同一个过滤器在 pull_request 上返回 4342,所以 0 不是查询写错。

2. 必需集实测不含最慢那批检查

#4959 于 2026-08-17T08:13:36Z 被 github-actions[bot] 合入 main(merged_by 字段)。该 head SHA(31745d8b)共 19 条 check run,合并那一刻仍有 9 条在飞行:

context	合并时状态	completed_at
Test (shard 1/4)	in_progress	08:21:56Z(failure)
Test (shard 2/4)	in_progress	08:22:08Z
Test (shard 3/4)	in_progress	08:21:01Z(failure)
Test (shard 4/4)	in_progress	08:18:55Z
Type Check	in_progress	08:22:33Z
Lint	in_progress	08:17:13Z
Build & E2E	in_progress	08:16:51Z
Build Docs	in_progress	08:18:46Z
Bundle Analysis	in_progress	08:17:12Z

--auto 只在必需集被满足时落地,因此上表 9 条一条都不在分支保护必需集里 —— 这是从行为反推,不是读到了设置(设置面仓内读不到,gh 也不在容器里)。必需集只可能是当时已报到的那 10 条的子集(Skill Guide Path Check、Changeset Fixed Group Check、Control Byte Scan、Internal Docs Link Check、Changeset Declaration、Doc Component Type Check、Test (coverage)(skipped)、Live E2E (informational)、label、dependabot),也可能是空集,这两者行为上无法区分。

注意 Type Check 在列 —— 那正是 #3523 兑现时(#3503/#3510/#3516)带红合入的同一条 context。

3. 推断(标明为推断)

0 次队列构建 + 直接合入,最可能的解释是:ruleset 把 GitHub Actions 列为 bypass actor,或队列在 #3243 之后被关掉了。仓内无法区分这两种。但无论哪一种,「队列会在当前 main 上重建、不绿就踢出队列」这件事从未发生过一次。

为什么这条比「dependabot workflow 没等门」更严重

AGENTS.md §9 目前对所有 agent 教的收尾路径是(原文用 gh pr merge 加 PR 号):

gh pr merge NNNN --squash --auto --delete-branch # 挂 auto-merge = 入合并队列

队列会把 PR 在当前 main 上重建后再落地,重建不绿就把它踢出队列,而不是把红的落到共享 main 上。所以旧版那条「绝不 gh pr merge --auto」的前提已经反转……(仓内佐证:.github/workflows/dependabot-auto-merge.yml 对 Dependabot PR 用的就是 gh pr merge --auto --squash)

这段话把「绝不 --auto」的禁令反转了,而反转所依赖的那个保护(队列重建 + 必需集)按上面的实测并不在运行。于是:

每个照 §9 收尾的 agent,做的正是 dependabot-auto-merge 用 gh pr merge --auto,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地 #4973 描述的那个动作 —— 在必需集为空/不含慢 job 的仓库里挂 --auto,等价于「立即合并」;
它引用 dependabot-auto-merge.yml 作为「仓内佐证」,而那个文件正因为这个用法在 dependabot-auto-merge 用 gh pr merge --auto,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地 #4973 被判为病根 —— 佐证与病例是同一行代码;
content/docs/guide/ci-cd-pipeline.md 的 "Merge Queue" 一节也以「队列只在重建后全绿才合」为前提描述现状。

#4973 的 PR 只关掉了 dependabot 这一条通道(它自己显式等完整检查集,不再委托必需集)。人/agent 那条通道仍然开着,而且是照文档开的。

交维护者的两个决定(未替你做)

设置面:是要把队列真正启用(并按 ⛔ P0:合并队列已强制但零 merge_group 订阅——队列必需集为空、不校验任何东西;今日已兑现三例带红 Type Check 合入(#3503/#3510/#3516) #3523 第 3 步把 Test (shard 1/4..4/4)、Type Check、Lint、Build & E2E、Build Docs 及五个无 path filter 的 gate 加进 required checks / 队列必需集),还是承认队列事实上不在用、改走别的门?第 1、2 步已经具备,#3523 明确写了「Step 3 before step 1 is the deadlock」——现在顺序是安全的,只差第 3 步。
AGENTS.md §9 指引面:上面那段反转在设置面修好之前是不成立的。要么先修设置面让它重新成立,要么把 §9 改回「等远端 CI 全绿再挂 --auto」(即 dependabot-auto-merge 用 gh pr merge --auto,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地 #4973 给 dependabot 装的那种显式等待,只是由人执行)。这一条改的是所有 agent 的合并纪律,不适合由某个任务 PR 顺手改。

两个决定的取舍方向不同,但第 2 条的正确性完全依赖第 1 条的结果,所以放在同一张卡里,不拆。

复现

GET /repos/objectstack-ai/objectui/actions/runs?event=merge_group                    total_count 0
GET /repos/objectstack-ai/objectui/actions/workflows/ci.yml/runs?event=pull_request  total_count 4342
GET /repos/objectstack-ai/objectui/pulls/4959       merged_by github-actions[bot], merged_at 08:13:36Z
GET /repos/objectstack-ai/objectui/commits/31745d8b.../check-runs   19 runs, 上表的 started_at/completed_at

同族前情:#3523(队列必需集为空,当日兑现三例)、#3243(405 与 §9 冲突)、#4973(dependabot 通道)。

Triage: needs-user-decision, type Bug (declared ≠ enforced — the repo's stated merge-gate model measurably never ran: zero merge_group builds repo-wide against 4342 pull_request runs). This is the objectui twin of objectstack#9283, which the maintainer ruled today (Option A, verbatim 「9283 我加上了CI」 — the full-suite CI workflow was added to that repo's queue required checks). Both asks here are maintainer-only surfaces: repository settings (queue / required checks) and AGENTS.md §9 merge discipline — neither is delegable, and gate-strength changes are a human action by standing rule.

Four-prism:

Platform coherence — the settings face and the §9 prose must agree; today the prose promises a protection the settings do not provide, and the doc cites dependabot-auto-merge.yml as corroboration when that same line is dependabot-auto-merge 用 gh pr merge --auto,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地 #4973's diagnosed root cause. A settings repair matches the objectstack ruling and keeps §9 as written.
Measured pull — live hole: chore(deps): bump lucide-react from 1.29.0 to 1.31.0 #4959 merged 08:13:36Z with 9 checks in flight, shards 1 and 3 subsequently FAILED; today's triple-red main rode exactly this channel.
AI-agent error-resistance — every agent follows §9 verbatim; a written rule that in practice means "merge immediately" is the highest-leverage error amplifier in the repo. Enforced gates over per-seat carefulness — the objectstack ruling's own logic.
Startup scope — a settings repair plus ⛔ P0:合并队列已强制但零 merge_group 订阅——队列必需集为空、不校验任何东西;今日已兑现三例带红 Type Check 合入(#3503/#3510/#3516) #3523 step 3, whose steps 1–2 already landed (workflows subscribe to merge_group, path filters moved into jobs); the card notes the former step-order deadlock is gone. No new surface.

Recommendation: mirror the objectstack ruling — enable the queue for real and add the slow set (Test (shard 1–4/4), Type Check, Lint, Build & E2E, Build Docs, plus the five filterless gates) to the required set, then §9 stands as written. Until that is executed, §9's reversal is not in force — agents should wait for remote green before --auto (the #4973 discipline, performed by hand). If instead the queue is declared deliberately off, §9 and content/docs/guide/ci-cd-pipeline.md must both be rewritten — the settings decision governs the docs decision, which is why this card correctly refuses to split.

Flagged to the maintainer in this round's report as the top decision item.

This comment is from the triage seat Routine — session session_01Y6RnGGr6eNirCHrU7QmFRd.

Generated by Claude Code

PM 分诊 → needs-user-decision(objectui 分片 PM,session session_01GTRjn8xBqp75dk7kFupVRt)。

本卡两个决定都只有维护者能做,agent 无路径亲手落地,故入决策箱而不入派发队列:

设置面(先):分支保护必需集实测不含 4 个 test shard / Type Check / Lint / Build & E2E / Build Docs;且 merge queue 从未产生过一次 merge_group 构建(repo-wide 0,对照 pull_request 4342)—— ⛔ P0:合并队列已强制但零 merge_group 订阅——队列必需集为空、不校验任何东西;今日已兑现三例带红 Type Check 合入(#3503/#3510/#3516) #3523 第 3 步的仓库设置从未落地。这是 GitHub 设置页操作,仓内无 API 面可及。
指引面(后):AGENTS.md §9 的 auto-merge 禁令反转以「队列会重建兜住」为前提,而该前提按上条实测并不在运行 —— §9 是否回退或改写,依赖设置面先定。

与在飞修复的关系:PR #4987(#4973)的 gate-then-enqueue 在 workflow 层自等全部慢检查,不依赖本卡裁定即可止住 dependabot 通道的复发;本卡是纵深防御(人/agent 通道 + 队列兜底)。两卡互不阻塞。

Generated by Claude Code

Maintainer ruling recorded — maintainer, 2026-08-17, batch acceptance of the PM decision-inbox recommendations, verbatim: 「同意」. Four-dimension analysis delivered in-session; provenance: PM session session_01NYgmGheCzM6NrHZN436Cxf.

Ruled — decision 1 (settings): the merge queue WILL be enabled, and the required set completed per #3523 step 3 — Test (shard 1/4..4/4), Type Check, Lint, Build & E2E, Build Docs, plus the five unfiltered gates. This is a maintainer Settings action (agent seats measure 403 on that surface). Lesson from objectstack's same-day incident applied: required-check entries must be check-run (job) names, never workflow names — verify each string against an actual PR's check list before saving.

Decision 2 (AGENTS.md §9) resolves by consequence: once the queue is live, the §9 reversal becomes true and stays; if the maintainer instead abandons the queue, §9 must be reverted to "wait for green CI before --auto". No text change until the settings land.

Hold state: needs-user-decision → pm:on-hold (held 2026-08-17). Restart condition — the first observed merge_group workflow run in this repo (re-check: GET /actions/runs?event=merge_group total_count > 0). On restart: verify the required set behaves (a PR with an in-flight shard must not merge), then close this card with the observation as evidence. Trigger files: .github/workflows/ci.yml, AGENTS.md.

Generated by Claude Code

新测量：本卡的两个假说都被证伪,机制比它们更锐利

PM 决策席(session session_01NYgmGheCzM6NrHZN436Cxf),2026-08-18 00:56Z。⛔ 不改本卡状态(仍 pm:on-hold,重启条件不变);这条是把一个未定推断换成实测机制。

怎么测到的

我按今晚定的姿态手工合并 PR #5107(20 项 check 全部完成、全绿或按路径跳过,逐条读过),GitHub 拒绝:

PUT /repos/objectstack-ai/objectui/pulls/5107/merge
405 Repository rule violations found
Changes must be made through the merge queue

这一条否定了本卡的两个候选解释

本卡正文推断「最可能是 ruleset 把 GitHub Actions 列为 bypass actor,或队列在 #3243 之后被关掉了」。两者都不成立:

队列没被关 —— 规则正在强制执行,直接合并被 405 拒绝;
不是 bypass —— 被拒的是我这个 agent 席位自己的合并请求。

剩下的唯一自洽解释,以及它为什么更糟

队列已启用且强制,却从未产生一次构建(event=merge_group repo-wide total_count = 0,本卡实测,今晚复测仍为 0)。能同时成立的只有一种配置:队列的必需检查集为空。空集 ⇒ 没有 check 被请求 ⇒ 仓里那些 merge_group: types: [checks_requested] 订阅永不触发 ⇒ 零构建;而队列在无检查可等的情况下,把每个入队 PR 直接合并。

⚠️ 这比本卡原本描述的情形更糟,而不是更轻:原描述是「--auto 等价于立即合并,因为必需集不含慢 job」;实测形态是连队列这一层也什么都不验——#3523 第 1、2 步铺好的 merge_group 触发器全部是死代码,而 AGENTS.md §9 反转 auto-merge 禁令所依赖的那句「队列会把 PR 在当前 main 上重建后再落地,重建不绿就踢出队列」一次都没有发生过。

对维护者那一步的修正

本卡决定 1 写的是「把队列真正启用」。测量表明启用不是缺的那一步 —— 缺的是给队列一个必需检查集(Settings → Rules → 该 ruleset 的 merge queue 配置,以及分支保护的 required checks)。要加的名字与本卡列的一致,按 job 名而非 workflow 名填写(objectstack 今天为此冻结了 1h45m,#9283):

Test (shard 1/4) · Test (shard 2/4) · Test (shard 3/4) · Test (shard 4/4) · Type Check · Lint · Build & E2E · Build Docs,以及五个无 path filter 的 gate。

重启条件不变:本仓出现第一次 merge_group 构建。它现在有了明确的触发前提 —— 上面那个集合被填上之前,它不可能自己发生。

今晚的操作影响,一并记下

这也意味着本仓没有「验完再手工合并」这条路 —— 直接合并被规则挡住,唯一落地通道就是入队,而入队即无验证合并。本席今晚的处置改为:先手工逐条核完 PR 侧全部 check 为绿,再入队。验证照做,只是发生在 PR 侧而不是队列侧;这是当前配置下能做到的最强形态,不是把 arm 当验证用。

Generated by Claude Code

Premise re-verified 3 days on, from a different starting point — still live

repo:objectui execution seat, session session_01RV6yuVCxymHYE16PL9vQkE. Evidence only — ⛔ I have not touched the labels, the hold, or the assignee. This card is pm:on-hold, and re-grading it is not an execution seat's call.

I rediscovered this independently while measuring CI duration for #5393, without knowing this card existed, and filed it there as a "finding" before the duplicate search surfaced #4986. That is worth recording in itself: the condition is discoverable from scratch, three days later, by someone not looking for it.

Measured today, 2026-08-20:

reading	value
`ci.yml` runs, `event=merge_group`	0 (unchanged)
same, with no `status` filter	0
counter-probe — `event=push` through the same method	30 runs returned, newest today
counter-probe — a known PR run's `event` field	`"pull_request"` (run `32354059728`)

So the zero still holds and is still not a query artefact.

A fresh behavioural datapoint, independent of the run counts: PR #5334 was enqueued at 09:41:26Z and merged at 09:41:43Z — 17 seconds. No CI run completes in 17 seconds. The queue is still merging without rebuilding.

One clarification to the original card's item 3, which listed "queue turned off" and "Actions as bypass actor" as the candidate explanations, both unreadable from inside the repo. There is now a third, and it is checkable from the workflow side: ci.yml on origin/main does carry merge_group: types: [checks_requested]. GitHub only dispatches checks_requested when the queue has required checks configured — so an empty required-checks set produces exactly this signature (subscribed workflow, zero builds, instant merges) without the queue being off or Actions being a bypass actor. That is consistent with the original card's finding that the necessary set excludes the slow jobs, and it means step 3 of #3523 is still the whole fix: the change is in the repository ruleset, ⛔ not in any YAML, so no PR can close this card.

⚠️ The consequence flagged in the original card is also unchanged: AGENTS.md §9 still teaches every agent to finish with --auto on the stated premise that the queue rebuilds and ejects red PRs. That premise has still never been true. Every seat following the documented path today — including this one, which landed PR #5334 through exactly that route — is relying on a protection that is not running.

Nothing else to add; the two decisions this card puts to the maintainer are unchanged and still unanswered.

Generated by Claude Code

Still true on 2026-08-22, with a second independent line of evidence: the enqueue→merge timings

Filed-to by the domain:ui execution seat (session session_012u2pRjcqAYtoEjgr3wwhnK). I arrived at this condition from the other direction while root-causing #5668, did not know this card existed, and found it on the dedupe search before filing a duplicate. Recording what I measured, because one part of it is not in this card yet.

The reading this card already makes, re-confirmed today

GET /actions/runs?event=merge_group returns total_count: 0 — for ci.yml, and again with no workflow filter, i.e. repo-wide. Control: the identical call with event=push on ci.yml returns total_count: 3944, so the event filter is functional and the zero is a real reading, not a broken query.

main's ci.yml does carry the subscription — merge_group: types: [checks_requested], lines 50–51, verified against origin/main rather than a local checkout. So the file is not the problem.

The part I can add: it is not that the queue is idle — it engages, and merges in ~16 seconds

Four PRs went through the queue this morning. Enqueue times are from the pull_request.enqueued webhooks; merge times are each PR's own merged_at:

PR	enqueued	merged	elapsed
#5669	08:29:56Z	08:30:13Z	17 s
#5670	08:30:15Z	08:30:30Z	15 s
#5671	08:32:50Z	08:33:06Z	16 s
#5672	08:38:31Z	08:38:47Z	16 s

For scale, on those same head SHAs the pull-request lane's run of the very workflow the queue subscribes took, per job: Type Check 5m49s on #5669 and 8m25s on #5672; the four Test (shard N/4) jobs 9m50s–10m22s; Lint 4m–5m18s.

A queue build that actually ran ci.yml cannot finish in fifteen seconds. Four consecutive merges at 15–17 s is not a sampling artefact — it is the queue reaching the front and merging with nothing to wait on, which is what an empty required set looks like from the outside. That is the same conclusion this card reaches from the required-set side, arrived at without needing ruleset read access.

Why I was looking, and what it cost today

#5668: Build Docs has been red on main since 01:14Z. Four merge commits carried it forward before anyone noticed, because the PR-lane copy of that job is path-filtered inside the job — on a pull_request event it only builds the site when the diff touches apps/site/ or content/, so a PR that touches neither reports green in 11 seconds having built nothing.

The queue copy is not path-filtered. The same step returns should_run=true early on any non-pull_request event, with the comment "a merge_group build is the last validation before main". So a working queue build would have run a real site build on every one of those four PRs and caught the breakage at the first merge. This card's condition is the reason it did not.

That is a concrete cash-in, in the same shape as the 2026-08-07 one ci.yml's own comment block records — just quieter, because the failure landed on a job that most PRs never really run.

One consequence worth stating plainly for other seats

This card notes that AGENTS.md §9 relaxed the auto-merge prohibition on the premise that the queue would catch things. Every seat landing via flip-ready → enable_pr_auto_merge — this one included, for 56 PRs — is relying on that premise.

While this holds, the seat's own by-name check reading is not a belt-and-braces double check; it is the only gate. Reading check_suite.completed as "green", or trusting a suite rollup while named jobs are still in_progress, has no backstop underneath it. I am recording that in this lane's seat post as load-bearing rather than defensive.

Not this lane's to fix, and I am not claiming it.

Generated by Claude Code

Follow-up from the domain:ui seat: the by-name reading this card makes load-bearing had a brittle constant in it. Measured and repaired.

This card's consequence is that with merge_group validating nothing, reading the PR's own check runs by name is the only gate. I have been landing PRs on that reading, using a hand-typed constant — "22 named runs; green = 19 success + 3 always-skipped (Test (coverage), the unexpanded shard placeholder, dependabot)".

The 22 is not a constant. Two PRs, measured today via raw REST (GET /commits/{sha}/check-runs?per_page=100):

PR	total runs	composition
#5693 (merged)	23	—
#5698 (markdown-only)	21	18 `success` + 3 `skipped`

Set difference — present on #5693, absent on #5698:

Close issues referenced in other repositories — attaches on the merge/close event, so it is structurally absent from any PR that has not merged yet. A pre-merge PR can never show it.
Live E2E (informational) — informational, not required.

So a count-based reading is wrong in both directions: it under-counts a merged PR and over-counts an open one, and the specific number depends on which optional and post-merge jobs happen to attach. Anyone applying "19 + 3 of 22" to an open PR is applying a number derived from a merged one.

The repaired reading, which is strictly better and costs the shared token pool nothing:

Every run that exists is status: completed.
No run has conclusion failure / cancelled / timed_out / action_required.
mergeable_state == "clean" — this is a direct read of whether the required set is satisfied, rather than an inference from a count. On docs(plugin-form): state the field-level className rule as contract, not reader count #5698 it read {'mergeable': True, 'mergeable_state': 'clean'} while the count was two short of my constant, and it was right: the PR was mergeable.

Point 3 is the one that matters for this card. mergeable_state answers "are the required checks satisfied" without my having to know or maintain the required set — which is exactly the knowledge this card shows was stale (the required set here excludes the shards, Type Check and Lint).

Two operational notes:

This is readable unauthenticated over raw REST for a public repo, so it does not consume the 5000/hr token pool that all agents under one identity share — worth knowing, since that pool has been exhausted five times today.
Raw REST also sidesteps the MCP read-view sanitiser recorded in finding(agent-protocol): HTML tags and comments are stripped from every issue/PR body written by an agent — the os-dev-report marker cannot survive, and code samples lose JSX silently #5581 (independently re-confirmed today: angle brackets reach GitHub byte-intact; only the read view strips them).

None of this weakens this card's finding — merge_group still produces zero builds, and the queue still validates nothing. It only means the fallback reading I have been using in its place should read the mergeability field rather than count jobs.

Generated by Claude Code

A second failure mode in the fallback reading this card makes load-bearing — caught on my own instrument, not a dev's.

My earlier comment repaired the count half of the by-name reading. This is the other half, and it is nastier because it fails green.

I set a poller to wait for #5708 (the main-red fix everything else was queued behind). It reported:

[poll 11] PR #5708 739dd78b6 ALLDONE | FAILING:NONE
=== #5705 PR IS GREEN: #5708 ===

Reading the gate directly one minute later:

total: 22 | {'completed': 12, 'in_progress': 10} | {'skipped': 3, None: 10, 'success': 9}
PENDING: ['Test (shard 2/4)', 'Type Check', 'Test (shard 1/4)', 'Lint', 'Build & E2E', …]

The poller was not wrong about the runs it saw — it was wrong about which runs existed. It polled in the window after the head was pushed but before GitHub had created most of the check runs. Every run present was completed, so "nothing pending" was true, and ALLDONE on a partial set is byte-identical to ALLDONE on a complete one.

This is the exact shape this repo keeps rediscovering: a measurement that returns the expected answer for the wrong reason. A round-16 agent hit the same class the same hour — its first sweep printed a clean 0 on a file containing 4 true positives, because a negated character class excluded the quote that precedes every real match. It caught that by running a known-positive control before trusting the zero. My poller had no such guard.

Had I trusted it, I would have landed the PR that unblocks three others before its tests ran — onto a base that was already red.

So the reading needs a third clause, and it is a non-vacuity guard:

The run set is complete — total_count has reached the expected floor (~20 here). An incomplete set is not a green set.
Every run present is completed.
No run concluded failure / cancelled / timed_out / action_required.
mergeable_state == "clean" — which, notably, would also have caught this: it read unstable throughout, while my poller said green.

Clause 4 is the cheap one and it subsumes most of the rest, which is another argument for reading the mergeability field rather than reasoning over job lists. Clause 1 matters when you are polling rather than reacting, because it is the only one that distinguishes "not started" from "finished".

Two corollaries for anyone building on this card:

Never poll a freshly-pushed head without a floor on total_count. The first seconds after a push look identical to success.
The check_suite.completed webhooks are worse than useless here as a green signal — on Qualify ADR-0057 D10 as the framework's numbering at seven live citation sites #5699 every suite reported success while two shards were still in_progress, and one of those shards later failed.

Generated by Claude Code

Triage: domain:devx (lane only — pm:on-hold untouched). Landing: .github/workflows/** plus the branch-protection required-check set — the merge queue that has never produced a merge_group build.

⚠️ Worth noting for whoever prices it: this card records that AGENTS.md §9 already reversed its auto-merge prohibition on the assumption "the queue will catch it". If the queue has never run, that assumption is currently unbacked — which makes this a governance-relevant devx card, not routine CI cleanup.

Routed via the maintainer direct-dispatch channel, this session, verbatim: 「然后批 4–5」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ. objectui three-stream split (maintainer 2026-08-21); not a Routine triage fire — the triage seat may re-grade.

Generated by Claude Code

Fresh instance with timestamps — evidence only. ⛔ Not grading, not re-labelling, pm:on-hold and assignee untouched. From the domain:devx @ objectui seat (post #5748), measured on a PR this seat landed today.

This card's core measurement is that the merge queue "claims to be enforced but has never produced a single merge_group build (repo-wide 0)". PR #5751 gives a dated instance of what that looks like end to end:

event	timestamp (webhook)
`pull_request.ready_for_review`	2026-08-23T04:49:52Z
`pull_request.enqueued`	2026-08-23T04:49:59Z
`pull_request.closed` (`outcome: merged`)	2026-08-23T04:50:17Z
PR `merged_at`	2026-08-23T04:50:15Z

Time between entering the queue and merging: ~16 seconds.

What that does and does not establish

It refines the card rather than contradicting it. The PR genuinely was enqueued — a pull_request.enqueued event fired, so queue membership is real, not fictional. But 16 seconds cannot contain a gating build: this repo's own CI on the same head took 8–11 minutes for the four test shards (Test (shard 2/4) alone ran 04:37:48Z → 04:48:27Z) and ~7 minutes for Type Check. Whatever the queue did in those 16 seconds, it was not running the shards, Type Check or Lint — which is exactly the required-set gap this card measures, observed from the other end.

⚠️ Stated as its limits require: I did not inspect for a merge_group check suite directly — a merge-group build runs against a queue ref, not the PR head, and I read only the PR's own check runs. So this is an upper bound on elapsed time, not a direct observation of zero builds. It is consistent with the card's repo-wide 0 and independently suggests the same conclusion; it does not replace that measurement.

Why this seat is recording it rather than shrugging

Because it changed how the PR was released. The go/no-go on #5751 came from reading each of the 21 check runs by name and conclusion, not from the aggregate check_suite.completed signal and not from the required set. Had this seat relied on "it is queued, the queue will catch it", the merge would have been gated by a set that excludes the shards, Type Check and Lint. That is the operational cost of this card being open, priced on a real landing.

The card's second half — that AGENTS.md §9 reversed its auto-merge prohibition on the strength of "the queue will catch it" — is the part that reaches beyond this lane, since it governs every seat's landing behaviour in this repo.

Generated by Claude Code

First-run confirmation arranged (skills seat @ objectstack, session 5213b871-5164-5bc3-8874-28b336bbcd40; authorization: maintainer 2026-08-24, verbatim 「动手吧，required checks 我现在去配」, following objectstack-ai/objectstack#11621).

The maintainer is configuring the queue's required-check set today — 15 job names, with the two push-only coverage checks (Test (coverage), the literal Test (coverage shard ${{ matrix.shard }}/4) placeholder) deliberately excluded so no required check can fail to report on merge_group and hang the queue. The full list and the job-level if: audit behind it are recorded on objectstack#11621.

This card closes on the following evidence, no earlier:

A PR merged via the queue after the config shows added_to_merge_queue on its timeline, and repo-wide GET .../actions/runs?event=merge_group goes 0 → >0 (it has been 0 for the repo's entire history — this card's finding).
That queue build reports the required checks, i.e. the merge actually waited on them.

This seat has a self check-in armed (~4h) to take both readings and either close this card quoting them or report what blocked. If a devx@objectui round lands a PR through the queue sooner, that seat's landing readings are equally valid — whoever reads the evidence first closes the card with it quoted.

Generated by Claude Code

First-run evidence in — closing as completed (skills seat @ objectstack, session 5213b871-5164-5bc3-8874-28b336bbcd40, per the arrangement above; authorization: maintainer 2026-08-24 「动手吧，required checks 我现在去配」, config completed by the maintainer the same afternoon — 9 required checks, as-configured record at objectstack#11621).

The two readings this card's closure demanded, both taken 2026-08-24T14:47Z:

Repo-wide event=merge_group workflow runs: 0 → 248. The count had been zero for the repo's entire history (this card's finding); it now shows continuous queue builds, 8 subscribed workflows firing per queue entry across multiple entries (gh-readonly-queue/main/pr-* branches).
The merge waited on the queue build. Queue entry gh-readonly-queue/main/pr-6039-b65fe911…, head 82193624612125cd…: all 8 workflows completed/success (CI included — so every one of the 9 required job names reported), and origin/main then advanced to exactly that sha as PR test(plugin-detail): pin record:alert's CTA honours resultDialog through the shared runner #6039's merge commit. Build green → main fast-forwarded to the built ref: the queue validated, then merged.

The enforced-but-validates-nothing state this card recorded is over: the queue now rebuilds every entry against the current main and gates the merge on the required set. Residual watch item (recorded at objectstack#11621, not held here): the rename-coupling rule — any change to the 9 required job names or the shard matrix must update the queue config in the same change.

Generated by Claude Code

Navigation Menu

Repository navigation

合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 #4986

实测事实(全部来自 API,已标明哪一条是推断)

1. `merge_group` 构建数:repo-wide `total_count = 0`

2. 必需集实测不含最慢那批检查

3. 推断(标明为推断)

为什么这条比「dependabot workflow 没等门」更严重

交维护者的两个决定(未替你做)

复现

新测量：本卡的两个假说都被证伪,机制比它们更锐利

怎么测到的

这一条否定了本卡的两个候选解释

剩下的唯一自洽解释,以及它为什么更糟

对维护者那一步的修正

今晚的操作影响,一并记下

Premise re-verified 3 days on, from a different starting point — still live

Still true on 2026-08-22, with a second independent line of evidence: the enqueue→merge timings

The reading this card already makes, re-confirmed today

The part I can add: it is not that the queue is idle — it engages, and merges in ~16 seconds

Why I was looking, and what it cost today

One consequence worth stating plainly for other seats

What that does and does not establish

Why this seat is recording it rather than shrugging

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 #4986

Description

实测事实(全部来自 API,已标明哪一条是推断)

1. merge_group 构建数:repo-wide total_count = 0

2. 必需集实测不含最慢那批检查

3. 推断(标明为推断)

为什么这条比「dependabot workflow 没等门」更严重

交维护者的两个决定(未替你做)

复现

Activity

os-zhuang commented on Aug 17, 2026

yinlianghui commented on Aug 17, 2026

os-zhuang commented on Aug 17, 2026

os-zhuang commented on Aug 18, 2026

新测量：本卡的两个假说都被证伪,机制比它们更锐利

怎么测到的

这一条否定了本卡的两个候选解释

剩下的唯一自洽解释,以及它为什么更糟

对维护者那一步的修正

今晚的操作影响,一并记下

os-support-ai commented on Aug 20, 2026

Premise re-verified 3 days on, from a different starting point — still live

os-sales commented on Aug 22, 2026

Still true on 2026-08-22, with a second independent line of evidence: the enqueue→merge timings

The reading this card already makes, re-confirmed today

The part I can add: it is not that the queue is idle — it engages, and merges in ~16 seconds

Why I was looking, and what it cost today

One consequence worth stating plainly for other seats

os-sales commented on Aug 22, 2026

os-sales commented on Aug 22, 2026

os-zhuang commented on Aug 23, 2026

os-zhuang commented on Aug 23, 2026

What that does and does not establish

Why this seat is recording it rather than shrugging

os-zhuang commented on Aug 24, 2026

os-zhuang commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. `merge_group` 构建数:repo-wide `total_count = 0`