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

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

#13321 native acceptance: read-only exploration reminder

PASS for both actual supported paths: headless core CLI and ordinary daemon/ACP Session. Both executed 102 real anonymous file reads, inserted one exploration reminder after the initial 101 results, accepted the additional read, and completed naturally. This controlled-provider run verifies runtime mechanics and wire insertion; it does not demonstrate production-model semantic convergence or token savings.

Candidate: bb78e71ffb54e884b50f2044e63978a8e92bee26 (source hashes verified against the committed files), based on 464f486e20198f7f39623f3e95f51ab5d4f98e40. The source and executed JavaScript hashes below were captured before and after the two native runs and were unchanged. The additive commit and normal push changed no source/build bytes. Core and CLI package builds completed with exit 0.

Actual scenarios and observations

Each isolated profile left model.maxToolCallsPerTurn unset, exercising the default adaptive allowance of 100. The anonymous loopback OpenAI-compatible provider first returned 101 distinct structured read_file calls for owned files, then returned one additional specific read (102), then a natural-stop summary. Files were served through the actual native tools, not injected as mock tool results. Each file contained 19 exact bytes, ANONYMOUS_READ_NNN plus newline; 1,938 actual bytes were checked per path against all 102 provider-received results. Local telemetry independently recorded 102 unique native call IDs with function_name=read_file, success=true, and execution_status=success per path.

Indices are zero-based wire-message indices. The reminder is a user-role text message beginning System:. In request 3, all 102 exact results were present, and the same single reminder remained at index 104; the latest tool result was at index 106. No second reminder was appended during this continuous read-only phase. read_file remained advertised in both continuation requests, and call 102 executed successfully. No write tool was issued or executed, and this reminder introduced no halt in these scenarios. The initial 101-call batch can pass the adaptive allowance before the continuation reminder; this is a soft reminder rather than an explicitly configured 100-call hard cap.

