@chanlerdev/scorel 0.0.1 → 0.0.3

package/docs/spec/ship/S0083-extension-manifest-and-im-channel-runtime.md

@@ -0,0 +1,338 @@
+# S0083: Extension Manifest And IM Channel Runtime
+
+## Goal
+
+Add the smallest extension and IM channel foundation that lets Scorel receive external IM messages, run them through the existing Host/Runtime path, and send replies back through the same channel.
+
+The business value is a new entry surface without a second agent stack: IM becomes a thin channel extension around `ScorelHost`, not a new runtime, queue, session store, or relay path.
+
+The design principles for this spec are:
+
+- elegant: channel code should be a narrow bridge, not a parallel product core;
+- minimally invasive: reuse `ScorelHost`, `DaemonClient`, session JSONL, follow-up, steer, skills, tools, and memory;
+- extensible: Telegram is only the first built-in channel, not a special case in core;
+- simple: V1 supports current-conversation replies only.
+
+## Source Of Truth
+
+- `docs/architecture.md`: CLI, WebUI, GUI, IM, and HTTP API are thin entries over the same Host.
+- `docs/spec/extensions.md`: extensions live under `~/.scorel/extensions/` and optional project `.scorel/extensions/`.
+- `docs/spec/channels.md`: channel docs must be updated by this spec to match the extension-backed channel bridge.
+- `docs/spec/ship/S0051-harness-item-and-system-reminder.md`: channel context must use `harness_item` and `<system-reminder>`.
+- `docs/spec/ship/S0052-follow-up-queue-and-dual-loop.md`: IM must reuse existing follow-up and steer queues.
+- `docs/spec/ship/S0053-skill-index-and-skill-tool.md`: enabled extension skill roots must enter the existing skill scanner.
+
+## Scope
+
+### 1. Extension Manifest
+
+Introduce a manifest file named:
+
+```text
+scorel.extension.json
+```
+
+Minimum schema:
+
+```typescript
+type ExtensionManifest = {
+  id: string;
+  kind: "im";
+  displayName: string;
+  adapter: string;
+  skills?: string[];
+  mcp?: unknown[];
+};
+```
+
+Rules:
+
+- `id` is the stable extension id and channel id, for example `telegram`.
+- `kind = "im"` means the extension exposes an IM adapter.
+- `adapter` is a path relative to the manifest directory.
+- `skills` is a list of directories relative to the manifest directory.
+- `mcp` is parsed and preserved for future specs, but S0083 does not start MCP servers.
+
+### 2. Extension Roots
+
+Load enabled extension manifests from:
+
+```text
+~/.scorel/extensions/
+.scorel/extensions/
+extensions/builtin/
+```
+
+Rules:
+
+- user extensions are under `~/.scorel/extensions/`;
+- project extensions are under `.scorel/extensions/`;
+- built-in extensions are shipped in the repo/package under `extensions/builtin/`;
+- project extension id wins over user extension id;
+- built-in extension id loses to both project and user extension id;
+- V1 only starts extensions explicitly enabled in config.
+
+### 3. Config
+
+Add explicit config for enabled IM extensions.
+
+Example:
+
+```toml
+[extensions.telegram]
+enabled = true
+kind = "im"
+
+[extensions.telegram.config]
+botTokenEnv = "SCOREL_TELEGRAM_BOT_TOKEN"
+```
+
+Rules:
+
+- secrets are referenced by env var name only;
+- raw tokens must not be written to config, JSONL, diagnostics, or memory;
+- disabled extensions may be discovered but must not start.
+
+### 4. IM Adapter Contract
+
+Define the adapter boundary around platform IO only:
+
+```typescript
+interface ImAdapter {
+  start(ctx: ImAdapterContext): Promise<void>;
+  stop(): Promise<void>;
+  sendMessage(target: ImTarget, message: ImOutgoingMessage): Promise<void>;
+  setTyping?(target: ImTarget, typing: boolean): Promise<void>;
+}
+
+interface ImAdapterContext {
+  onMessage(message: ImIncomingMessage): Promise<void>;
+  logger: Logger;
+}
+```
+
+Adapter rules:
+
+- adapter receives platform events and calls `onMessage`;
+- adapter sends messages to platform targets through its `sendMessage` method;
+- adapter must not create sessions;
+- adapter must not write JSONL;
+- adapter must not implement follow-up, steer, memory, tools, or skill loading;
+- adapter errors are isolated and logged without crashing the Host.
+
+### 5. Channel Bridge
+
+Add a Host-side channel bridge that connects enabled IM adapters to existing Host use cases.
+
+Responsibilities:
+
+- map `(extensionId, externalConversationId)` to a fixed Scorel session;
+- ensure the default workspace project exists at `~/.scorel/workspace`;
+- call existing `send_message` / Host application service for incoming text;
+- inject channel source context as a harness item for the current turn;
+- expose the current channel context to `SendChannelMessage`;
+- keep platform raw ids out of model-authored arguments.
+
+The bridge is allowed to keep a small durable binding index under `~/.scorel/`, for example:
+
+```text
+~/.scorel/channels/im-bindings.json
+```
+
+The binding value must be replayable:
+
+```typescript
+type ImSessionBinding = {
+  extensionId: string;
+  externalConversationId: string;
+  projectId: ProjectId;
+  sessionId: SessionId;
+  createdAt: number;
+  updatedAt: number;
+};
+```
+
+### 6. Default Workspace
+
+IM sessions use the default workspace project:
+
+```text
+~/.scorel/workspace
+```
+
+Rules:
+
+- the directory is created when the first enabled IM message needs it;
+- it is registered as a normal Project in the existing Project Registry;
+- it is not a special Runtime mode;
+- future GUI settings may allow users to choose another workspace, but S0083 does not add that UI.
+
+### 7. Incoming Message Semantics
+
+Incoming IM messages must enter the existing runtime path.
+
+Idle session:
+
+```text
+IM message -> normal send_message -> ordinary user_message
+```
+
+Running session:
+
+```text
+default -> runningBehavior: "follow_up"
+explicit /steer or /interrupt -> runningBehavior: "steer"
+```
+
+Rules:
+
+- no new follow-up queue;
+- no new steer queue;
+- no new IM runtime loop;
+- no new Host daemon;
+- no Relay dependency.
+
+### 8. Channel Source Reminder
+
+Before the Host runs the turn, append a channel source `harness_item`.
+
+Example content:
+
+```xml
+<system-reminder>
+This message came from an IM channel.
+
+channel: telegram
+conversation_type: group
+sender_display_name: Chanler
+mentioned_bot: true
+
+Use SendChannelMessage to reply to the current conversation when needed.
+</system-reminder>
+```
+
+Rules:
+
+- use `harness_item`, not provider-level system prompt;
+- the reminder is session evidence, not a user message;
+- the reminder must not include raw platform secrets;
+- raw user ids and raw group ids are allowed only in structured event data when needed for routing, not in model-facing text.
+
+### 9. SendChannelMessage Tool
+
+Add a built-in runtime tool available only when the current turn has channel context:
+
+```typescript
+SendChannelMessage({
+  text: string
+})
+```
+
+Optional V1 shape is allowed if implementation needs explicit channel echo:
+
+```typescript
+SendChannelMessage({
+  channel: string,
+  target: "current",
+  text: string
+})
+```
+
+Rules:
+
+- default target is the current external conversation;
+- the model must not provide Telegram chat ids, Feishu open ids, Slack channel ids, or other raw platform ids;
+- the Host resolves the current channel context to an adapter target;
+- if no channel context exists, the tool returns `no_channel_context`;
+- if the adapter send fails, the tool result is an error result and diagnostics record the adapter failure;
+- the tool result must not echo secrets or raw tokens.
+
+### 10. Extension Skills
+
+When an extension is enabled, each manifest `skills` directory enters the existing skill scanner.
+
+Rules:
+
+- extension skills are discovered by the same skill index machinery as project/user skills;
+- skill listing continues to enter the model through existing skill harness events;
+- conflict order is project skill, user skill, extension skill, built-in skill;
+- S0083 does not add a new Skill tool path.
+
+### 11. Loopback IM Extension
+
+Add one deterministic built-in loopback IM extension for tests and local verification.
+
+It should behave like a channel extension, not a testing bypass:
+
+- loaded through `scorel.extension.json`;
+- started through the same extension lifecycle;
+- receives incoming messages through a public local test hook or CLI/dev helper;
+- sends outgoing `SendChannelMessage` payloads into an inspectable in-memory or temp-file outbox.
+
+This validates the channel bridge without claiming Telegram support.
+
+## Not In Scope
+
+- Real Telegram API. That is S0084.
+- Real Feishu, Slack, Discord, WeCom, or WeChat.
+- Marketplace, remote installation, extension signing, or sandboxing.
+- MCP server startup from extension manifests.
+- Cross-conversation proactive send.
+- User-facing GUI extension management.
+- Webhook mode.
+- Relay-based IM routing.
+- A new Runtime, queue, session store, or daemon process for IM.
+
+## Acceptance Criteria
+
+- `scorel.extension.json` is parsed and validated.
+- enabled `kind = "im"` extensions start with Host lifecycle and stop cleanly.
+- disabled extensions do not start.
+- enabled extension skill directories are included in the existing skill index.
+- the default IM workspace is created at `~/.scorel/workspace` and registered as a normal Project.
+- repeated messages from the same `(extensionId, externalConversationId)` reuse the same session.
+- a running session receives normal IM messages as existing `follow_up` items.
+- explicit `/steer` or `/interrupt` IM messages enter the existing steer path.
+- channel source context is appended as a `harness_item` and reaches `buildContext()`.
+- `SendChannelMessage({ text })` sends to the current adapter target without model-authored raw ids.
+- loopback IM extension proves an incoming message can trigger a Host turn and a tool reply can reach the adapter outbox.
+- `docs/spec/extensions.md` and `docs/spec/channels.md` are updated to match the implemented extension-backed channel bridge.
+
+## Testing Requirements
+
+- Manifest parser tests for required fields, relative paths, disabled extensions, and invalid manifests.
+- Extension lifecycle tests proving enabled IM adapters start/stop and failures are isolated.
+- Skill index tests proving enabled extension skill roots are scanned.
+- Daemon/Host tests using the loopback IM extension with real temporary `~/.scorel` state and real JSONL sessions.
+- Daemon/Host tests proving running IM messages reuse existing follow-up and steer queues.
+- Tool tests proving `SendChannelMessage` resolves current channel context and rejects missing context.
+- Full `pnpm typecheck && pnpm test`.
+
+## Impacted Files
+
+- `docs/spec/extensions.md`
+- `docs/spec/channels.md`
+- `packages/protocol/src/*`
+- `packages/core/src/tools/*`
+- `packages/core/src/session/*`
+- `packages/daemon/src/*`
+- `packages/client/src/*` if the Host application service needs a client-facing option type
+- `extensions/builtin/loopback/*`
+- tests near the changed modules
+
+## Risks And Boundaries
+
+- Extension loading can become a platform too quickly. S0083 must only implement what IM channel runtime needs.
+- Raw platform ids are useful for routing but should not become model-authored parameters.
+- Follow-up and steer already exist. Reimplementing them in channel code is a regression.
+- The default workspace is convenient but broad. It must be a normal Project so future UI can inspect or move it.
+- Loopback channel is a product-path verification tool for the channel bridge, not proof that a real IM provider works.
+
+## Follow-Up Specs
+
+- S0084: Built-in Telegram IM Extension.
+- Feishu IM extension.
+- Slack or Discord IM extension.
+- GUI Settings for enabling and configuring IM extensions.
+- Extension MCP startup.
+- Cross-conversation channel target handles.

