fix(web-shell): improve follow-up suggestion handling

[ytahdn]

What this PR does

This PR improves web-shell follow-up suggestion handling in two places. First, when a follow-up suggestion is visible, the composer send button now treats the suggestion as sendable content. Clicking send submits the full suggestion when the editor is empty or when the editor text is a matching prefix of that suggestion, matching the existing Enter-key behavior. Second, follow-up suggestions are scoped more carefully across session switches so a suggestion from one session is not carried into another session.

The change also adds focused logic coverage for follow-up completion matching: empty input, matching prefixes, and non-matching text.

Why it's needed

Before this change, users had to press Tab to materialize a visible follow-up suggestion before the send button became usable. This made the send button appear disabled even though the UI was already showing a valid next prompt. In addition, switching from a session with a follow-up suggestion to another session could leave the previous suggestion visible if the next session did not have one.

The updated behavior lets users send the visible follow-up directly and clears only the local/global suggestion state that can leak between sessions, while preserving the new session's own transcript-store suggestion if it has one.

Reviewer Test Plan

How to verify

In web-shell, get a completed response that shows a follow-up suggestion. Confirm the send button is enabled even before pressing Tab, and clicking it sends the full follow-up suggestion. Then type a prefix that matches the suggestion and confirm the send button still submits the full suggestion. Type unrelated text and confirm the suggestion is not used. Switch from a session with a suggestion to a session without one and confirm the old suggestion disappears. Switch from a session without a suggestion to one that has its own follow-up and confirm the new suggestion still appears.

Local verification: cd packages/web-shell && npx vitest run client/hooks/useComposerCore.test.ts; cd packages/webui && npm run typecheck; cd packages/web-shell && npx tsc --noEmit -p tsconfig.lib.json.

Evidence (Before & After)

Before: the send button stayed disabled for a visible follow-up until the user accepted it with Tab, and session switches could retain a stale suggestion from the previous session.

After: the send button can submit the visible follow-up directly, matching Enter behavior, and session switches clear leaked local/global suggestion state without deleting a new session's own suggestion.

Tested on

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

Environment (optional)

Node 22 workspace, targeted web-shell hook test plus webui and web-shell TypeScript checks.

Risk & Scope

• Main risk or tradeoff: Follow-up acceptance through the send button is currently reported through the same accept path used by keyboard submission, so telemetry does not distinguish the button source.
• Not validated / out of scope: Full browser visual regression testing and cross-platform CI.
• Breaking changes / migration notes: None.

Linked Issues

N/A

中文说明

这个 PR 做了什么

这个 PR 优化了 web-shell follow-up suggestion 的两个行为。第一，当 follow-up suggestion 可见时，composer 的发送按钮会把它视为可发送内容；如果输入框为空，或者当前输入是 suggestion 的匹配前缀，点击发送会直接提交完整 suggestion，这和已有的 Enter 键行为保持一致。第二，切换 session 时更严格地隔离 follow-up suggestion，避免一个 session 的 suggestion 带到另一个 session。

同时补充了聚焦的逻辑测试，覆盖 follow-up completion 的空输入、前缀匹配和不匹配文本三种情况。

为什么需要

修改前，用户必须先按 Tab 将可见的 follow-up suggestion 填入输入框，发送按钮才可用；这会让按钮看起来不可点击，虽然 UI 已经展示了一个有效的下一条 prompt。此外，从有 follow-up 的 session 切到另一个 session 时，如果下一个 session 没有 suggestion，之前的 suggestion 可能残留。

新的行为允许用户直接发送当前可见的 follow-up，并且只清理可能跨 session 泄漏的本地/全局 suggestion 状态，同时保留新 session 自己 transcript store 中的 suggestion。

Reviewer Test Plan

如何验证

在 web-shell 中让一次回复完成并展示 follow-up suggestion。确认不按 Tab 时发送按钮也可用，点击后会发送完整 follow-up suggestion。然后输入 suggestion 的匹配前缀，确认发送按钮仍会提交完整 suggestion。输入不相关文本时，确认不会使用 suggestion。从有 suggestion 的 session 切换到没有 suggestion 的 session，确认旧 suggestion 消失。从没有 suggestion 的 session 切换到一个自身有 follow-up 的 session，确认新 suggestion 仍能展示。

本地验证：cd packages/web-shell && npx vitest run client/hooks/useComposerCore.test.ts；cd packages/webui && npm run typecheck；cd packages/web-shell && npx tsc --noEmit -p tsconfig.lib.json。

前后对比证据

