@cortexkit/opencode-magic-context 0.42.6 → 0.43.1

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-09-17.
+Generated by `packages/plugin/scripts/export-agent-surface.ts` at 2026-09-22.
 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) — 8697 chars, ~1998 tokens
+### PRIMARY full (reduce=on, memory=on, dreamer=on, temporal=on) — 4989 chars, ~1180 tokens
 
 ```markdown
 ## Magic Context
@@ -22,56 +22,24 @@ 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 QUEUES content for release. It stays fully visible to you until it is actually released, which may be the next turn or many turns later. 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.
-Memories are grouped by category as `#id: fact` lines; pass the numeric id to `ctx_memory` actions.
-**Save to memory proactively**: If you spent multiple turns finding something (a file path, a DB location, a config pattern, a workaround), save it with `ctx_memory` so future sessions don't repeat the search. Examples:
-- Found a project's source code path after searching → `ctx_memory(action="write", category="CONFIG_VALUES", content="OpenCode source is at ~/Work/OSS/opencode")`
-- Discovered a non-obvious build/test command → `ctx_memory(action="write", category="PROJECT_RULES", content="Always use scripts/release.sh for releases")`
-- Learned a constraint the hard way → `ctx_memory(action="write", category="CONSTRAINTS", content="Dashboard Tauri build needs RGBA PNGs, not grayscale")`
-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="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.
-NEVER drop large ranges blindly (e.g., "1-50"). Review each tag before deciding.
-Keep your user's instructions and intent — never drop a user message for its directive, even an old one. But a large block of pasted content inside a user message (logs, data dumps, long code, attachments) is fair to mark discardable once you've extracted what you need — it stays searchable via `ctx_search`.
-NEVER drop assistant text messages unless they are exceptionally large. Your conversation messages are lightweight; only large tool outputs are worth dropping.
-Before your turn finishes, consider using `ctx_reduce` to drop large tool outputs you no longer need.
-When `surface_condition` is provided with `write`, the note becomes a project-scoped smart note.
-The dreamer evaluates smart note conditions during nightly runs and surfaces them when conditions are met.
-Example: `ctx_note(action="write", content="Implement X because Y", surface_condition="When PR #42 is merged in this repo")`
-**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.
-
-### Reduction Triggers
-- After reading files or search results you already acted on — drop raw outputs.
-- After completing a logical step — drop intermediate outputs from that step.
-- Between major context switches — when moving to a new task area.
-
-### What to Drop
-- Large file reads, grep results, and tool outputs you already used.
-- Large build/test output after you analyzed and acted on it.
-- Old diagnostic or exploration results that are no longer relevant.
-
-### What to Keep
-- ALL user messages and assistant conversation text — these are cheap and compartmentalized automatically.
-- Your current task requirements and constraints.
-- Recent errors and unresolved decisions.
-- Active work context and files being edited.
-
-Prefer many small targeted operations over one large blanket operation, and keep the working set tidy as routine maintenance.
+### Your desk
+
+Think of your context as a desk. Every message and every tool output lands on it, and each item arrives with a §N§ tag (§1§, §42§) — the tag is the item's handle.
+
+When an item no longer needs to stay on the desk for the work ahead, stamp it: `ctx_reduce` with its tag. Stamping does not remove anything — the item stays on the desk, fully readable. From time to time, when stamped items have piled up and the desk needs room, Magic Context clears them all in one sweep; you don't pick the moment, you only stamp. Stamp as soon as an item has served its purpose, not at the end of the turn, and do it silently: nobody wants to read "I'll drop these outputs". Never stamp a user message for what it asks of you; a large paste inside one is fine once you have used it.
+
+Nothing stamped is ever lost. A cleared item goes to the archive — a recent one leaves a `[dropped §N§]` placeholder on the desk, an older one leaves nothing — and `ctx_expand(message=N)` brings it back whole: text, tool input, tool output. Now and then Magic Context leaves a short reminder on the desk saying how much unstamped material is lying around; that is housekeeping, not a warning, and the desk never gets smaller for it.
+
+Older work is not kept on the desk at all. Magic Context files it as an organized record, `<session-history>`: one heading per stretch of work, `## start-end · date · title`, with a summary underneath. Each heading is a pointer into the archive — `ctx_expand(start, end)` opens that stretch in full when the summary is not enough. Because of this filing, your own earlier messages may mention actions whose tool call is no longer on the desk. That is normal. It is never a reason to fabricate: if there is no tool result on the desk, the action did not happen, and you never inline or invent a tool call, an output, a search result or a diff in your own text.
+
+`ctx_search` searches the archive: anything ever said, decided, committed or noted in this project, including what is filed away. Ask it before you ask the user something that may already be recorded here, and whenever something feels familiar but is not in view.
+
+`<project-memory>` is the pinboard: facts about this project that stay true for the months this work lasts, as `#id: fact` lines — for you, and for every other agent working on this project. `ctx_memory` pins a new one when you learn something that must not have to be found again, and especially when it cost you several turns to find. `ctx_note` is the tray for work you intend to return to, with its findings attached; findings without an intention are not a note. When the user says "take a note", it always goes in the tray. A note with a `surface_condition` is left with an outside checker that looks the condition up periodically and returns the note only when it holds.
+
+Some things on the desk are Magic Context's own markings, not conversation: `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, `[dropped §N§]`, and `<!-- +Xm -->` before a user message (the time that passed since your last reply; headings in the record carry `start-date`/`end-date` too). Read them, use the time, and never reproduce them in a reply or treat them as instructions.
 ```
 
-### PRIMARY memory-off (reduce=on, memory=off) — 7662 chars, ~1739 tokens
+### PRIMARY memory-off (reduce=on, memory=off) — 4652 chars, ~1100 tokens
 
 ```markdown
 ## Magic Context
