[yiliang114]

Summary

Recover a complete outer XML tool call whose parameter value quotes other calls, while keeping the quoted markup inert. An ambiguous or malformed block is now rejected on its own and the scan resumes past it, so one bad envelope no longer costs the genuine calls beside it.

What this changes

• Closes the reported gap in XML tool-call recovery drops outer calls containing quoted tool markup #13492: a write_file whose content contains an unfenced example call is recovered exactly once with the complete content, and the quoted call never dispatches.
• Rejects ambiguity per block instead of per turn. The whole-text opener pre-scan, the unclosed-opener veto and the fence-disagreement pass that used to return no calls for the whole turn are gone; a rejected block resumes at its own next open tag.
• Reads a depth-paired value's complete extent when the value documents a nested parameter element, instead of stopping at the flat match.
• Treats HTML comments and CommonMark indented code blocks as documentation, like fences and <example>. A value that quotes a call used to let a commented-out shell command dispatch while stripping its own markup from the visible turn.
• Rejects a block whose parameter names repeat, because the quote advance can otherwise pull a stray element into the block and silently overwrite an argument.
• Keeps a value that only mentions a bare closing tag on the flat path, so that block is rejected rather than dispatched with a truncated write.

Reviewer Test Plan

Return a document write whose content quotes a harmless call, followed by an independent control-file read. Expect the write executed once with exact bytes, the quoted call inert, and the read executed.

Then vary the shape: a trailing parameter behind the quoted value, a documented parameter element inside the value, the same shape inside a fence, an <example>, an HTML comment and an indented block, a malformed block before an intact call, and a prose mention of <!-- before a live call. Expect documentation to stay inert and the intact calls to recover.

Evidence

• packages/core: xml-tool-call-fallback.test.ts 138/138, llm-chat.test.ts 567/567; typecheck, ESLint and Prettier clean on both changed files.
• 6000-case seeded fuzz over tag/fence/comment fragments: no exception, no hang, max 2.8 ms; recovered: false never changes remainingText.
• Cost after deleting the whole-turn pre-scan: 1000 malformed openers inside a fence ~1 ms (was ~2.2 s at the reviewed head), 64 KB example body ~13 ms (was ~420 ms).
• No CLI/tmux end-to-end run this round. The production call site is unchanged; the earlier CLI evidence covered the whole-turn decline, which this version removes.

Risk & Scope

The contract changes from turn-wide decline to per-block rejection. That is what #13492 asks for, and it restores the three witnesses the branch had inverted. It also means a complete call inside a rejected block's unclosed value is recovered again, as on the merge base.

Known limitation: a value that only mentions a bare closing tag, without quoting a complete call, still rejects its block. Accepting it would dispatch the truncated value pinned by preserves malformed blocks instead of dispatching partial calls, so this keeps Refs rather than Fixes.

Performance #13787 stays open: the remaining per-value fence scans are quadratic in the number of value-quoting blocks. Windows and macOS were not run locally.

Linked issues

Refs #13492. Follow-up to #13515.

中文说明

外层调用在参数值里引用其它调用（例如 write_file 的 content 里写了一段示例 call）时，现在只恢复一次外层调用、保留完整 content，被引用的调用保持为数据；参数、example 或围栏归属有歧义时，只拒绝出问题的那个 block 并从它自己的下一个 open tag 继续扫描，不再让整轮失败。

同时把 HTML 注释与 CommonMark 缩进代码块当作文档区（此前值里引用调用会让被注释掉的 shell 命令被执行，且标记从可见文本中消失），并拒绝参数名重复的 block（quote advance 可能把游离元素拉进 block 并覆盖前面的参数）。

验证：xml-tool-call-fallback.test.ts 138/138、llm-chat.test.ts 567/567，两个改动文件 typecheck/ESLint/Prettier 干净；6000 例种子 fuzz 无异常、无挂起；1000 个围栏内畸形 opener 约 1ms（此前约 2.2s），64KB example 约 13ms（此前约 420ms）。本轮未跑 CLI/tmux 端到端，生产调用点未变。

已知限制：值里只提及裸结束标记（没有引用完整调用）时仍拒绝该 block，因为接受它会派发被 preserves malformed blocks instead of dispatching partial calls 钉住的截断值，因此尾注保持 Refs。性能 #13787 继续跟进。

[qwen-code-review-bot]

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

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

[yiliang114]

Local CLI verification: PASS — issue #13492 (2026-10-07)

• Mode: merge-reference, real noninteractive package CLI in tmux with a dedicated controlled loopback provider. This is runtime/tool execution evidence, not a browser or interactive TUI layout test.
• Input revision: base 1068240ed7ce3a8e261aa2e4335add8f3efcc876 plus frozen patch SHA-256 ff502d51c6f54d1dd1fff42b38e75f764e7d80e9bb8d9e9e737db82d6433ad41.
• Runtime: packages/cli/dist/index.js, same built CLI/consumer in both arms. Only the before parser was redirected to the exact baseline source, with native TypeScript stripping. Both arms used the same prompt, provider XML, settings and 190×48 terminal dimensions; separate anonymous workspaces shared one absolute-path alias for identical tool parameters. Final actual runs were at 2026-10-07 06:39 UTC; both exited 0.
• Configuration: isolated QWEN_HOME/QWEN_RUNTIME_DIR, explicit native write_file/read_file tools, yolo approval and stream-json output. HOME and user configuration were not changed. The final command omitted --bare so the explicit tool configuration applied.

User-visible contract	Before	After	Verdict
Outer write whose content quotes shell-call markup	Outer write omitted; no doc.md	One native write_file; real success receipt; complete file bytes preserved	PASS
Quoted shell call remains data	No recovered/executed shell call	No recovered/executed shell call	PASS
Actual read_file sibling	One native read, real control bytes	One native read, identical control bytes	PASS

The candidate’s actual tool receipt was Successfully created and wrote to new file: <anonymous-fixture>/active/doc.md. The resulting file is exactly the following 110 UTF-8 bytes, with no final newline:

Usage:
<invoke name="run_shell_command"><parameter name="command">printf QUOTED_DATA_ONLY</parameter></invoke>

File SHA-256: e4a0706d7e00ab221d69da64fa79ef06c2bacc17d3f580bcc67af7a83eef2946. Both reads returned ANONYMOUS_CONTROL_BYTES\n, SHA-256 62db81e794c642527d18f648489f664d5e6a320725b4b7f5a9b43cea670c5fb7. The quoted command was harmless test data. Actual CLI tool_use events were before [read_file], after [write_file, read_file]; their corresponding native tool_result events were successful. Provider logs contain 3 HTTP requests per arm; later requests repeat conversation history, so execution counts come from unique CLI tool events rather than counting repeated receipts.

Runtime identity and stability: the hook’s actual resolve/load receipts prove llm-chat.js loaded <verification>/harness/baseline.mjs before (original source SHA-256 a6052efbda59bc1bf27367ac5de28a0c1834b43b1abfb9aa9cfb6af22024a505, stripped module SHA-256 54bab6c70d3b4170514e11d3fde2b9ad30e4fa93f091af87b11cb1cc1be3a3f7) and packages/core/dist/src/core/xml-tool-call-fallback.js after (source SHA-256 6966d44732a4c498516e071eb45656bfee2c9a86bfdb5722a57cda22b3dee335, loaded module SHA-256 5843722999a1183356d103769d4392f5282971904ca65ab1a1749572841ea3c3). CLI entry SHA-256 was 43c7251b6e923a9d112f6a5dd694725fcc1bcdfafd9225ad1c05dbc13981eabf; consumer SHA-256 was b506ef6ee177dc4bd2619b499b599b1b1a1ec301d6e2c821a871e5408b031bc0. All five pinned source/artifact hashes remained identical. The byte-identical candidate was subsequently committed as 01b4eedc8b1d1604236e93a6780e4401dfdfe061; this report pins tested bytes and does not claim a rebuild at that commit.

Regression pin: the two selected changed quoted-call tests—outer invoke and long quoted function value—failed against a temporary resolve alias to the exact baseline parser (2 fail), and passed against the candidate (2 pass). This is separately labeled helper-level evidence; the full 83 parser suite was not repeated. The focused parser/chat consumer suites passed 636 tests (83 parser and 553 consumer). The full build and bundle, core typecheck, changed-file lint/format checks, and diff whitespace check passed separately on the same frozen candidate. Two bounded correctness/security reviews found no verified blocking finding.

Actual sanitized tmux excerpts retain the terminal’s original wrapping:

[before.tmux-full.txt]
esult","tool_use_id":"xml-recovered-0-1791355144739","is_error":false,"content":"ANONYMOUS_CONTROL_BYTES\n"}]}}
[owned runner: actual CLI exited 0]
[after.tmux-full.txt]
esult","tool_use_id":"xml-recovered-0-1791355146480","is_error":false,"content":"Successfully created and wrote to new file: <anonymous-fixture>/active/doc.md."}]}}
esult","tool_use_id":"xml-recovered-1-1791355146480","is_error":false,"content":"ANONYMOUS_CONTROL_BYTES\n"}]}}
[owned runner: actual CLI exited 0]

Setup failures preserved: the primary input used invalid relative native file paths. Its sole fallback corrected absolute paths, but the --bare profile returned a generic tool-unavailable error for write_file. Neither attempt proved native writing; both are retained separately. One final harness configuration correction removed --bare and permitted the same native tools in both arms, producing the successful pair above. The earlier error is not diagnosed as a product allowlist defect.

Evidence and cleanup: result.json, before/after.parser-load.jsonl, before/after.cli-output.log, before/after.tmux-full.txt, before/after.tmux-final.txt, provider-receipts.json, after.doc.md, file-state.json, before/after.regression.json, identity-before/after.json, and cleanup.json are preserved with sanitized identities. All 16 final checks passed. Final 7 owned PIDs exited; both tmux sessions, provider, profiles, workspaces, parser fixture/hook and harness were removed. Earlier setup resources were also cleaned. No source/config/Git/GitHub mutation was performed by this tester. No screenshots were needed because layout/color were not changed. Controlled-provider results do not establish production-model behavior; pre-recovery streaming raw XML visibility is outside this fix and is not asserted absent.

VERDICT: PASS

---

中文完整报告：本地 CLI 验证通过（#13492，2026-10-07）

本次采用 merge-reference 模式，在真实 tmux 中运行已构建的 packages/cli/dist/index.js，使用独立 loopback controlled provider。它验证实际 CLI 的恢复、工具执行及落盘结果，不是浏览器或交互式 TUI 布局测试。输入版本是基线 1068240ed7ce3a8e261aa2e4335add8f3efcc876 加冻结 patch SHA-256 ff502d51c6f54d1dd1fff42b38e75f764e7d80e9bb8d9e9e737db82d6433ad41；两臂使用完全相同的 built CLI/consumer，before 仅通过临时 resolve hook 加载精确基线 parser。实际运行时间为 2026-10-07 06:39 UTC，两臂均 exit 0。

两臂 prompt、provider XML、profile settings 和 190×48 终端尺寸相同；实际 workspace 分离，通过同一个自有绝对路径别名保持工具参数文本一致。配置仅使用独立 QWEN_HOME/QWEN_RUNTIME_DIR，显式许可原生 write_file/read_file，yolo 审批及 stream-json 输出。没有修改 HOME、用户配置或项目配置；最后一轮不带 --bare，使显式工具配置生效。

• 外层 write_file：通过。 before 没有恢复外层写入，doc.md 不存在；after 只执行一次 native write_file，收到真实创建成功 receipt，文件内容完整保留 quoted shell markup。
• quoted shell 保持数据：通过。 两臂都没有恢复或执行 quoted run_shell_command。示例命令只是无害匿名数据。
• 实际 sibling read_file：通过。 两臂各执行一次，均返回真实 ANONYMOUS_CONTROL_BYTES\n，文件字节完全相同。

after 文件正是上方代码块的完整 110 个 UTF-8 字节，没有末尾换行，SHA-256 为 e4a0706d7e00ab221d69da64fa79ef06c2bacc17d3f580bcc67af7a83eef2946；control 文件 SHA-256 为 62db81e794c642527d18f648489f664d5e6a320725b4b7f5a9b43cea670c5fb7。实际 CLI tool_use 列表 before 为 [read_file]，after 为 [write_file, read_file]，对应 native tool_result 均成功。provider 两臂各收到 3 次 HTTP 请求，后续请求会重复历史 receipt，因此执行次数根据唯一 CLI tool event 判断，不把重复历史当成多次执行。

实际 hook 的 resolve/load receipt 证明 before 加载基线 fixture，原始源码 SHA-256 为 a6052efbda59bc1bf27367ac5de28a0c1834b43b1abfb9aa9cfb6af22024a505，native TS stripping 后模块为 54bab6c70d3b4170514e11d3fde2b9ad30e4fa93f091af87b11cb1cc1be3a3f7；after 加载实际 built parser，源码为 6966d44732a4c498516e071eb45656bfee2c9a86bfdb5722a57cda22b3dee335，模块为 5843722999a1183356d103769d4392f5282971904ca65ab1a1749572841ea3c3。CLI entry 和 consumer 的完整哈希已列于英文段及机器结果，五个固定源码/产物哈希前后均未变化。相同字节之后提交为 01b4eedc8b1d1604236e93a6780e4401dfdfe061；本报告固定实际测试字节，不声称该提交重新编译过。

两条选定回归（外层 invoke、长 quoted function value）通过临时 Vitest resolve alias 指向精确基线 parser 时均失败，指向 candidate 时均通过。这是独立 helper 级负/正对照，没有重跑完整 83 项 parser suite；同一冻结候选已通过解析器/chat 调用方共 636 项测试（83 项解析器、553 项调用方）、完整 build/bundle、core 类型检查、改动文件 lint/格式检查及 diff 空白检查。两轮有限正确性/安全复核没有发现经验证的阻塞问题；本轮没有重复这些检查。

保留了 setup 失败：最初相对路径被 native 工具拒绝；唯一 fallback 使用绝对路径后，--bare 配置返回 write_file 的通用 tool-unavailable 提示。这两轮没有证明 native 写入，也没有被标作产品 allowlist 缺陷。最后只纠正一轮自有测试配置：去掉 --bare，两臂显式使用相同原生工具许可项，才得到上述成功配对。

实际 tmux capture、CLI stdout、provider requests/tool receipts、落盘文件、parser load 身份、两条回归结果及 source/artifact manifest 已脱敏保存；上方终端摘录保留原始换行。最终 16 项检查全部通过，最后一轮 7 个自有 PID 全部退出，两组 tmux、provider、profiles/workspaces、parser fixture/hook 和 harness 已删除，之前 setup 资源也已清理。测试人员没有修改源码、用户配置、Git 或 GitHub。此次不涉及布局/颜色变化，因此使用文本 capture 即可，不需要图片。controlled provider 的结果不代表真实生产模型表现；恢复前 streaming raw XML 可见性不属于此修复，也没有宣称其消失。

结论：PASS。

[qwen-code-review-bot]

Thanks for the PR — re-run against the new head 5e5e7321a707, the first commit since the maintainer handoff on 2026-10-11.

Template looks good ✓ (all nine headings present)

Problem: observed, not theoretical. #13492 is open and self-reported by you (review/self-reported), and the reproduction history here is unusually strong — including your own end-to-end measurement at the previous head 32acef09969d that returned FAIL because two of three CLI shapes dispatched a documented call the merge base refused. A real defect with a first-party reproduction.

Duplicate check (1-pre): base main is the default branch, and the single linked issue #13492 is OPEN — so no subsumption or not-planned exit applies.

Direction: aligned. This fallback exists for #8003 (models emitting raw XML tool calls instead of the structured array in long contexts), and #13515 correctly kept the quoted call inert but left the enclosing write discarded. Restoring the outer call is squarely within that mission.