package/docs/spec/ship/S0084-built-in-telegram-im-extension.md

@@ -0,0 +1,188 @@
+# S0084: Built-In Telegram IM Extension
+
+## Goal
+
+Ship Telegram as the first real built-in IM extension on top of the S0083 extension/channel foundation.
+
+The business value is a real, locally runnable IM entry path: a user can message a Telegram bot, have the message enter a fixed Scorel session, and receive replies through `SendChannelMessage`.
+
+Telegram is the first provider because Bot API long polling works from a local Host without webhook, public ingress, or Relay.
+
+## Depends On
+
+- S0083: Extension Manifest And IM Channel Runtime.
+
+## Scope
+
+### 1. Built-In Extension Layout
+
+Add:
+
+```text
+extensions/builtin/telegram/
+  scorel.extension.json
+  adapter.js or adapter.ts
+  skills/
+    telegram/
+      SKILL.md
+```
+
+The manifest must use:
+
+```json
+{
+  "id": "telegram",
+  "kind": "im",
+  "displayName": "Telegram",
+  "adapter": "./adapter.js",
+  "skills": ["./skills"]
+}
+```
+
+The extension skill should explain Telegram-specific behavior to the model at a high level: group vs DM, mention expectations, and reply etiquette. It must not contain secrets.
+
+### 2. Config
+
+Telegram is enabled through normal extension config:
+
+```toml
+[extensions.telegram]
+enabled = true
+kind = "im"
+
+[extensions.telegram.config]
+botTokenEnv = "SCOREL_TELEGRAM_BOT_TOKEN"
+# Or store a direct bot API key when local plaintext config is acceptable:
+# apiKey = "123456:telegram-bot-token"
+pollIntervalMs = 1000
+allowedChatIds = "-1001234567890,123456789"
+```
+
+Rules:
+
+- either `apiKey` or `botTokenEnv` is required when enabled;
+- `apiKey` is stored directly in config; `botTokenEnv` reads the raw bot token from env at runtime;
+- `allowedChatIds` is an optional comma-separated string in V1 and defaults to no allow-list in local dev;
+- diagnostics must never print the raw bot token.
+
+### 3. Telegram Adapter
+
+Implement Telegram Bot API long polling.
+
+Required behavior:
+
+- call `getUpdates` with offset tracking;
+- convert text messages into S0083 `ImIncomingMessage`;
+- support private chats;
+- support group/supergroup messages where the bot is mentioned or replied to;
+- ignore non-text messages in V1 with a diagnostic entry;
+- call `sendMessage` for `SendChannelMessage`;
+- use `sendChatAction` for typing when available;
+- stop polling cleanly on Host shutdown.
+
+### 4. Conversation Identity
+
+Telegram conversation id should be stable and deterministic.
+
+Recommended mapping:
+
+```text
+private chat -> telegram:private:<chat.id>
+group chat   -> telegram:group:<chat.id>
+```
+
+The raw `chat.id` is used for routing in adapter context, but model-facing reminders should only expose safe descriptive fields:
+
+- `channel: telegram`
+- `conversation_type: private | group | supergroup`
+- `sender_display_name`
+- `mentioned_bot`
+
+### 5. Incoming Semantics
+
+Reuse S0083:
+
+- idle session -> normal prompt;
+- running session -> default `follow_up`;
+- `/steer ...` or `/interrupt ...` -> existing steer path;
+- all turns use channel source reminder;
+- replies use `SendChannelMessage`.
+
+### 6. Reply Semantics
+
+Telegram `SendChannelMessage` maps to Bot API `sendMessage`.
+
+Rules:
+
+- V1 sends plain text only;
+- no Markdown/HTML parse mode by default;
+- adapter may split messages that exceed Telegram length limits;
+- send failures return tool error results and diagnostics.
+
+### 7. Manual Smoke
+
+Add a documented manual smoke path:
+
+```bash
+export SCOREL_TELEGRAM_BOT_TOKEN=...
+pnpm scorel host serve
+```
+
+Then:
+
+1. send the bot a private message;
+2. verify `~/.scorel/workspace` project exists;
+3. verify the same Telegram chat reuses one Scorel session;
+4. verify JSONL contains the user message and channel reminder;
+5. verify the model can call `SendChannelMessage` and the Telegram chat receives the reply.
+
+## Not In Scope
+
+- Telegram webhook mode.
+- Inline keyboards.
+- Media, files, voice, stickers, images, or albums.
+- Markdown/HTML formatting.
+- Multiple bot accounts.
+- Proactive cross-chat sends.
+- Admin commands.
+- GUI settings for Telegram.
+- Relay deployment.
+
+## Acceptance Criteria
+
+- Telegram built-in extension is discoverable through the S0083 manifest loader.
+- Telegram starts only when enabled and either direct `apiKey` exists or `botTokenEnv` resolves.
+- Telegram long polling receives private text messages.
+- Telegram group messages are accepted only when bot mention/reply rules pass.
+- incoming Telegram messages reuse the fixed session for the Telegram conversation.
+- incoming messages enter existing Host runtime with S0083 channel reminder.
+- running Telegram messages reuse existing follow-up/steer behavior.
+- `SendChannelMessage` sends a Telegram `sendMessage` to the current chat.
+- stop shuts down long polling without leaving active timers.
+- manual smoke with a real Telegram bot token is documented.
+
+## Testing Requirements
+
+- Unit tests for Telegram update normalization.
+- Unit tests for mention/reply acceptance rules.
+- Unit tests for token redaction in diagnostics.
+- Adapter tests using a local HTTP Telegram API stub for `getUpdates`, `sendMessage`, and `sendChatAction`.
+- Host integration tests may use S0083 loopback for runtime semantics; Telegram tests cover provider-specific HTTP behavior.
+- Manual smoke with a real Telegram bot token before marking S0084 done.
+- Full `pnpm typecheck && pnpm test`.
+
+## Impacted Files
+
+- `extensions/builtin/telegram/*`
+- `packages/daemon/src/*`
+- `packages/core/src/config/*`
+- `docs/spec/extensions.md`
+- `docs/spec/channels.md`
+- tests near the changed modules
+
+## Risks And Boundaries
+
+- Telegram Bot API is reliable enough for first IM support, but still an external network dependency. Automated tests should use a local HTTP stub, while completion requires a real manual smoke.
+- Group chats can be noisy. V1 should require bot mention or reply in groups.
+- Telegram raw chat ids are routing data, not model-authored parameters.
+- S0084 must not add Telegram-specific branches to core channel logic. Provider-specific code stays inside the built-in extension.

