[wenshao]

What this PR does

The scenario-axes rule in item 1 of the verify-pr skill's Scope selection is now triggered by the diff, not by the central claim. When the diff changes how a Turn is cancelled, parked, taken over, recovered, approved or retried, the agent names the scenario axes before choosing the A/B instrument, whether or not that code is the central claim. If it is not, that code gets its own A/B as a secondary claim. The rest of the rule is unchanged. The measured example gains one sentence about the arm that showed the gap, and the triage workflow test pins the new trigger inside its section.

Why it's needed

#13813 put the axes rule into the plan the agent follows, keyed to "when the claim is about a turn's lifecycle". Its own evidence run (arm C) showed that this trigger never matched. The agent named Harness generation adoption as the central claim, and its reasoning never mentions the rule or which Turn was parked. Yet it did mutate the cancellation-load branches of the recovery code, varying only the checkpoint phase. So the code the rule is about was in the diff, and the agent was working on it; the trigger was keyed to how the agent framed the claim. #13813 named a diff-keyed trigger as the untested option. This PR makes that change and runs it.

Reviewer Test Plan

How to verify

1. Read item 1 of Scope selection.
2. Run npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/qwen-triage-workflow.test.js scripts/tests/verify-capture.test.js. The case "carries the maintainer-round verification techniques" passes with the new pins.
3. Non-vacuity: change any pinned phrase of the new trigger in the skill, or move the paragraph to another section unchanged. The same case fails on the assertion that names it.
4. As with docs(verify-pr): add local-round publish, follow-up, mutation and rig rules #13756 and docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813, the CI verify lane restores .qwen from the base branch, so a /verify on this PR reads the old skill and these pins show red there. That is by design; the text takes effect after merge.

Evidence (Before & After)

Arm D, this text. It used the same rig, inputs and pre-registered criterion as arms A to C in #13732 and #13813. It ran alone on the same tree, like arm C. The skill was arm C's text plus this change, byte-identical to the commit's hunk. I captured the first model request offline; it holds the new trigger, and it equals arm C's request once the skill body is swapped.

Arm	Target defect	Verdict	Assertions (pass/fail/total)	Time	Requests
A, before #13756	MISS	findings	43/1/44	2840 s	78
B, after #13756	MISS	blocked	23/4/27	2277 s	87
C, #13813	MISS	blocked	37/0/37	3387 s	101
D, this PR	CATCH	inconclusive	11/4/15	2115 s	83

• The trigger fired, and the target defect was caught.
  • The report's scenario-axes section opens with "This diff changes how a Turn is cancelled, parked, taken over and recovered, so the axes are named explicitly". It lists five axes, each with the settings the author's tests use.
  • On "which Turn parks", it copied the author's test and changed only the setup, so that Turn 1 completes before Turn 2 parks. At head this fails with expected 409 to be 200 and settledOnLoad=false, and the server logs Checkpoint names a different Turn. That is the round-9 defect.
  • Both criteria are met: the report says the cancellation takeover does not settle a park that is not the first Turn, and the failing run is in the artifact directory.
• It filed the defect as pre-existing, not as a gap in the fix.
  • It ran the same probe on base, got a 409 there too, and recorded the gap as a correction to the description ("converts every previously unbounded 'parked forever' Turn state") rather than as a numbered finding.
  • The comparison is literally true, but base has no settle path at all. So it hides that the new path covers first Turns only.
  • On base the 409 also comes from a different refusal (takeover_unrecovered), which the report calls identical.
• Other parts of the run were thinner than arm C's.
  • By the report's own account, the budget went to the A/B, the axis probe and two other findings, so no mutation matrix ran.
  • It also did not get Maven working in time, while arm C provisioned a JDK and Maven. So the Java central claim went unexecuted, and the verdict is inconclusive.
  • The merge-only red was still attributed correctly: 13/13 at HEAD^2, called a semantic merge conflict. This time the fix was not measured.

Pins. The mutation matrix from #13813 was rerun over all 14 pinned phrases of the two #13813 paragraphs, 4 of them new here. It also moved each paragraph, unchanged, into another section. It ran only the pinning case and required a failure whose message names the phrase: 16/16 killed. The unmutated case was green before and after, and the skill was restored from memory after each mutant.

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

Linux x86_64, Node 22.22.2. The triage workflow and verify-capture test files: 199 passed and 1 skipped, the same counts as main (the pins were added to an existing case). Prettier and the pre-commit ESLint pass. npm run build and npm run typecheck were not run: the change touches only skill text and a JavaScript test under scripts/tests, which they do not compile.

Risk & Scope

