@chanlerdev/scorel 0.0.1 → 0.0.3

package/docs/spec/ship/S0087-gui-ui-polish-sweep.md

@@ -0,0 +1,153 @@
+# S0087: Codex-Inspired GUI Visual Pass
+
+## Goal
+
+Move the Scorel desktop GUI closer to a mature Codex-style workbench without copying Codex screen-for-screen.
+
+The business value is product trust. Scorel should stop feeling like an engineering demo and start feeling like a quiet, high-density desktop tool for project-scoped agent work.
+
+This spec is a visual-system pass over existing GUI surfaces. It does not introduce new product capabilities.
+
+## Design Direction
+
+Learn from Codex at the level of visual principles:
+
+- restrained source-list sidebar;
+- white main workspace with low visual noise;
+- natural heading text instead of badge-heavy emphasis;
+- composer as a command surface with a clear input/control row;
+- metadata controls visually attached to the composer;
+- quiet active states, subtle borders, and shallow elevation;
+- compact but readable typography.
+
+Do not copy Codex literally. Scorel remains Project-first and should only show real controls backed by existing product paths.
+
+## Scope
+
+### Visual Pass Targets
+
+- Sidebar source list:
+  - reduce heavy active row treatment;
+  - tighten project/session row rhythm;
+  - make empty session rows quieter;
+  - load session lists for the selected Project and expanded Projects so startup stays responsive without stale empty states;
+  - keep Add Project as the real project-management entry.
+
+- Empty workspace:
+  - hide the empty topbar when it has no useful content;
+  - render the project name as natural heading text, not a large grey badge;
+  - keep the hero centered but calmer and less heavy.
+
+- Composer:
+  - reduce shadow and heavy pill feel;
+  - add whole-surface focus feedback;
+  - make model selection and send action read as a compact control row;
+  - keep fake controls such as attachment, voice, and permission mode hidden.
+
+- Project metadata:
+  - keep project picker as a real control;
+  - visually attach the project picker to the composer area;
+  - keep the popover anchored and searchable.
+
+- Active session:
+  - keep a stable topbar title fallback (`未命名对话`) until auxiliary title generation updates it.
+  - keep expanded thinking content within the message column, with long prose wrapping and code blocks scrolling internally.
+  - render code-block language and copy controls inside the code-block header.
+  - keep markdown code blocks aligned with the GUI light surface and token system; do not use a fixed dark code-block theme in the light workspace.
+  - render tool calls as compact execution evidence rows: clear tool name, target object, status, counters, and expandable details.
+  - keep successful tool output collapsed by default, while making errors, diffs, and pending/running state visible.
+
+### Tool Display Contract
+
+- `Read`: collapsed header shows file basename and line range; expanded details show the returned read text and full path/range evidence.
+- `Glob` / `Grep`: collapsed header shows pattern/result count; expanded details show the returned file or match list plus pagination/mode metadata when present.
+- `Bash`: collapsed header shows command and exit status when known; expanded details show stdout/stderr/cwd evidence returned by the tool.
+- `Edit` / `Write`: collapsed header shows operation, file basename, and `+/-` counters; diff details are visible by default and remain collapsible.
+- `TodoWrite`: collapsed header shows active progress; expanded details show the current todo list and item states.
+- Fallback tools: collapsed header shows tool name; expanded details show args/result JSON.
+
+## Not In Scope
+
+- New GUI product capability such as SSH remote device, HTTP API, account/auth, review banner, or changed-files diff surface.
+- Runtime, provider/model, memory, channel, extension, or daemon contract changes.
+- Reintroducing disabled placeholder commands.
+- Empty-state plugin recommendation cards.
+- Global conversation history grouping.
+- Voice, attachment, permission-mode, or null-project mode.
+- WebUI component reuse or shared UI package extraction.
+- Streaming thinking/runtime protocol changes. Thinking currently arrives with final persistent assistant messages; streaming thinking requires a follow-up protocol/runtime spec.
+
+## Acceptance Criteria
+
+- Empty workspace has no blank topbar.
+- Empty heading uses natural text, with no badge-like project-name background.
+- Composer has low-shadow elevation, stable focus feedback, and no unimplemented controls.
+- Project picker remains visible and attached to the composer cluster.
+- Sidebar active and empty states are quiet and source-list-like.
+- Startup loads session summaries for the selected Project and expanded Projects, not every Project.
+- Expanded thinking content cannot horizontally stretch the workspace.
+- Long prose wraps inside thinking/markdown content, while code blocks keep formatting and scroll internally.
+- Code blocks show the fenced language as non-interactive metadata on the top-left and a copy control on the top-right.
+- Code block theme and chrome match the GUI light mode instead of rendering as a visually detached dark block.
+- GUI tool blocks read as a low-noise execution trace, not generic JSON dumps.
+- Bash, Read, Glob/Grep, Edit/Write, TodoWrite, and fallback JSON tools share consistent header/body/error/pending styling.
+- File edits surface filename and diff counters in the header; expanded details keep diff/output internally scrollable.
+- Clicking a tool header reveals the right evidence for that tool type, not just raw arguments.
+- Active sessions show `未命名对话` when no generated title exists.
+- Existing GUI behavior remains Project-first.
+- Text remains readable and non-overlapping across narrow and normal desktop widths.
+- Sidebar collapse/resize behavior still works.
+- GUI shell render tests cover the changed contracts.
+- Full `pnpm typecheck && pnpm test` passes.
+
+## Testing Requirements
+
+- Focused GUI tests:
+
+```bash
+pnpm --filter @scorel/app-gui test
+```
+
+- GUI build:
+
+```bash
+pnpm --filter @scorel/app-gui build
+```
+
+- Full check:
+
+```bash
+pnpm typecheck && pnpm test
+```
+
+- Whitespace check:
+
+```bash
+git diff --check
+```
+
+- Run Electron GUI and visually inspect the empty workspace.
+
+## Impacted Files
+
+- `apps/gui/src/renderer/workspace/Workspace.tsx`
+- `apps/gui/src/renderer/App.tsx`
+- `apps/gui/src/renderer/shell/Sidebar.tsx`
+- `apps/gui/src/renderer/shell/ProjectTree.tsx`
+- `apps/gui/src/renderer/workspace/EmptyState.tsx`
+- `apps/gui/src/renderer/composer/Composer.tsx`
+- `apps/gui/src/renderer/chatbox/ShikiCodeBlock.tsx`
+- `apps/gui/src/renderer/chatbox/ShikiCodeBlock.test.tsx`
+- `apps/gui/src/renderer/chatbox/tool-blocks/*`
+- `apps/gui/src/renderer/styles.css`
+- `apps/gui/src/renderer/gui-shell.test.tsx`
+- `apps/gui/src/renderer/app-session-preload.test.tsx`
+- `apps/gui/src/sidebar-layout.test.ts`
+- `docs/ROADMAP.md`
+- `docs/spec/ship/S0087-gui-ui-polish-sweep.md`
+
+## Risks And Boundaries
+
+- Visual polish can sprawl. Keep this pass focused on existing workbench surfaces.
+- A better-looking fake feature is still bad product design. Hide unimplemented controls instead of styling them.
+- Render tests prove structure but not taste. Use manual GUI inspection before handoff.