package/docs/spec/ship/S0085-gui-im-extension-settings.md

@@ -0,0 +1,47 @@
+# S0085: GUI IM Extension Settings
+
+## Goal
+
+Add a real GUI control for enabling the built-in Telegram IM extension.
+
+The business value is that local GUI users no longer need to hand-edit `~/.scorel/config.toml` to try Telegram. The GUI writes the same user-level extension config that `scorel host serve` reads, and the embedded local Host applies the change immediately.
+
+## Scope
+
+- Add daemon/client protocol requests for reading and updating IM extension settings.
+- Persist extension settings through the shared config renderer, preserving existing provider, memory, and model config.
+- Refresh local Host IM adapters after settings are updated.
+- Add a GUI Settings page for IM with a Telegram toggle and basic config fields:
+  - credential mode: env or direct API key
+  - `credentialMode`
+  - `apiKey`
+  - `botTokenEnv`
+  - `pollIntervalMs`
+  - `allowedChatIds`
+  - `botUsername`
+- Use `~/.scorel/config.toml` as the user-level config path for GUI extension settings.
+- Include `extensions/` in package files and make built-in extension discovery work from the package root.
+
+## Not In Scope
+
+- Remote Relay IM control.
+- Telegram manual smoke with a real bot token.
+- GUI diagnostics timeline for extension startup errors.
+
+## Acceptance Criteria
+
+- GUI Settings exposes an IM page with a Telegram enable switch.
+- Toggling Telegram writes `[extensions.telegram]` to `~/.scorel/config.toml`.
+- Telegram config fields write `[extensions.telegram.config]`.
+- Telegram can use either an env-backed token or a directly stored `apiKey`.
+- Direct mode stays selected before an API key is entered.
+- Updating settings triggers local Host IM extension refresh without restarting the GUI.
+- Missing Telegram token does not crash the GUI; the extension remains configured but inactive.
+- Built-in extension discovery works when running from an installed package.
+
+## Testing Requirements
+
+- Core config renderer test for extension settings merge.
+- GUI local Host test for extension settings IPC path and persisted config.
+- GUI shell render test includes the IM settings page in navigation.
+- Full `pnpm typecheck && pnpm test`.