• Main risk or tradeoff: the trigger is wider. Any PR whose diff touches how a Turn is cancelled, parked, taken over, recovered, approved or retried now spends part of its budget on an A/B at a setting the author's tests do not use, even when its central claim is elsewhere. The always-loaded skill grows by 5 lines (19 added, 14 removed).
• Not validated / out of scope:
  • The catch is in-sample, and each arm ran once. The rule and its example were written from this PR, and the example names the very setting the agent ran: parking Turn 2 after Turn 1 completed. The run shows that the diff-keyed trigger fires and that the agent follows it. It does not show that the rule finds defects it was not written from.
  • The cost is unclear. In the one run, the extra A/B came alongside no mutation matrix. Whether that is a cost of the rule or run-to-run variance is not measured.
  • The rig differs from the lane. It has the same differences as in docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813: GitHub hosts were blocked, Chromium was not installed, and no arm has the JDK provisioning text from ci(verify): provision a Java toolchain for sdk-java PRs #13763.
  • Other platforms. macOS and Windows were not tested; the change is text only.
• Breaking changes / migration notes: none.

Linked Issues

Follow-up to #13813 and #13732. The re-run target is #13174 (round 9).

中文说明

这个 PR 做了什么

verify-pr 技能 Scope selection 第 1 项里的场景维度规则，现在由 diff 触发，而不是由中心主张触发。只要 diff 改动了 Turn 的取消、停住、接管、恢复、审批或重试方式，agent 就要在选定 A/B 手段之前列出场景维度，不论这段代码是不是中心主张。如果不是，这段代码就作为次要主张，单独做一次 A/B。规则其余部分不变。实测例子里补了一句，说明暴露这个缺口的那一臂；triage workflow 测试把新的触发条件钉在它所在的小节里。

为什么需要

#13813 把维度规则放进了 agent 遵循的计划清单，触发条件是"主张涉及 turn 的生命周期"。它自己的证据运行（C 臂）显示这个条件从没命中。agent 把中心主张定为 Harness 代际接纳，它的推理里从没提到这条规则，也没提到停住的是哪个 Turn。但它确实对恢复代码里处理取消加载的分支做了变异，只是改的是 checkpoint 阶段。也就是说，规则针对的代码就在 diff 里，agent 也在处理它；问题出在触发条件取决于 agent 怎么表述主张。#13813 把按 diff 触发列为尚未测试的选项，这个 PR 把它改过来并实际跑了一次。

评审测试计划

如何验证

1. 阅读 Scope selection 的第 1 项。
2. 运行 npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/qwen-triage-workflow.test.js scripts/tests/verify-capture.test.js。用例 "carries the maintainer-round verification techniques" 带着新钉子通过。
3. 非空性：改动技能里新触发条件中任一被钉住的短语，或把这一段原样挪到别的小节，同一用例会在点名该短语的断言上失败。
4. 与 docs(verify-pr): add local-round publish, follow-up, mutation and rig rules #13756、docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813 一样，CI verify lane 会从 base 分支恢复 .qwen，所以对本 PR 跑 /verify 读到的是旧技能，这些钉子在那里会显示为红。这是设计如此，文本在合入后才生效。

证据（前后对比）

D 臂，即本 PR 的文本。 沿用 #13732 和 #13813 中 A 到 C 臂的环境、输入和事先登记的判定标准，与 C 臂一样在同一棵树上单独运行。技能文本是 C 臂的文本加上本 PR 的改动，与提交里的改动逐字节一致。我离线抓取了首个模型请求：其中包含新的触发条件；把技能正文换回 C 的版本后，与 C 臂的请求完全相同。

臂	目标缺陷	结论	断言（通过/失败/总数）	用时	请求数
A，#13756 之前	MISS	findings	43/1/44	2840 s	78
B，#13756 之后	MISS	blocked	23/4/27	2277 s	87
C，#13813	MISS	blocked	37/0/37	3387 s	101
D，本 PR	CATCH	inconclusive	11/4/15	2115 s	83

• 触发条件生效了，目标缺陷也被抓到。
  • 报告的场景维度一节开头写着 "This diff changes how a Turn is cancelled, parked, taken over and recovered, so the axes are named explicitly"，并列出五个维度，每个都注明作者测试用的设置。
  • 在"停住的是哪个 Turn"这个维度上，它复制了作者的测试，只改准备步骤：先让 Turn 1 完成，再停住 Turn 2。这个用例在 head 上失败，报 expected 409 to be 200，settledOnLoad=false，服务端日志是 Checkpoint names a different Turn。这正是第 9 轮的缺陷。
  • 两条标准都满足：报告写明取消接管无法收尾非首个 Turn 的停住，失败的运行记录也在证据目录里。