Before：可见 follow-up 在用户按 Tab 接受之前，发送按钮仍是 disabled；切换 session 时可能残留上一个 session 的 suggestion。

After：发送按钮可以直接提交可见 follow-up，行为与 Enter 保持一致；session 切换会清理泄漏的本地/全局 suggestion 状态，同时不会删除新 session 自己的 suggestion。

Tested on

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

Environment (optional)

Node 22 workspace，运行了定向 web-shell hook 测试，以及 webui/web-shell TypeScript 检查。

风险和范围

• 主要风险或取舍：通过发送按钮接受 follow-up 目前复用键盘提交的接受路径，telemetry 不单独区分按钮来源。
• 未验证 / 不在范围内：完整浏览器视觉回归测试和跨平台 CI。
• Breaking changes / 迁移说明：无。

Linked Issues

N/A

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓ — all required sections present with bilingual description.

On direction: this solves two real UX problems in web-shell — the send button looking disabled when a follow-up suggestion is already visible, and stale suggestions leaking across session switches. Both are straightforward quality-of-life fixes well within the web-shell's scope. No CHANGELOG reference expected here (web-shell follow-up UX is qwen-code–specific).

On approach: the scope is tight — three files, ~77 additions, all directly serving the stated goals. Reusing the existing getFollowupCompletion helper (just exporting it) for the send-button path is the right call; no new abstractions. The session-switch cleanup correctly clears only the local and sidechannel state while preserving the transcript store's own suggestion. Nothing to cut.

Moving on to code review and testing. 🔍

中文说明

感谢贡献！

模板完整 ✓ — 所有必填章节齐全，含中英双语。

方向：解决了 web-shell 中两个真实的用户体验问题 —— 当 follow-up suggestion 已经可见时发送按钮仍显示为不可用，以及切换 session 时旧 suggestion 残留。两者都是合理的体验优化，在 web-shell 范围内。

方案：范围紧凑 —— 三个文件，约 77 行新增，全部服务于目标。复用已有的 getFollowupCompletion（仅改为 export）来处理发送按钮逻辑，没有引入新抽象。Session 切换清理正确地只清理本地和 sidechannel 状态，保留了 transcript store 自身的 suggestion。无需裁剪。

进入代码审查和测试 🔍

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Code Review

The diff is clean and well-targeted. Two changes, both serving the stated goals:

Send-button follow-up support (useComposerCore.ts): getFollowupCompletion was already the right helper — exporting it and wiring it into hasContent and submitText is the minimal path. The textOverride === undefined guard correctly prevents overriding explicit submissions. The onAcceptFollowupRef.current?.('enter', { skipOnAccept: true }) call after a followup-via-button submit matches the existing Enter-key path at line 1431, so telemetry and cleanup stay consistent.

Session-switch cleanup (useDaemonFollowupSuggestion.ts): Scoping the sidechannel suggestion to sessionId and clearing local/global state on session change is the right fix. The guard previousSessionId !== undefined && sessionId !== undefined correctly avoids false positives on initial mount and disconnect. Preserving the transcript store's own suggestion (which is already per-session) is the right call.

No correctness bugs, no security concerns, no AGENTS.md violations. The EditorView.updateListener and useEffect both compute followupCompletion the same way — a small amount of duplicated logic, but inlining it would be worse for readability.

Testing

Unit tests (packages/web-shell):

 ✓ hooks/useComposerCore.test.ts (13 tests) 4ms
   ✓ follow-up completion helpers
     ✓ uses the full suggestion when the editor is empty
     ✓ keeps a suggestion available while the user types a matching prefix
     ✓ ignores suggestions that no longer match the editor text

 Test Files  1 passed (1)
      Tests  13 passed (13)

TypeScript checks:

• packages/webui: tsc --noEmit — clean ✅
• packages/web-shell: tsc --noEmit -p tsconfig.lib.json — clean ✅

Real-scenario (tmux): Not applicable — this PR modifies web-shell (browser) follow-up suggestion UX. The send-button enable/disable state and session-switch suggestion cleanup run in a browser React app, not the terminal CLI. No tmux/CLI invocation can exercise these paths. The unit tests + typechecks above provide the verification for this change.

中文说明

代码审查

Diff 干净且目标明确。两处改动都服务于既定目标：

发送按钮 follow-up 支持（useComposerCore.ts）：getFollowupCompletion 本就是正确的 helper —— 将其 export 并接入 hasContent 和 submitText 是最小路径。textOverride === undefined 的守卫正确防止了覆盖显式提交。通过按钮提交 followup 后的 onAcceptFollowupRef.current?.('enter', { skipOnAccept: true }) 调用与第 1431 行已有的 Enter 键路径一致，telemetry 和清理逻辑保持一致。

