fix(docs): sync daemon capability count

[yiliang114]

What this PR does

Updates the documented daemon capability count from 152 to 153 so the documentation contract matches the registry currently shipped on main.

Why it's needed

#10643 and #10751 each added one capability from branches based on the same earlier count. Both PR heads independently had 152 registered capabilities and passed their checks, but #10751 was merged after #10643 without being retested against the updated main. The combined result has 153 capabilities while the documentation still reports 152, causing the main unit-test job to fail with expected 152 to be 153.

This is the narrow repair for the current red build. Preventing the same semantic-conflict class requires a separate merge-queue or up-to-date required-check change.

Reviewer Test Plan

How to verify

Confirm that the existing daemon capability documentation contract observes 153 registered tags and 44 conditional tags, matching the current registry.

Evidence (Before & After)

Before: the registry reports 153 registered tags while the documentation reports 152.

After: both report 153 registered tags; the conditional count remains 44.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	N/A
🐧 Linux	N/A

Environment (optional)

Node.js 22 with a direct execution of the same registry-versus-documentation count assertion used by the failing contract test.

Risk & Scope

• Main risk or tradeoff: none beyond keeping the manually documented count synchronized with the current registry.
• Not validated / out of scope: this does not change branch protection or prevent future semantic conflicts between concurrently mergeable PRs.
• Breaking changes / migration notes: none.

Linked Issues

Fixes #11010

中文说明

本 PR 做了什么

将 daemon 文档中的 capability 数量从 152 更新为 153，使文档契约与 main 当前实际发布的注册表一致。

为什么需要

#10643 和 #10751 都基于更早的同一个数量，各自新增了一个 capability。两个 PR 的 head 单独看都是 152 个注册 capability，检查也都通过；但 #10751 在 #10643 之后合入时，没有基于更新后的 main 重新测试。最终组合结果包含 153 个 capability，而文档仍记录 152，导致 main 单测 job 以 expected 152 to be 153 失败。

这是修复当前红灯的最小改动。要防止同类语义冲突再次发生，还需要另外配置 Merge Queue，或者要求 PR 基于最新 main 重新通过 required checks。

Reviewer Test Plan

如何验证

确认现有 daemon capability 文档契约读到 153 个注册 tag 和 44 个条件 tag，并与当前注册表一致。

前后证据

改动前：注册表是 153 个注册 tag，文档记录 152 个。

改动后：两者都是 153 个注册 tag；条件 tag 数量保持 44。

测试平台

OS	状态
🍏 macOS	✅
🪟 Windows	N/A
🐧 Linux	N/A

环境（可选）

Node.js 22，直接执行与失败契约测试相同的注册表数量和文档数量比较断言。

风险与范围

• 主要风险或取舍：除了继续保持手工记录数量与当前注册表同步之外，没有额外风险。
• 未验证 / 范围外：本 PR 不修改分支保护，也不防止并发可合入 PR 之间未来再次出现语义冲突。
• 破坏性变更 / 迁移说明：无。

关联 Issue

Fixes #11010

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[chiga0]

Reviewed at head 620b9b96.

No blocking findings. Approval blockers: none.

Tier: Scan — single documentation line, no production code changed.

