fix(web-shell): Replace undefined mock in split rerender tests (#11404)

[qwen-code-dev-bot]

What this PR does

Repairs two Web Shell unit tests that fail on every run. The split-view navigation change (#11250) added two does not rerender App for other split sessions test variants whose assertions reference a mock identifier that does not exist anywhere in the test file, so both tests throw a ReferenceError before completing. The fix points those assertions at the render spy the file already defines and wires into its module mock — the hook the App component calls on every render — restoring the intended "foreign split sessions must not rerender App" coverage with a three-line, test-only edit.

Why it's needed

This is the cause of the main-branch CI failure tracked in #11404: the Test (ubuntu-latest, Node 22.x) job fails in Run tests and generate reports at commit 70cf363395 because the web-shell vitest suite fails deterministically. The failure reproduces on every run and every retry, so CI's test-retry setting cannot absorb it, and every subsequent main run stays red until the reference is fixed.

Reviewer Test Plan

How to verify

On the base commit, run the web-shell suite and observe the failure; on this branch, observe it pass:

1. cd packages/web-shell && npx vitest run --config vitest.config.ts App.test.tsx -t "does not rerender App for other split sessions"
2. Before: both variants fail with ReferenceError: mockUseDaemonActivePromptBridge is not defined at App.test.tsx:28940.
3. After: both variants pass, and the full web-shell suite passes (288 files / 6712 tests).

The test intent is unchanged: after an initial pending-panes report, reports containing only other sessions' ids must not rerender App. A mutation probe confirms the assertions still bite — forcing a rerender on every report makes both tests fail again.

Evidence (Before & After)

N/A (test-only change, no UI behavior affected)

Tested on

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

Environment (optional)

N/A — vitest unit tests only (Node 22, same as the failing CI lane).

Risk & Scope

• Main risk or tradeoff: Minimal; the edit touches three assertion lines in one test file and changes no production code. The replacement spy is the file's established render-call witness, so the assertions keep their original meaning.
• Not validated / out of scope: The CI run logs were not directly readable from the authoring sandbox (no GitHub credentials); the failure was reproduced locally at the exact failing commit with the same command chain the CI step runs. Whether the red run also contained unrelated flaky failures beyond these two tests cannot be determined from here — this fix removes the deterministic failure.
• Breaking changes / migration notes: None.

Linked Issues

Fixes #11404

中文说明

本 PR 做了什么

修复两个必定失败的 Web Shell 单元测试。split-view 导航改动(#11250)新增了两个 does not rerender App for other split sessions 测试变体,其断言引用了一个在整个测试文件中根本不存在的 mock 标识符,导致两个测试在完成前抛出 ReferenceError。本次修复把这些断言指向该文件早已定义并接入模块 mock 的渲染探针——即 App 组件每次渲染都会调用的那个 hook——仅用三行、仅测试文件的改动恢复了"外部 split 会话不应触发 App rerender"这一原有覆盖意图。

为什么需要

这正是 #11404 跟踪的主分支 CI 失败原因:Test (ubuntu-latest, Node 22.x) 任务在提交 70cf363395 上的 Run tests and generate reports 步骤失败,因为 web-shell 的 vitest 套件确定性失败。该失败每次运行、每次重试都会复现,CI 的测试重试设置无法吸收;在修复该引用之前,后续每次 main 运行都会保持红色。

评审验证计划

如何验证

在基线提交上运行 web-shell 套件可观察到失败;切到本分支后可观察到通过:

1. cd packages/web-shell && npx vitest run --config vitest.config.ts App.test.tsx -t "does not rerender App for other split sessions"
2. 修复前:两个变体都失败,报错 ReferenceError: mockUseDaemonActivePromptBridge is not defined,位置在 App.test.tsx:28940。
3. 修复后:两个变体通过,且整个 web-shell 套件通过(288 个文件 / 6712 个测试)。

测试意图不变:在首次 pending-panes 上报之后,仅包含其他会话 id 的上报不应触发 App rerender。变异探针确认断言仍然有效——强制每次上报都 rerender 会让这两个测试再次失败。

前后对比证据

N/A(仅测试改动,不影响任何 UI 行为)

已测试平台

系统	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境(可选)

N/A —— 仅 vitest 单元测试(Node 22,与失败的 CI 车道一致)。

风险与范围

• 主要风险或权衡:极小;改动只涉及一个测试文件中的三行断言,不触碰任何生产代码。替换后的探针是该文件既有的渲染调用见证,断言保持原有语义。
• 未验证 / 超出范围:编写沙箱内无法直接读取 CI 运行日志(无 GitHub 凭据);已在出问题的确切提交上、用 CI 步骤实际运行的同一命令链完成本地复现。红色运行中是否还包含这两个测试之外的无关 flaky 失败,从这里无法判定——本修复消除的是其中的确定性失败。
• 破坏性变更 / 迁移说明:无。

关联 Issue

修复 #11404

[qwen-code-dev-bot]

E2E / Verification Report — Issue #11404

Summary

Main-branch CI failed at 70cf363395 in job Test (ubuntu-latest, Node 22.x), step Run tests and generate reports (which runs npm run test:ci:workspaces then npm run test:scripts). Reproduced locally at the exact failing commit: the packages/web-shell vitest suite fails deterministically with 2 failing tests.

Root cause

Commit 70cf363395 (feat(web-shell): Improve split-view session navigation, #11250) added two it.each variants of does not rerender App for other split sessions in packages/web-shell/client/App.test.tsx. Both reference mockUseDaemonActivePromptBridge, an identifier that is not defined anywhere in the file — App.tsx never calls useDaemonActivePromptBridge, and the file's ./session-catalog/session-catalog-hooks module mock does not export a mock for it. Every run throws ReferenceError: mockUseDaemonActivePromptBridge is not defined at App.test.tsx:28940, so the failure is deterministic and CI's VITEST_RETRY=2 cannot mask it.

Fix

Point the three references at the intended, existing render spy mockUseDaemonSessionActivityBridge (packages/web-shell/client/App.test.tsx). App.tsx calls useDaemonSessionActivityBridge on every render, the file already wires this mock into the session-catalog-hooks module mock, and it is already used elsewhere in the file as the render-call witness. The test semantics hold: after the initial report + forced rerender the spy has been called; subsequent reports that contain only foreign session ids never change outerSplitPanePending, React bails out of the state update, App does not rerender, and the spy stays silent. Three lines changed, test file only, no production code touched.

Mutation probe

Temporarily changed App.tsx so every pending-panes report forces a rerender (setOuterSplitPanePending((prev) => !prev)): both fixed tests FAIL (2 failed). Restored App.tsx and re-ran: both tests PASS (2 passed). This confirms the repaired tests genuinely witness the "does not rerender App for other split sessions" behavior rather than passing vacuously.

Environment note

The sandbox has no GitHub credentials, so the CI run logs for run 34257817936 could not be fetched; the failure was reproduced locally at the exact failing commit (70cf363395, the checked-out HEAD) using the same command chain the CI step runs. The QWEN_CI_COVERAGE=1 push-lane flag was not set locally; the ReferenceError is coverage-independent.

Verification

• npm run test:scripts — passed (82 test files, 2310 tests) — covers the scripts/tests/* side of the commit
• cd packages/web-shell && npx vitest run --config vitest.config.ts — pre-fix: 2 failed / 6710 passed; post-fix: 288 files, 6712 tests, all passed
• cd packages/web-shell && npx vitest run --config vitest.config.ts App.test.tsx -t "does not rerender App for other split sessions" — 2 passed (post-fix)
• Mutation probe: same focused run with App.tsx mutated — 2 failed (as expected); after restore — 2 passed
• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed

中文说明

E2E / 验证报告 — Issue #11404

摘要

主分支 CI 在提交 70cf363395 上失败,失败任务为 Test (ubuntu-latest, Node 22.x),失败步骤为 Run tests and generate reports(该步骤依次运行 npm run test:ci:workspaces 和 npm run test:scripts)。已在出问题的提交上本地复现:packages/web-shell 的 vitest 测试套件确定性失败,有 2 个测试失败。

根因

提交 70cf363395(feat(web-shell): Improve split-view session navigation,#11250)在 packages/web-shell/client/App.test.tsx 中新增了两个 it.each 版本的 does not rerender App for other split sessions 测试。这两个测试引用了 mockUseDaemonActivePromptBridge,而该标识符在整个文件中从未定义——App.tsx 从未调用 useDaemonActivePromptBridge,文件中对 ./session-catalog/session-catalog-hooks 的模块 mock 也没有导出对应的 mock。每次运行都会在 App.test.tsx:28940 抛出 ReferenceError: mockUseDaemonActivePromptBridge is not defined,因此该失败是确定性的,CI 的 VITEST_RETRY=2 重试无法掩盖。

修复

将这三处引用指向本来就打算使用的、已存在的渲染探针 mockUseDaemonSessionActivityBridge(packages/web-shell/client/App.test.tsx)。App.tsx 每次渲染都会调用 useDaemonSessionActivityBridge,该文件已将此 mock 接入 session-catalog-hooks 的模块 mock,并且文件内其他地方也已将它用作渲染调用的见证。测试语义成立:初始上报加强制 rerender 之后,探针已被调用;随后只包含外部会话 id 的上报不会改变 outerSplitPanePending,React 对相同值的状态更新直接跳过渲染,App 不再 rerender,探针保持静默。仅改动 3 行,只涉及测试文件,未触碰生产代码。

变异探针

临时修改 App.tsx,让每次 pending-panes 上报都强制触发 rerender(setOuterSplitPanePending((prev) => !prev)):两个修复后的测试如预期失败(2 failed)。还原 App.tsx 后重跑:两个测试通过(2 passed)。这证明修复后的测试真实地见证了"其他 split 会话不触发 App rerender"这一行为,而非空转通过。

环境说明

沙箱内没有 GitHub 凭据,无法拉取 run 34257817936 的 CI 日志;改为在出问题的确切提交(70cf363395,即当前检出的 HEAD)上,用 CI 步骤实际运行的同一命令链本地复现。本地未设置推送车道的 QWEN_CI_COVERAGE=1;该 ReferenceError 与覆盖率无关。

验证

• npm run test:scripts — 通过(82 个测试文件,2310 个测试)—— 覆盖该提交涉及的 scripts/tests/* 一侧
• cd packages/web-shell && npx vitest run --config vitest.config.ts — 修复前:2 失败 / 6710 通过;修复后:288 个文件、6712 个测试全部通过
• cd packages/web-shell && npx vitest run --config vitest.config.ts App.test.tsx -t "does not rerender App for other split sessions" — 2 通过(修复后)
• 变异探针:在 App.tsx 被变异的情况下运行同一组聚焦测试 — 2 失败(符合预期);还原后 — 2 通过
• npm run build — 通过
• npm run typecheck — 通过
• npm run lint — 通过

---

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

[qwen-code-ci-bot]

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

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

[qwen-code-ci-bot]

Thanks for the PR! Re-run of the gate against the current head (daf3d6d9), which now carries two commits — the original rename plus the review-driven mockClear fix.

Template looks good ✓ — all required headings present, Tested on filled in, full Chinese translation.

Problem: observed, and I confirmed it independently rather than taking the description's word for it. Main-branch CI run 34257817936, job Test (ubuntu-latest, Node 22.x), fails with Failed Tests 2 and ❯ App.test.tsx (796 tests | 2 failed). The job log carries ReferenceError: mockUseDaemonActivePromptBridge is not defined pointing at App.test.tsx:28940, and the two casualties are exactly does not rerender App for other split sessions (outer pending: false) and (outer pending: true). A repo-wide grep confirms why: that identifier appears only on lines 28940/28941/28944 of this file and is defined nowhere in it — no import, no vi.fn(), no module-mock wiring. It is still broken on live main (1f89008), so this is not a duplicate and nothing else has landed the fix.

Direction: clearly aligned — this unblocks a deterministically red main, which is why the retry setting can't absorb it. Nothing here touches auth, sandboxing, model selection, telemetry, release, or a public contract. No CHANGELOG signal needed for a test-only repair.

Size: not applicable. One file, packages/web-shell/client/App.test.tsx — outside every core path, and 0 production logic lines (+5/−3, all of it test code).

Approach: minimal, and the interesting part is which spy got picked. Worth saying plainly, because the obvious fix would have been wrong: useDaemonActivePromptBridge is a real hook, but it lives in session-catalog-hooks.ts:365 and is called from ChatPane.tsx:289 — App never calls it. Mocking it into this file would have produced a spy that an App rerender never touches, so the not.toHaveBeenCalled() loop would have passed forever and the coverage would have been fake. Pointing at mockUseDaemonSessionActivityBridge instead is the right call — that one is already imported (line 250), created (723), wired into the module mock (1625), and used as a witness elsewhere (11045). Reuse over new scaffolding, no drive-by edits.

One nit, non-blocking: the description still calls this "a three-line, test-only edit", but the second commit added a pre-rerender mockClear() plus its comment, so the diff is +5/−3. That addition is well documented in the review-round comment in this thread — it's only the PR body that's stale.

Risk: no elevated risk signals. The single changed file is excluded from the high-risk path scan by its .test.tsx extension, and no pattern matches.

Moving on to code review. 🔍

中文说明

感谢贡献！本次是针对当前 head（daf3d6d9）的重新审查，该 head 已包含两个提交——最初的改名，以及根据评审意见补上的 mockClear 修复。

模板完整 ✓ —— 所有必需小标题齐全，Tested on 已填写，中文翻译完整。

问题：已观测到的真实故障，而且我没有只采信 PR 描述，是自己独立核实的。 主分支 CI 运行 34257817936 中的 Test (ubuntu-latest, Node 22.x) 任务失败，报告 Failed Tests 2、❯ App.test.tsx (796 tests | 2 failed)。任务日志里有 ReferenceError: mockUseDaemonActivePromptBridge is not defined，指向 App.test.tsx:28940；两个失败用例正是 does not rerender App for other split sessions (outer pending: false) 与 (outer pending: true)。全仓 grep 也解释了原因：该标识符在本文件中只出现在 28940/28941/28944 三行，文件内没有任何地方定义它——没有 import、没有 vi.fn()、也没有接入模块 mock。当前 main（1f89008）上它依然是坏的，所以这不是重复 PR，也没有别的改动已经修掉它。

方向：明确对齐——它修复的是确定性变红的主分支，这也正是 CI 重试设置无法吸收的原因。改动不涉及鉴权、沙箱、模型选择、遥测、发布或公共契约。纯测试修复不需要 CHANGELOG 信号。

规模：不适用。只有一个文件 packages/web-shell/client/App.test.tsx——不属于任何核心路径，且生产代码行数为 0（+5/−3，全部是测试代码）。

方案：改动最小，而真正有意思的是选了哪个 spy。这点值得说清楚，因为最直觉的改法其实是错的：useDaemonActivePromptBridge 确实是一个真实存在的 hook，但它在 session-catalog-hooks.ts:365，由 ChatPane.tsx:289 调用——App 从来不调用它。如果把它 mock 进本文件，得到的将是一个 App 重渲染根本不会触碰的 spy，于是 not.toHaveBeenCalled() 循环会永远通过，覆盖是假的。改为指向 mockUseDaemonSessionActivityBridge 才是正确的：它在本文件里已经 import（250 行）、已经创建（723 行）、已经接入模块 mock（1625 行），并且在别处（11045 行）已被当作见证使用。复用而非新增脚手架，也没有夹带无关改动。

一个小问题，不阻塞：PR 描述仍称这是"三行的纯测试改动"，但第二个提交新增了一次 rerender 前的 mockClear() 及其注释，所以实际 diff 是 +5/−3。这个新增在本线程的评审处理评论里有充分说明——只是 PR 正文没有同步更新。

风险：无升级风险信号。唯一改动的文件因其 .test.tsx 扩展名被高风险路径扫描排除，且没有任何模式命中。

进入代码审查 🔍

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

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

[qwen-code-ci-bot]

Code review

I wrote my independent proposal before reading the diff: for a test asserting "App must not rerender", the witness has to be a spy wired to something App itself invokes unconditionally on every render — otherwise the negative assertion is decorative. Then I went looking for whether this PR's pick actually satisfies that.

It does, and the near-miss is the most interesting thing about this diff. useDaemonActivePromptBridge — the name in the broken lines — is a real hook, but it is defined in session-catalog-hooks.ts:365 and called from ChatPane.tsx:289. App never calls it. So the "obvious" repair (import it, mock it, keep the name) would have compiled, gone green, and quietly destroyed the coverage: a spy that an App rerender never touches makes not.toHaveBeenCalled() true forever, whatever the component does. The PR instead points at useDaemonSessionActivityBridge, which App.tsx calls at line 3304 inside the App body (export function App({ starts at 2876), unconditionally, alongside the other top-level hooks. One call per App render — a genuine witness. That spy was already imported (250), created (723), wired into the module mock (1625), reset and re-implemented in beforeEach (9393–9397), and used as a witness at 11045. Nothing new was invented to make the test work.

Two details I checked because they are where this kind of fix usually goes wrong:

• mockClear() vs mockReset() is load-bearing, not stylistic. beforeEach installs an implementation returning { hasActivePrompt, activeWorkState }, and App.tsx:3302 destructures that return value. A mockReset() at either clear site would wipe the implementation, the hook would return undefined, and the destructure would throw — trading a ReferenceError for a TypeError. Both added clears use mockClear(). Correct.
• The second commit's pre-rerender clear turns a vacuous guard into a real one. Between the beforeEach reset and line 28940, the spy accumulates calls from renderApp(), two flush() calls and the split-view click, so expect(spy).toHaveBeenCalled() after rerender() could not fail — it passed off setup calls and proved nothing. Clearing immediately before rerender() makes that assertion measure the render it sits under. This is in scope for the stated goal (restoring the intended coverage rather than merely silencing the error), it does not touch the trailing clear that isolates the loop, and it leaves the shared assertion at 11045 alone. The added comment explains a why that is not obvious from the code — two clears three lines apart look redundant until you know what each isolates — so it is consistent with the project's comment rule rather than a violation of it.

No cross-test leakage: beforeEach resets the spy, so the clears here cannot affect the 11045 assertion in a different test. No AGENTS.md violations, no over-abstraction, no duplication. No blocking findings.

Skipped both optional enrichments deliberately: there is no runtime flow to diagram and only one changed file, so a sequence diagram or a files table would be noise.

Test evidence

This is a CI-path run (GITHUB_EVENT_NAME set), so I did not build or execute anything from this PR — the review is static, and the evidence below is the PR's own CI plus the base-commit CI log, both read through the GitHub API.

The before/after here is unusually clean because the base commit's failure is a matter of public record. On base 70cf3633950b90c0ddc82b9fa4ee8791d2c373e3, the same lane is red:

Test (ubuntu-latest, Node 22.x)   conclusion: failure   (run 34257817936, job 102182712398)

  ⎯⎯⎯⎯⎯⎯ Failed Tests 2 ⎯⎯⎯⎯⎯⎯⎯
  ❯ App.test.tsx (796 tests | 2 failed) 104555ms
     → mockUseDaemonActivePromptBridge is not defined   (×6, i.e. both cases across retries)

  ReferenceError: mockUseDaemonActivePromptBridge is not defined
      28940|       expect(mockUseDaemonActivePromptBridge).toHaveBeenCalled();
      28941|       mockUseDaemonActivePromptBridge.mockClear();

Failing cases: does not rerender App for other split sessions (outer pending: false) and (outer pending: true). On the reviewed head, that lane is green and nothing else regressed — all 43 check-runs on daf3d6d9 are completed, with zero failures:

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	success
Lint & Static (ubuntu-latest, Node 22.x)	success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	success
Capture web-shell visuals (ubuntu-latest, Node 22.x)	success
Integration Tests (no-AK, No Sandbox)	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

The macOS and Windows test lanes are skipped by the workflow's own path filtering, not by anything in this PR — worth naming so the green table is not over-read as three-platform coverage. Since the change is a Vitest assertion in one file with no platform-specific surface, the Ubuntu lane is the one that matters and it is the lane that was red.

Not verified: the mutation probes in the PR description (deleting rerender(), or replacing the hook call in App.tsx:3304, makes both cases fail) are the author's claim, not independently re-run — I cannot execute PR-derived code on this path. I reached the same conclusion statically instead: the witness hook is unconditional in the component under test, and mockClear() preserves its implementation, so the guard can fail and the loop can bite. The probes would confirm it empirically.

Sandboxed verification would settle that residual: @qwen-code /verify — the claim that the restored guard actually fails when App rerenders (or when the App.tsx:3304 hook call goes away) is the one thing green CI cannot show, since CI only demonstrates the tests pass, not that they can fail. Low stakes here given the static argument above, but it is the cheap way to turn the author's probe narrative into an independent A/B result.

中文说明

代码审查

在读 diff 之前我先写下了自己的独立方案：对于一个断言"App 不得重渲染"的测试，见证者必须是一个绑定到 App 自身在每次渲染中无条件调用的东西的 spy——否则那条否定断言只是装饰。然后我去核实这个 PR 的选择是否真的满足该条件。

满足，而且其中的"险些出错"正是这个 diff 最有意思的地方。useDaemonActivePromptBridge——也就是那几行坏代码里的名字——确实是个真实的 hook，但它定义在 session-catalog-hooks.ts:365，由 ChatPane.tsx:289 调用。App 从来不调用它。所以那个"最直觉"的修法（把它 import 进来、mock 起来、保留原名）能编译、会变绿，却会悄悄毁掉这项覆盖：一个 App 重渲染根本不会触碰的 spy，会让 not.toHaveBeenCalled() 永远为真，无论组件做什么。本 PR 改为指向 useDaemonSessionActivityBridge——App.tsx 在第 3304 行、位于 App 函数体内（export function App({ 从 2876 行开始）无条件调用它，与其他顶层 hook 并列。每次 App 渲染调用一次,是真正的见证者。该 spy 早已 import（250 行）、创建（723 行）、接入模块 mock（1625 行）、在 beforeEach 中重置并重装实现（9393–9397 行），并在 11045 行已被用作见证。为了让测试跑通,没有新造任何东西。

有两个细节我专门核过,因为这类修复通常就栽在这里:

• mockClear() 与 mockReset() 的区别是关键性的,不是风格问题。 beforeEach 安装了一个返回 { hasActivePrompt, activeWorkState } 的实现,而 App.tsx:3302 会对该返回值解构。在任一清空点使用 mockReset() 都会抹掉这个实现,hook 将返回 undefined,解构随即抛错——等于把 ReferenceError 换成 TypeError。两处新增清空都用了 mockClear()。正确。
• 第二个提交在 rerender 之前新增的清空,把一个恒真守卫变成了真实守卫。 从 beforeEach 的重置到 28940 行之间,该 spy 已经累积了来自 renderApp()、两次 flush() 和打开 split view 点击的调用,所以 rerender() 之后的 expect(spy).toHaveBeenCalled() 不可能失败——它靠准备期调用就通过了,什么都没证明。紧邻 rerender() 之前清空,使这条断言只度量它所对应的那一次渲染。这落在既定目标范围之内(恢复原有覆盖,而不只是消掉报错),没有动到为循环做隔离的后置清空,也没有碰 11045 行共用的断言。新增注释解释的是代码本身看不出来的 why——相隔三行的两次清空看上去是冗余的,除非你知道各自隔离的是什么——因此它符合本项目的注释规则,而非违反。

不存在跨测试污染:beforeEach 会重置该 spy,所以这里的清空不会影响另一个测试中 11045 行的断言。没有违反 AGENTS.md,没有过度抽象,没有重复代码。无阻塞性问题。

两项可选增强我刻意没有加:没有可供绘制的运行时流程,改动也只有一个文件,所以时序图或文件表都会是噪音。

测试证据

本次是 CI 路径运行(GITHUB_EVENT_NAME 已设置),因此我没有构建或执行本 PR 的任何代码——审查是静态的,下面的证据来自 PR 自身的 CI 以及基线提交的 CI 日志,两者都通过 GitHub API 读取。

这里的前后对比格外干净,因为基线提交的失败是有公开记录的。在基线 70cf3633950b90c0ddc82b9fa4ee8791d2c373e3 上,同一条车道是红的(见上方日志摘录):Test (ubuntu-latest, Node 22.x) 结论为 failure,报告 Failed Tests 2、App.test.tsx (796 tests | 2 failed),日志中 6 次出现 mockUseDaemonActivePromptBridge is not defined,并定位到 28940/28941 行。失败用例为 does not rerender App for other split sessions (outer pending: false) 与 (outer pending: true)。在被审查的 head 上,该车道变绿,且没有其他回归——daf3d6d9 上全部 43 个 check-run 均为 completed,零失败(见上方表格)。

macOS 与 Windows 的测试车道是被 workflow 自身的路径过滤跳过的,与本 PR 无关——特意点明,以免这张绿灯表被过度解读为三平台覆盖。鉴于改动只是一个文件里的 Vitest 断言、不涉及任何平台相关面,Ubuntu 车道才是关键,而它正是原先变红的那条。

未验证:PR 描述中的变异探针(删除 rerender(),或替换 App.tsx:3304 的 hook 调用,会让两个用例失败)是作者的主张,未经独立复跑——在此路径下我不能执行 PR 派生的代码。我改为用静态分析得到同样结论:见证 hook 在被测组件中是无条件调用的,且 mockClear() 保留了其实现,因此该守卫可能失败、该循环也会咬人。探针只是把这一点做成经验性确认。

沙箱验证可以落实这一残余项:@qwen-code /verify —— "当 App 重渲染(或 App.tsx:3304 的 hook 调用被移除)时,恢复后的守卫确实会失败"这一主张,是绿灯 CI 无法展示的,因为 CI 只证明测试通过,不证明它们能够失败。鉴于上面的静态论证,这里风险很低,但这是把作者的探针叙述变成独立 A/B 结果的廉价方式。

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

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

[qwen-code-ci-bot]

Confidence: 5/5 — red lane on the base commit, green on this one, and the witness I would have chosen independently is the one the PR picked.

Stepping back: my independent proposal was "find a spy wired to something App calls unconditionally per render, and don't invent new scaffolding to do it." That is exactly what landed. The trap this PR walked past is worth repeating because it is the failure mode that ships silently — the undefined name happens to be a real hook elsewhere in the package, so the cheap fix (import it, mock it, keep the name) would have gone green and left not.toHaveBeenCalled() asserting nothing at all. Choosing the hook App actually calls, which the file already mocks and already uses as a witness, is the difference between silencing an error and restoring coverage.

The second commit is what moves this from "fine" to "good". A reviewer pointed out that the positive guard could not fail — the spy carried ~5 setup-time calls by the time the assertion ran — and the response was not to argue but to reproduce it (deleting rerender() left the guard green), fix it with a mockClear() in the one place that makes the assertion mean something, and keep mockClear() rather than mockReset() so the beforeEach implementation survives the destructuring in App.tsx. That is the right instinct and the right detail.

Everything I could check without running the code checks out: the identifier is genuinely undefined in that file, the replacement is genuinely wired, the hook is genuinely unconditional in the component under test, live main is genuinely still broken so this is not a duplicate, and the base-commit CI log names the exact two tests the PR restores. Test-only, zero production lines, no core paths, no high-risk paths, template complete, no drive-by edits.

The one thing I am not able to settle myself is the mutation evidence — that the restored assertions fail when they should — because I don't execute PR-derived code on this path. I substituted a static argument for it (unconditional hook + implementation-preserving mockClear()), and named @qwen-code /verify in the Stage 2 comment as the way to confirm it empirically if a maintainer wants that. It does not hold up the approval: the claim this PR actually makes is that main's deterministic red goes green, and both halves of that are on the record in CI.

The only nit is that the PR body still says "three-line" while the diff is +5/−3 across two commits — already documented in the thread, so it is a stale sentence, not a hidden change.

CI is fully settled on this commit (PENDING = 0 across pull_request workflow runs), so this is an immediate approval pinned to daf3d6d9 rather than a deferred one.

Approving. ✅

中文说明

信心度:5/5 —— 基线提交上该车道是红的,这个提交上是绿的,而我独立会选的那个见证者,正是本 PR 选中的那个。

退一步看:我的独立方案是"找一个绑定了 App 每次渲染都无条件调用的东西的 spy,并且不要为此新造脚手架"。落地的正是如此。这个 PR 绕开的那个陷阱值得再说一遍,因为它正是会静默合入的失效模式——那个未定义的名字恰好是本包内别处一个真实的 hook,所以最省事的修法(把它 import 进来、mock 起来、保留原名)会变绿,却让 not.toHaveBeenCalled() 什么也没断言。选择 App 真正调用的那个 hook——本文件早已 mock 它、也早已把它用作见证——是"消掉一个报错"与"恢复一项覆盖"之间的区别。

第二个提交把这件事从"还行"变成了"好"。评审指出那条肯定守卫不可能失败——断言执行时 spy 已带有约 5 次准备期调用——而回应不是争辩,而是先复现(删除 rerender() 后守卫依然绿),再用一处 mockClear() 修在唯一能让该断言产生意义的位置,并且坚持用 mockClear() 而非 mockReset(),好让 beforeEach 安装的实现能在 App.tsx 的解构中存活。这是正确的直觉,也是正确的细节。

所有无需运行代码即可核查的点都成立:该标识符在该文件中确实未定义,替换者确实已接入,该 hook 在被测组件中确实是无条件调用,当前 main 确实仍然是坏的(所以这不是重复 PR),而基线提交的 CI 日志点名了本 PR 恢复的那两个测试。纯测试改动、生产代码 0 行、不涉及核心路径、不涉及高风险路径、模板完整、没有夹带顺手改动。

唯一我无法自行落实的是变异证据——即恢复后的断言在应当失败时确实会失败——因为在此路径下我不执行 PR 派生的代码。我用一个静态论证替代了它(无条件 hook + 保留实现的 mockClear()),并在 Stage 2 评论中点名 @qwen-code /verify,以便维护者想做经验性确认时使用。它并不支撑本次批准:本 PR 真正主张的是主分支确定性红灯转为绿灯,而这主张的两半都已在 CI 中留有记录。

唯一的小问题是 PR 正文仍写着"三行",而 diff 是跨两个提交的 +5/−3——线程中已有说明,所以这是一句过时的表述,不是隐藏的改动。

本提交的 CI 已完全结束(pull_request workflow 运行的 PENDING = 0),因此这是一次钉在 daf3d6d9 上的即时批准,而非延迟批准。

批准。✅

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

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

[qwen-code-ci-bot]

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head daf3d6d. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

[qwen-code-ci-bot]

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

[qwen-code-ci-bot]

Partially reviewed — gaps disclosed. Suggestions are inline.

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

中文说明

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

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

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

[qwen-code-dev-bot]

✅ AutoFix round 2 finished — view run. See this round's report below.

中文说明

✅ AutoFix 第 2 轮已完成 —— 查看运行。本轮报告见下方。

[qwen-code-dev-bot]

🤖 Addressed the latest review feedback (round 1/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/10 轮）。改动内容与我反驳保留之处如下：

Address review round — PR #11406

Feedback dispositions

[rc:3962062547] — [Suggestion] Vacuous toHaveBeenCalled() guard in split rerender tests — Implemented

Claim (checkable): In App session callbacks > does not rerender App for other split sessions (outer pending: %s), the expect(mockUseDaemonSessionActivityBridge).toHaveBeenCalled() guard cannot fail: nothing clears the spy between the top-level beforeEach mockReset() (App.test.tsx:9393) and the assertion, so it already holds ~5 setup-time calls from renderApp(), the two flush() calls, and the split-view click. The assertion passes whether or not the rerender() two lines above actually rendered App, and a future refactor that stops re-invoking the hook on rerender would ship green.

Reproduction before implementing (probe A, unmodified HEAD): deleted rerender(); at App.test.tsx:28938 and ran the two parameterized cases → Tests 1 failed | 1 passed; the outer pending: false case passed entirely and the only failure (outer pending: true) was the loop's not.toHaveBeenCalled() — the line-28940 guard passed in both cases. The vacuous-guard claim is reproduced.

Fix applied: added mockUseDaemonSessionActivityBridge.mockClear(); immediately before rerender(); (with a one-line why-comment), so the guard measures only the render it precedes. The trailing mockClear() is kept (it isolates the not.toHaveBeenCalled() loop), both clears are mockClear() (never mockReset() — the implementation installed in beforeEach at 9394-9397 must survive), and the shared assertion at App.test.tsx:11045 is untouched. Net change: +2 lines in one test file.

Acceptance mutations (with the fix in place):

• Probe B — deleted rerender(); → both cases red at the guard: AssertionError: expected "spy" to be called at least once (App.test.tsx:28941:50 in the mutated file), Tests 2 failed. Previously the same mutation left the guard green in both cases.
• Probe C — replaced the useDaemonSessionActivityBridge(...) call in App.tsx:3304 with a static value → both cases red with the same assertion, Tests 2 failed.
• Both mutations reverted after probing; the committed tree contains only the test-side fix.

Review-body note [rv:5146791177]: "Partially reviewed — reverse audit stopped by the review time budget." Nothing actionable beyond the inline suggestion above; disclosed gap noted.

Issue-level comment [ic:5590748595]: automated web-shell visual preview (base vs head screenshots). Informational only; no action.

Conflict notes

--conflict false; no merge performed, none needed.

Verification

• npm run build — passed (run once before the fix to provision missing workspace dist/ prerequisites for the test runner, and re-run after the fix — both exit 0)
• npm run typecheck — passed
• npm run lint — passed (repo-wide; the changed file also passes npx eslint individually)
• npx vitest run --config vitest.config.ts client/App.test.tsx (packages/web-shell, full file) — 796 passed
• npx vitest run --config vitest.config.ts client/App.test.tsx -t "does not rerender App for other split sessions" — 2 passed | 794 skipped (baseline before fix: identical counts)
• Mutation probe A (pre-fix, rerender() deleted) — guard stayed green in both cases, reproducing the reported defect
• Mutation probe B (post-fix, rerender() deleted) — both cases red at the guard
• Mutation probe C (post-fix, hook call deleted in App.tsx) — both cases red at the guard
• No settings source changed (settingsSchema.ts/settings.ts untouched) — npm run generate:settings-schema not required
• Change is test-only inside an existing unit-test file — no bundled-CLI or integration-harness behavior affected, integration tests not required

中文说明

评审处理轮次 — PR #11406

反馈处置

[rc:3962062547] — [Suggestion] split 重渲染测试中的 toHaveBeenCalled() 守卫恒真 —— 已实施

主张(可验证): 在 App session callbacks > does not rerender App for other split sessions (outer pending: %s) 中,expect(mockUseDaemonSessionActivityBridge).toHaveBeenCalled() 守卫不可能失败:从顶层 beforeEach 的 mockReset()(App.test.tsx:9393)到该断言之间没有任何地方清空 spy,因此它已累积约 5 次准备期调用(来自 renderApp()、两次 flush() 和打开 split view 的点击)。无论上方两行的 rerender() 是否真的渲染了 App,该断言都会通过;若后续重构使该 hook 不再随重渲染被调用,回归会带着绿灯合入。

实施前的复现(探针 A,未修改的 HEAD): 删除 App.test.tsx:28938 的 rerender(); 并运行两个参数化用例 → Tests 1 failed | 1 passed;outer pending: false 用例整体通过,唯一失败(outer pending: true)来自循环中的 not.toHaveBeenCalled() —— 第 28940 行的守卫在两个用例中都保持绿色。恒真守卫的主张得到复现。

已应用的修复: 在 rerender(); 之前紧邻处新增 mockUseDaemonSessionActivityBridge.mockClear();(附一行说明性注释),使守卫只度量它前面那一次渲染。保留原有的后置 mockClear()(它为下方的 not.toHaveBeenCalled() 循环做隔离);两处清空均为 mockClear()(绝不用 mockReset() —— beforeEach 在 9394-9397 行安装的实现必须保留);App.test.tsx:11045 处共用的断言未改动。净改动:单个测试文件 +2 行。

验收变异(在修复之上):

• 探针 B —— 删除 rerender(); → 两个用例都在守卫处变红:AssertionError: expected "spy" to be called at least once(变异后文件的 App.test.tsx:28941:50),Tests 2 failed。此前同样的变异让守卫在两个用例中保持绿色。
• 探针 C —— 将 App.tsx:3304 的 useDaemonSessionActivityBridge(...) 调用替换为静态值 → 两个用例同样以该断言变红,Tests 2 failed。
• 两个变异在验证后均已还原;提交的代码树只包含测试侧的修复。

评审正文说明 [rv:5146791177]: "部分审查 —— 反向审计因评审时间预算停止。" 除上述行内建议外无其他可执行项;已披露的审查缺口已记录。

Issue 级评论 [ic:5590748595]: 自动化的 web-shell 视觉预览(base 与 head 的截图对比)。仅供参考,无需处理。

冲突说明

--conflict false;未执行合并,也不需要。

验证

• npm run build —— 通过(修复前运行一次,用于补齐测试运行器缺失的工作区 dist/ 前置构建;修复后再次运行 —— 两次均退出码 0)
• npm run typecheck —— 通过
• npm run lint —— 通过(全仓库;改动文件单独跑 npx eslint 也通过)
• npx vitest run --config vitest.config.ts client/App.test.tsx(packages/web-shell,整个文件)—— 796 通过
• npx vitest run --config vitest.config.ts client/App.test.tsx -t "does not rerender App for other split sessions" —— 2 通过 | 794 跳过(修复前基线计数完全相同)
• 变异探针 A(修复前,删除 rerender())—— 守卫在两个用例中保持绿色,复现了所报告的缺陷
• 变异探针 B(修复后,删除 rerender())—— 两个用例都在守卫处变红
• 变异探针 C(修复后,删除 App.tsx 中的 hook 调用)—— 两个用例都在守卫处变红
• 未改动 settings 源文件(settingsSchema.ts/settings.ts 未触碰)—— 无需运行 npm run generate:settings-schema
• 改动仅为既有单元测试文件内的测试改动 —— 不影响打包 CLI 或集成测试行为,无需运行集成测试

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 1 selected review thread(s). · 已关闭全部选中的 1 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

---

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

[qwen-code-ci-bot]

Partially reviewed — gaps disclosed.

Not reviewed: verification — no verifier could be built within the review time budget, so both of this round's findings stay unverified.

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

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

中文说明

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

未审查（原文为英文）：verification — no verifier could be built within the review time budget, so both of this round's findings stay unverified.

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

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

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

[wenshao]

@qwen-code /triage

[qwen-code-ci-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: 30 passed · 1 failed · 31 total

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

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

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

脚本断言：30 通过 · 1 失败 · 31 总计

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

Verification report

PR #11406 — deep verification report

Verdict: findings — 30/31 scripted assertions passed. The single unexpected outcome is a discrepancy between the head commit's stated mutation evidence and measurement (a documentation defect, not a code defect); no finding blocks the merge — the code change is correct and provably load-bearing. Verified head: daf3d6d97dcfc45a07a4bed842cca1bf79769d2e (base tip 1f890086f1a41e4de7965c44281116fd65b695d8, merge ref 17de175b).

中文摘要

• 结论:findings。31 条脚本化断言中 30 条通过;唯一未通过的一条是"head 提交说明里的变异证据与实测不符"(文档问题,非代码缺陷)。没有阻断合并的问题——代码改动本身正确且被证明是承重(load-bearing)的。
• A/B 结论:基线(HEAD^1)测试文件在两个参数化用例上以 ReferenceError: mockUseDaemonActivePromptBridge is not defined(App.test.tsx:28940)确定性红;head 两个用例绿;完整 web-shell 套件 288 文件 / 6712 测试全绿(与 PR 描述逐字一致)。中间态(commit 1,本地不可达,按字节精确重建)绿但空转:探针计数显示守卫在清除前已持有 5/6 次 setup 期调用,删除 rerender() 后守卫仍不红;head 加入的 mockClear() 把计数归零,rerender() 恰好贡献 1 次调用,守卫才真正咬合(删除 rerender() 或 App 中的 hook 调用,两个用例都在守卫处红)。
• Findings:① head 提交说明的 "(both previously stayed green)" 与实测不符(m1 在 commit1 让 outer pending: true 在循环断言处红、false 绿;m2 在 commit1 同样红);② 系统性根因:packages/web-shell/tsconfig.json 排除 client/**/*.test.tsx,仓库自带 typecheck 对未定义标识符盲(实测对坏文件 exit 0,对非测试文件注入错误则 exit 2),而该文件闭包内另有 410 个既有类型错误,说明"把测试纳入 typecheck"并非可即插即用的修法。
• 未覆盖:per-commit 归因(commit 1 本地不可达,用字节级重建替代并已验证等价);macOS/Windows 车道;CI 的 retry/flake 机制(本地 5/5 重复绿);410 个既有类型错误未逐条甄别。

Central claim and A/B

Central claim: the two does not rerender App for other split sessions (outer pending: %s) variants now (a) execute instead of dying on an undefined identifier, and (b) their render guard can actually fail — the "foreign split sessions must not rerender App" coverage is load-bearing rather than vacuous.

Secondary claims: (S1) the full web-shell suite goes green, un-red-ing the main CI Test job tracked in #11404; (S2) the replacement spy is the correct witness and the trailing mockClear() keeps the loop guard isolated.

The diff is test-only (git diff --stat HEAD^1..HEAD → one file, +5/−3), so the base and head arms share byte-identical production code; the only variable in every cell is the test file and/or the named mutation. Commit 1 (2f693f42) is not locally reachable (depth-2 graft), so the "commit1" arm is a reconstruction: head minus the two lines the head commit adds. Two scripted checks prove the reconstruction exact — it differs from base on exactly 3 lines, all identifier-only (R-reconstruction), and adding the clear/comment back reproduces head byte-for-byte (R-roundtrip).

Witness validity, established before trusting any cell: mockUseDaemonSessionActivityBridge is wired at App.test.tsx:1625 inside vi.mock('./session-catalog/session-catalog-hooks', …) — the exact specifier App.tsx:117 imports from — and useDaemonSessionActivityBridge(...) is called unconditionally in App's component body (App.tsx:3304). It is the only production caller; ChatPane calls the sibling wrapper useDaemonActivePromptBridge, which the same factory does not route to this spy. So the spy counts App renders only.

Command per cell: npx vitest run --config vitest.config.ts App.test.tsx -t "does not rerender App for other split sessions" from packages/web-shell (the author's Test Plan step 1, with NO_COLOR=true), every cell asserting exactly 2 targeted tests ran.

arm	test file	mutation	oracle	result
base (HEAD^1)	base	none	exit + error text	red — 2 failed, ReferenceError: mockUseDaemonActivePromptBridge is not defined @​ App.test.tsx:28940:14
commit1 (reconstructed)	base + identifier swap	none	exit	green — 2 passed
head	head	none	exit	green — 2 passed
commit1	commit1	m1 delete rerender()	guard assertion	guard survives — case false green; case true red at the loop assertion (28943 mutated / 28944 unmutated), never at the guard
head	head	m1	guard assertion	red — both cases expected "spy" to be called at least once
commit1	commit1	m2 remove App's hook call	guard assertion	red — both cases
head	head	m2	guard assertion	red — both cases
commit1	commit1	m3 force rerender per report	loop guard	red — both cases to not be called at all, but actually been called 1 times
head	head	m3	loop guard	red — both cases
head	head	m4 delete trailing clear	loop guard	red — both cases

Witness of the cells as they printed: evidence/01-mutation-matrix-all-cells.png; base arm evidence/02-base-arm-referenceerror.png; head+m1 evidence/03-head-m1-guard-bites.png.

Mutation A/B across the old vs new test file (the test-only-PR matrix): mutants of the unmodified production file, run against commit1's test file and head's:

mutant	old test file (commit1)	new test file (head)
m1 delete rerender()	survived at the guard (one case red elsewhere)	killed
m2 remove App's hook call	killed	killed
m3 force rerender per report	killed	killed

killed/total: 2/3 → 3/3; no mutant regressed from killed to survived. The new line is exactly what converts m1 from survived to killed.

Spy call counts, instrumented at the seam (real mock.calls.length printed inside the test, both cases):

point	commit1, outer pending: false	commit1, outer pending: true	head, false	head, true
after setup + report(ownerIds)	5	6	5	6
after the clear the head commit adds	— (absent)	— (absent)	0	0
after rerender()	6	7	1	1
each of the 3 loop reports	0 / 0 / 0	0 / 0 / 0	0 / 0 / 0	0 / 0 / 0

This is the load-bearing proof: at commit1 the guard toHaveBeenCalled() saw 5–6 pre-existing setup calls and therefore passed whether or not rerender() rendered App; at head the clear zeroes it and rerender() contributes exactly one call, so the guard measures that render only. The loop's zeros show foreign-session reports cause no App render — the property the test exists for — and m3 proves that assertion can fail.

S1 confirmed: full web-shell suite at head = Test Files 288 passed (288), Tests 6712 passed (6712), zero ReferenceError anywhere — byte-exact match to the PR body's claim, and the bug-class census for the package (evidence/04-fullsuite-288-files-6712-tests-green.png).

Reviewer Test Plan, walked step by step: step 1 (run the command on base and head) — performed, red→green; step 2 (both variants fail with ReferenceError at App.test.tsx:28940) — confirmed including the exact line; step 3 (both pass; full suite 288/6712) — confirmed exactly; step 4 (forcing a rerender on every report makes both tests fail again) — confirmed (m3). All four steps were performable.

Corrections

C1 — the head commit's mutation evidence is inaccurate. Commit daf3d6d9 states: "Mutation-verified: with the clear in place, deleting rerender() or the useDaemonSessionActivityBridge() call in App.tsx turns both parameterized cases red at the guard (both previously stayed green)." The head half is confirmed (cell 05: both cases red at the guard, no loop failures). The parenthetical is false in both directions:

• with rerender() deleted at commit1, the suite did not stay green: outer pending: true went red at the loop assertion (App.test.tsx:28943:56 in the mutated file — 28944 unmutated — expected "spy" to not be called at all, but actually been called 1 times) while outer pending: false stayed green — and the guard itself never failed in either case (cell 04, c04/guard-never-failed).
• with App's hook call removed at commit1, both cases went red at the guard (cell 07), because removing the call removes the setup-time calls too.

Reproduce: node tmp/pr11406-verify-20260908-232309/harness/run-cells.mjs cells 04-commit1-m1 and 07-commit1-m2 (logs logs/cells/04-commit1-m1.log, logs/cells/07-commit1-m2.log). This is a correction to the commit message's evidence, not a request to change the code: the substantive premise (the guard was vacuous before the clear) is independently confirmed by the spy counts above. The likely mechanism for the commit1/m1 red is React's documented "may still need to render that component once more before bailing out" on a same-value setState, which rerender() absorbs when present; that interaction is characterized, not root-caused (see Not covered).

Findings

F1 — Suggestion (systemic, pre-existing): the typecheck gate cannot see this bug class. packages/web-shell/tsconfig.json excludes client/**/*.test.tsx, so npm run typecheck never reads App.test.tsx. Measured (evidence/05-typecheck-gate-blind-to-test-files.png, logs logs/04-typecheck-gate.log):

• T1 — with the broken base test file in place, the repo's own gate (npx tsc -p tsconfig.json --noEmit in packages/web-shell) exits 0. Blind.
• T2 — liveness control: planting export const probe: number = 'not a number'; in a non-test client file makes the same command exit 2 and name the file. The gate is live for files it includes.
• T3/T4 — with tests included, the base file yields exactly 3 × TS2304: Cannot find name 'mockUseDaemonActivePromptBridge' at lines 28940/28941/28944 — precisely the three use sites and precisely the line the PR body cites; head yields 0. Normalizing the +2 line shift, head's error set equals base's minus exactly those three and introduces none (typecheck/error-set-equal-modulo-shift).

So the undefined identifier that red-ed main CI at 70cf363395 (#11404) was statically detectable and statically invisible to the gate that should have caught it. The obvious fix is not drop-in: the same with-tests run reports 410 pre-existing type errors in App.test.tsx's closure, so including web-shell tests in typecheck needs a backlog burn-down (or a per-file allowlist) first. Suggested follow-up, measured only in the sense above (not implemented here): file an issue to bring web-shell test files under a typecheck pass with the 410-error backlog tracked; the PR under review needs no change for it.

F2 — Suggestion (documentation): see C1. The commit message's mutation evidence should be corrected in the PR thread so a future reader does not rely on "(both previously stayed green)".

Neither F1 nor F2 is a defect in the five changed lines. The changed lines are correct: the chosen spy is the only per-App-render witness available in this file's mocks, the added clear makes the guard measure exactly one render, the trailing clear remains load-bearing (m4), and the loop guard remains able to fail (m3).

Not covered

• Per-commit attribution. Commit 2f693f42 is not locally reachable (git rev-list HEAD^1..HEAD^2 returns 1 at the shallow boundary; git cat-file -e 2f693f42… fails). The commit1 arm is a reconstruction, proven byte-exact against base and head by R-reconstruction/R-roundtrip; it was not checked out from git.
• macOS / Windows lanes — Linux container only; the PR's own table marks them untested.
• CI's retry/flake regime (VITEST_RETRY, shared-ECS worker caps) not exercised. Local determinism bounded by 5/5 green repeats at ~5.5 s each (logs/05-stability.log); the suite involves act()/promise flushing but no wall-clock timers, and the measured margin concern (React's same-value-setState extra render) did not manifest at head in any of 8 green runs of the targeted cell.
• The 410 pre-existing type errors in App.test.tsx's closure were counted and diffed, not triaged.
• The commit1/m1 extra-render mechanism is characterized (which assertion, which case, which counts) but not root-caused to a specific React internal; no attempt was made to bisect React versions.
• No behavioral A/B of the running app — impossible and unnecessary: the diff touches no production file.
• An early harness revision (v1) never wrote its test-side mutations to disk, so its m1 cells measured the unmutated file; those cells were discarded and re-run under v2. Every number in this report comes from the v2/verified logs in logs/.

Methodology

All work ran in the CI verify container on the merge-ref checkout (HEAD=merge, HEAD^1=base tip, HEAD^2=PR head); npm ci/npm run build were pre-existing and not redone. Three harnesses in harness/ drive everything: run-cells.mjs composes each variant/mutation by exact-string replacement (asserting exactly one occurrence), writes it over the real path, runs the author's own vitest command with NO_COLOR=true, parses the ANSI-stripped summary, refuses to score any cell that did not run exactly the 2 targeted tests, and restores the tree via git checkout -- in a finally (tree verified clean afterwards); typecheck-gate.mjs runs the repo's own tsc gate plus a with-tests config; stability.mjs repeats the targeted cell. adjudicate.mjs re-reads the captured logs and asserts the finer properties (which assertion failed, which case, spy counts, error-set equality modulo the line shift), and emits assertions.json. Raw per-cell vitest output lives in logs/cells/*.log, full-suite in logs/03-head-fullsuite.log, typecheck in logs/typecheck/, and the five PNGs in evidence/ were rasterised from those real logs with scripts/verify-capture.mjs. No GitHub writes were attempted; the PR text was treated as untrusted hypotheses throughout (its counts were confirmed, its mutation evidence was not).

Flakiness gate log

rounds=5 files=1 skipped=0
file packages/web-shell/client/App.test.tsx: (cd packages/web-shell) npx --no-install vitest run ./client/App.test.tsx


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  packages/web-shell/client/App.test.tsx: 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/web-shell/client/App.test.tsx: P (exit 0)
round 2 · packages/web-shell/client/App.test.tsx: P (exit 0)
round 3 · packages/web-shell/client/App.test.tsx: P (exit 0)
round 4 · packages/web-shell/client/App.test.tsx: P (exit 0)
round 5 · packages/web-shell/client/App.test.tsx: 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-ci-bot]

LGTM, looks ready to ship. ✅

[qwen-code-dev-bot]

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round — no action required

Feedback triage

Every item in this round's feedback was classified; none is actionable:

• [rv:5147795250] @qwen-code-ci-bot review (COMMENTED) — "Partially reviewed — gaps disclosed." The review ledger records "findings": [] and "posted": 0, and the feedback contains no inline comments. The two candidate findings it mentions still carried the — [unverified] tag when the review loop ended and were never posted, so there is no checkable claim (no named input, state, or wrong outcome) to reproduce or fix. Disposition: nothing actionable — informational review status.
• [ic:5593017724] @qwen-code-ci-bot issue-level comment — a status notice that sandboxed verification is running. It requests no change. Disposition: nothing actionable.
• Failed checks / still-red checks — none listed.
• Diff growth this window — source 0 / test 2 net lines, within budget; no brake engaged.

Prior inline finding re-verified against the current head

The PR's only inline comment, [rc:3962062547] (Suggestion, from the previous evaluation window), was addressed by commit daf3d6d97d ("test(web-shell): Clear spy before rerender so the guard can fail"), which added mockUseDaemonSessionActivityBridge.mockClear() immediately before rerender() in packages/web-shell/client/App.test.tsx and kept the trailing clear. I re-ran its acceptance criterion as a mutation probe on the current head (daf3d6d97d):

• Probe: neutralized the rerender(); call (App.test.tsx:28940) and ran the focused test. Both parameterized cases went red exactly at the guard line: AssertionError: expected "spy" to be called at least once at App.test.tsx:28942 — Tests 2 failed | 794 skipped, matching the reviewer's "ARM D2" expectation.
• Restore: git checkout -- packages/web-shell/client/App.test.tsx; git status clean; reran the focused test — Tests 2 passed | 794 skipped.

The previously landed fix therefore provably holds: the positive guard now measures the rerender alone, and the three not.toHaveBeenCalled() assertions in the loop are no longer vacuous.

Outcome

No commit was made; the working tree is unchanged. The round contains no verified finding, no failing check, and no maintainer request — nothing to implement, decline, defer, or escalate.

Verification

• npm run build (repo root) — passed. Required first: this runner had several workspace packages unbuilt (acp-bridge, sdk-typescript, web-shell, …), so the focused vitest run initially failed at import resolution for @qwen-code/sdk/daemon. (A direct npm run build -w @qwen-code/sdk attempt failed on missing @qwen-code/acp-bridge/* type declarations — a dependency-ordering artifact; the root build builds in dependency order and succeeded.)
• npx vitest run --config vitest.config.ts client/App.test.tsx -t "does not rerender App for other split sessions" (from packages/web-shell) — passed: Test Files 1 passed (1), Tests 2 passed | 794 skipped (796).
• Mutation probe (described above) — guard fails red without rerender() in both parameterized cases; file restored byte-identical and rerun green.

中文说明

Autofix 本轮——无需改动

反馈分诊

本轮反馈中的每一项都已分类;均不具备可执行性:

• [rv:5147795250] @qwen-code-ci-bot 评审(COMMENTED)——"部分完成审查,缺口已披露"。评审账本记录 "findings": [] 且 "posted": 0,反馈中没有任何行内评论。它提到的两条候选发现在评审循环结束时仍带有 — [unverified] 标记,且从未被发布,因此不存在可复现或可修复的可检验断言(没有指明输入、状态或错误结果)。处置:无可执行项——仅为信息性评审状态。
• [ic:5593017724] @qwen-code-ci-bot issue 级评论——一条"沙箱验证正在运行"的状态通知,不要求任何改动。处置:无可执行项。
• 失败检查 / 持续红色检查——均未列出。
• 本窗口 diff 增长——源码净增 0 行 / 测试净增 2 行,在预算内;未触发刹车。

针对当前 head 复核了此前的行内发现

本 PR 唯一的行内评论 [rc:3962062547](Suggestion,来自上一个评估窗口)已由提交 daf3d6d97d("test(web-shell): Clear spy before rerender so the guard can fail")处理:该提交在 packages/web-shell/client/App.test.tsx 的 rerender() 之前立即加入了 mockUseDaemonSessionActivityBridge.mockClear(),并保留了原有的后置清空。我在当前 head(daf3d6d97d)上把它的验收标准作为变异探针重新跑了一遍:

• 探针: 注释掉 rerender(); 调用(App.test.tsx:28940)后运行聚焦测试。两个参数化用例都精确地在守卫行变红:App.test.tsx:28942 处报 AssertionError: expected "spy" to be called at least once——Tests 2 failed | 794 skipped,与评审者"ARM D2"的预期完全一致。
• 还原: 执行 git checkout -- packages/web-shell/client/App.test.tsx;git status 干净;重新运行聚焦测试——Tests 2 passed | 794 skipped。

因此,此前落地的修复可被证明仍然有效:正向守卫现在只度量本次 rerender,循环中的三个 not.toHaveBeenCalled() 断言也不再是永真空断言。

结论

本轮未创建任何提交;工作树保持不变。本轮没有已验证的发现、没有失败的检查、也没有维护者的要求——没有需要实现、拒绝、推迟或升级处理的事项。

验证

• npm run build(仓库根目录)——通过。必须先执行:该运行器上有多个 workspace 包尚未构建(acp-bridge、sdk-typescript、web-shell 等),因此聚焦 vitest 最初在解析 @qwen-code/sdk/daemon 导入时失败。(直接执行 npm run build -w @qwen-code/sdk 的尝试因缺少 @qwen-code/acp-bridge/* 类型声明而失败——这是依赖顺序问题;根目录构建按依赖顺序执行并取得成功。)
• npx vitest run --config vitest.config.ts client/App.test.tsx -t "does not rerender App for other split sessions"(在 packages/web-shell 下执行)——通过:Test Files 1 passed (1),Tests 2 passed | 794 skipped (796)。
• 变异探针(如上所述)——去掉 rerender() 后,守卫在两个参数化用例中均变红;文件已逐字节还原并复测为绿。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

---

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

[wenshao]

Maintainer verification — local build + real test execution

Verified on a dedicated worktree at the PR head daf3d6d97d, fresh npm ci (Linux, Node v22.22.2, npm 10.9.7) — same Node major as the failing CI lane. Every number below comes from a real run on this machine; nothing is taken from the description.

Verdict: recommend merge. The fix is correct, minimal, and — with the second commit — non-vacuous. Two documentation nits below, neither blocking.

---

1. The failure reproduces exactly, and it is the whole failure

Restoring only App.test.tsx from 70cf363395 (the commit #11404 reports) and running the two tests reproduces the CI error verbatim at App.test.tsx:28940:

Running the whole web-shell suite at that content gives numbers byte-identical to CI job 102182712398:

	CI @ 70cf363395	Local, same content	Local, PR head
Test Files	1 failed | 287 passed (288)	1 failed | 287 passed (288)	288 passed (288)
Tests	2 failed | 6710 passed (6712)	2 failed | 6710 passed (6712)	6712 passed (6712)

This closes the PR's own "not validated" caveat: the red run contained no other failures — the two does not rerender App for other split sessions cases were the only red tests in the only red suite of the only red job. Fixes #11404 is exact, not approximate.

It is also still live. Five other open PRs currently have a red Test (ubuntu-latest, Node 22.x) for this same ReferenceError (#11397, #11396, #11392, #11369, #11360), so this is blocking merge signal repo-wide, not just main's own lane.

2. PR head is green

3. The assertions bite — 7 mutants, all behaving as predicted

Mutant	Result	Where it reds	What it proves
(control) PR head, unmutated	2 passed	—	baseline
delete rerender()	2 failed	the toHaveBeenCalled() guard	the guard now measures that render — the acceptance criterion from round 1 is met
delete rerender(), on commit 1 only	1 failed / 1 passed	the loop, guard stays green	reproduces the round-1 finding: without commit 2 the guard cannot fail
commit 1 only, unmutated	2 passed	—	commit 1 alone already clears the red; commit 2 is a strictness fix, not a correctness prerequisite
delete the trailing mockClear()	2 failed	the loop	the trailing clear is load-bearing, not redundant
added clear → mockReset()	2 failed	TypeError: Cannot destructure property 'hasActivePrompt'	it must be mockClear, never mockReset
production: drop useDaemonSessionActivityBridge(...) from App's render body	2 failed	the guard	the guard is bound to the real hook App calls, not to test scaffolding
production: make every pending-panes report toggle outerSplitPanePending	2 failed	the loop	the negative assertions genuinely detect an App rerender

Instrumenting the spy confirms the mechanism numerically. Before commit 2 the guard was reading 6–7 accumulated setup-time calls; after it, exactly the 1 call made by the render it claims to observe:

4. Post-merge safety

packages/web-shell is unchanged between this PR's base and current main (1f890086f1), the merge is conflict-free, and the merged App.test.tsx blob hashes identically to the file I tested — so the local green above is the post-merge state, not an approximation of it.

5. How this reached main (context, not a defect in this PR)

Worth recording, because the PR is right that its own sandbox could not determine it:

1. feat(web-shell): Improve split-view session navigation #11250's branch was green and correct: at its head 52484fecf3 the mock was declared, wired into the module mock, and named mockUseDaemonActivePromptBridge.
2. 51 minutes later fix(web-shell): show session active work #11267 landed on main and renamed the hook and its mock to useDaemonSessionActivityBridge / mockUseDaemonSessionActivityBridge.
3. The squash-merge took main's renames and feat(web-shell): Improve split-view session navigation #11250's three new lines. Textually clean, semantically broken — a classic semantic conflict.
4. No static gate can see it: packages/web-shell/tsconfig.json excludes client/**/*.test.tsx, so npm run typecheck exits 0 on the broken file, and eslint exits 0 too (no-undef is explicitly off for this file — verified with eslint --print-config). Only running the test catches it.
5. ci.yml has no push trigger and — per its own header comment — the merge queue is not enabled, so nothing re-validated the squashed tree — the after-the-fact main-failure watcher (Main CI failed: Qwen Code CI on 70cf3633950b #11404) was the first thing to notice.

The systemic fix (a merge queue, or typechecking test files) is out of scope here; this PR is the right immediate repair.

6. Non-blocking nits before squash

1. The description is stale relative to the second commit. It still says "a three-line, test-only edit" and describes the fix purely as repointing three assertions; the diff is +5/−3 and the added mockClear() — the change that actually makes the guard capable of failing — is not mentioned anywhere in the body. Since this squashes into one commit message, the body is worth a one-line update.
2. The "Not validated / out of scope" bullet can be struck. It says whether the red run contained unrelated flaky failures "cannot be determined from here". It can: it did not — §1 above.

中文说明

维护者验证 —— 本地构建 + 真实运行

在 PR head daf3d6d97d 的独立 worktree 上、全新 npm ci（Linux，Node v22.22.2，npm 10.9.7，与失败的 CI 车道同一 Node 大版本）完成验证。下列所有数字均来自本机真实运行，未采信 PR 描述。

结论：建议合并。 修复正确、最小，且在第二个提交加入后不再是空断言。文末两条仅为文档层面的小问题，均不阻塞。

---

1. 失败可精确复现，且它就是全部失败

仅把 App.test.tsx 还原到 70cf363395（#11404 所报的提交）再运行这两个测试，逐字复现 CI 的报错，位置 App.test.tsx:28940（见上方第一张截图）。

在该内容上运行整个 web-shell 套件，结果与 CI job 102182712398 完全一致：

	CI @ 70cf363395	本地同内容	本地 PR head
Test Files	1 failed | 287 passed (288)	1 failed | 287 passed (288)	288 passed (288)
Tests	2 failed | 6710 passed (6712)	2 failed | 6710 passed (6712)	6712 passed (6712)

这填补了 PR 自述的"未验证"缺口：那次红色运行中没有其他失败——两个 does not rerender App for other split sessions 用例是唯一红色 job 里唯一红色套件中唯一红色的测试。Fixes #11404 是精确的，不是近似的。

问题目前仍在扩散：另有 5 个其他开放 PR（#11397、#11396、#11392、#11369、#11360）的 Test (ubuntu-latest, Node 22.x) 正因同一个 ReferenceError 变红。它阻塞的是全仓库的合并信号，而不只是 main 自己的车道。

2. PR head 全绿

两个目标测试通过；整套 web-shell 套件 288/288 文件、6712/6712 测试通过（见上方第二张截图）。

3. 断言确实有效 —— 7 个变异体，全部如预期

变异体	结果	变红位置	说明
(对照) PR head 未变异	2 passed	—	基线
删除 rerender()	2 failed	toHaveBeenCalled() 守卫	守卫现在确实度量该次渲染——第 1 轮评审提出的验收标准已满足
删除 rerender()，仅在第 1 个提交上	1 failed / 1 passed	循环处，守卫仍绿	复现第 1 轮的发现：没有第 2 个提交，守卫不可能失败
仅第 1 个提交，未变异	2 passed	—	仅靠第 1 个提交即可消除红色；第 2 个提交是严格性修复，而非正确性前提
删除后置的 mockClear()	2 failed	循环处	后置清空是承重的，并非冗余
新增的清空改为 mockReset()	2 failed	TypeError: Cannot destructure property 'hasActivePrompt'	必须是 mockClear，绝不能是 mockReset
生产代码： 从 App 渲染体中移除 useDaemonSessionActivityBridge(...)	2 failed	守卫处	守卫绑定的是 App 真正调用的 hook，而非测试脚手架
生产代码： 让每次 pending-panes 上报都翻转 outerSplitPanePending	2 failed	循环处	负向断言确实能检测到 App 的重渲染

对 spy 的插桩计数从数值上印证了机制：第 2 个提交之前，守卫读到的是 6–7 次挂载期累积调用；加入之后，恰好只有它声称观察的那次渲染所产生的 1 次调用（见上方第四张截图）。

4. 合并后的安全性

本 PR 的 base 与当前 main（1f890086f1）之间，packages/web-shell 没有任何改动；合并无冲突；合并树中 App.test.tsx 的 blob 哈希与我实测的文件完全一致——因此上面的本地绿色结果就是合并后的状态，而不是对它的近似。

5. 它是怎么进入 main 的（背景信息，非本 PR 的缺陷）

值得记录，因为 PR 确实说明了它自己的沙箱无法判定这一点：

1. feat(web-shell): Improve split-view session navigation #11250 的分支本身是绿色且正确的：在其 head 52484fecf3 上，该 mock 已声明、已接入模块 mock，名字是 mockUseDaemonActivePromptBridge。
2. 51 分钟后 fix(web-shell): show session active work #11267 合入 main，把该 hook 及其 mock 重命名为 useDaemonSessionActivityBridge / mockUseDaemonSessionActivityBridge。
3. squash 合并同时采纳了 main 的重命名和 feat(web-shell): Improve split-view session navigation #11250 新增的三行。文本上无冲突，语义上已损坏——典型的语义冲突。
4. 没有任何静态门禁能发现它：packages/web-shell/tsconfig.json 排除了 client/**/*.test.tsx，因此 npm run typecheck 在损坏文件上退出码为 0，eslint 同样为 0（该文件的 no-undef 被显式关闭——已用 eslint --print-config 核实）。只有真正运行测试才能捕获。
5. ci.yml 没有 push 触发器，且据其文件头注释合并队列亦未启用，因此没有任何环节复验 squash 后的树——最先发现的是事后的主干失败监测（Main CI failed: Qwen Code CI on 70cf3633950b #11404）。

系统性修复（启用合并队列，或把测试文件纳入类型检查）不属于本 PR 范围；本 PR 是正确的即时修复。

6. squash 前的两条非阻塞小问题

1. 描述相对第 2 个提交已经过时。 正文仍写着"仅三行、仅测试文件的改动"，并把修复完整描述为"重新指向三处断言"；而实际 diff 是 +5/−3，且新增的 mockClear()——真正让守卫具备失败能力的那处改动——在正文中完全没有提及。由于这会 squash 成单条提交信息，正文值得补一句。
2. "未验证 / 超出范围"那一条可以删掉。 它写的是"红色运行中是否还包含无关 flaky 失败，从这里无法判定"。是可以判定的：没有——见上文第 1 节。

[qwen-code-dev-bot]

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round — no code change

Triaged all feedback newer than the last evaluation. There is exactly one new
item: the maintainer verification comment [ic:5593269567] (@wenshao), which
recommends merge and raises two non-blocking nits. No inline comments, no
reviews requesting changes, and no failed checks are pending. The head commit
daf3d6d97d needs no code change, so nothing was committed.

Feedback disposition

[ic:5593269567] — maintainer verification, recommend merge — acknowledged

The comment verifies the fix end-to-end at the PR head: the original
ReferenceError reproduces at the base content, the full web-shell suite is
green at head (288/288 files, 6712/6712 tests, byte-identical to CI), and 7
mutation probes confirm the assertions are non-vacuous — including that the
round-1 finding (the toHaveBeenCalled() guard that could not fail) is now
load-bearing. This closes the loop on the earlier inline finding
(rc:3962062547), which head commit daf3d6d97d resolved; nothing in the
comment asks for a code change.

Nit 1 — PR body is stale relative to the second commit — valid, not actionable from this mode (maintainer to apply at squash)

Verified against the real diff: it is +5/−3, and the added mockClear() —
the change that makes the guard capable of failing — is indeed not described
in the PR body. The nit is about the PR description, a GitHub-side
artifact. This mode cannot edit it: the agent has no GitHub credentials, and
the address-review path never updates a PR body (pr-body.md is consumed only
at PR creation in the develop-issue path — .github/workflows/qwen-autofix.yml).
Suggested resolution for the merging maintainer: when squashing, add one line
to the message noting that the second commit also clears the activity-bridge
spy before the rerender so the guard measures only that render.

Nit 2 — "Not validated / out of scope" bullet can be struck — valid, same disposition

The maintainer's §1 supplies the missing evidence: the red CI run contained no
other failures, so the caveat is resolvable rather than undeterminable. Same
constraint as Nit 1 — the bullet lives in the PR body, which this mode cannot
edit. Suggested resolution for the merging maintainer: strike that bullet when
finalizing the squash message.

Why no commit

Every actionable code finding from prior rounds is already resolved at the
head commit, the two remaining nits concern PR metadata rather than code, and
all required checks are green. Committing anything here would add diff without
addressing any feedback.

Verification

No build or test commands were run this round because no file was modified;
read-only verification performed:

• git diff origin/main...HEAD — confirmed the full PR diff is the +5/−3 test-only change in packages/web-shell/client/App.test.tsx, matching the maintainer's description.
• git status --short — working tree clean; nothing to commit.
• checks.json scan — no failing checks (only the superseded review-scan job shows CANCELLED).
• Grep of App.test.tsx — mockUseDaemonSessionActivityBridge is declared (line 723), wired into the module mock (line 1625), and referenced by the fixed assertions (lines 28939–28946); the base-branch ReferenceError cannot recur in this file.
• .github/workflows/qwen-autofix.yml inspection — confirmed the address-review path has no PR-body update mechanism, so the two nits are escalated to the merging maintainer rather than silently dropped.

Independent test evidence at this exact head comes from the maintainer's
verification run (full suite green, 7/7 mutants behave as predicted), and the
two approving reviews.

中文说明

Autofix 本轮 —— 无代码改动

已分拣上一轮评估之后的全部新反馈。新反馈只有一条:维护者验证评论 [ic:5593269567](@wenshao),结论是建议合并,并提出两条不阻塞的小问题。没有待处理的内联评论,没有要求修改的评审,也没有失败的检查。头提交 daf3d6d97d 无需任何代码改动,因此本轮没有提交。

反馈处置

[ic:5593269567] —— 维护者验证,建议合并 —— 已知悉

该评论在 PR head 上对修复做了端到端验证:原始 ReferenceError 在 base 内容上可复现;整个 web-shell 套件在 head 上全绿(288/288 个文件、6712/6712 个测试,与 CI 逐字节一致);7 个变异探针确认断言并非空转——包括第 1 轮发现的问题(toHaveBeenCalled() 守卫此前不可能失败)现已真正承重。这也闭环了此前的内联发现(rc:3962062547),该发现已由头提交 daf3d6d97d 解决;评论中没有任何要求改动代码的内容。

小问题 1 —— PR 描述相对第二个提交已过时 —— 属实,但本模式无法操作(由合并维护者在 squash 时处理)

已与真实 diff 核对:diff 为 +5/−3,且新增的 mockClear()——真正让守卫具备失败能力的改动——确实未在 PR 正文中提及。该问题针对的是 PR 描述,属于 GitHub 侧的产物。本模式无法编辑它:agent 没有 GitHub 凭据,且 address-review 路径从不更新 PR 正文(pr-body.md 仅在 develop-issue 路径创建 PR 时被消费——见 .github/workflows/qwen-autofix.yml)。给合并维护者的建议:squash 时在提交信息中补一句,说明第二个提交还在 rerender 前清空了 activity-bridge 的 spy,使守卫只度量那一次渲染。

小问题 2 —— "Not validated / out of scope" 项目符号可删除 —— 属实,处置同上

维护者评论的第 1 节补上了缺失的证据:红色 CI 运行中没有其他失败,因此该保留条款是可以判定的,而非无法判定。约束与小问题 1 相同——该项目符号在 PR 正文中,本模式无法编辑。给合并维护者的建议:在最终确定 squash 提交信息时删掉该项目符号。

为什么不提交

此前各轮所有可操作的代码发现均已在头提交中解决;剩余的两条小问题针对的是 PR 元数据而非代码;所有必需检查均为绿色。此时提交任何内容只会增加 diff,而不解决任何反馈。

验证

本轮未修改任何文件,因此未运行构建或测试命令;已完成的只读验证如下:

• git diff origin/main...HEAD —— 确认完整 PR diff 就是 packages/web-shell/client/App.test.tsx 中 +5/−3 的纯测试改动,与维护者描述一致。
• git status --short —— 工作树干净,无待提交内容。
• checks.json 扫描 —— 无失败检查(仅被取代的 review-scan 任务显示为 CANCELLED)。
• 对 App.test.tsx 的检索 —— mockUseDaemonSessionActivityBridge 已声明(第 723 行)、已接入模块 mock(第 1625 行),并被修复后的断言引用(第 28939–28946 行);base 分支的 ReferenceError 不会在该文件复发。
• 检查 .github/workflows/qwen-autofix.yml —— 确认 address-review 路径没有 PR 正文更新机制,因此两条小问题升级为交给合并维护者处理,而非被静默丢弃。

该 head 上的独立测试证据来自维护者的验证运行(全套件绿色,7/7 变异体行为均如预期)以及两份批准评审。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

---

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.1

[qwen-code-ci-bot]

Released in v0.23.2.