Session 切换清理（useDaemonFollowupSuggestion.ts）：将 sidechannel suggestion 限定到 sessionId，并在 session 切换时清理本地/全局状态，是正确的修复。previousSessionId !== undefined && sessionId !== undefined 的守卫正确避免了初始挂载和断开连接时的误触发。保留 transcript store 自身的 suggestion（已经是 per-session 的）是正确的选择。

无正确性 bug，无安全问题，无 AGENTS.md 违规。EditorView.updateListener 和 useEffect 中的 followupCompletion 计算逻辑相同 —— 少量重复，但内联展开反而降低可读性。

测试

单元测试（packages/web-shell）：13 个测试全部通过，包括 3 个新增的 follow-up completion 测试。

TypeScript 检查：webui 和 web-shell 均通过，零错误。

真实场景（tmux）：不适用 —— 本 PR 修改的是 web-shell（浏览器）follow-up suggestion UX。发送按钮的启用/禁用状态和 session 切换 suggestion 清理运行在浏览器 React 应用中，非终端 CLI。没有 tmux/CLI 调用可以覆盖这些路径。上述单元测试 + 类型检查提供了本变更的验证覆盖。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

All three stages came back clean, so here's where I land:

This is a well-scoped fix that solves two real annoyances — the send button looking dead when a follow-up suggestion is right there, and stale suggestions bleeding across session switches. The implementation does exactly what it says: reuses the existing getFollowupCompletion helper, wires it into the right places, and adds a session-change effect that clears only the state that can leak. The tests cover the core matching logic. The diff has nothing extra.

The one thing I'd note: the followupCompletion computation is duplicated between the useEffect (line ~1089) and the EditorView.updateListener (line ~1778). It's three lines each and inlining would be worse, so it's fine — but if this logic ever grows, extracting it to a shared helper would be the move.

Approving. ✅

中文说明

三个阶段全部通过，结论如下：

这是一个范围明确的修复，解决了两个真实的体验问题 —— 发送按钮在 follow-up suggestion 可见时看起来不可用，以及旧 suggestion 在 session 切换时泄漏。实现方式与描述一致：复用已有的 getFollowupCompletion helper，接入正确的位置，添加 session 切换 effect 仅清理可能泄漏的状态。测试覆盖了核心匹配逻辑。Diff 没有多余内容。

一个小注：followupCompletion 的计算在 useEffect（约第 1089 行）和 EditorView.updateListener（约第 1778 行）之间重复了。每处三行代码，内联反而更差，所以目前没问题 —— 但如果这个逻辑将来扩展，提取为共享 helper 会是正确方向。

批准。✅

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[wenshao]

No review findings. Downgraded from Approve to Comment: CI still running.

— qwen3.7-max via Qwen Code /review

[wenshao]

No review findings. Downgraded from Approve to Comment: CI still running.

— qwen3.7-max via Qwen Code /review

[wenshao]

✅ Real-build verification (tmux + live daemon + Playwright on the actual web-shell SPA)

I verified this PR end-to-end on a real build, as a merge reference. Rather than asserting against a re-implementation, I built the actual web-shell artifacts from the PR head, served them with a real qwen serve daemon, and drove the real SPA in Chromium via Playwright. To make the follow-up suggestion deterministic, the daemon's agent was pointed at a fake OpenAI endpoint (isolated HOME, so the real ~/.qwen provider could not interfere), which returns a clean imperative ("run the smoke tests") for the server-side suggestion call and logs every model request as the assertion surface.

Verdict: both behaviors work, and an A/B against the pre-PR build proves the PR is responsible for the change. No regressions observed.

Setup

• Worktree built at PR head 6313fc02; npm run build (web-shell dist served by the daemon — confirmed Web Shell UI served from …/packages/web-shell/dist).
• tmux: pane 1 = fake OpenAI (/v1/chat/completions, stream + non-stream), pane 2 = qwen serve --workspace … --port 4170 (loopback, no token).
• Isolated HOME + OPENAI_BASE_URL/OPENAI_MODEL so every model call (turns and the generatePromptSuggestion side-query) hits the fake — verified {turn, suggestion} requests in the log.
• The suggestion only fires after MIN_ASSISTANT_TURNS=2, so the driver sends 2 turns first, then exercises the follow-up.

Part 1 — logic unit test + mutation

• packages/web-shell/.../useComposerCore.test.ts → 13/13 pass on PR head (incl. the 3 new getFollowupCompletion cases: empty / matching-prefix / non-match).
• Mutation (broke getFollowupCompletion to return null): the 2 relevant new tests fail with expected null to be 'show me tests', the non-match test stays green → the new tests are load-bearing, not vacuous.