package/docs/spec/ship/S0088-gui-streaming-thinking-contract.md

@@ -0,0 +1,35 @@
+# S0088: GUI Streaming Thinking Contract
+
+## Goal
+
+Make thinking visible while a turn is running instead of inserting the thinking block only after the final persistent `assistant_message` arrives.
+
+The business value is process trust. Users should see the agent's work unfold in order, not as a post-hoc replay after the visible answer has already completed.
+
+## Context
+
+Today Scorel streams only `text_delta`. Thinking content exists in the final persistent assistant message, so GUI can only render it after the turn is finalized. A GUI-only placeholder would be misleading because it would imply thinking is streaming when the runtime has not emitted it.
+
+## Scope
+
+- Add a protocol/runtime event for streaming thinking, likely `thinking_delta` or a more general ordered `content_delta`.
+- Preserve ordered assistant content blocks so thinking, text, and tool calls reconcile cleanly with the final persistent assistant message.
+- Update GUI projector to create and update thinking parts incrementally.
+- Keep final `assistant_message` as authoritative reconciliation, not a second visual insertion.
+
+## Not In Scope
+
+- Tool block visual polish; covered by `S0087`.
+- Fake GUI placeholders for thinking content.
+- Changing provider reasoning semantics beyond the event stream needed to display already-produced thinking.
+
+## Acceptance Criteria
+
+- Thinking appears during the active turn when the provider/runtime emits thinking content.
+- Final assistant reconciliation does not duplicate or reorder thinking/text/tool parts.
+- Existing text streaming remains smooth.
+- Protocol, daemon/client, GUI projector, and tests all agree on the new event contract.
+
+## Status
+
+Done.