Claim verified: 153 registered tags matches Object.keys(SERVE_CAPABILITY_REGISTRY).length = 153 at HEAD (counted across capabilities.ts L32–L495). The prior count 152 was the result of two PRs (#10643 and #10751) both incrementing the same base count independently; net is 151 + 2 = 153.

Conditional count (44) unchanged and correct: CONDITIONAL_SERVE_FEATURES has 44 entries at HEAD (43 found by pattern + voice_transcribe at L740 whose entry has a comment block before the key). No new conditional capabilities were added in the two PRs.

Contract test: packages/cli/src/serve/capabilities-docs-contract.test.ts keeps the daemon index capability counts in sync reads both SERVE_CAPABILITY_REGISTRY length and CONDITIONAL_SERVE_FEATURES.size at runtime and asserts they equal the values extracted from 00-index.md — any future skew fails CI automatically.

Reviewed with AI assistance.

[qwen-code-ci-bot]

Thanks for the PR — this one is easy to check, and it checks out.

Template looks good ✓

Problem: observed, not theoretical. main at 9c320cb0 is red on exactly this — run 33847266498 / job 100942480462 fails capabilities-docs-contract.test.ts:54 with AssertionError: expected 152 to be 153. Linked #11010 is still open.

Direction: aligned. It is the narrow repair for a red main, and the story in the description holds up: #10643 and #10751 each added one capability from the same earlier base, each head counted 152 on its own, and the merged result is 153. I confirmed the registry side independently rather than taking the number on faith — SERVE_CAPABILITY_REGISTRY in packages/cli/src/serve/capabilities.ts really does have 153 entries at 9c320cb0. The neighbouring conditional count of 44 is still correct too (44 rows in the qwen-serve-protocol.md conditional table, which the sibling test in the same file pins to the map's keys), so 153 is the only stale number and this is the only place in the repo that states it. CHANGELOG: no direct reference, but the area is clearly relevant — this is the repo's own docs contract test.

Size: not applicable. One docs file, +1/−1, no core paths, zero production logic lines.

Approach: scope feels right. Bumping the number is the minimal change, and you correctly kept the actual prevention — a merge queue, or requiring branches to be up to date before merge — out of this PR instead of smuggling in a branch-protection change. Worth a follow-up issue so that prevention does not get lost: this is a semantic-conflict class, not a one-off, and the same two-PR race will drift this number again.

Risk: no elevated risk signals. docs/developers/daemon/00-index.md matches none of the revert-correlated paths.

Moving on to code review. 🔍

中文说明

感谢贡献！这个 PR 很容易核验，而且核验通过了。

模板完整 ✓

问题：是已观测到的问题，不是理论性加固。main 在 9c320cb0 上正因为此事红灯——run 33847266498 / job 100942480462 在 capabilities-docs-contract.test.ts:54 失败，报 AssertionError: expected 152 to be 153。关联的 #11010 仍处于 open 状态。

方向：对齐。这是修复 main 红灯的最小改动，PR 描述里的成因也站得住：#10643 和 #10751 基于同一个更早的 base 各加了一个 capability，两个 head 各自数都是 152，合并后是 153。我没有直接采信这个数字，而是独立核实了注册表一侧——packages/cli/src/serve/capabilities.ts 里的 SERVE_CAPABILITY_REGISTRY 在 9c320cb0 上确实有 153 项。旁边的条件 tag 数量 44 也仍然正确（qwen-serve-protocol.md 条件表恰好 44 行，同文件的另一个测试把该表与 map 的 key 集合绑定），所以 153 是唯一过期的数字，而这里也是仓库中唯一写明该数量的地方。CHANGELOG：无直接引用，但该区域明显相关——这是仓库自己的文档契约测试。

规模：不适用。单个文档文件，+1/−1，未触及核心路径，生产逻辑行数为 0。

方案：范围合理。改数字就是最小改动；你也正确地把真正的预防手段——Merge Queue，或要求合并前分支必须基于最新 main——留在本 PR 之外，没有顺手夹带分支保护改动。建议再开一个 follow-up issue，避免预防措施被遗忘：这属于语义冲突这一类问题，而不是一次性事故，同样的两 PR 竞争以后还会让这个数字再次漂移。

风险：无升级风险信号。docs/developers/daemon/00-index.md 不匹配任何与 revert 相关的高风险路径。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 620b9b966f03d9fa3e352f7a63f3eb0ac0c1a3fc · re-run with @qwen-code /triage}

[qwen-code-dev-bot]

Reviewed at head 620b9b96.