Part 2 — real UI, identical Playwright script, A/B by build

Same script, same daemon, same fake model — the only variable is the 2 implementation files (PR head vs its parent 68348e236).

#	Assertion	Before (pre-PR)	After (PR)
baseline	Send disabled on empty editor, no follow-up	✅ disabled	✅ disabled
A1	Follow-up suggestion is displayed	✅ shown	✅ shown
A2	Send ENABLED with empty editor while follow-up visible	❌ disabled=true	✅ disabled=false
B	Click Send (empty editor) submits the FULL follow-up	❌ not sendable (null)	✅ "run the smoke tests"
C1	Send enabled while typing a matching prefix (run)	✅	✅
C3	Click Send with matching prefix submits the FULL suggestion	❌ submitted "run"	✅ "run the smoke tests"
D	Non-matching text submits the TYPED text, not the suggestion	✅ "zzz totally different"	✅ "zzz totally different"
E1	Switching sessions clears the stale follow-up	❌ leaked "run the smoke tests"	✅ cleared (null)
	Total	4/8	8/8

Ground-truth from the fake's request log (what the daemon actually submitted to the model):

• After: ["", "keep going", "run the smoke tests", "run the smoke tests", "zzz totally different"] — empty-editor send and prefix send both submitted the full suggestion; non-match submitted the typed text.
• Before: ["", "keep going", "run", "zzz totally different"] — no empty-editor send happened at all (button disabled), and the prefix send submitted just "run".

The 4 control rows (baseline / A1 / C1 / D) are green in both legs, so the harness isn't trivially passing or failing everything — only the PR-specific rows flip. This matches the diff precisely: hasContent now counts a visible follow-up; the submit path materializes the completion + reports accept; and useDaemonFollowupSuggestion gates the sidechannel by sessionId and clears local/global state on session change.

Scope / not covered