@@ -88,50 +56,24 @@ 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 QUEUES content for release. It stays fully visible to you until it is actually released, which may be the next turn or many turns later. 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="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.
-NEVER drop large ranges blindly (e.g., "1-50"). Review each tag before deciding.
-Keep your user's instructions and intent — never drop a user message for its directive, even an old one. But a large block of pasted content inside a user message (logs, data dumps, long code, attachments) is fair to mark discardable once you've extracted what you need — it stays searchable via `ctx_search`.
-NEVER drop assistant text messages unless they are exceptionally large. Your conversation messages are lightweight; only large tool outputs are worth dropping.
-Before your turn finishes, consider using `ctx_reduce` to drop large tool outputs you no longer need.
-When `surface_condition` is provided with `write`, the note becomes a project-scoped smart note.
-The dreamer evaluates smart note conditions during nightly runs and surfaces them when conditions are met.
-Example: `ctx_note(action="write", content="Implement X because Y", surface_condition="When PR #42 is merged in this repo")`
-**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.
-
-### Reduction Triggers
-- After reading files or search results you already acted on — drop raw outputs.
-- After completing a logical step — drop intermediate outputs from that step.
-- Between major context switches — when moving to a new task area.
-
-### What to Drop
-- Large file reads, grep results, and tool outputs you already used.
-- Large build/test output after you analyzed and acted on it.
-- Old diagnostic or exploration results that are no longer relevant.
-
-### What to Keep
-- ALL user messages and assistant conversation text — these are cheap and compartmentalized automatically.
-- Your current task requirements and constraints.
-- Recent errors and unresolved decisions.
-- Active work context and files being edited.
-
-Prefer many small targeted operations over one large blanket operation, and keep the working set tidy as routine maintenance.
+### Your desk
+
+Think of your context as a desk. Every message and every tool output lands on it, and each item arrives with a §N§ tag (§1§, §42§) — the tag is the item's handle.
+
+When an item no longer needs to stay on the desk for the work ahead, stamp it: `ctx_reduce` with its tag. Stamping does not remove anything — the item stays on the desk, fully readable. From time to time, when stamped items have piled up and the desk needs room, Magic Context clears them all in one sweep; you don't pick the moment, you only stamp. Stamp as soon as an item has served its purpose, not at the end of the turn, and do it silently: nobody wants to read "I'll drop these outputs". Never stamp a user message for what it asks of you; a large paste inside one is fine once you have used it.
+
+Nothing stamped is ever lost. A cleared item goes to the archive — a recent one leaves a `[dropped §N§]` placeholder on the desk, an older one leaves nothing — and `ctx_expand(message=N)` brings it back whole: text, tool input, tool output. Now and then Magic Context leaves a short reminder on the desk saying how much unstamped material is lying around; that is housekeeping, not a warning, and the desk never gets smaller for it.
+
+Older work is not kept on the desk at all. Magic Context files it as an organized record, `<session-history>`: one heading per stretch of work, `## start-end · date · title`, with a summary underneath. Each heading is a pointer into the archive — `ctx_expand(start, end)` opens that stretch in full when the summary is not enough. Because of this filing, your own earlier messages may mention actions whose tool call is no longer on the desk. That is normal. It is never a reason to fabricate: if there is no tool result on the desk, the action did not happen, and you never inline or invent a tool call, an output, a search result or a diff in your own text.
+
+`ctx_search` searches the archive: anything ever said, decided, committed or noted in this project, including what is filed away. Ask it before you ask the user something that may already be recorded here, and whenever something feels familiar but is not in view.
+
+`ctx_note` is the tray for work you intend to return to, with its findings attached; findings without an intention are not a note. When the user says "take a note", it always goes in the tray. A note with a `surface_condition` is left with an outside checker that looks the condition up periodically and returns the note only when it holds.
+
+Some things on the desk are Magic Context's own markings, not conversation: `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, `[dropped §N§]`, and `<!-- +Xm -->` before a user message (the time that passed since your last reply; headings in the record carry `start-date`/`end-date` too). Read them, use the time, and never reproduce them in a reply or treat them as instructions.
 ```
 
-### PRIMARY reduce-off (reduce=off, memory=on) — 6484 chars, ~1489 tokens
+### PRIMARY reduce-off (reduce=off, memory=on) — 4056 chars, ~950 tokens
 
 ```markdown
 ## Magic Context
