E2E Test Report

Environment

• macOS, production Web Shell build, isolated local daemon, system Chrome headless, real model/tool execution.
• Disposable sessions, task processes, daemon ports, and output directories were removed after each run.

Process output visibility

• Started live background Shell and Monitor tasks with distinct stdout/stderr markers.
• While running, Shell output grew from 139 to 279 characters across two real reads, and Monitor output grew from 279 to 419 characters; every request returned HTTP 200 and the DOM contained the latest marker.
• After natural completion, reopening both details returned HTTP 200 with truncated=false; stdout/stderr markers 01–45 remained visible from first to last line.
• A Monitor finished with eventCount=49 and droppedLines=41, while its output detail still contained all 90 stdout/stderr lines. Notification throttling therefore did not drop captured UI output.
• Running output markers were absent from the main conversation DOM before the task panel opened; the output detail did not depend on running Monitor notifications being rendered there.

Auto-scroll and copy

• With an overflowing output box at the bottom, a live refresh increased scrollHeight from 1514 to 1550 and moved scrollTop from 1156 to 1192, leaving the box at the bottom.
• After manually setting scrollTop=0, another live refresh increased scrollHeight to 1604 while scrollTop remained 0, confirming that refreshes preserve a user's upward scroll position.
• Clicking the copy action produced a 2567-character clipboard value that exactly matched the displayed output snapshot, and the button showed the success check icon.

Automated verification

• npm run build
• npm run typecheck
• npm run lint
• Targeted Core, ACP bridge, CLI serve/ACP, TypeScript SDK, and Web Shell tests.
• Focused task-detail suite: 20/20 tests passed, including overflow-at-bottom, scrolled-away, non-overflowing, copy, truncation, empty, unavailable, refresh, and old-daemon capability fallback cases.

Not manually covered

• Windows and Linux UI runs.
• Browser E2E for the 64 KiB truncation boundary, symlink refusal, cross-session ownership rejection, and missing-file state; these paths have automated coverage.

@qwen-code /triage

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

Autofix round summary — PR #10906

Feedback disposition

[rc:3970931518] R13-1 [Critical] — escape-sequence payload leaks through the capture grammar — Addressed

All five entrances reproduced on the pre-round head with focused failing tests, then fixed at the grammar level in packages/core/src/tools/monitor.ts and packages/core/src/services/backgroundShellRegistry.ts:

• (a) Writer hold-back vs stripper mismatch — the OSC hold class accepted only printable ASCII while the stripper accepts [^\x07\x1b\n\r]*. The hold class now mirrors the stripper's payload class for both OSC and DCS/SOS/PM/APC, so a chunk boundary inside a UTF-8 window title or OSC 8 hyperlink no longer defeats the hold.
• (b) Hold-back cap dropped the hold — an over-PARTIAL_LINE_BUFFER_CAP string sequence (multi-KB OSC 52 / inline image, reachable by accumulation across individually small chunks) now engages a per-stream discardingStringPayload flag: the arrived partial is dropped from the chunk and the remaining payload is discarded until BEL, ST (ESC \), a fresh ESC, LF, or CR — mirroring the stripper's own terminators — instead of being persisted as fabricated output. A chunk-final ESC during the discard stays held with the discard so an ST straddling the boundary cannot leak its backslash. A teardown mid-discard drops the decoder residue as payload, not text. The cap itself was not raised, per the finding's constraint.
• (c) Reader window boundary — readTaskOutputTail now peeks one byte ahead of the window; when the window opens immediately after an ESC, everything up to the first line break is leaderless sequence residue (a sequence can never cross a line break), so the served text starts at the first line that begins inside the window. This covers the shell-writer carrier (a >64 KiB output file holding a chunk-final lone ESC) without touching the shell writer, whose grammar unification the finding explicitly scopes as longer-term.
• (d) String-terminator split — both string hold alternatives now accept a bounded in-flight ST suffix (a trailing lone ESC is held with the sequence), so a boundary between the ST's ESC and its backslash reconstitutes the ST instead of persisting \ as text.
• (e) Close flush — TAIL_CSI_REGEX and TAIL_FE_ESC_REGEX gained the end-of-input arm the OSC and string rules already had, so a teardown whose last chunk ends mid-CSI (ESC [ 3 1) no longer persists the bracket and parameters. The Fe rule still requires an intermediate byte, and \x1b\\ stays first in the string terminator group; MAX_MONITOR_OUTPUT_CAPTURE_BYTES = MAX_TASK_OUTPUT_TAIL_BYTES + 1 is unchanged.

[rc:3970931527] R14-1 [Critical] — CR frame selector treats a whitespace-only erase pad as the frame — Addressed

normalizeOutputCarriageReturns now skips frames whose trim() is empty when choosing kept, so a progress-bar erase pad (spaces/tabs) no longer discards the real frame — and no longer turns a window's only content into undefined (which both consumers surfaced as "task produced no output"). droppedFrames still requires a second non-blank frame, so a real frame followed by a pad reports truncated: false; the doc comment now says non-blank to match. Both pinned collapse fixtures (rec 1\rrec 2\rrec 3, frame 10%…done) stay green.

Deferred / declined

None this round. The review body's deferred non-Critical list is explicitly "recorded, not requested in this round" under the convergence posture, and the Deferred non-Critical feedback brake section is an audit record — per the round rules I did not act on those items.

Conflict notes

--conflict false; no merge performed.

Verification

Reproduction first (pre-fix, at head 7c511421d4): the six new tests fail for the reasons the findings describe —

• backgroundShellRegistry.test.ts: serves the real frame when a redraw erases it with a whitespace pad red (returned undefined); drops the first line when the served window opens mid-escape red (served [31m… residue); pins the multi-segment carriage-return collapse shape green pre-fix (a pin, per the finding green today and red under the mutants it names).
• monitor.test.ts: strips an OSC with a UTF-8 payload split across stdout chunks red; discards an over-cap string payload that grew across small chunks red (payload remainder persisted); strips a DCS split inside its ST terminator across stdout chunks red (stray \ captured); strips a dangling CSI leader flushed at close from the capture red (tail [31); discards an over-cap payload whose ST straddles a chunk boundary red.

Post-fix checks actually run:

• cd packages/core && npx vitest run src/services/backgroundShellRegistry.test.ts src/tools/monitor.test.ts — 176 passed.
• cd packages/cli && npx vitest run src/serve/server.test.ts src/serve/acp-http/transport.test.ts src/acp-integration/acpAgent.test.ts — 2309 passed (downstream consumers of the reader against the rebuilt dist).
• npm run build — passed. npm run typecheck — passed. npm run lint — passed. npx prettier --check on the four touched files — passed.
• Mutation probes (each: revert guard → run → confirm red → restore → green): (1) trim() frame-skip revert → pad test red; (2) hold-regex revert → UTF-8 OSC and DCS-ST tests red; (3) discard-flag revert → over-cap test red; (4) CSI/Fe end-of-input-arm revert → dangling-CSI test red; (5) window-peek revert → mid-escape test red; (6) ST-straddle-branch revert → straddle test red. All restored and re-verified green.

Deferred non-Critical feedback

Critical-only mode is active: 5 change-producing rounds are complete. The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

• @wenshao is at this window's regular-feedback budget — to continue: start your comment with [Critical], submit a Request changes review, or comment @qwen-code /retry for a fresh window. / @wenshao 本窗口常规反馈预算已用完——继续请以 [Critical] 开头评论、提交 Request changes、或评论 @qwen-code /retry 开新窗口。

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

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

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

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

Round-4 local verification on a real stack (maintainer) — head 4661b40aa4

Follow-up to my round-1 (5c41a581a6), round-2 (14ef3e198e) and round-3 (0d2ee20037) reports. Rebuilt this head in a fresh worktree, re-ran the real qwen serve + real Chrome rig, and focused on the three substantive commits added since round 3: c491511461 (teardown join), 7c511421d4 (one escape grammar for writer and reader) and 4661b40aa4 (the remaining grammar gaps).

Result: the Reviewer Test Plan is still 5/5, the safety guards still hold, and the two escape-grammar commits are a large, real improvement for the Monitor path — I measured four distinct payload leaks that they close. Two things need a decision before merge:

1. My round-3 F1 is not fixed, and 7c511421d4 propagated it from the reader into the writer. The Monitor capture now strips through stripOutputControlChars, which still carries the TAIL_FE_ESC_REGEX + bug — so the wrong byte is now written permanently into the capture file, where no reader-side fix can recover it. The one-character half-revert I proposed in round 3 fixes it and, at this head, is strictly better in three distinct cases.
2. F2 (new): the leaderless-residue window rule can serve nothing at all for a >64 KiB single-record stream, rendering as No output yet for a task that has 70 KB of output.

Neither serves wrong data; both are display-level. Everything else about these commits that I could measure came out well — the mutation matrix is 11 killed of 12, up from 4 of 8 at round 3.

Rig — worktree at 4661b40aa4, lockfile-matched node_modules, npm run build; daemon node packages/cli/dist/index.js serve --port 8941 --workspace <tmp git repo>, isolated HOME; ~60-line fake OpenAI provider so real run_shell_command/monitor calls execute; system Chrome; Web Shell client bundle index-CHsT9Vdj.js (recorded on every measurement). npm run typecheck and npm run lint both pass at this head.

0. Scope — what this PR contributes that moved since round 3

Comparing the PR's own contribution (the added/removed line set of git diff <merge-base> <head> per file, so the two main merges do not register):

packages/core/src/services/backgroundShellRegistry.ts  + .test.ts   the grammar work
packages/core/src/tools/monitor.ts                     + .test.ts   capture writer, hold-back, over-cap discard
packages/core/src/services/monitorRegistry.ts                       +8 lines: outputCaptureClosed?: Promise<void>
packages/cli/src/ui/AppContainer.test.tsx                           the QWEN_HOME pin now also pins HOME
packages/web-shell/client/i18n.tsx                                  2 lines: "Showing the latest 64 KiB" -> "Showing the latest output"
packages/web-shell/client/components/messages/TasksStatusMessage.test.tsx   1 line: the matching assertion

The PR's contribution to the other 39 files is byte-identical to round 3, so that report still covers them. TasksStatusMessage.tsx itself did not move, which is why items 3 and 4 below only needed re-confirming.

1. Reviewer Test Plan — 5 / 5 at this head

Route validation and the safety guards, re-measured on this head:

kind missing / kind=bogus         -> 400 VALIDATION_FAILED
no Authorization header           -> 401
unknown taskId                    -> 200 in-band {error:"Task output is unavailable."}
symlink planted over the path     -> refused, the target's secret never served
FIFO planted over the path        -> HTTP 200 in 10 ms, daemon not wedged

2. What the two grammar commits genuinely fix — four leaks, measured live on the Monitor path

One probe writes ESC and its final byte in separate write() calls 250 ms apart (an ordinary pipe-chunk split), run once as a background Shell and once as a Monitor.

On the Monitor path these four all went from leaking to clean, and the capture file now carries 0 ESC bytes:

The mechanism the commit names is real — strip-ansi matches only the two ESC P bytes and leaves the payload:

stripAnsi("a <ESC> P 1$r0m <ESC> \ KEPT")   ->   "a1$r0m\KEPT"
stripAnsi("a <ESC> P 1$r0m <BEL> KEPT")     ->   "a1$r0mKEPT"

But shell.ts:3871 is untouched by this PR — still outputStream.write(stripAnsi(event.chunk)) with no hold-back — and the same route serves kind=shell. So all four leaks are still live there, visible in the browser:

J-dcs 1$r0m\KEPT END      K-dcs-bel 1$r0mKEPT END      L-dcs-unterm 1$rpayload      O-st 1$r0m\KEPT END

The commit message's "the capture now strips through the same TAIL_* grammar the reader serves with" holds for Monitor only. Closing the Shell half is the natural follow-up — either share the Monitor writer, or leave it, but the design doc should not claim both halves are covered.

3. F1 is not fixed, and it is now written to disk

TAIL_FE_ESC_REGEX is still /\x1b[\x20-\x2f]+(?:[\x30-\x7e]|$)/g. At round 3 that leaked the final byte of split two-byte Fe escapes on the reader side only. Now the Monitor writer uses the same function, so the wrong byte is persisted:

round-3 head   monitor capture file   b'G-split-fe decsc decrc crix END'     (correct)
THIS head      monitor capture file   b'G-fe 7decsc 8decrc ccrix END'        (0 ESC bytes - the 7/8/c are real text on disk now)

Same one-character half-revert as round 3, and at this head it is strictly better in three distinct cases, not one. Pure-function comparison on the real dist:

Over 4 000 modelled Shell capture files (identical bytes on both arms): real characters lost 8 254 on both; garbage characters leaked 10 644 head vs 9 406 arm C; of 1 078 disagreements, arm C correct 108, head correct 0.

Arm C costs exactly two assertions, and both pin a leak rather than a behaviour:

• readTaskOutputTail > deletes only the ESC of a residual lone ESC, keeping the byte after it — the ambiguous ESC W case.
• MonitorTool > flushes held escape and decoder tails into the capture at close — this one pins 'tail [<U+FFFD>', i.e. it asserts that the CSI introducer is persisted. Its own comment says "the readable bytes that followed it stay", but [ is the sequence's introducer, not a byte the program wrote.

-const TAIL_FE_ESC_REGEX = /\x1b[\x20-\x2f]+(?:[\x30-\x7e]|$)/g;
+const TAIL_FE_ESC_REGEX = /\x1b[\x20-\x2f]*(?:[\x30-\x7e]|$)/g;

4. F2 (new, Suggestion) — the leaderless-residue rule can serve nothing at all

readTaskOutputTail now peeks one byte before the 64 KiB window; if it is ESC, everything up to the first line break is dropped as residue. With files laid out so the byte before the window is exactly the one named:

Reachable for any single-record stream over 64 KiB — a JSON log line, a base64 blob, minified bundle output — whose window boundary happens to land on an ESC. Bounded probability, total consequence, and the empty result is indistinguishable from a task that genuinely produced nothing. Dropping one line when a break exists is defensible; the firstBreak === -1 branch should fall back to serving the window rather than discarding it.

5. The new truncated semantics fire on ordinary progress bars

Folding droppedFrames into truncated is honest — the CR collapse really does destroy records — and the notice text was softened to match. Worth knowing what it costs in practice: a 104-byte progress bar now carries the truncation notice even though its entire output is on screen.

capture file (104 bytes)   downloading pkg-a <CR> downloading pkg-a 35% <CR> downloading pkg-a 100% done <LF> installed 3 packages <LF> PROGRESS-DONE
served                     truncated = true, 3 lines, all of them shown
pane                       "Showing the latest output"

Not a defect — just a call worth making deliberately, since npm, pip, curl -# and most build tools will now show it.

6. Mutation matrix on the new commits — 12 mutants, 11 killed

The bot's own test-efficacy probe still reports no measurement for this PR, so this is measured rather than assumed. Both new test files are much stronger than at round 3 (which was 4 killed of 8).

M5 is a coverage gap, not an equivalent mutant: I rebuilt it and a teardown chunk ending in ESC ( serves 'a' at head and 'a(' under the mutant.

7. Suites at this head (macOS — the lane CI skips outside merge_group)

Both failures are load-dependent flakes in areas this PR does not touch, and both are green when their file runs alone (bridge.test.ts 920 passed twice; server.test.ts 1 259 passed): preheat > clamps explicit keep-alive to the setTimeout maximum / arms idle timer on preheated channel, and GET /workspace/:id/sessions > reports organized session truncation. They appeared only while the batch ran alongside the daemon and a browser. Round 3 saw the same class in server.test.ts and reproduced it on the merge base.

CI at this head: Qwen Code CI success — Test (ubuntu-latest, Node 22.x), Lint & Static, web-shell E2E Smoke, Integration Tests (no-AK) and both Desktop Shell lanes green; Test (macos-latest) and Test (windows-latest) skipped, which is the gap these local macOS runs fill.

Verdict

The direction of these two commits is right and the Monitor half is materially better than it was at round 3 — four real payload leaks closed, pinned by tests a same-tree revert kills. Before merge I would like the one-character F1 half-revert in section 3, because that defect is now persisted to disk rather than applied at read time, and its two pinning assertions both encode a leak. F2 and the Shell-side writer asymmetry are fine as follow-ups. Nothing here serves wrong data or affects the session-owner binding, the 64 KiB ceiling, or the symlink/FIFO guards, all of which I re-measured and they hold.

packages/core/src/services/backgroundShellRegistry.ts  + .test.ts   语法改动
packages/core/src/tools/monitor.ts                     + .test.ts   捕获写入器、hold-back、超限丢弃
packages/core/src/services/monitorRegistry.ts                       +8 行：outputCaptureClosed?: Promise<void>
packages/cli/src/ui/AppContainer.test.tsx                           QWEN_HOME 之外再钉住 HOME
packages/web-shell/client/i18n.tsx                                  2 行：「仅显示最近 64 KiB」→「仅显示最新输出」
packages/web-shell/client/components/messages/TasksStatusMessage.test.tsx   1 行：对应断言

缺少 kind / kind=bogus            -> 400 VALIDATION_FAILED
无 Authorization 头               -> 401
未知 taskId                       -> 200 带内 {error:"Task output is unavailable."}
在输出路径放置符号链接            -> 拒绝，目标文件的秘密内容从未被返回
在输出路径放置命名管道            -> HTTP 200，耗时 10 ms，daemon 未被楔死

stripAnsi("a <ESC> P 1$r0m <ESC> \ KEPT")   ->   "a1$r0m\KEPT"
stripAnsi("a <ESC> P 1$r0m <BEL> KEPT")     ->   "a1$r0mKEPT"

J-dcs 1$r0m\KEPT END      K-dcs-bel 1$r0mKEPT END      L-dcs-unterm 1$rpayload      O-st 1$r0m\KEPT END

第三轮 head    monitor 捕获文件   b'G-split-fe decsc decrc crix END'   （正确）
本 head        monitor 捕获文件   b'G-fe 7decsc 8decrc ccrix END'      （ESC 数为 0——7/8/c 已成为磁盘上的真实文本）

捕获文件（104 字节）   downloading pkg-a <CR> downloading pkg-a 35% <CR> downloading pkg-a 100% done <LF> installed 3 packages <LF> PROGRESS-DONE
返回                   truncated = true，3 行，全部显示
面板                   「仅显示最新输出」

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

Autofix round summary — PR #10906

Addressed all four actionable Critical findings. Each fix ships with the red-test
witness the finding named, and every new guard/branch was mutation-probed
(removed → pinned test fails → restored → green).

[rc:3973840767] R13-1 — escape-grammar class (monitor.ts / backgroundShellRegistry.ts)

All five measured entrances are closed, sharing the one stripper grammar:

1. Reader window (e1) — readTaskOutputTail no longer peeks one byte and
   drops the first line. It scans back a bounded prefix (≤ 4096 bytes, stopping
   at the previous line break) for the nearest ESC before the window and
   prepends from it, so the stripper removes the reconstituted sequence whole
   and the real first line survives. Pinned by the flipped mid-escape test plus
   new fixtures whose windows open 2 and 9 bytes into ESC[38;5;208m.
2. Teardown (e2) — flushPartialLineBuffers now strips the held escape and
   the decoder residue independently, so a U+FFFD can no longer defeat the
   end-of-input arm; the capture records tail instead of tail [.
   The sibling test's expectation was flipped deliberately, as the finding
   instructed.
3. Over-cap non-string leader (e3) — the discard state now carries the
   leader kind (string | csi | fe) with per-class terminator scans, so an
   over-cap CSI or Fe payload is discarded until its final byte instead of
   fabricating that byte into the capture and the event stream.
4. Line-break cut (e4) — the CSI and Fe stripper rules gained the
   (?=[\x1b\n\r]) newline-lookahead arm their OSC/string siblings already
   carried; a leader cut by LF/CR strips whole instead of leaking its bracket
   and parameters.
5. Two-byte escapes (e5) — a new rule strips the assigned no-intermediate
   escapes (SS2/SS3, the Fe single functions D/E/H/M/N/O/Z, the DEC private
   pairs 6–9/=/>, RIS ESC c, the locking shifts ESC n/o/|/}/~). Unassigned
   finals still cost only the ESC byte, so the pinned lone-ESC contract
   (ESC W keeps W) is intact.

Not done, with reasons:

• The suggested writer rewrite (retain raw bytes, re-strip the whole retained
  window per flush) was considered and declined: it would leak the tail of any
  payload larger than the 64 KiB capture window (today's discard state handles
  those at any size) and would re-strip the whole window on every chunk,
  amplifying the already-reported per-chunk rewrite cost (R2-5). The
  per-entrance closures above close every measured witness without that
  regression.
• The producer-side follow-up named in the finding (giving the background-shell
  capture writer in packages/core/src/tools/shell.ts the monitor writer's
  cross-chunk hold-back) is outside this PR's footprint; recorded in
  deferred-findings.json for the follow-up queue.

[rc:3973840774] R15-1 — mid-escape drop destroyed real output (backgroundShellRegistry.ts)

Fixed by the same reader rewrite: the drop-to-first-line branch and its
empty-the-window arm are gone. A window that opens mid-sequence keeps its real
line; a window with no line break at all is served instead of collapsing to
undefined; a cut landing on a CRLF no longer serves a leading blank line (one
leading \n is trimmed on the prepend path only, so the full-window leading
\n pin is untouched). truncated stays start > 0 || droppedFrames and the
read stays bounded by Math.min(N, start).

[rc:3973840778] R15-2 — over-cap branch sliced away the terminator ESC (monitor.ts)

The over-cap branch now keeps a string payload's trailing ESC held
(held = '\x1b', slice one byte less), so the next chunk's backslash
reconstitutes the ST and the real line after the sequence survives. The
existing straddle test (ST ESC arriving in a later payload chunk) still passes;
a new test with the ESC as the cap-crossing chunk's final byte pins the fix.

[rc:3973840783] R15-4 — silent capture write failures (monitor.ts / monitorRegistry.ts / tasksSnapshot.ts / status types)

• The first write failure is recorded on the registration as
  outputCaptureError; the writer gives up after 3 consecutive failures
  (success resets the counter) instead of re-attempting a doomed full-tail
  write on every chunk.
• The failure is surfaced beside droppedLines: in the terminal notification
  (display text and <summary>) and in the served status
  (tasksSnapshot.ts → ServeSessionMonitorTaskStatus →
  DaemonSessionMonitorTaskStatus), so readers can tell a stale tail from a
  complete one.
• My own probe of this path exposed a latent race in the PR's flush loop: a
  chunk dirtied between the loop's last check and the promise reset left the
  dirty flag set with no writer running — the capture would silently stop
  advancing and the close join could hang. The .finally now restarts the
  loop when the tail is dirty. (The give-up branch forces the flag false, so
  this never re-arms a dead disk.)

Mutation probes

Verification

• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed
• npx prettier --check on all 10 changed files — passed (2 files auto-formatted with --write first, then re-verified)
• vitest packages/core: src/tools/monitor.test.ts (101), src/services/monitorRegistry.test.ts (59), src/services/backgroundShellRegistry.test.ts (86) — 246 passed
• vitest packages/cli: tasksSnapshot.test.ts (20), serve/server.test.ts + serve/acp-http/transport.test.ts (1647), acp-integration/acpAgent.test.ts (682) — passed
• vitest packages/acp-bridge — 1996 passed
• vitest packages/sdk-typescript (DaemonClient, DaemonSessionClient, acpRouteTable) — 616 passed
• vitest packages/web-shell (TasksStatusMessage, daemon session actions) — 229 passed
• Integration: npm run bundle then QWEN_SANDBOX=false npx vitest run cli/qwen-serve-routes.test.ts in integration-tests/ — 38 passed

Deferred non-Critical feedback

Critical-only mode is active: 5 change-producing rounds are complete. The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

• PR comment by @wenshao: feat(web-shell): show shell and monitor task output #10906 (comment)

• @wenshao is at this window's regular-feedback budget — to continue: start your comment with [Critical], submit a Request changes review, or comment @qwen-code /retry for a fresh window. / @wenshao 本窗口常规反馈预算已用完——继续请以 [Critical] 开头评论、提交 Request changes、或评论 @qwen-code /retry 开新窗口。

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

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

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

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

Round-5 local verification on a real stack (maintainer) — head 5ef3c95258

Follow-up to round-3 (0d2ee20037) and round-4 (4661b40aa4). One commit landed after my round-4 report — 5ef3c95258 — and it addresses both of the things I asked about.

Result: F1 and F2 are both fixed, and F1 by a better mechanism than the one I proposed. The new capture-failure surface works end to end. My round-4 blocking ask is resolved; I have no blocking item at this head. Two new Suggestion-level notes below (F3, F4), plus the Shell-side writer asymmetry from round 4 that is still open by design.

Rig — worktree at 5ef3c95258, lockfile-matched node_modules, npm run build; daemon node packages/cli/dist/index.js serve --port 8951 --workspace <tmp git repo>, isolated HOME; ~60-line fake OpenAI provider so real run_shell_command/monitor calls execute; system Chrome; Web Shell client bundle index-CHsT9Vdj.js. npm run typecheck and npm run lint both pass.

1. F1 is fixed — with an enumerated allowlist, which is the right call

I asked for TAIL_FE_ESC_REGEX + → *. The commit did something better: it left the Fe rule alone and added

const TAIL_TWO_BYTE_ESC_REGEX = /\x1b(?:[DEHMNOZ]|[6-9=>]|[cno|}~])/g;

That strips the assigned two-byte escapes without touching the byte after a genuinely stray ESC — so it resolves the ambiguity I flagged in round 3 instead of trading one side of it for the other. Measured on the real dist:

Live on the daemon, same probe as round 4 (a child writing ESC and its final byte in separate write() calls 250 ms apart):

SHELL   served   "G-fe decsc decrc crix END"      (round 4: "G-fe 7decsc 8decrc ccrix END")
MONITOR served   "G-fe decsc decrc crix END"      and the capture file holds 0 ESC bytes

The monitor capture file being clean is the part that mattered most — round 4's version had written 7decsc to disk, where no reader-side fix could recover it.

2. F2 is fixed — and better than I asked for

I suggested the firstBreak === -1 branch fall back to serving the window. The commit instead looks back up to 4 096 bytes for the sequence's leader and prepends it so the stripper can remove the whole sequence, which keeps the real first line as well:

3. The new capture-failure surface works end to end

I drove it live: a running monitor, then chmod 500 on its capture directory so every write fails.

served status        outputCaptureError = 'atomicWriteFile("…"): EACCES: permission denied…'
model notification   <summary>… Output capture failed: atomicWriteFile(&quot;…&quot;): EACCES …</summary>
give-up latch        the capture froze at 144 bytes / "cap line 12" and stayed there even after
                     I restored the directory permissions (MAX_OUTPUT_WRITE_FAILURES = 3)
final task           status completed, eventCount 25, served output 12 lines

So the tail really is stale — but it is no longer silently stale, which is the whole point of the change. Both the browser and the model are told.

4. F3 (new, Suggestion) — the lookback can serve past the documented 64 KiB ceiling

When the nearest ESC before the window is a stray one on the same line, everything between it and the window is prepended and served, so the response exceeds the cap by that distance:

ESC..window gap      0     100    1000    4000    4095    4096    5000
served chars     65536   65636   66536   69536   69631   65536   65536
over the cap         0     100    1000    4000    4095       0       0

Bounded at MAX_TAIL_SEQUENCE_LOOKBACK_BYTES = 4 096, so the served tail is really "at most 64 KiB + 4 095 bytes". The design doc and the reviewer test plan both say 64 KiB. Either clamp after prepending or state the real bound — this is a one-line call, not a defect.

5. F4 (new, Suggestion) — the capture-failure message is 746 chars and repeats the absolute path

The recorded error embeds the daemon-absolute capture path twice — once in the atomicWriteFile(…) prefix and once in the EACCES body — and it ships to the browser client and into the model-facing <summary>. This PR exists partly because "a daemon-local file path is often not useful to a remote browser"; trimming to the errno plus a basename would fit that better and cost the model far fewer tokens.

6. Still open from round 4 (not a regression, and not introduced here)

shell.ts:3871 is still outputStream.write(stripAnsi(event.chunk)) with no hold-back, and strip-ansi eats ESC P as a two-byte escape — so on kind=shell the DCS payloads still reach the browser, while the Monitor path (which this PR hardened) is clean:

SHELL     J-dcs 1$r0m\KEPT END      K-dcs-bel 1$r0mKEPT END      L-dcs-unterm 1$rpayload
MONITOR   J-dcs KEPT END            K-dcs-bel KEPT END           L-dcs-unterm

Fine as a follow-up; I only ask that the design doc not claim both halves share one grammar.

7. Mutation matrix on the new commit — 12 mutants, 8 killed

The three witnessed survivors are coverage gaps, not equivalent mutants. N7 is the one worth a line of test — it is exactly what keeps F3 bounded to a single line instead of running back across the whole 4 KiB lookback.

8. Reviewer Test Plan and guards at this head

kind missing / kind=bogus   -> 400 VALIDATION_FAILED
no Authorization header     -> 401
symlink over the path       -> in-band error, the target's secret never served
FIFO over the path          -> HTTP 200 in 12 ms, daemon not wedged

Suites at this head, all green, no flakes this run:

Verdict

My round-4 blocking ask is resolved and I have no blocking item at this head. F1 was fixed with a better mechanism than I proposed, F2 was fixed more thoroughly than I asked, and the capture-failure surface does what it says on a real daemon. F3, F4, the N5/N7/N12 coverage gaps and the Shell-side writer asymmetry are all follow-up sized. From my side this is ready to merge.

const TAIL_TWO_BYTE_ESC_REGEX = /\x1b(?:[DEHMNOZ]|[6-9=>]|[cno|}~])/g;

SHELL   返回   "G-fe decsc decrc crix END"      （第四轮："G-fe 7decsc 8decrc ccrix END"）
MONITOR 返回   "G-fe decsc decrc crix END"      且捕获文件中 ESC 字节数为 0

返回状态       outputCaptureError = 'atomicWriteFile("…"): EACCES: permission denied…'
模型通知       <summary>… Output capture failed: atomicWriteFile(&quot;…&quot;): EACCES …</summary>
放弃闩锁       捕获文件冻结在 144 字节 /「cap line 12」，即使我恢复目录权限后也不再前进
               （MAX_OUTPUT_WRITE_FAILURES = 3）
最终任务       status completed、eventCount 25、返回输出 12 行

ESC 到窗口的间距      0     100    1000    4000    4095    4096    5000
返回字符数        65536   65636   66536   69536   69631   65536   65536
超出上限              0     100    1000    4000    4095       0       0

SHELL     J-dcs 1$r0m\KEPT END      K-dcs-bel 1$r0mKEPT END      L-dcs-unterm 1$rpayload
MONITOR   J-dcs KEPT END            K-dcs-bel KEPT END           L-dcs-unterm

缺少 kind / kind=bogus   -> 400 VALIDATION_FAILED
无 Authorization 头      -> 401
在路径上放置符号链接     -> 带内错误，目标文件的秘密内容从未被返回
在路径上放置命名管道     -> HTTP 200，耗时 12 ms，daemon 未被楔死

🤖 AutoFix stopped: this counting window now contains 3 agent time-budget exhaustions (pushed rounds in between included; this round itself may have failed differently). That is 3 full agent runs that pushed nothing. A human should split or reduce the PR (or raise the agent time budget AND its step backstop together), then comment @qwen-code /retry to re-arm. Until then future scans will skip this PR.

⚠️ This change was NOT pushed — any commit referenced below was made only in the runner workspace and has been discarded. What the agent reported:
Qwen failed during address-review: timeout (7200000ms).

See the Qwen Autofix agent step logs for model/tool output.

Run log: https://github.com/QwenLM/qwen-code/actions/runs/34451132365

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

⏸️ Takeover paused: this PR reached its round cap (100/100). Comment @qwen-code /takeover to re-arm a fresh window and continue management, or @qwen-code /takeover stop to release.

@qwen-code /resolve

Qwen Code resolved the merge conflicts and pushed the branch update.

Root cause

Main's 471b6e5ef5 (PR #11262, session sources) collided with this PR. Both append to the same legacySessionTelemetryRoutes catalog and rewrite the same derived counters: ours added GET /session/:id/tasks/:taskId/output (69→70), theirs the three /session/:id/sources routes (69→72).

Semantic, not merely adjacent

The route table auto-merged: the four entries sit in disjoint regions and all survived. The counters did not — each side wrote a total that must include the other's routes, so taking either parent under-counts and fails the guard. Resolution is the union, verified by counting the merged table:

// telemetry.test.ts
it('contains 73 unique routes with the audited 71/2 attribution split', ...)
expect(keys).toHaveLength(73);   expect(new Set(keys).size).toBe(73);
/* handler_resolved */ ).toHaveLength(71);  // 67 base + 1 ours + 3 theirs
/* pre_resolved     */ ).toHaveLength(2);   // untouched by either side
// telemetry-catalog.test.ts
expect(registered).toHaveLength(73);  expect(registered).toEqual(catalog);

Load-bearing

• registered comes from the live Express router stack, so 73 holds only if both sides' registrations survived too. They did (session.ts:6243/:6349/:6368/:6393). Never relax toEqual(catalog) into a subset check to make a count pass — that equality is the guard.
• Catalog order is not load-bearing for the new routes: the matcher rejects on segment-count mismatch first, so the 3-, 4- and 5-segment additions cannot shadow each other. Pairwise-checking all 73, the only first-match-wins ambiguity is pre-existing: turns/current vs turns/:promptId, untouched here, but that one is order-sensitive — keep current first.

Not verified

No build, typecheck, lint or tests were run. Two non-conflicted dependents, checked statically:

• integration-tests/cli/qwen-serve-routes.test.ts auto-merged an exact capability-key list both sides extended (session_task_output ours; session_sources, web_shell_brand theirs). All three are in the merged test and in SERVE_CAPABILITY_REGISTRY.
• telemetry.test.ts's "matches every catalog entry…" loop is catalog-driven, so it now runs theirs' three routes through this PR's resolver for the first time. The resolver builds from the same catalog, so no break is expected.

@qwen-code /triage

🔓 Takeover auto-released: the autofix loop paused on this PR 3 day(s) ago (🤖 AutoFix stopped: this counting window now contains 3 agent time-budget exhaustions (pushed rounds in between included;) and no re-arm followed, so the autofix/takeover label is removed to keep the managed pool honest. autofix/needs-human stays as the reminder that this PR needs a human decision: merge it, close it, or split/reduce it and comment @qwen-code /takeover to re-engage with a fresh round window.

@qwen-code /resolve

Qwen Code attempted to resolve merge conflicts but the run did not complete successfully.

Check the workflow run for full logs.

Review follow-up and verification report

Commit: 84402dff7a. Merged current main and resolved the bridge split, sandbox runtime, telemetry catalog, and test integration conflicts.

The follow-up fixes the confirmed control-filter grammar/adjacency issues, strict returned-byte bound, capture-failure visibility and recovery, and a terminal Monitor capture-flush race. The full build, typecheck, bundle, lint, targeted Core/CLI/ACP/SDK/Web Shell tests and 41 daemon-route integration tests passed locally. Two clean self-audit passes and independent review found no remaining confirmed Critical. Remote CI is running separately.

E2E and regression verification

Verified the rebuilt CLI with a real Monitor child process and a localhost mock model. Split escapes, embedded controls, oversized OSC payloads terminated by C1 ST/CAN, and ordinary Unicode text produced the expected captured output and served tail. All seven output lines survived even when event notifications were throttled.

The original parser/reader witnesses now pass: no measured escape residue, no ordinary text lost through adjacent escapes, and exactly 65,536 bytes returned for the former 69,627-byte overflow case.

Capture failures show a notice in Web Shell and TUI while retaining captured text; recovery clears the warning. A cancelled monitor's task-output request stays pending until the final capture flush completes, then returns the final bytes.

Results: 45 focused regression tests passed, plus the bundled-CLI capture assertion. This combines headless CLI E2E with component and ACP endpoint tests; it does not claim interactive browser E2E or a physical disk-full test.

Tested bundle SHA-256: c2e08955908a194b4b041c0a7897e0ed0c9c38d5e1abaea3919cfe86991dcace.

中文：已合并 main 并处理冲突，修复控制序列清理、输出字节上限、捕获失败提示及取消时末尾输出读取竞态。本地构建、类型检查、打包、lint、相关定向测试及 41 项路由集成测试通过；最终实测和回归验证结果如下述报告。远端 CI 正在运行，未将本地测试结果等同于远端 CI 通过。

Review follow-up scope

Tracked in #12849.

This PR has already passed through more than 17 review rounds. Following AGENTS.md’s review-convergence rule, this update fixes confirmed correctness defects and merge regressions. The following remaining Suggestion families are explicitly deferred rather than represented as fixed. Repeated round-2/3/4 copies are grouped under their original id; each linked thread retains the detailed request.

R1-5 (CI collection) is covered by the current no-AK integration script and the 41-test integration run. R1-12 (unbounded file) is already fixed by the rolling tail; R2-11 (hard-cap coverage) is addressed in this update.

中文：本 PR 已经历超过 17 轮审查，按仓库约定，本轮只修复已确认的正确性问题和合并回归。上表逐项记录仍需后续处理的建议，并保留原评论链接；这些建议不冒充已修复。R1-12 已由滚动尾部解决，R2-11 的硬上限测试已补齐。

Fixed the Lint & Static failure in d27482b4e9. The capture-failure warning was missing its required Traditional Chinese translation; the standalone i18n parity gate reproduced the CI failure with exactly that error. Added the missing translation without changing validation rules or runtime logic.

Validation: the exact npm run check-i18n command now passes, as do build, typecheck, bundle, formatting/ESLint, and 161 focused i18n/task-detail tests. Independent verification confirmed the same translation in source and bundled locale assets. The latest main merge is preserved. The remote Lint & Static job has now completed successfully, including the originally failing i18n check and every subsequent static gate. Other test/review jobs are still running; no other failure is currently reported.

中文：已补齐遗漏的繁体中文文案，修复严格 i18n 检查失败。原始失败命令、本地构建与类型检查、打包和 161 项相关测试均通过，打包产物也已独立复核。远端 Lint & Static 已完整通过，包含原先失败的 i18n 检查及后续全部静态检查；其他测试与评审尚在运行，当前没有其他失败项。