package/docs/spec/ship/S0089-memory-reliability-and-dream-trigger.md

@@ -0,0 +1,84 @@
+# S0089: Memory Reliability And Dream Trigger
+
+## Goal
+
+Make Scorel memory actually useful in normal GUI/agent use by tightening the `AppendDaily -> idle dream -> memory injection` loop.
+
+The business value is continuity. If users finish meaningful work and later return to the project, Scorel should remember durable progress, decisions, and follow-ups without relying on fragile manual reminders.
+
+## Context
+
+S0081/S0082 established the memory architecture:
+
+- daily evidence is written through the agent-owned `AppendDaily` tool;
+- successful append marks the project dirty;
+- daemon schedules dreaming after project idle time;
+- memory content re-enters future turns through the hidden memory harness.
+
+In practice this is not reliable enough yet:
+
+- `AppendDaily` depends too much on the model remembering a prompt instruction near the end of work;
+- daily entries can be low quality when the model records vague summaries instead of durable evidence;
+- dream triggering is hard to observe and easy to miss;
+- idle-only scheduling means memory may not update before the app/host exits;
+- GUI has no clear signal that daily/dream/memory actually happened.
+
+## Scope
+
+### AppendDaily Quality
+
+- Make the tool contract harder to ignore in completed meaningful turns.
+- Improve the journal schema/prompt so entries prefer concrete completed work, decisions, evidence paths, and follow-ups over generic summaries.
+- Add validation or lightweight scoring for empty, duplicate, or low-signal entries.
+- Keep `AppendDaily` project-scoped and append-only.
+
+### Dream Trigger Reliability
+
+- Audit the current daemon dirty-project and idle-timer path.
+- Ensure a successful `AppendDaily` reliably schedules a dream attempt.
+- Add a recovery path for pending daily evidence when the process restarts before idle dream fires.
+- Consider a manual or debug trigger if it materially improves verification and support.
+
+### Observability
+
+- Expose enough local state to answer:
+  - when was the last daily append;
+  - whether the project is dirty;
+  - whether dream is scheduled/running/failed;
+  - when project memory was last updated.
+- Surface this in GUI Settings or a compact project memory status area.
+- Keep failures non-blocking for chat turns, but visible enough to debug.
+
+### Injection Verification
+
+- Verify that updated project memory is actually injected into subsequent model context.
+- Add tests or a local verification path proving `AppendDaily` evidence can become project memory and then influence a later turn.
+
+## Not In Scope
+
+- Full activity recorder.
+- Vector search or semantic memory.
+- Topic memory file fan-out.
+- Root/global memory promotion beyond the existing guarded behavior.
+- Replacing the memory harness with provider system prompt content.
+
+## Acceptance Criteria
+
+- Meaningful completed work has a reliable path to daily evidence without depending only on user reminders.
+- Successful `AppendDaily` schedules or queues dream work even across host restarts.
+- Dream status is inspectable from local state and surfaced in GUI.
+- Low-quality or duplicate daily entries are reduced by contract, validation, or tests.
+- A verified path proves daily evidence can update project memory and be injected into a later turn.
+- Existing memory settings remain backward compatible.
+
+## Testing Requirements
+
+- Core tests for `AppendDaily` schema/quality validation.
+- Daemon tests for dirty-project scheduling, idle dream, restart recovery, and failure visibility.
+- GUI tests for memory status rendering if a GUI surface is added.
+- Integration-style test or scripted verification for `AppendDaily -> dream -> memory injection`.
+- Full `pnpm typecheck && pnpm test`.
+
+## Status
+
+Done.

