Thanks for the PR!

Template looks good ✓

Problem: this is a feat adding a new extension point (bottomStatusItems) for WebShell embedders — not a bug fix, so no reproduction is expected. The gap is real: embedders currently have no first-class way to surface compact status alongside the TODO panel.

Direction: aligned. WebShell is an actively extended part of the product (CHANGELOG has 20+ web-shell features). The bottomStatusItems prop follows the existing customization pattern (renderComposerToolbarRight, renderFooter, etc.).

Size: not applicable — no core paths touched. 359 production lines + 88 test lines across 10 files, all in packages/web-shell/client/.

Approach: the status-items half (type, TodoPanel rendering, CSS, exports) is clean and minimal. The scroll-follow half (MessageList.tsx +172 lines) is where I'd push back. The PR bundles a substantial rework of the scroll-follow state machine — followPausedByUserRef set in 10+ locations, a userScrollIntentUntil timestamp with four event listeners (wheel, touch, pointer, keyboard), and a new pendingTranscriptBottomScroll lifecycle. All of this is to prevent the follow-toggle from fighting the bottom panel's layout changes, but it's a lot of new state to get right. Have you considered a simpler guard — e.g. only re-evaluating follow state when the panel height is stable (debounced), or skipping the shouldFollow toggle inside the ResizeObserver callback when the trigger is a panel resize rather than new content? That might cover most of the use case without the scroll-intent detection machinery.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

Independent proposal: I'd define a WebShellBottomStatusItem type, add it as a prop, render items in TodoPanel with a separator, and use CSS bottom positioning to keep the floating panel above the composer. For scroll follow, I'd leave the existing state machine alone and just ensure the panel height is reflected in a CSS variable for padding.

Comparison: the status-items half matches my proposal closely — clean type, clean conditional rendering in TodoPanel, clean CSS. The scroll-follow half goes well beyond what I'd have done: followPausedByUserRef (mutated in 10+ locations), userScrollIntentUntil with 4 event listeners, and a new pendingTranscriptBottomScroll lifecycle. This is a substantial rework of the scroll state machine bundled alongside a relatively small extension-point feature.

No correctness bugs found in the code. The new state transitions are internally consistent and the naming is clear. The concern is maintenance surface — scroll-follow behavior now has more moving parts, and timing-dependent interactions (1s userScrollIntent window, ResizeObserver callbacks, RAF chains) are hard to reason about from code alone.

Reuse check: no duplicated logic or missed reuse opportunities. The WebShellBottomStatusItem type is unique to this feature and the CSS follows existing patterns.

Test Results

$ cd packages/web-shell && npx vitest run components/panels/TodoPanel.test.tsx

 RUN  v3.2.4 web-shell/client

 ✓ components/panels/TodoPanel.test.tsx (2 tests) 26ms

 Test Files  1 passed (1)
      Tests  2 passed (2)
   Duration  653ms

$ cd packages/web-shell && npx vitest run components/MessageList

 RUN  v3.2.4 web-shell/client

 ✓ components/MessageList.test.ts (93 tests) 18ms
 ✓ components/MessageList.dom.test.tsx (43 tests) 1227ms

 Test Files  2 passed (2)
      Tests  136 passed (136)
   Duration  1.99s

$ npm run build --workspace=packages/web-shell

✓ built in 8.22s
vite v5.4.21 building for production...
✓ 200 modules transformed.
dist/index.js  1,505.45 kB │ gzip: 356.36 kB
✓ built in 1.36s

All 138 tests pass, build succeeds, no TypeScript errors.

Tmux Testing

Not applicable — this is a WebShell React component feature that requires a browser host application to pass bottomStatusItems via the API. It can't be exercised through the CLI or terminal. The behavior is covered by the 136 existing MessageList tests (including 43 DOM tests that exercise scroll-follow logic) and the 2 new TodoPanel tests.

— Qwen Code · qwen3.7-max

The core feature — bottomStatusItems prop, TodoPanel rendering, type definition, exports — is clean, minimal, and well-tested. It fills a real gap for WebShell embedders and follows the established customization prop pattern. The 2 new TodoPanel tests cover both the combined (todos + status) and status-only rendering paths. All 136 existing MessageList tests still pass.

The scroll-follow overhaul is the part I'd flag. ~172 lines of new scroll state machinery in MessageList — followPausedByUserRef, userScrollIntentUntil with 4 event listeners, pendingTranscriptBottomScroll lifecycle — is a lot of complexity for what started as a "add status items" feature. My independent proposal would have left the scroll state machine alone and just adjusted CSS padding. The author's approach is more thorough (it prevents the follow-toggle from fighting panel layout changes), but it's also harder to reason about long-term. The 1-second userScrollIntentUntil window in particular feels like it could produce subtle timing-dependent behavior.

That said: no correctness bugs found, all tests pass, the build is clean, and the scroll changes are internally well-structured with clear naming. The author clearly understands the scroll system and made deliberate choices. The concern is maintenance cost, not correctness — and that's a tradeoff the maintainer can weigh.

LGTM overall, with the scroll complexity noted for awareness. ✅

— Qwen Code · qwen3.7-max

Suggestions — commit 42ee94df7

— qwen3.7-max via Qwen Code /review