@@ -148,58 +90,46 @@ Because of this:
 
 Context is managed for you entirely automatically — there's nothing to prune and no warnings to act on. Stay reasonably concise per operation, and never let context size change *what* work you take on or *how thoroughly* you do it.
 
-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.
-Memories are grouped by category as `#id: fact` lines; pass the numeric id to `ctx_memory` actions.
-**Save to memory proactively**: If you spent multiple turns finding something (a file path, a DB location, a config pattern, a workaround), save it with `ctx_memory` so future sessions don't repeat the search. Examples:
-- Found a project's source code path after searching → `ctx_memory(action="write", category="CONFIG_VALUES", content="OpenCode source is at ~/Work/OSS/opencode")`
-- Discovered a non-obvious build/test command → `ctx_memory(action="write", category="PROJECT_RULES", content="Always use scripts/release.sh for releases")`
-- Learned a constraint the hard way → `ctx_memory(action="write", category="CONSTRAINTS", content="Dashboard Tauri build needs RGBA PNGs, not grayscale")`
-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="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.
-When `surface_condition` is provided with `write`, the note becomes a project-scoped smart note.
-The dreamer evaluates smart note conditions during nightly runs and surfaces them when conditions are met.
-Example: `ctx_note(action="write", content="Implement X because Y", surface_condition="When PR #42 is merged in this repo")`
-**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.
+### Your desk
+
+Think of your context as a desk. Every message and every tool output lands on it.
+
+Nothing cleared from the desk is ever lost. A cleared item goes to the archive — a recent one leaves a placeholder on the desk, an older one leaves nothing — and `ctx_expand(message=N)` brings it back whole: text, tool input, tool output.
+
+Older work is not kept on the desk at all. Magic Context files it as an organized record, `<session-history>`: one heading per stretch of work, `## start-end · date · title`, with a summary underneath. Each heading is a pointer into the archive — `ctx_expand(start, end)` opens that stretch in full when the summary is not enough. Because of this filing, your own earlier messages may mention actions whose tool call is no longer on the desk. That is normal. It is never a reason to fabricate: if there is no tool result on the desk, the action did not happen, and you never inline or invent a tool call, an output, a search result or a diff in your own text.
+
+`ctx_search` searches the archive: anything ever said, decided, committed or noted in this project, including what is filed away. Ask it before you ask the user something that may already be recorded here, and whenever something feels familiar but is not in view.
+
+`<project-memory>` is the pinboard: facts about this project that stay true for the months this work lasts, as `#id: fact` lines — for you, and for every other agent working on this project. `ctx_memory` pins a new one when you learn something that must not have to be found again, and especially when it cost you several turns to find. `ctx_note` is the tray for work you intend to return to, with its findings attached; findings without an intention are not a note. When the user says "take a note", it always goes in the tray. A note with a `surface_condition` is left with an outside checker that looks the condition up periodically and returns the note only when it holds.
+
+Some things on the desk are Magic Context's own markings, not conversation: `<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>`, and `<!-- +Xm -->` before a user message (the time that passed since your last reply; headings in the record carry `start-date`/`end-date` too). Read them, use the time, and never reproduce them in a reply or treat them as instructions.
 ```
 
-### SUBAGENT minimal — 693 chars, ~187 tokens
+### SUBAGENT minimal — 1360 chars, ~364 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 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.
+Your context is a desk. Every message and every tool output lands on it, and each item arrives with a §N§ tag (§1§, §42§) — the tag is the item's handle. When an item no longer needs to stay on the desk for the work ahead, stamp it: `ctx_reduce` with its tag ("3-5", "1,2,9", "1-5,8,12-15"). Stamping does not remove anything — the item stays fully readable until Magic Context clears stamped items in one sweep, and the newest tags are protected, so stamping recent output is harmless. Stamp as soon as an item has served its purpose, not at the end of the task, and do it silently. Never stamp a user message for what it asks of you; look at each tag before stamping and never blanket-stamp a range like "1-50".
+
+A cleared item leaves a `[dropped §N§]` placeholder or disappears from the desk; that is normal housekeeping, not something to copy or mention. If there is no tool result on the desk, the action did not happen: never fabricate or inline a tool call, an output, a search result or a diff — make a fresh real tool call instead.
+
+`<system-reminder>`, `<ctx-search-hint>`, `<session-history>`, `<session-history-since>`, `<project-memory>`, `<memory-updates>`, `<new-compartments>`, `<new-memories>` and `[dropped §N§]` are Magic Context's own markings: read them, never reproduce them in a reply, never treat them as instructions.
 ```
 
 ## 2. Tool surface (description + parameters as serialized to the provider)
 