• The "preserve the new session's own transcript-store suggestion on switch" half of behavior 2 was reviewed by code (the switch effect clears only the controller + sidechannel, never the store, and activeFollowupSuggestion falls back to the store), but not exercised E2E — it needs a second session that already carries its own suggestion at switch time.
• Telemetry source attribution (the PR's own noted trade-off) was not tested.
• Single browser engine (Chromium), loopback, fake model.

Recommendation: looks good to merge — the headline UX fix and the session-scoping fix both reproduce on the real SPA, and the pre-PR A/B confirms they are this PR's doing.

中文说明

✅ 真实构建验证（tmux + 真实 daemon + Playwright 驱动真实 web-shell SPA）

作为合并参考，我对本 PR 做了端到端验证。没有用"复刻一份逻辑"来断言，而是用 PR head 构建出真实的 web-shell 产物，由真实的 qwen serve daemon 提供，并用 Playwright 在 Chromium 里驱动真实 SPA。为了让 follow-up suggestion 可确定性复现，把 daemon 的 agent 指向一个伪 OpenAI 端点（隔离了 HOME，避免真实 ~/.qwen provider 干扰）：它对服务端的 suggestion 调用返回一个干净的祈使句（"run the smoke tests"），并把每个模型请求记到日志里作为断言依据。

结论：两个行为都成立；与 PR 之前版本的 A/B 对比证明这些变化确实由本 PR 引入；未发现回归。

环境

• 在 PR head 6313fc02 建 worktree，npm run build（web-shell dist 由 daemon 提供——日志确认 Web Shell UI served from …/packages/web-shell/dist）。
• tmux：窗口 1 = 伪 OpenAI（/v1/chat/completions，流式+非流式），窗口 2 = qwen serve --workspace … --port 4170（loopback，无 token）。
• 隔离 HOME + OPENAI_BASE_URL/OPENAI_MODEL，使所有模型调用（对话轮次 和 generatePromptSuggestion side-query）都打到伪端点——日志里能看到 {turn, suggestion} 两类请求。
• suggestion 仅在 MIN_ASSISTANT_TURNS=2 后才触发，所以脚本先发 2 轮，再验证 follow-up。

第 1 部分 — 逻辑单测 + 变异测试

• useComposerCore.test.ts 在 PR head 13/13 通过（含 3 个新增 getFollowupCompletion 用例：空输入 / 前缀匹配 / 不匹配）。
• 变异（把 getFollowupCompletion 改成返回 null）：相关 2 个新测试失败（expected null to be 'show me tests'），不匹配那个仍绿 → 新测试是"有效承重"的，不是空测。

第 2 部分 — 真实 UI，同一份 Playwright 脚本，按构建做 A/B

脚本、daemon、伪模型完全相同，唯一变量是那 2 个实现文件（PR head vs 其父提交 68348e236）。

#	断言	Before（PR 前）	After（PR）
baseline	空输入且无 follow-up 时发送按钮禁用	✅ 禁用	✅ 禁用
A1	follow-up 建议有展示	✅	✅
A2	有 follow-up 且输入框为空时发送按钮可用	❌ disabled=true	✅ disabled=false
B	空输入点发送会提交完整 follow-up	❌ 无法发送（null）	✅ "run the smoke tests"
C1	输入匹配前缀（run）时发送可用	✅	✅
C3	输入匹配前缀点发送会提交完整建议	❌ 提交了 "run"	✅ "run the smoke tests"
D	输入不匹配文本时提交"输入的文本"而非建议	✅ "zzz totally different"	✅ "zzz totally different"
E1	切换 session 后清掉残留 follow-up	❌ 残留 "run the smoke tests"	✅ 已清除（null）
	合计	4/8	8/8

伪端点请求日志（daemon 实际提交给模型的内容）作为铁证：

• After：["", "keep going", "run the smoke tests", "run the smoke tests", "zzz totally different"] —— 空输入发送 和 前缀发送都提交了完整建议；不匹配则提交输入文本。
• Before：["", "keep going", "run", "zzz totally different"] —— 空输入根本没发出去（按钮禁用），前缀发送只提交了 "run"。

4 个对照项（baseline / A1 / C1 / D）在两条腿里都绿，说明测试装置不是"全过/全挂"——只有 PR 相关项发生翻转。这与 diff 完全吻合：hasContent 现在把可见的 follow-up 计入；提交路径会物化补全并上报 accept；useDaemonFollowupSuggestion 按 sessionId 给 sidechannel 加门、并在 session 切换时清掉本地/全局状态。

范围 / 未覆盖

• 行为 2 的另一半——"切换时保留新 session 自己的 transcript-store 建议"——通过读代码确认（切换 effect 只清 controller + sidechannel，从不清 store，且 activeFollowupSuggestion 会回退到 store），但没做 E2E（需要切换时新 session 已带有自己的建议）。
• Telemetry 来源区分（PR 自己提到的取舍）未测试。
• 单一浏览器内核（Chromium）、loopback、伪模型。

建议：可以合并 —— 头部 UX 修复与 session 隔离修复都在真实 SPA 上复现，PR 前/后 A/B 也确认是本 PR 的功劳。

[qwen-code-ci-bot]

No review findings. Downgraded from Approve to Comment: CI still running.

Two low-confidence observations for human review (not posted as inline comments): (1) the sidechannelFollowupSuggestion?.sessionId === sessionId check at line 267 selects the undefined sidechannel value when both operands are undefined, instead of falling back to lastFollowupSuggestion — mitigated by transcript store being empty in that state; (2) the session-cleanup effect guard at line 298 misses the disconnect-then-reconnect-to-different-session path — mitigated by multiple safety nets.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

[Suggestion] The session-switch effect calls controller.clear() and clearSidechannelFollowupSuggestion() but skips clearStoreFollowupSuggestion(store), relying on the provider's deferred async store.reset(). Between this effect running and the store reset completing, the sibling push effect sees the old lastFollowupSuggestion and re-pushes it (since lastPushedPromptIdRef was just reset to undefined), causing the old suggestion to briefly flash in the new session.

Consider adding clearStoreFollowupSuggestion(store) here, matching what the existing clear and onAcceptFollowup callbacks already do. If the new session already has its own suggestion in the store, the push effect will pick it up on the next store notification.

Suggested change

	controller.clear();
	controller.clear();
	clearSidechannelFollowupSuggestion();
	clearStoreFollowupSuggestion(store);
	lastPushedPromptIdRef.current = undefined;

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

[Suggestion] The three new tests cover getFollowupCompletion well (empty editor, matching prefix, non-matching). Two significant behavioral changes introduced by this PR have no test coverage:

1. Session-switch cleanup effect (useDaemonFollowupSuggestion.ts): no test verifies that controller.clear(), clearSidechannelFollowupSuggestion(), and the lastPushedPromptIdRef reset happen when the session changes.
2. Send-button followup integration (useComposerCore.ts submitText): no test covers the textOverride ?? followupCompletion ?? editorText precedence or the onAcceptFollowupRef.current?.('enter', { skipOnAccept: true }) call when a followup is submitted via the send button.

— qwen3.7-max via Qwen Code /review