package/docs/spec/ship/S0086-auto-compact-and-session-memory.md

@@ -0,0 +1,124 @@
+# S0086: Auto Compact And Session Memory
+
+## Goal
+
+Ship the first simple automatic context compaction path and optional session memory maintenance.
+
+The business value is continuity in long-running GUI/CLI sessions: Scorel should avoid waiting until context overflow, keep recent turns intact, and preserve enough current-task state for the model to continue after older history is summarized.
+
+In S0086, **session memory is context management, not long-term memory**. It is an asynchronous pre-compact summary of the current session. It exists so auto compact can replace old context immediately at the threshold instead of blocking the user turn while generating a summary.
+
+## Scope
+
+### Auto Compact
+
+Before a new user turn runs, Host estimates the current LLM context size for the active session. If the estimate reaches the configured threshold, Host appends one persistent `compact` event. Host prefers the already-maintained session memory summary, but still falls back to the original foreground agent compact when session memory is missing.
+
+Default threshold:
+
+```text
+memory.autoCompactThreshold = 0.8
+```
+
+The threshold is a ratio of the selected model context window. If the selected model has no context window, Scorel falls back to the existing internal 200,000 token window assumption.
+
+Compact behavior:
+
+- compact only old history before the recent retention window;
+- keep up to the most recent 8 conversation events after the compact event, starting only from a replay-safe boundary;
+- write session memory content into JSONL as a `compact` event when available;
+- if session memory is unavailable, run a foreground auxiliary compact summary and write that summary instead;
+- do not delete or rewrite old JSONL events;
+- `buildContext()` injects the compact summary and stops walking earlier history;
+- compact is cheap at threshold time when session memory is fresh, but must still compact through the original foreground path when no session memory exists.
+
+The first implementation keeps a small fixed retention budget of recent conversation events. The retained suffix must start at `user_message`, `compact`, or an `assistant_message` that contains a `tool_call`. This keeps recent long-running tool evidence replayable while avoiding an orphan `tool_result` as the first retained message. It does not expose manual compact UX.
+
+### Session Memory
+
+Add a project setting:
+
+```text
+memory.sessionMemory = true
+```
+
+When enabled, Host maintains a per-session memory file after completed turns:
+
+```text
+~/.scorel/context/session-memory/<projectId>/<sessionId>.md
+```
+
+Session memory is current-session continuity, not root/project memory. It captures:
+
+- current task/status;
+- important decisions;
+- files or commands that matter for continuation;
+- blockers/follow-ups;
+- a short recent-work log.
+
+Session memory is updated asynchronously after completed turns. At compact time, Host directly uses this file as the compact summary when session memory is enabled and available.
+
+If a session memory update is already in flight when compact is needed, Host waits up to 5 seconds for that update. If the update does not finish in time, Host continues with foreground compact instead of waiting indefinitely. This gives the async pre-compact path a realistic chance to finish without letting a stale or slow background task block the main user turn.
+
+If `memory.sessionMemory = false`, auto compact still works through the original foreground compact path. The toggle only controls asynchronous pre-compact maintenance.
+
+### GUI Settings
+
+GUI Settings Memory section exposes:
+
+- session memory toggle;
+- auto compact threshold select.
+
+These controls use the existing project-scoped memory config path.
+
+## Not In Scope
+
+- Manual `/compact` command.
+- User-facing compact history browser.
+- Token counting through provider APIs.
+- Semantic recall or vector memory.
+- Topic memory files.
+- Cross-process scheduled session memory repair.
+- Deleting, truncating, or rewriting historical JSONL.
+
+## Acceptance Criteria
+
+- `[memory]` parses/renders `sessionMemory` and `autoCompactThreshold`.
+- GUI Settings renders real controls for session memory and compact threshold.
+- `PersistentEvent` includes `compact`.
+- Session replay treats `compact` as a conversation barrier: context starts with the summary and does not include older events.
+- Host checks compact before each user turn and appends `compact` once the estimated context reaches 80% of the selected model window.
+- Compact keeps recent context after the barrier by replaying the compact summary plus the retained recent safe event suffix.
+- After completed turns, Host updates the session memory file when enabled.
+- Session memory is project/session-scoped and does not update root or project `MEMORY.md`.
+- If session memory maintenance is in flight when compact is needed, Host briefly waits for it and then proceeds.
+- If session memory is unavailable, Host falls back to foreground auxiliary compact and still appends `compact`.
+- Failures in session-memory maintenance write diagnostics but do not fail the user turn.
+
+## Testing Requirements
+
+- Core session tests for `compact` parsing and barrier context.
+- Config tests for new memory fields.
+- Daemon tests proving auto compact appends `compact` and session memory is maintained.
+- GUI render tests proving the controls are visible.
+- Full `pnpm typecheck && pnpm test`.
+
+## Impacted Files
+
+- `packages/protocol/src/events.ts`
+- `packages/core/src/config/index.ts`
+- `packages/core/src/session/index.ts`
+- `packages/core/src/session/session.test.ts`
+- `packages/core/src/memory/index.ts`
+- `packages/core/src/memory/memory.test.ts`
+- `packages/daemon/src/index.ts`
+- `packages/daemon/src/embedded/embedded.test.ts`
+- `apps/gui/src/renderer/settings/sections/MemorySection.tsx`
+- `apps/gui/src/renderer/gui-shell.test.tsx`
+- `docs/ROADMAP.md`
+
+## Risks And Boundaries
+
+- Token estimation is approximate. This is acceptable for V1 because the trigger is intentionally conservative and uses the same rough estimate style as existing context-budget tooling.
+- A stale session memory can lose nuance. V1 keeps recent turns intact and preserves full JSONL evidence for audit/replay.
+- Session memory should be treated as continuity notes, not current code truth.