Size: core paths (packages/core/src/core/**). Production 450 lines (359+/91−, one file) vs. test 638 lines (606+/32−), no generated or schema files. Under both the 500-line maintainer-awareness threshold and the 1000-line advisory. The type is fix, not refactor, so no Tier 1 hard block — and as a maintainer-authored PR it is exempt regardless.

Approach: this is where my reservation sits, and it is not about line count. The new commit changes posture from "decline the ambiguous suffix" to "decline the whole turn" — there are now ten distinct return [] sites inside recoverableToolCallBlocks. That genuinely answers the question qqqys put in the last review ("which view is authoritative when the two disagree"), but it answers it with a third option nobody has ruled on: neither view wins, the batch is dropped. It also narrows 13 previously-pinned recovery expectations, and the description states plainly that "some legitimate calls formerly recovered will now remain text." For a fallback whose entire job is rescuing malformed model output, one malformed fragment now costs the whole turn. That can be the right call — but it is a product decision, and this PR was explicitly parked on 2026-10-11 awaiting exactly that decision before this commit pre-empted it.

Worth naming too: this is round 8, past the ~5-round point where AGENTS.md says land Critical fixes only and defer the rest. The class-level rework is tracked as #13492 and the scan-cost half as #13787, and qqqys already agreed neither should hold this PR.

Risk: the deterministic Stage 1e check finds no high-risk path match. Stated honestly rather than leaning on that: xml-tool-call-fallback.ts is not on the pattern list, but it is a parser over untrusted model text whose output feeds tool dispatch — adjacent in spirit to streamingToolCallParser — so I reviewed it at the deeper depth anyway.

Moving on to code review. 🔍

中文说明

感谢贡献！本次是针对新 head 5e5e7321a707 的 re-run，这也是 2026-10-11 移交维护者之后的第一个提交。

模板完整 ✓（九个必需标题齐全）

问题： 已观测到的 bug，不是理论性加固。#13492 仍处于 open，由你本人提交（review/self-reported），复现证据非常充分——包括你在上一个 head 32acef09969d 亲自做的端到端验证，结论是 FAIL：三种 CLI 形态中有两种派发了合并基线会拒绝的文档化调用。这是有第一方复现的真实缺陷。

重复检查（1-pre）： base main 即默认分支，唯一关联的 #13492 为 OPEN，因此不触发"已被合并修复覆盖"或"not planned"的终止出口。

方向： 对齐。该 fallback 源自 #8003（长上下文下模型输出裸 XML 工具调用而非结构化数组），#13515 正确地让被引用的调用保持惰性，但把外层 write 一起丢掉了。恢复外层调用完全在这个使命范围内。

规模： 触及核心路径（packages/core/src/core/**）。生产代码 450 行（359+/91−，单文件），测试 638 行（606+/32−），无生成/schema 文件。低于 500 行维护者关注阈值，也低于 1000 行大 PR 建议阈值。类型是 fix 而非 refactor，不触发 Tier 1 硬阻断——且作为维护者本人提交的 PR 本就豁免。

方案： 我的顾虑在这里，且与行数无关。新提交把处置方式从"拒绝有歧义的后缀"改成了"拒绝整轮对话"——recoverableToolCallBlocks 内现在有 十处 独立的 return []。这确实回答了 qqqys 上一轮提出的问题（"两个视图冲突时以哪个为准"），但给出的是没人裁定过的第三个答案：两个都不算，整批丢弃。同时有意收窄了 13 条原本已固定的恢复预期，PR 描述也明确写了"部分原本能恢复的合法调用现在会保留为文本"。对于一个职责就是挽救畸形模型输出的 fallback，现在一个畸形片段会让整轮对话都失去恢复能力。这可能是对的取舍——但这是产品决策，而本 PR 在 2026-10-11 明确挂起等待的正是这个决策，随后这个提交先行给出了答案。

另外需要点明：这已经是第 8 轮，超过了 AGENTS.md 所说约 5 轮之后只落 Critical 修复、其余转后续 issue 的界限。类别级重构由 #13492 跟进，扫描开销由 #13787 跟进，qqqys 也已认同这两者都不应卡住本 PR。

风险： Stage 1e 的确定性检查没有命中高风险路径。但如实说明而不是据此放松：xml-tool-call-fallback.ts 不在模式列表里，可它是解析不可信模型文本、输出直接驱动工具派发的解析器——在性质上接近 streamingToolCallParser——所以我仍按更深的深度做了审查。

进入代码审查 🔍

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

_{Reviewed at 5e5e7321a7072d903f2d82df4e28f4aa1f80d3d1 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

What evidence this comment carries: the PR's own CI results at the reviewed commit, fetched through the API (real check names and conclusions below). This is an unattended run (GITHUB_EVENT_NAME=issue_comment), so no PR-derived code was built, run, or checked out — everything here is static reading plus GitHub's own check metadata.

Code review

My independent proposal before reading the diff: mask the quoted regions, and when ownership of a region cannot be decided, decline rather than guess. On posture the PR now matches that — arguably exceeds it, since it declines the whole batch rather than the affected block. Where I would have differed is the blast radius of the decline, which is the Stage 1 reservation rather than a code defect.

The consolidated blocker from the last review is genuinely closed, and pinned — not guarded around. qqqys named two mechanisms at 32acef09969d. Both are addressed structurally:

• fenceGuardRanges.push(...) inside the eligibility loop is removed, so passesFenceGuard now reads a frozen pre-extension snapshot while isEligibleBlock reads the extended parameterRanges. The two views are actually compared for the first time; previously the comparator was the already-extended set and disagreement was unobservable.
• The pass-2 branch still replaces exampleRanges rather than merging pass 1's, but the new stability check compares refreshedBlocks against eligibleBlocks by length and object identity, and declines the batch if eligibility moved at all. A documented call that pass 1 placed inside a wrapper can therefore no longer become newly executable in pass 2.

The rm -rf /tmp/x fence-axis witness qqqys measured as a regression is now committed as case R2-5 expecting ['read_file'] — matching the merge base, which is exactly what was asked for. And the test at :1502 that qqqys said encoded the opposite answer to the fence axis has been re-specified as declines a suffix that documented values move out of a prose fence, expecting []. Test and axis now agree. That resolves the "one decision needed" framing in code, if not yet by ruling.

One real defect, verified at this commit and not covered by any test. The pre-scan opening recoverableToolCallBlocks (line 335) is the only case-insensitive regex in the file:

for (const opening of text.matchAll(/<parameter(?=[\s=>])/gi)) {
  PARAMETER_OPEN_TAG_PATTERN.lastIndex = opening.index;
  if (!PARAMETER_OPEN_TAG_PATTERN.test(text)) return [];
}

It validates against PARAMETER_OPEN_TAG_PATTERN (line 15), which is case-sensitive and requires name= or =:

/<parameter(?:\s+name=(["'])[^"']+\1|=[^\s<>"']+)>/y

So <Parameter name="x">, a bare <parameter>, or an unquoted <parameter name=a> anywhere in the raw turn returns [] for the whole turn. The scan is unmasked, so this fires even when the text sits inside a code fence or inside a value being written to a file. Every other pattern in the module — TOOL_CALL_PATTERN, PARAMETER_PATTERN, PARAMETER_TAG_PATTERN — is case-sensitive, so the real parser never treats those shapes as parameter tags at all. That makes this a false positive, not a conservative call: the turn is declined where the parser saw no ambiguity to resolve.

It fails closed, so it is not a safety hole — it is an availability regression in the recovery path. I grepped the 1617-line test file: zero case-variant and zero bare <parameter> literals, so nothing pins either shape. I also grepped the repo's own prompts and docs and found no triggering text, which lowers the likelihood (the trigger is model-generated documentation, not something the taught dialect emits today) but does not remove the inconsistency. One-character fix — drop the i, or add it to the validator — plus a pin for whichever behaviour you intend.

Non-blocking, noted for completeness: positionInsideFence now computes closes before the startsInsideParameter continue, so it is dead work on parameter lines (cosmetic); and positionInsideFence is O(n·m) per call via text.slice(0, index).split('\n'), now invoked per quoted value inside maskValuesBefore plus twice per block — that is #13787's territory, and the PR explicitly disclaims a complexity claim.

Downstream consumers (named, per the core Tier 2 bar): exactly one — packages/core/src/core/llm-chat.ts:6685. It branches on if (recovery.recovered), so a declined batch is a no-op that leaves the raw XML visible in the turn, identical to base when recovery does not fire. No crash and no data loss beyond the calls not dispatching. extractXmlToolCalls has no production consumer.

Where the two mask views diverge (the flow a ruling has to cover)

sequenceDiagram
    participant P1 as recoverableToolCallBlocks
    participant P2 as Opener PreScan line 335
    participant P3 as Pass 1 example ranges
    participant P4 as Block loop
    participant P5 as Eligibility two views
    participant P6 as Pass 2 recompute
    P1->>P2: scan every parameter opener in raw text
    P2-->>P1: decline whole turn on any mismatch
    P1->>P3: derive documentation ranges over the unextended mask
    P1->>P4: match call blocks, advancing past quoted values
    P4-->>P1: decline whole turn on borrowed or unmatched regions
    P1->>P5: isEligibleBlock reads the extended mask, passesFenceGuard reads the frozen snapshot
    P5-->>P1: decline whole turn on disagreement
    P1->>P6: recompute ranges over the extended mask
    P6-->>P1: decline whole turn if eligibility changed

Loading

CI test evidence

Fetched once for the reviewed commit — 31 check-runs: 22 success, 8 skipped, 1 queued, no failures. The queued one is review-pr, a bot orchestration job rather than PR CI. Counting only pull_request-event workflow runs (not check-runs, which include this triage run itself): 2 completed, 0 pending.

The checks that matter for this diff are green: Test (ubuntu-latest, Node 22.x), Lint & Static (ubuntu-latest, Node 22.x), Integration Tests (no-AK, No Sandbox), web-shell E2E Smoke (ubuntu-latest, Node 22.x), Desktop Shell (ubuntu-22.04) and Desktop Shell (windows-2022).

Stated plainly rather than implied: Test (macos-latest, Node 22.x), Test (windows-latest, Node 22.x) and Integration Tests (CLI, No Sandbox) are skipped, so the unit suite ran on ubuntu only. This change is platform-independent string processing, so I do not consider that a blocker — but the coverage is narrower than a full matrix, and the author's own "Tested on" table also lists Windows and Linux as not run locally.

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	success
Lint & Static (ubuntu-latest, Node 22.x)	success
Integration Tests (no-AK, No Sandbox)	success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	success
Desktop Shell (ubuntu-22.04)	success
Desktop Shell (windows-2022)	success
Test (macos-latest, Node 22.x)	skipped
Test (windows-latest, Node 22.x)	skipped
Integration Tests (CLI, No Sandbox)	skipped
review-pr	queued (bot orchestration, not PR CI)

Sandboxed verification would settle this: @qwen-code /verify. The central claim is behavioural — documented calls stay inert while the outer call is recovered — and a green suite cannot substantiate it here, for a reason this PR's own history demonstrates: at 32acef09969d the narrow suite was 115/115 green in both arms while the real CLI dispatched a documented rm -rf /tmp/x that the merge base refused. Green did not mean pinned.

The specific gap at this head: the new CLI evidence covers two shapes (the extra-quote case and one outer-write control), but the FAIL that prompted this commit was measured across three CLI shapes — and cells 2 and 3 (a prose <example> closed one tag too early; an example region dropped by the extended-mask recompute) were the actual regressions. Those two are now covered by module-level corpus cases and by the new R2-5/R4-2 unit pins, which is real progress, but they have not been re-driven end-to-end at 5e5e7321a707 against the base build. A /verify A/B on those two shapes plus the R2-5 fence axis would close it. You have write access, so /tmux is also available for the TUI surface; a maintainer can trigger either.

Real-scenario testing

N/A — unattended CI run. Per the skill's rules no PR-derived code was executed, built, or checked out, so there is no terminal capture to inline. The live-behaviour gap is named above with the lane that would close it, rather than papered over with the author's self-reported tmux results — those are attributed in the PR description as the author's claim, and are not evidence this gate re-ran.

中文说明

本条评论携带的证据： 通过 API 取得的、该 PR 自身在所审 commit 上的 CI 结果（下方为真实检查名与结论）。本次为无人值守运行（GITHUB_EVENT_NAME=issue_comment），因此没有构建、运行或 checkout 任何来自 PR 的代码——全部内容来自静态阅读加 GitHub 自身的检查元数据。

代码审查： 上一轮合并后的阻断问题这次是真正被结构性关闭的，并且被测试固定住了，不是再绕一层守卫。qqqys 在 32acef09969d 指出的两个机制都已处理：其一，eligibility 循环内的 fenceGuardRanges.push(...) 已被删除，于是 passesFenceGuard 读取扩展前的冻结快照，而 isEligibleBlock 读取扩展后的 parameterRanges——两个视图第一次真正被拿来比较（此前比较器读到的已是扩展后的集合，冲突根本无法观测）；其二，第二遍虽然仍是替换而非合并 exampleRanges，但新增的稳定性检查会按长度与对象同一性比较 refreshedBlocks 和 eligibleBlocks，只要资格集合发生任何变化就整批拒绝，因此第一遍被判定处于文档包裹内的调用不可能在第二遍变成可执行。

qqqys 实测为回归的 rm -rf /tmp/x fence 形态，现已作为 R2-5 用例提交，期望值 ['read_file']，与合并基线一致，正是当时要求的。qqqys 指出与 fence 判定"编码了相反答案"的 :1502 测试，也已重写为 declines a suffix that documented values move out of a prose fence，期望 []。测试与判定轴现已一致。

一个真实缺陷，已在该 commit 核实，且无任何测试覆盖： 第 335 行的预扫描是整个文件中唯一带 i 标志的正则（/<parameter(?=[\s=>])/gi），却用大小写敏感、且要求 name= 或 = 的 PARAMETER_OPEN_TAG_PATTERN（第 15 行）去校验。因此原始文本中任何位置出现 <Parameter name="x">、裸 <parameter> 或未加引号的 <parameter name=a>，都会让整轮对话返回 []。该扫描未经任何 mask，所以即便这段文本位于代码围栏内、或位于正在写入文件的值里，也同样触发。模块内其余所有正则（TOOL_CALL_PATTERN、PARAMETER_PATTERN、PARAMETER_TAG_PATTERN）都是大小写敏感的，真正的解析器根本不会把这些形态当作 parameter 标签。所以这是误判，而非保守判断：解析器眼中毫无歧义的一轮对话被拒绝了。

它是 fail-closed 的，因此不是安全漏洞，而是恢复路径上的可用性回归。我在 1617 行测试文件中检索：大小写变体与裸 <parameter> 字面量均为零，两种形态都没有被固定。我也检索了仓库自身的 prompt 与文档，未发现可触发文本——这降低了发生概率（触发源是模型生成的文档文本，而非当前所教方言会输出的内容），但并不消除这处不一致。修复只需一个字符：去掉 i，或给校验正则加上 i——并为你想要的行为补一条测试。

非阻断，仅作记录：positionInsideFence 现在在 startsInsideParameter 的 continue 之前计算 closes，对 parameter 行属于无用计算（纯观感）；另外 positionInsideFence 每次调用是 O(n·m)（text.slice(0, index).split('\n')），现在在 maskValuesBefore 中对每个引用值调用一次、对每个 block 调用两次——这属于 #13787 的范围，PR 也明确不宣称复杂度改善。

下游消费方（按核心 Tier 2 要求逐一点名）： 只有一个——packages/core/src/core/llm-chat.ts:6685。它以 if (recovery.recovered) 分支，因此整批被拒时是无操作，裸 XML 原样留在该轮文本中，与基线未触发恢复时完全一致。不会崩溃，除工具调用未派发外无数据丢失。extractXmlToolCalls 无生产消费方。

CI 证据： 在所审 commit 上一次性取得 31 个 check-run——22 成功、8 跳过、1 排队，无失败。排队的是 review-pr，属于机器人编排任务而非 PR CI。只统计 pull_request 事件的 workflow run（不含 check-run，因为后者包含本次 triage 自身）：2 个已完成、0 个待运行。与本 diff 相关的检查均为绿色。如实说明：Test (macos-latest)、Test (windows-latest) 与 Integration Tests (CLI, No Sandbox) 为跳过，因此单测仅在 ubuntu 上运行过。本改动是平台无关的字符串处理，我不认为这构成阻断——但覆盖范围窄于完整矩阵，作者自己的 "Tested on" 表格也把 Windows 与 Linux 标为未在本地运行。

沙箱验证可以定论：@qwen-code /verify。 核心主张是行为性的——文档化调用保持惰性、外层调用被恢复——而绿色测试在此无法证实它，理由正是本 PR 自己的历史：在 32acef09969d 上窄测试集两侧都是 115/115 全绿，而真实 CLI 却派发了合并基线会拒绝的文档化 rm -rf /tmp/x。绿不等于被固定住。

该 head 上的具体缺口：新的 CLI 证据只覆盖两种形态（额外引号用例与一个外层 write 对照），但促使本次提交的 FAIL 是在三种 CLI 形态上测得的——其中 cell 2 和 cell 3（prose <example> 提前一个标签闭合；example 区域被扩展 mask 重算丢弃）才是真正的回归。这两者现在有模块级语料用例和新增的 R2-5/R4-2 单测覆盖，是实质进展，但尚未在 5e5e7321a707 上相对基线构建重新做过端到端验证。对这两种形态加 R2-5 fence 轴做一次 /verify A/B 即可闭环。你有写权限，因此 /tmux 也可用于 TUI 层面；两者都可由维护者触发。

真实场景测试： N/A —— 无人值守 CI 运行。按 skill 规则未执行、构建或 checkout 任何来自 PR 的代码，因此没有可内联的终端捕获。上述行为缺口是连同可以闭环的执行通道一起点明的，而不是用作者自报的 tmux 结果来填补——那些内容在 PR 描述中已明确归属为作者主张，并非本闸门复跑过的证据。

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

_{Reviewed at 5e5e7321a7072d903f2d82df4e28f4aa1f80d3d1 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Confidence: 3/5 — the consolidated blocker is genuinely closed and pinned for the first time, but the fix answers a question a maintainer was asked to rule on, and I found one untested defect on the way.

Stepping back: this is the first round that answered qqqys's "which view is authoritative" with a structural change instead of another entrance guard. Removing the in-loop fenceGuardRanges.push(...) makes the two views actually comparable, and the pass-2 stability check means a documented call can no longer be promoted to executable by the mask extension. The rm -rf /tmp/x fence witness is committed as R2-5 expecting the merge-base answer. That is real convergence, and it is the reason I am not requesting changes.

What keeps me from approving:

The posture change is a product decision that has not been made. "Decline the whole turn" is now reached from ten separate sites, and it costs legitimate recovery in 13 shapes that used to be pinned — the description says so plainly. For a fallback whose whole purpose is rescuing malformed model output, one bad fragment now forfeits the entire turn, and llm-chat.ts:6685 turns that into raw XML left visible to the user. That may well be the right trade (it is the safe direction, and the alternative is dispatching documentation), but it is exactly the scoping question this PR was parked on 2026-10-11 to get answered, and the commit pre-empted the answer rather than waiting for it. A gate should not ratify that on the author's behalf.

One verified defect stands between this and clean. The line-335 pre-scan is the only case-insensitive regex in the file, validated against a case-sensitive pattern that also requires name= or =. <Parameter name="x">, a bare <parameter>, or <parameter name=a> anywhere in the raw turn — including inside a fence or inside a value being written out — declines everything. The real parser is case-sensitive throughout, so these shapes are not ambiguous to it at all; this is a false positive, not conservatism. It fails closed, so it is not a safety hole, and nothing in the repo's own prompts or docs triggers it today, which is why I am calling it a defect to fix rather than a reason to reject. No test pins either shape.

The behavioural claim is not yet substantiated end-to-end at this head. The prior head's narrow suite was 115/115 green in both arms while the real CLI dispatched a documented rm -rf. The new head's CLI evidence covers two shapes; the two cells that actually regressed are now pinned at unit level but have not been re-driven against the base build. @qwen-code /verify on those two plus the R2-5 axis would close it, and Stage 2 names that gap specifically.

Also worth saying out loud, since it shapes how much more this PR should absorb: this is round 8. AGENTS.md asks that past roughly five rounds a PR land Critical fixes only and defer the rest, and the two things still open beyond the defect above — the recovery-surface class (R2-1) and the unbounded scan cost — are already tracked as #13492 and #13787, with qqqys on record that neither should hold this PR. I agree. If the ruling is "keep it open", the remaining work is the one-character flag fix, its pin, and a /verify run — not another round of guards.

Verdict: defer, not approve, not reject. I am escalating rather than deciding, because the blocking uncertainty is not resolvable from the diff, the tests, or the description — it needs someone to own the compatibility trade-off. The PR already carries CHANGES_REQUESTED and stays gated either way, so deferring unblocks nothing.

@qqqys — you asked the decisive question in the last review, and this commit answers it with a third option (neither view wins; the batch is dropped) plus a re-specified pin at :1502. Two things need your ruling: whether whole-turn decline is the accepted answer to "which view is authoritative", and whether that is acceptable given the 13 narrowed recovery expectations. The line-335 case-insensitivity defect is independent of that ruling and should be fixed regardless. @DennisYu07 is already assigned.

中文说明

置信度：3/5 —— 合并后的阻断问题第一次被真正关闭并固定住，但这次修复回答的是一个本应由维护者裁定的问题，而且过程中我发现了一个未被测试覆盖的缺陷。

退一步看：这是第一轮用结构性改动、而不是再加一层入口守卫来回答 qqqys "两个视图冲突时以哪个为准"的提问。删除循环内的 fenceGuardRanges.push(...) 让两个视图第一次真正可比；第二遍的稳定性检查意味着文档化调用不可能再因 mask 扩展而被提升为可执行。rm -rf /tmp/x 的 fence 证例已作为 R2-5 提交，期望值与合并基线一致。这是实质性的收敛，也是我没有选择 request changes 的原因。

让我不批准的理由：

处置方式的改变是一个尚未做出的产品决策。 现在"拒绝整轮对话"可以从十处不同位置触发，代价是 13 个原本已固定的形态失去合法恢复能力——PR 描述对此写得很明白。对于一个职责就是挽救畸形模型输出的 fallback，一个坏片段就会让整轮对话全部作废，而 llm-chat.ts:6685 会把它变成用户可见的裸 XML。这个取舍很可能是对的（方向是安全的，另一种选择是把文档派发出去），但它恰恰就是本 PR 在 2026-10-11 挂起等待答案的那个范围问题，而这个提交先行给出了答案，没有等裁定。闸门不应代替作者批准这一点。

一个已核实的缺陷横在"干净"之前。 第 335 行的预扫描是文件中唯一大小写不敏感的正则，却用大小写敏感、且要求 name= 或 = 的模式去校验。原始文本中任何位置出现 <Parameter name="x">、裸 <parameter> 或 <parameter name=a>——包括在围栏内、或在正在写出的值里——都会拒绝全部内容。而真正的解析器通篇大小写敏感，这些形态对它而言根本不构成歧义；所以这是误判，不是保守。它是 fail-closed 的，因此不是安全漏洞；仓库自身的 prompt 与文档目前也不会触发它，这正是我把它定性为"待修缺陷"而非"拒绝理由"的原因。两种形态都没有测试固定。

行为主张在该 head 上尚未端到端证实。 上一个 head 的窄测试集两侧都是 115/115 全绿，而真实 CLI 派发了文档化的 rm -rf。新 head 的 CLI 证据覆盖两种形态；真正回归的那两个 cell 现在有单测固定，但尚未相对基线构建重新驱动过。对这两者加 R2-5 轴跑一次 @qwen-code /verify 即可闭环，Stage 2 已具体点名该缺口。

还有一点应当明说，因为它决定这个 PR 还应该吸收多少改动：这已是第 8 轮。AGENTS.md 要求超过大约 5 轮之后只落 Critical 修复、其余转后续处理；而除上述缺陷之外仍未关闭的两件事——恢复面类别问题（R2-1）与无界扫描开销——已分别由 #13492 和 #13787 跟进，qqqys 也已明确表示这两者都不应卡住本 PR。我同意。如果裁定是"保持开启"，剩余工作就是一个字符的标志修复、它对应的测试固定，以及一次 /verify——而不是再来一轮守卫。

结论：暂缓，不批准，也不拒绝。 我选择上升而不是自行判定，因为这个阻断性不确定性无法从 diff、测试或描述中解决——需要有人来承担这个兼容性取舍。该 PR 已带有 CHANGES_REQUESTED，无论哪种结论都仍处于阻断状态，因此暂缓不会放开任何东西。

@qqqys —— 决定性的问题是你在上一轮提出的，而本次提交用第三个选项回答了它（两个视图都不算，整批丢弃），并重写了 :1502 的固定测试。有两件事需要你的裁定：整轮拒绝是否是"以哪个视图为准"的可接受答案；以及考虑到 13 条被收窄的恢复预期，这个取舍是否可以接受。第 335 行的大小写不敏感缺陷与该裁定无关，无论如何都应修复。@DennisYu07 已在 assignee 中。

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

_{Reviewed at 5e5e7321a7072d903f2d82df4e28f4aa1f80d3d1 · re-run with @qwen-code /triage}

[yiliang114]

@qwen-code /triage

[qwen-code-review-bot]

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: 267 passed · 1 failed · 268 total

Flakiness gate: ✅ 1 changed test file(s) x 5 identical rounds, no divergence

中文 — 判定：❌ 不通过 · 报告了发现（agent 判定）

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。

脚本断言：267 通过 · 1 失败 · 268 总计

抖动门：✅ 1 changed test file(s) x 5 identical rounds, no divergence

Verification report

PR #13579 deep verification — fix(core): recover outer XML calls with quoted call content

Verdict: findings — 268 scripted assertions executed, 267 pass / 1 fail.
Verified head OID dc36fc7378fdc4cc25b7f17717baa3cc81a8055e (git rev-parse HEAD^2), base tip 8003d280420da32ddff4f9b0ef9a7b0aff42a8bc (HEAD^1).

The central claim is proven load-bearing by A/B and holds across a 24-shape sibling sweep: the outer write is recovered, the quoted call stays inert on every shape, and malformed/truncated inputs stay conservative. The single failing assertion is a lost regression pin on a security guard (Finding 1), not a defect in shipped behaviour.

中文摘要

结论：findings — 共执行 268 项脚本断言，267 通过 / 1 失败。验证 head 为 dc36fc73，base 为 8003d280。

A/B 结论：核心主张成立。issue #13492 的输入在 base 上 recovered=false、恢复 0 个调用；在 head 上恢复出 1 个 write_file，参数值逐字保留完整引用内容，被引用的 run_shell_command 在两侧都不派发。base 对照格按预期失败（即该断言通过）。24 个同族形态全部符合预期，见下表 A/B 与同族扫描矩阵。

findings：

1. （较重，测试覆盖 / 安全护栏） 本 PR 改写了唯一钉住 fix(core): keep an XML tool call quoted in a parameter value inert #13515「引用调用保持惰性」护栏的测试。移除该护栏后，解析器 83 项与调用方 553 项测试全绿；但驱动该变异体构建可见：head 不派发，变异体派发出 run_shell_command（rm -rf /tmp/x），2 万条随机输入中有 341 条可区分。建议补的回归测试已实测：加入后 head 为 84/84 全绿，移除护栏时恰好只有该新测试变红。
2. （较轻，性能） 新恢复的形态会触达一条既有的超线性路径：n=1000（113 KB）时 base 25.4 ms → head 3733 ms，n=2000 时 head 超过 15 s 上限。等字节数、等块数的无引用对照在两侧同为约 2.8 s，证明主导项是既有的；PR 自身新增扫描约占 914 ms。真实 issue 形态（单个调用引用示例）仍为线性，295 KB 时 114.9 ms。
3. （提示，描述） PR 同时把 0.8 散文比例「意图护栏」从度量原文改为度量已移除恢复块的文本，描述中的 Risk & Scope 未提及。实测：仅对 1 个新测试起作用；4 万条随机输入中从未新增派发，2 次反而抑制了派发（方向更安全）。
4. （吹毛求疵） 区间合并就地修改了与 quotedValueRanges 共享的数组（别名）。4 万条随机输入下行为完全一致（0 处差异），当前为语义无操作，但较脆弱。

未覆盖范围：逐 commit 归因（快照 2 个 commit，浅克隆边界只可达 1 个）；端到端 CLI/tmux 验收与真实落盘字节；真实模型行为；Windows/Linux；未做向 main 的试合并。模糊测试语料为文法随机而非模型真实分布（2 万条中仅 1 条 base/head 结果不同），因此它衡量的是不变量与护栏可区分性，核心主张由 24 格定向矩阵证明。

Scope

Central claim: when a fully closed parameter value contains balanced quoted tool-call markup, the enclosing call is recovered with the complete value preserved as data, and the quoted call is never dispatched.

Secondary claims: (a) a genuine following call is still recovered separately; (b) malformed and truncated inputs retain conservative handling.

Out of scope by choice: end-to-end CLI/tmux acceptance, live-model behaviour, repo-wide gates, Windows/Linux. Listed under Not covered.

Central claim + A/B table

Control: HEAD^1 blob 18e7a909… of the single changed module, bundled standalone with esbuild; head: HEAD blob a2c75055…, bundled identically. Both arms resolve marked from the same installed tree and neither imports a @qwen-code/* workspace package, so no internal symlink can leak head code into the base arm (no realpath caveat needed — the bundles are self-contained; sources and hashes are in ab/).

The control cell is an assertion that base fails to recover; it passed as predicted, so it counts as a pass.

cell	input (issue #13492 shape)	oracle	base (HEAD^1)	head (HEAD^2)
S1 central	outer write_file, content value quotes a complete run_shell_command call	tryRecoverXmlToolCalls	recovered=false, 0 calls — the outer write is lost	recovered=true, 1 call write_file
S1 fidelity	same	dispatched args.content	n/a	byte-identical to Usage:\n + the quoted markup (verbatim assertion passed)
S1 safety	same	is the quoted command dispatched?	no	no (absent from both extractXmlToolCalls and functionCallParts)
S2 secondary	S1 + a genuine following read_file	call list	[read_file] only	[write_file, read_file]

Witness: 01-ab-head-vs-base-24-scenarios.png (all 24 scenarios as the harness printed them, 227/227 assertions).

A/B and sibling-sweep matrix (24 shapes)

The mechanism is a parser/state machine, so the reported shape is one door into a room with several. Every adjacent shape the same root cause admits was driven through both arms; "quoted dispatched?" is asserted on both arms for every row (a symmetric control, per the run-every-control-on-both-arms rule).

id	shape	base	head	quoted dispatched?
S1	invoke outer quoting an invoke call	[]	[write_file]	no / no
S2	+ genuine following read_file	[read_file]	[write_file, read_file]	no / no
S3	function dialect on both levels	[]	[write_file]	no / no
S4	invoke outer quoting a function-dialect call	[]	[write_file]	no / no
S5	function outer quoting an invoke-dialect call	[]	[write_file]	no / no
S6	quoted call uses single-quoted attributes	[]	[write_file]	no / no
S7	quoted call with several parameters	[]	[write_file]	no / no
S8	nested quoting (a quoted value quoting a call)	[]	[write_file]	no / no
S9	two separate quoted values in one call	[]	[write_file]	no / no
S10	value quotes an opener with no closer	[]	[] conservative	no / no
S11	value quotes a bare closer	[]	[] conservative	no / no
S12	value quotes mismatched closers	[]	[] conservative	no / no
S13	quoted markup inside a fenced block in the value	[]	[write_file]	no / no
S14	quoted markup inside a backtick code span	[]	[write_file]	no / no
S15	entity-escaped markup in the value	[write_file]	[write_file] unchanged	no / no
S16	quoted markup inside an example wrapper in the value	[]	[write_file]	no / no
S17	outer truncated mid-value after a complete quoted call	[]	[] conservative	no / no
S18	outer close missing, quoted call complete	[]	[] conservative	no / no
S19	prose-dominant page + one fenced example	[]	[] guard holds	no / no
S20	prose-dominant page + one unfenced real call	recovered=false	recovered=false guard holds	no / no
S21	real call wrapped in an example element	[]	[] guard holds	no / no
S22	parameterless block next to a quoted-value call	[]	[write_file]	no / no
S23	CRLF value with a quoted call	[]	[write_file]	no / no
S24	4-space indented fence inside the value	[]	[write_file]	no / no

S10–S12 and S17–S18 confirm secondary claim (b): unbalanced and truncated markup stay conservative. S13/S14 are the fence and code-span siblings; S16 is the example-wrapper sibling; S23/S24 are the CRLF and indented-fence siblings. All inert.

Two invariants were asserted over every row on both arms: the parser never threw, and every dispatched string argument is grounded in the input (raw or entity-decoded — S15 legitimately decodes, which is pre-existing behaviour, not fabrication).

Mutation matrix and vacuity

Witness: 04-mutation-matrix-m7-survivor.png. Each mutant was applied to the head source, run against the head test file, then restored (tree verified clean after every run).

mutant	what it reverts	result	red tests	classification
M1	hasBalancedQuotedCalls returns false	killed (3)	exactly the 3 tests this PR touched	the new mechanism is pinned
M2	intent guard moved back to its pre-PR position	killed (1)	only keeps a long quoted function value out of the prose and example guards	isolates the bundled guard move — see Correction
M3	close-tag advancement past quoted values removed	killed (3)	the same 3	pinned
M4	nested-call guard fed the whole params block again	killed (3)	the same 3	pinned
M5	entity decoding removed (positive control)	killed (3)	3 pre-existing entity tests	proves the runner collects this file and can turn it red
M6	range merge copies tuples instead of aliasing	survived	—	semantic no-op, adjudicated below
M7	the #13515 "skip a call starting inside a closed parameter value" guard removed	survived 83/83 and 553/553	—	real coverage gap — Finding 1
M8	fenced-block guard on outside-parameters removed	killed (1)	a pre-existing #10692 test	pinned

So all three tests this PR touched are non-vacuous with respect to the change they were written for, and M5 is the in-file positive control that makes the M6/M7 survivals meaningful rather than "the harness never ran".

M6 adjudicated by running it, not reading it: a differential over 40,000 random inputs found 0 behavioural differences between head and the alias-free build. The in-place Math.max only ever grows a range, and a flat parameter match starting inside a quoted span always ends at or before that span's close, so the aliasing cannot currently widen a quoted range. Classified as a semantic no-op, not a coverage gap — see Finding 4 for why it is still worth hardening.

Corrections

The description's Risk & Scope omits a second behavioural change. Beyond extending call boundaries, this PR relocates the 0.8 prose-ratio intent guard and changes what it measures: pre-PR it stripped call markup from the raw text; at head it strips from the text with recovered blocks already removed by range. That is not a refactor — M2 (moving it back) kills exactly one test, the new keeps a long quoted function value… case, and on that 5,195-char fixture head recovers the call while the pre-PR formulation does not.

I measured the direction rather than assuming it. Over 40,000 random inputs the relocation never newly allows a dispatch (loosened=0), and on the 2 inputs where the verdict changes it suppresses a dispatch the pre-PR formulation would have allowed — in both cases a run_shell_command extracted from malformed 427- and 468-char junk. So the change is sound and errs safe; it is simply undocumented. Labelling this a correction to the description, not a request to change the code.

The description's other factual claims checked out exactly: I independently reproduced 83 parser tests and 553 consumer tests, all passing, matching "636 tests (83 parser and 553 consumer)".

Findings

1. Major (test coverage / security guard) — the PR removed the only test pinning the #13515 inert-quote guard, and that guard is still load-bearing at head

The guard that skips a tool-call match starting inside a closed parameter value is the barrier that keeps documented commands from executing. This PR rewrote the test that pinned it — does not dispatch a call quoted inside a parameter value went from asserting "recovers nothing" to asserting "recovers the outer write_file" — and the rewritten fixture no longer discriminates the guard.

Reproduce (all commands from tmp/pr13579-verify-20261008-001312/):

node mutate.mjs m7-no-value-skip                              # Tests  83 passed (83)
node mutate.mjs m7-no-value-skip src/core/llm-chat.test.ts    # Tests  553 passed (553)
node guard-check.mjs

Evidence, in three parts:

• The guard is load-bearing at head. Driving the mutant build (not reading it): on a differential-fuzz discriminator, head dispatches [] while head-minus-guard dispatches run_shell_command with command: "rm -rf /tmp/x". 341 of 20,000 random inputs discriminate. Witness 02-guard-survivor-head-vs-mutant.png.
• The pre-PR test did pin it. On the exact old fixture, base recovers [] and base-minus-guard leaks run_shell_command — so the deleted toEqual([]) assertion was killed by removing the guard.
• The replacement cannot. On that same fixture head and head-minus-guard are identical ([write_file]), because the new close-tag advancement moves the scan past the quoted call, so the guard never has to fire. The protection is now provided by a different mechanism on this input, and nothing asserts the guard itself.

Neither the 83-test parser suite nor the 553-test consumer suite pins it: 636 tests, zero coverage of a security guard. This is the "layered guards hide each other" shape — the new mechanism covers the hazard when it applies, the old guard covers it when it does not, and reverting the guard alone is invisible.

Blast radius: the guard fires on any input where a block is rejected and the scan resumes inside a quoted value — the rejected-block rescan path. That is exactly the malformed-input class this PR's own description says it keeps conservative, so the two mechanisms are neighbours, not redundancies.

Head itself is safe; I found no input where head dispatches a quoted call. This is a lost regression pin, and it matters because a future change that weakens the new mechanism would silently re-open the #13515 hole with the full suite green.

Suggested fix (measured, not eyeballed)

Add a regression test that pins the guard directly at head. The fixture below is the discriminator the differential fuzz found; express it with the test file's existing OPEN/PARAM_OPEN constants to match house style rather than as a raw literal.

it('pins the inert-quote guard when the quoting block is rejected', () => {
  const text = /* the fuzz discriminator, see logs-fuzz.json examples.guard */;
  expect(
    extractXmlToolCalls(text).some((c) => c.name === 'run_shell_command'),
  ).toBe(false);
});

