@qwen-code /triage

Qwen Code review did not complete successfully: Qwen review aborted with an API error before posting comments. See workflow logs.

Updated the PR body to follow the template: added What this PR does, Why it's needed, a full Reviewer Test Plan (how-to-verify, before/after schematic, tested-on table, environment), Risk & Scope, and Linked Issues, with a complete paragraph-by-paragraph Chinese translation. Thanks for the pointer — re-triage when you get a chance.

@qwen-code /triage

@qwen-code /triage

Thanks for the PR @wenshao!

Template looks good ✓ — all required sections present, bilingual, thorough.

Direction: Per-task cost visibility in the todo list fills a real gap — the web-shell showed task status but nothing about what each step consumed. This is exactly the kind of observability that makes multi-step agent runs legible. Fits web-shell's role well. No direct Claude Code CHANGELOG reference, but the area (usage visibility, session stats) is squarely in scope.

Approach: The data pipeline is clean and deterministic: cumulative accumulator → snapshot stamped on plan update → SDK pass-through → client-side diff. The previous polling approach was clearly racy, and replacing it with transcript-derived data is the right call. The scope touches exactly the layers it needs to (cli emitter, sdk normalizer, web-shell UI), each change proportional.

One bundled change worth noting: the i18n terminology shift (令牌 → Token) rides along with the feature. It's minor and probably correct (Token is more standard in developer-facing Chinese), but it's a separate concern. Not a blocker.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code review: clean — no correctness bugs, security issues, or convention violations found.

The data pipeline is well-structured across three layers:

• CLI: MessageEmitter accumulates usage with NaN/Infinity guards (the addFinite helper prevents a single bad provider response from corrupting the running total forever). PlanEmitter snapshots a copy (not a reference) of the accumulator onto _meta.stats. The ordering invariant — usage must advance before the plan snapshots it — is documented in comments at both call sites.
• SDK: normalizePlanUpdate is a minimal, safe pass-through: extract _meta.stats if present, fold it into rawOutput. Two lines of logic, tested.
• Web-shell: computeTodoDetails is the most complex piece — a state machine that tracks task windows, diffs cumulative snapshots, and sums tool-time within each window using binary search. It handles the tricky cases correctly: ID reuse after completion (resets the window), task reopening via pending (resets via completedKeys set), stats-less start baselines (upgrades to a later snapshot that has stats).

The TodoFullList component correctly uses stopPropagation on the expander button so clicking a task detail never collapses the parent tool row. The todoDetailSignature memoization keeps the detail map referentially stable across unrelated streaming ticks.

One observation (not a blocker): the expanded state in TodoFullList is keyed by todo.id || String(index). If todos were reordered or removed, an expanded state could attach to the wrong row. In practice, todos are append-only during a session so this won't bite — but worth being aware of.

Testing: this PR modifies the web-shell (a browser-based UI), so tmux-based real-user testing isn't applicable — you can't drive a browser UI from a terminal session. Verification was done via unit/render tests across all three affected packages.

Unit test results (verified on PR branch):

packages/cli — MessageEmitter.test.ts + PlanEmitter.test.ts
  Test Files  2 passed (2)
  Tests       39 passed (39)

packages/sdk-typescript — daemonUi.test.ts
  Test Files  1 passed (1)
  Tests       230 passed (230)

packages/web-shell — todos.test.ts + TodoView.test.tsx + PlanMessage.test.tsx + ToolGroup.test.tsx
  Test Files  4 passed (4)
  Tests       94 passed (94)

Total: 363 passed, 0 failed

The new tests cover the full data path: accumulator correctness (including NaN/Infinity rejection), snapshot stamping and copy semantics, SDK round-trip, snapshot diffing, tool-time windowing with binary search, the resume path (API time omitted, tokens reconstructed), ID reuse after completion, task reopening, the not-captured hint, click-to-expand interaction, and stopPropagation.

— Qwen Code · qwen3.7-max

Stepping back to look at the whole picture: this PR solves a genuine gap in the web-shell — the todo list showed task status but nothing about cost or timing, which is exactly the kind of visibility you need when reviewing a multi-step agent run. The approach is the right one: stamp cumulative usage on plan updates, diff on the client, derive everything from the transcript. No polling, no races, works on resume.

The implementation is thorough without being overengineered. The state machine for task windows handles the tricky cases (ID reuse after completion, reopened tasks, resume without API time) and the tests prove it — 363 tests across the three touched packages, all passing. The binary search for tool-time windowing is a nice efficiency touch. The NaN/Infinity guard in the accumulator is the kind of defensive code that actually matters — one bad provider response shouldn't corrupt the entire session's stats.

Resume caveat: a prior real-browser E2E validation (by a separate reviewer) confirmed that on cold resume, tokens reconstruct correctly and API time is correctly omitted — but duration and tool time do not reconstruct because the daemon replay re-stamps every todo update at replay time, collapsing task windows to ~0 width. The PR description's behaviour table overstates this: it says duration and tool time "still show" on resume, but in practice they degenerate. This is a documentation accuracy issue, not a code bug — the feature's primary value (per-task token/cost visibility) does work on resume. Worth either correcting the table or preserving original transcript timestamps on replay, but not a merge blocker.

The bundled i18n terminology change (令牌 → Token) is minor and doesn't affect the feature. The code is additive and backward-compatible — sessions from older agents degrade gracefully.

LGTM, approving. ✅

— Qwen Code · qwen3.7-max

Qwen Code review did not complete successfully: Qwen review aborted with an API error before posting comments. See workflow logs.

✅ Verification report — real browser E2E (the live run this PR skipped) + data-layer reverse-audit

