Pushed 06b62cbc0 addressing the latest review.

1. Settings description (@wenshao) — "Enter to accept and submit" no longer matched the behavior (Enter only fills the buffer now) and was shown to everyone since the feature defaults on. Updated both settingsSchema.ts and settings.schema.json to: "Press Tab, Right Arrow, or Enter to accept into the input buffer."

2. hasTabConsumer / handler desync (@wenshao, also @doudouOUC's line 1600) — Real bug: handlers gated on buffer.text.length === 0 but hasTabConsumer gated on !suggestionDismissed, so after type-then-delete the two disagreed and Windows bare Tab both inserted the suggestion and cycled approval mode (regression of #4171). Took the preferred path: removed suggestionDismissed entirely and gated hasTabConsumer on buffer.text.length === 0, matching the handlers.

3. Fallback telemetry (@doudouOUC, line 1009) — Added a fallbackText option to the controller's accept(). The Tab/Right/Enter fallback branches now call accept(method, { fallbackText }) instead of a bare buffer.insert, so these accepts log onOutcome instead of appearing as "ignored".

4. Tests — Reworked the fallback tests to advance only 100ms (< the 300ms show delay) so followup.state.suggestion actually stays null and the prop-fallback branch is covered. Added core tests for accept() with/without fallbackText.

All typecheck/lint/tests pass.

Thanks for the second pass @wenshao — pushed e4d893fa3.

1. time_ms: 0 for fallback accepts (followupState.ts) — Went with option (a): added an accept_source: 'live' | 'fallback' field. The controller derives it from whether a live currentState.suggestion existed before applying fallbackText, and it's threaded through onOutcome → PromptSuggestionEvent → the clearcut attributes. Analytics can now separate fallback accepts (which legitimately report time_ms: 0, since the suggestion was never shown via the timer) from instant live accepts, without overloading the latency field.

2. Missing "live wins over fallbackText" test — Added. It sets a live suggestion, passes fallbackText, and asserts both onAccept and the telemetry (accept_source: 'live', suggestion_length) use the live suggestion — guarding the currentState.suggestion ?? options.fallbackText ordering.

3. hasTabConsumer buffer-gate transitions — Added an InputPrompt test asserting hasTabConsumer reports false when a promptSuggestion is set but the buffer is non-empty (the old Boolean(promptSuggestion) gate wrongly reported true here). The complementary empty-buffer → true direction is already pinned by the existing "reports true immediately when promptSuggestion prop is set" test, so both sides of the buffer.text.length === 0 contract are covered. (Went with deterministic fresh-mount assertions rather than a single mounted type-then-delete round trip, which raced against the followup show-timer.)

All typecheck/lint/tests pass.

Thanks @doudouOUC — all three addressed in e40f5a4b9.

1. Duplicate compound condition (InputPrompt.tsx) — Extracted a single availableSuggestion derived value:

const availableSuggestion: string | null =
  followup.state.isVisible || promptSuggestion
    ? (followup.state.suggestion ?? promptSuggestion ?? null)
    : null;

The Tab/Right/Enter accept guards, both typing-dismiss guards, and the placeholder prop now all derive from it (buffer.text.length === 0 && availableSuggestion, and availableSuggestion ?? placeholder). Behavior is unchanged — the controller keeps isVisible and suggestion in lockstep, so the two dismiss sites that previously checked only the first half are equivalent.

2. dismissPromptSuggestion rename — Renamed to abortPromptSuggestion across the UIState context, AppContainer, Composer, and the MainContent mock, and updated the comment to explain the name reflects that it only aborts generation/speculation and intentionally preserves promptSuggestion.

3. Stale time_to_first_keystroke_ms on fallback accepts — Good catch. Now omitted when accept_source === 'fallback', since shownAt stayed 0 and prevShownAtRef would otherwise contribute a previous suggestion's timestamp:

...(params.accept_source !== 'fallback' &&
  firstKeystrokeAtRef.current > 0 &&
  prevShownAtRef.current > 0 && { time_to_first_keystroke_ms: ... }),

typecheck/lint/tests all pass (245).

Maintainer verification — real local + tmux testing

Verified e40f5a4b9 on Linux (Node v22.22.2) in an isolated worktree + clean test HOME, against a live DashScope qwen-flash for both the main model and fastModel (so suggestion generation runs end-to-end). Methodology: code review of the final state → unit tests → a dist harness against the compiled controller → an interactive tmux session driving the real TUI (placeholder styling captured via tmux capture-pane -e ANSI).

Verdict

The feature itself is solid and every item from my earlier review rounds is correctly resolved. I can reproduce the full UX live. One item needs a decision before merge: the default: false → true change is a runtime no-op — it does not actually turn the feature on, and it introduces a settings-dialog-vs-runtime inconsistency. Details in Finding 1.

1. Live behavior (interactive tmux, enableFollowupSuggestions: true, ≥2 turns)

All driven against the real model; suggestion text was model-generated ("run the tests", then "commit this").

ANSI proof of placeholder (empty buffer) vs filled buffer:

placeholder:  > <ESC>[7m<ESC>[39mr<ESC>[0m<ESC>[38;5;103mun the tests   (cursor pos 0, dim 103)
after Tab:    > <ESC>[39mrun the tests<ESC>[7m _                        (cursor at end, normal 39)

Tests 3–6 specifically exercise the prop-fallback path the PR adds (live followup.state.suggestion is null after type-then-delete; acceptance comes from the promptSuggestion prop via fallbackText).

2. Tests & harness

• followupState.test.ts 18/18; packages/core/src/followup/ 109/109.
• InputPrompt.test.tsx + MainContent.test.tsx 176 passed / 1 skipped.
• tsc --noEmit clean for core and cli.
• Dist harness against the compiled createFollowupController — 11/11: accept_source live vs fallback; live suggestion wins over fallbackText; time_ms: 0 for fallback; the no-op and accept-guard paths.

3. My earlier review items — all resolved ✅

Findings

🔴 Finding 1 — default: false → true does not enable the feature at runtime (decide intent before merge)

The schema default is read only by the Settings dialog; the runtime gate never falls back to it, and settings.merged is not seeded from the schema:

• Runtime gates (unchanged by this PR):
  • AppContainer.tsx:2108 → settings.merged.ui?.enableFollowupSuggestions === true
  • Session.ts:909 (ACP) → if (... !== true) return;
• mergeSettings() merges only the system-defaults file + user + workspace + system files — it does not apply SETTINGS_SCHEMA defaults.
• getDefaultValue() (→ schema default) is consumed only by settingsUtils/SettingsDialog for display & reset.

Empirical A/B (live, 2 model turns each, only the key differs):

• No key set (relying on the new default true) → no suggestion, zero [FOLLOWUP] generations.
• ui.enableFollowupSuggestions: true explicit → suggestion generates immediately.

Probe against the compiled code:

Settings DIALOG displays (getDefaultValue):                 true
RUNTIME gate (merged.ui?.enableFollowupSuggestions===true): false
>>> dialog shows ENABLED but runtime treats it as DISABLED for an unset key

Consequences for a user who never set the key (i.e. most users after upgrade, and fresh installs):

1. The feature stays off — the PR's stated goal "on by default" is not delivered.
2. The Settings dialog will show the toggle as enabled (true) while the behavior is disabled — a new, user-visible inconsistency this PR introduces (before the PR both were false, so consistent).
3. Docs are now stale/contradictory: docs/users/features/followup-suggestions.md:35,75 and docs/users/configuration/settings.md:120 still say disabled by default / false (and still call it "ghost text" / pre-PR Enter behavior).

Resolution (maintainer's call — both are fine, pick one):

• To truly ship on-by-default: change the two runtime gates to treat unset as enabled (!== false), and update the three doc locations. Note this turns on a fastModel LLM call every turn by default — worth a deliberate cost/latency/privacy decision.
• Otherwise: revert the schema default to false and drop the "on by default" wording so dialog, runtime, and docs stay consistent.

🟡 Finding 2 — stale JSDoc after the dismiss → abort rename (nit)

packages/cli/src/ui/contexts/UIStateContext.tsx:189 still reads:

/** Dismiss prompt suggestion (clears state, aborts speculation) */
abortPromptSuggestion: () => void;

This now contradicts the carefully-written AppContainer.tsx comment — the function neither "dismisses" nor "clears state" (that's the whole reason for the rename). Suggest: "Abort in-flight suggestion generation/speculation; intentionally preserves promptSuggestion so the placeholder can restore it."

Bottom line: implementation + all prior-round fixes are verified and LGTM. Please resolve Finding 1 (it's a one-way-or-the-other decision, not a deep change) before merge; Finding 2 is a one-line doc fix.

占位符:    > <ESC>[7m<ESC>[39mr<ESC>[0m<ESC>[38;5;103mun the tests   (光标位 0, 暗色 103)
Tab 之后:  > <ESC>[39mrun the tests<ESC>[7m _                        (光标在末尾, 正常 39)

设置面板显示 (getDefaultValue):                              true
运行时门控 (merged.ui?.enableFollowupSuggestions===true):    false
>>> 未设 key 时：面板显示「已启用」，运行时按「已禁用」处理

/** Dismiss prompt suggestion (clears state, aborts speculation) */
abortPromptSuggestion: () => void;

_{Verified by maintainer wenshao via local build + dist harness + live tmux against DashScope qwen-flash. HEAD e40f5a4b9.}

Thanks for the verification @wenshao — confirmed: mergeSettings doesn't apply the schema default, so the === true gates leave it off while the panel reads it as on.

Decision: default-on (Option A). On the cost concern — for users without a configured fastModel (the default case) generation already falls back to the main model, and with enableCacheSharing on by default the forked query reuses the conversation's prefix cache. So a default-on turn is discounted cached input + a short suggestion, not a full fresh call. fastModel is opt-in and actually bypasses the shared cache (different model), so it can cost more on long conversations — I'll note that in the docs.

Changes I'll push:

1. Flip the two runtime gates to !== false (AppContainer.tsx:2108, Session.ts:909).
2. Update docs to match — default-on, drop the stale "ghost text" / Enter-submits wording, add the fastModel-vs-cache cost note (followup-suggestions.md:35,75, settings.md:120).
3. Problem 2: fix the stale UIStateContext.tsx:189 JSDoc.

Shout if you'd rather keep it opt-in (Option B) — otherwise I'll push the above.

@qwen-code /triage

Pushed 45aa1c337 — default-on for real now.

• Both runtime gates treat an unset value as enabled (AppContainer.tsx, ACP Session.ts); only an explicit false opts out. Added a Session test for the unset/default-on path.
• Fixed the stale UIStateContext JSDoc (Problem 2).
• Docs updated: on-by-default, Enter fills the input (no auto-submit), ghost text → placeholder text, plus the fastModel-vs-shared-cache cost note.

Thanks for the review pass and the local verification @wenshao 🙏

Merged main into the branch (fbd34b815) — conflicts resolved, now MERGEABLE.

Only two files conflicted; all source/config auto-merged cleanly:

• Session.test.ts — main refactored runToolCalls to return an object (const result / result.parts). Took main's side for both hunks. The new "default-on when unset" test is preserved in the kept follow-up-suggestion describe block.
• docs/users/configuration/settings.md — main realigned the whole settings table. Took main's reformatted table and re-applied the ui.enableFollowupSuggestions row (default true, placeholder wording).

Verified on the merged tree: typecheck clean across all packages; Session / followupState / InputPrompt suites pass (335). All earlier review fixes are intact (the two runtime gates, schema default, availableSuggestion, accept_source / fallbackText, the abortPromptSuggestion rename).

Ready for a re-review when you have a moment @wenshao — the prior approval was auto-dismissed by these pushes.

@qwen-code /triage

✅ Maintainer verification — mutation (resolves the review blocker) + build/tests + real-TUI diagnosis

Verified on a clean build of the PR head in an isolated worktree. The code is sound and the blocking review concern is resolved. One real-TUI finding below is out of this PR's scope (pre-existing, gracefully handled).

What it does

Shows the follow-up suggestion in the input placeholder (instead of only chips). availableSuggestion is a single source of truth — the live followup.state suggestion if visible, otherwise the persisted promptSuggestion prop (the type-then-delete / pre-show-delay fallback). Tab / Right-arrow fill it into the input; Enter now fills the buffer instead of submitting (safety: avoids auto-running a suggested /clear·/quit); typing dismisses; deleting back to empty restores it. enableFollowupSuggestions default → true.

The review blocker is resolved (mutation-proven)

@DragonnZhang's CHANGES_REQUESTED (06-16) was: the three "promptSuggestion prop fallback" tests don't actually exercise the fallback — they advanced timers 700ms, which let the 300 ms debounce set followup.state.suggestion, so Tab/Right/Enter hit the live-state path, not the promptSuggestion fallback.

The author reworked it (commits from 06-16 06:33): the tests now advance only 100 ms (well under the 300 ms debounce) so followup.state.suggestion stays null, forcing the promptSuggestion fallback. I confirmed these tests are now non-vacuous with a mutation:

Mutation: drop the promptSuggestion fallback from `availableSuggestion`
  (followup.state.isVisible ? followup.state.suggestion : null)
→ all 3 fallback tests FAIL:
  × accepts promptSuggestion via Tab when followup.state.suggestion is null
  × accepts promptSuggestion via Right arrow when followup.state.suggestion is null
  × fills buffer on Enter (does not submit) when followup.state.suggestion is null

So at 100 ms (state null) the accept only works through the promptSuggestion fallback — the tests genuinely guard it now. This directly closes @DragonnZhang's concern.

Evidence

Real-TUI (tmux) — feature is wired & fires, but generation 400s on this endpoint

Running the built binary with enableFollowupSuggestions: true, the suggestion generator correctly fires on every Responding → Idle transition after the MIN_ASSISTANT_TURNS = 2 threshold (confirmed in the FOLLOWUP debug log). However, the placeholder never populated because the prompt-suggestion side-query consistently returns HTTP 400 on this qwen3.7-max endpoint:

[FOLLOWUP] Generating suggestion: cacheSharing=false, model=(default)
[FOLLOWUP] Suggestion generation failed: 400 status code (no body)
  at generateViaBaseLlm (packages/core/.../suggestionGenerator.js:166)

This originates in suggestionGenerator.ts, which this PR does not touch (the diff changes followupState.ts, not the generator) — so it's a pre-existing, endpoint-specific generation issue, out of 5145's scope, and it's handled gracefully (caught → default placeholder, no crash, 0 stderr). Consequently the placeholder/accept UX itself is verified via the deterministic unit tests + mutation above rather than a live capture.

⚠️ Worth a separate look (not a 5145 blocker): because this PR flips the default to true, the feature is now on for everyone — but on any endpoint where the prompt-suggestion side-query 400s (as it does here), it silently produces nothing. Investigating the 400 (model=(default) resolution / request shape) would make the now-default-on feature actually visible.

Verdict

The PR's code is correct, CI is green, and the review-blocking concern (vacuous fallback tests) is resolved and mutation-proven. It's already approved by me and the CI bot; the only thing keeping it BLOCKED is @DragonnZhang's now-stale CHANGES_REQUESTED — a re-review / dismissal unblocks it. Recommend merge (and a separate ticket for the pre-existing prompt-suggestion 400).

变异：从 `availableSuggestion` 去掉 promptSuggestion fallback
  (followup.state.isVisible ? followup.state.suggestion : null)
→ 3 个 fallback 测试全部失败：
  × accepts promptSuggestion via Tab when followup.state.suggestion is null
  × accepts promptSuggestion via Right arrow when followup.state.suggestion is null
  × fills buffer on Enter (does not submit) when followup.state.suggestion is null

[FOLLOWUP] Generating suggestion: cacheSharing=false, model=(default)
[FOLLOWUP] Suggestion generation failed: 400 status code (no body)
  at generateViaBaseLlm (packages/core/.../suggestionGenerator.js:166)

_{Verification method: worktree build + declared unit tests + source-mutation on availableSuggestion (3 fallback tests flip) + real-TUI run with FOLLOWUP debug logging (generation fires; side-query 400s in suggestionGenerator.ts, which is outside this PR's diff).}

🔁 Maintainer re-verification of the current head (bb6eb3726)

Updates my earlier verification — since then the branch advanced (a new fix(core) commit + an upstream merge) and @doudouOUC posted a fresh review after the new head. I rebuilt bb6eb3726 in an isolated worktree (Node v22.22.2, macOS) and re-tested with real compiled dist + a real-TUI tmux run.

Net: the new control-char hardening is correct and complete, but @doudouOUC's two Critical findings are real and reproducible — the PR is one small fix away from merge-ready, not merge-ready as-is.

A. New fix(core): reject control chars and ANSI escapes (bb6eb3726) — ✅ sound & complete

Now that enableFollowupSuggestions defaults on, the suggestion (influenceable via tool/file/web output in history) is rendered verbatim in the input placeholder. The commit adds a gate at the top of the shared getFilterReason (suggestionGenerator.ts:284) that rejects any C0/C1 control byte or DEL — char class 0x00-0x1F, 0x7F, 0x80-0x9F → returns control_chars.

Real built-function A/B — imports the actual compiled dist (no model, no network), realistic multi-word "next-step" suggestions with control bytes embedded (long enough to survive the word-count filter, so the only thing that can reject them is the new gate):

• The display ≠ insert mismatch is the concrete harm: the accept path (text-buffer.ts insert → stripUnsafeCharacters) strips/transforms these bytes, so the placeholder would render raw control bytes while accept inserts something different.
• Mutation: revert the 9-line gate + rebuild core → the new unit test filters control characters and ANSI escapes FAILs (expected false to be true) → non-vacuous.
• Completeness (reverse-audit): the gate sits at the single getFilterReason chokepoint, and every value that can reach the placeholder flows through it — live generation (generatePromptSuggestion → getFilterReason, suggestionGenerator.ts:130), the speculation pipeline (generatePipelinedSuggestion → getFilterReason, speculation.ts:577), and the live followup is itself fed from the already-filtered promptSuggestion (InputPrompt.tsx:1641). No bypass.

B. @doudouOUC's 2026-06-19 review — both Critical findings are REAL ❌ (the remaining blocker)

Not in the control-char commit — a pre-existing state-leak that the new default-on visibility makes user-facing. Confirmed against the current head.

Critical #2 — accept handlers leak promptSuggestion → ghost placeholder. The three accept handlers (followup.accept('tab'…) @1009, 'right' @1021, 'enter' @1277) reset the followup controller but never call onPromptSuggestionDismiss?.(), so the persisted promptSuggestion prop survives. When the buffer next empties, availableSuggestion (@543) re-derives from it and the just-accepted suggestion reappears. Deterministic repro (added to InputPrompt.test.tsx, run, then reverted):

✓ Tab accept         → buffer.insert('/clear') called,  onPromptSuggestionDismiss NOT called   (leaks)
✓ Right-arrow accept → buffer.insert('/clear') called,  onPromptSuggestionDismiss NOT called   (leaks)
✓ CONTROL: type 'x'  →                                  onPromptSuggestionDismiss IS  called    (clears)

The asymmetry is the bug — typing (@1380) and paste (@665) clear it; accept and submit don't. Real-world: model suggests /clear → Tab → Ctrl+U → /clear ghosts back into the placeholder.

Critical #1 — sync slash command leaves a stale placeholder. handleSubmitAndClear (@399) calls followup.dismiss() but not onPromptSuggestionDismiss?.(). AppContainer only nulls promptSuggestion on the Idle→Responding transition (AppContainer.tsx:2178) — a synchronous slash command (/clear, /help) starts no model turn, so the suggestion persists as a stale placeholder. (Code-trace confirmed; same root cause as #2.)

Fix = exactly doudouOUC's one-liners: add onPromptSuggestionDismiss?.() after the three followup.accept(...) calls and in handleSubmitAndClear. Their two Suggestion items (reuse availableSuggestion in hasTabConsumer @1627; add a test for the accept_source!=='fallback' telemetry guard) are valid minor polish.

C. Prior blocker (@DragonnZhang — vacuous fallback tests) — ✅ resolved, survives the merge

availableSuggestion is still the single source of truth (@543-546) after the upstream merge. Re-ran the mutation (drop the promptSuggestion fallback) on the current head → the 3 fallback tests FAIL → they genuinely guard it.

D. No-regression — ✅

• Build exit 0; 45/45 core followup tests (suggestionGenerator 19 incl. the new test, followupState 18, speculation 8) + 27 InputPrompt suggestion tests (incl. the 3 fallback) green.
• Real-TUI (tmux): the built binary boots clean (Qwen Code v0.18.3, IdeaLab DeepSeek/deepseek-v4-pro, YOLO); a 2-turn chat crosses MIN_ASSISTANT_TURNS; the followup generator fires on Responding→Idle; 0 stderr crash (only an unrelated punycode deprecation); placeholder not corrupted.
• Pre-existing & out of scope: the prompt-suggestion side-query still returns HTTP 400 on this endpoint (model=(default) → the main DeepSeek endpoint), so the placeholder never populates live here. The new gate runs only after generation succeeds, so it can't be exercised live on this account — which is exactly why the decisive proof is the built-function A/B in §A. The 400 lives in generateViaBaseLlm, untouched by this PR.

Verdict

The control-char security hardening is correct, complete, and well-placed, and @DragonnZhang's blocker stays resolved. But @doudouOUC's two Critical findings reproduce on the current head — a real (cosmetic: stale/ghost placeholder, no crash/data-loss) state-leak. Recommendation: apply doudouOUC's onPromptSuggestionDismiss?.() additions (3 accept handlers + handleSubmitAndClear) + a regression test for accept-then-clear, then it's merge-ready. (This supersedes my earlier "recommend merge", which was against fbd34b815, before this review and the control-char commit.)

✓ Tab 接受       → buffer.insert('/clear') 被调用,  onPromptSuggestionDismiss 未调用   (泄漏)
✓ 右方向键接受   → buffer.insert('/clear') 被调用,  onPromptSuggestionDismiss 未调用   (泄漏)
✓ 对照: 输入 'x' →                                 onPromptSuggestionDismiss 被调用    (清除)

_{Method: isolated worktree build of bb6eb3726 · real compiled-dist A/B on getFilterReason (mutation = revert + rebuild core) · reverse-audit of every placeholder-feed path · deterministic repro test for the accept-leak (added → run → reverted) · 45 core + 27 InputPrompt tests · real-TUI tmux smoke on the DeepSeek endpoint.}

Thanks for the deep re-verification 🙏 — especially the built-function A/B and the reverse-audit of the placeholder-feed paths.

One timing note: your re-verification was run against head bb6eb3726 (the control-char commit), which is the parent of the doudouOUC fix. The two Critical findings you reproduced are already addressed on the current head — they were pushed after bb6eb3726:

• 04fcffd1c — applies exactly your recommended one-liners:
  • onPromptSuggestionDismiss?.() after all three followup.accept(...) calls (Tab / Right / Enter) → fixes Critical Where is the config saved? #2 (ghost placeholder on accept-then-clear).
  • onPromptSuggestionDismiss?.() in handleSubmitAndClear after followup.dismiss() → fixes Critical pre-release: fix ci #1 (stale placeholder after a synchronous /clear /help).
  • hasTabConsumer now reuses the availableSuggestion single-source-of-truth instead of an inlined parallel expression (doudouOUC Suggestion).
  • new useFollowupSuggestions test asserting the accept_source !== 'fallback' guard suppresses time_to_first_keystroke_ms (doudouOUC Suggestion).
• 7eebe8567 — the accept-then-clear regression test you recommended: asserts onPromptSuggestionDismiss is called on Tab / Right / Enter accept and on message submit (in InputPrompt.test.tsx).
• c791b203f — merged latest upstream/main and resolved the stopAfterUserQuestionCancel → stopAfterPermissionCancel rename from fix(cli): Stop after cancelled permissions #5258, which was the only thing breaking the PR-merge CI build (a stale-incremental-cache false-green locally; caught on a clean build).

So all of doudouOUC's items (2 Critical + 2 Suggestion) plus your recommended regression test are on the current head. Local: clean build exit 0, full typecheck 0 errors, InputPrompt 171 + core followup 45 green. Would appreciate a re-verify against 7eebe8567 when you get a chance.

✅ Local runtime verification (real tmux, real Ink render) — PR #5145

Verdict: the feature works and is well-tested; no regressions. Safe to merge after two small heads-ups below (a stale line in the PR description and the new default-on behavior).

I rendered the real InputPrompt component (ink-testing-library → real React/Ink, real keypress events via stdin.write, real output frames) inside an isolated tmux session, and ran the changed test files + an A/B against origin/main (0 commits behind — clean apply).

What the PR does

Surfaces the follow-up suggestion in the input placeholder. A single availableSuggestion (live followup.state or the persisted promptSuggestion prop) now drives the placeholder, Tab/Right/Enter acceptance, the typing-dismiss guards, and hasTabConsumer — so they can't drift apart. enableFollowupSuggestions default flips false → true.

Evidence — PR head

Tests (real renders)

core  followupState.test.ts + suggestionGenerator.test.ts → 37 passed
cli   Session + InputPrompt + MainContent + useFollowupSuggestions → 351 passed (4 files)
typecheck core → 0 errors
typecheck cli  → 1 error, unrelated (see Environment note)

Real Ink render — the actual rendered input line:

render <InputPrompt promptSuggestion="commit this" />  (buffer empty)
  RT5145_INPUT_LINE = "> commit this"          ← suggestion shown in the placeholder
  RT5145_PLACEHOLDER_HAS_SUGGESTION = true
press Tab:
  mockBuffer.insert called with ["commit this"]  ← Tab fills the suggestion into the input

A/B vs origin/main (swap InputPrompt.tsx, same test harness)

                                PR head                  origin/main (base)
rendered input line (empty)     "> commit this"          ">   Type your message or @path/to/file"
Tab on empty buffer             inserts "commit this"    no-op  (insert calls = [])

The new tests have teeth — against base InputPrompt.tsx:

-t "promptSuggestion"  → 8 failed | 1 passed   (FALLBACK_TEETH_EXIT=1)
-t "does not submit"   → 2 failed              (ENTER_TEETH_EXIT=1)
   e.g. "expected spy to be called with ['commit this']"

Heads-ups for the maintainer (non-blocking)

1. PR description vs. actual Enter behavior. The description says "Enter accepts and submits the suggestion", but the implemented behavior (and the test that pins it) is Enter fills the buffer and does NOT submit — test name: fills buffer on Enter when suggestion is available (does not submit), with a code comment that this is deliberate to avoid accidentally executing destructive slash commands (/clear, /quit). The code is the safer choice; please update the PR description line so reviewers aren't surprised.
2. New default-on. enableFollowupSuggestions default is flipped false → true (confirmed in settingsSchema.ts), so the placeholder-suggestion UX is on by default after merge — worth a release-note mention.

Environment note (not caused by this PR)

On a fresh checkout in this sandbox, InputPrompt.test.tsx initially failed to collect (Missing "./dom" specifier in "ink" package) and BaseTextInput.tsx had 5 typecheck errors (ink/dom, ink/components/CursorContext). Root cause: the repo's own patches/ink+7.0.3.patch (which adds those ink subpaths) was not applied. BaseTextInput.tsx is not in this PR. Running npx patch-package (what npm install's postinstall does) fixed it; afterwards cli tests are 351/351 and cli typecheck drops to 1 pre-existing unrelated error (Cannot find module '@qwen-code/channel-qqbot', an optional channel workspace package not installed here). Both are environment/install artifacts, not the PR.

Verified on Linux. Suggestion generation (fast-model selection) is covered by the core suggestionGenerator.test.ts (19 tests); this report focused the live render on the placeholder/keyboard UX.

core  followupState.test.ts + suggestionGenerator.test.ts → 37 passed
cli   Session + InputPrompt + MainContent + useFollowupSuggestions → 351 passed（4 个文件）
typecheck core → 0 errors
typecheck cli  → 1 error，与本 PR 无关（见“环境说明”）

render <InputPrompt promptSuggestion="commit this" />  （buffer 为空）
  RT5145_INPUT_LINE = "> commit this"          ← 建议显示在 placeholder 里
  RT5145_PLACEHOLDER_HAS_SUGGESTION = true
按 Tab：
  mockBuffer.insert 被以 ["commit this"] 调用    ← Tab 把建议填入输入框

                                PR head                  origin/main (base)
渲染出的输入行（空 buffer）      "> commit this"          ">   Type your message or @path/to/file"
空 buffer 下按 Tab              填入 "commit this"        无动作（insert 调用 = []）

-t "promptSuggestion"  → 8 failed | 1 passed   (FALLBACK_TEETH_EXIT=1)
-t "does not submit"   → 2 failed              (ENTER_TEETH_EXIT=1)
   例如 "expected spy to be called with ['commit this']"

Thanks for the second pass on the current head 🙏 — and for independently hitting (and documenting) the same patches/ink+7.0.3.patch / patch-package install artifact; that matches what I saw locally.

Both heads-ups handled:

1. PR description — updated. The Enter line now reads "accepts the suggestion into the input (does not submit)" and the test-plan checklist item was fixed to match, so the description no longer contradicts the implemented (safer) behavior.
2. Default-on — enableFollowupSuggestions: false → true is called out in the PR description's Code Changes section; flagging it here too so it can land in the release notes.

No code changes for either (both were doc/behavior-description only), so the verified head 7eebe8567 stands.

@qwen-code /triage