docs(autofix): add an operator guide for /takeover from N - #9622
Conversation
`qwen-autofix.md` records why each line of the workflow is the way it is, indexed by code site — af-007 for the `from N` parser, af-016 for the marker it writes. That answers "why is this code shaped like this", but a maintainer deciding whether to seed a takeover has a different question: what do I type, what number do I pick, and what happens next. Nothing answered that. This adds a task-oriented sibling guide covering the problem the seed solves, how to choose N (with a table of remaining suggestion budget per seed), the three semantics that surprise people — the seed is a floor for an empty window rather than an offset added to every round, it dies with its counting window so `/retry` and a bare `/takeover` both return the counter to zero, and it is clamped strictly below the round cap while the audit record still cites the number that was typed — and the two things it deliberately does not do: seed the growth brake, or change what Critical-only keeps flowing. Every row of the accepted/rejected command table was produced by replaying the merged parser fragment verbatim, so the doc records observed behaviour rather than intent: `from 04` and `from 08` seed 4 and 8 rather than tripping octal, `from 0` engages as the explicit no-seed spelling, and `stop from 4`, a doubled space, a 3-digit number, and a prefixed or suffixed body all fail closed to no label and no seed. Cross-linked both ways: the design record's preamble now points at task-oriented guides, and the parser keeps its af-007 pointer with an operator-guide line beside it. The workflow grows by 64 bytes, which the size gate covers.
|
Thanks for the PR! Template looks good ✓ Problem: observed gap, not a theoretical one — Direction: aligned. The guide lives next to the workflow it documents and is cross-linked both ways with the existing design record. Placing it in Size: not applicable — no core paths touched (+156/−0 across two markdown files plus a one-line YAML comment). Approach: the scope feels right and minimal. The guide answers a genuinely different question from the design record ("what do I type, what number do I pick, what happens next" vs. "why is this code shaped like this"), and the only workflow edit is a 64-byte pointer comment beside the parser. Nothing to cut, no drive-by changes. Risk: no elevated risk signals — none of the revert-correlated high-risk paths are touched. Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 问题:这是已观察到的缺口,而非理论性问题 —— 方向:对齐。指南与其描述的 workflow 放在一起,并与既有设计记录双向交叉链接。放在 规模:不适用 —— 未触及核心路径(+156/−0,两个 markdown 文件加一行 YAML 注释)。 方案:范围合理且最小化。指南回答的问题与设计记录确实不同("我该敲什么、数字选多少、之后会发生什么" vs. "这段代码为什么长这样"),对 workflow 的唯一改动是解析器旁一行 64 字节的指针注释。没有可砍的部分,也没有夹带改动。 风险:无升级风险信号 —— 未命中任何与 revert 相关的高风险路径。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
|
Code review — for a docs PR the review is factual accuracy, so I verified the guide's claims against the merged workflow itself, not against the PR description:
No findings — I did not find a single inaccurate claim, and the only behavioral file edit is a comment line. CI evidence — the PR's own checks on the reviewed commit, read via the API (96 check-runs, zero failures; table below). The skipped jobs (Test on macOS/Windows, Integration Tests, build-cli) are path-filtered away for
Real-scenario testing: N/A — documentation only, no runtime behavior to drive. 中文说明代码审查 —— 对文档 PR 而言,审查的重点是事实准确性,因此我对照已合入的 workflow 本身逐条核实了指南中的断言,而不是只看 PR 描述:
无任何发现 —— 未找到一条不准确的断言;唯一涉及行为文件的改动是一行注释。 CI 证据 —— 来自该 PR 自身在受审 commit 上的检查,通过 API 读取(96 个 check-run,零失败;见下表)。被跳过的任务(macOS/Windows 的 Test、集成测试、build-cli)是 真实场景测试:N/A —— 纯文档,无运行时行为可驱动。 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — documentation-only, every factual claim verified against the merged workflow, CI fully green. Stepping back: the problem is real (a shipped command with no operator-facing page), and the answer is exactly what I would have proposed — one short task-oriented guide next to the workflow, cross-linked with the design record that already carries the rationale, plus a pointer comment beside the parser so the docs are discoverable from the code. The diff is minimal (zero deletions, no unrelated edits), the guide concentrates on precisely the semantics that surprise people — the floor-not-offset behavior, the seed dying with its window, the clamp — and the PR is honest about its one structural weakness: nothing enforces freshness if the parser or constants change, with the 中文说明置信度:5/5 —— 纯文档改动,所有事实断言均已对照已合入的 workflow 核实,CI 全绿。 退一步看整体:问题是真实的(已合入的命令却没有面向操作者的文档),而方案也正是我会提议的形态 —— 一份简短的、面向任务的指南放在 workflow 旁边,与已承载实现理由的设计记录双向交叉链接,再在解析器旁加一行指针注释让文档可以从代码侧发现。diff 最小化(零删除、无夹带改动),指南聚焦于恰恰最容易让人意外的语义 —— 种子是下界而非偏移、种子随窗口消亡、收敛行为 —— 并且对自身唯一的结构性弱点保持坦诚:若解析器或常量变更,没有任何机制强制文档同步,主要防线是紧贴解析器的 — Qwen Code · qwen3.8-max Reviewed at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
|
@qwen-code /takeover |
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管:autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突,直到移除标签或达到轮次上限。移除 |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查——无阻断问题。 建议见行内评论。
未检查(工具限制,非阻断):the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| only Critical findings, `Request changes` reviews, failed checks, and base | ||
| conflicts drive code changes; everything else is recorded in a |
There was a problem hiding this comment.
[Suggestion] This list of what keeps driving code changes in Critical-only mode omits in-budget maintainer feedback, which contradicts the guide's own "What it does not do" section (~line 106) and the workflow. qwen-autofix.yml implements a per-author budget (CRITICAL_ONLY_HUMAN_BATCHES: '2'): the actionable-review filter keeps in-budget maintainer feedback even when Critical-only is on, and only bot/over-budget feedback is deferred ("Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail"). I ran the workflow's two jq programs on a fixture to confirm: with the author in budget, a maintainer's non-Critical review lands under ACTIONABLE (not DEFERRED); over budget, it flips. As written, a reader concludes that after round 5 all their ordinary comments are dead-on-arrival, when in fact in-budget maintainer feedback keeps flowing. Suggest adding the item, e.g. "only Critical findings, Request changes reviews, in-budget maintainer feedback, failed checks, and base conflicts drive code changes". The same omission appears in "Picking N" (~line 60) — align both with the ~line-106 list.
中文说明
这份"Critical-only 模式下仍会驱动代码改动"的清单遗漏了预算内的维护者反馈,与指南自身"What it does not do"一节(约第 106 行)及 workflow 相矛盾。qwen-autofix.yml 实现了按作者计的预算(CRITICAL_ONLY_HUMAN_BATCHES: '2'):即使开启 Critical-only,可执行评审过滤器仍保留预算内的维护者反馈,只延迟机器人/超预算的反馈。我用 workflow 的两个 jq 程序在夹具上核实:作者在预算内时,维护者的非 Critical 评审落在 ACTIONABLE(不被延迟);超预算时则翻转。按现写法,读者会误以为第 5 轮后自己所有普通评论都不再生效,而事实上预算内的维护者反馈仍会驱动改动。同样的遗漏也出现在"Picking N"(约第 60 行),两处清单都应与约第 106 行的清单对齐。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| Critical findings, `Request changes` reviews, failed checks, and base-conflict | ||
| resolution keep flowing regardless of the seed. |
There was a problem hiding this comment.
[Suggestion] Same omission as the intro (~lines 12-14): this list of what keeps flowing omits in-budget maintainer feedback. The workflow's per-author budget (CRITICAL_ONLY_HUMAN_BATCHES: '2') keeps in-budget maintainer feedback actionable even in Critical-only mode — verified by running the workflow's jq filters on a fixture — and the guide's "What it does not do" section (~line 106) already lists it. Suggest: "Critical findings, Request changes reviews, in-budget maintainer feedback, failed checks, and base-conflict resolution keep flowing regardless of the seed."
中文说明
与引言(约第 12-14 行)相同的遗漏:这份"仍会放行"的清单缺少预算内的维护者反馈。workflow 的按作者预算(CRITICAL_ONLY_HUMAN_BATCHES: '2')使预算内的维护者反馈在 Critical-only 模式下仍可执行(已用 workflow 的 jq 过滤器在夹具上核实),且指南"What it does not do"一节(约第 106 行)已将其列出。建议补上该项。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| The literal prefix must match `@qwen-code /takeover` byte-for-byte and the tail | ||
| must be a bare 1–2 digit integer. Leading and trailing whitespace on the comment | ||
| is trimmed; nothing else is tolerated, and anything unrecognized fails closed to |
There was a problem hiding this comment.
[Suggestion] "Leading and trailing whitespace on the comment is trimmed" overstates the tolerance. The trim pipeline (tr -d '\r' → line-oriented sed 's/^[[:space:]]*//' → $(...)) strips leading spaces/tabs on the first line and all trailing whitespace, but a leading blank line survives — the captured prefix then fails the byte-for-byte match and the command fails closed with no reply at all. I ran the verbatim parser (yml lines 424-447) on both inputs: @qwen-code /takeover from 4 → CMD=[add] TAKEOVER_FROM=[4]; the same command with one leading blank line → CMD=[], silent. So an operator who hits Enter once before the command gets silence the guide did not prepare them for — and the accepted/rejected table has no row for it. Suggest tightening the sentence:
| The literal prefix must match `@qwen-code /takeover` byte-for-byte and the tail | |
| must be a bare 1–2 digit integer. Leading and trailing whitespace on the comment | |
| is trimmed; nothing else is tolerated, and anything unrecognized fails closed to | |
| The literal prefix must match `@qwen-code /takeover` byte-for-byte and the tail | |
| must be a bare 1–2 digit integer. Leading spaces and tabs on the first line, and | |
| all trailing whitespace, are trimmed — but a blank line before the command is | |
| not, so it must start the comment's first line. Nothing else is tolerated, and | |
| anything unrecognized fails closed to |
中文说明
"Leading and trailing whitespace on the comment is trimmed" 说过头了。裁剪管道(tr -d '\r' → 按行的 sed 's/^[[:space:]]*//' → $(...))只会去除首行的前导空格/制表符和全部尾部空白,但前导空行会保留——捕获的前缀随后无法通过逐字节匹配,命令会静默失败、没有任何回复。我用逐字抽取的解析器(yml 第 424-447 行)分别验证:@qwen-code /takeover from 4 → CMD=[add] TAKEOVER_FROM=[4];前面多一个空行的相同命令 → CMD=[],无任何回应。因此在命令前多按一次回车的操作者只会得到指南没有预告的沉默,且接受/拒绝表中也没有这一行。建议收紧这句措辞。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| The same refusals apply — a non-`main` base, `autofix/skip`, and a fork without | ||
| maintainer-edit access are all declined out loud. |
There was a problem hiding this comment.
[Suggestion] This enumerates 3 of the 4 out-loud engage refusals. It omits the fork-author gate (qwen-autofix.yml ~lines 1786-1795): a fork PR whose author lacks write+ on this repository is also declined out loud. That gate is distinct from the maintainer-edit one named here — it fires even with "Allow edits from maintainers" checked, keys on the PR author's permission rather than the sender's, and its only remedy is adoption. Since the sentence reads exhaustive ("...are all declined out loud") and the three named refusals all have operator-side remedies, the list implicitly teaches "clear these three and engagement succeeds" — which is false for a typical external-fork PR, where the refusal message becomes the operator's first hint. Suggest:
| The same refusals apply — a non-`main` base, `autofix/skip`, and a fork without | |
| maintainer-edit access are all declined out loud. | |
| The same refusals apply — a non-`main` base, `autofix/skip`, a fork without | |
| maintainer-edit access, and a fork whose author lacks write+ on this repository | |
| are all declined out loud. |
中文说明
此处只列出了 4 个"出声拒绝"中的 3 个,遗漏了 fork 作者门禁(qwen-autofix.yml 约第 1786-1795 行):若 fork PR 的作者在本仓库无 write+ 权限,同样会被出声拒绝。该门禁与此处提到的 maintainer-edit 门禁不同——即便勾选"Allow edits from maintainers"也会触发,依据的是 PR 作者(而非发送者)的权限,且唯一补救是收养(adoption)。由于这句读起来是穷尽的("...are all declined out loud"),且已列出的三个拒绝都有操作者可自行解决的办法,清单隐含"清掉这三项即可接管成功"——对典型的外部 fork PR 并不成立,那条拒绝消息会成为操作者得到的第一个提示。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈(第 1/100 轮)。改动内容与我反驳保留之处如下: Round summary — PR #9622 (address review round)All four findings are automated-reviewer [Suggestion] items about the accuracy of the new operator guide Findings and dispositions
Changes
Verification
中文说明本轮总结 — PR #9622(处理评审轮)四条发现均为自动评审器针对新增操作指南 发现与处置
改动
验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审;第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
Deferred under the convergence posture (round 2, not a blocker) — recorded, not requested in this round:
.github/workflows/qwen-autofix-round-seed.md:5 — [review] New guide's af-007/af-016 links are a third, un-pinned participant in the link graph.github/workflows/qwen-autofix-round-seed.md:4 — [review] Intro promises rationale "behind each gate" but omits the af-017 link for the re-arm gate
中文说明
已审查——无阻断问题。 建议见行内评论。
未检查(工具限制,非阻断):the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
收敛姿态下延后(第 2 轮,非阻断)——已记录,本轮不要求修改:共 2 条(原文未翻译,列表见上方英文部分)。
— qwen3.8-max via Qwen Code /review (v0.21.15)
| | `@qwen-code /takeover from 100` | **nothing** — 3 digits rejected | | ||
| | `@qwen-code /takeover from 4` | **nothing** — double space | | ||
| | `please @qwen-code /takeover from 4` | **nothing** — must start the comment | | ||
| | blank line, then the command | **nothing** — must start the first line | |
There was a problem hiding this comment.
[Suggestion] R2-1: The rejection this new table row documents — a blank line before the command is not trimmed, so the command must start the comment's first line — is pinned by no test. Both behavioral replay harnesses in scripts/tests/qwen-autofix-workflow.test.js (near lines 5850 and 5991) feed exclusively single-line bodies, so nothing notices if the trim changes.
Today the rejection rests on sed trimming whitespace line-wise, so a leading blank line survives into the exact-match comparison. If someone later "improves" the trim — e.g. strips leading empty lines before matching — a body like \n\n@qwen-code /takeover from 9 would engage and seed while the whole suite stays green, shipping behaviour that contradicts the operator guide this PR publishes. A mutation replay confirmed the flip: stripping leading blank lines turns \n\n@qwen-code /takeover from 4 from rejected (|) into engaged (add|4) with every existing test still passing.
// in the fail-closed array of `behaviorally parses the takeover round seed`
// (scripts/tests/qwen-autofix-workflow.test.js, ~line 6030):
'\n\n@qwen-code /takeover from 4',
'@qwen-code /takeover from 4\nthanks',Both shapes pass at HEAD and catch that mutation.
中文说明
本行表格新记录的拒绝行为 —— 命令前的空行不会被裁剪,因此命令必须位于评论的第一行 —— 目前没有任何测试固定。scripts/tests/qwen-autofix-workflow.test.js 中的两个行为回放测试台(约第 5850 行与第 5991 行)喂入的全部是单行文本,所以裁剪逻辑若发生变化,不会有任何测试察觉。
当前这一拒绝依赖于 sed 逐行裁剪空白,使得行首空行得以保留到精确比较阶段。若日后有人"改进"裁剪逻辑(例如在匹配前先去掉行首空行),形如 \n\n@qwen-code /takeover from 9 的评论就会触发接管并播种,而整个测试套件依旧全绿 —— 最终发布的行为将与本 PR 发布的操作者指南相矛盾。变异回放确认了这一翻转:去掉行首空行后,\n\n@qwen-code /takeover from 4 从拒绝(|)变为生效(add|4),且现有全部测试仍然通过。
建议按上方代码块在 fail-closed 数组中补充这两个多行形态;它们在 HEAD 上通过,并能捕获上述变异。
— qwen3.8-max via Qwen Code /review (v0.21.15)
There was a problem hiding this comment.
Verified — and deferred to the follow-up queue (thread stays open).
Probes at the current head confirm both claims:
- Both proposed bodies —
'\n\n@qwen-code /takeover from 4'and'@qwen-code /takeover from 4\nthanks'— fail closed (|) in the seed replay harness on current code, so they pass at HEAD when added to the fail-closed array. - Mutating the trim to strip whitespace-only lines before matching (
sed -e '/^[[:space:]]*$/d') flips the first body from rejected (|) to engaged (add|4) with every other takeover test still green — without these cases, the suite cannot see a change that contradicts the guide this PR publishes.
Why deferred instead of implemented here: the only home for the fix is scripts/tests/qwen-autofix-workflow.test.js, but this PR's footprint is .github/workflows/ only. The round gate is deny-by-default on footprint — an expansion into an area the PR never touched is surfaced (and rejected outright when footprint enforcement is set to reject). Per loop policy, a verified finding whose fix lives outside the PR's footprint is deferred to this PR's follow-up queue rather than implemented in it; nothing is lost at merge.
中文说明
已核实——现转入后续处理队列(deferred findings queue),本线程保持打开。
在当前 HEAD 上的探针确认了两点论断:
- 两个建议的评论体——
'\n\n@qwen-code /takeover from 4'与'@qwen-code /takeover from 4\nthanks'——在当前代码的种子回放测试台中均按失败关闭(fail closed,结果为|)处理,因此加入 fail-closed 数组后在 HEAD 上通过。 - 将裁剪逻辑变异为在匹配前去除纯空白行(
sed -e '/^[[:space:]]*$/d')后,第一个评论体从拒绝(|)翻转为生效(add|4),而其余全部 takeover 测试依旧全绿——若不补充这两个用例,测试套件无法察觉与本 PR 发布的指南相矛盾的行为变化。
为何推迟而不在本 PR 实现:修复只能落在 scripts/tests/qwen-autofix-workflow.test.js,而本 PR 的足迹仅为 .github/workflows/。轮次门对足迹采用默认拒绝(deny-by-default)策略——改动 PR 从未触及的区域会被门提示(若足迹强制设为 reject 则直接拒绝)。按本循环的策略,修复位于 PR 足迹之外的已核实发现将推迟到本 PR 的后续处理队列,而不在本 PR 内实现;合并时不会丢失任何内容。
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下: Autofix review round — no code changesPR: #9622 · Reviewed head: Dispositions
VerificationProbes only — every probe edit was temporary and fully restored;
No 中文说明Autofix 审查轮次——无代码变更PR: #9622 · 被审查的 HEAD: 处置结果
验证仅执行探针——所有探针改动均为临时性质且已完全还原;
无需运行 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
|
@qwen-code /triage |
|
Sandboxed verification: ❌ not passed — findings reported (agent verdict) - workflow run Ran the PR in an isolated, token-free container: A/B against the base build, mock-free harness assertions, targeted gates. Advisory evidence for human reviewers — not a review, an approval, or a CI check. Scripted assertions: 114 passed · 1 failed · 115 total Flakiness gate: not applicable — no runnable changed test files (0 out-of-scope file(s) noted in the log) 中文 — 判定:❌ 不通过 · 报告了发现(agent 判定)沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码(与 base 构建 A/B 对照、无 mock harness 断言、定向门禁)。仅作为评审证据,不构成评审、批准或 CI 检查。 脚本断言:114 通过 · 1 失败 · 115 总计 抖动门:不适用 — no runnable changed test files (0 out-of-scope file(s) noted in the log) Verification reportPR 9622 — deep verificationVerdict: 中文摘要
Central claim and A/BCentral claim (docs PR): Secondary claims: (1) the PR is behavior-neutral (a 64-byte comment-only YAML delta); (2) the gates the PR cites pass, and are live. The A/B oracle is a replay: the parser fragment (
Witnesses: The base-vs-head replay is the load-bearing proof for a docs PR: the guide documents the merged workflow, so the oracle ran against Reviewer Test Plan, walked step by step. (1) "spot-check its claims against main — every number and quoted string": done in scripted form — tables 1–3 above; every constant ( FindingsF1 (minor) — one guide quote is a paraphrase presented as verbatim. The guide's re-arm sentence quotes the ack as “the round counter restarts at 7 — rounds already spent on this PR”, but the actual Non-findings, checked and bounded. (a) The clamp never fires while takeover is engaged (parser caps seeds at 99 < cap 100); it fires when the label is later removed and the cap drops to 10 — exactly what the code comment and the guide's "cap is 100 while Not covered
MethodologyEnvironment: the CI verify container ( Flakiness gate logEvidence imagesHarness scripts and raw logs are in the workflow run artifacts (7-day retention). — Qwen Code · sandboxed verification |
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下: Autofix review round — no changes neededReviewed all feedback newer than the last evaluation (2026-08-21T05:13:10Z). Nothing requires a code change this round, point by point:
Diff growth this window is 6 source / 0 test lines against budgets of 400/400, so no growth audit or critical-only constraints apply. No commit was made; the branch head is unchanged. 中文说明Autofix 评审轮次 —— 无需改动已审阅上次评估(2026-08-21T05:13:10Z)之后的全部反馈。本轮无需任何代码改动,逐点说明如下:
本窗口内的 diff 增长为源码 6 行 / 测试 0 行,预算为 400/400,因此不触发增长审计或仅处理 Critical 的约束。 本轮未提交任何改动;分支头部保持不变。 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
|
Released in v0.22.0. |




What this PR does
Adds
.github/workflows/qwen-autofix-round-seed.md, a task-oriented operator guide for@qwen-code /takeover from N, and cross-links it with the existing design record.qwen-autofix.mdis a design record: it holds the verbatim prose that moved out of the YAML, indexed by code site, and it already covers this feature — af-007 for the parser and af-016 for the marker the engage ack writes. That answers "why is this code shaped like this". A maintainer looking at a long-running PR and deciding whether to seed the takeover has a different question — what do I type, what number do I pick, and what happens after — and nothing answered it.The guide covers: the problem the seed solves; how to choose N, with a table of remaining suggestion budget per seed; the three semantics that surprise people — the seed is a floor for an empty window rather than an offset added to every round, it dies with its counting window so
@qwen-code /retryand a bare@qwen-code /takeoverboth return the counter to zero, and it is clamped strictly below the round cap while the audit record still cites the number that was typed; and the two things it deliberately does not do — seed the growth brake, or change what Critical-only keeps flowing.Cross-linked both ways. The design record's preamble now says it is indexed by code site and points at task-oriented guides; the parser in the YAML keeps its
af-007pointer and gains anOperator guide →line beside it. The workflow grows by 64 bytes.Why it's needed
from Nshipped in #9321 with its rationale documented but no usage documentation anywhere. The command's audience is maintainers who mostly will not read a workflow file to discover that a parameter exists, and the parts most likely to be got wrong are exactly the parts the rationale comments do not address — that re-arming silently drops the seed, that the growth brake is a separate brake the seed does not touch, and that anything other than the exact accepted spelling fails closed with no partial effect and no error comment.Placed in
.github/workflows/next to the workflow and its design record rather than underdocs/:docs/_meta.tspublishes onlyusersanddevelopers, and/takeoveris a repo-internal command that collaborators on this repository can issue. It does not belong in the published product documentation.Reviewer Test Plan
How to verify
Read the guide, then spot-check its claims against
main— every number and quoted string in it was taken from the merged workflow, not from the PR that introduced the feature.The accepted/rejected command table is the part most likely to rot, so it was not written from the regex. The parser fragment was extracted verbatim from the merged
qwen-autofix.yml(theCMD=''…RETRY_REQ=''block inroute·Decide phases), combined with the marker-write condition fromtakeover-command, and every row was replayed:All ten rows in the doc match.
from 04/from 08seeding 4 and 8 rather than tripping octal is the10#canonicalisation from #9321's R2 round, and the guide documents the observed result rather than the intent.The constants the guide quotes were re-read from
origin/mainafter this branch was rebased onto it:CRITICAL_ONLY_AFTER_ROUND: '5',MAX_ROUNDS: '10',TAKEOVER_MAX_ROUNDS: '100',GROWTH_BUDGET_SRC_LINES/GROWTH_BUDGET_TEST_LINESat 400, both clamp sites, and the re-arm and Critical-only audit wordings.There is also one piece of production evidence, from #9491.
@qwen-code /takeover from 4was issued there on 2026-08-20; the engage ack rendered "starts at 4 … after 1 more change-producing round(s)" and carried<!-- autofix-round-start 4 -->on its own line below a byte-identical<!-- takeover-ack engaged -->. The next scan then wrote<!-- autofix-eval ts=… acted=false round=4 win=2026-08-20T12:43:35Z -->, i.e. the read path computed the seeded value with no eval markers in the window and a no-change round materialised it into a durable marker. Partial: that PR merged before any change-producing round ran, so the brake itself was not exercised in production — the round-5 transition and the Critical-only engagement are still only covered by the unit tests from #9321.Gates, run on this branch after rebasing onto the current
main:Evidence (Before & After)
N/A — documentation only, plus a 64-byte comment pointer in the workflow. No runtime behaviour changes.
Tested on
Environment (optional)
N/A — no runtime involved; workflow-contract tests and linters only.
Risk & Scope
CRITICAL_ONLY_AFTER_ROUNDwill not fail a test because this file went stale. Theaf-007pointer sitting directly above the parser is the main defence.from Nonly, not the wider takeover command surface (stop,/retry, the labels, the caps), which still has no operator-facing page. The one behavioural line in this PR is a comment; the feature itself is unchanged.Linked Issues
Follows #9321, which introduced
@qwen-code /takeover from N.中文说明
这个 PR 做了什么
新增
.github/workflows/qwen-autofix-round-seed.md:面向操作的@qwen-code /takeover from N使用指南,并与既有的设计记录做了双向交叉链接。qwen-autofix.md是一份设计记录:它保存从 YAML 中迁出的逐字原文,按代码位置索引,并且已经覆盖了本特性 —— af-007 对应解析器,af-016 对应接管回执写入的标记。那回答的是"这段代码为什么长这样"。而一位维护者面对一个长期运行的 PR、在决定要不要给接管种子时,问的是另一个问题 —— 我该敲什么、数字选多少、之后会发生什么 —— 此前没有任何文档回答它。指南涵盖:种子解决的问题;如何选 N,并附每个种子对应剩余 suggestion 预算的对照表;最容易让人意外的三条语义 —— 种子是空窗口的下界而非叠加到每一轮的偏移量、它随所属计数窗口一同消亡(因此
@qwen-code /retry与裸@qwen-code /takeover都会把计数归零)、以及它被收敛在轮次上限之下而审计记录仍引用你实际输入的数字;还有它刻意不做的两件事 —— 不种子化增长刹车,也不改变 Critical-only 放行的内容。双向交叉链接:设计记录的前言现在说明自身按代码位置索引,并指向面向任务的指南;YAML 中的解析器保留其
af-007指针,并在旁边新增一行Operator guide →。workflow 因此增加 64 字节。为什么需要
from N随 #9321 发布时带了完整的实现理由,却没有任何使用文档。该命令的受众是维护者,他们多半不会为了发现"存在一个参数"去读 workflow 文件;而最容易搞错的部分,恰恰是那些理由注释没有覆盖的 —— 重新武装会静默丢弃种子、增长刹车是种子管不到的另一道刹车、以及除精确写法外任何输入都会 fail closed,既不产生部分效果也不会有任何报错评论。放在
.github/workflows/下、紧邻 workflow 与其设计记录,而不是放到docs/下:docs/_meta.ts只发布users与developers两个页面,而/takeover是本仓库协作者可用的仓库内部命令,不应进入对外发布的产品文档。评审者测试计划
如何验证
阅读该指南,然后对照
main抽查其中的断言 —— 文中每一个数字与引用字符串都取自已合入的 workflow,而非引入该特性的那个 PR。接受/拒绝命令表是最容易腐化的部分,因此它不是照着正则写出来的。解析器片段是从已合入的
qwen-autofix.yml中逐字抽取的(route·Decide phases里从CMD=''到RETRY_REQ=''的那一段),再拼上takeover-command中的标记写入条件,然后逐行回放:文档中的十行全部吻合。
from 04/from 08得到 4 与 8 而非触发八进制,来自 #9321 第二轮评审加入的10#归一化;指南记录的是实测结果而非设计意图。指南引用的常量,是在本分支变基到
origin/main之后重新读取的:CRITICAL_ONLY_AFTER_ROUND: '5'、MAX_ROUNDS: '10'、TAKEOVER_MAX_ROUNDS: '100'、GROWTH_BUDGET_SRC_LINES/GROWTH_BUDGET_TEST_LINES均为 400,两处 clamp 位置,以及重新武装与 Critical-only 审计的措辞。另有一份来自 #9491 的生产证据。2026-08-20 在该 PR 上执行了
@qwen-code /takeover from 4;接管回执渲染为"starts at 4 … after 1 more change-producing round(s)",并在字节完全一致的<!-- takeover-ack engaged -->下方单独一行携带<!-- autofix-round-start 4 -->。随后的扫描写入了<!-- autofix-eval ts=… acted=false round=4 win=2026-08-20T12:43:35Z -->,即读取侧在窗口内没有任何 eval 标记的情况下算出了种子值,并由一个无改动轮次把它固化为持久标记。但这只是部分验证:该 PR 在任何产生改动的轮次运行之前就已合入,因此刹车本身并未在生产中被触发 —— 第 5 轮的跨越与 Critical-only 的实际生效,目前仍只由 #9321 的单元测试覆盖。门禁,在本分支变基到当前
main之后运行:证据(改动前后)
N/A —— 纯文档,外加 workflow 中一处 64 字节的注释指针。无运行时行为变更。
测试平台
环境(可选)
N/A —— 不涉及运行时;仅 workflow 契约测试与各类 linter。
风险与范围
CRITICAL_ONLY_AFTER_ROUND并不会因为本文件过时而导致测试失败。紧贴解析器上方的af-007指针是主要防线。from N,不覆盖更广的接管命令面(stop、/retry、各标签、各上限),后者仍然没有面向操作者的页面。本 PR 中唯一涉及行为文件的改动是一行注释;特性本身未做任何变更。关联 Issue
承接 #9321,该 PR 引入了
@qwen-code /takeover from N。