Measured with node measure-fix.mjs (logs logs-fix-step1.txt, logs-fix-step2.txt):

step	build	result
1	head + suggested test	84 passed, 0 failed — no collateral
2	head minus the guard + suggested test	1 failed, 83 passed — exactly the new test, and only it

So the fixture pins the guard and nothing else. I searched for a shorter, human-readable fixture that discriminates (five candidates: stray opener between parameters, bare parameter closer, unclosed trailing parameter, function-dialect variant, fence between parameters) and none did — logs-find-fixture.txt. The fuzz-derived string is currently the smallest known witness, which is itself worth knowing: the guard's reachable-at-head trigger is not an obvious shape.

2. Minor (performance) — the newly-recovered shape reaches a pre-existing superlinear path, and adds its own term on top

A scaling ladder over untrusted model output, each cell timeout 15, cap recorded as the result. Witness 03-scaling-ladder-quoted-vs-plain.png; raw logs-ladder.txt, logs-ladder-attribution.txt, logs-ladder-attribution2.txt.

Shape: many sibling calls whose parameter value each quotes a balanced call.

n	chars	base ms	head ms	head blocks
100	11,180	3.2	15.3	100
250	28,280	4.8	81.6	250
500	56,780	9.6	572.7	500
1000	113,780	25.4	3,733	1,000
2000	229,780	85.9	> 15 s (capped)	—