The provider records classify managed-memory by its actual managed memory extraction subagent system prompt and suggestion by the actual [SUGGESTION MODE: request. The main continuation counts exclude those requests. They replay prior history, including the existing reminder; their copies do not establish a second main-chat reminder insertion. Actual purpose/timestamp receipts are retained in result.json and original provider bodies.

Final answer in both paths:

ANONYMOUS_READONLY_FINDINGS: 102 anonymous files read successfully; remaining verification gap resolved. Controlled mechanics evidence only.

Executed-byte identity

The read-only Node load hook delegated to the normal loader and recorded actual load paths and SHA-256 values without transforming source. Core loaded its own candidate budget/client/CLI modules. The daemon loaded those modules plus its own candidate Session.js in the real ACP child process. Module loading alone is not the execution proof: the real tool results and outgoing reminder boundary establish the reached behavior.

Actual tmux captures

These are excerpts from tmux capture-pane on the real owned sessions, with local paths/host prompts and UUIDs redacted, including UUIDs wrapped across terminal lines. Full raw captures remain local; complete sanitized captures are retained beside them.

Core final excerpt:

:1050}}}
{"type":"user","uuid":"<id>","session_id":"<id>","parent_tool_use_id":null,"message":{"role":"us
er","content":[{"type":"tool_result","tool_use_id":"native-core-read-102","is_er
ror":false,"content":"ANONYMOUS_READ_102\n"}]}}
{"type":"assistant","uuid":"<id>","session_id":"
<id>","parent_tool_use_id":null,"message":{"id":
"<id>","type":"message","role":"assistant","mode
l":"native-exploration-core","content":[{"type":"text","text":"ANONYMOUS_READONL
Y_FINDINGS: 102 anonymous files read successfully; remaining verification gap re
solved. Controlled mechanics evidence only."}],"stop_reason":null,"usage":{"inpu
t_tokens":1000,"output_tokens":50,"cache_read_input_tokens":0,"total_tokens":105
0}}}
{"type":"result","subtype":"success","uuid":"<id>","session_id":"<id>","is_error":false,"duratio
n_ms":491,"duration_api_ms":282,"num_turns":3,"result":"ANONYMOUS_READONLY_FINDI
NGS: 102 anonymous files read successfully; remaining verification gap resolved.
 Controlled mechanics evidence only.","usage":{"input_tokens":4000,"output_token
s":200,"cache_read_input_tokens":0,"total_tokens":4200},"permission_denials":[]}
Warning: running headless with --yolo / approval-mode=yolo and no sandbox. All t
ool calls (shell, write, edit) auto-execute at this process's privilege level. C
onfigure tools.executionSandbox on Linux or a supported legacy sandbox via --san
dbox / QWEN_SANDBOX, or set QWEN_CODE_SUPPRESS_YOLO_WARNING=1 to silence this no
tice.
[actual owned CLI exit 0]
<local-path> %

Ordinary daemon/ACP capture:

ACTUAL_DAEMON_READY pid=93311 defaultAllowanceSetting=UNSET
ACTUAL_PROMPT_ADMITTED {"promptId": "<id>", "las
tEventId": 0, "eventEpoch": "<id>"}
ACTUAL_TERMINAL {"id": 316, "v": 1, "type": "turn_complete", "promptId": "<id>", "data": {"sessionId": "<id>", "stopReason": "end_turn", "promptId": "<id>", "branchPoint": {"assistantRecordUuid": "<id>", "checkpointUuid": "<id>"}}, "origina
torClientId": "client_<id>", "_meta": {"serverTi
mestamp": 1791376830120}}
ACTUAL_NATIVE_DONE events=316 state={"sessionId": "<id>", "workspaceCwd": "<owned-fixture> /dae
mon/workspace", "createdAt": "2026-10-07T12:40:28.453Z", "updatedAt": "2026-10-0
7T12:40:30.120Z", "clientCount": 1, "hasActivePrompt": false, "activeWorkState":
 "idle", "hasRunningBackgroundTasks": false, "isWaitingForPermission": false, "i
sWaitingForUserQuestion": false, "pendingInteractionCount": 0, "hasTurnError": f
alse, "pendingInteractions": []}
OWNED_DAEMON_STOPPED
<local-path> %

Scope and evidence

The provider and daemon were anonymous loopback fixtures. The core used the real noninteractive stream-json CLI. The daemon used real workspace-runtime admission, session creation, prompt HTTP admission, ACP Session execution, and its SSE event stream. The profile enabled automatic approval for the owned read-only fixture. Actual user auth and configuration were untouched. No production-model reasoning, deployment policy, user-input preemption, or write/permission boundary was claimed from these two positive runs.

Productive-phase/reset/permission/disabled/retry controls were not additional native scenarios here. Local check receipts confirm 649 focused core budget/loop/client tests passing and 12 executed CLI Session tests passing; 1,181 CLI tests were skipped, including all 38 reducer cases. Those targeted-check results are separate evidence from the native observations.

The first tmux launch passed non-executable owned shell scripts directly and exited before any product process or provider request. It was corrected to invoke those scripts with /bin/zsh -f; each actual native scenario then ran once. A postprocessing parser was corrected to accept null assistant content, using the same retained records; no native rerun occurred.

Evidence is under the owned 13321-native directory: identity-before.json, identity-after.json, result.json, frozen-fixture.json, and cleanup.json; per-path original and sanitized provider requests, provider response receipts, stdout/stderr, module-load logs, local telemetry, actual tmux captures, exact anonymous file manifests, and executed settings snapshots. The daemon additionally retains actual HTTP receipts, SSE events, and final idle status. No artifacts reconstruct terminal output.

Cleanup complete: both scenario tmux sessions and provider session removed; owned provider/daemon listeners closed; no owned native process remains; owned profile/runtime/workspace directories removed. Anonymous input manifests, controlled-provider/helper snapshots, raw evidence and sanitized captures remain. No product source, Git/GitHub, dependency or build action was performed by this verifier.

中文说明

两个真实运行路径均通过：headless core CLI 与普通 daemon/ACP Session 各实际读取 102 个匿名文件，前 101 个工具结果之后的下一次主请求均只出现一条探索提醒。随后第 102 次真实读取仍正常执行；再下一次主请求包含全部 102 个精确结果，只保留原有提醒，没有追加第二条。core 正常退出 0；daemon 收到 turn_complete/end_turn 后进入 idle，未发生 turn error。工具 telemetry 和 ACP 完成事件分别佐证了真实读取，不是把预期结果直接塞入请求。

配置没有显式设置 100 次硬上限，使用现有默认自适应 allowance。此次观测证明提醒在真实运行时正确插入、工具仍可继续使用且未被强迫写入或新增 halt。模型回复来自受控匿名本地 provider，因此不能据此声称生产模型一定收敛、减少 token 或产生有效研究结论。managed-memory 与 suggestion 的辅助请求按实际请求标记区分，它们携带历史中的同一条提醒，不计为主会话的再次插入。

运行前后源码与实际加载 JS 的 SHA-256 均一致，源码哈希已与完整候选 commit 中的文件核对。报告保留实际 tmux 抓取及脱敏版本，连跨行折断的 UUID 一并脱敏。所有自有 provider、daemon、tmux、临时 profile/runtime/workspace 已清理；原始请求、事件、telemetry、捕获和匿名输入清单保留。权限、重试及 reset 等边界以本地定向测试为独立证据，本报告没有扩大为第三次 native 场景，也没有声称执行被跳过的 CLI 测试。

Thanks — re-running the gate at the current head 2525fee6, which is a different commit from the pass that deferred at bb78e71f. The follow-up commit is additive and I reviewed the code as it now stands.

Template looks good ✓ — every heading from the template is present and filled in, including Evidence (Before & After) and Risk & Scope.

Problem: the mechanism gap is real and I verified it on main rather than taking the description's word for it. getMaxToolCallsPerTurn() returns the configured value, or Infinity when it is <= 0, and the adaptive default only halts a diverse-call turn on a stuck-repetition signal or at the hard backstop (shouldHaltOnTurnToolCallCap, loopDetectionService.ts:212). So a turn of 100 distinct successful reads passes the soft allowance with nothing asking the model to consolidate. What is not established is the user-level harm: #13321 is still open, carries need-discussion, and records one historical session (~9.6M tokens, no deliverable) whose deployed version was never captured and which was never reproduced on main. The PR says so plainly in its own scope section, which is the honest way to present it. This is a feat, so the missing reproduction is a direction question, not a Stage 1b blocker.

Direction: in scope, and more in-idiom than I expected from the description. Runaway-exploration bounding is already shipped policy here (adaptive cap, hard backstop, LoopDetectionService, #10887), and the advisory-reminder-at-a-threshold shape is already shipped too — the new reminder lands in the same parts array directly beside REPEATED_TOOL_FAILURE_REMINDER (Session.ts:9331) and beside activeTodoReminder on the core side. This extends an accepted mechanism rather than opening a new product surface. The genuine product question is narrower than "should this exist": it is whether an advisory nudge is worth its tokens when its effectiveness on production models is unmeasured. That question was escalated on the previous pass and is parked with @DragonnZhang plus the five requested reviewers; nothing here re-opens it.

Size: core paths are touched (packages/core/src/core, packages/core/src/services, packages/cli/src/acp-integration), so the two-tier gate applies. Breakdown of the 333 added lines, 0 deleted: 140 production (tool-exploration-budget.ts 80, client.ts 32, Session.ts 24, loopDetectionService.ts 4), 139 test (tool-exploration-budget.test.ts 88, Session.test.ts 46, client-goal.test.ts 5), 54 docs (the two design docs). 140 is well under the 500-line escalation threshold and this is a feat, so no size-based escalation and no hard block. Tier 2's confidence bar is the one that matters, and I could name every downstream consumer — listed in the review comment.

Approach: scope feels right and the diff is genuinely minimal — zero deletions, no drive-by refactor, no formatting churn, no unrelated files. Both design docs are present with reciprocal language links and matching section structure, which is what AGENTS.md asks for. I considered hosting the counter inside LoopDetectionService to inherit its existing reset hooks, but the daemon cannot use that class, and the repo already solves exactly this problem the way this PR does: a small pure helper in core imported by both runtimes (shouldHaltOnTurnToolCallCap is defined in loopDetectionService.ts:212, exported from core, and imported at Session.ts:194). So the extracted-module shape follows precedent rather than inventing a parallel one. Nothing I would cut.

Risk: Stage 1e matched one high-risk path — packages/cli/src/acp-integration/session/Session.ts (acp-integration). That is the revert-correlated signal, not a defect, but it raises review depth: no enrichment skipped, CI evidence required before approval, and a sandboxed lane named for the behavioural claim. Both are in the review comment.

Moving on to code review. 🔍

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

_{Reviewed at 2525fee66359cd06211e48f7ee06982c2b5043d2 · re-run with @qwen-code /triage}

Code review

No critical blockers and no AGENTS.md violations. One low-severity finding worth a one-line fix, named below.

I wrote my independent proposal before opening the diff: a counter for the continuous read-only phase, reset at logical-turn boundaries, emitting one advisory text part at the existing allowance. My first instinct was to host it inside LoopDetectionService to inherit the reset/commit/rollback hooks already wired in client.ts. That does not work, because the daemon cannot use LoopDetectionService — it keeps its own DaemonToolLoopState and shares only pure predicates with core. The repo already has a convention for exactly this, and the PR follows it: shouldHaltOnTurnToolCallCap is defined in loopDetectionService.ts:212, exported from core, and imported at Session.ts:194 so the two runtimes cannot drift. A small standalone module in core/src/services imported by both sides is the same move. The PR's shape is at least as good as mine, and it is 80 lines with four methods and no cleverness in it.

What I verified against main rather than reading for plausibility:

• Every API the new module leans on exists with the assumed signature: Kind.Read|Search|Fetch|Edit|Think (tools/tools.ts:1309), canonicalToolName (tool-names.ts:215), resolveRegisteredToolName returning string | string[] | undefined (tool-names.ts:233) — the new code handles the array case by declining to classify, which is the right answer for an ambiguous case-insensitive registration and is pinned by a test. ToolNames.TOOL_CALL is 'tool_call', ToolRegistry.getAllToolNames() (tool-registry.ts:1479) and getTool() (:1518) match.
• The cross-package import resolves: core's exports map carries "./*": "./dist/src/*" (packages/core/package.json:86), so @qwen-code/qwen-code-core/services/tool-exploration-budget.js lands on the built module. Importing the defining module instead of the package root is what AGENTS.md requires.
• Reset wiring is complete. client.ts has exactly four loopDetector.reset(prompt_id) sites (3800, 4141, 5283, 5391) and the diff adds a matching budget reset at all four, so no path leaks the counter across logical turns. I checked for a fifth site; there isn't one.
• Both insertion points are correct and preserve existing ordering. On the core side takeReminder sits inside the messageType === SendMessageType.ToolResult block (opened at client.ts:4675) and pushes before the activeTodoReminder splice runs, so findIndex now stops at the reminder and the todo reminder lands just ahead of it — still after every functionResponse part, which is what the Qwen call/response pairing constraint needs. On the daemon side the reminder goes into the single parts array (base Session.ts:9326) between activeTodoReminder and REPEATED_TOOL_FAILURE_REMINDER, ahead of drained.parts; there is only one such assembly site, so no continuation path is missed.
• The daemon needs no rollback and correctly has none. recordDaemonToolCalls is reached only for a completed attempt — the base comment at Session.ts:1092 states that RETRY / MODEL_FALLBACK discard the failed attempt's calls before re-streaming — and the new record loop is deliberately placed after both halt checks, so a batch that would cross the cap never feeds the budget. That placement is the substance of the follow-up commit and it is right.
• The optional field is not a dead switch. Every DaemonToolLoopState comes from createDaemonToolLoopState (call sites 6757, 7731, 10491, 11591), which always constructs the budget; the ?. guards exist for the exported type's sake, not for a live undefined path.
• client.ts already calls config.getToolRegistry().getAllToolNames() per event at :4783, so classifying each call the same way is consistent with existing cost, and client.test.ts already mocked both accessors (:871, :954 returning Infinity) — which is why only client-goal.test.ts needed completing. That mock returns POSITIVE_INFINITY, so those tests keep their prior behaviour instead of being bent around the feature.

Finding (low severity, not a blocker): ModelFallback does not roll the budget back. client.ts:4911 groups LlmEventType.Retry and LlmEventType.ModelFallback in one branch — both clear hasToolCalls and loopGuardFedCallIds and call restartAttempt, i.e. both discard the attempt's accumulated tool calls, and both are emitted from the same place (turn.ts:760 and turn.ts:777). The new block rolls back on Retry only, so after a model fallback the budget keeps Read/Search/Fetch counts for calls that were thrown away and never executed. The reminder can then fire earlier than the true executed count within that logical turn; it self-heals at the next reset. Worst case is one advisory sentence arriving early after a fallback during a heavy read-only turn, which is why I am not calling it a blocker — but the adjacent base code and the daemon comment both treat the two events as a pair, so adding || event.type === LlmEventType.ModelFallback would make the core path match its own stated invariant.

Two things I traced and concluded are fine, mentioned so you know they were checked rather than missed. Core's record runs before checkAlwaysOnSafeties, so a batch the always-on cap then halts has already been counted — harmless, because that path clears turn.pendingToolCalls and returns, ending the logical turn. And takeReminder writes committedReminded eagerly, so a rollback after a phase-ending tool restores reminded = true and suppresses a later reminder; that is the deliberate "never duplicate a delivered reminder" tradeoff and the third unit test pins it explicitly.

Added tests genuinely pin the change rather than passing alongside it: the budget test asserts the threshold, one-shot suppression, phase resets on Edit/Think/undefined, retry rollback, disabled allowance, ambiguous registrations, and bridged MCP kinds; the Session test asserts exactly one reminder reaches the provider, that a third read still executes, and that the reminder is the last part in the follow-up message. Removing the feature would fail both.

sequenceDiagram
    participant P1 as Model stream
    participant P2 as LlmClient or Session loop
    participant P3 as ToolExplorationBudget
    participant P4 as Next provider request
    P1->>P2: ToolCallRequest events
    P2->>P3: record the resolved Kind (Read, Search, Fetch count, anything else resets the phase)
    P1->>P2: Finished or Retry
    P2->>P3: commit on Finished, rollback on Retry
    Note over P2,P3: ModelFallback also discards the attempt but does not roll back
    P2->>P3: takeReminder with the per-turn allowance, on a tool-result turn
    P3-->>P2: reminder text once, then suppressed for the phase
    P2->>P4: tool results, then the reminder text
    Note over P2,P3: reset at all four logical-turn boundaries

Testing

This is an unattended CI re-run, so per the gate rules I executed nothing from this PR — no build, no test, no gh pr checkout. The evidence below is the PR's own CI, read through the API for the reviewed commit. Real-scenario tmux testing is N/A on this path; a maintainer can trigger it (see the lane line below).

All 34 check-runs on 2525fee6 are settled: 0 failures, 0 pending, and all three pull_request workflow runs (Qwen Code CI, SDK Java, tui-parity) completed successfully. Nothing is red, so there is no failing-job log excerpt to quote. The skipped jobs — Test (macos-latest), Test (windows-latest), Integration Tests (CLI, No Sandbox), and five orchestration jobs — are skipped by the workflows' own filters, not failed. The diff is platform-independent TypeScript with no path, filesystem, process, or shell surface, so the green ubuntu unit suite plus lint plus the no-AK integration run is adequate coverage for it; the Java SDK matrix is unrelated to this diff and green regardless.

34 check-runs on the reviewed commit — 0 failure, 0 pending. Java SDK matrix grouped into one row.

Sandboxed verification would settle the part CI cannot: @qwen-code /verify — that on the current head the reminder is actually present in the outgoing provider request at the allowance, that one further legitimate read still executes afterwards, and that a provider retry cannot deliver it twice. The unit and Session tests pin those mechanics against mocks, and the author's own native reports are self-run against a controlled loopback provider, so no independent A/B against the base build exists yet. @qwen-code /tmux is the lane for the interactive surface, since the reminder is model-bound text a user never sees directly but which changes what the model does next. The author has write access, so both lanes are directly available.

Not verified, and why: production-model convergence and token savings — no evidence of any kind, and the PR explicitly places them out of scope, so I am treating the reminder as an unproven-but-cheap nudge rather than a demonstrated win. Also not verified: Windows and Linux runtime behaviour, which the author's own table marks untested (the diff has no platform-specific surface, so I do not consider this a gap worth blocking on). The author's tmux captures, request histories, and source-hash identities in this thread are the author's claims, not evidence I re-ran — I could not, and did not treat them as a substitute.

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

_{Reviewed at 2525fee66359cd06211e48f7ee06982c2b5043d2 · re-run with @qwen-code /triage}

独立复核确认：本 PR 实现的"只读探索收敛提醒"与 #13321 的诉求一致，设计与代码改动自洽。下面给出按 PR head bb78e71f 独立走查源码得到的证据，便于 reviewer 直接核对。

提醒阈值与 disable/Infinity 语义对齐

ToolExplorationBudget.takeReminder(allowance)（packages/core/src/services/tool-exploration-budget.ts:33-44）在 !Number.isFinite(allowance) || allowance <= 0 || this.calls < allowance || this.reminded 时返回 undefined，命中时设置 reminded=true 并返回 TOOL_EXPLORATION_REMINDER（一次性）。这与 loopDetectionService.ts 里 getMaxToolCallsPerTurn() 的契约一致——loopDetectionService.ts:1596-1604 注释明确："Per-turn cap. getMaxToolCallsPerTurn() is the configured value (already resolved, Infinity when disabled)"。因此：

• 显式配置 → allowance 为有限值，到达阈值即提醒一次；
• 未配置（默认自适应）→ getMaxToolCallsPerTurn() 返回软阈值，提醒在软阈值处插入，硬回退仍由 checkTurnToolCallCap 负责（loopDetectionService.ts:1610-1618 调 shouldHaltOnTurnToolCallCap(... isMaxToolCallsPerTurnExplicit())，与提醒互不干扰）；
• 禁用/无限 → !Number.isFinite 直接 short-circuit，不提醒，符合 PR "禁用或无限 allowance 不产生提醒"。

core 路径：record / commit / rollback 与 loop guard 同源

client.ts:4967-4984 把 budget 的事件接入与 loopGuardFedCallIds 去重绑定到同一个 duplicateLoopGuardRequest 判定：

if (event.type === ToolCallRequest && !duplicateLoopGuardRequest) {
  budget.record(getToolExplorationKind(registry, event.value.name, event.value.args));
} else if (event.type === Finished) {
  budget.commit();
} else if (event.type === Retry) {
  budget.rollback();
}

这与 loopDetectionService.ts 的 Retry 处理对齐——checkAlwaysOnSafeties 的 Retry 分支（loopDetectionService.ts:660-697）注释明确 retry 会 replay 失败 attempt 的 tool calls，并 clear 重复计数器；budget 的 rollback()（tool-exploration-budget.ts:50-54）把 calls/reminded 回滚到 committedCalls/committedReminded，语义一致——一次 retry 不会把已撤销的 read 计入探索阶段，也不会重复投递已发过的提醒。provider 重复 callId 的去重由 duplicateLoopGuardRequest（client.ts:4955-4962，基于 loopGuardFedCallIds.has(fedCallId)）保证，budget 复用同一判定，与 #9450 的 dedup 同源。

提醒插入点 client.ts:4797-4805 用 this.loopDetector.isDisabledForSession() 作前置闸——isDisabledForSession() 是本 PR 在 loopDetectionService.ts:455-457 新增的访问器，返回 this.disabledForSession（在 :448 由交互式 disable 设置）。这样"会话级 loop-detector disable 也抑制 core 提醒"成立，且与 checkAlwaysOnSafeties:788 的 if (this.disabledForSession) ... 共用同一开关，行为统一。

reset 覆盖面

budget 的 reset() 在 user turn / Goal / Stop-hook 进入处调用：client.ts:3805（startsInteraction）、:4146（Goal）、:5312（Stop-hook goal）、:5392（Stop-hook continuation）。这覆盖了 loopDetector.reset(prompt_id) 的所有既有 reset 点（PR 在每个 this.loopDetector.reset(prompt_id) 旁边都加了 this.toolExplorationBudget.reset()），逻辑轮次边界与既有 loop-detector 完全对齐，不会出现 budget 跨轮次泄漏。

kind 分类与桥接 MCP 工具

getToolExplorationKind（tool-exploration-budget.ts:25-42）通过 canonicalToolName → resolveRegisteredToolName(canonical, registry.getAllToolNames()) 解析目标：当 name === ToolNames.TOOL_CALL 且 args.name 为 string 时改用桥接目标名，否则用传入名。resolveRegisteredToolName（tool-names.ts:233-244）的歧义返回是 string[]（多个 case-insensitive 命中），budget 在 :35 用 Array.isArray(resolved) → undefined 处理——即歧义名（如同时注册 READ_FILE/Read_File）按"未分类"处理，结束当前 read 阶段，这是保守且安全的方向。tool-exploration-budget.test.ts:43-49 与 :51-68 分别覆盖了歧义未分类与桥接 MCP 工具两种情形。

一个非阻塞观察

record()（tool-exploration-budget.ts:30-38）对非 Read/Search/Fetch kind 直接 calls=0; reminded=false——即一个失败的 Edit/Think 调用也会重置探索阶段。PR 设计文档（docs/design/tool-exploration-convergence.md:18-20）已显式声明这是有意为之："A non-read request resets the phase even if its execution later fails; the existing failure protections retain responsibility for that case." 这与 #10887 的重复失败保护职责切分清晰，不构成本 PR 的问题，仅提示 reviewer 确认该切分符合预期——如果未来希望"探索阶段被失败的非读调用打断后、下一轮只读继续累积"，需要单独再提，当前实现按设计文档是有意为之。

测试

tool-exploration-budget.test.ts（88 行）覆盖：阈值一次性 + 合法继续（:8-16）、实现/规划/未知 kind 重置（:18-29）、retry 回滚不重复提醒（:31-41）、disabled/Infinity/0（:43-47）、歧义未分类与桥接 MCP（:49-68）。Session.test.ts:20548-20590 在 ACP 路径上验证"read 结果后插入一次提醒、允许继续 read、提醒文本含 does not authorize writes"，并断言 execute 被调用 3 次（2 次触发阈值 + 1 次合法继续）。core 与 ACP 两条路径均有落点。

结论：设计与实现一致、与既有 loop-detector / cap 语义对齐、测试到位，建议合入。

Confidence: 4/5 — the code is sound and I verified the wiring end to end; the one nit is a single missing event type, and my only real reservation is a product judgment that is not mine to make and is already parked with the assigned maintainer.

To be explicit about what this score is not: the fork-refactor guardrail did not fire (GUARD = ok — this is a feat), and Stage 0 raised no size escalation (140 production lines against a 500-line threshold). So 4/5 is my honest read of the code, not a policy cap, and the missing point is the ModelFallback finding plus the unproven-effectiveness question below.

Going back to my independent proposal: I would have reached for the same thing, and for the same reason the PR did. My first idea — host the counter in LoopDetectionService and inherit its existing hooks — fails on the daemon, which cannot use that class. The repo already solved that problem once, by extracting a small pure helper into core and importing it from both runtimes (shouldHaltOnTurnToolCallCap), and this PR repeats the move rather than inventing a parallel mechanism. That is the part I weigh most heavily: it is not a new abstraction, it is the existing one applied a second time.

On whether the problem exists — I did not accept the framing. The historical session in #13321 was never reproduced on main and its version was never recorded, so the user-level harm rests on one unreproduced incident. But the mechanism gap is checkable and I checked it: getMaxToolCallsPerTurn() resolves a non-positive config to Infinity, and the adaptive default only halts a diverse-call turn on a stuck-repetition signal or at the hard backstop, so 100 distinct successful reads pass the soft allowance with nothing asking the model to consolidate. That is a real hole in a policy this repo has already decided to ship, and closing it with an advisory sentence rather than a new halt is the proportionate response.

What I would flag for the maintainer, none of it blocking:

• The ModelFallback rollback gap from the review comment. One-line fix; the core path currently contradicts an invariant its own adjacent code states.
• The reminder has no dedicated setting. It is suppressed only by a disabled/infinite model.maxToolCallsPerTurn on both paths, and additionally by the interactive loop-detector disable on the core path — which has no ACP equivalent, so daemon sessions have one less route to turn it off. For an advisory feature whose payoff is unmeasured, inheriting the cap's configuration is defensible and keeps the diff minimal, but it does mean this ships always-on for every session that crosses the allowance. Worth a deliberate yes rather than a default.
• Volume, stated plainly because the gate is supposed to notice it: 18 open PRs from this author, 11 opened today. That is a reason to read each one on its own merits with more skepticism, not less, and it is why I verified the integration against main instead of skimming. It is not a defect in this PR, and I did not let it argue either direction here.

Would I curse whoever wrote this in six months? No. It is 140 additive lines with zero deletions, no drive-by refactor, tests that fail if you remove the feature, and design docs in both languages with reciprocal links. The class has four methods and no state machine cleverness, and the reset wiring is complete at all four logical-turn boundaries — which is the thing that usually rots in this area and the thing I spent most of my time on.

So: approving on the code. I am not signing off on the product direction, and I want that to be unambiguous — #13321 is still open and carries need-discussion, the previous pass escalated exactly this question, and it is assigned to @DragonnZhang with five reviewers requested. Whether an unproven advisory nudge is worth its tokens on every long read-only turn is a call for a maintainer, and main requiring two approving reviews means that call is still theirs to make. My approval is the code-review vote: the implementation is correct, minimal, tested, and idiomatic, and CI is green on the reviewed commit.

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

_{Reviewed at 2525fee66359cd06211e48f7ee06982c2b5043d2 · re-run with @qwen-code /triage}

Added scope/core for maintainer routing. The latest triage raised a product acceptance gate rather than a verified code defect: this PR deliberately adds a bounded read/search/fetch convergence reminder, while full domain-level convergence and measured token savings remain outside the evidence collected so far. The current-head local and actual CLI/daemon-ACP tmux report distinguishes controlled-provider behavior from real-model effectiveness.

I am retaining Addresses #13321, keeping the issue open, and leaving the product-direction decision with the assigned maintainer. No speculative policy expansion or unrelated refactor has been added.

中文：已补 scope/core 标签供 maintainer 评估。当前改动与本地、真实 CLI/daemon-ACP tmux 报告证明的是有界的收敛提醒行为，还没有证明原生产场景的语义收敛或实际 token 降幅。继续按 Addresses #13321 跟进，issue 保持开放，产品方向需要 maintainer 判断。

Current-head follow-up at 2525fee66359cd06211e48f7ee06982c2b5043d2.

The new additive commit moves exploration-budget recording past the existing cap and duplicate halt checks and completes the client-goal Config mock. This verification keeps the current daemon path attributable to its changed runtime bytes.

Local checks: 56 client-goal tests passed with zero skips; two selected Session cap/duplicate cases passed (1,153 other cases intentionally skipped). The selected cases verify the existing halt behavior, not the internal exploration counter of a discarded batch. Fresh CLI build/typecheck passed. The core production tree is unchanged by this follow-up, so the earlier core headless run is retained at its original recorded identity rather than rerun or relabeled.

PR #13601 current-head daemon/ACP verification

PASS at 2525fee66359cd06211e48f7ee06982c2b5043d2. One ordinary daemon/ACP scenario ran through the real native CLI, workspace-runtime admission, session prompt admission and SSE stream. Responses came from an anonymous controlled loopback provider; this is runtime-mechanics evidence, not production-model convergence or token-savings evidence.

The isolated profile left model.maxToolCallsPerTurn unset, using the default adaptive allowance of 100 rather than an explicit hard cap. The provider requested 101 distinct native read_file calls, then one additional read, then natural completion. All 102 actual file results matched the anonymous input bytes exactly (1,938 bytes total). ACP emitted 102 completed tool updates; local telemetry independently recorded 102 unique successful read_file calls.

Positions are zero-based wire-message indices. The reminder first appeared after the 101 results. The continuation still advertised read_file; the 102nd call executed. No second reminder was appended, no accidental hard-cap terminal occurred, and the admitted prompt ended with exactly one turn_complete/end_turn. Final state was idle, with no active prompt or turn error. The main-request count excludes one managed-memory request and one suggestion request, identified from their actual system/purpose text. Their replayed history carries the same existing reminder.

Source bytes matched the current committed files. Pre/post source and compiled-module hashes were unchanged. A read-only Node load hook delegated to the normal loader and recorded the actual CLI and ACP-child loads, including the current Session module and core budget module. Generated commit metadata still reports 464f486e2019; it predates this candidate and was not used as loaded-byte identity.

Actual owned tmux capture excerpt (identifiers, local paths and process IDs sanitized; original capture retained):

ACTUAL_DAEMON_READY pid=<owned-process> defaultAllowanceSetting=UNSET
ACTUAL_PROMPT_ADMITTED {"promptId": "<id>", "lastEventId": 0, "eventEpoch": "<id>"}
ACTUAL_TERMINAL {"id": 316, "v": 1, "type": "turn_complete", "promptId": "<id>", "data": {"sessionId": "<id>", "stopReason": "end_turn", "promptId": "<id>", "branchPoint": {"assistantRecordUuid": "<id>", "checkpointUuid": "<id>"}}, "originatorClientId": "client_<id>", "_meta": {"serverTimestamp": 1791384990008}}
ACTUAL_NATIVE_DONE events=316 state={"sessionId": "<id>", "workspaceCwd": "<owned-fixture>/daemon/workspace", "createdAt": "2026-10-07T14:56:28.417Z", "updatedAt": "2026-10-07T14:56:30.008Z", "clientCount": 1, "hasActivePrompt": false, "activeWorkState": "idle", "hasRunningBackgroundTasks": false, "isWaitingForPermission": false, "isWaitingForUserQuestion": false, "pendingInteractionCount": 0, "hasTurnError": false, "pendingInteractions": []}
OWNED_DAEMON_STOPPED

Only this changed daemon path was run. Core headless behavior, real-model semantics, duplicate/cap negative controls, reset, retry and permission controls were not additional native scenarios. No product source, dependencies, Git/GitHub state or global services were changed. Raw requests/responses, HTTP receipts, SSE events, module loads, telemetry, file manifest and original tmux capture are retained. The result and identity receipts record the assertions above.

Cleanup verified: both owned tmux sessions and processes stopped, both owned listeners closed, and the owned profile/runtime/workspace directories removed. Raw evidence remains.

中文说明

当前提交 2525fee 的普通 daemon/ACP 路径通过一次真实原生运行验证。独立配置没有显式设置 100 次硬上限，实际使用默认自适应 allowance。前 101 次真实文件读取完成后，第二次主模型请求在最后一个工具结果之后插入一条探索提醒；第 102 次读取仍正常执行，第三次主请求包含全部 102 个精确结果，只保留已有提醒，没有追加第二条。实际文件内容合计 1,938 字节，ACP 的 102 个完成事件和本地 telemetry 的 102 个唯一成功调用共同佐证读取行为。

该提示没有造成新的终止：同一获准 prompt 收到唯一的 turn_complete/end_turn，会话进入 idle，未发生 turn error。主请求共三次；另有各一次 managed-memory 和 suggestion 请求，按实际请求内容归因并从主请求统计中排除。辅助请求中的历史提醒不计为新的插入。

加载记录证明真实 ACP 子进程使用当前编译后的 Session 和 core budget 模块；运行前后源代码与编译产物哈希一致。生成的版本元信息仍显示较早的 464f486e2019，本报告明确区分它与实际加载字节的身份。本次 provider 是匿名本地受控服务，因此只证明运行时计数、注入、继续调用和自然结束，不证明生产模型的语义收敛或 token 节省。没有重跑 core headless，也没有扩大成负向控制矩阵；原始证据保留，清理仅涉及本次拥有的进程、tmux、配置和运行目录。

清理已核实完成：本次 provider 与 daemon 进程、两个 tmux 会话和监听端口均已关闭，只删除本次独立配置、运行目录及匿名输入文件；原始请求、事件、tmux 和哈希证据保留。

中文补充：当前 2525fee 增量提交后，本地 56 个 client-goal 测试及两个定向 cap/重复调用 Session 用例通过；其余 1,153 个 Session 用例未执行，不计入通过数。fresh CLI build/typecheck 通过。此次额外原生验收仅覆盖变更后的 daemon/ACP 路径；core 生产逻辑没有变化，先前 headless 报告继续保留原提交身份。仍按 Addresses #13321 跟进，产品方向、生产模型收敛及 token 节省尚未证明；PR 未合并，issue 保持开放。

Qwen Code review did not complete successfully. The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

The corrected productive-phase control passed at 2525fee66359cd06211e48f7ee06982c2b5043d2: one corrective native CLI/tmux attempt, retry 0, exit 0, natural completion. It executed 102 real tools: 99 distinct read_file calls → one separate edit creation → two verification reads. All 102 terminal receipts succeeded; next-request history independently contained 102 tool results. The provider received the 99 read results before issuing the edit, then the actual Created new file: … with provided content. result before issuing verification reads.

The summary was derived from actual read payloads and matched the independent expected bytes exactly: 1,377 bytes, SHA-256 8b645af48accd1e63de05dac3242d023fd79fe02e35ff809baf4cadbbc7f23f6. Traffic was 4 primary requests, 0 memory, 0 suggestion, with prior-result counts 0/99/100/102. No exploration reminder appeared in any model-bound request. The adaptive allowance remained unset (default 100); the actual edit is registered as Kind.Edit, whose matched budget implementation resets the continuous read-only phase.

All 26 scoped source/runtime identities and HEAD stayed fixed; fixture helpers stayed fixed. Eleven actually loaded modules matched the manifest. The edit source hash was e2d196b45adb96ab14a14fb1b0583a6a5694e9a39a73949d69964b9d587af71c; loaded edit runtime was 09a0c0e43dbae3d8f94c888762ceb069169ac6a2beacc89e1258414d66fcbcfd, with current source emission matching. Loaded budget was 0b41f7d892122d3de411cfda400956d482d4d9cdfb00c3361fcc1f85b9dfa2b9; client was f713fcd604a3607d5ae740bf33fe28b674699c35c8c0d0eb83482ed827d2915b. No build or unit rerun was needed.

The actual tmux excerpt and compact result receipt are included below. There were two native attempts overall: a first fixture-selection failure with 0 tools, followed by this one corrected control. Neither used automatic retries. The first attempt remains recorded and is not acceptance evidence. The controlled localhost provider verifies phase mechanics and productive non-interference, not production-model semantic convergence or complete #13321 acceptance. Owned provider/tmux/config/runtime were cleaned up; fixture helpers and test files remain for review.

{"type":"user","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"message":{"role":"user","content":[{"typ
e":"tool_result","tool_use_id":"call_<ID>","is_error":false,"content":"Created new file: <ARTIFACT_DIR>/workspace/sum
mary.txt with provided content. Showing lines 1-100 of 100 from the edited file:\n\n---\n\nrecord-001=1\nrecord-002=2\nrecord-003=3\nrecord-004=4\nrecord-005=5\nrecord-006=6\nrecor
d-007=7\nrecord-008=8\nrecord-009=9\nrecord-010=10\nrecord-011=11\nrecord-012=12\nrecord-013=13\nrecord-014=14\nrecord-015=15\nrecord-016=16\nrecord-017=17\nrecord-018=18\nrecord-0
19=19\nrecord-020=20\nrecord-021=21\nrecord-022=22\nrecord-023=23\nrecord-024=24\nrecord-025=25\nrecord-026=26\nrecord-027=27\nrecord-028=28\nrecord-029=29\nrecord-030=30\nrecord-0
31=31\nrecord-032=32\nrecord-033=33\nrecord-034=34\nrecord-035=35\nrecord-036=36\nrecord-037=37\nrecord-038=38\nrecord-039=39\nrecord-040=40\nrecord-041=41\nrecord-042=42\nrecord-0
43=43\nrecord-044=44\nrecord-045=45\nrecord-046=46\nrecord-047=47\nrecord-048=48\nrecord-049=49\nrecord-050=50\nrecord-051=51\nrecord-052=52\nrecord-053=53\nrecord-054=54\nrecord-0
55=55\nrecord-056=56\nrecord-057=57\nrecord-058=58\nrecord-059=59\nrecord-060=60\nrecord-061=61\nrecord-062=62\nrecord-063=63\nrecord-064=64\nrecord-065=65\nrecord-066=66\nrecord-0
67=67\nrecord-068=68\nrecord-069=69\nrecord-070=70\nrecord-071=71\nrecord-072=72\nrecord-073=73\nrecord-074=74\nrecord-075=75\nrecord-076=76\nrecord-077=77\nrecord-078=78\nrecord-0
79=79\nrecord-080=80\nrecord-081=81\nrecord-082=82\nrecord-083=83\nrecord-084=84\nrecord-085=85\nrecord-086=86\nrecord-087=87\nrecord-088=88\nrecord-089=89\nrecord-090=90\nrecord-0
91=91\nrecord-092=92\nrecord-093=93\nrecord-094=94\nrecord-095=95\nrecord-096=96\nrecord-097=97\nrecord-098=98\nrecord-099=99\n"}]}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"message_start","
message":{"id":"<ID>","role":"assistant","model":"productive-controlled","content":[]}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
art","index":0,"content_block":{"type":"tool_use","id":"call_<ID>","name":"read_file","input":{}}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_de
lta","index":0,"delta":{"type":"input_json_delta","partial_json":"{\"file_path\":\"<ARTIFACT_DIR>/workspace/summary.txt\",\"offse
t\":0,\"limit\":99}"}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
op","index":0}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
art","index":1,"content_block":{"type":"tool_use","id":"call_<ID>","name":"read_file","input":{}}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_de
lta","index":1,"delta":{"type":"input_json_delta","partial_json":"{\"file_path\":\"<ARTIFACT_DIR>/workspace/input-099.txt\",\"off
set\":0,\"limit\":1}"}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
op","index":1}}
{"type":"assistant","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"message":{"id":"<ID>","type":"message","role":"assistant","model":"productive-controlled","content":[{"type":"tool_use","id":"call_<ID>","name":"read_file","input":{"file_
path":"<ARTIFACT_DIR>/workspace/summary.txt","offset":0,"limit":99}},{"type":"tool_use","id":"call_<ID>","name":"read
_file","input":{"file_path":"<ARTIFACT_DIR>/workspace/input-099.txt","offset":0,"limit":1}}],"stop_reason":"tool_use","usage":{"i
nput_tokens":12616,"output_tokens":63,"cache_read_input_tokens":0,"total_tokens":12679}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"message_stop"}}
{"type":"user","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"message":{"role":"user","content":[{"typ
e":"tool_result","tool_use_id":"call_<ID>","is_error":false,"content":"Read lines 1-99 of 100 from ../../../../..<ARTIFACT_DIR>/workspace/summary.txt"}]}}
{"type":"user","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"message":{"role":"user","content":[{"typ
e":"tool_result","tool_use_id":"call_<ID>","is_error":false,"content":"Read lines 1-1 of 2 from ../../../../..<ARTIFACT_DIR>/workspace/input-099.txt"}]}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"message_start","
message":{"id":"<ID>","role":"assistant","model":"productive-controlled","content":[]}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
art","index":0,"content_block":{"type":"text","text":""}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_de
lta","index":0,"delta":{"type":"text_delta","text":"Productive control complete: 99 reads, one summary creation, and two verification reads succeeded."}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"content_block_st
op","index":0}}
{"type":"assistant","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"message":{"id":"<ID>","type":"message","role":"assistant","model":"productive-controlled","content":[{"type":"text","text":"Productive control complete: 99 reads, one summary creation
, and two verification reads succeeded."}],"stop_reason":null,"usage":{"input_tokens":13186,"output_tokens":25,"cache_read_input_tokens":0,"total_tokens":13211}}}
{"type":"stream_event","uuid":"<ID>","session_id":"<ID>","parent_tool_use_id":null,"event":{"type":"message_stop"}}
{"type":"result","subtype":"success","uuid":"<ID>","session_id":"<ID>","is_error":false,"duration_ms":467,"duration_
api_ms":312,"num_turns":4,"result":"Productive control complete: 99 reads, one summary creation, and two verification reads succeeded.","usage":{"input_tokens":41467,"output_tokens
":3090,"cache_read_input_tokens":0,"total_tokens":44557},"permission_denials":[]}

Native exit: 0; provider receipts captured.

{
  "head": "2525fee66359cd06211e48f7ee06982c2b5043d2",
  "verdict": "passed_controlled_productive_phase",
  "cliExit": 0,
  "naturalCompletion": true,
  "execution": {
    "totalToolCalls": 102,
    "readFileCalls": 101,
    "initialDistinctReads": 99,
    "editCreations": 1,
    "verificationReads": 2,
    "nativeToolResults": 102,
    "nativeErrorResults": 0,
    "nextRequestToolResults": 102,
    "sequence": [
      [
        "read_file",
        99
      ],
      [
        "edit",
        1
      ],
      [
        "read_file",
        2
      ]
    ],
    "writeAndVerificationSeparated": true,
    "editResultSuccessGatePassed": true
  },
  "summary": {
    "bytes": 1377,
    "sha256": "8b645af48accd1e63de05dac3242d023fd79fe02e35ff809baf4cadbbc7f23f6",
    "expectedSha256": "8b645af48accd1e63de05dac3242d023fd79fe02e35ff809baf4cadbbc7f23f6",
    "exactBytesMatch": true,
    "derivedFromActual99ReadResults": true
  },
  "requests": {
    "primary": 4,
    "memory": 0,
    "suggestion": 0,
    "other": 0,
    "primaryPriorResultCounts": [
      0,
      99,
      100,
      102
    ],
    "explorationReminders": 0
  },
  "allowance": {
    "configured": false,
    "resolvedDefault": 100,
    "evidence": "Matched unchanged config and loaded loop detector default; total102 completes beyond default100 without hard-cap override"
  },
  "identity": {
    "entries": 26,
    "beforeAfterStable": true,
    "loadedMatchManifest": true,
    "editKind": "Kind.Edit",
    "editSourceSha256": "e2d196b45adb96ab14a14fb1b0583a6a5694e9a39a73949d69964b9d587af71c",
    "editRuntimeSha256": "09a0c0e43dbae3d8f94c888762ceb069169ac6a2beacc89e1258414d66fcbcfd",
    "editEmissionMatches": true
  }
}

中文：纠正后的控制在同一 2525fee head 通过。仅运行一次，retry 0、exit 0，自然完成 102 个真实工具：99 个不同文件读取 → 独立 edit 创建汇总 → 收到真实创建成功结果后再做两次验证读取。102 个终端结果均成功，下一请求历史也有 102 个工具结果；4 个主请求、memory 0、suggestion 0，均未出现 exploration reminder。汇总由真实读取结果生成，1,377 字节与独立预期完全一致。默认 allowance 未设置，edit 的 Kind.Edit 与实际加载预算实现对应重置只读阶段。26 项源码/产物身份前后固定，11 个真实加载模块哈希匹配；未重复构建或单测。先前 0 工具的 fixture 设置失败证据保留。此次受控 provider 只证明阶段机制及实际写入后的验证流程不受探索提醒影响，不代表真实模型语义收敛或 #13321 完整验收。下方保留实际脱敏 tmux 片段和结果回执；完整 capture、schema、fixture 与输入/输出也已在本地保留，自有进程、tmux、运行配置已清理。整体是一次 0 工具的设置失败和一次纠正运行，两次均没有自动重试。capture 中的 usage 数字来自模拟 provider，不能作为真实模型 token 或节省量。

@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: 1925 passed · 0 failed · 1925 total

Flakiness gate: ⚠️ timeout — only 3 of 5 rounds fit the 15-minute budget; the completed rounds agreed

node tmp/pr13601-verify-20261008-003104/mutate.mjs --only M09,M10,M11,M12,M13,PROBE-CORE

node tmp/pr13601-verify-20261008-003104/mutate.mjs --only M15    # full 1159-test Session suite
node tmp/pr13601-verify-20261008-003104/mutate.mjs --only M15F   # same revert, focused on the new test

allowance=Infinity calls=5 -> reminder=none      allowance=0  -> none
allowance=NaN      calls=5 -> reminder=none      allowance=-1 -> none
allowance=3        calls=5 -> reminder=DELIVERED

resolveRegisteredToolName exact hit   0.09 us/call     canonicalToolName          0.04 us/call
resolveRegisteredToolName miss        3.46 us/call     getAllToolNames equivalent 5.65 us/call
added cost per tool call ~= 5.77 us   (worst case, unregistered name: 9.14 us)
1000 tool calls (the adaptive hard backstop) ~= 5.77 ms total

rounds=5 files=3 skipped=0
file packages/cli/src/acp-integration/session/Session.test.ts: (cd packages/cli) npx --no-install vitest run ./src/acp-integration/session/Session.test.ts
file packages/core/src/core/client-goal.test.ts: (cd packages/core) npx --no-install vitest run ./src/core/client-goal.test.ts
file packages/core/src/services/tool-exploration-budget.test.ts: (cd packages/core) npx --no-install vitest run ./src/services/tool-exploration-budget.test.ts


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  packages/cli/src/acp-integration/session/Session.test.ts: PPPP
  packages/core/src/core/client-goal.test.ts: PPP
  packages/core/src/services/tool-exploration-budget.test.ts: PPP

verdict: timeout
summary: only 3 of 5 rounds fit the 15-minute budget; the completed rounds agreed

--- per-invocation detail (full copy in the artifact) ---
round 1 · packages/cli/src/acp-integration/session/Session.test.ts: P (exit 0)
round 1 · packages/core/src/core/client-goal.test.ts: P (exit 0)
round 1 · packages/core/src/services/tool-exploration-budget.test.ts: P (exit 0)
round 2 · packages/cli/src/acp-integration/session/Session.test.ts: P (exit 0)
round 2 · packages/core/src/core/client-goal.test.ts: P (exit 0)
round 2 · packages/core/src/services/tool-exploration-budget.test.ts: P (exit 0)
round 3 · packages/cli/src/acp-integration/session/Session.test.ts: P (exit 0)
round 3 · packages/core/src/core/client-goal.test.ts: P (exit 0)
round 3 · packages/core/src/services/tool-exploration-budget.test.ts: P (exit 0)
round 4 · packages/cli/src/acp-integration/session/Session.test.ts: P (exit 0)

Evidence images

Harness scripts and raw logs are in the workflow run artifacts (7-day retention).

— Qwen Code · sandboxed verification