package/docs/spec/ship/S0090-gui-provider-delete-and-dark-code-theme.md

@@ -0,0 +1,77 @@
+# S0090: GUI Provider Delete And Dark Code Theme
+
+## Goal
+
+Fix two GUI regressions before the next IM expansion:
+
+- dark theme code blocks must use a dark Shiki theme instead of light-token colors;
+- Provider settings must expose a real delete path for configured providers.
+
+The business value is basic settings trust. Users should be able to remove bad provider config and read code blocks in the selected GUI theme.
+
+## Scope
+
+### Dark Code Blocks
+
+- Load both light and dark Shiki themes in the GUI code block highlighter.
+- Select the rendered theme from `:root[data-theme]` / system dark preference.
+- Re-render when the GUI theme changes.
+- Keep code block chrome styled by Scorel tokens; only syntax token colors switch.
+
+### Provider Delete
+
+- Add a protocol/client/daemon request for removing one provider from a project model profile.
+- Deleting a provider removes:
+  - `[providers.<id>]`;
+  - provider models owned by that provider;
+  - available models pointing at removed provider models;
+  - role selections that pointed at removed available models, with stable fallback when possible.
+- GUI Provider Settings exposes a delete button for the selected provider.
+- If no provider remains, the Provider page returns to the empty state without stale selected-provider UI.
+
+## Not In Scope
+
+- Deleting individual provider model definitions unless required by provider deletion.
+- Bulk reset of all model profile config.
+- Provider secret migration.
+- Changing provider catalog fetch behavior.
+- IM platform work; covered by S0091-S0093.
+
+## Acceptance Criteria
+
+- Dark GUI theme renders Shiki tokens with a dark theme.
+- Light GUI theme keeps the current light code block behavior.
+- Switching GUI theme updates future code block renders without app restart.
+- Provider delete removes the provider and all dependent model profile entries from persisted config.
+- Provider delete does not leave roles pointing at removed models.
+- GUI can delete the selected provider and updates the selected provider to the next available provider or empty state.
+- Remote GUI provider deletion uses the same daemon/client request as local GUI.
+
+## Testing Requirements
+
+- GUI Shiki tests prove both light and dark themes are loaded/selected.
+- Config renderer tests cover provider deletion and role fallback.
+- Protocol/client/daemon tests cover the delete request.
+- GUI render test covers delete button and empty-state transition.
+- Full `pnpm typecheck && pnpm test`.
+
+## Impacted Files
+
+- `apps/gui/src/renderer/chatbox/ShikiCodeBlock.tsx`
+- `apps/gui/src/renderer/chatbox/ShikiCodeBlock.test.tsx`
+- `apps/gui/src/shiki-theme.test.ts`
+- `apps/gui/src/renderer/settings/sections/ProviderSection.tsx`
+- `apps/gui/src/shared/ipc.ts`
+- `apps/gui/src/main.ts`
+- `apps/gui/src/main/local-host.ts`
+- `apps/gui/src/main/relay-service.ts`
+- `packages/protocol/src/events.ts`
+- `packages/protocol/src/wire.ts`
+- `packages/client/src/index.ts`
+- `packages/core/src/config/index.ts`
+- `packages/core/src/config/*.test.ts`
+- `packages/daemon/src/index.ts`
+
+## Status
+
+Done.

