3 commits

Author	SHA1	Message	Date
Shaojin Wen	afbb5e71db	fix(cli): rework session recap rendering and add blur threshold setting (#3482) ... * feat(cli): make recap away-threshold configurable The 5-minute blur threshold was hard-coded. Confirmed from Claude Code's own binary (v2.1.113) that 5 minutes is their default as well (and that they shift to 60 minutes when 1h prompt-cache is active) — so the default stays, but expose it as `general.sessionRecapAway ThresholdMinutes` for users who briefly alt-tab often and don't want recaps piling up, or who want to lower it for testing. Non-positive / unset values fall back to the 5-minute default, so dropping the key has the same behavior as before. * fix(core): align recap prompt with Claude Code (1-2 sentences, ≤40 words) The earlier "exactly one sentence, 80-char cap" was an over-correction to a single in-the-moment ask. Going back to it: the natural shape of "current task + next action" is two clauses, and forcing them into a single sentence either crams them with a semicolon or drops the next action entirely on complex sessions. Adopt Claude Code's prompt verbatim (extracted from the v2.1.113 binary): "under 40 words, 1-2 plain sentences, no markdown. Lead with the overall goal and current task, then the one next action. Skip root-cause narrative, fix internals, secondary to-dos, and em-dash tangents." Add a Chinese-budget note (~80 chars) and keep the <recap>...</recap> wrapping that protects against reasoning-model preambles leaking into the UI. The sticky banner already re-measures controls height when the recap toggles, so a 2-line render lays out cleanly. Sweep "one-line" out of user-facing copy (settings description, slash-command description, feature docs, design doc) so the documentation matches the new shape. * fix(cli): restore "one-line" in user-facing recap copy Verified from the Claude Code v2.1.113 binary that the slash-command description IS literally "Generate a one-line session recap now" even though the underlying prompt allows 1-2 sentences. Claude Code is deliberately setting a tighter user expectation than the prompt guarantees, which keeps the surface feel "glanceable". Mirror that asymmetry: keep the prompt at 1-2 sentences (the previous commit) for behavioral parity, but put "one-line" back in the user- visible copy (slash-command description, settings description, user docs). Internal design doc keeps the accurate "1-2 sentence" wording. * fix(cli): render recap inline in history to match Claude Code Earlier I read the user's complaint that the recap "scrolled away" as "the recap should be sticky above the input box," and built a sticky banner accordingly. Disassembly of the Claude Code v2.1.113 binary shows the actual behavior is the opposite: their away_summary is a plain `type:"system", subtype:"away_summary"` message dispatched through the standard message renderer (no Static, no anchor, no flexbox pinning) — it scrolls with the conversation like every other system message. Tear out the sticky-banner machinery so recap matches that: - Recap is back in the `HistoryItemWithoutId` union and `addItem`'d into history (both from `/recap` and from auto-trigger), so it serializes into session saves and behaves like every other history item — no special clear paths, no resume-wrapper, no layout-effect re-measure dance. - `useAwaySummary` takes `addItem` again instead of a setter callback. - `AwayRecapMessage` renders the way Claude Code does: a 2-column gutter with `※`, then bold "recap: " and italic content, all in dim color. Drop the prior `StatusMessage`-shaped layout that fused prefix and label into "※ recap:". - Remove the AppContainer plumbing, the slashCommandProcessor state, the UIStateContext fields, the DefaultAppLayout / ScreenReader placement blocks, the test-utils mocks, and the noninteractive stub. Restore `useResumeCommand.handleResume` to a void return since callers no longer need the success boolean. Sweep the design doc so the architecture diagram, files table, and hook deps reflect the inline-history flow. * fix(cli): dedupe back-to-back auto-recaps with no new user turns between Two consecutive blur cycles, each over the threshold but with no new user activity in between, would each fire their own auto-recap and add two near-duplicate entries to history (same task, slightly different wording from temperature-driven LLM variance). Reported case: leaving the terminal twice while a /review of one PR was still on screen produced two recaps both about that same review. Add a `shouldFireRecap` gate before kicking off the LLM call: - Need at least 3 user messages in history total (don't fire on a near-empty session). - If a previous away_recap is already in history, need at least 2 new user messages since that one before another can fire. Same shape as Claude Code's `Ic1` gate (`Sc1=3`, `Rc1=2`). Read history through a ref so this isn't in the effect's deps and the effect doesn't re-run on every message. * fix(cli): type useResumeCommand.handleResume as Promise<void> Per gemini review on #3482: the interface declared this as `() => void` but the implementation is `async` and returns `Promise<void>`. The mismatch silently lost the chainable promise — tests had to launder it through `as unknown as Promise<void> | undefined` just to await. Tighten the interface to `Promise<void>` and drop the cast in the "closes the dialog immediately" test. * fix(cli): persist auto-fired recap to chat recording so /resume keeps it Per yiliang114 review on #3482: the manual `/recap` path persists across `/resume` because the slash-command processor records every output history item via `chatRecorder.recordSlashCommand({ phase: 'result', outputHistoryItems })`, but the auto path called `addItem` directly and bypassed that recorder. The result was an asymmetry where users who triggered recap manually saw it after `/resume`, while users whose recap fired automatically lost it. Mirror the manual recording from useAwaySummary's `.then` callback — record only the `result` phase (not invocation, since we don't want a fake `> /recap` user line replayed) with the away-recap item as the single output. Wrapped in try/catch because recap is best-effort and must never surface a failure to the user. Add useAwaySummary.test.ts covering: - the recording path is taken on a successful auto-trigger - the dedup gate (`shouldFireRecap`) suppresses the LLM call entirely, including the recording, when no new user turns happened since the last recap * fix(cli): cast recap item via spread to satisfy strict tsc --build CI's `tsc --build` (stricter than local `tsc --noEmit`) rejected the direct `item as Record<string, unknown>` cast: HistoryItemAwayRecap's literal `type: 'away_recap'` field doesn't overlap with `unknown`, TS2352. Use the `{ ...item } as Record<string, unknown>` spread pattern that the rest of the codebase (arenaCommand, slashCommandProcessor's serializer) already uses for the same SlashCommandRecordPayload field.	2026-04-21 14:39:13 +08:00
Shaojin Wen	52c7a3d0ed	fix(cli): pin /recap above input and align defaults with fastModel (#3478) ... * fix(cli): pin /recap above input box and align defaults with fastModel The recap rendered as a regular history item, so as soon as the model streamed a new reply the "where you left off" reminder scrolled out of view. Move it to a sticky banner anchored just above the Composer (matching how btwItem is rendered) so it stays visible across turns. While reworking the surface, also: - Replace the chevron prefix with `※ recap:` so it reads as a labeled recap line instead of a generic dim message. - Mirror the placement in ScreenReaderAppLayout so screen-reader users see it in the same logical position. - Drop HistoryItemAwayRecap from the HistoryItemWithoutId union — it is no longer addItem-able, and leaving it in invited silent no-op bugs where addItem(awayRecap) would compile but render nothing. - Clear the banner on /clear, /reset, /new and on /resume into a different session, so a recap from a previous context doesn't bleed into a freshly started one. - Re-measure the controls box when the banner appears or disappears (its height changes by a couple of lines) so the main content area recomputes availableTerminalHeight and stays laid out correctly. Auto-trigger now defaults to "on iff fastModel is configured" rather than unconditionally on. Running an ambient background recap on the main coding model is too costly and slow to be a sane default; tying it to fastModel means the feature is silently opt-in for users who have set up a cheap fast model. An explicit `general.showSessionRecap` override still wins either way, and `/recap` itself is unaffected. Sharpen the slash-command description to match the new behavior. * fix(core): silence AbortSignal listener-leak warning in OpenAI pipeline Every chat.completions.create call wires up an abort listener on the incoming AbortSignal, and several layers — retryWithBackoff, the LoggingContentGenerator wrapper, the SDK's own internal stream/fetch plumbing — register their own listeners against the same signal. Five retry attempts plus those layers comfortably exceed Node's default 10-listener cap and produce a MaxListenersExceededWarning. With features that share or compose signals (e.g., recap + followup speculation firing on the same response cycle), even a higher cap gets blown past. The signals here are per-request and short-lived, so the accumulation is structural rather than a real memory leak — they get GC'd as soon as the request settles. setMaxListeners(0, signal) at the SDK boundary disables the warning for these specific signals only, without masking any genuine leak elsewhere in the process. Idempotent and confined to the one place where retry-bound API calls cross into the SDK. * fix(core): tighten recap to a single sentence within 80 chars The 1-3 sentence budget reliably wrapped onto two lines in the sticky banner above the input box, which made it visually heavy for what is supposed to be a glanceable reminder. Constrain the prompt to exactly one sentence with a hard 80-char cap, and merge the "high-level task + next step" rule into a single sentence instead of two adjacent ones. Also sweep the docs (settings, commands, design) so the user-facing copy and the internal design notes match the new format. * fix(cli): apply review feedback for recap PR Two issues from review: - The schema description for `general.showSessionRecap` still said "1-3 sentence summary" while the prompt, docs, and slash-command copy already say "one-line". Aligns the text in settingsSchema.ts and the regenerated VSCode JSON schema. - The /resume wrapper cleared the sticky recap synchronously, before the inner handler had a chance to discover that no session data was available. On a no-op resume the user would still lose the current recap. Make `useResumeCommand.handleResume` return Promise<boolean> reporting whether a session actually loaded, and only clear the recap on a confirmed switch. * fix(cli): default showSessionRecap to false and drop fastModel heuristic The earlier "enabled iff fastModel is configured" default made it hard for users to answer the simple question "is auto-recap on for me right now?" — the answer depended on a setting from a different category, and setting/unsetting fastModel silently changed recap behavior. Revert to a plain boolean with a conservative off-by-default: - Auto-trigger fires only when the user explicitly sets `general.showSessionRecap: true`. - Manual `/recap` keeps working regardless (that's a user-initiated call, not an ambient one). - Users never get ambient LLM calls billed to their main coding model without having opted in. Aligns settings.md, design doc, and the regenerated JSON schema.	2026-04-20 23:58:19 +08:00
Shaojin Wen	60a6dfc14c	feat(cli): add session recap with /recap and auto-show on return (#3434) ... * feat(cli): add session recap with /recap and auto-show on return Users often open an old session days later and need to scroll through pages to remember where they left off. This change adds a short "where did I leave off" recap — a 1-3 sentence summary generated by the fast model — so they can resume without re-reading the history. Two triggers: - /recap: manual slash command. - Auto: when the terminal has been blurred for 5+ minutes and gets focused again (uses the existing DECSET 1004 focus protocol via useFocus). Gated on streamingState === Idle so it never interrupts an active turn. Only fires once per blur cycle. The recap is rendered in dim color with a chevron prefix, visually distinct from assistant replies. A new `general.showSessionRecap` setting controls the auto-trigger (default on). /recap works independent of the setting. Implementation notes: - generateSessionRecap uses fastModel (falls back to main model), tools: [], maxOutputTokens: 300, and a tight system prompt. It strips tool calls / responses from history before sending — tool responses can hold 10K+ tokens of file content that drown the recap in irrelevant detail. The 30-message window respects turn boundaries (slice never starts on a dangling model/tool response). - Output is wrapped in <recap>...</recap> tags; the extractor returns empty (skips render) if the tag is missing, preventing model reasoning from leaking into the UI. - All failures are silent (return null) and logged via a scoped debugLogger; recap is best-effort and must never break main flow. - /recap refuses to run while a turn is pending. * fix(cli): abort in-flight recap when showSessionRecap is disabled If the user disables showSessionRecap while an auto-recap LLM call is already in flight, the previous code returned early without aborting. The pending .then would still pass its idle/abort guards and append the recap, producing an unwanted message after the user has opted out. Abort the controller and clear it eagerly so the resolved promise no longer adds to history. * fix(cli): gate /recap and auto-recap on streaming idle state Two related issues from review: 1. /recap was only refusing when ui.pendingItem was set, but a normal model reply runs with streamingState === Responding and a null pendingItem. Invoking /recap mid-stream would generate a recap from a partial conversation and insert it between the user prompt and the assistant reply. 2. useAwaySummary cleared blurredAtRef before checking isIdle, so if focus returned during a still-streaming turn (after a >5min blur) the recap was permanently dropped — there was no later retry when the turn became idle, because isIdle was not in the effect deps. Fixes: - Expose isIdleRef on CommandContext.ui (mirrors btwAbortControllerRef pattern). Plumb it from AppContainer through useSlashCommandProcessor. - recapCommand now refuses when isIdleRef.current is false OR pendingItem is non-null. - useAwaySummary preserves blurredAtRef on the !isIdle bail and adds isIdle to the effect deps, so the trigger re-evaluates when the current turn finishes. - Brief blurs (< AWAY_THRESHOLD_MS) still reset blurredAtRef. Also seeds isIdleRef in nonInteractiveUi and mockCommandContext so the new field has a sensible default outside the interactive UI. * docs: document /recap command, showSessionRecap setting, and design - User docs: add /recap to the Session and Project Management table in features/commands.md and a dedicated subsection covering manual use, the auto-trigger, the dim-color rendering, and the fast-model tip. - User docs: add general.showSessionRecap row to the configuration settings reference. - Design doc: docs/design/session-recap/session-recap-design.md covers motivation, the two trigger paths, the per-file architecture, prompt design with the <recap> tag and three-tier extractor, history filtering rationale (functionResponse can be 10K+ tokens), the useAwaySummary state machine, the isIdleRef gating for /recap, model selection, observability, and out-of-scope items. * fix(core): exclude thought parts from session recap context filterToDialog kept any non-empty text part, but @google/genai's Part type also marks model reasoning with part.thought / part.thoughtSignature. That hidden chain-of-thought was being fed to the recap LLM and could get summarized as if it were user-visible dialogue. Drop parts where either flag is set. Update the design doc's History 过滤 section to call this out alongside the existing tool-call/response rationale. * docs(session-recap): correct debug-logging guidance, fill in state machine, sharpen UX wording Audit of the session recap docs against the implementation found three issues worth fixing: - Design doc claimed debug logs were enabled via a QWEN_CODE_DEBUG_LOGGING env var. That var does not exist; debug logs are written to ~/.qwen/debug/<sessionId>.txt by default, gated by QWEN_DEBUG_LOG_FILE. Replace with the accurate path + opt-out behavior, and tell the reader to grep for the [SESSION_RECAP] tag. - Design doc's useAwaySummary state machine table was missing the isFocused && blurredAtRef === null path (taken on first render and right after a brief-blur reset). Add the row. - User doc's "Refuses to run ... failures are silent" line conflated the inline-error refusal with silent generation failures, and "(when the conversation is idle)" used internal jargon. Split the two cases and spell out what "idle" means, including the wait-then-fire behavior when focus returns mid-turn. * docs(session-recap): correctly describe /recap vs auto-trigger failure modes The previous wording said "Generation/network failures are silent — the recap simply does not appear", but recapCommand returns a user-facing info message ("Not enough conversation context for a recap yet.") in exactly that path, and also returns inline messages for the config-not-loaded and busy-turn guards. Only the auto-trigger path is truly silent (it just skips addItem when generateSessionRecap returns null). Split the two paths in the doc so the manual command's "always responds with something" behavior is distinguished from the auto-trigger's no-op-on-failure behavior. * docs(session-recap): align prompt-rules section with the actual prompt Two doc-vs-code mismatches in the design doc's "System Prompt" section, caught with the same lens as yiliang114's failure-mode review: - The bullet list claimed RECAP_SYSTEM_PROMPT forbids "推测用户意图" and "用 'you' 称呼用户". Those rules existed in an early draft but were dropped when the <recap> tag rules were added; the current prompt has no such restrictions. Replace with the actual rules and add a "与 RECAP_SYSTEM_PROMPT 一一对应" marker so future edits stay in sync. - The doc said systemInstruction "覆盖" the main agent prompt. True for the agent prompt portion, but GeminiClient.generateContent internally calls getCustomSystemPrompt which appends user memory (QWEN.md / 自动 memory) as a suffix. Spell that out — the final system prompt is recap prompt + user memory, which is actually useful project context for the recap. * docs(session-recap): translate design doc to English The repo convention for docs/design is English (7 of 8 existing files; auto-memory/memory-system.md is the only Chinese one). The first version of this design doc followed the auto-memory example, which turned out to be the wrong sample. Translate to English while preserving the existing structure, the state-machine table, the prompt-vs-doc 1:1 alignment, the QWEN_DEBUG_LOG_FILE description, and the failure-mode notes added in prior commits. * fix(cli): drop empty info return from /recap interactive success path The interactive success path inserts the away_recap history item directly via ui.addItem and then returned `{type: 'message', messageType: 'info', content: ''}`. The slash-command processor's 'message' case unconditionally calls addMessage, which adds another HistoryItemInfo with empty text. The empty info renders as nothing (StatusMessage early-returns null), but it still bloats the in-memory history list and shows up in /export and saved sessions. Return void on the interactive success path and on the abort path so the processor's `if (result)` check skips the message-handler branch entirely. Widen the action's return type to `void | SlashCommandActionReturn` to match (same shape as btwCommand).	2026-04-19 21:38:48 +08:00