feat(ci): route non-functional PRs to a triage-only review path - #9193
feat(ci): route non-functional PRs to a triage-only review path#9193yiliang114 wants to merge 8 commits into
Conversation
Small behavior-neutral maintenance PRs (internal renames, formatting, comment/JSDoc fixes) currently go through the full multi-stage triage, review, and verification pipeline. Add a conservative Stage 1f route in the triage skill that classifies such PRs (100%-certainty bar, risky surfaces excluded, unattended runs only) and marks them with the existing status/on-hold label, and make the automatic PR-review lane check the live label before invoking the model. Explicit /review asks and review_requested always bypass the skip.
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ Problem: real and quantified, not theoretical — #7411 counted 26 fork PRs of ≤40 lines among the 300 most recent, each paying the full three-stage triage + automated review cost for changes that carry no observable risk. The overhead is observed, and the issue scopes the fix precisely: route only behavior-neutral maintenance, keep everything behavior-changing on the full path. Direction: aligned. This is the repo's own review-capacity plumbing — the change stays entirely inside the automation layer (workflow + skill docs + contract tests), no product surface, and it honours the issue's non-goals: nothing blocks merging, and a maintainer can always pull a full review. Size: no core paths touched. 115 production lines (22 workflow + 93 skill docs) vs 205 test lines — tests outweigh the behavior change, which is the right shape for a routing rule whose failure mode is a silently skipped review. Approach: the scope feels right. The two moving parts are exactly what the problem needs: a conservative classifier contract in the triage skill (Stage 1f), and a live-label gate in the automatic review lane. Routing lives where the diff is already being read, the gate fails open, and explicit asks bypass it entirely. I don't see a materially simpler version of this. Risk: no elevated risk signals — no Stage 1e high-risk paths matched, no core modules, no runtime code. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题： 真实且有量化数据，不是理论性问题——#7411 统计了最近 300 个 PR 中有 26 个不超过 40 行的 fork PR，它们没有任何可观测风险，却都要走完整的三阶段 triage + 自动评审流程。开销是实际观测到的，issue 也精确划定了范围：只路由行为中性的维护性改动，行为变化类 PR 仍走完整流程。 方向： 对齐。这是仓库自身的评审容量管道——改动完全在自动化层（workflow + skill 文档 + 契约测试），不涉及产品面，并遵守 issue 的非目标：不阻塞合并，maintainer 随时可以发起完整评审。 规模： 未触及核心路径。生产代码 115 行（22 行 workflow + 93 行 skill 文档），测试 205 行——测试比行为改动本身还重，对于一个失败模式是"悄悄跳过评审"的路由规则来说，这是正确的形态。 方案： 范围合理。两个改动点恰好是问题所需的：triage skill 里的保守分类契约（Stage 1f），以及自动评审通道里的实时标签门。路由放在本来就要读 diff 的地方，门失败时放行（fail open），显式请求完全绕过。没有实质更简的版本。 风险： 无升级风险信号——未命中 Stage 1e 高风险路径，不涉及核心模块，不涉及产品运行时代码。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewThe implementation matches what I'd have proposed: classify where the diff is already being read (triage), signal with an existing label, and gate only the automatic lane on a live label query. I verified the integration points against the current workflow rather than taking the diff's word for it:
One design question worth a conscious maintainer call, non-blocking: the label doesn't track the commit it was applied at. Triage fires on Minor, no action needed: Not verified: the end-to-end live wiring (triage labels a real trivial PR → the automatic lane skips on the next event) — that is only observable in production after merge, no sandboxed lane can A/B a workflow YAML, and the author proposes post-merge back-testing against the 26 historical small fork PRs. The author also reports red-before/green-after for the skip test and 255/255 passing — author's claim; the pending CI run below is what confirms it. Testing evidence — the PR's own CI at
|
| Check | Conclusion |
|---|---|
Classify PR |
✅ success |
Dependency CVE audit |
✅ success |
Desktop Shell (ubuntu-22.04) |
✅ success |
Desktop Shell (windows-2022) |
✅ success |
Post Coverage Comment (ubuntu-latest, 22.x) |
✅ success |
Secret scan (TruffleHog) |
✅ 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，失败项排在最前。
This is a CI-automation change with no user-visible surface, so no real-scenario testing applies on this unattended run.
中文说明
代码审查：实现与我独立给出的方案一致——在本来就要读 diff 的 triage 环节做分类，用已有标签传递信号，且只对自动评审通道加门。我对照现有 workflow 逐一核实了集成点，而不是只看 diff 自述：
- 门的位置正确。 跳过逻辑紧跟事件分发分支之后，此处
AUTO_REVIEW=true仅对应自动pull_request_target通道（不含review_requested）。dispatch、/review评论和 review-requested 事件根本不会走到标签查询——其中两个新测试专门锁定了这一点。 - 在
set -euo pipefail下仍然失败放行（fail open）。 标签读取失败时if条件为假，评审照常执行。grep -Fxq精确匹配（status/on-hold-extended不会触发跳过，有测试锁定）；should_run=false+exit 0与该步骤已有的提前退出形态一致，下游所有步骤本就受should_run门控。 - 令牌与时序成立。
review-pr作业带issues: write权限，GITHUB_TOKEN可读标签；opened/synchronize路径要经过约 10 分钟的delay-automatic-review环境门后才解析上下文——triage 早已完成打标，任何残余竞态都只会导致"照常评审"，不会误跳过。 - 测试执行的是真实逻辑。 workflow 测试用 stub
gh执行从 YAML 解析出的真实Resolve PR contextbash；新增代码不引入任何${{ }}表达式（无新注入面），所用 fs/process 导入均已在文件顶部存在。skill 契约测试锁定的是保守性本身——失败关闭措辞、仅无人值守范围、排除清单、100 行上限、只用已有标签、Stage 2 前终止。
一个值得 maintainer 有意识拍板的设计问题（非阻塞）：标签不记录打标时的提交。 triage 只在 opened/ready_for_review 触发、不随 synchronize 重跑，因此 PR 被路由为 triage-only 之后，若后续推送了实质性提交，自动评审通道会一直跳过，直到有人移除 status/on-hold 或执行 /review。剩余的安全网仍然存在——fork 安全预检、完整 CI、以及 bot 从不批准 triage-only PR（合并仍需人工看最终 diff）——但如果在意这种漂移，选项是：把它文档化为预期行为（有新提交就摘标签），或在 head 越过被 triage 的 SHA 后视该路由为过期。
次要、无需处理：status/on-hold 同时表示"暂停"并且是 stale 机器人的豁免标签——这两处耦合 PR 正文已说明，且 #7411 本身就建议复用该标签。新评论模板的签名与本文件当前签名一致；若未来 bot 签名升级，此模板需同步改一行。
未验证： 端到端实时链路（triage 给真实的小 PR 打标 → 自动通道在下一事件跳过）——只有合并后才能在生产环境观测，没有任何沙箱通道能对 workflow YAML 做 A/B，作者建议合入后用 26 个历史小 fork PR 回测。作者还报告了 skip 测试先红后绿、255/255 通过——这是作者陈述，以下进行中的 CI 才是确认依据。
测试证据：f51482fb 上无红色检查。运行两个新契约测试文件的 ubuntu 单元测试仍在进行；CI 落定后 finalize 流程会更新上方表格。所有跳过均为设计内的门控而非缺测：macOS/Windows 具名作业只在合并队列运行（ci.yml 注明 ubuntu 是 PR 的快速信号），precheck-pr 仅针对 fork，tmux/verify 通道按触发方式门控。Security Checks、TruffleHog、依赖 CVE 审计和两个 Desktop Shell 作业已通过。
本 PR 为 CI 自动化改动、无用户可见界面，无人值守运行不适用真实场景测试。
— Qwen Code · qwen3.8-max
Reviewed at f51482fb9438a60b45d8ffd4eac016a2db18a05d · re-run with @qwen-code /triage
|
Confidence: 4/5 — verified end to end against the live workflow; the one reservation is a design question for the maintainer, not a defect. My independent baseline for this problem was exactly what the PR does: route where the diff is already being read, signal with an existing label, gate only the automatic lane on a live label query, fail open, and never stand in the way of an explicit ask. The PR matches that and goes further where it counts — the tests don't paraphrase the rules, they execute the real context-resolution bash with a stubbed Everything in the diff earns its place: 22 lines of workflow gate, 93 lines of classifier contract, 205 lines of tests. No drive-by edits, no scope creep, and the author already documented the sharp edges themselves (the stale-bot exemption coupling, the #9153 merge-order overlap, the decision not to back-test pre-merge). The one reservation, named in Stage 2 and worth a deliberate maintainer call rather than blocking on: the label doesn't record the SHA it was applied at, and triage doesn't re-fire on pushes — so substantive commits pushed after a triage-only routing skip the automatic lane until a human removes the label or runs In six months this reads as two small gates with sharp tests, not machinery. Approving — with the ubuntu unit suite still in progress on this commit, the approval lands once CI is green rather than now. The ubuntu suite is the only pending 中文说明置信度：4/5 —— 已对照线上 workflow 端到端核实；唯一保留意见是一个留给 maintainer 的设计问题，而非缺陷。 我对这个问题的独立方案与 PR 完全一致：在本来就读 diff 的地方做路由、用已有标签传递信号、只对自动通道加实时标签门、失败放行、绝不阻拦显式请求。PR 做到了这些，并在关键处更进一步——测试不是转述规则，而是用 stub diff 中每一处改动都物有所值：22 行 workflow 门、93 行分类契约、205 行测试。没有顺手改动、没有范围蔓延，作者自己也已经把锋利边角写清楚了（stale 机器人豁免的耦合、与 #9153 的合并顺序交叠、合入前不做回测的取舍）。 唯一的保留意见已在 Stage 2 点名，值得 maintainer 有意识拍板而非因此阻塞：标签不记录打标时的 SHA，triage 也不随推送重新触发——因此 triage-only 路由之后推送的实质性提交，会一直跳过自动评审通道，直到有人摘掉标签或执行 六个月后回看，这是两道带锋利测试的小门，而不是一台机器。准备批准——由于该提交上的 ubuntu 单元测试仍在进行，批准将待 CI 变绿后落地，而不是现在。 ubuntu 套件是唯一未完成的 — 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. ✅
|
Closeout from resolve-pr-comments automation: Changed: no product code. The failed review job stopped during Checkout base branch, so I requested a failed-job rerun. Verified: rerun request was accepted by GitHub. Pending: rerun CI and automatic review on the current head. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: reverse audit — did not converge within the reverse-audit round cap of 5.
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：反向审计——在 5 轮的反审轮数上限内未收敛。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.12)
The status/on-hold label is applied once at open time by Stage 1f and is never invalidated, so a PR earning it with a benign v1 would silently skip the automatic review lane for every later push of arbitrary content — a fork contributor could smuggle behaviour changes past review with zero classifier error. - Stage 1f now also posts a marker comment pinning the skip to the triaged head SHA (`<!-- qwen-triage on-hold sha=<HEAD_SHA> -->`) - the skip fires only while that pin matches the LIVE head: a push after triage moves the head (triage does not re-run on synchronize), so the new diff goes to the review lane; a manually applied parked label has no marker and never skips; an unreadable head fails open like the label read - pin the new behaviour with workflow step tests (matching pin skips, stale pin reviews, marker-less label reviews, unreadable head fails open) and a Stage 1f doc pin for the marker instruction
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not reviewed: reverse audit — stopped at the round cap of 5 without converging (rounds 3 and 4 reported findings; round 5 was dry).
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
仅完成部分审查，审查缺口已披露。
未审查：reverse audit — stopped at the round cap of 5 without converging (rounds 3 and 4 reported findings; round 5 was dry)。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.12)
# Conflicts: # scripts/tests/qwen-pr-review-workflow.test.js
|
Closeout: merged latest main to clear the conflict, then fixed triage-only marker validation to filter bot-authored marker comments, avoid pipefail+grep false negatives, and give the test shell a HOME. Verified qwen-pr-review workflow test, Prettier, and diff check. Pending: status/on-hold label policy remains a maintainer decision. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Not explored to full depth (tool budget reached): "agent 6c": none — no check was cut short..
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
未探索到全部深度（达到工具调用预算）："agent 6c"：none — no check was cut short.。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.12)
Round-3 review of the triage-only route (#7411): - The marker match no longer pipes `printf '%s\n' "$MARKERS"` into `grep -Fq`: under `set -o pipefail`, grep -q exits at the first match and closes the pipe, printf dies on EPIPE with 141, and pipefail surfaces the producer failure as FALSE — with >64 KB of bot comment bodies (busy PRs) the skip silently never fired while the summary claimed the opposite. The marker check is now a pipe-free `[[ "$MARKERS" == *"..."* ]]` pattern match; the label check keeps exact-line semantics via a herestring (`grep -Fxq <<< "$LABELS"`, no producer pipe). Regression test: the stub emits a 300 KB bot comment body alongside the marker and the skip must still fire — mutation-verified red against the old shape. - Pin the author-filter jq expression verbatim in the positive and forged-marker tests (the stub does its own filtering, so the '.user.login' substring alone let select(.user.login != "") and dropped-login mutants survive). - Stage 1f posts its pin marker through the author-scoped upsert-bot-comment.sh (lookup marker is the SHA-less prefix) instead of a bare `gh pr comment`, so a re-run PATCHes the existing marker instead of minting a byte-identical duplicate. - The triage-only Stage 1 wording qualifies the "no review verdict will post" promise for the ready_for_review race (the review lane starts immediately on that action while triage takes minutes).
|
Closeout from resolve-pr-comments: Changed: aligned the triage workflow test with the current upsert-bot-comment marker flow, fixing the exact Ubuntu failure assertion. Verified: targeted qwen-triage workflow vitest for the failed assertion, Prettier, and diff check passed. Note: the full local script file still has unrelated long-running verify tests that timed out under the 5s local timeout. Pending: post-push CI/review. |
doudouOUC
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not explored to full depth (tool budget reached): "You are review agent 6a — Agent 6a: Undirected audit —…": none — all checks completed within budget.; "You are review agent 6b — Agent 6b: Undirected audit — 3…": 无 — 我在预算内完成了所有检查。; "You are review agent 1a — Agent 1a: Line-by-line…": 无.
Not reviewed: reverse audit — no auditor was launched with a prompt this skill builds — the pass that hunts what the rest of the review missed ran, if at all, without the method its brief carries.
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
仅完成部分审查，审查缺口已披露。
未探索到全部深度（达到工具调用预算）："You are review agent 6a — Agent 6a: Undirected audit —…"：none — all checks completed within budget.；"You are review agent 6b — Agent 6b: Undirected audit — 3…"：无 — 我在预算内完成了所有检查。；"You are review agent 1a — Agent 1a: Line-by-line…"：无。
未审查：反向审计——没有审计 agent 是用本 skill 构建的 prompt 启动的——负责搜寻评审其余部分遗漏问题的这道工序，即便运行过，也缺失了 brief 承载的方法。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— deepseek-v4-flash via Qwen Code /review (v0.21.11)
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-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查——无阻断问题。 建议见行内评论。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| re-enables review automatically (#9219): | ||
|
|
||
| ```bash | ||
| gh pr edit "$PR_NUMBER" --repo "$REPO" --add-label 'status/on-hold' |
There was a problem hiding this comment.
[Suggestion] The automatic status/on-hold label inherits a permanent stale-bot exemption and is never removed. stale.yml lists status/on-hold in exempt-pr-labels (exempting the 60-day stale mark and the 30-day auto-close that follows), and its message frames the label as one "Maintainers may apply". Stage 1f now applies it via CI to every behaviour-neutral maintenance PR — the high-volume class — and no code anywhere removes it (repo-wide sweep; the workflow's own comment says "nothing ever removes it"). Before this diff the label was manual-only, so the exemption is newly reachable for an automated, recurring PR class. — Failure scenario: a routed PR whose author goes quiet is skipped by the review lane (by design) AND never marked stale AND never auto-closed — permanently invisible to every automated nudge, accumulating open indefinitely where it previously died at ~90 days; a maintainer scanning the backlog can no longer distinguish a deliberately parked PR from an auto-routed one. — Suggested fix: decide deliberately — strip the label in the review lane's "not pinned to the live head" branch, or route via a dedicated label not in exempt-pr-labels, or at minimum document the exemption consequence in Stage 1f and pin that choice in the triage test.
中文说明
[Suggestion] 自动添加的 status/on-hold 标签会继承 stale 机器人的永久豁免，且永远不会被移除。stale.yml 将 status/on-hold 列在 exempt-pr-labels 中（豁免 60 天 stale 标记及随后的 30 天自动关闭），其文案把该标签描述为 "Maintainers may apply"（maintainer 可添加）的标签。Stage 1f 现在会通过 CI 对所有行为中性的维护性 PR（正是高频类别）打上该标签，且全仓库没有任何代码移除它（repo 级扫描；workflow 自己的注释也写明 "nothing ever removes it"）。在此 diff 之前该标签仅手动添加，因此这一豁免首次对自动化、反复出现的 PR 类别生效。— 失败场景：被路由 PR 的作者如果不再活跃，该 PR 既被评审通道跳过（设计如此），也永远不会被标记 stale、不会被自动关闭——对所有自动提醒机制永久隐形，会无限期累积为 open 状态，而过去这类 PR 约 90 天就会被清理；maintainer 扫描积压时，也无法再区分"故意暂挂"与"自动路由"。— 建议修复：有意识地决策——在评审通道的 "not pinned to the live head" 分支移除该标签，或改用不在 exempt-pr-labels 中的专用标签，或至少在 Stage 1f 中写明豁免后果并在 triage 测试中锁定该选择。
— qwen3.8-max via Qwen Code /review (v0.21.12)
There was a problem hiding this comment.
Not fixed — needs a maintainer decision (policy, not mechanics). The concern is real: Stage 1f now applies status/on-hold automatically to a high-volume PR class, inheriting stale.yml's permanent exemption with no removal path. Options: (a) have the workflow remove the label when the pin is invalidated by a new push (pairs with the existing re-enable semantics, but then the exemption is moot anyway while pinned); (b) scope stale.yml exempt-pr-labels or add a max-age for automated on-hold; (c) accept the exemption as the intended behaviour for behaviour-neutral PRs and document it in the label description. Each trades off stale-bot hygiene vs. the route's purpose; picking here would be a product call, so leaving open.
| if grep -Fxq 'status/on-hold' <<< "$LABELS"; then | ||
| HEAD_SHA="$(gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR_NUMBER}" --jq '.head.sha' 2>/dev/null || true)" | ||
| MARKERS="$(gh api "repos/${GITHUB_REPOSITORY}/issues/${PR_NUMBER}/comments?per_page=100" --paginate --jq '.[] | select(.user.login == "github-actions[bot]" or .user.login == "qwen-code-ci-bot") | .body' 2>/dev/null || true)" | ||
| if [ -n "$HEAD_SHA" ] && [[ "$MARKERS" == *"qwen-triage on-hold sha=${HEAD_SHA}"* ]]; then |
There was a problem hiding this comment.
[Suggestion] No cross-artifact identity test ties the marker's writer side (the skill-doc template + upsert prefix) to this reader. The marker grammar exists as independent hand-written copies — this match pattern, the skill-doc printf template, and fixture copies in both test files — and qwen-pr-review-workflow.test.js never loads the skill doc, so each suite is self-consistent with its own fixtures. The round-2 thread accepted this concern; its claimed fix commit 3c8741a1a does not exist in the repository (gh api → 422; absent from branch history), and no cross-artifact assertion exists at HEAD. — Failure scenario: a future one-sided rename of the marker prefix (skill doc + triage-side fixture updated) passes BOTH suites, and in production the posted marker no longer satisfies this match → every triage-routed PR silently takes the full-review lane forever — the optimization this PR exists for is a permanent no-op, and the only signal ("not pinned to the live head") is indistinguishable from a normal stale pin. Fail-open direction, so maintainability rather than safety. — Suggested fix: add one cross-artifact assertion — e.g. in qwen-pr-review-workflow.test.js, extract the marker prefix from the skill doc's upsert-bot-comment.sh invocation and assert this match pattern contains it (and vice versa); or collapse the writer side into a shared script so the format lives in one place.
中文说明
[Suggestion] 没有任何跨工件一致性测试把 marker 的写侧（skill 文档模板 + upsert 前缀）与这个读侧绑定。marker 语法以多份独立手写副本存在——此匹配模式、skill 文档中的 printf 模板、两个测试文件中的 fixture 副本——且 qwen-pr-review-workflow.test.js 从不加载 skill 文档，因此两个套件各自与自己的 fixture 自洽。第 2 轮的讨论已接受该问题；其声称的修复提交 3c8741a1a 在仓库中不存在（gh api → 422；不在分支历史中），HEAD 处也没有任何跨工件断言。— 失败场景：未来对 marker 前缀的单侧改名（更新 skill 文档 + triage 侧 fixture）可以让两个套件全部通过，而生产中发布的 marker 不再满足此匹配 → 每个被 triage 路由的 PR 都会悄悄永远走完整评审通道——本 PR 赖以存在的优化变成永久空操作，且唯一信号（"not pinned to the live head"）与正常的 pin 过期无法区分。方向是失败放行，因此是可维护性问题而非安全问题。— 建议修复：新增一个跨工件断言——例如在 qwen-pr-review-workflow.test.js 中从 skill 文档的 upsert-bot-comment.sh 调用里提取 marker 前缀，断言此匹配模式包含它（反向亦然）；或把写侧收敛到一个共享脚本，让格式只存在于一处。
— qwen3.8-max via Qwen Code /review (v0.21.12)
There was a problem hiding this comment.
Not addressed this round — deferred to the next one. The cross-artifact identity test (loading the skill doc from qwen-pr-review-workflow.test.js and tying the writer-side marker grammar to the workflow reader pattern) needs its own design pass; noting it here so it is not lost. Meanwhile the retag in 5c02b55 at least makes the provenance citations traceable.
| expect(section).toContain('always take the full path'); | ||
| }); | ||
|
|
||
| it('keeps risky surfaces out of the triage-only route', () => { |
There was a problem hiding this comment.
[Suggestion] Six further fixes accepted in round-2 threads are claimed in author replies as "Fixed in 3c8741a1a" — a commit that does not exist in this repository (gh api → 422; absent from branch history) — and all remain absent at HEAD: (1) a test supplying a matching marker with the label ABSENT (pinning the label gate) — the label-absent test at qwen-pr-review-workflow.test.js:2722 supplies no marker, so the dropped-label-gate mutant survives and is dangerous (probe: label absent + genuine marker → should_run=false vs original should_run=true); (2) the exclusion probes here still use the vacuous 'fix' substring (which also matches unrelated Stage 1f text like "comment/JSDoc fixes") instead of "not a fix type", and lack "core module paths" / "package manifests" (probe: deleting the fix-type precondition bullet from the skill doc leaves this suite green); (3) the classification-contract clauses "source-comment or JSDoc-only edit" / "no token-level semantic change" are pinned in no test; (4) the per-endpoint ghFailOn fixture is absent — the head-SHA pulls-call fail-open guard (workflow line 563) is asserted by no test; (5) the unattended-scope test pins only GITHUB_EVENT_NAME=issues (an event that can never run this route), not pull_request_target — the only event on which Stage 1f can actually execute; (6) runContextStep cleanup is still 11 post-assertion rmSync calls with no finally block. — Failure scenario: each cited deletion/relaxation passes the suite while weakening a contract round 2 asked pinned, and the closeout comments record these threads as done — the discrepancy is invisible until someone edits this code. — Suggested fix: re-apply the six accepted fixes from the round-2 closeout, or state in each thread that the item is being dropped.
中文说明
[Suggestion] 第 2 轮讨论中另外六项已被接受的修复，在作者回复中声称 "Fixed in 3c8741a1a"——该提交在本仓库中不存在（gh api → 422；不在分支历史中）——且 HEAD 处全部缺失：(1) 提供"标签缺失但 marker 匹配"的测试（锁定标签门）——qwen-pr-review-workflow.test.js:2722 处的无标签测试未提供 marker，因此"删除标签门"突变体存活且危险（probe：无标签 + 真实 marker → should_run=false，原始实现为 should_run=true）；(2) 此处的排除项探针仍使用空洞的 'fix' 子串（它同样匹配 Stage 1f 的无关文本，如 "comment/JSDoc fixes"），而非 "not a fix type"，且缺少 "core module paths" / "package manifests"（probe：从 skill 文档删除 fix 类型前置条款后该套件仍为绿色）；(3) 分类契约条款 "source-comment or JSDoc-only edit" / "no token-level semantic change" 没有任何测试锁定；(4) 缺少按端点失败的 ghFailOn fixture——head-SHA pulls 调用的失败放行守卫（workflow 第 563 行）没有任何测试断言；(5) 无人值守范围测试只锁定了 GITHUB_EVENT_NAME=issues（该事件永远无法运行此路由），未锁定 pull_request_target——Stage 1f 唯一可能执行的事件；(6) runContextStep 的清理仍是 11 处断言之后的 rmSync 调用，没有 finally 块。— 失败场景：上述每一种删除/放宽都能通过套件，同时削弱第 2 轮要求锁定的契约，且收尾评论已把这些线程记录为完成——在有人修改这段代码之前，这一差异是不可见的。— 建议修复：重新应用第 2 轮收尾中的六项已接受修复，或在每个线程中声明放弃该项。
— qwen3.8-max via Qwen Code /review (v0.21.12)
There was a problem hiding this comment.
Partially addressed in 5c02b55 — item (1) is fixed: the label-absent test now supplies a genuine bot marker matching the live head, so dropping the label gate flips the outcome and fails. Provenance of the phantom commit: 3c8741a1a exists in the local worktree reflog (created by an earlier round) but was reset away and never pushed — the six round-2 fixes were genuinely lost, which is why they are absent at HEAD. Items (2)-(6) (vacuous fix-substring probes + missing core-module/manifest exclusions, unpinned classification clauses, missing ghFailOn fixture for the head-SHA read, pull_request_target unattended-scope pin, finally-block cleanup) are NOT re-applied in this round — tracked for the next patrol round rather than claimed fixed. Leaving this thread open.
- skill doc: post the on-hold marker BEFORE applying the label and fail closed if the upsert fails (a label without the pin would skip review for every future push) - skill doc: mirror the ready_for_review race hedge into the ZH half of the Stage 1f comment (both halves post in one comment) - retag the misplaced (#9219) provenance citations to (#9193) at the remaining sites (workflow, step summary, skill doc, tests); the marker-pin assertion itself was already aligned in 1430f84 - tests: supply genuine bot markers in the lookalike-label and label-absent skip-gate tests so the exact-label and label gates are each the only failing gate (kills the relaxed-match / dropped-gate mutants); pin the step-level GH_TOKEN env on 'Resolve PR context'
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-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查——无阻断问题。 建议见行内评论。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-code-pr-review.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| Fail closed, in this order: post the marker FIRST. If the upsert fails | ||
| (retries exhausted), stop — do not apply the label and do not post the | ||
| triage-only outcome. A label without the pin would skip review for every |
There was a problem hiding this comment.
[Suggestion] R5-2: The fail-closed rationale states "A label without the pin would skip review for every future push", but the gate shipped in this same PR requires the label AND a bot marker pinned to the live head — with a label but no matching pin it falls through to the review lane ("not pinned to the live head", workflow lines 561-570), and the test 'a manually applied on-hold label without a marker never skips (#9193)' pins exactly that. The sentence describes the pre-pin label-only behaviour and contradicts three statements in this feature's own docs: "the review lane honours the label only while this pin matches the live head" (this section), "A manually applied status/on-hold carries no marker and never skips" (the outcome template), and the workflow's own comment. — Failure scenario: a maintainer or agent diagnosing why an on-hold PR is (or is not) reviewed reads this paragraph and models the gate backwards — e.g. concludes the marker-first ordering cannot matter because the gate demands the pin anyway, and drops it, reopening the window where a failed upsert still posts the outcome comment's promise while the review lane runs. The marker-first instruction itself is correct; only the stated harm is wrong.
Suggested rewording (covers the full sentence, lines 305-309):
Fail closed, in this order: post the marker FIRST. If the upsert fails
(retries exhausted), stop — do not apply the label and do not post the
triage-only outcome. A label without the pin never skips — the review
lane requires both — but it still marks the PR as parked while the
automatic lane keeps reviewing, and the outcome comment's promise would
post over a review that still happens. Post the pin first so the promise
and the state agree.
中文说明
[Suggestion] R5-2：此处的失败关闭理由写道 "A label without the pin would skip review for every future push"（没有 pin 的标签会让之后每次推送都跳过评审），但本 PR 同时新增的门控要求标签且 bot marker pin 到 live head——只有标签而没有匹配 pin 时会落入评审通道（"not pinned to the live head"，workflow 561-570 行），测试 'a manually applied on-hold label without a marker never skips (#9193)' 正是锁定了这一行为。该句描述的是加 pin 之前仅凭标签的旧行为，并与本功能自身文档中的三处表述矛盾："the review lane honours the label only while this pin matches the live head"（本节）、"A manually applied status/on-hold carries no marker and never skips"（结论评论模板）以及 workflow 自己的注释。— 失败场景：排查某个 on-hold PR 为何被/未被评审的 maintainer 或 agent 读到此段后会对门控建立错误模型——例如认为 marker 优先的顺序无关紧要（反正门控要求 pin）而删掉它，重新打开"upsert 失败却仍发布结论评论承诺"的窗口。marker 优先的指令本身正确，错的只是所述危害。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| LABELS="$(gh api "repos/${GITHUB_REPOSITORY}/issues/${PR_NUMBER}/labels?per_page=100" --paginate --jq '.[].name' 2>/dev/null || true)" | ||
| if grep -Fxq 'status/on-hold' <<< "$LABELS"; then |
There was a problem hiding this comment.
[Suggestion] R5-4: The gate's fail-open paths leave no diagnostic that distinguishes an API failure from a negative result: a failed label read (2>/dev/null || true) yields empty LABELS, grep -Fxq fails, and no summary line is written at all — the skip's death by API failure, rate-limit window, or token regression is undiagnosable from run artifacts, and the only symptom is the continued full-review capacity burn this PR exists to eliminate. And when the comments read fails while labels read fine, the gate reports "status/on-hold present but not pinned to the live head ()" — the same line as a genuine stale pin, asserting a pin mismatch that was never observed and sending the investigation the wrong way. The fail-open behaviour itself is correct and tested; only the silence/misreport is at issue. — Failure scenario: a transient API outage silently disables every skip for a window, or a future permission regression disables them permanently, and whoever investigates is handed either nothing or a false pin-staleness claim.
Suggested shape — capture each read's exit status and distinguish failure from empty result:
LABELS="$(gh api ".../labels?per_page=100" --paginate --jq '.[].name' 2>/dev/null)" \
|| echo "::warning::on-hold label read failed — running the review lane (fail open)" >> "$GITHUB_STEP_SUMMARY"
# ...and for the marker read, when it failed:
# "marker comments unreadable — running the review lane"
# instead of "not pinned to the live head"中文说明
[Suggestion] R5-4：门控的失败放行路径没有留下任何能区分"API 失败"与"查询结果为空"的诊断信息：标签读取失败时（2>/dev/null || true）LABELS 为空、grep -Fxq 失败，且完全不写任何 summary 行——跳过功能因 API 故障、限流窗口或 token 权限回退而失效时，从运行产物中无法诊断，唯一症状就是本 PR 要消除的完整评审开销持续存在。而当标签可读、评论读取失败时，门控会输出 "status/on-hold present but not pinned to the live head ()"——与真正的 pin 过期是同一句话，断言了一个从未观察到的 pin 不匹配，把排查引向错误方向。失败放行行为本身正确且有测试覆盖；问题只在于静默/误报。— 失败场景：一次瞬时 API 故障在窗口期内悄悄禁用所有跳过，或未来的权限回退使其永久失效，而排查者拿到的要么是空白、要么是虚假的 pin 过期断言。建议按上面的形状捕获每次读取的退出码，把"读取失败"与"结果为空"区分开。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| ```bash | ||
| printf '%s' '<!-- qwen-triage on-hold sha=<HEAD_SHA> -->' > /tmp/qwen-triage-on-hold-marker.md | ||
| .github/scripts/upsert-bot-comment.sh "$REPO" "$PR_NUMBER" 'qwen-triage on-hold sha=' /tmp/qwen-triage-on-hold-marker.md | ||
| gh pr edit "$PR_NUMBER" --repo "$REPO" --add-label 'status/on-hold' |
There was a problem hiding this comment.
[Suggestion] R4-1: (round-4 finding, still stands — the author deferred it to a maintainer policy decision) The automatic status/on-hold label inherits stale.yml's permanent exempt-pr-labels exemption and is never removed by any automation, so the high-volume class of Stage-1f-routed PRs can never be auto-closed while the label stands, and the label's documented "parked" meaning is overloaded — a maintainer reading it can no longer distinguish "parked by a human" from "routed by triage". — Failure scenario: triage-routed PRs accumulate that the stale bot can never close; the label's signal value degrades exactly as its volume grows. Options recorded in the round-4 thread: (a) a dedicated label for the triage-only route without the stale exemption, (b) a removal path (e.g. strip the label when the route's pin goes stale after a push), or (c) keep the reuse and accept the coupling — already documented in the Stage 1f prose as the interim state. Re-reporting so the decision stays visible; this needs a maintainer call, not more code churn.
中文说明
[Suggestion] R4-1：（第 4 轮发现，仍然成立——作者已将其留给 maintainer 做策略决策）自动打上的 status/on-hold 标签会继承 stale.yml 中 exempt-pr-labels 的永久豁免，且没有任何自动化会移除它，因此被 Stage 1f 路由的大量 PR 在标签存在期间永远不会被自动关闭，该标签文档中的"暂挂"语义也被重载——maintainer 看到它时无法再区分"人为暂挂"与"triage 路由"。— 失败场景：被 triage 路由的 PR 不断累积且 stale 机器人永远无法关闭；标签的信号价值恰恰在其使用量增长时衰减。第 4 轮线程中记录的选项：(a) 为 triage-only 路由使用不带 stale 豁免的专用标签；(b) 增加移除路径（例如推送后 pin 过期时摘掉标签）；(c) 保持复用并接受该耦合——Stage 1f 文中已将其作为过渡状态写入文档。重新上报是为了让该决策保持可见；这需要 maintainer 拍板，而非更多代码改动。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| if grep -Fxq 'status/on-hold' <<< "$LABELS"; then | ||
| HEAD_SHA="$(gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR_NUMBER}" --jq '.head.sha' 2>/dev/null || true)" | ||
| MARKERS="$(gh api "repos/${GITHUB_REPOSITORY}/issues/${PR_NUMBER}/comments?per_page=100" --paginate --jq '.[] | select(.user.login == "github-actions[bot]" or .user.login == "qwen-code-ci-bot") | .body' 2>/dev/null || true)" | ||
| if [ -n "$HEAD_SHA" ] && [[ "$MARKERS" == *"qwen-triage on-hold sha=${HEAD_SHA}"* ]]; then |
There was a problem hiding this comment.
[Suggestion] R4-4: (round-4 finding, still stands — the fix was deferred to this round) No cross-artifact identity test ties the marker's writer side (the skill-doc template + upsert prefix in pr-workflow.md) to this reader pattern. Verified at HEAD: the marker grammar exists as independent hand-copied literals — the reader-side fixtures in qwen-pr-review-workflow.test.js restate the writer format, and neither test file reads the other's artifact (no pr-workflow.md reference in the review test, no workflow reference in the triage test). — Failure scenario: a maintainer renames the marker prefix on the writer side with the triage test updated in lockstep; this gate keeps matching the old prefix forever — every Stage 1f PR logs "status/on-hold present but not pinned to the live head" and gets a full review. The optimisation silently dies with a plausible-looking summary line and no alert (safe direction, but exactly the silent no-op that R5-4 makes undiagnosable). This repo already paid for this drift class: upsert-bot-comment.sh's header exists because per-step copies of the same protocol had drifted. Suggested fix: one cross-artifact test — extract the match pattern from the real 'Resolve PR context' step's run text, load the writer template from the skill doc, render it with a sample SHA, and assert each side contains the other's literal prefix.
中文说明
[Suggestion] R4-4：（第 4 轮发现，仍然成立——修复被推迟到本轮）没有任何跨工件身份测试把 marker 的写入侧（pr-workflow.md 中的 skill 文档模板 + upsert 前缀）与这里的读取侧模式绑定。已在 HEAD 核实：marker 语法以互相独立的手工复制字面量存在——qwen-pr-review-workflow.test.js 的读取侧 fixture 只是复述写入侧格式，两个测试文件互不读取对方的工件（review 测试中无 pr-workflow.md 引用，triage 测试中无 workflow 引用）。— 失败场景：maintainer 重命名写入侧的 marker 前缀并同步更新 triage 测试；此门控将永远匹配旧前缀——每个 Stage 1f PR 都会记录 "status/on-hold present but not pinned to the live head" 并走完整评审。优化会带着看似合理的 summary 行悄悄失效且无任何告警（方向安全，但正是 R5-4 所指那种无法诊断的静默空转）。本仓库已为这类漂移付过代价：upsert-bot-comment.sh 的头部注释正是因为同一协议的各步骤副本发生了漂移。建议修复：一个跨工件测试——从真实 'Resolve PR context' step 的 run 文本中提取匹配模式，从 skill 文档读入写入侧模板，用示例 SHA 渲染，并断言两侧互相包含对方的字面前缀。
— qwen3.8-max via Qwen Code /review (v0.21.12)
| it('keeps risky surfaces out of the triage-only route', () => { | ||
| const section = stage1f(); | ||
| for (const excluded of [ | ||
| 'fix', |
There was a problem hiding this comment.
[Suggestion] R4-8: (round-4 finding, partially addressed) Of the round-2 fixes once claimed for the then-phantom commit 3c8741a1a, four are verified absent at this HEAD: (1) the exclusion loop still under-pins the contract — the 'fix' probe is vacuously satisfied as a substring, and the 'core module paths' / 'package manifests' probes are missing; (2) the unattended-scope test does not pin pull_request_target, the only event on which Stage 1f can execute; (3) no test pins the classification contract verbatim ('token-level semantic change', 'sends the whole PR to the full path'); (4) runContextStep's per-test rmSync cleanup still runs after the assertions instead of in a finally block (the new block's tests at 2635/2656/2668). Each item has a recorded author deferral in its round-2 thread. — Failure scenario: each missing pin is a surviving mutant — a future edit deleting the 'core module paths' exclusion sentence, changing the scope event, or weakening the classification wording ships green; and a failing assertion leaks its temp dir precisely when forensics matter most. Either land the four deferred items or record them in a follow-up issue so the deferrals are tracked rather than dropped.
中文说明
[Suggestion] R4-8：（第 4 轮发现，部分已解决）在曾归于幽灵提交 3c8741a1a 的第 2 轮修复中，经核实在当前 HEAD 仍缺失四项：(1) 排除项锁定循环对契约的锁定不足——'fix' 探针作为子串空洞成立，且缺少 'core module paths' / 'package manifests' 探针；(2) 无人值守范围测试未锁定 pull_request_target——Stage 1f 唯一可能执行的事件；(3) 没有测试逐字锁定分类契约（'token-level semantic change'、'sends the whole PR to the full path'）；(4) runContextStep 的每测试 rmSync 清理仍在断言之后执行而非 finally 块中（新测试块 2635/2656/2668 处）。每一项在其第 2 轮线程中都有作者记录的推迟说明。— 失败场景：每个缺失的锁定都是一个存活的变异体——未来删除 'core module paths' 排除句、更改范围事件或弱化分类措辞的改动都能绿灯通过；而断言失败时恰好会在最需要取证现场的情况下泄漏临时目录。请要么落地这四项推迟的修复，要么记录到后续 issue 中，使推迟被跟踪而非遗失。
— qwen3.8-max via Qwen Code /review (v0.21.12)
What this PR does
This PR teaches the automation to match review depth to risk for the smallest, most mechanical contributions, as requested in #7411. The triage skill gains a new Stage 1f route: when an unattended triage run sees a PR it can certify with 100% confidence as behavior-neutral maintenance (internal renames, formatting, comment/JSDoc-only edits), it posts the usual Stage 1 summary, applies the existing
status/on-holdlabel, and stops — no Stage 2 code review, no Stage 3 verdict, no approval. The automatic PR-review lane inqwen-code-pr-review.ymlthen checks the live labels before invoking the model and skips the automatic run whilestatus/on-holdis present. Nothing blocks merging: a maintainer can always pull a full review with@qwen-code /review(explicit triggers never hit the label check), and removing the label re-enables the automatic lane on the next push.Why it's needed
Today every PR — including one-line comment fixes — goes through three-stage triage, multiple automated review passes, tests, and several long bot comments. #7411 counted 26 fork PRs of 40 lines or fewer among the 300 most recent PRs whose orchestration and model cost exceeded the value and risk of the change, while occupying review capacity needed by higher-risk PRs. The issue explicitly scopes this as routing behavior-neutral maintenance to a lighter outcome, keeping behavior-changing small PRs (bug fixes, user-facing docs/CLI help, links, system prompts, security/data-loss/compatibility) on the full path.
Reviewer Test Plan
How to verify
The route is deliberately conservative, and the tests pin that conservatism rather than paraphrasing it:
npm run test:scripts -- scripts/tests/qwen-pr-review-workflow.test.js scripts/tests/qwen-triage-workflow.test.js— 255/255 pass. The newqwen pr review triage-only skip (#7411)block executes the realResolve PR contextbash with a stubghand asserts: automatic review is skipped only when the LIVE label query returnsstatus/on-hold(exact match —status/on-hold-extendeddoes not skip); a failed label read fails OPEN and still reviews; explicit/reviewcomments andreview_requestednever skip and never even query labels. Verified red-before/green-after: with the workflow change stashed, the skip test fails.triage skill non-functional routing (#7411)block pins the Stage 1f contract words: fail-closed fallback ("when in doubt, take the full path"), unattended-only scope, the exclusion list (fix titles, core paths, workflows, manifests/lockfiles, schema/generated files, model-visible text, user-facing docs/CLI help, broken links, high-risk paths), the 100-production-line cap, the existing-label-only rule, and the terminal exit before Stage 2.actionlinton the modified workflow: clean. Prettier on the changed files: clean.Evidence (Before & After)
N/A — CI-automation change, no user-visible/TUI surface.
Tested on
Environment (optional)
Vitest workflow/skill contract tests plus actionlint; no runtime or sandbox involved.
Risk & Scope
/review,review_requested, and dispatch always run, and no merge blocker is added (per the issue's non-goals)./reviewcost discussion in /review skill consume large amount of tokens #6264; the approval-policy proposal in Proposal: remove automated PR approvals — triage gates only, approval authority returns to maintainers #9182.stale.yml, which already exemptsstatus/on-holdPRs from staleness — a triage-only PR will not be auto-closed by the stale bot while the label stands. Also note open PR feat(review): wire --resume through /review, review run and the CI retry #9153 touches the same workflow file (different area:--resumewiring); a rebase may be needed depending on merge order.Linked Issues
Fixes #7411
中文说明
这个 PR 做了什么
本 PR 让自动化流水线按风险匹配评审深度，处理最小、最机械的贡献（#7411）。triage skill 新增 Stage 1f 路由：当无人值守的 triage 运行遇到一个可以 100% 确定是行为中性维护性改动的 PR（内部重命名、格式化、仅注释/JSDoc 修改）时，照常发布 Stage 1 摘要，打上已有的
status/on-hold标签，然后停止——不进 Stage 2 代码评审、不出 Stage 3 结论、不做 approve。qwen-code-pr-review.yml的自动评审通道在调用模型前检查实时标签，只要status/on-hold存在就跳过自动评审。合并不受任何阻塞：maintainer 随时可以用@qwen-code /review拉起完整评审（显式触发永远不走标签检查），移除标签后下次推送即恢复自动评审。为什么需要
目前每个 PR——哪怕只改一行注释——都要走三阶段 triage、多轮自动评审、测试和若干条冗长的机器人评论。#7411 统计最近 300 个 PR 里有 26 个不超过 40 行的 fork PR，其编排和模型成本超过了改动本身的价值和风险，还占用了更高风险 PR 需要的评审精力。issue 明确把范围限定为：把行为中性的维护性改动导向轻量结果，而会改变行为的小 PR（bug 修复、面向用户的文档/CLI 帮助、链接、系统提示词、安全/数据丢失/兼容性）仍走完整流程。
评审者测试计划
如何验证
该路由刻意保守，测试锁定的是这些保守约束本身，而不是转述：
npm run test:scripts -- scripts/tests/qwen-pr-review-workflow.test.js scripts/tests/qwen-triage-workflow.test.js——255/255 通过。新增的qwen pr review triage-only skip (#7411)用桩gh执行真实的Resolve PR contextbash，并断言：仅当实时标签查询返回status/on-hold时才跳过自动评审（精确匹配——status/on-hold-extended不会触发跳过）；标签读取失败时失败开放（fail open），照常评审；显式/review评论和review_requested永不跳过，甚至不查询标签。已验证先红后绿：把 workflow 改动 stash 掉后，跳过测试失败。triage skill non-functional routing (#7411)锁定 Stage 1f 的契约措辞：失败关闭兜底（"when in doubt, take the full path"）、仅无人值守运行、排除清单（fix 标题、核心路径、workflows、manifest/lockfile、schema/生成文件、模型可见文本、面向用户的文档/CLI 帮助、坏链、高风险路径）、100 行生产代码上限、只使用已有标签的规则，以及在 Stage 2 之前终止退出。actionlint：干净。改动文件跑 Prettier：干净。前后证据
N/A——CI 自动化改动，无用户可见/TUI 界面。
测试环境
环境（可选）
Vitest workflow/skill 契约测试 + actionlint；不涉及运行时或沙箱。
风险与范围
/review、review_requested和 dispatch 永远执行，也不新增任何合并拦截（符合 issue 的非目标）。/review成本讨论；Proposal: remove automated PR approvals — triage gates only, approval authority returns to maintainers #9182 的 approval 策略提案。stale.yml的交互：该工作流本来就把status/on-hold排除在 stale 机制外——带此标签的 triage-only PR 不会被 stale 机器人自动关闭。另请注意未合并 PR feat(review): wire --resume through /review, review run and the CI retry #9153 也改了同一个 workflow 文件（不同区域：--resume接线），视合并顺序可能需要 rebase。关联 Issue
Fixes #7411