package/docs/spec/ship/S0091-built-in-qq-and-wechat-im-extensions.md

@@ -0,0 +1,125 @@
+# S0091: Built-In QQ And WeChat IM Extensions
+
+## Goal
+
+Add QQ Bot and WeChat as built-in IM extensions on the existing extension-backed channel bridge.
+
+The business value is channel reach. Telegram proved the bridge; QQ and WeChat force the adapter contract to stay generic enough for multiple IM platforms without forking Scorel runtime behavior.
+
+## Product Boundary
+
+Scorel must use official or documented bot/server APIs. This spec does not support personal-account reverse engineering, browser automation of consumer clients, unofficial Web WeChat scraping, or any path likely to get user accounts restricted.
+
+## Scope
+
+### Shared IM Adapter Utilities
+
+- Extract reusable helpers for HTTP polling/webhook-shaped adapters where the current Telegram code has platform-neutral logic.
+- Keep platform-specific authentication, payload parsing, mention rules, and send APIs inside each built-in extension.
+- Preserve the S0083 adapter boundary: adapters do platform IO only and never create sessions or write JSONL.
+
+### QQ Bot Extension
+
+Add:
+
+```text
+extensions/builtin/qq/
+  scorel.extension.json
+  adapter.js
+  adapter.d.ts
+  skills/qq/SKILL.md
+```
+
+Expected config shape:
+
+```toml
+[extensions.qq]
+enabled = true
+kind = "im"
+
+[extensions.qq.config]
+appId = "..."
+appSecret = "..."
+botId = "..."
+allowedConversationIds = "..."
+```
+
+QQ Bot uses the current official server-side credential flow: Scorel stores the developer-console `App ID` and `App Secret`, calls `https://bots.qq.com/app/getAppAccessToken`, caches the returned access token until shortly before expiry, and sends API requests with `Authorization: QQBot ACCESS_TOKEN`.
+
+`apiBaseUrl` and `accessTokenUrl` may remain internal override hooks for tests and sandbox work, but GUI Settings must not expose them as the default setup path.
+
+### WeChat Extension
+
+Add:
+
+```text
+extensions/builtin/wechat/
+  scorel.extension.json
+  adapter.js
+  adapter.d.ts
+  skills/wechat/SKILL.md
+```
+
+Expected config shape:
+
+```toml
+[extensions.wechat]
+enabled = true
+kind = "im"
+
+[extensions.wechat.config]
+webhookUrl = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=..."
+callbackToken = "..."
+callbackHost = "127.0.0.1"
+callbackPort = 0
+```
+
+Use WeCom group robot webhook semantics for outbound send only. The user copies the full webhook URL from the official group robot configuration and pastes it into Scorel. This webhook cannot receive user messages from the group.
+
+Inbound WeChat receive is covered by S0094: Scorel can expose an official-account style plaintext callback server when `callbackToken` is configured. Do not make users split `key`, env var names, or base URLs in the default outbound setup path. Do not implement consumer WeChat personal account automation.
+
+### Skills
+
+Each built-in extension must include a platform-specific skill that tells the model:
+
+- what kind of conversation it is replying to;
+- how mentions/group context should be interpreted;
+- platform etiquette and short-response expectations;
+- when to use `SendChannelMessage`;
+- what not to assume about raw platform ids.
+
+## Not In Scope
+
+- Consumer QQ/WeChat personal account login.
+- Public callback deployment, TLS, or hosted ingress.
+- Rich media send support; covered by S0092.
+- GUI Settings layout; covered by S0093.
+- Remote Relay management of IM settings.
+
+## Acceptance Criteria
+
+- QQ and WeChat built-in extension manifests are discoverable by the existing loader.
+- Each extension starts only when explicitly enabled and required credentials are present.
+- QQ requires `appId` and `appSecret`; WeChat requires either a full outbound `webhookUrl` or an inbound `callbackToken`.
+- Each adapter normalizes incoming text messages into the existing `ImIncomingMessage` shape.
+- Each adapter sends plain text replies through the existing `SendChannelMessage` path.
+- QQ send obtains and reuses an official access token instead of accepting deprecated bot token config.
+- Adapter diagnostics redact secrets.
+- QQ, WeChat, Telegram, and loopback share the same channel bridge and session binding behavior.
+- No QQ/WeChat-specific branch is added to runtime/session/core channel orchestration.
+
+## Testing Requirements
+
+- Manifest loader coverage for QQ and WeChat built-ins.
+- Adapter normalization tests using local HTTP stubs or pure parser fixtures.
+- Send-message tests proving each adapter maps `SendChannelMessage` to its platform send API shape.
+- Secret redaction tests.
+- Full `pnpm typecheck && pnpm test`.
+
+## Local State Boundary
+
+Pre-1.0 local config may contain older `tokenEnv`, `token`, `webhookKeyEnv`, `webhookKey`, or `webhookBaseUrl` keys from earlier S0091 drafts. Those keys are no longer the supported setup surface. Users should re-enter QQ `App ID` / `App Secret` or WeChat `Outbound Webhook` / `Callback Token` in GUI Settings.
+
+## Status
+
+Done.

