Repository navigation
合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 #4986
Description
Activity
Triage:
needs-user-decision, type Bug (declared ≠ enforced — the repo's stated merge-gate model measurably never ran: zeromerge_groupbuilds repo-wide against 4342pull_requestruns). This is the objectui twin of objectstack#9283, which the maintainer ruled today (Option A, verbatim 「9283 我加上了CI」 — the full-suiteCIworkflow 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.ymlas 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
mainrode 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 andcontent/docs/guide/ci-cd-pipeline.mdmust 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
- 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
PM 分诊 →
needs-user-decision(objectui 分片 PM,sessionsession_01GTRjn8xBqp75dk7kFupVRt)。本卡两个决定都只有维护者能做,agent 无路径亲手落地,故入决策箱而不入派发队列:
- 设置面(先):分支保护必需集实测不含 4 个 test shard / Type Check / Lint / Build & E2E / Build Docs;且 merge queue 从未产生过一次
merge_group构建(repo-wide 0,对照pull_request4342)—— ⛔ 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
- 设置面(先):分支保护必需集实测不含 4 个 test shard / Type Check / Lint / Build & E2E / Build Docs;且 merge queue 从未产生过一次
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 observedmerge_groupworkflow run in this repo (re-check:GET /actions/runs?event=merge_grouptotal_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_grouprepo-widetotal_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:objectuiexecution seat, sessionsession_01RV6yuVCxymHYE16PL9vQkE. Evidence only — ⛔ I have not touched the labels, the hold, or the assignee. This card ispm: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.ymlruns,event=merge_group0 (unchanged) same, with no statusfilter0 counter-probe — event=pushthrough the same method30 runs returned, newest today counter-probe — a known PR run's eventfield"pull_request"(run32354059728)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.ymlonorigin/maindoes carrymerge_group: types: [checks_requested]. GitHub only dispatcheschecks_requestedwhen 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--autoon 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:uiexecution seat (sessionsession_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_groupreturnstotal_count: 0— forci.yml, and again with no workflow filter, i.e. repo-wide. Control: the identical call withevent=pushonci.ymlreturnstotal_count: 3944, so the event filter is functional and the zero is a real reading, not a broken query.main'sci.ymldoes carry the subscription —merge_group: types: [checks_requested], lines 50–51, verified againstorigin/mainrather 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.enqueuedwebhooks; merge times are each PR's ownmerged_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 Check5m49s on #5669 and 8m25s on #5672; the fourTest (shard N/4)jobs 9m50s–10m22s;Lint4m–5m18s.A queue build that actually ran
ci.ymlcannot 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 Docshas been red onmainsince 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 apull_requestevent it only builds the site when the diff touchesapps/site/orcontent/, 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=trueearly on any non-pull_requestevent, 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.completedas "green", or trusting a suite rollup while named jobs are stillin_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:uiseat: 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_groupvalidating 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 = 19success+ 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+ 3skippedSet 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_stateanswers "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 CheckandLint).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-reportmarker 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_groupstill 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, andALLDONEon a partial set is byte-identical toALLDONEon 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
0on 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_counthas 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 readunstablethroughout, 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.completedwebhooks are worse than useless here as a green signal — on QualifyADR-0057 D10as the framework's numbering at seven live citation sites #5699 every suite reportedsuccesswhile two shards were stillin_progress, and one of those shards later failed.
Generated by Claude Code
- The run set is complete —
Triage:
domain:devx(lane only —pm:on-holduntouched). Landing:.github/workflows/**plus the branch-protection required-check set — the merge queue that has never produced amerge_groupbuild.⚠️ 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-holdand assignee untouched. From thedomain: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_groupbuild (repo-wide 0)". PR #5751 gives a dated instance of what that looks like end to end:event timestamp (webhook) pull_request.ready_for_review2026-08-23T04:49:52Z pull_request.enqueued2026-08-23T04:49:59Z pull_request.closed(outcome: merged)2026-08-23T04:50:17Z PR merged_at2026-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.enqueuedevent 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 forType Check. Whatever the queue did in those 16 seconds, it was not running the shards,Type CheckorLint— 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 amerge_groupcheck 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.completedsignal 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 CheckandLint. 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 literalTest (coverage shard ${{ matrix.shard }}/4)placeholder) deliberately excluded so no required check can fail to report onmerge_groupand hang the queue. The full list and the job-levelif: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_queueon its timeline, and repo-wideGET .../actions/runs?event=merge_groupgoes 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
- A PR merged via the queue after the config shows
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_groupworkflow 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…, head82193624612125cd…: all 8 workflowscompleted/success(CI included — so every one of the 9 required job names reported), andorigin/mainthen 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
- Repo-wide
Filed unassigned while implementing #4973（PR 见该 issue）。不由那个 PR 修:#4973 的修形是让
dependabot-auto-merge.yml自己等门,属仓内代码面;本条是仓库设置面 + AGENTS.md 指引面,两者都不该在热修里替维护者决定。实测事实(全部来自 API,已标明哪一条是推断)
1.
merge_group构建数:repo-widetotal_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。但订阅之后一次队列构建都没有发生过:ci.ymlruns,event=merge_groupevent=merge_groupci.ymlruns,event=pull_request最后一行是对照:同一个过滤器在
pull_request上返回 4342,所以 0 不是查询写错。2. 必需集实测不含最慢那批检查
#4959 于
2026-08-17T08:13:36Z被github-actions[bot]合入main(merged_by字段)。该 head SHA(31745d8b)共 19 条 check run,合并那一刻仍有 9 条在飞行:--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 号):这段话把「绝不
--auto」的禁令反转了,而反转所依赖的那个保护(队列重建 + 必需集)按上面的实测并不在运行。于是: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 那条通道仍然开着,而且是照文档开的。
交维护者的两个决定(未替你做)
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 步。--auto」(即 dependabot-auto-merge 用gh pr merge --auto,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地 #4973 给 dependabot 装的那种显式等待,只是由人执行)。这一条改的是所有 agent 的合并纪律,不适合由某个任务 PR 顺手改。两个决定的取舍方向不同,但第 2 条的正确性完全依赖第 1 条的结果,所以放在同一张卡里,不拆。
复现
同族前情:#3523(队列必需集为空,当日兑现三例)、#3243(405 与 §9 冲突)、#4973(dependabot 通道)。