I validated this PR end-to-end by building the full daemon + web-shell from the branch and driving it in a real Chromium browser against a live qwen serve daemon + vite web-shell over tmux, with glm-4.7 working through multi-step todo_write plans. This covers the gap the PR notes ("no end-to-end run against a live provider … real screenshots are not attached"). TL;DR: the feature works — per-task token & time detail renders correctly end-to-end. I recommend merge. One minor resume-path observation and two negligible heuristic notes below.

How it was validated

Live E2E evidence (real rendered detail panels, glm-4.7 via the daemon)

After the agent completed a plan, expanding a completed task renders exactly the designed layout. Real captured output:

Read package json  ▾
  Time         Start 13:07:07   End 13:07:10 (3.3s)
  Tokens       Input 57,485     Output 132    Cached 57,216
  Time spent   API 3.3s         Tool 16ms
Read readme  ▾
  Time         Start 13:07:10   End 13:07:13 (3.3s)
  Tokens       Input 58,146     Output 133    Cached 57,856
  Time spent   API 3.3s         Tool 23ms
Count deps  ▾
  Time         Start 13:07:13   End 13:07:15 (1.7s)
  Tokens       Input 29,347     Output 127    Cached 29,184
  Time spent   API 1.7s                       ← no Tool row (this step ran no tool)

The numbers are real and correctly differentiated per task (the no-file "Count deps" step has lower tokens and no Tool row). I also instrumented computeTodoDetails in the running app and confirmed it derives these from the daemon's stamped _meta.stats snapshots: every TodoWrite message arrives with hasStats:true + a timestamp, and consecutive snapshots diff into the per-task {inputTokens, cachedTokens, outputTokens, apiTimeMs, toolTimeMs}. The full data path (cli MessageEmitter/PlanEmitter → ACP _meta.stats → sdk normalizePlanUpdate → web-shell todos.ts/TodoView) works as described, with no polling.

The "not captured" hint and compact-mode/expand wiring also behave as designed (a completed task with no measured tokens shows the hint, not a row of zeros).

Resume path

Cold resume (daemon restarted so it reloads from the persisted transcript, then reattached in-browser): tokens reconstruct and the API-time row is correctly omitted (verdict: API-OMITTED-AS-EXPECTED, 0 API rows across the sampled completed tasks, token rows present). This matches the design — the fresh accumulator in acpAgent.ts advances tokens from replayed usage metadata while apiTimeMs only moves on a live per-turn durationMs.

🟠 Finding 1 — on cold resume, duration and tool time do not reconstruct (only tokens do) · Low–Medium

The PR's behaviour table says that on /resume "tokens … from persisted usage metadata" and "tool time … from transcript" reconstruct, and that "start / end / duration … still show". I measured a cold resume (daemon restarted → reloads from the persisted transcript → reattached in-browser) across all 83 completed tasks:

• ✅ tokens reconstruct, ✅ API row omitted (both correct, by design)
• ❌ duration collapses — every task renders Start 13:10:52 End 13:10:52 (0s) (a few (1ms)): start/end show but at replay-time, not the original wall-clock, so durations are degenerate
• ❌ tool time is absent — 0 of 83 blocks show a Tool row, even for the stable-title tasks that showed Tool 16ms / 23ms in the live run

Root cause: the daemon replay re-stamps every todo update (and tool call) at replay time, so the per-task windows collapse to ~0 width; tokens survive because they're cumulative (the diff is timing-independent), but duration and the transcript tool-time windowing both depend on wall-clock timestamps that the replay overwrites. The feature's primary value (per-task token/cost visibility) does work on resume — but the PR description overstates it: on a cold resume, duration and tool time do not reconstruct. Worth either preserving the transcript's original timestamps on replay, or correcting the behaviour table to "tokens only" for resume.

⚪ Finding 2 — tool-time attribution heuristic (negligible) · Info

sumToolTimeInWindow attributes a tool span to the task whose window contains the span's start, and counts the span's full duration. Two consequences, both confirmed with a focused test: (a) a span that starts inside a task but ends after the task completed is counted in full, so tool time can exceed the task's wall-clock duration; (b) a span starting exactly on a shared end==start boundary between two adjacent tasks is counted in both. Both require timing coincidences that don't arise in normal operation (the agent marks a task complete only after its tool returns), so this is a non-issue — noting only for completeness. The documented "reworded-todo / reused id+content" trade-offs in todoStateKey are honest and held up in testing (stable titles key and render correctly).

Recommendation

Approve / mergeable. The core feature is correct and now has a real live-provider E2E behind it (Time + Tokens + API + Tool, with proper graceful degradation). Finding 1 is a small resume-only timing caveat; Finding 2 is informational.

_{Validated at 54b9654e2. Stack: qwen serve daemon (glm-4.7/GLM_API_KEY) + vite web-shell + Playwright Chromium over tmux. Note: ui.compactMode must be off (or toggled via Ctrl+O) for the TodoWrite card body to render, and each card is expanded by clicking its header. Local screenshots captured but not attached.}

Read package json  ▾
  时间    开始 13:07:07   结束 13:07:10 (3.3s)
  Token   输入 57,485     输出 132    缓存 57,216
  耗时    API 3.3s        工具 16ms
Read readme  ▾
  时间    开始 13:07:10   结束 13:07:13 (3.3s)
  Token   输入 58,146     输出 133    缓存 57,856
  耗时    API 3.3s        工具 23ms
Count deps  ▾
  时间    开始 13:07:13   结束 13:07:15 (1.7s)
  Token   输入 29,347     输出 127    缓存 29,184
  耗时    API 1.7s                    ← 无"工具"行（该步未调用工具）

@qwen-code /triage

Qwen Code review did not complete successfully: Qwen review aborted with an API error before posting comments. See workflow logs.