@cortexkit/opencode-magic-context 0.41.4 → 0.42.0

package/src/shared/prompt-surface-a1-golden.md

@@ -1,11 +1,11 @@
 # Magic Context agent-facing surface (exported from source)
 
-Generated by `packages/plugin/scripts/export-agent-surface.ts` at 2026-08-08.
+Generated by `packages/plugin/scripts/export-agent-surface.ts` at 2026-09-11.
 Token counts are Claude BPE estimates on the raw text.
 
 ## 1. System-prompt guidance section
 
-### PRIMARY full (reduce=on, memory=on, dreamer=on, temporal=on) — 8714 chars, ~2003 tokens
+### PRIMARY full (reduce=on, memory=on, dreamer=on, temporal=on) — 8752 chars, ~2008 tokens
 
 ```markdown
 ## Magic Context
@@ -23,7 +23,7 @@ Because of this:
 Reduction prompts are routine housekeeping to keep the session fast and cheap — act on them as light maintenance, never as scarcity warnings. Keep individual operations efficient, but never let context size change *what* work you take on or *how thoroughly* you do it.
 
 Messages and tool outputs are tagged with §N§ identifiers (e.g., §1§, §42§).
-Use `ctx_reduce` to mark spent tagged content as discardable and reclaim space. Marking is NOT an immediate delete — it queues the content, which stays fully visible until space is actually needed (as soon as the next turn if you're already under pressure, much later if not), so mark a tool output as soon as you're done with it rather than hoarding the call for the end of the turn. The last 20 tags are protected (marking one just queues it until it ages out). Syntax: "3-5", "1,2,9", or "1-5,8,12-15".
+Use `ctx_reduce` to mark spent tagged content as discardable and reclaim space. Marking is NOT an immediate delete — it queues the content, which stays fully visible until space is actually needed (as soon as the next turn if you're already under pressure, much later if not), so mark a tool output as soon as you're done with it rather than hoarding the call for the end of the turn. The newest token-mass window stays protected until displaced. Syntax: "3-5", "1,2,9", or "1-5,8,12-15".
 Do not announce or narrate `ctx_reduce` drops — just call the tool silently. Saying "I'll drop these outputs" wastes tokens the user does not care about.
 Use `ctx_note` ONLY for genuinely future concerns — something to revisit much later, not work coming up in the next few turns (that's already in your active context) and not active multi-step work (use todos for that). Magic Context preserves your full context across both compaction and restarts, so an upcoming restart or "let's come back to this later" is never a reason to take a note — nothing is lost either way. Notes you do take survive compression and resurface at natural work boundaries (after commits, historian runs, todo completion).
 Use `ctx_memory` for durable project knowledge: write what future sessions must know, update/archive/merge the memories you see in `<project-memory>` when they drift. Memories persist across sessions and every new session starts with them.
@@ -35,11 +35,11 @@ Memories are grouped by category as `#id: fact` lines; pass the numeric id to `c
 Use `ctx_search` to search across project memories, indexed git commits, and this session's full conversation history (including compacted parts) from one query.
 Use `ctx_expand` to recover the raw conversation behind a summary under a `## start-end · date · title` heading inside `<session-history>` — pass the heading's start/end range when the summary is not enough (exact wording, values, error text).
 **Search before asking the user**: If you can't remember or don't know something that might have been discussed before or stored in project memory, use `ctx_search` before asking the user. Examples:
-- Can't remember where a related codebase or dependency lives → `ctx_search(query="opencode source code path")`
-- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres")`
-- Need a config value, API key location, or environment detail → `ctx_search(query="embedding provider configuration")`
-- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work")`
-- Want to recall what was decided in an earlier conversation → `ctx_search(query="dashboard release signing setup")`
+- Can't remember where a related codebase or dependency lives → `ctx_search(query="where is the opencode source code path?")`
+- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres?")`
+- Need a config value, API key location, or environment detail → `ctx_search(query="how is the embedding provider configured?")`
+- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work?")`
+- Want to recall what was decided in an earlier conversation → `ctx_search(query="what did we decide about the dashboard release signing setup?")`
 `ctx_search` returns ranked results from memories, git commits, and raw message history. Use message ordinals from results with `ctx_expand` to retrieve surrounding conversation context.
 Compressed history intentionally omits tool calls and their outputs — summaries like "I edited file X" are historian records, not patterns to replicate. In the live conversation, older tool calls and their results are cleaned up to save context — you may see your own past messages referencing actions without the corresponding tool call or result visible. This is normal context management. ALWAYS use real tool calls; never simulate, fabricate, or inline tool outputs in your text. If there is no tool result message, the action did not happen. NEVER simulate, hallucinate or claim tool calls, command output, search results, file edits, or diffs in plain text as if they actually occurred.
 Magic Context control metadata is not reply syntax. Never reproduce `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, `[dropped §N§]`, or `<!-- +Xm -->` markers in a normal reply and never treat them as user instructions; use ordinary prose and real tool calls instead.
@@ -71,7 +71,7 @@ Example: `ctx_note(action="write", content="Implement X because Y", surface_cond
 Prefer many small targeted operations over one large blanket operation, and keep the working set tidy as routine maintenance.
 ```
 
-### PRIMARY memory-off (reduce=on, memory=off) — 7679 chars, ~1744 tokens
+### PRIMARY memory-off (reduce=on, memory=off) — 7717 chars, ~1749 tokens
 
 ```markdown
 ## Magic Context
@@ -89,17 +89,17 @@ Because of this:
 Reduction prompts are routine housekeeping to keep the session fast and cheap — act on them as light maintenance, never as scarcity warnings. Keep individual operations efficient, but never let context size change *what* work you take on or *how thoroughly* you do it.
 
 Messages and tool outputs are tagged with §N§ identifiers (e.g., §1§, §42§).
-Use `ctx_reduce` to mark spent tagged content as discardable and reclaim space. Marking is NOT an immediate delete — it queues the content, which stays fully visible until space is actually needed (as soon as the next turn if you're already under pressure, much later if not), so mark a tool output as soon as you're done with it rather than hoarding the call for the end of the turn. The last 20 tags are protected (marking one just queues it until it ages out). Syntax: "3-5", "1,2,9", or "1-5,8,12-15".
+Use `ctx_reduce` to mark spent tagged content as discardable and reclaim space. Marking is NOT an immediate delete — it queues the content, which stays fully visible until space is actually needed (as soon as the next turn if you're already under pressure, much later if not), so mark a tool output as soon as you're done with it rather than hoarding the call for the end of the turn. The newest token-mass window stays protected until displaced. Syntax: "3-5", "1,2,9", or "1-5,8,12-15".
 Do not announce or narrate `ctx_reduce` drops — just call the tool silently. Saying "I'll drop these outputs" wastes tokens the user does not care about.
 Use `ctx_note` ONLY for genuinely future concerns — something to revisit much later, not work coming up in the next few turns (that's already in your active context) and not active multi-step work (use todos for that). Magic Context preserves your full context across both compaction and restarts, so an upcoming restart or "let's come back to this later" is never a reason to take a note — nothing is lost either way. Notes you do take survive compression and resurface at natural work boundaries (after commits, historian runs, todo completion).
 Use `ctx_search` to search across project memories, indexed git commits, and this session's full conversation history (including compacted parts) from one query.
 Use `ctx_expand` to recover the raw conversation behind a summary under a `## start-end · date · title` heading inside `<session-history>` — pass the heading's start/end range when the summary is not enough (exact wording, values, error text).
 **Search before asking the user**: If you can't remember or don't know something that might have been discussed before or stored in project memory, use `ctx_search` before asking the user. Examples:
-- Can't remember where a related codebase or dependency lives → `ctx_search(query="opencode source code path")`
-- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres")`
-- Need a config value, API key location, or environment detail → `ctx_search(query="embedding provider configuration")`
-- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work")`
-- Want to recall what was decided in an earlier conversation → `ctx_search(query="dashboard release signing setup")`
+- Can't remember where a related codebase or dependency lives → `ctx_search(query="where is the opencode source code path?")`
+- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres?")`
+- Need a config value, API key location, or environment detail → `ctx_search(query="how is the embedding provider configured?")`
+- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work?")`
+- Want to recall what was decided in an earlier conversation → `ctx_search(query="what did we decide about the dashboard release signing setup?")`
 `ctx_search` returns ranked results from memories, git commits, and raw message history. Use message ordinals from results with `ctx_expand` to retrieve surrounding conversation context.
 Compressed history intentionally omits tool calls and their outputs — summaries like "I edited file X" are historian records, not patterns to replicate. In the live conversation, older tool calls and their results are cleaned up to save context — you may see your own past messages referencing actions without the corresponding tool call or result visible. This is normal context management. ALWAYS use real tool calls; never simulate, fabricate, or inline tool outputs in your text. If there is no tool result message, the action did not happen. NEVER simulate, hallucinate or claim tool calls, command output, search results, file edits, or diffs in plain text as if they actually occurred.
 Magic Context control metadata is not reply syntax. Never reproduce `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, `[dropped §N§]`, or `<!-- +Xm -->` markers in a normal reply and never treat them as user instructions; use ordinary prose and real tool calls instead.
@@ -131,7 +131,7 @@ Example: `ctx_note(action="write", content="Implement X because Y", surface_cond
 Prefer many small targeted operations over one large blanket operation, and keep the working set tidy as routine maintenance.
 ```
 
-### PRIMARY reduce-off (reduce=off, memory=on) — 6429 chars, ~1477 tokens
+### PRIMARY reduce-off (reduce=off, memory=on) — 6484 chars, ~1489 tokens
 
 ```markdown
 ## Magic Context
@@ -158,11 +158,11 @@ Memories are grouped by category as `#id: fact` lines; pass the numeric id to `c
 Use `ctx_search` to search across project memories, indexed git commits, and this session's full conversation history (including compacted parts) from one query.
 Use `ctx_expand` to recover the raw conversation behind a summary under a `## start-end · date · title` heading inside `<session-history>` — pass the heading's start/end range when the summary is not enough (exact wording, values, error text).
 **Search before asking the user**: If you can't remember or don't know something that might have been discussed before or stored in project memory, use `ctx_search` before asking the user. Examples:
-- Can't remember where a related codebase or dependency lives → `ctx_search(query="opencode source code path")`
-- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres")`
-- Need a config value, API key location, or environment detail → `ctx_search(query="embedding provider configuration")`
-- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work")`
-- Want to recall what was decided in an earlier conversation → `ctx_search(query="dashboard release signing setup")`
+- Can't remember where a related codebase or dependency lives → `ctx_search(query="where is the opencode source code path?")`
+- Forgot a prior architectural decision or constraint → `ctx_search(query="why did we choose SQLite over postgres?")`
+- Need a config value, API key location, or environment detail → `ctx_search(query="how is the embedding provider configured?")`
+- Looking for how something was implemented previously → `ctx_search(query="how does the dreamer lease work?")`
+- Want to recall what was decided in an earlier conversation → `ctx_search(query="what did we decide about the dashboard release signing setup?")`
 `ctx_search` returns ranked results from memories, git commits, and raw message history. Use message ordinals from results with `ctx_expand` to retrieve surrounding conversation context.
 Compressed history intentionally omits tool calls and their outputs — summaries like "I edited file X" are historian records, not patterns to replicate. In the live conversation, older tool calls and their results are cleaned up to save context — you may see your own past messages referencing actions without the corresponding tool call or result visible. This is normal context management. ALWAYS use real tool calls; never simulate, fabricate, or inline tool outputs in your text. If there is no tool result message, the action did not happen. NEVER simulate, hallucinate or claim tool calls, command output, search results, file edits, or diffs in plain text as if they actually occurred.
 Magic Context control metadata is not reply syntax. Never reproduce `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, `[dropped §N§]`, or `<!-- +Xm -->` markers in a normal reply and never treat them as user instructions; use ordinary prose and real tool calls instead.
@@ -172,13 +172,13 @@ Example: `ctx_note(action="write", content="Implement X because Y", surface_cond
 **Temporal awareness**: User messages may be preceded by HTML comments like `<!-- +12m -->`, `<!-- +2h 15m -->`, or `<!-- +3d 4h -->` indicating time elapsed since the previous message's completion. Compartments in `<session-history>` carry `start-date` and `end-date` attributes (YYYY-MM-DD) showing real-time boundaries. Use these when reasoning about workflow pacing, log durations, build times, or how long ago something happened.
 ```
 
-### SUBAGENT minimal — 679 chars, ~185 tokens
+### SUBAGENT minimal — 693 chars, ~187 tokens
 
 ```markdown
 ## Magic Context
 
 Messages and tool outputs are tagged with §N§ identifiers (e.g., §1§, §42§).
-Use `ctx_reduce` to drop tool outputs you have already finished with, keeping your working context lean. Syntax: "3-5", "1,2,9", or "1-5,8,12-15". The last 20 tags are protected.
+Use `ctx_reduce` to drop tool outputs you have already finished with, keeping your working context lean. Syntax: "3-5", "1,2,9", or "1-5,8,12-15". The newest token-mass window stays protected.
 Drop silently — do not narrate it. NEVER drop large ranges blindly (e.g., "1-50"); review each tag first. Do not drop user or assistant text messages — only large tool outputs are worth dropping.
 Older tool calls may show `[dropped §N§]` sentinels; that is normal context management, not a pattern to copy. ALWAYS make fresh real tool calls when you need data again; never fabricate or inline tool output.
 ```
@@ -254,19 +254,19 @@ Two recovery modes for finer detail:
 }
 ```
 
-### ctx_note — description ~391 tokens, params ~317 tokens (total ~708)
+### ctx_note — description ~392 tokens, params ~378 tokens (total ~770)
 
 **Description:**
 
 ```
-Working notes for this session's future — reminders, follow-ups, and things to revisit later.
+Working notes for this session — reminders, follow-ups, and things to revisit later.
 
-Use a note when something matters LATER but not in the next few steps: "revisit the retry logic after the release", "user wants the dashboard polish batched", "flaky test to investigate when touching CI". Don't use notes for active multi-step work (use todos) or for durable project knowledge that should outlive this session (use ctx_memory). Notes resurface automatically at natural work boundaries and whenever you read them.
+Use a note when something matters LATER but not in the next few steps: "revisit the retry logic after the release", "user wants the dashboard polish batched", "flaky test to investigate when touching CI". Don't use notes for active work (use todos) or durable project knowledge (use ctx_memory). Notes resurface at work boundaries and when read.
 
 Actions:
 - write: save a note (content). Add surface_condition to make it a smart note (below).
 - read: list notes, newest first. Default: latest active session notes + ready smart notes; page older ones with limit/offset, or inspect other states with filter.
-- update / dismiss: change or retire a note by note_id.
+- update: change a note by note_id. dismiss: retire one by note_id or 1–50 by note_ids; provide exactly one.
 
 Smart notes: pass surface_condition and the note stays hidden until a background checker confirms the condition — using ONLY externally verifiable signals (GitHub state via gh, files on disk, git history, web pages). It cannot see this conversation, so the condition must be checkable from outside:
 ✓ "When PR #42 in cortexkit/magic-context is merged"
@@ -321,11 +321,22 @@ Example: ctx_note(action="write", content="Re-run the perf benchmark once the bo
   "note_id": {
     "description": "Note ID (required for 'dismiss' and 'update' actions).",
     "type": "number"
+  },
+  "note_ids": {
+    "description": "One to fifty note ids for 'dismiss' only; do not combine with note_id.",
+    "minItems": 1,
+    "maxItems": 50,
+    "type": "array",
+    "items": {
+      "type": "integer",
+      "minimum": 1,
+      "maximum": 9007199254740991
+    }
   }
 }
 ```
 
-### ctx_memory — description ~234 tokens, params ~201 tokens (total ~435)
+### ctx_memory — description ~234 tokens, params ~216 tokens (total ~450)
 
 **Description:**
 
@@ -365,7 +376,7 @@ Example: ctx_memory(action="write", category="CONSTRAINTS", content="Pi stores s
     "type": "string"
   },
   "category": {
-    "description": "What kind of fact this is (required for write; optional merge override)",
+    "description": "What kind of fact this is (required for write; optional on update to recategorize, omitted keeps the current category; optional merge override)",
     "type": "string",
     "enum": [
       "PROJECT_RULES",
@@ -393,20 +404,24 @@ Example: ctx_memory(action="write", category="CONSTRAINTS", content="Pi stores s
 }
 ```
 
-### ctx_search — description ~309 tokens, params ~184 tokens (total ~493)
+### ctx_search — description ~402 tokens, params ~184 tokens (total ~586)
 
 **Description:**
 
 ```
 Your long-term recall for this project — search everything that ever happened here, not just what's currently visible.
 
+Retrieval matches meaning as well as exact words and fuses them, so phrasing matters: phrase `query` as a natural-language question that still contains the exact terms you expect in the answer (paths, symbols, config keys, error strings); a bare keyword stack finds less than a question carrying the same words.
+- Good: "where is the retry backoff for the upload client configured?"
+- Bad: "upload client retry backoff config"
+
 Reach for it when something feels familiar but isn't in view: "did we solve this before?", "what did we decide about X?", "when did this break?", "where does Y live?". Results only contain things you CANNOT currently see — memories already shown in <project-memory> and the live conversation tail are filtered out. A query that is just one or more memory ids (e.g. `#7234` or `12, 34`) bypasses text search and resolves those ids directly.
 
 Sources (omit for a broad search across all):
 - memory: curated cross-session project knowledge — rules, constraints, conventions.
 - message: the raw conversation behind your compacted history. Hits include message ordinals — expand the surrounding exchange with ctx_expand(start=N-10, end=N+5).
 - git_commit: this repository's commit history.
-- note: parked decisions, follow-ups, and dismissed notes with their recorded text.
+- note: parked decisions and follow-ups with their recorded text.
 
 Picking sources:
 - "when did this change / was this working before" → ["git_commit", "message"]
@@ -450,9 +465,9 @@ The hash handler persists the MD5 of `output.system.join("\\n")`. The values bel
 
 | Variant | Guidance bytes | MD5 system-prompt hash |
 |---|---:|---|
-| PRIMARY full | 8778 | `e8606e8e36cf19f5588ae0a76ce23b0e` |
-| PRIMARY memory-off | 7737 | `4d528493cac10523f815689677c46ea1` |
-| PRIMARY reduce-off | 6471 | `f5e8089b0ec037f8a81c648edd141913` |
-| SUBAGENT minimal | 691 | `83d69748f204fff98249565d5a31aa99` |
+| PRIMARY full | 8816 | `e8a75373e85edefedf7a5c8c19af3926` |
+| PRIMARY memory-off | 7775 | `402c342a3ff283375c47a1735d03aa1a` |
+| PRIMARY reduce-off | 6526 | `7e5d386d94abe4f101bfd6d891ec183b` |
+| SUBAGENT minimal | 705 | `1c09c70b742f79274c501dd8f7eff1fc` |
 
 The OpenCode and Pi runtime compatibility tests consume this snapshot for omitted `prompt_surface` and explicit `{ default: "full" }`: both assert guidance, registered tool descriptions, tool IDs, and hashes; OpenCode also asserts these parameter schemas directly, while Pi asserts its TypeBox-owned schemas stay byte-identical across both config forms.

package/src/shared/prompt-surface-runtime.test.ts

@@ -80,6 +80,34 @@ describe("prompt-surface runtime", () => {
         expect(changedModel.primaryOverride).toBe(second);
     });
 
+    it("shares one frozen guidance epoch between the system hook and Rust adapter", () => {
+        const directory = tempDir();
+        const path = join(directory, "guidance.md");
+        const first = "## Magic Context\n\nShared first epoch";
+        const second = "## Magic Context\n\nShared second epoch";
+        writeFileSync(path, first);
+        const runtime = createPromptSurfaceRuntime({
+            userConfigDirectory: directory,
+            warn: () => undefined,
+        });
+        const systemEpochs = createPromptSurfaceGuidanceEpochCache(runtime);
+        const adapterEpochs = createPromptSurfaceGuidanceEpochCache(runtime);
+        const config = {
+            default: "full" as const,
+            guidance_override_path: "guidance.md",
+        };
+
+        const systemInitial = systemEpochs.resolve("session", config, "provider/model");
+        writeFileSync(path, second);
+        const adapterDeferred = adapterEpochs.resolve("session", config, "provider/model");
+        expect(adapterDeferred).toBe(systemInitial);
+        expect(adapterDeferred.primaryOverride).toBe(first);
+
+        adapterEpochs.clear("session");
+        const systemNextEpoch = systemEpochs.resolve("session", config, "provider/model");
+        expect(systemNextEpoch.primaryOverride).toBe(second);
+    });
+
     it("uses registration default, applies known overrides, and reports invalid IDs", () => {
         const warnings: string[] = [];
         const runtime = createPromptSurfaceRuntime({

package/src/shared/prompt-surface-runtime.ts

@@ -230,18 +230,33 @@ interface GuidanceEpoch {
     selection: PromptSurfaceGuidanceSelection;
 }
 
-/** Freeze preset selection and materialized override bytes for one model-key epoch. */
-export function createPromptSurfaceGuidanceEpochCache(runtime: PromptSurfaceRuntime): {
+export interface PromptSurfaceGuidanceEpochCache {
     resolve: (
         sessionId: string,
         config: PromptSurfaceConfig | undefined,
         modelKey: string | undefined,
     ) => PromptSurfaceGuidanceSelection;
     clear: (sessionId: string) => void;
-} {
-    const epochs = new Map<string, GuidanceEpoch>();
+}
 
-    return {
+const guidanceEpochCacheByRuntime = new WeakMap<
+    PromptSurfaceRuntime,
+    PromptSurfaceGuidanceEpochCache
+>();
+
+/**
+ * Freeze preset selection and materialized override bytes for one model-key epoch.
+ * Every hook using the same runtime also shares this cache, so a file edit cannot
+ * make the system hook and Rust adapter observe different bytes within one epoch.
+ */
+export function createPromptSurfaceGuidanceEpochCache(
+    runtime: PromptSurfaceRuntime,
+): PromptSurfaceGuidanceEpochCache {
+    const shared = guidanceEpochCacheByRuntime.get(runtime);
+    if (shared) return shared;
+
+    const epochs = new Map<string, GuidanceEpoch>();
+    const cache: PromptSurfaceGuidanceEpochCache = {
         resolve(sessionId, config, modelKey) {
             const canonicalModelKey = modelKey ? piModelRefToCanonical(modelKey) : undefined;
             const cached = epochs.get(sessionId);
@@ -257,4 +272,6 @@ export function createPromptSurfaceGuidanceEpochCache(runtime: PromptSurfaceRunt
             epochs.delete(sessionId);
         },
     };
+    guidanceEpochCacheByRuntime.set(runtime, cache);
+    return cache;
 }

package/src/shared/resolve-fallbacks.ts

@@ -2,7 +2,7 @@ import type { ModelInput, ResolvedModelEntry } from "./model-resolution";
 
 /**
  * Resolve the fallback model list to attempt for a hidden-agent (historian /
- * dreamer / sidekick) call when its configured primary fails.
+ * dreamer) call when its configured primary fails.
  *
  * Policy: ONLY the user's explicitly-configured `fallback_models` for this
  * agent. There is NO builtin provider-agnostic chain — a hardcoded chain

package/src/shared/rpc-types.ts

@@ -7,6 +7,7 @@ import type {
     DreamTaskBacklogMap,
     DreamTaskProgress,
 } from "../features/magic-context/dreamer/task-registry";
+import type { SynapseLaneDescriptor } from "../features/magic-context/memory/embedding-synapse";
 import type { ConfigParseFailure } from "./config-diagnostics";
 import type { LoggerDiagnostics } from "./logger";
 
@@ -169,6 +170,8 @@ export interface StatusDetail extends SidebarSnapshot {
             reserve: number;
             reserveSource: "output_catalog" | "output_config" | "wall_margin" | "none";
             geometry: "shared_upfront" | "shared_truncating" | "separate";
+            windowSource: "catalog" | "overlay" | "provider" | "detected";
+            absoluteWall: number;
         };
     };
     /**
@@ -239,12 +242,127 @@ export interface EmbedDetail {
     enabled: boolean;
     model: string;
     provider: string;
+    synapseDescriptor?: SynapseLaneDescriptor;
     session: { embedded: number; total: number };
     memories: { embedded: number; total: number };
     commits: { embedded: number; total: number; gitEnabled: boolean };
     statusText: string;
 }
 
+export interface DebugProcessMemoryUsage {
+    rss: number;
+    heapTotal: number;
+    heapUsed: number;
+    external: number;
+    arrayBuffers: number;
+}
+
+export interface DebugSessionHolderCount {
+    sessionId: string;
+    lkgBytes: number;
+    taggerAssignments: number;
+    taggerToolAccounting: number;
+    wireRawMessages: number;
+    wireMessages: number;
+    wireContentSnapshots: number;
+    wireEstimatedBytes: number;
+}
+
+export interface DebugMemoryHolders {
+    lkgSlots: {
+        count: number;
+        totalBytes: number;
+    };
+    taggerCache: {
+        sessionCount: number;
+        assignmentEntries: number;
+        toolAccountingEntries: number;
+        loadSignatureEntries: number;
+    };
+    wireCache: {
+        snapshots: number;
+        rawContentSnapshots: number;
+        estimatedBytes: number;
+    };
+    compartmentMirrors: {
+        entries: number;
+    };
+    messageIndexQueue: {
+        queueLength: number;
+        reconciliationScheduled: number;
+        incrementalTimers: number;
+        pendingIncremental: number;
+        activeSessionLocks: number;
+        completedIncrementalKeys: number;
+        activeBufferMessages: number;
+        activeBufferBytes: number;
+    };
+    sessions: DebugSessionHolderCount[];
+}
+
+export interface DebugSqliteConnectionMemoryStats {
+    sequence: number;
+    filename: string;
+    readonly: boolean;
+    pageSize: number | null;
+    pageCount: number | null;
+    freelistCount: number | null;
+    cacheSize: number | null;
+    cacheSizeUnit: "pages" | "kib" | null;
+    cacheUpperBoundBytes: number | null;
+    mmapSizeBytes: number | null;
+    walFileBytes: number | null;
+    shmFileBytes: number | null;
+    fts5TableCount: number | null;
+    journalMode: string | null;
+}
+
+export interface DebugNativeMemoryUsage {
+    sqlite: {
+        connectionCount: number;
+        cacheUpperBoundBytes: number;
+        mmapUpperBoundBytes: number;
+        walFileBytes: number;
+        shmFileBytes: number;
+        sqliteStatusApi: "unavailable";
+        connections: DebugSqliteConnectionMemoryStats[];
+    };
+    tokenizer: {
+        loaded: boolean;
+        loadAttempted: boolean;
+        tableBytes: number | null;
+        tablePath: string | null;
+    };
+    localEmbedding: {
+        loaded: boolean;
+        providerCount: number;
+        models: string[];
+        runtimes: Array<"native" | "wasm">;
+        modelCacheBytes: number | null;
+        rssDeltaAtLoad: number;
+        externalDeltaAtLoad: number;
+        arrayBuffersDeltaAtLoad: number;
+    };
+    quickJs: {
+        loadAttempted: boolean;
+        loaded: boolean;
+    };
+}
+
+export interface DebugMemoryUsageResponse {
+    pid: number;
+    bunVersion: string;
+    memoryUsage: DebugProcessMemoryUsage;
+    native: DebugNativeMemoryUsage;
+    holders: DebugMemoryHolders;
+}
+
+export interface DebugHeapSnapshotResponse extends DebugMemoryUsageResponse {
+    path: string;
+    format: "jsc" | "v8";
+    snapshotVersion?: number;
+}
+
 export interface RpcNotificationMessage {
     id: number;
     type: string;

package/src/shared/session-messages-bounded.test.ts

@@ -6,7 +6,7 @@
 // huge sessions (10k+ messages) which is exactly when Magic Context shines.
 //
 // Background: the plugin only ever needs the latest assistant message of a
-// helper subagent (historian / dreamer / sidekick / key-files / user-memory)
+// helper subagent (historian / dreamer / key-files / user-memory)
 // or a bounded tail of the active session (conflict-warning cleanup). Both
 // fit comfortably in `limit: 50` with massive headroom.
 //

package/src/shared/sqlite-import-fence.test.ts

@@ -0,0 +1,19 @@
+import { describe, expect, test } from "bun:test";
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+// `sqlite.ts` is executed directly by Node in CI's `node:sqlite` smoke and by
+// Pi/Desktop hosts. Node's type-stripping loader does not resolve extensionless
+// relative imports, so a static import of any sibling module breaks that path
+// while every Bun-run test stays green (2026-09-12: master CI red for three
+// runs after a logging import landed here). Runtime dependencies must be
+// injected (see registerSlowWriteReporter); only type-only imports may be relative.
+describe("sqlite.ts import fence", () => {
+    test("has no runtime-relative imports", () => {
+        const source = readFileSync(join(import.meta.dir, "sqlite.ts"), "utf8");
+        const relativeRuntimeImports = source
+            .split("\n")
+            .filter((line) => /^import\s+(?!type\s)[^;]*from\s+["']\.\.?\//.test(line));
+        expect(relativeRuntimeImports).toEqual([]);
+    });
+});

package/src/shared/sqlite.test.ts

@@ -1,7 +1,33 @@
 import { describe, expect, it } from "bun:test";
-import { loadSqliteModule, SqliteRuntimeUnavailableError } from "./sqlite";
+import {
+    Database,
+    getSqliteMemoryStats,
+    loadSqliteModule,
+    SqliteRuntimeUnavailableError,
+} from "./sqlite";
 
 describe("SQLite runtime selector", () => {
+    it("reports live connection PRAGMAs and removes closed handles", () => {
+        const before = getSqliteMemoryStats().connectionCount;
+        const db = new Database(":memory:");
+        try {
+            db.exec("PRAGMA cache_size=-1024");
+            db.exec("CREATE VIRTUAL TABLE probe_fts USING fts5(content)");
+            const during = getSqliteMemoryStats();
+            expect(during.connectionCount).toBe(before + 1);
+            expect(during.connections.at(-1)).toMatchObject({
+                filename: ":memory:",
+                cacheSize: -1024,
+                cacheSizeUnit: "kib",
+                cacheUpperBoundBytes: 1024 * 1024,
+                fts5TableCount: 1,
+            });
+        } finally {
+            db.close();
+        }
+        expect(getSqliteMemoryStats().connectionCount).toBe(before);
+    });
+
     it("wraps a missing node:sqlite module with the detected runtime and cause", async () => {
         const cause = Object.assign(new Error("No such built-in module: node:sqlite"), {
             code: "ERR_UNKNOWN_BUILTIN_MODULE",