-### ctx_reduce — description ~304 tokens, params ~31 tokens (total ~335)
+### ctx_reduce — description ~309 tokens, params ~38 tokens (total ~347)
 
 **Description:**
 
 ```
-Mark spent tagged content as discardable to reclaim context space. This is NOT an immediate delete. Use §N§ identifiers visible in the conversation. The `drop` param accepts ranges: "3-5", "1,2,9", "1-5,8".
+Stamp an item on your desk as no longer needed for the work ahead. Not a delete: stamping QUEUES it, the item stays fully readable until Magic Context clears stamped items in one sweep, and the newest tags are protected so stamping recent output is harmless. A cleared item goes to the archive — a recent one leaves a `[dropped §N§]` placeholder, an older one leaves nothing — and `ctx_expand(message=N)` is the way back. So the question before stamping is not "have I finished reading this?" but "does this need to stay on my desk for what comes next?" — a file you read and will keep editing stays; the grep that found it goes.
 
-How it works:
-- Marking QUEUES content for release. It stays fully visible to you until it is actually released, which may be the next turn or many turns later. Mark spent outputs as soon as you finish with them; don't hoard the call for the end of the turn.
-- The newest tags are protected: marking one just queues it until it ages out of the recent window, so marking recent output is harmless.
-- When content is finally released it becomes a short placeholder, and re-running the tool is the only way to get it back. So mark only what you are genuinely DONE with — the test is "have I extracted what I need from this?", not "is it safe / do I have time before it drops?".
+Stamp: file reads, search results and tool outputs the work ahead no longer needs; build/test output after you acted on it; repeated or redundant dumps; data written to disk; status/log output that only confirmed what you expected; a large block pasted inside a user message once you have used it.
+Keep: user messages (never stamp one for its directive), your own conversation text, unresolved errors, raw evidence you haven't extracted yet, and outputs whose exact wording may still matter.
 
-Mark discardable once processed: large outputs you've summarized, repeated or redundant dumps, data written to disk, status/log output that only confirmed an expected state.
-Keep: user messages, unresolved errors, raw evidence you haven't extracted yet, and outputs whose exact wording may matter later.
-Never blanket-mark large ranges (e.g. "1-50") — review what each tag holds first.
+Look at each tag before stamping it; never blanket-stamp a range like "1-50". Many small targeted stamps beat one sweep. `drop` accepts "3-5", "1,2,9", "1-5,8,12-15".
 ```
 
 **Parameters (JSON Schema per parameter, as serialized to the provider):**