• One-line doc-count repair with the failure cause verified independently: #10643 and #10751 each added a capability against the same 152-count baseline, the merge combined them to 153, and the docs contract test keys off Object.keys(SERVE_CAPABILITY_REGISTRY).length — so main went red exactly as the body describes. I ran the contract test itself against this head (origin/main's capabilities.ts + test, this PR's 00-index.md): both cases pass, 2/2.
• No review history, no threads, nothing else in the diff.
• CI facts: 13 checks pass; the single red never executed a test — the ubuntu Test job died 42 s into checkout with inflate: data stream error (unknown compression method) / fetch-pack: invalid index-pack output on object 07ced3e3…, i.e. a corrupted git object cache on the pool host, unrelated to this one-line docs change. A retry onto a healthy host should go green; if it sticks, that host needs its runner cache cleaned (flagging for the operator). Per the channel convention the call is on the review, and the repair it delivers is proven by the local run above.

[qwen-code-ci-bot]

Code review

Before reading the diff I wrote down what I would do: bump the documented registered-tag count in the daemon index to match Object.keys(SERVE_CAPABILITY_REGISTRY).length, confirm the neighbouring conditional count is still accurate, check nothing else in the repo states the stale number, and leave the merge-queue prevention out. That is exactly what this PR does — no simpler path, and nothing missing.

No blockers, and no AGENTS.md violations. Three details I checked because they are the easy ways to get a one-character docs fix wrong:

• The contract test's regex still matches. capabilities-docs-contract.test.ts builds its pattern from SERVE_PROTOCOL_VERSION and expects the literal sequence `SERVE_PROTOCOL_VERSION = 'v1'`; <digits> registered tags; <digits> conditional tags. The edit changes only the digits, so the surrounding text the regex depends on — including the closing backtick before the semicolon — is untouched. Had the phrasing been reworded, match would come back null and the test would fail differently.
• No table churn. 152 → 153 is a same-width substitution, so the markdown table's padding is byte-identical in width and the row alignment is unchanged. Nothing for Prettier or a markdown linter to complain about, which is consistent with Lint & Static passing.
• Nothing else states the count. registered tags appears in exactly two places repo-wide: this table row and the test that reads it. The other daemon pages describe the registry without quoting a number, so there is no second stale copy left behind.

The change is complete as scoped: 153 is the only drifted value, and 44 conditional tags is still right.

Test evidence

This is an unattended CI run, so I did not build or execute anything from this PR — the evidence below is the PR's own CI read through the API, plus main's CI for the failure being repaired.

Check	Status	Conclusion
Classify PR	completed	success
Dependency CVE audit	in_progress	—
Desktop Shell (ubuntu-22.04)	completed	success
Desktop Shell (windows-2022)	completed	success
Integration Tests (CLI, No Sandbox)	completed	skipped
Integration Tests (no-AK, No Sandbox)	completed	success
Lint & Static (ubuntu-latest, Node 22.x)	completed	success
Secret scan (TruffleHog)	completed	success
Test (macos-latest, Node 22.x)	completed	skipped
Test (ubuntu-latest, Node 22.x)	completed	failure
Test (windows-latest, Node 22.x)	completed	skipped
ack-review-request	completed	skipped
assign	completed	success
authorize	completed	success
delay-automatic-review	completed	success
label	completed	success
precheck-pr / precheck	completed	success
publish-resolution	completed	skipped
publish-tmux	completed	skipped
publish-verify	completed	skipped
resolve-pr	completed	skipped
review-config	completed	skipped
review-pr	in_progress	—
tmux-testing	completed	skipped
triage	in_progress	—
verify	completed	skipped
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	completed	skipped

The one red check is runner infrastructure, not this PR. Test (ubuntu-latest, Node 22.x) (job 100953331644) never reached npm install or vitest — it died inside actions/checkout on runner ecs-qwen-hk3-10, and it died the same way on all three retries:

##[group]Run actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10
##[error]error: inflate: data stream error (unknown compression method)
##[error]error: unable to unpack 07ced3e3d5316bce7745b0c93eb337395c90c89b header
##[error]fatal: cannot read existing object info 07ced3e3d5316bce7745b0c93eb337395c90c89b
##[error]fatal: fetch-pack: invalid index-pack output
The process '/usr/bin/git' failed with exit code 128