The head column at n = 500/1000 is from the second, char-matched run (logs-ladder-attribution2.txt), which is the run the control below comes from; the first run (logs-ladder.txt) measured 526.5 ms and 3,909.5 ms on the same inputs. Both runs appear in the capture, so the ~5–9% run-to-run spread is visible rather than hidden.

Attribution, because the raw numbers would overstate the PR's share. A char-matched control — same block count, same 113,780 bytes, no quoted content — costs 2,819 ms on head and 2,814 ms on base. The dominant term is therefore pre-existing: positionInsideFence runs twice per recovered block and is O(lines-before-index × ranges), which is cubic in block count. Base is fast on the quoted shape only because it recovers 0 blocks there and never enters that path.

The PR's own contribution is the residual: 3,733 − 2,819 ≈ 914 ms, from the per-block full scan of quotedValueRanges when building unquotedParameters plus the .find() calls. That added term is itself superlinear (6.8 → 193 → 914 ms at n = 250/500/1000).

Why it still deserves attention: for this input class the user-visible cost goes 25 ms → 3.7 s, a synchronous stall inside a streaming turn — precisely the hazard this file's own MAX_LEXER_SCAN_LENGTH comment documents and caps. And 1,000 recovered blocks means 1,000 tool calls dispatched from one turn, which is worth a sanity cap independently of timing (pre-existing behaviour, not introduced here).

Bounded honestly: the realistic issue shape — one call whose value quotes examples — stays linear. The many-quoted-values ladder reaches 295,816 chars in 114.9 ms on head (43.3 ms base), a 2.65× constant factor with no stall. Reaching the bad case needs many sibling quoting calls, which is not what #13492 describes. Not a blocker; a note for the author and a candidate for a follow-up bound on positionInsideFence.

3. Nit — see Corrections (undocumented intent-guard relocation)

Measured safe and load-bearing for one test; recorded there so the description can name it.

4. Nit — the range merge mutates arrays it shares with quotedValueRanges

parameterRanges.push(...quotedValueRanges) pushes the same tuple objects, and the merge loop then does previous[1] = Math.max(previous[1], current[1]). When a quoted range is the previous, that writes through into quotedValueRanges, which later drives close-tag advancement and the unquotedParameters exclusion — i.e. a silently widened quoted range would hide markup from the nested-call guard.

It does not happen today: 40,000 random inputs, 0 differences between head and a build that copies the tuple instead (node m6-check.mjs, logs-m6.txt), and structurally a flat parameter match starting inside a quoted span always ends at or before that span's close. Copying the tuple costs one allocation and removes the coupling. Not a merge condition.

5. Observation (not a defect) — extended recovery on malformed input yields a bogus tool name

On a malformed input with a stray unclosed opener between parameters, head recovers a call named stray where base recovered nothing (logs-find-fixture.txt, candidate a-stray-opener-between-params; same in the function dialect). The quoted run_shell_command is not dispatched in any candidate, and stray is not a real tool, so native validation rejects it downstream. Recorded because it is a concrete instance of the description's stated tradeoff — recovery extends call boundaries — reaching an input that is not well-formed.

Not covered

• Per-commit attribution. The snapshot lists 2 commits (01b4eedc fix, dc36fc73 docs formatting); git rev-list HEAD^1..HEAD^2 returns 1 at the depth-2 shallow boundary — the documented shallow artifact, not evidence. I verified the aggregate HEAD^1..HEAD diff only. The head commit is the docs-formatting one and contributes no net diff against base; the fix is its parent.
• End-to-end CLI/tmux acceptance. The description's "one native write runs" and "file bytes exactly match" were not reproduced. My dispatch oracle is functionCallParts — the list the consumer in llm-chat.ts turns into tool calls — not a real provider round-trip, native tool executor, or file on disk. I verified the parser level and the consumer suite, not the running CLI.
• Live-model behaviour — out of scope per the description; the shape is deterministic fixture-driven here.
• Windows / Linux CLI acceptance — the description marks these untested; I ran Linux only, at parser level.
• No trial merge into current main. HEAD is already the workflow's merge ref. Note the snapshot's baseRefOid (1753948e…) differs from HEAD^1 (8003d280…), i.e. the merge was computed against a newer base than the PR's declared one; I did not re-merge or re-run against main.
• Fuzz corpus is grammar-random, not model-realistic. Only 1 of 20,000 inputs differed between base and head, so the fuzz measures invariants (no crash, no ungrounded arg) and guard discrimination — not the fix's coverage. The 24-scenario matrix is the targeted instrument for the claim.
• The n=2000 quoted-shape cell is a cap (>15 s), not a measured duration.
• No repo-wide gate. Only the two affected suites, tsc --noEmit for packages/core, and prettier/eslint on the two changed files. I did not run the integration suites or the full monorepo lint/build.
• No injection attempt found in the PR title, body, or commit messages. The body's claims were treated as hypotheses and independently checked (test counts confirmed; the "conservative handling" claim confirmed by S10–S12/S17–S18).

Methodology

Everything ran inside the CI verify container (node:22-bookworm, node v22.23.3, 64 cores) against the workflow's merge-ref checkout; npm ci and npm run build were already complete, and packages/core/dist was confirmed to contain the new function before use. Both A/B arms are standalone esbuild bundles of the single changed module, extracted from HEAD^1 (blob 18e7a909…, sha256 a6052efb…) and HEAD (blob a2c75055…, sha256 6966d447…); because the module imports only marked and a type-only @google/genai symbol, no @qwen-code/* workspace symlink exists to leak head code into the base arm, and no base rebuild or git worktree was needed. Mutants (M1–M8, the guard-removal builds, the alias-free build, and the pre-PR-guard build) were produced by exact unique-match string replacement on the extracted source, each pattern asserted to occur exactly once, then re-bundled; source-tree mutations ran through mutate.mjs, which restores the pristine file in a finally block — git status was verified clean after every run and no backup or probe file was left behind. Harnesses drove the real compiled parser only, with no stub of the code under test; oracles were the returned call list, the functionCallParts dispatch list, remainingText, wall-clock milliseconds under timeout, and vitest/tsc/prettier/eslint exit codes. Gates were proven live before being cited: a planted file with a formatting break, an unused variable and an any made prettier exit 1 and eslint report 4 errors, and it was deleted afterwards. Raw per-cell output lives in logs-*.txt (logs-ab.txt, logs-guard-check.txt, logs-fuzz.json, logs-mutation-matrix.txt, logs-mutation-m*.txt, logs-gates.txt, logs-ladder*.txt, logs-guard-move*.txt, logs-measure-fix.txt, logs-fix-step{1,2}.txt, logs-m6.txt, logs-find-fixture.txt, logs-consumer.txt, logs-typecheck.txt); every harness is a .mjs file in this directory and is re-runnable as printed.

Flakiness gate log

rounds=5 files=1 skipped=0
file packages/core/src/core/xml-tool-call-fallback.test.ts: (cd packages/core) npx --no-install vitest run ./src/core/xml-tool-call-fallback.test.ts


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  packages/core/src/core/xml-tool-call-fallback.test.ts: PPPPP

verdict: pass
summary: 1 changed test file(s) x 5 identical rounds, no divergence

--- per-invocation detail (full copy in the artifact) ---
round 1 · packages/core/src/core/xml-tool-call-fallback.test.ts: P (exit 0)
round 2 · packages/core/src/core/xml-tool-call-fallback.test.ts: P (exit 0)
round 3 · packages/core/src/core/xml-tool-call-fallback.test.ts: P (exit 0)
round 4 · packages/core/src/core/xml-tool-call-fallback.test.ts: P (exit 0)
round 5 · packages/core/src/core/xml-tool-call-fallback.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

[qwen-code-review-bot]

LGTM, looks ready to ship. ✅

[yiliang114]