• 它把缺陷定性为既有问题，而不是修复本身的缺口。
  • 它在 base 上跑同一个探针，同样得到 409，于是把这个缺口记成对 PR 描述的更正（描述里写的是 "converts every previously unbounded 'parked forever' Turn state"），没有列为编号的 finding。
  • 这个对比字面上成立，但 base 根本没有收尾路径，所以掩盖了"新路径只覆盖首个 Turn"这一点。
  • base 上的 409 也来自另一条拒绝路径（takeover_unrecovered），报告却说两者完全相同。
• 这次运行的其他部分比 C 臂单薄。
  • 按报告自己的说法，预算花在了 A/B、维度探针和另外两个发现上，所以没跑变异矩阵。
  • 它也没能及时装好 Maven，而 C 臂装好了 JDK 和 Maven。所以 Java 侧的中心主张没有执行，结论是 inconclusive。
  • 只在 merge 上出现的红仍然归因正确：HEAD^2 上 13/13 通过，判为语义合入冲突；但这次没有实测修复。

钉子。 重跑了 #13813 的变异矩阵，覆盖 #13813 两段里全部 14 个被钉住的短语（其中 4 个是本 PR 新增的），并把每一段原样挪到别的小节。只跑钉住它们的用例，要求失败信息点名该短语：16/16 全部被杀。未变异的用例前后都是绿，每个变异之后技能文本都从内存恢复。

测试平台

OS	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境（可选）

Linux x86_64，Node 22.22.2。triage workflow 和 verify-capture 两个测试文件：199 通过、1 跳过，与 main 相同（钉子加在已有用例里）。Prettier 和 pre-commit 的 ESLint 均通过。没有运行 npm run build 和 npm run typecheck：改动只涉及技能文本和 scripts/tests 下的一个 JavaScript 测试，这两条命令都不编译它们。

风险与范围

• 主要风险或取舍：触发范围变宽了。只要 diff 改动了 Turn 的取消、停住、接管、恢复、审批或重试方式，即使中心主张在别处，PR 也要拿出一部分预算，在作者测试没用到的设置上做一次 A/B。常驻加载的技能净增 5 行（新增 19 行，删除 14 行）。
• 未验证 / 不在范围内：
  • 这次抓到属于样本内，而且每臂只跑了一次。 规则和例子都源自这个 PR，例子点出的正是 agent 跑的那个设置：让 Turn 1 先完成再停住 Turn 2。这次运行说明按 diff 触发的条件会生效，agent 也会照做；但不能说明这条规则能找出它所来源之外的缺陷。
  • 代价尚不清楚。 在这一次运行里，多出来的 A/B 与没跑变异矩阵同时出现。这是规则的代价还是运行间的随机差异，没有测量。
  • 这套环境与 lane 有差异。 差异与 docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813 相同：屏蔽了 GitHub 主机，没有装 Chromium，所有臂都没有 ci(verify): provision a Java toolchain for sdk-java PRs #13763 的 JDK 准备文本。
  • 其他平台。 macOS 和 Windows 未测试；改动只是文本。
• 破坏性变更 / 迁移说明：无。

关联 Issue

#13813 和 #13732 的后续。重跑对象是 #13174（第 9 轮）。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[qwen-code-review-bot]

✅ Qwen Triage finished — CI landed green on 0e59ea1 and the deferred approval was posted. finalize run

✅ Qwen Triage 已完成 —— 0e59ea1 的 CI 全绿，延迟审批已提交。查看 finalize 运行

[qwen-code-review-bot]

Thanks for the PR!

Template looks good ✓

Problem: observed, not theoretical. #13813 shipped the axes rule keyed to the central claim, and the arm C re-run on #13174 R9 shows that trigger never matched — the agent named Harness generation adoption as its claim while still mutating the cancellation-load branches. The failure sits in a run record, so there is a real defect here rather than a hypothesis. One caveat I cannot close from this seat: the arm evidence is your own run log. This is an unattended CI pass, so I executed no PR-derived code, and by your own note the CI verify lane restores .qwen from base — nothing on this side re-derives arm C independently.

Direction: aligned. This is the repo's own verification tooling, the third step in a line a maintainer has already landed twice (#13756, #13813), and diff-keying is the option #13813 itself named as untested. The upstream CHANGELOG is not a useful signal for internal skill text, so I did not weigh it.