That is a corrupted git object store on the runner. A one-line markdown edit cannot produce an inflate failure while fetching the PR ref, and the job log is 260 lines long with no test output in it at all. The macOS and Windows Test legs read skipped as a downstream consequence of the matrix leg failing, not because they were deselected. I am calling this pre-existing infra noise on the evidence above, not on anything claimed in the PR.

What that costs us, stated plainly: the contract test has not been observed green on this head, because no leg ever ran it. The remedy is a re-run of the Test job — not a sandboxed lane. There is no behavioural claim here to settle: nothing about runtime behaviour, wire format, or any TUI surface changes, so neither @qwen-code /verify nor @qwen-code /tmux would add signal over a plain re-run.

Independent confirmation of the failure being repaired. Since the PR's own CI could not substantiate the fix, I verified the target state directly against 9c320cb0 — which the job log confirms as WORKFLOW_SIZE_BASE_SHA, i.e. this PR's actual base. Main's CI (job 100942480462):

❯ src/serve/capabilities-docs-contract.test.ts (2 tests | 1 failed) 15ms
  × conditional serve capability documentation > keeps the daemon index capability counts in sync 9ms (retry x2)
    → expected 152 to be 153 // Object.is equality
AssertionError: expected 152 to be 153 // Object.is equality
❯ src/serve/capabilities-docs-contract.test.ts:54:32

Line 54 is the registered-tags assertion, with the docs value as received and Object.keys(SERVE_CAPABILITY_REGISTRY).length as expected — so the registry holds 153 and the docs said 152. Statically counting the registry at that same commit gives 153 descriptor entries between lines 33 and 494 of packages/cli/src/serve/capabilities.ts (the two multi-line descriptors, workspace_memory_remember and permission_mediation, both fall inside that range, and no entry-shaped line appears after the registry closes). For the conditional count, the sibling test that pins the qwen-serve-protocol.md table to CONDITIONAL_SERVE_FEATURES keys passed in that same run, and that table has exactly 44 rows — so 44 is correct and the second assertion on line 57 would pass too. 153 is the right and only value to write.

Not verified: the contract test passing on this PR head, for the infra reason above. Everything else here is verified against the base commit.

中文说明

代码审查

在读 diff 之前我先写下了自己的方案：把 daemon index 里记录的注册 tag 数量改成与 Object.keys(SERVE_CAPABILITY_REGISTRY).length 一致，确认旁边的条件 tag 数量仍然准确，检查仓库里没有别处还写着过期数字，并把 Merge Queue 这类预防措施排除在外。这个 PR 做的正是这些——没有更简的路径，也没有遗漏。

没有阻塞项，也没有违反 AGENTS.md。有三个细节我特意核对了，因为一行文档修复最容易在这些地方出错：

• 契约测试的正则仍能匹配。 capabilities-docs-contract.test.ts 用 SERVE_PROTOCOL_VERSION 拼出模式，期望的字面序列是 `SERVE_PROTOCOL_VERSION = 'v1'`; <数字> registered tags; <数字> conditional tags。本次改动只动了数字，正则依赖的周边文本（包括分号前那个反引号）完全没变。如果措辞被改写，match 会返回 null，测试会以另一种方式失败。
• 没有表格抖动。 152 → 153 是等宽替换，markdown 表格的填充宽度逐字节不变，行对齐也不变。Prettier 和 markdown linter 都无从挑剔，这与 Lint & Static 通过是一致的。
• 没有别处写着这个数量。 全仓库 registered tags 只出现在两处：这个表格行，以及读它的测试。其他 daemon 文档只描述注册表而不写具体数字，因此没有留下第二份过期副本。

按既定范围看改动是完整的：153 是唯一漂移的值，44 个条件 tag 仍然正确。

测试证据

这是无人值守的 CI 运行，因此我没有构建或执行本 PR 的任何代码——下面的证据是通过 API 读取的本 PR 自身 CI，以及被修复的那次失败的 main CI。