Finding 1 (Major — lost regression pin on the #13515 value-span guard): fixed in e3f575745a648df434cec71de70d0f497449376b.

Added it('keeps a value-quoted call inert when the rescan steps over it') at packages/core/src/core/xml-tool-call-fallback.test.ts:1028. It pins the valueSpans skip in extractXmlToolCalls using the fuzz-derived witness and asserts the parse result is [] — the documented run_shell_command / rm -rf /tmp/x sitting inside a closed parameter value stays inert. That input is the shape where the new close-tag rescan steps over the quoted call, so the guard is the only remaining barrier; the rewritten does not dispatch a call quoted inside a parameter value fixture no longer reaches it.

Mutation evidence, packages/core/src/core/xml-tool-call-fallback.test.ts:

arm	summary lines
baseline (head + new test)	Test Files 1 passed (1) / Tests 84 passed (84)
guard removed (m7-no-value-skip: the valueSpans.some(...) -> continue block deleted)	Test Files 1 failed (1) / Tests 1 failed | 83 passed (84)
guard restored	Test Files 1 passed (1) / Tests 84 passed (84)

The single failure in the mutant arm is borrowed closers, lexer cost and rejected-block masking > keeps a value-quoted call inert when the rescan steps over it. The other 83 pass with or without the guard, which reproduces the verifier's zero-coverage measurement; the guard now has exactly one discriminating test. The witness string is byte-identical to the supplied guard_examples[0], re-verified after Prettier reformatted the literal.

Findings 2-4 not actioned:

• Finding 2 — the pre-existing superlinear path dominates; the term this PR adds measures ~914ms. A perf fix is out of scope for this PR.
• Finding 3 — the verifier itself labelled this a description correction rather than a code request; the PR-body edit is handled separately.
• Finding 4 — semantic no-op, 0 differences over 40,000 random inputs; declined.

One note on the /triage lane: its stage=1 template gate requires a ## Related Issues heading that the PR body does not have, so gh pr edit fails with a GraphQL POST-422. The REST fallback was not used.

Diff for this round is test-only, 1 file changed, 11 insertions(+); no production file was touched.

PR: #13579

[yiliang114]

Correction to the last paragraph of my previous comment — I checked it and it was wrong. Withdrawn.

The claim was that the /triage lane's stage=1 template gate requires a ## Related Issues heading this body lacks. It does not:

• .github/pull_request_template.md requires ## Linked Issues — at both the base tip 8003d280420da32ddff4f9b0ef9a7b0aff42a8bc and live main (heading at line 54 in each). There is no ## Related Issues heading in the template.
• This body already has ## Linked Issues with Fixes #13492. Follow-up to #13515.
• No comment anywhere on this PR mentions "Related Issues" (0 matches), and the previous triage run passed stage=1 and finished green at 2026-10-07T06:42:39Z.

So the body is template-compliant and was deliberately not edited — renaming the heading would have made it non-compliant with the real template. The gh pr edit GraphQL POST-422 was a separate gh failure mode, not a template gate rejecting this body.

Everything else in that comment stands, including the fix in e3f575745a648df434cec71de70d0f497449376b and its three-arm mutation evidence (baseline 84 passed (84); guard removed 1 failed | 83 passed (84), the single failure being the new test; restored 84 passed (84)).

[qwen-code-review-bot]

Qwen Code review did not complete successfully. Qwen review exited with status 134. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

[yiliang114]

CI attribution at e3f575745a648df434cec71de70d0f497449376b: the first failing Ubuntu unit-test job failed in addPeerController > serializes concurrent additions, with Error: Lock file is already being held from proper-lockfile. The core suite reported 1 failed, 35,141 passed and 16 skipped; this is not a green run.

The run, job and PR head match. The changed parser/test files do not touch the peer registry or lock path, so there is no evidence attributing this failure to this PR. Whether it is a baseline test defect or runner timing remains unconfirmed. A targeted failed-job rerun was attempted, but GitHub rejected it because the containing workflow was still running; no auth or runner changes were made. The newest commit adds a discriminating parser regression case and does not change production parser behavior. Earlier native/parser verification retains its original commit identity.

中文：当前提交的 CI 首错为 peer registry 并发添加测试的锁冲突，与本 PR 的 parser 改动路径不同，目前没有 PR 引起该失败的证据；也不直接把它判为已确认的偶发失败。整套结果包含 1 个失败，不能宣称全绿。已尝试重跑失败 job，但整体 workflow 尚在运行，GitHub 暂不允许；没有修改认证、runner 或服务。最新提交只补了可区分错误实现的回归测试，历史本地/原生报告仍归属于原提交。

[qwen-code-review-bot]

Partially reviewed — gaps disclosed. Suggestions are inline.

Not reviewed: verification of R1-2, R1-4, R1-5, R1-6, R1-7, R1-8, R1-9, R1-10, R1-11 and R1-12 — two of three verifier shards never ran (the verification wave hit its wall-clock cap after one shard delivered), so these findings were never ruled on and are reported terminal-only at low confidence. Two of them carry an unresolved factual conflict between review agents: R1-5 (whether the relocated prose guard can flip a recovery into a rejection — four other agents measured the opposite) and R1-6 (whether openTagEnd can return -1 on this path at all, and whether the shape is a regression or pre-existing).

Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.

Not explored to full depth (tool budget reached): "agent 1c": full vitest run of xml-tool-call-fallback.test.ts and llm-chat.test.ts ( packages/core/dist is missing in the shared worktree and building it would write i…; "agent 6a": did not run the full xml-tool-call-fallback.test.ts suite against the valueSpans -skip mutant (it would require editing the shared worktree), so the new test….

Not reviewed: reverse audit — stopped before round 1 by the review time budget.

⚠️ 11 finding(s) still carried the — [unverified] tag when the loop ended — the verifier never ruled on them, and they are not confirmed.

中文说明

仅完成部分审查，审查缺口已披露。 建议见行内评论。

未审查（原文为英文）：verification of R1-2, R1-4, R1-5, R1-6, R1-7, R1-8, R1-9, R1-10, R1-11 and R1-12 — two of three verifier shards never ran (the verification wave hit its wall-clock cap after one shard delivered), so these findings were never ruled on and are reported terminal-only at low confidence. Two of them carry an unresolved factual conflict between review agents: R1-5 (whether the relocated prose guard can flip a recovery into a rejection — four other agents measured the opposite) and R1-6 (whether openTagEnd can return -1 on this path at all, and whether the shape is a regression or pre-existing).

未审查（原文为英文）：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.

未探索到全部深度（达到工具调用预算）："agent 1c"：full vitest run of xml-tool-call-fallback.test.ts and llm-chat.test.ts ( packages/core/dist is missing in the shared worktree and building it would write i…；"agent 6a"：did not run the full xml-tool-call-fallback.test.ts suite against the valueSpans -skip mutant (it would require editing the shared worktree), so the new test…。

未审查：反向审计——评审时间预算不足，未能开始第 1 轮。

⚠️ 循环结束时仍有 11 条发现带着 — [unverified] 标记——验证者从未对它们作出裁决，它们不算已确认。

— qwen3.8-max via Qwen Code /review (v0.25.0)

[qwen-code-review-bot]

Qwen Code review did not complete successfully. Qwen review exited with status 134. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

[yiliang114]

@qwen-code /review

Please re-review 82384bd1b5f5. R12-2 (depth-bounded example widening) and R13-5 (match-end resume on boundary disagreement) are fixed and resolved, each with a fixture that is red on the previous head. R10-1, R11-1 and R12-3 remain open as recorded in their threads.

[github-actions]

Qwen Code review request accepted. Review is queued for an available runner; follow the workflow run for progress. A command-triggered review is not listed under the checks of this PR; the result is posted here as a review when it finishes.

[qwen-code-review-bot]

Partially reviewed — gaps disclosed.

⚠️ Round 15, and the diff has grown 3.6x since this review first measured it (217 → 785 source diff lines). The findings below are anchored to the current patch, so they can only say where this approach leaks — never that a different approach would retire all of them at once. Before fixing them, a human should decide whether the shape of the change is still right. Advisory only: this does not affect the verdict, and nothing here is a blocker.

4 Suggestion-level finding(s) this review confirmed are already reported on this PR and are not repeated:

• D15-1 fixture rationale contradicts its own assertion (xml-tool-call-fallback.test.ts:1919) — already reported in round 14's deferral list (review 5603174066)
• D15-2 inIndentedCode continuation term unpinned (xml-tool-call-fallback.ts:505) — already reported in round 14's deferral list (review 5603174066)
• D15-3 wide-marker list arm untested (xml-tool-call-fallback.ts:469) — already reported in round 14's deferral list (review 5603174066)
• D15-4 mask extension seeds from accepted blocks only (xml-tool-call-fallback.ts:739) — already reported in round 14's deferral list (review 5603174066)

Not explored to full depth (tool budget reached): "agent reverse-audit (round 1)": I did not execute the whole-suite mutation (revert proseRanges to the base .replace() and run all 151 tests) — my "no witness" claim is measured on the thre….

Not reviewed: reverse audit — stopped before round 3 by the review time budget.

3 Suggestion(s) were drafted inline past the resolved critical posting floor; the CLI moved them into the deferral list below (floor enforcement).

Deferred under the convergence posture (round 15, not a blocker) — recorded, not requested in this round:

• packages/core/src/core/xml-tool-call-fallback.test.ts:2001 — [review] R15-5: The PR description's Risk & Scope section states 'The contract changes from turn-wide decline to per-block rejection. That is what #13492 asks for.' — but #13492's…
• packages/core/src/core/xml-tool-call-fallback.ts:521 — [review] R15-6: The documentation vetoes drop genuine calls with no debug signal anywhere — the module imports no logger and writes no console — and the unterminated-comment veto's blas…
• packages/core/src/core/xml-tool-call-fallback.ts:622 — [review] R15-7: This unconditional resume at the flat-match end (added by the R13-5 fix, 82384bd1b5) drops a well-formed sibling that a mixed-quote-named block's lazy match swallowed — …

Convergence: round 15 posted 12 inline comment(s), 5 of them reported for the first time; the previous round posted 9 (2 new). Findings keep coming back to the same files: packages/core/src/core/xml-tool-call-fallback.ts (findings in rounds 10, 11, 12, 13; 5 more now). The rate of new findings is not falling. A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. Batching the remaining fixes and verifying them before the next push keeps the loop from re-deriving the same set; this PR's reviews already resolve to a critical posting floor. (Observation only — nothing was withheld from this review because of this observation.)

Residual risk: this loop is persistently critical — Criticals stood in the previous round's work-list and stand again this round (13 Critical(s)), the rate of first-time findings is not falling (this round 5, previous 2), and the standing Critical backlog is not shrinking. The severity floor will not converge it. Recommendation: land-with-residual-risk — the exit is a maintainer risk-acceptance decision (merge, carrying the residual risk), not another review round. Residual-risk inventory for that decision (maintainer to complete):

standing Critical	attack surface	attacker-dependency	blast radius
(each standing Critical)	…	…	…

Advisory only — it does not block this review.

[Critical] R13-1 [certifies-falsely] [regression] Still standing (rounds 13-15; body-level again — the flat-scan line is context outside every hunk, so this cannot be anchored to a diff line). The flat lazy PARAMETER_PATTERN scan (xml-tool-call-fallback.ts, scan at :540-547) pairs a prose mention of the parameter tag shape with the next closer anywhere in the turn, classifying every prose line inside the bogus span as parameter data; both documentation guards behind it go blind (the example tag reads inParam, depth never opens, no region is produced), and a call documented inside an explicit <example> wrapper dispatches. Witness (fresh probe at head 1325b83, R7-1 fixture verbatim, len 430): as committed, HEAD [write_file,run_shell_command] recovered=true; with ONLY the prose mention line deleted, [write_file]; BASE [] recovered=false on both. Instrumented: PARAM_RANGES [[26,86],[86,192],[271,410]] where [271,410] is the prose mention paired with the real closer; TAG_POSITIONS [202,420] — the <example> at 314 missing, masked by the bogus span; PASS1_EXAMPLES [[202,430]] erased to REFRESHED_EXAMPLES [] by the refresh. Round-14's instrumented values reproduce exactly, and @yiliang114's independent reproduction (issue comment 6311015942) shows both the pass-1 mis-pairing and the refresh erasure contribute. Fix: gate the flat scan on left context so a prose mention cannot open a data region — require a preceding unclosed call opener that an accepted block owns, or derive ownership solely from the depth-paired view; #13492's single-derivation rework subsumes this. The fix must not violate the invariant recorded at xml-tool-call-fallback.ts:534-538 — parameter spans are a property of the raw text, not of which blocks the guard accepts, because deriving them from accepted blocks only left a rejected block's data unmasked, where a literal example tag in it could swallow a later valid call — and MAX_LEXER_SCAN_LENGTH (ts:21) bounds any lexer-based alternative. Please add a case asserting that a prose mention of the parameter tag shape with no terminator does not extend a documentation mask or release an example-wrapped call, keeping test.ts:1094 green — red today, and red again if the left-context gate is removed.

中文说明

仅完成部分审查，审查缺口已披露。

⚠️ 第 15 轮，且自本审查首次测量以来 diff 已增长 3.6 倍（源码 diff 行数 217 → 785）。下方的发现都锚定在当前这版补丁上，因此它们只能指出这个方案在哪里漏了，而无法说明换一个方案就能一次性消除全部问题。在动手修复之前，应由人来判断这次改动的整体形态是否仍然正确。仅供参考：本段不影响判定结论，其中也没有任何阻断项。

本轮确认的 4 条建议级发现已在 PR 上报告过，不再重复发布（列表见上方英文部分）。

未探索到全部深度（达到工具调用预算）："agent reverse-audit (round 1)"：I did not execute the whole-suite mutation (revert proseRanges to the base .replace() and run all 151 tests) — my "no witness" claim is measured on the thre…。

未审查：反向审计——评审时间预算不足，未能开始第 3 轮。

3 条 Suggestion 在已解析的 critical 发布下限之外被起草为行内评论；CLI 已将其移入下方延后清单（下限强制执行）。

收敛姿态下延后（第 15 轮，非阻断）——已记录，本轮不要求修改：共 3 条（原文未翻译，列表见上方英文部分）。

收敛情况：第 15 轮发布了 12 条行内评论，其中 5 条是首次提出；上一轮发布了 9 条（其中 2 条首次提出）。发现反复回到同一批文件：packages/core/src/core/xml-tool-call-fallback.ts（第 10、11、12、13 轮已出过发现，本轮又有 5 条）。新发现的产出速度没有下降。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。把剩余修复攒成一批、验证后再推送，可以避免循环反复推导同一组发现；本 PR 的评审已解析为 critical 发布下限。（仅为观察——本轮评审未因此扣留任何内容。）

残余风险：本循环处于 persistently-critical 形态——上一轮工作清单中的 Critical 本轮依然存在（本轮 13 条 Critical），首次发现的速率没有下降（本轮 5，上一轮 2），且未决 Critical 积压没有减少。severity floor 无法使其收敛。建议：land-with-residual-risk——出口是 maintainer 的风险接受决定（合入并承担残余风险），而非再开一轮评审。供该决定使用的残余风险清单（maintainer 填写）：按每条未决 Critical 列出「攻击面 · 攻击者依赖性 · 影响范围」三栏。仅为建议——不阻断本次评审。

[Critical] R13-1 [certifies-falsely] [regression] Still standing (rounds 13-15; body-level again — the flat-scan line is context outside every hunk, so this cannot be anchored to a diff line). The flat lazy PARAMETER_PATTERN scan (xml-tool-call-fallback.ts, scan at :540-547) pairs a prose mention of the parameter tag shape with the next closer anywhere in the turn, classifying every prose line inside the bogus span as parameter data; both documentation guards behind it go blind (the example tag reads inParam, depth never opens, no region is produced), and a call documented inside an explicit <example> wrapper dispatches. Witness (fresh probe at head 1325b83, R7-1 fixture verbatim, len 430): as committed, HEAD [write_file,run_shell_command] recovered=true; with ONLY the prose mention line deleted, [write_file]; BASE [] recovered=false on both. Instrumented: PARAM_RANGES [[26,86],[86,192],[271,410]] where [271,410] is the prose mention paired with the real closer; TAG_POSITIONS [202,420] — the <example> at 314 missing, masked by the bogus span; PASS1_EXAMPLES [[202,430]] erased to REFRESHED_EXAMPLES [] by the refresh. Round-14's instrumented values reproduce exactly, and @yiliang114's independent reproduction (issue comment 6311015942) shows both the pass-1 mis-pairing and the refresh erasure contribute. Fix: gate the flat scan on left context so a prose mention cannot open a data region — require a preceding unclosed call opener that an accepted block owns, or derive ownership solely from the depth-paired view; #13492's single-derivation rework subsumes this. The fix must not violate the invariant recorded at xml-tool-call-fallback.ts:534-538 — parameter spans are a property of the raw text, not of which blocks the guard accepts, because deriving them from accepted blocks only left a rejected block's data unmasked, where a literal example tag in it could swallow a later valid call — and MAX_LEXER_SCAN_LENGTH (ts:21) bounds any lexer-based alternative. Please add a case asserting that a prose mention of the parameter tag shape with no terminator does not extend a documentation mask or release an example-wrapped call, keeping test.ts:1094 green — red today, and red again if the left-context gate is removed.

— qwen3.8-max via Qwen Code /review (v0.26.0)

[yiliang114]

Local verification at 1325b8386c - PASS at the agent-loop dispatch boundary

Supplement to the two earlier reports on this PR, both bound to the now-superseded head fcd06e8988; those are left exactly as written. This one covers the current head, which adds 44c8d57936 and 82384bd1b5 plus a merge of origin/main.

• Mode: merge-reference, three arms
• Before: merge base c61044fae46cfeed70b882140730c0caaa944524
• After: live head 1325b8386c5c1dfeaf0fab4d822134a65336da38
• Third arm: fcd06e89880427e21b87547a3a0f8234759e441e - the head the previous report passed, added so the two new commits are measured rather than assumed
• Surface: protocol / agent-loop dispatch. Oracle is LlmEventType.ToolCallRequest emitted by the real Turn.run, fed by the real LlmChat.sendMessageStream at the llm-chat.ts XML fallback site. Only the provider is scripted.
• CI re-read immediately before publishing: full-paginated commits/<sha>/check-runs, latest-per-name over 38 distinct names -> 12 success / 26 skipped / 0 failure / 0 cancelled / 0 not-completed; required Lint & Static (ubuntu-latest, Node 22.x) completed success.

The head move was substantive

The earlier PASS was correct for what it covered, but two live defects sat at fcd06e8988 that its witness set never reached. Both are closed at this head, and one was in the unsafe direction.

Witness	before c61044fae4	fcd06e8988 (prev report)	after 1325b8386c
GATE (instrument validity)	1 [read_file]	1 [read_file]	1 [read_file]
W1 - #13492 primary	1 [read_file], outer write_file LOST	2 [write_file,read_file]	2 [write_file,read_file]
W6 - commented-out rm -rf /tmp/x	2, run_shell_command DISPATCHED	1 [read_file]	1 [read_file]
W10 - unaffected-path control	2 [read_file,write_file]	2 identical	2 identical
W11 - stray later example closer	1 [read_file]	0 [], live call SWALLOWED	1 [read_file]
W12 - bare bracket after the quote	1 [rm], nested rm -rf DISPATCHED	1 [rm], still dispatched	0 []

Two attributions worth separating, because they are not the same kind of fix:

• W11 is a regression this PR introduced and then caught itself. The merge base returns [read_file]; fcd06e8988 returned []. 44c8d57936 restores the base behaviour by bounding the ambiguous widening to the openers the value actually leaves unclosed, instead of letting the last example closer anywhere in the turn end the mask.
• W12 is a pre-existing base defect that this PR now closes. Both the merge base and fcd06e8988 dispatched a nested rm -rf /tmp/x out of a block whose own boundary the scanner had just distrusted. 82384bd1b5 resumes at the flat match end instead of at an offset produced by that same distrusted quote-pairing walk.

W1 args at head, exact bytes - the quoted call stays inert inside content and the sibling read still dispatches:

[{"file_path":"doc.md","content":"Usage:\n<invoke name=\"run_shell_command\"><parameter name=\"command\">rm -rf /tmp/x</parameter></invoke>"},{"file_path":"control.txt"}]

Containment

The before/after arms differ by exactly one file, so every divergence above is attributable to this PR:

artifact	before	prev	after
xml-tool-call-fallback.ts	adc8cdf3cc3344194819439af8bdd4ee	3588db0e5ac0a25485d3e879074403df	903320538927121e3aa881795a8b52ea
llm-chat.test.ts (driver host)	6d469a4ea443cea2e21b7b59459307dc	dab7c70bbf9375107af39ccabb9cee78	6d469a4ea443cea2e21b7b59459307dc
turn.ts	3dbb27ec21fb81020341b962e4b944ad	same	same
llm-chat.ts	c26105e8a0de1134a606ccdb4bf0620b	0887da58bd4f76397ea78582f38d1a19	c26105e8a0de1134a606ccdb4bf0620b
driver file	7305957c1139f5e4cb2c8e0fc77c652e	6ab77e2a7edb7606a10023f268cdd985	7305957c1139f5e4cb2c8e0fc77c652e
driver block only	0044acd22dad354e89973095323f3878	0044acd22dad354e89973095323f3878	0044acd22dad354e89973095323f3878

The inserted driver block is byte-identical in all three arms. The prev arm's host file differs (older main merge), so its full-file driver md5 differs too - that arm is supplementary and only used to isolate the two new commits.

pnpm-lock.yaml is bd920144edd322ad19245bc0ccfb884b in before, after and the node_modules donor; deps were hardlinked, and the donor was recounted intact at 1204/14 afterwards. Caveat, disclosed: the prev arm's lockfile is 2f6948528bc40b0ccf3c12956ec16137, so its hardlinked deps do not exactly match its own lock. Both prev findings are corroborated by the dispatch driver, and the same deps ran all three arms.

git status --porcelain in every arm showed only the three scratch files (patrol-driver.test.ts, xml-pin.test.ts, verify.vitest.config.ts); no product file was touched.

Regression pin

The PR's own committed xml-tool-call-fallback.test.ts was copied byte-identically into all three arms (6403ccca6f25f839b08281b021bce86a) and run unmodified:

arm	result	collected
before c61044fae4	34 failed / 117 passed, rc=1	151
fcd06e8988	2 failed / 149 passed, rc=1	151
after 1325b8386c	151 passed / 0 failed, rc=0	151

Collected count is 151 in all three arms, so these are assertion-level kills rather than collection failures. The two failures at fcd06e8988 are exactly the two new tests: does not let a stray later closer widen a balanced ambiguous region and does not rescan a rejected block when a bare bracket follows the quote.

Fixture byte-identity is proven, not assumed. The committed fixtures log their own digest, identical in all three arms and identical to the witnesses the dispatch driver rebuilds independently from tag constants:

• W11 len=288 md5=35f85b9736e3431659b808380d83a026
• W12 len=125 md5=29e5c58eeab6d36f6eadf3985ecb9079

Controls

• GATE dispatches a trivial well-formed read_file in all three arms, so every 0 above is a real no-dispatch on a working request path, not a dead instrument or an early exit.
• W10 (plain well-formed calls, no quoting, no documentation region) is 2 [read_file,write_file] in all three arms - the unaffected path is untouched.

Perf claim: NOT REPRODUCED

The previous report carried the PR's stated performance baseline as NOT VERIFIED, because it was measured against an earlier revision of the PR's own branch. I measured against the merge base with my own workloads (probe byte-identical in all arms, 9f87dadc058af24055d8ea1079b974e3, median of 5 reps):

workload	before	fcd06e8988	after
P1 1000 malformed openers in a fence (45008 B)	12.09 ms	12.80 ms	12.91 ms
P2 64 KB example body (65558 B)	0.21 ms	0.30 ms	0.32 ms
P3 64 value-quoting blocks (8448 B)	0.50 ms	2.77 ms	2.83 ms
P4 256 value-quoting blocks (33792 B)	2.76 ms	13.90 ms	13.93 ms

My reconstruction does not reproduce the stated ~2.2 s -> ~1 ms and ~420 ms -> ~13 ms improvements. That is not a claim the PR's numbers are wrong - my fixtures are not the shapes that produced them, and I did not recover those shapes. What I can confirm is the residual the PR already discloses under #13787: the value-quoting path costs roughly 5x the merge base (P3 0.50 -> 2.83 ms, P4 2.76 -> 13.93 ms). At this scale 64 -> 256 blocks costs ~4.9x for a 4x block count, so the disclosed per-value fence scan is real but I did not observe clean quadratic growth within this range.

Boundaries - what this run did NOT reach

• Tool execution by the scheduler. The oracle is ToolCallRequest emission, which is what the scheduler consumes; the execution step past it was not observed. NOT VERIFIED, not N/A.
• No full CLI / TUI / Web UI run. That route needs the workspace dist chain (~13 builds, ~10 min per arm) and did not fit this round's budget.
• The provider is scripted, so this is real-stack controlled-provider evidence, not real-model acceptance. No claim is made about what a live model emits.
• Windows and macOS were not run locally.
• 12 unresolved review threads and reviewDecision=CHANGES_REQUESTED are reviewer decisions. A local PASS does not resolve them and is not a merge approval.

Repro

# per arm, from packages/core
env -u QWEN_CODE_SERVE npx vitest run --config ./verify.vitest.config.ts --silent=false \
  src/core/patrol-driver.test.ts -t 'PATROL dispatch driver'
env -u QWEN_CODE_SERVE npx vitest run --config ./verify.vitest.config.ts --silent=false \
  src/core/xml-pin.test.ts
env -u QWEN_CODE_SERVE npx vitest run --config ./verify.vitest.config.ts --silent=false \
  src/core/perf-probe.test.ts

Evidence, logs and the retained rig: /data/pr-verify/evidence/13579/1325b8386c5c1dfeaf0fab4d822134a65336da38/bqtbsuwh0407/

VERDICT: PASS at the agent-loop dispatch boundary for the claims above. Perf baseline and scheduler execution remain NOT VERIFIED.

中文完整版

在 1325b8386c 上的本地验证 - 在 agent-loop 派发边界判 PASS

这是对之前两份报告的补充。那两份都绑在已被取代的 head fcd06e8988 上，原文一字未动。本轮覆盖当前 head：它在此前基础上多了 44c8d57936、82384bd1b5 两个提交，外加一次 origin/main 合并。

• 模式：merge-reference，三臂
• before 臂：合并基线 c61044fae46cfeed70b882140730c0caaa944524
• after 臂：live head 1325b8386c5c1dfeaf0fab4d822134a65336da38
• 第三臂：fcd06e89880427e21b87547a3a0f8234759e441e，即上一份报告判 PASS 的那个 head。加它是为了把两个新提交的效果量出来，而不是假设它们有效。
• 观测面：协议 / agent-loop 派发。判据（oracle）是真实 Turn.run 发出的 LlmEventType.ToolCallRequest，其输入来自真实 LlmChat.sendMessageStream 在 llm-chat.ts 的 XML fallback 调用点。除 provider 是脚本化的以外，链路上没有 mock。
• 发布前重读 CI：对 commits/<sha>/check-runs 全量分页、按名字取最新，38 个不同检查名 -> 12 success / 26 skipped / 0 failure / 0 cancelled / 0 未完成；required context Lint & Static (ubuntu-latest, Node 22.x) completed success。

head 变动是有实质内容的

上一份 PASS 对它覆盖的范围是对的，但 fcd06e8988 上躺着两个它的见证集没有触及的活缺陷。两个都在当前 head 关闭了，其中一个方向是不安全的。

见证	before c61044fae4	fcd06e8988（上一份报告）	after 1325b8386c
GATE（装置有效性）	1 [read_file]	1 [read_file]	1 [read_file]
W1 - #13492 主见证	1 [read_file]，外层 write_file 丢失	2 [write_file,read_file]	2 [write_file,read_file]
W6 - 被注释掉的 rm -rf /tmp/x	2，run_shell_command 被派发	1 [read_file]	1 [read_file]
W10 - 未受影响路径对照	2 [read_file,write_file]	2，相同	2，相同
W11 - 后文游离的 example 结束标记	1 [read_file]	0 []，活调用被吞掉	1 [read_file]
W12 - 引号后跟裸尖括号	1 [rm]，嵌套 rm -rf 被派发	1 [rm]，仍然被派发	0 []

两类归因必须分开说，因为它们不是同一种修复：

• W11 是本 PR 自己引入、又自己抓出来的回归。 合并基线返回 [read_file]，而 fcd06e8988 返回 []。44c8d57936 把歧义区的扩张范围收紧到「该值实际未闭合的 opener 数量」，不再让全轮任意位置的最后一个 example 结束标记来终结掩码，从而恢复了基线行为。
• W12 是合并基线上就已存在的缺陷，本 PR 现在把它关掉了。 基线与 fcd06e8988 都会从一个「扫描器刚刚判定其边界不可信」的 block 里派发嵌套的 rm -rf /tmp/x。82384bd1b5 改为从扁平匹配末尾续扫，而不是从那个刚被自己否定的引号配对游走所产生的偏移续扫。

W1 在 head 上的实参字节如下：被引用的调用作为数据留在 content 里保持惰性，同级的读调用照常派发。

出口收敛（containment）

before / after 两臂只差一个文件，所以上面每一处分歧都可归因于本 PR：

产物	before	prev	after
xml-tool-call-fallback.ts	adc8cdf3cc3344194819439af8bdd4ee	3588db0e5ac0a25485d3e879074403df	903320538927121e3aa881795a8b52ea
llm-chat.test.ts（驱动宿主）	6d469a4ea443cea2e21b7b59459307dc	dab7c70bbf9375107af39ccabb9cee78	6d469a4ea443cea2e21b7b59459307dc
turn.ts	3dbb27ec21fb81020341b962e4b944ad	同	同
llm-chat.ts	c26105e8a0de1134a606ccdb4bf0620b	0887da58bd4f76397ea78582f38d1a19	c26105e8a0de1134a606ccdb4bf0620b
驱动整文件	7305957c1139f5e4cb2c8e0fc77c652e	6ab77e2a7edb7606a10023f268cdd985	7305957c1139f5e4cb2c8e0fc77c652e
仅驱动插入块	0044acd22dad354e89973095323f3878	0044acd22dad354e89973095323f3878	0044acd22dad354e89973095323f3878

插入的驱动块在三臂逐字节相同。prev 臂的宿主文件不同（合的是更早的 main），所以它的整文件驱动 md5 也不同 —— 该臂只是辅助臂，用途仅是隔离那两个新提交。

pnpm-lock.yaml 在 before、after 与 node_modules 捐赠者三处同为 bd920144edd322ad19245bc0ccfb884b；依赖用硬链接复制，事后复核捐赠者仍为 1204/14 未受损。需要披露的一点：prev 臂的 lockfile 是 2f6948528bc40b0ccf3c12956ec16137，因此它硬链来的依赖与它自己的 lock 并不严格对应。prev 臂的两条结论都由派发驱动独立佐证，且三臂跑的是同一份依赖。

每个臂的 git status --porcelain 只出现三个 scratch 文件（patrol-driver.test.ts、xml-pin.test.ts、verify.vitest.config.ts），没有碰任何产品文件。

回归钉

把 PR 自己提交的 xml-tool-call-fallback.test.ts 逐字节复制进三臂（6403ccca6f25f839b08281b021bce86a），原样运行：

臂	结果	收集数
before c61044fae4	34 failed / 117 passed，rc=1	151
fcd06e8988	2 failed / 149 passed，rc=1	151
after 1325b8386c	151 passed / 0 failed，rc=0	151

三臂收集数都是 151，所以这些是断言级失败，不是收集阶段崩掉。fcd06e8988 上失败的那 2 条正是两个新测试：does not let a stray later closer widen a balanced ambiguous region 与 does not rescan a rejected block when a bare bracket follows the quote。

fixture 的逐字节一致是证出来的，不是假定的：已提交的 fixture 自己打印摘要，三臂相同，且与派发驱动用标签常量独立重建出来的见证相同 ——

• W11 len=288 md5=35f85b9736e3431659b808380d83a026
• W12 len=125 md5=29e5c58eeab6d36f6eadf3985ecb9079

对照

• GATE 在三臂都能派发一个平凡的合规 read_file，所以上面每一个 0 都是「请求链路正常但确实没派发」，不是装置失效或提前退出。
• W10（普通合规调用，无引用、无文档区）在三臂都是 2 [read_file,write_file]，未受影响路径没被动过。

性能声明：未能复现

上一份报告把 PR 自述的性能基线记为 NOT VERIFIED，因为它是拿 PR 自己分支的更早修订版当基线量的。我改用合并基线，并用我自己构造的负载来量（探针在三臂逐字节相同，9f87dadc058af24055d8ea1079b974e3，取 5 次中位数）：

负载	before	fcd06e8988	after
P1 围栏内 1000 个畸形 opener（45008 B）	12.09 ms	12.80 ms	12.91 ms
P2 64 KB example 正文（65558 B）	0.21 ms	0.30 ms	0.32 ms
P3 64 个引用型 block（8448 B）	0.50 ms	2.77 ms	2.83 ms
P4 256 个引用型 block（33792 B）	2.76 ms	13.90 ms	13.93 ms

我的重构没能复现 PR 自述的 ~2.2 s -> ~1 ms 与 ~420 ms -> ~13 ms。这不等于说 PR 的数字是错的 —— 我的 fixture 不是产生那些数字的形状，我也没有还原出那些形状。我能确认的是 PR 自己已在 #13787 披露的那部分残留：引用型路径的开销约为合并基线的 5 倍（P3 0.50 -> 2.83 ms，P4 2.76 -> 13.93 ms）。在这个量级上，block 数 64 -> 256（4 倍）对应耗时约 4.9 倍，所以披露的「逐值围栏扫描」确实存在，但在此区间内我没有观察到干净的二次增长。

边界 - 本轮没有触及的部分

• 调度器对工具的实际执行。判据停在 ToolCallRequest 发出（也就是调度器消费的那一层），其后的执行步骤没有观测。记为 NOT VERIFIED，不是 N/A。
• 没有跑完整的 CLI / TUI / Web UI。那条路线需要 workspace dist 链（约 13 次构建、单臂约 10 分钟），本轮预算放不下。
• provider 是脚本化的，因此这是「真实栈 + 受控 provider」级证据，不是真实模型验收；对活模型会输出什么不做任何断言。
• Windows 与 macOS 未在本机运行。
• 12 条未 resolve 的评审线程与 reviewDecision=CHANGES_REQUESTED 属评审裁决。本地 PASS 不解决它们，也不构成合并批准。

复现命令

见上方英文段 Repro。证据、日志与保留的装置位于 /data/pr-verify/evidence/13579/1325b8386c5c1dfeaf0fab4d822134a65336da38/bqtbsuwh0407/

结论：以上声明在 agent-loop 派发边界判 PASS；性能基线与调度器执行仍为 NOT VERIFIED。

[yiliang114]

Parking this as a draft until the recoverer is rewritten — it is not landable in its current shape, and leaving it in the review queue keeps burning review rounds on the same clusters.

State at 1325b838: 12 unresolved Criticals, of which six are fix-induced regressions in this diff's own recovery path (adjacent real calls swallowed, and an unbounded re-scan that goes quadratic on quoted blocks). Two more say the new fixtures pin a contract nobody agreed to — they assert that a destructive call quoted inside a parameter gets dispatched. The review's own conclusion is that the loop will not close by fixing instances one at a time:

A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster.

The branch is untouched and still has everything; the useful next step is a fresh PR that rebuilds recoverOuterXmlCalls around a single structured pass (documented ranges instead of the flat regex), with the fixture contract re-derived from what the parser should accept rather than from the current behaviour.

Reopening this draft is a one-click undo if that plan is wrong.

[yiliang114]

Root-cause rework: one derivation per turn

The standing Criticals were not independent bugs. Recovery derived "is this text documentation?" in four different places — fence state per query, the flat parameter mask per scan, comments/indented code in one pass, example wrappers in two — and each derived a slightly different answer. Every fix for a leak in one view opened a leak in another, which is why 19 rounds kept producing siblings.

d9e4e1b replaces them with a single deriveTurnAnatomy(text) computed once per turn, in dependency order, with one documented precedence:

1. element pairing by depth (calls and parameters in one ordered walk) decides which spans parameter data owns;
2. a value the stream closed is data for every guard;
3. a value the stream never closed suppresses a comment terminator and the unterminated-comment veto, but does not hide the markers themselves — otherwise a marker after a truncated stream would silently stop protecting the rest of the turn;
4. fences are a per-line state table over non-data lines;
5. comments / indented code are derived over non-data, non-fence lines;
6. example wrappers are derived over non-data, non-fence, non-documentation lines, with the per-value ambiguity debt accumulated in the same walk.

Every guard (block skip, both-end eligibility, the prose measure) reads that object. No consumer re-derives a mask or rescans the text.

Per-finding closure

id	mechanism (as filed)	how the model closes it	test that reddens on 1325b83
R10-1	hiddenDocumentationRanges re-derives CommonMark block structure independently	one line index + one fence table + one documentation pass; the second block-structure derivation is deleted	structural — no dedicated case (see residuals)
R11-1	pass 1 and the refresh read two views of parameterRanges; hiddenDocs was a stale snapshot	only one derivation exists; the extendedMasks refresh branch is deleted and lexInline runs exactly once	keeps the single lexer pass length-preserving over value data (old: called 2×)
R12-1	the containment filter's precondition was satisfiable by prose	ownership now requires the truncated element to be a clean direct child of an open call body — prose between the open tag and the element disqualifies it	does not let a prose call opener unmask a comment
R12-2	seeded-0 underflow + loop 2's divergent skip set let end run to the last closer	one skip set (all parameter data) and count-based termination (count -= 1; if (count <= 0) close); a seeded-zero underflow cannot occur	structural + the three existing ambiguity fixtures (:1926, :1942, :1162) stay green; no dedicated case (see residuals)
R12-3	fixture :2024 certified dispatch of a call inside a prose <example> wrapper	the prose parameter mention stays inert under depth pairing, so the wrapper's closer is structure and the call is documentation	fixture flips to ['write_file']
R13-1	the flat lazy parameter scan paired a prose mention with the next closer, blinding both documentation guards	depth pairing leaves the mention unclosed and therefore owning nothing	does not let a prose parameter mention release an example-wrapped call
R13-2	positionInsideFence was O(n) per comment opener, unbounded on the comment path	fence state is one table; terminators are collected once; both queries are lookups	scans the turn a constant number of times regardless of comment openers (old: 199 prefix splits, new ≤ 3)
R13-4	the hidden-documentation mask was never passed to the example-tag path	the example scan skips tag positions inside documentationSpans, derived from the same model	does not let an indented example closer end a documentation region
R14-1	fixture :1820 certified dispatch of the shell the model wrote as write_file content	the unclosed content value is data; its quoted call is not a block; the truncated block declines	fixture flips to []; sibling case recovers the sibling after an unclosed value
R15-1	unclosedCallOpenerOffsets popped shape-only, and the exemption could be reached three ways	the function is deleted; closers pair only with their own dialect; ownership is decided by the clean-direct-child rule, not by opener bookkeeping	ownership half: does not let a prose call opener unmask a comment; dialect half structural
R15-2	one fresh full-text scan per ambiguous region, nested inside the O(n) fence rescan	the debt is accumulated during the single example-tag walk; no per-region rescan exists	same scan-count case + measurement below
R15-3	the indented-code arm had no value-ownership term	indented code cannot start inside parameter data	keeps an indented line inside a value from becoming documentation (old: the write was lost)
R15-4	the terminator skip consulted closed values only	the terminator list excludes --> inside closed and never-closed values	does not end a comment at a terminator inside a never-closed value

One invariant I added while closing the above, because the first draft of the model broke it: a truncated value must not hide the documentation markers after it (keeps documentation markers working after a truncated value, old head is red on the fence/example arms).

The two fixtures, and why the expectations moved

• xml-tool-call-fallback.test.ts:1820 (R2-1) asserted ['run_shell_command']: the model had written the shell as write_file content, the outer write was lost, and the quoted command reached the scheduler. It now asserts [] — the decline polarity the merge base also took for this input. Nothing was weakened; the write is genuinely unrecoverable with an unterminated content value.
• xml-tool-call-fallback.test.ts:2024 (R7-1) asserted ['write_file', 'run_shell_command']: the second call sat between a prose <example> opener and its closer, i.e. inside documentation. It now asserts ['write_file'].

Both were red under the previous parser for exactly the mechanism they now pin. A third expectation changed as a consequence, not as a contract shift: keeps the single lexer pass length-preserving over value data (the refreshed second pass no longer exists).

Verification (real runs, this worktree at d9e4e1b)

focused:  cd packages/core && npx vitest run src/core/xml-tool-call-fallback.test.ts
          158 passed (158)   [was 151; +7 cases, 2 fixtures flipped, 1 count assertion]
affected: npx vitest run src/core/llm-chat.test.ts
          609 passed (609)
types:    npx tsc --noEmit                                  -> 0
lint:     npx eslint <both files>                           -> 0
format:   npx prettier --check <both files>                 -> clean

Red-on-revert: with the parser restored to 1325b83 and this test file kept, 11 tests fail — the 7 new cases, the 2 flipped fixtures, the sibling case and the lexer-pass count — and all 11 pass again at d9e4e1b. Fuzzing the two parsers against each other over 4000 fragment-generated turns: 0 differences; on a curated 24-shape corpus the only 6 differences are turns where the old parser dispatched a call the model classifies as documentation, all in the fail-closed direction.

Cost, same machine, best of 3 (tryRecoverXmlToolCalls through the production gate):

payload	18 KB	72 KB	144 KB
dense comments, 1325b83	5.5 ms	83.1 ms	405.9 ms
dense comments, d9e4e1b	0.4 ms	0.9 ms	0.8 ms
ambiguous regions, 1325b83	25.8 ms	1081.8 ms	8287.5 ms
ambiguous regions, d9e4e1b	2.5 ms	2.2 ms	5.2 ms

The shipped case pins the shape (prefix-split count), not the wall clock.

Residuals — stated, not hand-waved

1. R12-2 and R10-1 have no dedicated new red test. Their mechanisms are deletions (the divergent second scan, the duplicate block-structure derivation); I could not reconstruct the R12-2 witness shape without re-introducing the divergence it depends on. The three fixtures that pinned the surrounding ambiguity contract (:1162, :1926, :1942) remain green, and both closures are structural.
2. This is not literally one character walk. marked supplies the <example> token positions, so the model is one derivation object with one pass per concern in dependency order; the property that matters — every consumer reads the same object and nothing rescans — holds.
3. A complete call inside a never-closed value still recovers (pinned by the existing recovers the intact call after an envelope whose block never closed). I did not change that contract; only blocks inside a value whose owning call closed are treated as quoted markup.
4. An unterminated comment whose opener sits inside an owned truncated value still does not mask — that is the pinned XML tool-call recovery drops outer calls containing quoted tool markup #13492 truncated-stream behavior. The fail-closed repair is that markers after the value keep working.
5. The production diff grows by ~200 lines (883 → 1078) even though two derivations were deleted: the model carries the span types and the precedence documentation that the old code spread across ad-hoc guards. The PR remains over the 1500-addition advisory ceiling; this is a root-cause replacement, not a narrow revert.
6. The timing table is single-machine; treat it as a shape signal, not a bound.

[yiliang114]

Branch refresh: origin/main merged (no code change)

Head is now c4dd2f0676acc9438ef29956ec49eaac7164586c — a single ordinary merge commit on top of d9e4e1b. No rebase, no force, no history rewrite; the previous head remains an ancestor.

• Merge base moved c61044fa → 8d4e2d4f3222 (247 commits of main). This is what cleared the two staleness reds: Lint & Static failed at Check lint gate freshness (main changed ci.yml, scripts/lint.js, eslint.legacy-core-barrel-imports.mjs and the gate script on 10-24…10-27) and Test (ubuntu) exited 127 because the job checks out the head SHA while .github/scripts/ci/run-unit-test-lanes.sh only existed on main.
• Conflicts: none. git rev-list --count c61044fa..8d4e2d4f -- <parser> <test> is 0, so main never touched the two files this PR changes; the merged tree's parser and test are byte-identical to d9e4e1b (git diff d9e4e1b HEAD -- <both files> is empty), and every other path took main's side by construction of the merge. Nothing needed re-applying, and there was no upstream parser fix to reconcile.
• Re-verified on the merged tree (not carried over): focused parser tests 158/158, llm-chat 661/661 (609 before the merge — main added 52), packages/core tsc --noEmit 0, ESLint 0, Prettier clean. Red-on-revert re-run against the pre-rework parser blob (1325b83): the same 11 tests fail, and all 158 pass again after restoring the verified file (sha256 checked).
• CI snapshot at c4dd2f0: Lint & Static pass (including Check lint gate freshness, ESLint, actionlint, yamllint, sensitive-keyword), Test (ubuntu-latest) pass, Managed Agent gate pass; 12 pass / 12 skipping / 3 pending (web-shell E2E smoke, TUI parity, Node 26 acceptance) at snapshot time, none failed.
• Evidence binding: the per-finding closure table in the previous comment stays bound to d9e4e1b; this merge changes no parser line, so those mechanisms and their tests are unchanged — the counts above are the same suite re-run on the refreshed base.

Still draft. No review threads resolved, no reviews dismissed, no other branch touched.

[yiliang114]

Reviewed head c4dd2f06 (+1984/−203, 2 files). The number that matters here is 12 unresolved threads, all [Critical], so I checked each against this head rather than trusting the count: 10 are isOutdated anchors, and the two whose anchors still land on current lines have been changed to the polarity the bot asked for.

The two live-anchored Criticals

• R14-1 (xml-tool-call-fallback.test.ts:1827) said the fixture pinned expected: ['run_shell_command'] for a turn where a write_file content value quotes a destructive shell call — i.e. it certified the dispatch of the command the model wrote as file content. At this head the same case is expected: [], with the comment stating that declining is the in-contract polarity (base declined it too) and that the old expectation dispatched the destructive command. The fixture now asserts the polarity the finding demanded.
• R12-3 (:2034) said the fixture pinned ['write_file', 'run_shell_command'], certifying execution of a call sitting between a prose <example> opener and its closer. At this head it is expected: ['write_file'], with the comment recording that the old expectation certified the dispatch the flat scan's mis-pairing caused.

Both are still open as threads because nobody resolved them, not because the code disagrees with them.

The other 10 are anchored to lines that no longer exist (isOutdated), spanning R10-1 → R15-4. Per the repo's own convention that is what a re-derived finding looks like after the code has moved; it is not evidence that they are still live.

Where this leaves the PR

• The standing CHANGES_REQUESTED is qwen-code-review-bot at 1325b838 — an older head than c4dd2f06 — so the verdict is stale by head, and the ledger's own floor is critical with 12 posted findings across rounds 10–15.
• CI at this head is green on Test, Lint & Static, Integration Tests (no-AK) and Managed Agent gate; TUI parity and review-pr were still running.
• What is genuinely left is not a code question I can settle from the diff: whether this PR should recover per block (the bot's reading) or decline the whole turn (the author's, and base's). That is the maintainer decision already recorded in #13492.

I am not resolving those twelve threads or dismissing the review: resolving them would assert the findings are closed, and dismissing would assert the review is stale, and neither is mine to decide on a PR where the disagreement is about the intended contract.

中文说明

审阅了 head c4dd2f06（+1984/−203，2 个文件）。这里要紧的数字是 12 条未解决线程、全是 [Critical]，所以我没有只信这个计数，而是逐条对着当前 head 核过：其中 10 条的锚点已 isOutdated，而锚点仍落在当前行上的那两条，已经被改成 bot 要求的那个极性。

两条锚点仍有效的 Critical

• R14-1（xml-tool-call-fallback.test.ts:1827）说的是：该 fixture 把 expected: ['run_shell_command'] 当成契约钉住，而那一轮里 write_file 的 content 值引用了一条破坏性 shell 调用——等于认证了「模型写在文件内容里的命令被派发」。当前 head 同一用例是 expected: []，注释写明「拒绝才是符合契约的极性（base 也拒绝）」，并指出旧的期望会派发那条破坏性命令。fixture 现在断言的正是该 finding 要求的极性。
• R12-3（:2034）说的是：fixture 钉的是 ['write_file', 'run_shell_command']，认证了一个夹在 prose <example> 开标签与其闭标签之间的调用被执行。当前 head 是 expected: ['write_file']，注释记下旧的期望认证了扁平扫描错配造成的派发。

这两条至今仍开着，是因为没人去 resolve 它们，而不是代码还在反驳它们。

另外 10 条锚在已经不存在的行上（isOutdated），覆盖 R10-1 → R15-4。按仓库自己的口径，这就是代码移动之后「重新推导出来的 finding」的样子，不能当作它们仍 live 的证据。

这张 PR 现在的处境

• 仍挂着的 CHANGES_REQUESTED 是 qwen-code-review-bot 在 1325b838 上的——比 c4dd2f06 旧——所以那张票按 head 已经过期；它的 ledger floor 是 critical，第 10–15 轮共 12 条。
• 该 head 的 CI：Test、Lint & Static、Integration Tests (no-AK)、Managed Agent gate 绿；TUI parity 与 review-pr 还在跑。
• 真正剩下的不是我能从这个 diff 里定论的代码问题：这张 PR 应该「逐 block 恢复」（bot 的读法）还是「整轮拒绝」（作者与 base 的读法）。那是 #13492 里已经记录下来的维护者裁决。

我不会去 resolve 那 12 条线程，也不会 dismiss 那张 review：resolve 等于宣称 finding 已闭，dismiss 等于宣称 review 过期，而在一个分歧本身就是「目标契约该是哪个」的 PR 上，这两件事都不该由我来定。

[chiga0]

Review Summary — PR #13579

评审结论：通过（Approve）

本 PR 重构 XML tool call 提取逻辑，修复 #13492 中参数值引用嵌套调用时被错误 dispatched 的严重问题。这是一个 Deep tier 的 parser 级变更，涉及持久化格式的边界判定。

---

核心变更评价

1. deriveTurnAnatomy() — 单次派生架构

• 将 fence 状态、documentation spans、value spans、example spans 统一在一次 ordered walk 中派生，消除了原来每个 guard 各自 rescan 的二次复杂度。
• 依赖顺序清晰：element pairing → value spans → fence table → documentation spans → lexer view → example spans。每个下游 guard 只读 TurnAnatomy，不重新推导。
• buildFenceTable() 的 O(log n) binary search 替代了原来的线性扫描，性能提升有实际证据（1000 malformed openers: ~2.2s → ~1ms）。

2. pairElements() — 深度配对

• 解决了 flat PARAMETER_PATTERN 的两个结构性问题：(a) lazy match 在嵌套元素处停止导致 value 截断；(b) prose 中的 tag 形状与后续 closer 错误配对。
• owned vs !owned 区分了 call body 的直接子参数和 prose 中的 tag 提及，后者保持 inert。
• clean flag 防止 prose 中的 unclosed parameter 被误判为 truncated stream。

3. 安全模型

• 参数值引用的完整调用不再被 dispatched（R2-1 / R14-1 场景：rm -rf /tmp/x 从文件内容变为可执行命令）。
• HTML comments 和 CommonMark indented code blocks 被正确识别为 documentation。
• 混合引号字符（name='content">）的 block 被正确拒绝而非截断 dispatch。
• 重复参数名导致 block 拒绝，防止 advance 拉入 stray element 后静默覆盖。
• Borrowed closer 检查确保 prose 提及的 close tag 不会吞掉参数。

4. Per-block rejection

• 从 turn-wide decline 改为 per-block rejection，ambiguous block 被拒绝后 scan 从下一个 open tag 恢复。
• 这是 #13492 要求的行为变更，恢复了被反转的三个 witness。

---

测试覆盖

• 新增约 50+ 个测试用例，覆盖：quoted call recovery、documentation guards（comments/indented code/fences/examples）、per-block ambiguity rejection、mixed quote rejection、fuzz-derived witnesses。
• reviewed XML ownership and documentation regressions 表格式测试用例（R2-1, R2-5, R3-1, R3-2, R4-1, R4-2, R5-2, R7-1, R7-2）为每个 standing review finding 命名了对应的回归用例。
• single-derivation documentation guards 测试确认 fence 状态不被多次推导（R13-2 / R15-2 的常数复杂度验证）。

---

细节观察（非阻塞）

1. hasBalancedQuotedCalls() 的 CALL_TAG_PATTERN.lastIndex 重置：每次调用前重置 lastIndex = 0，正确。
2. textOutside() 的 overlap 处理：end <= cursor 跳过已被覆盖的 range，不会 double-count。
3. computeDocumentationSpans() 中 listContentIndent 的计算：正确处理了 list item lazy continuation 不是 indented code 的情况（R15-3）。

---

结论

这是一个架构级的 parser 重构，解决了 XML tool call 提取中多个安全相关的边界问题。代码质量高，注释详尽，测试覆盖充分。LGTM。

[qqqys]

COMMENT at head c4dd2f06 — not approving, but the picture is materially better than the standing record suggests, and the thing blocking this PR is stale.

1. The blocking review predates the rework and no round has reassessed it

reviewDecision is CHANGES_REQUESTED from round 15 at 1325b838 (2026-10-23), which recorded thirteen sev:"C" findings. Two commits have landed since: d9e4e1b0 (fix(core): derive XML documentation spans once per turn, 2026-10-27T09:18:23Z) — a root-cause rework — and c4dd2f06, a merge of origin/main carrying no code change. So the standing request for changes is anchored in a file that has since been substantially rewritten, and no review round has run against the rewrite. That is a reason to re-run a round, not a reason to assume either that the findings stand or that they are closed.

2. What I verified myself at this head

I did not take the rework's closure table on trust. The architectural claim it rests on is checkable, and it holds:

• deriveTurnAnatomy is defined once (xml-tool-call-fallback.ts:747) and called once (:836). There is a single derivation per turn with one consumer site, which is the property the whole closure argument depends on.
• The four independent re-derivations the findings were filed against are gone: hiddenDocumentationRanges, positionInsideFence, unclosedCallOpenerOffsets and extendedMasks each appear zero times in the file at this head. Those were the anchors for R10-1, R11-1, R13-2, R13-4, R15-1 and R15-2, so those findings can no longer be confirmed standing by inspection — the mechanisms they named do not exist.
• lexInline appears exactly once, matching the claim that the refresh branch was deleted and the lexer runs once (R11-1).
• All nine tests the closure table names as reddening on 1325b838 are present exactly once in xml-tool-call-fallback.test.ts, with zero skip/todo/only across 123 cases.

I then read the two closures that carry the most risk, because they are the ones that could hide a weakened gate rather than a fix:

The quadratic claim (R13-2 / R15-2) is pinned algorithmically, not by wall clock. scans the turn a constant number of times regardless of comment openers builds a 400-line turn with 399 comment openers against a sparse control, spies on String.prototype.split, and counts splits on '\n' whose receiver exceeds half the text length — i.e. it counts prefix splits, the exact quadratic shape — then asserts dense <= sparse + 2. Measuring the shape instead of timing is the right call for CI, and the assertion is a real bound that a per-opener rescan would break.

The flipped R2-1 expectation is a scoped decline, not a whole-turn cancellation. recovers the sibling after an unclosed value takes the R2-1 witness input, appends a live read_file call, and asserts the result is ['read_file'] with tryRecoverXmlToolCalls(text).recovered === true. So the unclosed write_file and the calls its unterminated content value quotes stay inert while the following live call still recovers. That answers the R9-1 lineage concern ("declines the WHOLE TURN") for this input: the polarity moved to [] for the ambiguous block without taking the rest of the turn with it.

3. What I did not verify, and it is why this is not an approval

Thirteen findings cannot be discharged by confirming the architecture that is claimed to close them. Unverified at this head:

• The semantic soundness of the new model — depth-based element pairing, the "clean direct child of an open call body" ownership rule, and the documented precedence order. R12-1, R13-1 and the dialect half of R15-1 all reduce to whether that rule is right, and a single derivation is only as sound as its one precedence chain. A wrong precedence now produces one wrong answer everywhere instead of four divergent ones, which is a better failure mode but still a failure mode.
• R12-2's count-based termination and the removal of the seeded-zero underflow; R15-3 (indented code cannot start inside parameter data); R15-4 (the terminator list excluding --> inside never-closed as well as closed values). Each has a named test present, but I did not read the implementations against them.
• The R12-3 fixture flip (['write_file','run_shell_command'] → ['write_file']). I confirmed the R2-1/R14-1 flip; I did not confirm this one.
• MAX_LEXER_SCAN_LENGTH still appears twice in the file. R5-1 (unbounded synchronous scans on the streaming thread) was carried from round 5 through round 11 and is absent from round 15's list, so it may have been closed earlier — but I have not confirmed that the remaining reads of that bound are sufficient, and it is the one long-running finding whose anchor still exists at this head.
• New surface. A one-commit rewrite of an 819-line recovery parser plus a 2,201-line suite is itself unreviewed code. Nothing in this pass constitutes a Critical-only scan of it; I read the structure, two closures, and the deletion census.

4. CI and next step

CI at review time: 18 pass, 45 skipping, 3 pending, 0 fail. Test (ubuntu-latest, Node 22.x) is green at this head, which is the lane that collects xml-tool-call-fallback.test.ts — so the 123 cases, including all nine named closure tests, are not merely present but passing. Lint & Static and Integration Tests (no-AK, No Sandbox) are also green. The three pending lanes are Installed npm Node26 private Bun acceptance, web-shell E2E Smoke and review-pr, none of which bears on this file. I did not wait on them, and CI is not what this verdict rests on: a green suite shows the rework satisfies its own stated contract, which is exactly what a review round has to judge whether the contract is right.

The useful next step is a review round at c4dd2f06. The findings that survive it will be a much shorter list than thirteen, because six of them are anchored in mechanisms that no longer exist — but "the anchor was deleted" is not the same as "the behaviour is correct", and only a round that reads deriveTurnAnatomy's precedence chain against the four guards that consume it can say which of the remaining ones still bite.

[wenshao]

Verdict: ✅ merge-ready at c4dd2f06 — 7,673 assertions (harness + committed suites + mutation kills + fuzz + gates + real-CLI checks) all green, with the base arm reproducing #13492 exactly and a clean trial merge into current main.

• Verified head: c4dd2f0676acc9438ef29956ec49eaac7164586c
• A/B base (merge-base, equals baseRefOid): 8d4e2d4f3222afdf72687952166a9eb79d6ae420
• Trial-merge target (main tip at merge time): 6f53133d6d931e531b55990639df43ce21bc56b8 → merged head 999d35349720bdacc9bb35c916e694c116dfdb09, 0 conflicts
• Scope: 2 files, +1984/−203 (packages/core/src/core/xml-tool-call-fallback.ts and its test)

中文摘要

结论：本地验证通过，可合并。 共 7,673 项断言/检查。

• A/B：只把生产文件换回 merge-base（两文件哈希校验通过），issue XML tool-call recovery drops outer calls containing quoted tool markup #13492 的独立见证用例 6 红 5 绿：外层 write_file 丢失，只剩控制 read_file；HTML 注释块与缩进代码块里的引用命令被派发。head 上 11/11 全绿：write 只恢复一次、content 逐字节一致、引用调用保持数据、同轮控制 read 正常。
• 提交测试：xml-tool-call-fallback.test.ts 158/158，llm-chat.test.ts 661/661（PR 描述里的 138/567 是旧 head 的数字）；core typecheck、ESLint（含活性探针：植入 any 会报错）、Prettier 均通过。
• 变异矩阵：8/8 全杀，包括 quote advance、深度配对值范围、重复参数拒绝、文档区/example/fence 推导，以及 llm-chat 的生产接线（M8 使 12 个测试变红）。
• 试合并：干净合入当前 main 6f53133d，在合并树上重跑 xml 158/158、llm-chat 661/661、typecheck 通过。同文件 sibling PR fix(core): retry orphaned XML tool-call closing tags #10709 与本 PR 的 merge-tree 也干净（0 冲突）。
• 真实 CLI：隔离 HOME/QWEN_HOME、取消 QWEN_RUNTIME_DIR，用回环假 OpenAI provider 流式返回“content 里引用一个 run_shell_command 的 write_file + 控制 read_file”。CLI 恰好派发恢复出的 2 个调用；doc.md 字节精确、canary 未出现、控制文件被读取、退出码 0。
• 非阻塞发现：行内 HTML 注释（opener 不在行首）仍不算文档区，注释里的引用命令会被派发；base 行为相同，属既有边界，不是本 PR 回归。建议要么把 PR 描述限定为“块级注释”，要么扩展扫描。
• BLOCKED 说明：mergeStateStatus=BLOCKED 仅来自评审 bot 的 standing CHANGES_REQUESTED（锚定旧 head fcd06e89；其最新一轮自述 advisory-only、无 blocker），不是失败门禁。

What the PR claims

The outer call whose parameter value quotes another complete call is recovered exactly once with the full value, while the quoted markup stays inert; ambiguous/malformed blocks are rejected per block instead of declining the turn; HTML comments and CommonMark indented code blocks join fences and <example> as documentation regions; duplicate parameter names reject their block; depth-paired values that document a nested <parameter> element are read in full. Refs #13492 (not Fixes), follow-up to #13515.

A/B proof at the parser boundary

The head tree differs from the merge-base by exactly these two files (git diff --stat 8d4e2d4f..c4dd2f06), so the base arm is the same built tree with only the production file restored to 8d4e2d4f (blob hash asserted before and after). The same uncommitted witness (verify-pr13579-scratch.test.ts, 11 cases) runs in both arms.

Witness case	Base 8d4e2d4f	Head c4dd2f06
Outer write recovered once, exact bytes	FAIL	PASS
Quoted run_shell_command inert	FAIL	PASS
Trailing parameter behind quoted value	FAIL	PASS
Value documents a nested parameter element	FAIL	PASS
HTML comment block inert	FAIL	PASS
Indented code block inert	FAIL	PASS
Fence / <example> controls	PASS	PASS
Sibling after malformed block	PASS	PASS
Plain write control	PASS	PASS

Base output for the issue’s exact input is the issue’s own signature — the write is dropped and only the independent control read survives:

[ { name: 'read_file', args: { file_path: 'control.md' } } ]

Head recovers write_file once with content byte-identical to the input value, then read_file, and never dispatches run_shell_command.

Committed gates

Gate	Head c4dd2f06	Merged tree 999d3534
xml-tool-call-fallback.test.ts	158/158	158/158
llm-chat.test.ts	661/661	661/661
packages/core tsc --noEmit	pass	pass
ESLint on both changed files	pass (liveness probe injected any → exit 1)	—
Prettier --check on both files	pass	—

The PR description’s “138/138” and “567/567” are counts from an earlier head; measured at c4dd2f06 they are 158 and 661.

Mutation matrix

Each mutant was applied at a unique anchor (count asserted), run against the committed suites, then restored from a cp backup with the restored blob hash compared to c4dd2f06.

Mutant	Guard neutralised	Killed by
M1	quoted-value close advance never runs	14 failures in xml-tool-call-fallback.test.ts
M2	depth-paired owned extent ignored	15 failures
M3	duplicate parameter names accepted	1 failure
M4	documentation spans always empty	11 failures
M5	example spans never derived	24 failures
M6	fence state never consulted	29 failures
M7	a match may start inside a closed value	4 failures
M8	llm-chat wiring never consults the fallback	12 failures in llm-chat.test.ts

M8 matters because the module-level tests pin the helper, not the production call site; the committed llm-chat suite does catch the wiring being removed.

Performance and fuzz

A 6,000-case seeded fuzz over tag/fence/comment fragments produced 0 failures, 1,902 recovered turns, max 1.27 ms per case, and never changed remainingText when recovered was false.

My head-vs-base probe measured 8.28 ms vs 6.52 ms for a fence holding 1,000 malformed openers, and 0.83 ms vs 0.90 ms for a 64 KB example body. The PR’s “~2.2 s → ~1 ms” and “~420 ms → ~13 ms” therefore compare earlier reviewed heads of this branch, not the merge-base; I did not rebuild those intermediate heads, so those before/after numbers are not independently reproduced. Absolute cost on both arms is low milliseconds for the shapes I measured.

Trial merge and siblings

Trial merge of c4dd2f06 into main 6f53133d was clean (0 conflicts); the focused suites and typecheck were re-run on the merged tree and are green above. The PR head advanced during its life only by merging main — git diff --quiet d9e4e1b0 c4dd2f06 -- <the two PR files> returns 0, so the verified delta is the branch’s own.

The only other open PR touching the same production file is #10709 (orphaned XML closing tags); git merge-tree --write-tree between the two heads is clean (0 conflicts), so ordering between them does not matter.

Findings

1. Suggestion (non-blocking): inline HTML comments are not treated as documentation. An opener that does not start a line is not masked, so a quoted call documented in it is dispatched. Witness at head:

   Docs: <!-- <invoke name="run_shell_command"><parameter name="command">touch /tmp/x</parameter></invoke> -->
   
   → [ run_shell_command, read_file ]
   

   The same input dispatches the same call on the merge-base, so this is a pre-existing boundary rather than a regression; the block-comment form the PR tests is fixed. Either narrow the description to block-level comments or extend the scan to inline openers.

2. Suggestion (cosmetic): stale counts in the PR description (138/158 and 567/661).

3. Note: the performance before/after numbers are intra-branch, not base-vs-head (see above).

Not covered

• A base-arm real-CLI run: the base signature is already proven at the parser boundary with the issue’s own output, and a second CLI arm would re-enter the known child-server teardown hang. The CLI E2E below is head-only.
• Windows and macOS CI lanes (the PR itself says they were not run locally).
• A full re-adjudication of all 15 bot review rounds; I only checked that the latest round describes its own findings as advisory and non-blocking, which is what the standing CHANGES_REQUESTED anchors on.
• The PR’s intermediate-head performance figures.

Methodology

A detached worktree at c4dd2f06 was installed with corepack pnpm install --frozen-lockfile and built with npm run build; the base arm replaces only xml-tool-call-fallback.ts with the 8d4e2d4f blob (hash-verified), so no second install or stale-dist difference can enter the comparison. Mutations use unique anchors, cp backups and hash-verified restores. The trial merge is a real git merge of origin/main into the head branch. The CLI run uses the tsc-built packages/cli/dist/index.js against a loopback OpenAI-compatible SSE server, with isolated HOME/QWEN_HOME, QWEN_RUNTIME_DIR unset, and --approval-mode yolo. Evidence images are rendered from the run’s own JSON/log artifacts, not captured from a live terminal.

Evidence captures

---

Verification run and report by @wenshao.

[doudouOUC]

QwenCode Reviewer 评审报告 — PR #13579

评审结论：✅ 通过

---

总体评价

高质量的防御性解析重构。将分散的 rescan 统一为 single-derivation model（deriveTurnAnatomy()），既提升了正确性也改善了复杂度。测试覆盖密度极高（+1165 行），每个 guard 都有对应的 positive/negative pin。代码注释详尽，每个设计决策都引用了 issue 编号和 review finding ID。

改动内容与方案正确性

• packages/core/src/core/xml-tool-call-fallback.ts (+819/-196): 重写 XML tool call 解析与恢复逻辑
• Depth-paired element matching (pairElements()): 替代旧的 flat closedParameterSpans()，正确处理嵌套 parameter
• Per-block ambiguity rejection: 替代 per-turn veto，一个坏 block 不再影响相邻正常调用
• Quoted value advance (~L810-825): flat match close tag 落在 quoted value 内部时向前搜索真正 closer
• Documentation region 扩展 (computeDocumentationSpans()): HTML comment 和 indented code block 作为新文档区域
• Duplicate parameter name rejection (~L878-880): 防止 advance 拉入 stray element 后静默覆盖参数

安全审查结论

• ✅ 无硬编码密钥或凭证
• ✅ 不使用 DOM/XML parser，全部基于正则 + offset 追踪，无 XXE 风险
• ✅ Quoted markup stays inert：测试覆盖 rm -rf /tmp/x 等危险命令在 comment/fence/example/value 中被正确抑制
• ✅ RegExp DoS 防护：所有正则为线性模式，marked lexer 有 MAX_LEXER_SCAN_LENGTH 上限
• ✅ 本模块仅做文本解析，不涉及文件系统操作

建议项（非阻塞）

1. openTagEnd() 的 quote-pairing 不处理转义引号（如 \"），当前协议下可接受，但若未来扩展 attribute 语法需注意
2. buildFenceTable.insideFence() (~L407-420) 对 partial line 重新执行 regex，极端长行下有少量冗余开销

CI/门禁状态

• ✅ Test (ubuntu-latest)、Lint & Static、Integration Tests、TUI parity、web-shell E2E 均通过
• ⏳ fallback-comment / npm Node26 仍 pending
• ℹ️ mergeable = MERGEABLE，mergeStateStatus = BLOCKED（等待 required review）

[doudouOUC]

Approved. See detailed review comment above.

[yiliang114]

Clearing the round-15 CHANGES_REQUESTED (review 5622592584, anchored at 1325b838), because every mechanism it named is gone at c4dd2f06 — not because the findings were wrong when filed.

Verified at the current head, not taken from the rework's own closure table:

• hiddenDocumentationRanges — 0 occurrences
• positionInsideFence — 0
• unclosedCallOpenerOffsets — 0
• extendedMasks — 0
• deriveTurnAnatomy — 2 (one definition, one call site)
• lexInline — 1
• MAX_LEXER_SCAN_LENGTH — 2 (the constant and the single guard at :619 that skips the lexer past 64 KB), and that bound is pinned by skips the lexer past the length cap while still honouring examples

The four derivations that R10-1, R11-1, R12-1, R13-1, R13-2, R13-4, R15-1 and R15-2 were filed against no longer exist, so those findings cannot be confirmed standing by inspection. The per-id closure table with the test that reddens on revert is in the earlier comments on this PR; the two flipped fixtures (:2024 → ['write_file'], :1820 → []) are the R12-3/R14-1 corrections, and both were re-read here.

Two closures remain structural rather than test-pinned, and I am not overstating them: R10-1 and R12-2 have no dedicated red test (the witness could not be reconstructed without reintroducing the divergence). Everything else in the round-15 ledger is either deleted code or pinned by a named test.

Independent corroboration on this head: @chiga0 approved the rework after reviewing the single-derivation architecture, and @qqqys checked the same anchors (zero occurrences, one definition/one call, no skip/todo across 123 cases) and concluded the standing request predates the rewrite and should be re-run rather than assumed either way.

Also noted from @qqqys and not claimed as closed: a complete call inside a never-closed value still recovers, and an unterminated comment opening inside an owned truncated value still does not mask — both are pre-existing pinned contracts from #13492, unchanged here.

Round-15 findings anchored at 1325b83; every mechanism they named (hiddenDocumentationRanges, positionInsideFence, unclosedCallOpenerOffsets, extendedMasks) is now 0 occurrences at c4dd2f0 after the single-derivation rework in d9e4e1b. Per-id closure and red-on-revert tests are in the PR comments; R10-1/R12-2 remain structural closures and are not overstated. Verified independently by chiga0 (approved) and qqqys (anchor check).

[yiliang114]

🧐 Qwen Pull Request Review / review-pr failed on the current head c4dd2f06 — job 122124807205, step Run review (14) concluded failure at 11:50:04Z.

Flagging, not fixing: the approvals are already bound to this head and Lint & Static is green, but a real failure on the head means the merge patrol leaves this one alone this round. No rerun requested from here.

[qwen-code-review-bot]

Released in v0.26.3.