Size: not applicable — no core paths. Both files sit outside packages/*: 19 added / 14 removed in the skill markdown, 15 added / 1 removed in the workflow test. 34 additions and 15 deletions total, far under every threshold.

Approach: the scope feels right, and it matches what I would have written from the problem statement alone — re-key the one trigger sentence in place instead of adding a parallel rule or a new section. Net +5 lines of skill text. No drive-by churn; the only adjacent edit is the test comment explaining why the trigger moved, which belongs with it.

One question worth thinking about, not a blocker: the new sentence sends non-central turn-lifecycle code to "its own A/B as a secondary claim", but the budget list has no numbered slot for a secondary A/B. Item 1 is scoped to the central claim at "~half the budget", and the section closes with "Never let breadth eat the A/B". Your arm D run is where that pressure shows up — no mutation matrix, the Java claim unexecuted, verdict inconclusive. You list the cost as unmeasured in Risk & Scope, which is the honest framing; I would just note that the mandate now exists without a budget line attached, and this file's own test documents that class of gap three times over. Picking it up in the code review.

Risk: no elevated risk signals — nothing under Stage 1e's revert-correlated paths.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题： 是实际观测到的，不是理论加固。#13813 把维度规则的触发条件挂在"中心主张"上，而在 #13174 R9 上的 C 臂重跑显示这个条件从未命中——agent 把中心主张定为 Harness 代际接纳，却仍然变异了处理取消加载的分支。失败记录在运行日志里，所以这里有真实缺陷要修，而不是假设。有一点我无法在这个位置补上：各臂证据来自你自己的运行记录。这是无人值守的 CI 流程，我没有执行任何 PR 带来的代码；而且按你自己的说明，CI verify lane 会从 base 恢复 .qwen，所以这一侧无法独立复现 C 臂。

方向： 对齐。这是仓库自身的验证工具，是维护者已经两次合入的系列（#13756、#13813）的第三步，而按 diff 触发正是 #13813 自己列为"尚未测试"的那个选项。上游 CHANGELOG 对内部技能文本没有参考价值，因此我没有采纳这个信号。

规模： 不适用——未触及核心路径。两个文件都在 packages/* 之外：技能 markdown 新增 19、删除 14，workflow 测试新增 15、删除 1。合计新增 34、删除 15，远低于所有阈值。

方案： 范围合理，也和我只看问题描述时会写出的方案一致——就地改写那一句触发条件，而不是新增一条平行规则或新开一节。技能文本净增 5 行，没有顺手夹带的改动；唯一的相邻修改是解释触发条件为何移动的那段测试注释，它本就该跟在一起。

有一个值得思考的问题，不是阻塞项：新句子把"非中心主张"的 turn 生命周期代码交给"作为次要主张单独做一次 A/B"，但预算清单里没有给次要 A/B 的编号槽位。第 1 项限定为中心主张、占"约一半预算"，而本节结尾写着"Never let breadth eat the A/B"。你的 D 臂运行正是这个压力显现的地方——没跑变异矩阵、Java 主张未执行、结论 inconclusive。你在 Risk & Scope 里把代价列为未测量，这个表述是诚实的；我只是想指出，现在这条强制要求存在，却没有配套的预算行，而这个文件自己的测试已经把这一类缺口记录过三次。详见代码审查。

风险： 无升级风险信号——Stage 1e 的 revert 相关路径一个都没命中。

进入代码审查 🔍

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

_{Reviewed at 0e59ea1924d931462f80db2f3b02b7da2240be49 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Code review

Before reading the diff I wrote down what I would do from the title and the motivation alone: the trigger was keyed to how the agent frames its claim, which is unobservable from outside, so re-key it to something observable — the diff — and make sure turn-lifecycle code still gets an A/B when it is not the central claim, then pin the wording so the trigger cannot silently regress. That is what this PR does, and I did not find a simpler path. It edits one rule in place instead of adding a parallel section, and the only other edit is a test comment explaining why the trigger moved.

What I checked statically, since I executed nothing:

• The four new pins really bite. flat is verifySkill.replace(/\s+/g, ' ') (line 4545) — a normalized string, so scopeSelection is a substring and toContain does substring matching across the markdown's line wraps. All four phrases land inside the ## Scope selection … ## Method slice after the rewrite: When the diff changes how a Turn is cancelled, parked, taken over, whether or not that code is the central claim, it gets its own A/B as a secondary claim, The trigger is therefore the diff, not the claim.
• The five pre-existing docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813 pins in that slice all survive — the rewrite keeps name the scenario axes before choosing the A/B instrument, even when the instrument is the PR's own test files, parking Turn 2 after Turn 1 completed, The report lists each axis with the settings that ran and `expected 409 to be 200`.
• No orphaned pins anywhere. I grepped scripts/ and .github/ for the wording this PR deletes: turn's lifecycle and take them from return zero hits, so nothing else asserts on the removed phrasing. The other Parameterise scenarios pin (line 4929) targets the Method-section heading at SKILL.md:918, which is untouched.
• The second slice of the same section is safe. A different case, budgets evidence capture in scope selection (line 6318), slices the raw skill and asserts /^4\. \*\*Capture/m plus four item-4 phrases. The PR renumbers nothing and leaves items 2–4 byte-identical.
• verify-capture.test.js, the other file in your verify command, has no pin on Scope selection, the scenario axes, Turn 2, central claim or Parameterise. Including it is harmless, but it is not load-bearing for this change.
• The cross-reference still resolves. _Parameterise scenarios_ under wire-oracle harnesses is SKILL.md:918, and the axes it lists — "which turn is parked or cancelled (the first, or a later one after a completed turn)" — are the ones the measured example turns on.
• Formatting matches Prettier. Every new markdown line is ≤ 80 columns, and each new expect breaks exactly where Prettier would break it (the single-line forms run 81–90 chars).

One reservation, non-blocking — the secondary A/B has no budget slot. The new sentence mandates an extra A/B, but it lives inside item 1, whose heading is "A/B load-bearing proof of the central claim (always, ~half the budget)". No numbered item budgets a secondary A/B, and the section closes with "Everything else is explicitly out of scope" and "Never let breadth eat the A/B: one proven load-bearing claim beats ten unverified observations" — which reads against a mandated extra one. Your arm D is where that pressure surfaces: the budget went to the A/B, the axis probe and two findings, so no mutation matrix ran, Maven never came up, the Java central claim went unexecuted and the verdict was inconclusive. That is breadth eating the A/B, in the one run that has the data.

The instruction being inside the list is the real improvement and arm D demonstrates it, so I would not hold the PR for this. But it is worth a follow-up that either gives the secondary A/B its own numbered budget line or states what it displaces — especially since this file's own test documents that exact failure class three times over at line 6313 ("Third instance of one structural bug: an instruction placed outside the flow the agent actually follows"). To be fair to the diff: secondary claims never had a budget slot, the section intro only says "plus up to two secondary claims". What is new is mandating one.

No critical blockers, no AGENTS.md violations.

Test evidence

This is an unattended CI pass, so per the gate rules I built nothing, ran no test and executed no PR-derived code. Everything below is the PR's own CI, read through the API on the reviewed commit. Zero checks are red so far; the two that decide this PR are still running and I am not polling them.

The load-bearing detail: the test job runs test:ci:workspaces and then, only if that exits 0, test:scripts (ci.yml:787-790) — and test:scripts is vitest run --config ./scripts/tests/vitest.config.ts, the lane that executes qwen-triage-workflow.test.js and therefore these four pins. It is in_progress, so the pin result is not in yet. Test (macos-latest) and Test (windows-latest) are both skipped, so the pins are exercised on ubuntu only — consistent with your Tested-on table (Linux ✅, macOS/Windows ⚠️) and fine for a text-only change.

Your local figures — 199 passed / 1 skipped, Prettier and pre-commit ESLint green — are your claim, not evidence I reproduced. Lint & Static is still in flight, so I have not independently confirmed formatting either.

Not verified, with reasons: (1) that the new pins pass — the job that runs them has not finished; (2) Prettier/ESLint on the changed files — Lint & Static still running; (3) the 16/16 mutation-kill claim — a mutation matrix is not something I can re-run here, and it is not a CI lane.

Final CI results for 0e59ea1 (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Integration Tests (no-AK, No Sandbox)	✅ success
Lint & Static (ubuntu-latest, Node 22.x)	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Sandboxed verification

The central claim here is behavioural — that a diff-keyed trigger actually fires and drives the agent to name the axes — and neither the static review above nor CI substantiates it. A green test:scripts proves the pins match the text; it says nothing about whether an agent reading that text behaves differently.

Naming the usual lane would be noise in this specific case, so let me be precise instead: @qwen-code /verify cannot settle it pre-merge, for the reason you already documented — the CI verify lane restores .qwen from the base branch, so a run against this PR reads the old skill and the new pins show red by design. You have write access, so the lane is available to you without sponsorship; it is just the wrong instrument here.

What would actually settle it is post-merge: re-run an arm on a target the rule was not written from. Your own Risk & Scope says the catch is in-sample and each arm ran once — the rule and its measured example both come from #13174 R9, and the example names the exact setting arm D happened to probe (park Turn 2 after Turn 1 completed). Arm D shows the trigger fires and the agent follows it. It does not show the rule finds defects it was not authored from, and that is the claim carrying the merge decision. Worth stating plainly in the follow-up rather than leaving it implied.

Real-scenario testing

N/A — unattended CI run. tmux real-scenario driving is local-invocation only, and the change has no user-visible TUI surface: it is agent-skill prose plus a workflow test.

中文说明

代码审查

在看 diff 之前，我只根据标题和动机写下了自己的方案：触发条件挂在 agent 如何表述主张上，而这从外部不可观测，所以应该改挂到可观测的东西——diff——上；同时保证 turn 生命周期代码在不是中心主张时仍然拿到一次 A/B；再把措辞钉住，防止触发条件悄悄退化。这个 PR 做的正是这些，我没有找到更简单的路径。它就地把一条规则改掉，而不是新增一节平行内容；唯一的另一处改动是解释触发条件为何移动的测试注释。

以下是我静态核对的内容（没有执行任何东西）：

• 四个新钉子确实有效。 flat 是 verifySkill.replace(/\s+/g, ' ')（4545 行）——一个归一化后的字符串，所以 scopeSelection 是子串，toContain 做的是跨 markdown 换行的子串匹配。改写之后，四个短语都落在 ## Scope selection 到 ## Method 这一段里。
• docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813 原有的五个钉子全部保留，改写没有动到它们依赖的措辞。
• 没有任何孤立的钉子。 我在 scripts/ 和 .github/ 里搜了本 PR 删掉的措辞：turn's lifecycle 和 take them from 命中数为零，说明没有别处断言依赖被删的文本。另一处 Parameterise scenarios 钉子（4929 行）指向 SKILL.md:918 的 Method 小节标题，本 PR 未改动。
• 同一小节的第二处切片是安全的。 另一个用例 budgets evidence capture in scope selection（6318 行）切的是未归一化的技能文本，断言 /^4\. \*\*Capture/m 和四条第 4 项短语。本 PR 没有改编号，第 2 到第 4 项逐字节未变。
• 你验证命令里的另一个文件 verify-capture.test.js，对 Scope selection、场景维度、Turn 2、central claim、Parameterise 都没有钉子。带上它无害，但对本次改动不起作用。
• 交叉引用仍然有效。 _Parameterise scenarios_ under wire-oracle harnesses 在 SKILL.md:918，它列出的维度（"停住或取消的是哪个 turn：首个，还是完成一个之后的后续那个"）正是实测例子所依赖的。
• 格式符合 Prettier。 新增 markdown 每行都不超过 80 列，每个新 expect 的换行位置也和 Prettier 的断行一致（单行形式是 81 到 90 字符）。

一个保留意见，非阻塞——次要 A/B 没有预算槽位。 新句子强制要求多做一次 A/B，但它位于第 1 项之内，而第 1 项的标题是"中心主张的 A/B 承载性证明（必做，约占一半预算）"。没有任何编号项为次要 A/B 列预算，而本节结尾写着"其余一切都明确不在范围内"以及"Never let breadth eat the A/B：一个被证明的承载性主张胜过十条未验证的观察"——这与强制多做一次是相互矛盾的。你的 D 臂正是这个压力显现的地方：预算花在了 A/B、维度探针和另外两个发现上，于是没跑变异矩阵、Maven 没装起来、Java 中心主张未执行、结论 inconclusive。在唯一有数据的那次运行里，这就是"广度吃掉了 A/B"。

指令位于清单之内才是真正的改进，而 D 臂证明了这一点，所以我不会因此拦住这个 PR。但值得一个后续：要么给次要 A/B 一条自己的编号预算行，要么写明它挤占的是什么——尤其因为这个文件自己的测试在 6313 行已经把这一类失败记录过三次（"同一结构性 bug 的第三次出现：指令被放在 agent 实际遵循的流程之外"）。就 diff 本身公平地说：次要主张从来就没有预算槽位，本节开头只写了"外加最多两个次要主张"。新出现的东西是强制要求一个。

无关键阻塞项，无 AGENTS.md 违规。

测试证据

这是无人值守的 CI 流程，因此按门禁规则我没有构建、没有跑测试、没有执行任何 PR 带来的代码。下面全部是通过 API 读到的、该 PR 自身在被审提交上的 CI 结果。目前没有红的检查；决定这个 PR 的两个仍在运行，我不会去轮询它们。

关键细节：test 作业先跑 test:ci:workspaces，然后仅在其退出码为 0 时跑 test:scripts（ci.yml:787-790）——而 test:scripts 就是 vitest run --config ./scripts/tests/vitest.config.ts，即执行 qwen-triage-workflow.test.js、进而执行这四个钉子的那条 lane。它目前是 in_progress，所以钉子结果还没出来。Test (macos-latest) 和 Test (windows-latest) 都是 skipped，因此钉子只在 ubuntu 上被执行——这与你的测试平台表（Linux ✅、macOS/Windows ⚠️）一致，对纯文本改动也没问题。

你本地的数字——199 通过 / 1 跳过、Prettier 和 pre-commit ESLint 绿——是你的声明，不是我复现的证据。Lint & Static 仍在运行，所以格式我也还没有独立确认。

未验证项及原因：（1）新钉子是否通过——跑它们的作业还没结束；（2）改动文件上的 Prettier/ESLint——Lint & Static 仍在运行；（3）16/16 变异全杀的声明——变异矩阵不是我在这里能重跑的东西，也不是一条 CI lane。

（CI 表格见上方英文部分的标记区域，此处不重复。）

沙箱验证

这里的中心主张是行为性的——按 diff 触发的条件是否真的生效、并驱动 agent 列出场景维度——上面的静态审查和 CI 都无法证实它。test:scripts 变绿只能证明钉子与文本匹配，完全不能说明读到这段文本的 agent 行为有所不同。

在这种情况下套用常规 lane 只会是噪音，所以我说得更具体些：@qwen-code /verify 无法在合入前解决这一点，原因你已经写明——CI verify lane 会从 base 分支恢复 .qwen，所以对本 PR 跑一次读到的是旧技能，新钉子按设计显示为红。你有写权限，因此这条 lane 对你可用、不需要担保；只是在这里它是错的工具。

真正能解决它的是合入之后：在一个不是这条规则来源的目标上重跑一臂。你自己在 Risk & Scope 里写了这次抓到属于样本内、每臂只跑一次——规则和实测例子都源自 #13174 R9，而例子点出的正是 D 臂恰好探测的那个设置（让 Turn 1 先完成再停住 Turn 2）。D 臂说明触发条件会生效、agent 会照做；它不能说明这条规则能找出它所来源之外的缺陷，而这正是承载合入决定的那个主张。这一点值得在后续里写明，而不是留着让人自己推断。

真实场景测试

N/A——无人值守 CI 运行。tmux 真实场景驱动仅适用于本地调用，而且本次改动没有用户可见的 TUI 界面：它是 agent 技能文本加一个 workflow 测试。

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

_{Reviewed at 0e59ea1924d931462f80db2f3b02b7da2240be49 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Confidence: 4/5 — the trigger re-key is minimal, demonstrably needed and pinned; the one reservation is a budget ambiguity the author already half-disclosed, not a defect.

Stepping back. My independent proposal and this PR are the same shape: the trigger was keyed to how the agent frames its claim, which nothing outside the agent can observe, so keying it to the diff is the obvious correction — and it is the option #13813 itself left on the table as untested. I did not find a simpler path, and I do not think one exists. Five net lines of skill text, four assertions, no machinery added.

Does it solve something anyone cares about? The consumer is the verify lane, not an end user, but a rule that never fires is dead weight in an always-read skill — #13813 shipped it, arm C proved it inert, and leaving it would mean every future run pays the reading cost for an instruction that never applies. So yes, this earns its place.

The honest split in what I am approving. I am approving the trigger re-key, which is demonstrated: the diff shows the rule now keys off an observable property, the four pins bite (verified statically against the whitespace-normalized slice), no other test in scripts/ or .github/ asserts on the deleted wording, and the second slice of the same section is untouched. I am not certifying the generalization — that this rule finds defects it was not authored from. Arm D is in-sample, ran once, and the measured example names the exact setting it probed. The PR says so itself, which is why this is a 4 and not a 5 rather than a reason to block: the unproven part is disclosed, and the proven part is what is merging.

Six months from now I would thank the author, not curse them. A trigger keyed to the diff is checkable by anyone reading the report; one keyed to the claim required reading the agent's mind. The residual maintenance cost is the budget question from Stage 2, and it is small enough to defer.

Two things I want on the record rather than buried:

1. Give the secondary A/B a budget line, or say what it displaces. Item 1 is titled "A/B load-bearing proof of the central claim (always, ~half the budget)", the section closes with "Never let breadth eat the A/B", and now a non-central turn-lifecycle change mandates an extra A/B with no numbered slot. Arm D is the evidence: no mutation matrix, Java claim unexecuted, inconclusive. Follow-up material, not a blocker.
2. Pattern check, since this is the third in a series (docs(verify-pr): add local-round publish, follow-up, mutation and rig rules #13756, docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813, now this). I asked myself whether I am being worn down by volume. I do not think so — each of the three landed one discrete, evidence-backed rule and this one is five net lines, not an accretion. But the series is steadily growing a skill that is read on every verify run, and the budget list is exactly where that pressure will surface next. Worth a maintainer's eye on the aggregate at some point, not on this PR.

Am I being a pushover? I do not think so. I have a real reservation, I stated it in both stages, and I am not approving to avoid friction — I am approving because the load-bearing change is correct, minimal, and pinned, and because the gap I found is a disclosed scope limitation rather than a defect in the diff.

Approval deferred until CI lands green on 0e59ea1924d931462f80db2f3b02b7da2240be49. The test job — the one that runs test:scripts, and therefore these pins — was still in flight at review time, along with Lint & Static. Approving now would attest to a result that does not exist yet, so this comment carries the deferred-approval instruction and the finalize workflow will post the commit-pinned approval once every check on that SHA completes green. If anything lands red, or the head moves, it withholds and flags instead.

中文说明

信心：4/5 —— 触发条件的重挂是最小改动、确有实证需要、并且已被钉住；唯一的保留意见是作者已部分披露的预算含糊，不是缺陷。

退一步看。我的独立方案和这个 PR 形状一致：触发条件原本挂在 agent 如何表述主张上，而这在 agent 之外无法观测，所以改挂到 diff 上是显而易见的修正——而且这正是 #13813 自己列为"尚未测试"而留下的那个选项。我没有找到更简单的路径，也不认为存在。技能文本净增 5 行、四条断言，没有新增机制。

它解决的是有人在意的东西吗？消费者是 verify lane，不是终端用户；但一条永不触发的规则，在一个每次都会被读取的技能里就是纯粹的重量——#13813 把它合了进来，C 臂证明它是死的，留着它意味着今后每一次运行都要为一条永不适用的指令付出阅读成本。所以它站得住。

我要诚实区分我在批准什么。我批准的是触发条件的重挂，这一点有实证：diff 显示规则现在依赖一个可观测属性；四个钉子有效（我针对归一化后的切片做了静态核对）；scripts/ 和 .github/ 里没有别的测试断言依赖被删除的措辞；同一小节的第二处切片未被改动。我没有为普适性背书——即这条规则能找出它所来源之外的缺陷。D 臂属于样本内、只跑了一次，而实测例子点出的正是它探测的那个设置。PR 自己也这么写了，这正是它拿 4 分而不是 5 分的原因，而不是拦截它的理由：未被证明的那部分已经披露，而被证明的那部分才是这次要合入的。

半年之后我会感谢作者，而不是埋怨。挂在 diff 上的触发条件，任何人读报告都能核对；挂在主张上的触发条件，需要去猜 agent 在想什么。剩下的维护成本就是 Stage 2 里的预算问题，小到可以延后。

有两件事我要写在明处，而不是埋起来：

1. 给次要 A/B 一条预算行，或者写明它挤占什么。 第 1 项的标题是"中心主张的 A/B 承载性证明（必做，约占一半预算）"，本节结尾写着"Never let breadth eat the A/B"，而现在一次非中心的 turn 生命周期改动被强制要求多做一次 A/B，却没有编号槽位。D 臂就是证据：没跑变异矩阵、Java 主张未执行、结论 inconclusive。这是后续材料，不是阻塞项。
2. 模式检查，因为这是系列里的第三个（docs(verify-pr): add local-round publish, follow-up, mutation and rig rules #13756、docs(verify-pr): name scenario axes in scope selection and attribute merge-only reds #13813、以及本次）。我问过自己是不是被数量磨软了。我认为没有——三次各自落地了一条离散的、有实证支撑的规则，而这一次是净增 5 行，不是堆积。但这个系列确实在让一个每次 verify 运行都会读取的技能持续增长，而预算清单正是这种压力下次会显现的地方。某个时点值得维护者看一眼总量，但不必落在这个 PR 上。

我是不是在当老好人？我不认为。我有一个真实的保留意见，在两个阶段都写明了；我批准不是为了避免摩擦，而是因为承载性的改动是正确、最小且被钉住的，而我发现的缺口是一个已披露的范围限制，不是 diff 里的缺陷。

批准推迟到 CI 在 0e59ea1924d931462f80db2f3b02b7da2240be49 上全绿之后。 test 作业——也就是运行 test:scripts、进而运行这些钉子的那个——在审查时仍在执行，Lint & Static 也是。现在批准等于为一个还不存在的结果背书，所以本条留言带上了推迟批准的指令，finalize 工作流会在该 SHA 上所有检查绿了之后，提交绑定到该提交的批准。如果有检查变红，或者 head 发生移动，它会改为不予批准并标出状态。

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

_{Reviewed at 0e59ea1924d931462f80db2f3b02b7da2240be49 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

LGTM, looks ready to ship — CI landed green after the review. ✅

[yiliang114]

LGTM — docs-only change keying the verify-pr turn-axes rule to the diff. CI green on the required checks; approving per maintainer request.

[qwen-code-review-bot]

Released in v0.25.1.