package/docs/spec/ship/S0092-im-message-media-and-human-cadence.md

@@ -0,0 +1,83 @@
+# S0092: IM Message Media And Human Cadence
+
+## Goal
+
+Make IM conversations feel alive and trustworthy by improving outgoing message capability and IM-specific response cadence.
+
+The business value is user confidence. In IM, silence for minutes reads as failure; Scorel needs visible progress and short human-style replies without compromising the existing agent loop.
+
+## Scope
+
+### SendChannelMessage Payload
+
+Extend `SendChannelMessage` from text-only to a structured outgoing message:
+
+```ts
+type SendChannelMessageInput = {
+  text?: string;
+  attachments?: Array<{
+    type: "image" | "file";
+    path?: string;
+    url?: string;
+    mimeType?: string;
+    caption?: string;
+  }>;
+  channel?: string;
+  target?: "current";
+};
+```
+
+Rules:
+
+- At least one of `text` or `attachments` is required.
+- Adapters may downgrade unsupported attachments to a clear tool error.
+- Local file paths must be explicit and must not be guessed from raw platform ids.
+- Tool result details report per-attachment status.
+
+### Adapter Capability Contract
+
+- Add optional adapter capabilities for outgoing attachment support.
+- Telegram/QQ/WeChat can initially support text and explicitly reject unsupported media.
+- Loopback should support structured capture of text and attachment metadata for tests.
+
+### IM System Prompt / Harness Guidance
+
+Add IM-specific guidance to channel context:
+
+- acknowledge quickly when work will take time;
+- send brief progress updates through `SendChannelMessage` during long tasks;
+- prefer concise, conversational wording;
+- do not wait until every tool finishes before sending any reply;
+- avoid exposing internal tool names unless useful to the user;
+- keep business-critical facts and file references precise.
+
+This guidance must enter through the existing channel harness item / skill path, not a second provider-level system prompt.
+
+## Not In Scope
+
+- Full media upload implementation for every platform.
+- Voice, stickers, albums, interactive buttons, or payments.
+- Cross-conversation proactive messages.
+- A new IM runtime loop or queue.
+- Fake progress timers outside the agent loop.
+
+## Acceptance Criteria
+
+- `SendChannelMessage` accepts text, image, and file attachment metadata.
+- Text-only calls remain backward compatible.
+- Unsupported attachment sends fail as tool errors, not silent no-ops.
+- IM channel reminders tell the agent to respond early and keep long-running users informed.
+- Built-in IM skills include platform-specific response cadence guidance.
+- Tests prove the model-facing tool schema rejects empty sends and preserves attachment metadata.
+
+## Testing Requirements
+
+- Core channel tool tests for structured payload parsing.
+- Loopback adapter tests for captured attachment metadata.
+- Telegram/QQ/WeChat tests for unsupported media errors or implemented send mapping.
+- Instruction/channel context tests for IM cadence guidance.
+- Full `pnpm typecheck && pnpm test`.
+
+## Status
+
+Done.

