docs(autofix): let the agent escalate a maintainer's decision, not decide it - #7636
Merged
Conversation
…cide it The address-review classification had only two dispositions — fix, or decline-with-reason — so when a finding turned on a judgment that is the maintainer's to make (a v1 tradeoff, two reviewers wanting opposite things, whether the problem is worth solving at all), the agent was forced to either quietly implement one contested direction or decline it as "out of scope" — both of which ARE deciding. Add a third disposition: escalate. The agent names the decision, gives the options and its recommendation, and leaves the thread unresolved so the maintainer reads a question, not a verdict already reached. It is not a failure and not "could not address": everything else is addressed this round and the answer arrives as ordinary new feedback the next round — no new marker or state, it just rides along in the summary. Distinguishes decline (the change is not worth doing) from escalate (the call is not the agent's to make). Pins the new disposition in the existing SKILL policy test.
Collaborator
Author
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
Collaborator
|
🤝 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 冲突，直到移除标签或达到轮次上限。移除 |
Collaborator
|
Thanks for the PR! Template looks good ✓ — every section is covered (what / why / how / reviewer test plan / risk & scope / full Chinese translation). Minor, non-blocking: the headings differ slightly from the template ( Problem: observed, not theoretical. The description points to a real episode on #7471 where the address-review agent declined several findings as "design decision / out of scope" (shared-checkout concurrency tradeoff, branch-metadata persistence) that were genuinely the maintainer's calls, forcing @wenshao to re-litigate them by hand. That's a concrete failure mode, and "declining IS deciding" is the right diagnosis. Direction: aligned. Giving the agent a third honest disposition — name the decision and leave the thread unresolved — instead of forcing decide-or-bury is exactly the right lever, and it's squarely within the autofix skill's mission. No CHANGELOG signal needed; this is agent-policy, not a user feature. Size: not applicable — no core paths touched ( Approach: the scope feels right and deliberately minimal — one prose block adding the disposition, plus the consistent one-line update to the Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ —— 各部分齐全（what / why / how / 评审验证 / 风险与范围 / 完整中文翻译）。轻微、不阻塞：标题与模板略有出入（ **问题：**已观测，非理论。描述指向 #7471 上的真实情况——address-review agent 把几条本是维护者判断的意见以"design decision / out of scope"拒绝（共享 checkout 的并发取舍、分支元数据持久化），@wenshao 只好手动重新论证。这是具体的失败模式，"拒绝即是决定"的诊断正确。 **方向：**对齐。给 agent 第三种诚实的处置——点名决策并保持线程 unresolved——而非被迫"决定或埋掉"，正是正确的杠杆，也完全在 autofix skill 的职责内。无需 CHANGELOG 信号；这是 agent 策略，不是用户功能。 **规模：**不适用——未触及核心路径（ **方案：**范围合理且刻意最小化——一段散文新增处置，加上对 进入代码审查 🔍 — Qwen Code · qwen3.8-max-preview Reviewed at |
Collaborator
Code reviewReading just the title + "Why", my independent proposal was: add a third disposition to the address-review feedback classification, define when it applies (a judgment that's the maintainer's — product/scope tradeoff, conflicting reviewers, worth-solving-at-all), have the agent name the decision + options + recommendation and leave the thread unresolved, and — the load-bearing part — make sure the workflow doesn't auto-resolve it so the question actually gets read. Pin it with a test. The PR does essentially this, and nothing more. Two things done well:
No correctness, security, or regression risk — this is agent-facing prose with no runtime code path. No AGENTS.md violations; if anything it leans the right way on KISS (the heavier paused-state + label was deliberately left unbuilt). Nothing to block on. Real-scenario testingThis is a prose/policy change to the autofix agent skill — there is no CLI runtime path to drive in tmux (a The two pre-existing assertions still pass and the two new ones pin the added prose. (Run via a faithful node replication of the test's assertions rather than vitest, since neither tree had 中文说明代码审查只看标题 + "Why"，我的独立方案是：在 address-review 的反馈分类里加第三种处置，定义其适用场景（属于维护者的判断——产品/范围取舍、reviewer 意见相左、问题到底值不值得修），让 agent 点名决策 + 给出选项与建议并保持线程 unresolved，以及——最关键的一环——确保 workflow 不自动 resolve 它，使问题真的被读到。再用测试 pin 住。PR 基本就是这么做的，且没有多做。 两处做得好：
无正确性、安全或回归风险——这是面向 agent 的散文，不触及运行时代码路径。无违反 AGENTS.md；在 KISS 上方向正确（更重的暂停态 + 标签被刻意不做）。无可阻塞项。 真实场景测试这是对 autofix agent skill 的散文/策略改动——没有可在 tmux 中驱动的 CLI 运行路径（ — Qwen Code · qwen3.8-max-preview Reviewed at |
Collaborator
|
Confidence: 5/5 — clean across every stage; would merge without hesitation. Stepping back: this is a small PR that fixes a real, observed gap — the address-review agent had no honest way to hand a genuine judgment call back to a maintainer, so it either silently decided one contested direction or buried it as "out of scope" (which is itself a decision). The fix is the smallest possible lever: one prose disposition plus the one-line It reads well, the boundary between decline and escalate is crisp enough to keep the agent from abusing it, and the deliberately-unbuilt paused-state/label is the right restraint. The before/after evidence is the #7471 episode rather than a tmux capture, which is appropriate — there's no CLI runtime path for a docs/policy change, and the pinned unit test is the honest verification. Approving. 中文说明置信度：5/5 —— 各阶段均干净，毫不犹豫地合并。 退一步看：这是个小 PR，修了一个真实、已观测到的缺口——address-review agent 没有诚实的方式把一个真正的判断题交回维护者，于是要么默默决定某个有争议的方向，要么以"out of scope"埋掉（这本身就是决定）。修法是最小的杠杆：一段散文处置，加上让它真正生效的一行 读起来顺畅，decline 与 escalate 的界线足够清晰、能防止 agent 滥用，刻意不做的暂停态/标签是正确的克制。before/after 证据是 #7471 的事件而非 tmux 截图，这很合适——docs/策略改动没有 CLI 运行路径，pin 住的单元测试才是诚实的验证。批准。 — Qwen Code · qwen3.8-max-preview Reviewed at |
qwen-code-ci-bot
approved these changes
Jul 24, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
Contributor
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
approved these changes
Jul 24, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅
— qwen3.7-max via Qwen Code /review
yiliang114
approved these changes
Jul 24, 2026
yiliang114
left a comment
yiliang114
left a comment
Collaborator
There was a problem hiding this comment.
LGTM. Practical third disposition — escalate when the call is not the agent's to make. The distinction between Decline (change not worth doing) and Escalate (call not yours to make) is clear and well-documented. Leaving the thread UNRESOLVED so the maintainer reads an explicit question is the right behavior.
— qwen3.8-max-preview via Qwen Code /review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Gives the address-review agent a third way to handle a finding — escalate a maintainer's decision — instead of being forced to either implement it or decline it (both of which are the agent deciding).
Why
The SKILL classified every feedback point as fix or decline-with-reason. So when a finding turned on a judgment that is genuinely the maintainer's to make — a v1/product tradeoff, two reviewers asking for opposite things, or whether the reported problem is worth solving at all — the agent had no honest option: it either quietly implemented one contested direction, or declined it as "out of scope". Declining is deciding. And when the agent couldn't, it fell into the vague "could not address … a human should take over", which says nothing about what decision is needed.
Observed live on #7471: the agent declined several review findings as "design decision / out of scope" (the shared-checkout concurrency tradeoff, branch-metadata persistence). Those were the maintainer's calls — @wenshao then re-litigated them by hand. A cleaner flow names the decision and asks.
How
One prose change to
Mode: address-review— the smallest lever, no new marker or state:Deliberately the minimal version: the agent-behaviour change (this) is the high-value, low-cost piece. A distinct paused "waiting-on-human" state + label was considered and left unbuilt until it's shown the summary/reply channel is insufficient.
Reviewer Test Plan
npx vitest run scripts/tests/qwen-autofix-workflow.test.js -t "decision logic in the project autofix skill"— the SKILL policy test now also pins the escalate disposition (Needs a maintainer's decision,escalate when the). Passes.eligibility recheck,permanent API failures terminal,admits managed fork PRs— each passes in isolation and onmain).Risk & Scope
中文说明
本 PR 做了什么
给 address-review agent 处理评审意见的第三种方式 —— 升级由维护者决策,而不是被迫二选一(实现它 / 拒绝它,而这两者都是 agent 在替人做决定)。
为什么
SKILL 把每条反馈只分成 修 或 带理由拒绝。于是当一条意见的关键是"该由维护者拍板的判断"时 —— v1/产品取舍、两个 reviewer 要求相反、这问题到底值不值得修 —— agent 没有诚实的选项:要么默默实现某个有争议的方向,要么以"out of scope"拒绝(拒绝即是决定);实在不行就落进含糊的"could not address, 交人",却没说清到底要人决什么。
#7471 上实测:agent 把几条评审意见以"design decision / out of scope"拒绝(共享 checkout 的并发取舍、分支元数据持久化)—— 那本是维护者的判断,@wenshao 只好手动重新论证。更干净的做法是点名这个决策并发问。
怎么做
对
Mode: address-review一处 prose 改动 —— 最小杠杆,不新增 marker/状态:刻意做最小版:改 agent 行为(本 PR)是高价值低成本的一块;一个独立的"等人决策"暂停态 + 标签有意不做,等证明 summary/回帖通道不够用再说。
评审验证
-t "decision logic in the project autofix skill"—— SKILL policy 测试现在也 pin 了 escalate 处置。通过。风险与范围