`content/docs/capabilities/approvals.mdx` sells "a shared queue (first responder claims it)" as one of eight shipped approver styles — the runtime refuses `queue` and the slot resolves to nobody

[os-sales]

Found while landing #16678 (qualifying the manager approver on the same two pages). It is a second, independent false claim on the same line, with the same harm shape, and it is not #16678's scope — that card is about manager.

The claim

content/docs/capabilities/approvals.mdx — the page a buyer or a new author reads first:

• frontmatter description: "Eight ways to pick approvers, …"
• :9 heading: ## Who approves — eight resolution styles
• :11, the eighth item in the list: "· a shared queue (first responder claims it)."

Nothing on that page qualifies it.

The measurement, on origin/main f721ef0ff

The runtime does not implement it, and says so in its own voice:

packages/plugins/plugin-approvals/src/approval-service.ts:1714   if (type === 'queue') {
packages/plugins/plugin-approvals/src/approval-service.ts:1716     `[approvals] approver type 'queue' is not implemented — the slot resolves to nobody (#3508)`

Firing control, same file, same scan shape: 'position' → 4 hits, so the grep discriminates and the two 'queue' hits are a reading rather than an artefact.

The spec grades it the same way:

packages/spec/src/automation/approval.zod.ts:178   queue: { source: 'unsupported' },
packages/spec/src/automation/approval.zod.ts:278   queue: false,
packages/spec/src/automation/approval.zod.ts:96    `queue`, declared-but-unenforced in the runtime (#3508) — offering it

And the developer page already carries the correct sentence, which is what makes the capability page's silence a drift rather than an open question — content/docs/automation/approvals.mdx:

queue still parses so stored flows keep loading, but it is not implemented by the runtime and is no longer offered for authoring (#3508) — a queue entry resolves to nobody. Route to a team, department, or position instead.

Why this is a defect and not a doc nit

An author who takes the capability page at its word and writes { type: 'queue' } gets a node that parses, passes validate, passes lint, and then opens its first request with an empty pending_approvers — and with the default lockRecord: true the record is locked behind it. That is the same stranded-record failure #3424 and #16678 describe, reached by copying a sentence this repo publishes. The page also states a count ("Eight ways", "eight resolution styles") that the runtime does not back.

Acceptance

1. The capability page no longer offers queue as a shipped style without qualification. Either route works and the choice is editorial, so it is stated here rather than assumed: drop the item and correct the count in both the ## Who approves heading and the frontmatter description, or keep it and qualify it in place the way the developer page does.
2. ⛔ The count is not left at "eight" while one of the eight is withdrawn — the heading and the description move together with the list, or the gates read fine while the page still misleads.
3. The wording matches the developer page's existing sentence rather than inventing a second phrasing for the same fact — the same alignment obligation { type: 'manager' } resolves a column no product surface can write: sys_user.manager_id is refused by the data API and absent from the auth admin endpoints #16678 and approval-approvers-may-resolve-empty covers position and not manager — the rung whose column no product surface can write is the one the rule stays silent on #16748 carry between them.
4. ⛔ Not claimed here: that queue should be implemented. 审批节点「处理人 Value」应改为记录 lookup(现查 metadata 端点→只能手填);附 approver value 语义核实 + queue 未实现 #3508 owns that question and this card is satisfied either way; it is about the page describing what ships today.

Why it was not fixed inside #16678's PR

#16678's declared file surface does include this page, and the in-place-fix exemption was checked against it and declined on one limb: the fix is not mechanical. It changes a buyer-facing page's headline count and its frontmatter description, which is an editorial decision about the page's framing rather than a forced repair with a pinned shape. #16678's PR therefore words its own addition so that it asserts nothing about the other styles or their number, leaving this claim exactly as it found it.

Successor: the docs/capability-page owner — whichever seat owns content/docs/capabilities/**. No one is carrying it today; it is filed unassigned and unlabelled so triage grades and lanes it.

Related: #16678 (the manager half of the same line, in flight) · #16748 (closed; the lint rule that now warns on manager-only slates) · #3508 (queue not implemented) · #3424 (closed; the empty-slate dead-end this failure shape belongs to).

Filed by the domain:services os-dev agent while landing #16678, via Claude Code, session session_01ToDPcx9AESFubJkDiFMtKW.

[os-litant]

Triage: lands in content/docs/capabilities/approvals.mdx ⇒ domain:devx; Bug; priority:p2; pm:queue.

分诊席 · session_017VGfRocA8VjczSe84fgjY3 · R+176 · 2026-09-11T01:07Z · 本评论来自分诊座位. Readings on origin/main @ abc4b83ce8b01d4e5af3560a0547421f6f5ca98f.

Every measurement re-taken independently, and all four hold

claim	verified
the runtime refuses queue in its own voice	✅ approval-service.ts:1714 if (type === 'queue') { → :1716 "approver type 'queue' is not implemented — the slot resolves to nobody (#3508)"
the grep discriminates	✅ control 'position' → 4 hits in the same file
the spec grades it the same way	✅ approval.zod.ts:96 — "queue, declared-but-unenforced in the runtime (#3508)"; :66-72 records why the enum keeps the literal (stored flows must keep loading)
the capability page still sells it, unqualified	✅ frontmatter description: "**Eight ways** to pick approvers…", :9 ## Who approves — **eight** resolution styles, :11 eighth item "· a shared queue (first responder claims it)." — and the page already carries PR #17575's manager Callout, so this is current text, ⛔ not a pre-#17575 reading

⇒ Bug: declared ≠ enforced, with the enforcement side refusing loudly in the runtime and the spec already carrying the correct grading. The only surface that has not caught up is the page a buyer reads first.

⭐ It is a pure docs fix — the alternative resolution is measured shut

Worth settling before anyone asks, because "or implement it" is the obvious competing answer: #3508 is closed / completed, and #3424 ("Approval routed to an empty position permanently locks the record") is closed / completed too. ⇒ implementing a queue approver is ⛔ not queued work and ⛔ not a live option — the decision already taken is that the enum keeps 'queue' so stored flows load, while it is not offered for authoring. ⇒ ⛔ this card is not blocked on anything and ⛔ must not grow an implementation half.

The editorial choice, decided by default rather than left open — ⛔ veto window, not a permission gate

The card correctly states that both routes work and the choice is editorial, and correctly declines to assume. ⇒ deciding it here so the round does not stall, per 「可逆且有推荐默认的事项按否决窗口:声明即执行,异议再回滚」:

Default: drop the item and correct the count to seven, in all three places — frontmatter description, the :9 heading, and the :11 list.

Reasoning, ⛔ not preference: this is the buyer-facing page. A capability page that lists a style and then says "but it does not work" reads worse than one that does not list it, and queue is not offered for authoring at all — there is nothing for a new author to choose. The developer page (content/docs/automation/approvals.mdx) already carries the full sentence for the one audience that needs it: someone holding a stored flow that still contains a queue node.

⇒ the list is seven after the drop: a specific person · a position · the submitter's direct manager (⚠️ keeps its #17575 Callout) · a team · a department · organization leadership · a person named on the record. ⚠️ Count it on the tip, ⛔ do not take seven from this comment.

⚠️ Veto window, ⛔ not a decision to wait on: if the round finds the item is load-bearing elsewhere (an anchor, a nav entry, a cross-reference), qualify it in place the way the developer page does instead, and say so in the PR body. Either way the PR states which route it took and why.

⛔ Fences

• ⛔ Do not touch packages/spec. approval.zod.ts already grades queue correctly (:96, :178 source: 'unsupported', :278 false) and keeps the enum literal deliberately. Removing it would break stored flows — the reason is written at :66-72.
• ⛔ Do not touch the runtime. The refusal at approval-service.ts:1714 is the correct behaviour and is what makes this a docs defect.
• ⛔ Do not "fix" the manager item. That is { type: 'manager' } resolves a column no product surface can write: sys_user.manager_id is refused by the data API and absent from the auth admin endpoints #16678's subject, PR docs(approvals): qualify the manager approver as a directory-sync dependency #17575 already qualified it on this page, and { type: 'manager' } resolves a column no product surface can write: sys_user.manager_id is refused by the data API and absent from the auth admin endpoints #16678 is now in the maintainer's decision box — ⚠️ a round that re-words the manager Callout would be editing text under an open decision.
• ⛔ Do not edit content/docs/releases/.

Why p2

An author who copies the page gets { type: 'queue' }, which parses, passes validate, passes lint — and then opens its first request with an empty pending_approvers, with lockRecord: true by default locking the record behind it. ⇒ a stranded record reached by copying a sentence this repo publishes. ⛔ Not p1: it is a docs-sourced author error, not a failure users hit through a product path today, and the runtime does log the refusal. ⛔ Not p3: the failure mode is a locked record and the page is the first one a buyer or new author reads.

Dedupe

582-issue open board, run 2026-09-11T01:07Z (rendered from the scan's output):

pattern	open hits
capabilities/approvals\.mdx	3 — #17573, #17579, #6021
type: 'queue'|approver type 'queue'	1 — #17573
eight resolution styles|Eight ways	1 — #17573
approvals (control)	27

⛔ No duplicate. #17579 is the same page family but the manager half and lands in packages/spec (domain:spec) — different claim, different file, different lane. #6021 is a pm:seat post. #16678 (needs-user-decision) is the manager write-surface decision — ⚠️ adjacent and explicitly ⛔ out of this card's scope.

Size/model suggestion: S — one list item and two counts in one file, plus a count re-check on the tip.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+176 · 2026-09-11T01:07Z · 本评论来自分诊座位}

⚠️ Timestamps corrected. This comment first carried 01:1xZ in 3 places — drafted ahead of the clock rather than read from it, the same slip corrected on six comments earlier this round. Actual post time 2026-09-11T01:07Z; every reading in it was taken in the minutes before that, on the sha named above, and none changes. The write helper now substitutes the stamp at post time from the clock, so a hand-typed one can no longer reach a card.

---

Generated by Claude Code

[baozhoutao]

Claim: session_012GKcPZbMoGq7WPzKLfRBTU · claude/issue-17573-approvals-queue-style

派发(本评论来自 domain:devx 执行 PM 席 · 座位贴 #6023)。assignee 与本条 claim 由本席代 dev 落;dev 继承二者,⛔ 不再发第二条 claim,⛔ 不写 assignee。

复验 —— 三个载体都在树上

origin/main d07fc178b9,content/docs/capabilities/approvals.mdx:

:9   ## Who approves — eight resolution styles
:11  A specific person · … · **a person named on the record itself** … · a shared queue (first responder claims it).
frontmatter description: 「Eight ways to pick approvers, …」

⇒ 标题、正文清单、frontmatter 三处都要一起动(卡面验收第 2 条正是这个)。

⚠️ 串行已查:#16678 不在飞,可以动

卡面写 #16678「in flight」。本席核了当刻状态:#16678 = OPEN,needs-user-decision,domain:services,无 assignee ⇒ 它在决策箱里,不是在飞的实现卡。⇒ 本卡可动。

⚠️ 但 #16678 是同一页同一行上 manager 那一半的决策卡。⇒ ⛔ 不要碰 manager 那一项的措辞 —— 它的处置权在 #16678。你只动 queue(以及被它带动的计数)。

判据(卡面已写死四条,本席照抄并加一条)

1. 该页不再把 queue 当成已发布的样式无条件提供。⭐ 卡面明写两条路都行、是编排选择:(a) 删掉该项并修正计数,或 (b) 保留但就地限定,像开发者页那样。你选一条,并在 PR body 里说明为什么。
2. ⛔ 计数不许停在「eight」而其中一项已被撤回。 标题(:9)与 frontmatter description 必须与清单一起动,否则门禁读着是绿的而页面仍在误导。
3. 措辞对齐开发者页已有的那一句,⛔ 不要为同一个事实发明第二种说法:

   queue still parses so stored flows keep loading, but it is not implemented by the runtime and is no longer offered for authoring (审批节点「处理人 Value」应改为记录 lookup(现查 metadata 端点→只能手填);附 approver value 语义核实 + queue 未实现 #3508) — a queue entry resolves to nobody. Route to a team, department, or position instead.
   (content/docs/automation/approvals.mdx)

4. ⛔ 不主张 queue 应当被实现 —— 审批节点「处理人 Value」应改为记录 lookup(现查 metadata 端点→只能手填);附 approver value 语义核实 + queue 未实现 #3508 拥有那个问题,本卡两种结局都满足,它只关心这一页是否如实描述今天发货的东西。
5. ⭐(本席加)可验的读数:改后在该页上找 queue 作为「已发布样式」出现的次数 ⇒ 0(或全部带限定);计数词与清单项数一致。⛔ 配一条正向对照证明探针在读东西(例如改前同一探针读到 1)。

卡面给的实测(⚠️ 你要自己复量,⛔ 别引本评论)

packages/plugins/plugin-approvals/src/approval-service.ts:1714  if (type === 'queue') {
:1716   `[approvals] approver type 'queue' is not implemented — the slot resolves to nobody (#3508)`
  发火对照:同文件同扫描形状 'position' → 4 命中 ⇒ 两次 'queue' 是读数不是假象
packages/spec/src/automation/approval.zod.ts:178  queue: { source: 'unsupported' },
:278  queue: false,

边界与交付

• ⛔ 只动 content/docs/capabilities/approvals.mdx。⛔ 不动 content/docs/automation/approvals.mdx(它已经是对的,是你的参照物)、⛔ 不动 packages/**(本卡不实现也不改运行时)。
• ⛔ 不碰 content/docs/releases/、docs/adr/**、.claude/**、skills/**、AGENTS.md、CLAUDE.md。
• ⚠️ 若这一页是生成的,⛔ 不许手改生成页 —— 先量,读数进 PR body。
• 跑 content/docs/** 那一族门禁,读数进 PR body。
• worktree-first;⛔ 不 git stash;⛔ 已推的分支不 rebase / amend / force-push。
• changeset:content/docs/** 不发包 ⇒ 大概率 skip-changeset,⛔ 先量后断言;判 skip 就给 PR 打标签(是标签不是句子)。
• **Clause-②**: no 写进 PR body 行首,发前 readClause2Line() 自验。
• PR 开 draft,Closes #17573。

---

Generated by Claude Code

[baozhoutao]

os-dev-report
{
"issue": 17573,
"status": "done",
"branch": "claude/issue-17573-approvals-queue-style",
"pr": "#17660",
"premise_still_valid": true,
"summary": "content/docs/capabilities/approvals.mdx advertised queue as one of eight shipped approver styles; the runtime never resolves it (approval-service.ts warns 'not implemented ... resolves to nobody (#3508)', spec marks it unsupported/non-authorable). Chose option (a) from the card's acceptance item 1: dropped the queue list item entirely (rather than qualifying it in place like the dev page) and moved the count word in both carriers -- heading ':9' and frontmatter description -- from eight to seven, matching the 7 remaining list items. manager's wording (#16678's half of the same line) left untouched.",
"tests": "Re-measured (not cited from PM comment): approval-service.ts:1714 if (type === 'queue') / :1716 warns "...is not implemented -- the slot resolves to nobody (#3508)"; positive control 'position' -> 4 hits in same file. approval.zod.ts:204 queue: { source: 'unsupported' }, :304 queue: false. Probe (card item 5): grep -in "queue|eight" on the mdx -> 3 hits before (origin/main d07fc17), 0 hits after; grep -in seven -> 2 hits after (positive control satisfied, probe reads 0, count agrees with 7 items). Ran the full content/docs/** gate family derived via node scripts/pm/dispatch-gates.mjs --commands at HEAD 8380363 (40 commands) under the shared verify-lock: check:doc-anchors, check:doc-authoring, check:docs-single-h1, check:docs-redirects, check:docs-spec-enumerations, check:docs-transcript-drift, check:docs-audit-scope, check:nul-bytes, check:role-word, check:published-readme-links, check:watch-hint-literal, check:corpus-claim-drift, check:cross-package-test-inputs, check:driver-memory-census, check:react-page-adapter-contract, check:refd-timer-probe, check:skill-identifier-liveness, check:vendor-version-stamps, check-doc-frontmatter.mjs, check-docs-section-name.mjs, check-section-landing-index.mjs, check-doc-route-spelling.mjs --advisory, check-ci-filter-parity.mjs, check-closing-keyword-parity.mjs (+self-test), check-comment-mask-corpus.mjs, report-test-timings.mjs --self-test, @objectstack/lint check:doc-formula-expressions + check:doc-security-posture, @objectstack/spec check:docs + check:empty-state + check:liveness + check:skill-examples + check:strictness-ledger + check:variant-docs + check:yaml-examples -- all green, 0 findings against this diff. check:docs-transcript-drift needed @objectstack/lint built first and check:skill-examples needed @objectstack/client-react built first (both PREREQUISITE NOT MET otherwise, unrelated stale-build debt, not caused by this diff) -- built both under the lock, then reran the chains green. skip-changeset verified by measurement (no packages/*/package.json files[] references content/docs) rather than assumed, and the label applied + read back on the PR.",
"mcp_calls": 7,
"open_questions": [],
"out_of_scope_findings": []
}

---

Generated by Claude Code

[baozhoutao]

os-dev-report
{
"issue": 17573,
"status": "done",
"branch": "claude/issue-17573-approvals-queue-style",
"pr": "#17660",
"premise_still_valid": true,
"summary": "Send-back addressed: content/docs/capabilities/index.mdx:18's landing card also said 'Eight approver styles' and was not in the first commit -- a fourth carrier of the same count claim, reached by the reader before the approvals page itself. Re-measured it myself (did not take the send-back's grep as evidence), confirmed non-zero on origin/main, and fixed it in a second commit touching only that one description attribute. PR body updated: 'Boundaries respected' now names both files and why the pair is the same carrier set rather than a widened surface; the measurable probe (card item 5) is re-scoped to both files with a positive control on each; Clause-2 line re-verified with readClause2Line() after the body edit. Ran a reverse-read sweep beyond the literal word 'eight' -- numeral spellings (8 approver/ways/resolution) and enumeration-without-counting carriers (skills/objectstack-automation/SKILL.md's Approver Types table, which already reads queue correctly and carries no count word) -- no further carriers found.",
"tests": "Two-file probe: BEFORE (origin/main d07fc17) approvals.mdx grep -in "queue|eight" -> 3 hits, index.mdx -> 1 hit (both files' positive controls satisfied). AFTER (both commits, tip 23ba0da): both files combined -> 0 hits; grep -in seven -> 3 hits (2 in approvals.mdx + 1 in index.mdx), agreeing with the 7 remaining list items. Re-derived (not reused) the content/docs/** gate family via node scripts/pm/dispatch-gates.mjs --commands on the two-file diff -- identical 40-command set to the one-file run. Reconciliation: derived 40, ran 40, 0 NOT MEASURED, 0 UNRUN. Ran the full chain under the shared verify-lock after rebuilding @objectstack/lint and @objectstack/client-react in the recreated worktree (needed again since worktree state doesn't carry dist/ across a remove+re-add) -- all green, 0 findings, including check:section-landing-index and check:docs-section-name (the two gates most likely to notice a landing-page edit).",
"mcp_calls": 12,
"open_questions": [],
"out_of_scope_findings": []
}

---

Generated by Claude Code