package/docs/spec/ship/S0093-gui-im-settings-platform-layout.md

@@ -0,0 +1,66 @@
+# S0093: GUI IM Settings Platform Layout
+
+## Goal
+
+Redesign GUI IM Settings so multiple platforms fit without crowding the page.
+
+The business value is scale. Telegram was one provider; Telegram + QQ + WeChat needs a repeatable platform row pattern where details expand only when the user asks.
+
+## Scope
+
+- Replace the current Telegram-only large form with a platform list.
+- Each platform row shows:
+  - platform name;
+  - enabled/disabled toggle;
+  - active/inactive status;
+  - concise credential/config summary;
+  - expand/collapse affordance.
+- Clicking a row expands its detailed config below that row.
+- Clicking the expanded row again collapses it.
+- The page defaults to all platforms collapsed unless a previous expanded platform is stored locally.
+- The last expanded platform is remembered locally; collapsing clears that remembered state.
+- Support Telegram, QQ, and WeChat using one reusable component shape.
+- Preserve existing Telegram config fields and persistence behavior.
+- Add QQ and WeChat config fields that match S0091/S0094.
+- For QQ and WeChat, expose the current quick setup fields only: QQ `App ID` / `App Secret`, WeChat `Outbound Webhook` plus inbound callback `Callback Token` / `Callback Host` / `Callback Port`.
+- Keep settings stored through the existing `getExtensionSettings` / `upsertExtensionSettings` IPC path.
+- Absorb immediate GUI review fixes found before push:
+  - expanded platform details must have a visible ownership boundary;
+  - the composer must not submit while an IME composition is active.
+
+## Not In Scope
+
+- Remote Relay IM settings.
+- Diagnostics timeline.
+- Live credential validation beyond existing adapter refresh behavior.
+- Account OAuth or QR login.
+
+## Acceptance Criteria
+
+- The IM Settings page renders three compact platform rows.
+- The first render does not expand Telegram by default.
+- No single disabled platform consumes a full settings page height.
+- Expanding Telegram reveals the existing credential/poll/allow-list fields.
+- Expanding QQ or WeChat reveals their S0091 config fields.
+- QQ and WeChat do not expose env-var-first credential fields in the default Settings flow.
+- Re-clicking the expanded platform collapses details.
+- Re-opening IM Settings restores the previously expanded platform when one was stored.
+- Toggling a platform writes the correct extension config and refreshes local Host IM extensions.
+- Direct secret fields are password inputs and are never displayed in summaries.
+- Layout remains readable in narrow GUI widths.
+- Expanded fields are visually grouped under the active platform, not blended into sibling platform rows.
+- Pressing Enter while Chinese/Japanese/Korean IME composition is active does not submit or block candidate selection.
+- Plain Enter still submits when enabled; Shift+Enter remains available for newline input.
+
+## Testing Requirements
+
+- GUI render tests for compact rows and expansion.
+- GUI interaction tests for default-collapsed, toggle-to-collapse, and stored expansion restore.
+- GUI interaction tests for toggling and field blur persistence.
+- Existing Telegram settings behavior remains covered.
+- GUI composer tests cover IME composition Enter, plain Enter, and Shift+Enter.
+- Full `pnpm typecheck && pnpm test`.
+
+## Status
+
+Done.