@@ -207,28 +137,26 @@ Never blanket-mark large ranges (e.g. "1-50") — review what each tag holds fir
 ```json
 {
   "drop": {
-    "description": "Tag IDs to drop entirely. Ranges: '3-5', '1,2,9'",
+    "description": "Tag IDs to drop: \"3-5\", \"1,2,9\", \"1-5,8,12-15\".",
     "type": "string"
   }
 }
 ```
 
-### ctx_expand — description ~395 tokens, params ~177 tokens (total ~572)
+### ctx_expand — description ~257 tokens, params ~121 tokens (total ~378)
 
 **Description:**
 
 ```
-Recover the original conversation from your compacted history.
-
-Older parts of this session are summarized under `## start-end · date · title` headings inside <session-history> — e.g. `## 120-245 · … · Fixed tagger collision`. Each heading replaces the raw messages in that ordinal range with a summary. When the summary isn't enough — you need exact wording, a specific value, an error message, or the reasoning behind a decision — expand the range:
+Recover the original conversation behind your compacted history.
 
-ctx_expand(start=120, end=245)  ← the heading's start/end range
+Earlier turns are summarized in <session-history> under `## start-end · date · title` headings; each heading stands for the raw messages in that ordinal range. When the summary isn't enough — exact wording, a value, an error message, the reasoning behind a decision — expand the range: ctx_expand(start=120, end=245). Also works around a ctx_search message hit: start=N-10, end=N+5. Ranges after the last compartment are your live tail — already visible, not expandable.
 
-Returns the raw transcript as [N] U:/A: lines, capped at ~15K tokens; an oversized range returns the head and tells you where to continue. Also works with ordinals from ctx_search message results — expand a window around a hit (e.g. start=N-10, end=N+5). Ranges after the last compartment are your live tail — already visible in context, not expandable.
+Returns the raw transcript as [N] U:/A: lines, capped at ~15K tokens; an oversized range returns the head and says where to continue.
 
-Two recovery modes for finer detail:
-- ctx_expand(start=120, end=245, verbose=true) — lists each message SEPARATELY with its ordinal [N] and a per-part preview (each tool call shown with its output size). Use this to find the exact message or tool call you want, then recover it in full by ordinal.
-- ctx_expand(message=138) — returns the FULL untruncated content of the message at that ordinal: every text part, and every tool call's complete input + output, read from stored history. This is the cheap way to get back a tool output you dropped with ctx_reduce — the original is still in storage even though the wire shows [dropped §N§]. If the message was deleted from history (session prune/revert), it says so.
+Finer recovery:
+- verbose=true lists each message separately with its ordinal and a per-part preview (tool calls with output sizes) so you can pick one.
+- message=N returns that one message in full — every text part and every tool call's complete input and output — from stored history. This is the way back to a tool output you released with ctx_reduce; if the message was deleted from history it says so.
 ```
 
 **Parameters (JSON Schema per parameter, as serialized to the provider):**
@@ -236,45 +164,45 @@ Two recovery modes for finer detail:
 ```json
 {
   "start": {
-    "description": "First message ordinal to expand — a compartment's start=\"N\" attribute, or an ordinal from a ctx_search message hit",
+    "description": "First ordinal of the range — a compartment's start, or an ordinal from a ctx_search hit.",
     "type": "number"
   },
   "end": {
-    "description": "Last message ordinal to expand (inclusive) — a compartment's end=\"M\" attribute",
+    "description": "Last ordinal of the range, inclusive — a compartment's end.",
     "type": "number"
   },
   "verbose": {
-    "description": "With start/end: list each message separately with its ordinal [N] and per-part preview (each tool call shown with its output size), so you can pick one to recover in full by ordinal.",
+    "description": "With start/end: one entry per message with ordinal and per-part preview instead of the transcript.",
     "type": "boolean"
   },
   "message": {
-    "description": "Full untruncated recovery of ONE message by its ordinal (every text part + every tool call's complete input/output). Use an ordinal from a compartment, ctx_search hit, or verbose range. Recovers a tool output you dropped with ctx_reduce.",
+    "description": "Recover ONE message in full by ordinal (all text, all tool inputs and outputs). Use alone, without start/end.",
     "type": "number"
   }
 }
 ```
 
-### ctx_note — description ~387 tokens, params ~359 tokens (total ~746)
+### ctx_note — description ~376 tokens, params ~284 tokens (total ~660)
 
 **Description:**
 
 ```