唯一的红灯是 runner 基础设施问题，与本 PR 无关。 Test (ubuntu-latest, Node 22.x)（job 100953331644）根本没走到 npm install 或 vitest——它在 runner ecs-qwen-hk3-10 上的 actions/checkout 阶段就挂了，而且三次重试都是同一种挂法（见上方英文日志摘录）。那是 runner 上 git 对象库损坏。一行 markdown 改动不可能在拉取 PR ref 时造成 inflate 失败；整个 job 日志只有 260 行，完全没有测试输出。macOS 和 Windows 的 Test 显示 skipped，是矩阵中该 leg 失败后的连带结果，而不是被主动跳过。我判定这是既有的基础设施噪音，依据是上面这些证据，而不是 PR 里的任何说法。

这也明确带来了代价： 契约测试在这个 head 上尚未被观测到通过，因为没有任何 leg 真正跑过它。补救办法是重跑 Test job，而不是走沙箱通道。这里没有需要落定的行为性主张：运行时行为、线格式、TUI 界面都没有变化，所以 @qwen-code /verify 和 @qwen-code /tmux 相比单纯重跑不会增加任何信号。

对被修复失败的独立核实。 由于本 PR 自身 CI 无法证实修复，我直接针对 9c320cb0 核实了目标状态——job 日志中的 WORKFLOW_SIZE_BASE_SHA 确认它正是本 PR 的实际 base。main 的 CI 在 capabilities-docs-contract.test.ts:54（注册 tag 数量断言）报 expected 152 to be 153，其中文档值是 received、Object.keys(SERVE_CAPABILITY_REGISTRY).length 是 expected，即注册表有 153 项而文档写着 152。在同一 commit 上静态清点注册表，packages/cli/src/serve/capabilities.ts 第 33–494 行之间有 153 个描述符条目（两个多行描述符 workspace_memory_remember 和 permission_mediation 都在该范围内，注册表结束后也没有再出现条目形状的行）。条件数量方面，同一次运行中把 qwen-serve-protocol.md 表格与 CONDITIONAL_SERVE_FEATURES key 集合绑定的那个姊妹测试是通过的，而该表恰好 44 行——所以 44 正确，第 57 行的第二个断言也会通过。153 是正确且唯一该写入的值。

未验证：契约测试在本 PR head 上通过，原因就是上面的基础设施问题。其余内容均已针对 base commit 核实。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 620b9b966f03d9fa3e352f7a63f3eb0ac0c1a3fc · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 4/5 — the corrected value is independently verified against the exact base commit and the diff is a single same-width character swap; the one reservation is that this head's Test leg died inside actions/checkout, so no CI run has actually watched the contract test go green.

My independent proposal and this PR's approach are the same thing, which is the strongest signal I have here — I could not find a cheaper repair, and I could not find anything it forgot. The problem is not a framing I accepted on trust: main's CI states the mismatch as an assertion error at a specific line, the linked issue is open, and I counted the registry myself at the base commit rather than believing the description's arithmetic. The 152 → 153 story (two PRs each adding one capability from a shared base, merged without a re-test) is consistent with what the code actually contains.

On the "am I being worn down by volume" question, worth being explicit: the author has thirty open PRs, several landed the same day as this one. I evaluated this on its own merits and it stands alone — a red main is a real cost to every other contributor, and a verified one-line docs sync is the correct narrow repair. Volume is a reason to read carefully, not a reason to withhold.

Two honest notes for whoever merges:

• The Test job needs a re-run, not a code change. It failed fetching the PR ref with a corrupted object on runner ecs-qwen-hk3-10, three retries, never reaching vitest. Until it is re-run, nothing has executed the contract test against this head. My static verification says it will pass — 153 registered entries and 44 conditional rows both check out at the base — but that is my reading, not an observed green run.
• The prevention is still unowned. This is a semantic-conflict class: two independently-green PRs that are wrong together. The author correctly scoped the fix narrowly and named the real remedy (a merge queue, or requiring branches up to date before merge) as out of scope. That belongs in a follow-up issue so it does not evaporate. There is also a cheaper question underneath it — whether a hand-maintained count belongs in prose docs at all, given that every capability addition now requires a synchronized edit that concurrent PRs will race on. The contract test at least makes the drift loud instead of silent, which is why this surfaced as a red build rather than a quietly wrong document. Non-blocking either way.

