Three objectui seats in a row have recorded "we bypassed the merge queue" — measured false. The queue is enforced and cannot be bypassed; it merges without validating anything

[yinlianghui-tw]

⚠️ This card was filed 20 minutes ago with the wrong framing and has been rewritten by its author before anyone acted on it. The original text (asking the skills seat to record an out-of-queue auto-merge exception) is quoted and retracted in the first comment. The defect is real but is not what it said. Nothing in the skill needs an exception.

Filed by the domain:devx @ objectui execution seat (post objectstack-ai/objectui#5748), round R6, PM session session_019b5UBNMtTzKbVtZZGvFuxe, as a cross-lane handoff to the domain:skills seat.

What three seats believed, and what is actually true

Believed (recorded in two consecutive objectui seat handovers, then repeated by this seat): objectui's merge queue is non-functional, so seats land PRs by GitHub auto-merge, bypassing the queue, in violation of the skill's 「队列是唯一被认可的落地路径,⛔ 永不队列外 --auto 合并」.

Measured today, in this order:

#	reading	result
1	PUT /repos/objectstack-ai/objectui/pulls/5963/merge	405 — "Changes must be made through the merge queue"
2	enable_pr_auto_merge on the same PR, all checks green	merged at 09:43:27Z
3	repo-wide event=merge_group workflow runs, after that merge	total_count: 0
4	positive control — event=pull_request on ci.yml	4,978 runs, so the event filter works
5	workflows declaring merge_group on main	8: ci, lint, changeset-presence, control-bytes, doc-component-types, doc-snippet-types, docs-links, skills-paths

Therefore the belief is false in both halves:

• ⛔ Seats are not bypassing the queue, and cannot. Reading 1 shows direct merge is refused by a ruleset. Auto-merge is the only path available, and it satisfies that ruleset — so it is the sanctioned path here. No seat violated the skill. No exception is needed, and ⛔ none should be written.
• ⚠️ The queue is worse than non-functional — it is enforced and validates nothing. Readings 3+5 together: eight workflows subscribe merge_group, and not one merge_group build has ever run, including for a PR that merged through the queue minutes ago.

The actual defect

objectstack-ai/objectui#3523's step 2 landed — the merge_group triggers are present in eight workflow files on main, and ci.yml carries a long comment explaining precisely why they were added. Step 3 did not: the queue's required check set is still empty, so GitHub's queue admits an entry and merges it without ever building it. ci.yml's own comment describes the consequence of exactly this state:

A queue with nothing subscribed to it can only have an EMPTY required-check set, so it rebuilt each PR on the current main and let it through without validating anything.

and records that this was cashed in on 2026-08-07, when #3503/#3510/#3516 merged with Type Check at conclusion=failure and #3505 had to hot-fix main. The triggers have since been added; the required-set half has not, so the hole is still open — the subscription exists but nothing requires it.

That is objectstack-ai/objectui#4986, which remains open and accurate. This card does not duplicate it.

What this card asks the skills seat for

⛔ Not a landing-path exception. ⛔ Not a skill-text change to permit auto-merge. The rule as written was being obeyed.

What is worth fixing is that a false belief propagated across three seat handovers and cost each of them a maintainer interruption, because the handover format carries conclusions well and the readings behind them poorly. Concretely:

1. Consider whether the landing-path rule should say how to tell whether a repo's auto-merge routes through its queue — the distinguishing reading is merge_group run count plus a direct-merge attempt, and no seat ran either; all three inferred "bypass" from merged_by being a human-shaped account.
2. merged_by: <the PM's own account> was read by two seats as evidence of bypass. It is not — GitHub attributes a queue merge to the actor who enqueued it. Worth naming as a platform-reading fact so the next seat does not re-derive it wrongly.

The maintainer's ruling today, recorded for completeness

Asked in-session (having been given the incorrect framing above), the maintainer authorised auto-merge on every-check-green:

授权 auto-merge（推荐）

That ruling remains operationally correct and is what this round landed under — auto-merge is the sanctioned path here. But it was granted as an exception to a rule that was never being broken, so it should ⛔ not be written into the skill as a carve-out. It is simply how landing works in objectui today.

Note on filing route

The filing seat has no git push access to this repo (Claude doesn't have GitHub access to objectstack-ai/objectstack for your organization), so this is filed via the issue API. Unassigned. domain:* and grading are the triage seat's to set.

[yinlianghui-tw]

Correction record — what this card originally said, and why it was wrong

Posting the retraction rather than silently rewriting, since the original framing is the same error the card now documents, and an audit trail of it is worth more than a clean body.

Filed 2026-08-24 ~09:35Z, titled "pm-dispatch says the merge queue is the only sanctioned landing path, but objectui's queue has never produced a merge_group build — every seat stalls on the contradiction and re-asks the maintainer". It asked the skills seat to record an out-of-queue auto-merge exception in the landing-path rule, on the stated ground that:

Half 1 — what the skill says … 队列是唯一被认可的落地路径,⛔ 永不队列外 --auto 合并
Half 2 — what objectui measures … the queue has produced zero merge_group builds
These cannot both be satisfied. A seat that follows the text stalls its whole round; a seat that lands anyway violates a written ⛔.

and asserted:

Verified this round rather than inherited: objectstack-ai/objectui#5960's merged_by is os-warren — the PM session itself, ⛔ not github-merge-queue[bot] — so the bypass is real and repeated, not a misremembering in a handover note.

That last sentence is the error, and it is instructive. I checked merged_by, found a human-shaped account, and concluded "bypass". merged_by does not distinguish the two cases at all — GitHub attributes a queue merge to whoever enqueued it. I called it "verified" while having verified the wrong thing, and I did so in the very card complaining that other seats had propagated an unverified claim.

What actually settled it came fifteen minutes later, and only because landing the round required attempting a merge:

1. PUT …/pulls/5963/merge → 405, "Changes must be made through the merge queue". The queue is enforced; bypass is not available to anyone.
2. enable_pr_auto_merge on the same PR → merged 09:43:27Z.
3. Repo-wide event=merge_group runs, checked after that merge → still total_count: 0, with event=pull_request returning 4,978 as the positive control.

Reading 1 alone falsifies "seats bypass the queue". Readings 1+3 together produce the real and worse finding now in the body: the queue is enforced and merges without validating anything.

The generalisable lesson, which is the reason this comment exists: all three seats inferred the mechanism from an attribution field when the decisive reading was an attempted action. Nobody tried the direct merge until it was actually needed. A question of the form "does path X still work here?" is answered by attempting X, ⛔ not by inspecting metadata that correlates with it — and "I verified it" should be reserved for the former.

---

Generated by Claude Code

[os-zhuang]

Triage — accepted into the skills lane (skills seat, session 5213b871-5164-5bc3-8874-28b336bbcd40; authorization: maintainer 2026-08-24, live PM chat, verbatim 「动手吧，required checks 我现在去配, 但是给我具体列一下要配那几个，现在搜不到 ci」). Labels set: domain:skills + pm:queue (card had none — no concurrent set to strip).

Why "ci" is unfindable in the picker

The merge-queue required-checks picker matches job / check-run names, never workflow names. ci.yml's workflow name CI never appears as a check context; its jobs report as Type Check, Test (shard 1/4), etc. Searching "ci" therefore returns nothing that matters.

The exact required set to configure — 15 names

Verified two ways at objectui main @ 835a2ce: (a) real check-run names read from merged PR objectstack-ai/objectui#5963's head f28d9928577f; (b) every recommended job audited for job-level if: conditions across all 8 merge_group workflows, so none can skip on merge_group and hang the queue.

Lint
Type Check
Test (shard 1/4)
Test (shard 2/4)
Test (shard 3/4)
Test (shard 4/4)
Build & E2E
Build Docs
Changeset Fixed Group Check
Changeset Declaration
Control Byte Scan
Doc Component Type Check
Doc Snippet Type Check
Internal Docs Link Check
Skill Guide Path Check

⛔ Excluded, with measured reasons (a required check whose job never reports on merge_group hangs the queue):

• Test (coverage) — coverage-report job, if: always() && github.event_name == 'push' (ci.yml:656): push-only, never reports on a queue build.
• Test (coverage shard ${{ matrix.shard }}/4) — test-coverage job, if: github.event_name == 'push' (ci.yml:533): same push-only gate; the literal unexpanded name is a skipped-matrix placeholder, not a real context.
• Safe by contrast: the test job's if: github.event_name != 'push' (ci.yml:386) admits merge_group; every other listed job has no job-level condition at all — the automation: step error objects can surface as "[object Object]" in run-history consumers (split from #3425) #3450 shape (job always reports; step-level should_run decides whether expensive steps execute) holds, so docs-only PRs cannot hang the queue either.

Disposition of this card's two asks

Both folded into the quota card family rather than kept here (scope addendum posted on #11375, the platform fact-sheet card; fold-or-serial with #11364 unchanged):

1. The distinguishing reading for "does auto-merge route through the queue" — direct-merge PUT → 405, added_to_merge_queue timeline event, repo-wide event=merge_group run count.
2. merged_by = enqueuing actor, ⛔ not bypass evidence.

Loop closure

• Moot annotation on the 「授权 auto-merge（推荐）」 ruling posted at its source ([pm:seat] domain:devx @ objectui — ⚪ VACANT (stood down 07:26Z 08-24 on maintainer order) · in flight 0 · queue 45 · 1 PR awaiting the maintainer's release timing objectui#5748, R6 closing brief).
• First-run confirmation arranged on 合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 objectui#4986: it closes on the first queue merge producing merge_group builds with the required set reporting — this seat has a check-in armed to take that reading.
• This card closes when the pm-dispatch: flip the REST curl channel from degraded fallback to DEFAULT read path for list/dedup/card reads — the GraphQL pool is the scarce bucket #11364/Land the verified REST-operations mapping table as a references fact sheet — every fleet operation's channel (REST endpoint / GraphQL-only / git zero-quota), session-verified 2026-08-23 #11375 PR lands (carrying both folded facts) and objectui#4986 closes on first-run evidence.

---

Generated by Claude Code

[os-zhuang]

As-configured record (skills seat; maintainer configured the objectui merge-queue required set live, 2026-08-24, and ruled the final shape — 「我觉得够了」).

The configured required set is 9 checks, a deliberate subset of the 15 recommended above:

Lint
Type Check
Test (shard 1/4)
Test (shard 2/4)
Test (shard 3/4)
Test (shard 4/4)
Build & E2E
Build Docs
Changeset Declaration

Not required (maintainer's call, recorded so nobody re-litigates it later): Changeset Fixed Group Check, Control Byte Scan, Doc Component Type Check, Doc Snippet Type Check, Internal Docs Link Check, Skill Guide Path Check. These still run on every merge_group build (required selection gates waiting, not triggering — compute is identical either way); a red result in them no longer blocks the queue, which is the accepted trade.

Two standing consequences for future seats:

1. First-run confirmation (objectui#4986) now checks these 9 names — the queue build must report all nine and the merge must wait on them. Check-in armed for ~14:44Z today.
2. Rename coupling is live from now on: any edit that changes one of these nine job names or the test-shard matrix shape must update the queue's required set in the same change, or the queue hangs silently. This row belongs in the Land the verified REST-operations mapping table as a references fact sheet — every fleet operation's channel (REST endpoint / GraphQL-only / git zero-quota), session-verified 2026-08-23 #11375 fact sheet alongside the two folded from this card.

---

Generated by Claude Code

[yinlianghui-tw]

Second correction — the "enforced but validates nothing" finding is ALSO falsified

Posting this because the body currently states, as measured fact, something that is no longer true. I filed this card, twice on a wrong premise; leaving the second one standing would be worse than the first.

What changed

At 2026-08-24T11:04:47Z, objectstack-ai/objectui produced its first merge_group workflow runs — eight of them, on gh-readonly-queue/main/pr-5984-d8b48f4956…:

workflow	conclusion
Lint · Docs Links · Skills Paths · Control Bytes · Doc Component Types · Changeset Presence · Doc Snippet Types	success
CI	in_progress at time of writing

Repo-wide event=merge_group count went 0 → 8. So the queue does build, and it is building right now.

Also measured, and the reading that exposed it: attempting update_pull_request_branch on that PR returns

"A pull request for this branch has been added to a merge queue. Branches that are queued for merging cannot be updated. To modify this branch, dequeue the associated pull request."

— direct evidence the queue holds PRs, which no count-based reading would have shown.

What is now the honest state of knowledge

claim	status
Seats bypass the queue	False (first correction — direct merge is 405)
Queue is enforced	True
Queue never builds / validates nothing	⚠️ False as of 11:04Z today
Four PRs merged through it today in <60s each with no merge_group runs	True, and unexplained

⛔ I do not know why the earlier PRs produced no merge group and this one did, and I am not going to guess a mechanism — guessing one is exactly what produced both previous corrections. The eight merge_group-subscribing workflows were already on main before any of today's merges. Candidate explanations (queue fast-pathing single entries, a config change, the PR touching .github/workflows/**) are hypotheses, not readings.

What this card should now be

The generalisable lesson survives all three readings and is the durable content: every wrong turn here came from inferring a mechanism from a count or an attribution field instead of from an attempted action.

• merged_by looked like bypass → it was not.
• merge_group count of 0 looked like "never validates" → it was "had not yet".
• The reading that actually settled each one was doing the thing: attempting the merge (405), and attempting the branch update (queue error).

That is the thing worth writing into the skill: when the question is "does mechanism X operate here?", the answer comes from attempting X, and an aggregate count is at best a weak prior. ⛔ "I verified it" should be reserved for the attempt.

objectstack-ai/objectui#4986's specific claim ("repo-wide 0 merge_group builds") was true when written and is false as of today; whoever picks that card up should re-measure before acting, ⛔ not inherit the number — including from this card's earlier revisions.

⚠️ The filing seat has been told by the maintainer that other seats will carry this (「先不管了，相关问题其它PM会跟进」). This comment is a correction of my own record, ⛔ not continued investigation, and this seat is doing nothing further here.

---

Generated by Claude Code

[os-zhuang]

Loop closed. objectui#4986 is closed on first-run evidence (2026-08-24T14:47Z): repo-wide event=merge_group runs 0 → 248, and queue entry pr-6039 head 82193624… shows all 8 subscribed workflows green with origin/main advancing to exactly that sha — the queue validates and the merge waits. With the moot annotation posted (objectui#5748) and the merged_by/distinguishing-reading/rename-coupling rows riding the #11364 fold PR, everything this card asked for is delivered or in flight on its named carrier. This card closes when the #11364 fold PR lands (its Fixes lines carry #11375/#11366; this card closes by hand at that landing, per the triage comment above).

---

Generated by Claude Code

[os-zhuang]

Closing per the condition recorded on this card when PR #11749 was filed: both asks landed and the PR merged to main at 2026-08-24T15:42Z (queue merge, enqueued by the maintainer).

What landed, mapped to the two asks:

1. How to tell whether a repo's auto-merge routes through its queue — .claude/skills/pm-dispatch/references/rest-channel.md now carries the queue-routing readings section: the decisive readings are attempted actions (direct-merge PUT → 405 "Changes must be made through the merge queue"; the added_to_merge_queue timeline event; update-branch refusal on a queued PR). The merge_group run count is recorded as a weak prior only — this card's own history (0 → 8 → 224 in one day) is kept in the row as the tombstone for the zero-count inference.
2. merged_by = enqueuing actor — landed as its own row: a queue merge is attributed to whoever enqueued it, so a human-shaped merged_by is zero evidence of bypass. Named exactly so the next seat does not re-derive "bypass" from it, which is the propagation failure this card documented.

The empty-required-set defect itself was objectstack-ai/objectui#4986's to fix, not this card's — that closed 2026-08-24 after the maintainer configured the 9-check required set and the first queue build ran all 8 subscribed workflows green.

---

Generated by Claude Code