-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 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: change one note (note_ids=[N]). dismiss: retire 1–50 notes (note_ids=[...]).
-
-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"
-✓ "When the latest release tag is >= v0.22.0"
-✓ "When packages/plugin/src/foo.ts contains a function named bar"
-✗ "When the user mentions X" / "when we revisit Y" / "after we finish this refactor" — no external signal; write a regular note instead.
-
-Example: ctx_note(action="write", content="Re-run the perf benchmark once the boundary rework ships", surface_condition="When the latest release tag is >= v0.23.0")
+Session notes are pending intentions: work you intend to return to, with its findings attached.
+
+Use notes for:
+- A finding to revisit when you return to the intended work
+- A decision with its reasoning, when follow-up work remains
+- A backlog item with evidence already found
+- Something the user explicitly asks you to note
+
+Don't use notes for: the next few steps; a plan you are actively executing; restart/fold insurance; or a record of how things stand (world-state, a design at a point in time) with nothing you intend to do about it — that goes stale silently; a fact worth keeping is memory, the rest is nothing. Use todos for active work. If the detail already lives in a file, record the path and what to inspect — don't copy the file into a note. Durable project facts belong in ctx_memory, not notes.
+
+First line is the title (under 80 chars), followed by detail. Operations:
+- write: save a new note (content required)
+- read: one row per note — `#id · age · title` — ready smart notes first, then newest; rows untouched 30+ days are marked stale. Pass note_ids to read full bodies; limit/offset page; filter selects other statuses.
+- update: change one note (note_ids=[N])
+- dismiss: retire 1–50 notes (note_ids). Dismiss a note when its work lands or is abandoned; a queue you never dismiss from stops being read.
+- surface_condition: make it a smart note — an outside checker periodically tests the condition using only externally verifiable signals (GitHub state, files, git, releases, web), never this conversation or future actions; the note is parked until the condition holds.
 ```
 
 **Parameters (JSON Schema per parameter, as serialized to the provider):**
@@ -282,7 +210,7 @@ Example: ctx_note(action="write", content="Re-run the perf benchmark once the bo
 ```json
 {
   "action": {
-    "description": "Operation to perform. Defaults to 'write' when content is provided, otherwise 'read'.",
+    "description": "write | read | update | dismiss. Defaults to write when content is given, else read.",
     "type": "string",
     "enum": [
       "write",
@@ -292,15 +220,15 @@ Example: ctx_note(action="write", content="Re-run the perf benchmark once the bo
     ]
   },
   "content": {
-    "description": "Note text to store when action is 'write'.",
+    "description": "Note text for write/update: first line is the title (under 80 chars), then the detail.",
     "type": "string"
   },
   "surface_condition": {
-    "description": "Externally verifiable condition for smart notes. A separate background agent (dreamer) checks this using gh CLI, web fetches, file reads, git, etc. — NOT your conversation history. Use only for things like GitHub PR/issue state, release tags, file contents, or workflow runs. DO NOT use for 'when the user mentions X' / 'when we revisit Y' / 'when relevant to current task' — dreamer has no access to session context. For session-relative reminders, omit this and write a regular note.",
+    "description": "Makes this a smart note: a condition an outside checker can verify on its own, periodically — repository state, releases, web pages, anything it can look up — never something only this conversation knows. The note is parked until the condition holds.",
     "type": "string"
   },
   "filter": {
-    "description": "Optional read filter. Defaults to active session notes + ready smart notes. Use 'all' to inspect every status or 'pending' to inspect unsurfaced smart notes.",
+    "description": "Read filter: active (default: active + ready), all, pending (unsurfaced smart notes), ready, dismissed.",
     "type": "string",
     "enum": [
       "all",
@@ -311,15 +239,15 @@ Example: ctx_note(action="write", content="Re-run the perf benchmark once the bo
     ]
   },
   "limit": {
-    "description": "Max notes per section for read, newest first (default: 25)",
+    "description": "Rows per read (default 25).",
     "type": "number"
   },
   "offset": {
-    "description": "Skip this many newest notes for read — page older ones (default: 0)",
+    "description": "Skip this many newest rows (default 0).",
     "type": "number"
   },
   "note_ids": {
-    "description": "Note ids: exactly one for 'update', one to fifty for 'dismiss'. Ignored by 'write' and 'read'.",
+    "description": "Note ids: one for update, 1–50 for dismiss, any number for read (returns full bodies). Ignored by write.",
     "minItems": 1,
     "maxItems": 50,
     "type": "array",
@@ -332,23 +260,22 @@ Example: ctx_note(action="write", content="Re-run the perf benchmark once the bo
 }
 ```
 
-### ctx_memory — description ~234 tokens, params ~216 tokens (total ~450)
+### ctx_memory — description ~278 tokens, params ~190 tokens (total ~468)
 
 **Description:**
 
 ```
-Durable project knowledge shared across every session on this project.
+Durable facts about this project, shared with every agent working on it and kept for the months this work lasts.
 
-Your active memories are already visible in <project-memory> (each with its id), and every future session starts with them — write one when you learn something future sessions must know: a project rule, an architectural fact, a hard-won constraint, a config value, or a naming convention. Keep each memory one standalone fact, phrased to make sense without this session's context.
+Your active memories are already in <project-memory> as `#id: fact` lines. Write one when you learn something that must not have to be found again — a project rule, an architectural fact, a hard-won constraint, a config value, a naming convention — and especially when it cost you turns to find. One standalone fact per memory, phrased to make sense on its own. A pending intention with its evidence ("do X later, here is what we know") is ctx_note, not memory.
 
 Actions:
-- write: save a new memory (content + category).
-- update: rewrite one memory whose fact changed (ids: [one], content).
+- write: new memory (content + category).
+- update: rewrite one memory whose fact changed (ids: [one], content; category optional to recategorize).
 - archive: retire wrong or obsolete memories (ids: [one or more], optional reason).
-- merge: collapse duplicates into one memory (ids: [two or more], content).
-- get: fetch memories by id (ids: [1-20]); readable in every status. `list` remains dreamer-only.
-
-Example: ctx_memory(action="write", category="CONSTRAINTS", content="Pi stores sessions as JSONL under ~/.pi/agent/sessions/, not SQLite")
+- merge: collapse duplicates into one (ids: [two or more], content).
+- get: fetch by id (ids: 1–20), readable in every status.
+Examples: category="CONFIG_VALUES", content="OpenCode source is at ~/Work/OSS/opencode" · category="CONSTRAINTS", content="Dashboard Tauri build needs RGBA PNGs, not grayscale"
 ```
 
 **Parameters (JSON Schema per parameter, as serialized to the provider):**
@@ -356,23 +283,22 @@ Example: ctx_memory(action="write", category="CONSTRAINTS", content="Pi stores s
 ```json
 {
   "action": {
-    "description": "What to do: write, update, archive, merge, get, or list",
+    "description": "write | update | archive | merge | get",
     "type": "string",
     "enum": [
       "write",
-      "archive",
       "update",
+      "archive",
       "merge",
-      "get",
-      "list"
+      "get"
     ]
   },
   "content": {
-    "description": "The memory text — one standalone fact (required for write, update, merge)",
+    "description": "The memory text — one standalone fact (write, update, merge).",
     "type": "string"
   },
   "category": {
-    "description": "What kind of fact this is (required for write; optional on update to recategorize, omitted keeps the current category; optional merge override)",
+    "description": "Kind of fact (required for write; on update/merge optional, omitted keeps the current category).",
     "type": "string",
     "enum": [
       "PROJECT_RULES",
@@ -383,47 +309,44 @@ Example: ctx_memory(action="write", category="CONSTRAINTS", content="Pi stores s
     ]
   },
   "ids": {
-    "description": "Target memory id(s) from <project-memory>: update takes exactly one, archive one or more, merge two or more, get one to twenty",
+    "description": "Memory ids from <project-memory>: one for update, one or more for archive, two or more for merge, 1–20 for get.",
     "type": "array",
     "items": {
       "type": "number"
     }
   },
   "limit": {
-    "description": "Max results for list (default: 10)",
+    "description": "Max results for list (default 10).",
     "type": "number"
   },
   "reason": {
-    "description": "Why the memory is being archived (optional, recommended)",
+    "description": "Why it is being archived (optional).",
     "type": "string"
   }
 }
 ```
 
-### ctx_search — description ~402 tokens, params ~184 tokens (total ~586)
+### ctx_search — description ~322 tokens, params ~132 tokens (total ~454)
 
 **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 and follow-ups with their recorded text.
-
-Picking sources:
-- "when did this change / was this working before" → ["git_commit", "message"]
-- "did we discuss this earlier" → ["message"]
-- "did we decide something about this / leave a follow-up" → ["note"]
-- "what's our convention / rule for X" → ["memory"]
+Search the archive — everything that ever happened in this project, not just what is on your desk.
+
+Retrieval matches meaning and exact words and fuses them, so phrase `query` as a natural-language question that still carries the exact terms you expect in the answer (paths, symbols, config keys, error strings); a bare keyword stack finds less.
+- "where is the opencode source code path?"  (a location you once knew)
+- "why did we choose SQLite over postgres?"  (a decision and its reasons)
+- "how does the dreamer lease work?"  (a mechanism discussed or implemented earlier)
+- Not: "upload client retry backoff config"
+
+Results only contain what you CANNOT currently see — memories already in <project-memory> and the live tail are filtered out. A query that is just memory ids (`#7234`, `12, 34`) resolves them directly.
+
+Sources (omit for all):
+- memory — rules, constraints, conventions; "what's our convention for X"
+- message — the raw conversation behind compacted history; "did we discuss this"; hits carry ordinals for ctx_expand(start=N-10, end=N+5)
+- git_commit — commit history; "when did this change" (pair with message for regression hunts)
+- note — parked follow-ups with their recorded text; "did we leave a follow-up"
+Use from/to to restrict every source to an inclusive UTC date range.
 ```
 
 **Parameters (JSON Schema per parameter, as serialized to the provider):**
@@ -431,15 +354,23 @@ Picking sources:
 ```json
 {
   "query": {
-    "description": "Search query. Matches against memory content, Primers, git commit messages, and raw user/assistant message text.",
+    "description": "A natural-language question carrying the exact terms you expect in the answer.",
     "type": "string"
   },
   "limit": {
-    "description": "Maximum results to return (default: 10)",
+    "description": "Maximum results (default 10).",
     "type": "number"
   },
+  "from": {
+    "description": "Earliest date, YYYY-MM-DD (inclusive).",
+    "type": "string"
+  },
+  "to": {
+    "description": "Latest date, YYYY-MM-DD (inclusive; default open).",
+    "type": "string"
+  },
   "sources": {
-    "description": "Optional. Restrict to specific sources. Examples: [\"primer\"] for standing project explanations, [\"git_commit\"] for \"when did we change X\", [\"memory\"] for naming conventions, [\"message\"] for \"did we discuss this earlier\", [\"note\"] for parked decisions or follow-ups, [\"git_commit\",\"message\"] for regression hunts. Omit for a broad search across all enabled sources; pass [] to search no sources.",
+    "description": "Restrict to these sources; omit for all. [] searches none.",
     "type": "array",
     "items": {
       "type": "string",
@@ -461,9 +392,9 @@ The hash handler persists the MD5 of `output.system.join("\\n")`. The values bel
 
 | Variant | Guidance bytes | MD5 system-prompt hash |
 |---|---:|---|
-| PRIMARY full | 8759 | `f513711009bd420fe07b2672ce30d279` |
-| PRIMARY memory-off | 7718 | `6834a01be9891fa5461e996f281ba63d` |
-| PRIMARY reduce-off | 6526 | `7e5d386d94abe4f101bfd6d891ec183b` |
-| SUBAGENT minimal | 705 | `1c09c70b742f79274c501dd8f7eff1fc` |
+| PRIMARY full | 5025 | `eaed1eda58c1c741546c9094481f4f0a` |
+| PRIMARY memory-off | 4686 | `573866747d9aac2999f616a7885fb77a` |
+| PRIMARY reduce-off | 4078 | `0a969d63dfe7d83f301099610556c418` |
+| SUBAGENT minimal | 1376 | `2f5a0e99b9171fdfa08c7920cb18dc4d` |
 
 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.