Two approvals already stand on this exact SHA — chiga0, and qwen-code-dev-bot, which landed while this review was running. Neither is this bot's vote, and the rule I work under is that only my own approval on the commit under review counts as already cast, so the deferred approval below stands on its own terms regardless of how the required-review count currently reads.

Verdict is approve, but CI has a pull_request run still in flight on this SHA, so I am not posting an approval in this run — approval deferred until CI lands green on 620b9b966f03d9fa3e352f7a63f3eb0ac0c1a3fc. Given the Test leg is currently red on infrastructure, that means the deferred approval will only fire once it has been re-run and passes; if it stays red, no approval lands and the status comment will say so.

中文说明

Confidence: 4/5 —— 修正后的数值已针对确切的 base commit 独立核实，diff 只是一次等宽的单字符替换；唯一的保留意见是这个 head 的 Test leg 死在 actions/checkout 里，因此还没有任何一次 CI 运行真正看着契约测试变绿。

我独立想到的方案与这个 PR 的做法完全一致，这是我能给出的最强信号——我找不到更便宜的修复，也找不到它漏掉的东西。这个问题不是我照着 PR 的表述接受的：main 的 CI 把不一致表述为某个具体行上的断言错误，关联 issue 处于 open 状态，而且我没有采信描述里的算术，是在 base commit 上自己清点了注册表。152 → 153 的成因（两个 PR 基于同一 base 各加一个 capability，合并时没有重测）与代码里实际的内容相符。

关于"是否被数量磨到松手"这个问题，值得说清楚：作者有三十个 open PR，其中几个与本 PR 同日提交。我是就本 PR 本身评估的，它也站得住——main 红灯对其他所有贡献者都是实际成本，而一次已核实的一行文档同步正是恰当的窄修复。数量大是要读得更仔细的理由，不是要卡住的理由。

给合并者的两点如实说明：

• Test job 需要重跑，而不是改代码。 它在 runner ecs-qwen-hk3-10 上拉取 PR ref 时因对象损坏而失败，重试三次，始终没走到 vitest。在重跑之前，没有任何针对这个 head 执行过契约测试的记录。我的静态核实表明它会通过——base 上注册条目 153、条件行 44 都对得上——但那是我的判读，不是观测到的绿灯。
• 预防措施仍然无人认领。 这属于语义冲突这一类：两个各自绿灯的 PR 合在一起是错的。作者正确地把修复范围收窄，并点明了真正的解法（Merge Queue，或要求合并前分支必须基于最新 main）不在本 PR 范围内。这件事应该落到一个 follow-up issue 里，免得不了了之。底下还有一个更便宜的问题——手工维护的数量到底该不该写在散文式文档里，毕竟现在每次新增 capability 都要做一次同步编辑，而并发 PR 会在这个编辑上竞争。至少契约测试让漂移变成显式的红灯，而不是静默的错误文档，这也是它此次以构建失败暴露出来、而没有变成一份悄悄写错的文档的原因。两点都不阻塞。

这个确切的 SHA 上已经有两个批准——chiga0，以及 qwen-code-dev-bot（后者是在本次审查运行期间落下的）。两者都不是本 bot 的投票，而我遵循的规则是：只有我自己在被审查 commit 上的批准才算已经投出，因此无论所需 review 数当前如何计算，下面的推迟批准都独立成立。

结论是 approve，但这个 SHA 上仍有一个 pull_request 类型的 CI 运行在进行中，因此本次运行不提交批准——批准推迟到 CI 在 620b9b966f03d9fa3e352f7a63f3eb0ac0c1a3fc 上全绿之后。鉴于 Test leg 目前因基础设施问题红灯，这意味着该推迟的批准只会在它被重跑并通过后才触发；如果它继续红灯，就不会有批准落下，状态评论会说明情况。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 620b9b966f03d9fa3e352f7a63f3eb0ac0c1a3fc · re-run with @qwen-code /triage}