open-memex 0.5.1 → 0.6.0-alpha.4

package/dist/tools/ops.js

@@ -15,9 +15,24 @@ import { upsertFromFile, deleteFromIndex } from "../store/sync.js";
 import { findDuplicates, supersede } from "../store/lifecycle.js";
 import { db } from "../store/db.js";
 import { redact } from "../redact.js";
-import { getSyncStatus, formatSyncStatus, submitMemories } from "../submit.js";
+import { getSyncStatus, formatSyncStatus, submitMemories, outboxDraftCount } from "../submit.js";
 import { getPrStatus, formatPrStatus, applyPrStatus } from "../github.js";
 import { proposeMemories, promoteMemory, listConflicts, resolveConflict, formatReviewHistory, } from "../review.js";
+/**
+ * D53: push, don't poll. Append the project-outbox pending count to mutating
+ * tool results so agents learn about drafts waiting for review without a
+ * checkpoint poll. Silent when the outbox is empty. `reviewHint` names the
+ * tool to call (MCP); transports without that tool leave it generic.
+ */
+export async function withOutboxNote(scopeKey, p, reviewHint) {
+    const r = await p;
+    const n = outboxDraftCount(scopeKey);
+    if (n > 0) {
+        const tail = reviewHint ? ` — ${reviewHint}` : " for review";
+        r.output += `\n[open-memex: ${n} draft${n === 1 ? "" : "s"} waiting in the project outbox${tail}]`;
+    }
+    return r;
+}
 /** LLM-facing tool descriptions, shared by the opencode plugin and the MCP server. */
 export const TOOL_DESCRIPTIONS = {
     memory_add: "Save a fact, preference, decision, or note to persistent local memory. Call this PROACTIVELY whenever the user shares something worth remembering across sessions — project conventions, tool choices, personal preferences, decisions made, error fixes and their causes. Do not wait to be asked. Keep each memory to one self-contained statement. Default scope is the current project; use the personal scope for facts about the user that apply across all projects.",

package/docs/V2-DESIGN.md

@@ -546,6 +546,15 @@ requirement: personal data never touches third-party services). Benchmarks to tr
 - **0.5.1 (stable).** `--help` accuracy: `mcp` help states the server exposes 11
   tools (a superset of the opencode plugin's five memory tools); install hints point
   at the stable line instead of `@alpha` (F27).
+- **0.6.0 (in development).** Close the install→init gap (D50): postinstall
+  prints the `open-memex init` pointer (never prompts — CI-safe); bare
+  `open-memex` on a fresh machine offers to run init on a TTY. Close the
+  init→first-use gap (D51): init ends with a one-line next-step hint
+  (`open-memex add` + ask the agent to recall it). Agent-prompt clarity pass
+  (D52): rewrite both agent-facing prompts (MCP handshake + init template) so
+  agents execute them correctly. Push-not-poll outbox (D53): the checkpoint
+  mechanism is retired — the server reports the outbox draft count at session
+  start and appends it to mutating tool results when non-zero.
 - **Phase 4 — Future, signal-gated.** Cloud `RemoteProvider` customization only on: multi-private-repo
   sharing needs, fine-grained ACL, audit/compliance mandates · optional API-backed exporters/providers
   for enterprise knowledge systems.
@@ -975,6 +984,78 @@ requirement: personal data never touches third-party services). Benchmarks to tr
   *Rationale: an empty file is the safest write target, not a corrupt file;
   refusing it sent the user down a manual path for no reason. Triggered by
   Stone's report 2026-09-29.*
+- **D50** — close the install→init gap (0.6.0-alpha.1). `npm install -g`
+  only puts the CLI on PATH; the editor wiring is `init`'s job, and a clean
+  reinstall wipes it — Stone hit exactly this on 2026-09-30 (fresh opencode
+  reinstall + `npm i -g open-memex`, then no open-memex in `opencode.jsonc`).
+  Two changes, both CI-safe: (1) a `postinstall` script that **prints**
+  `Run \`open-memex init\`…` — postinstall must never prompt, it runs in CI /
+  Docker / `npm ci` where stdin isn't a terminal; (2) bare `open-memex` on a
+  machine where init never completed **offers** to run it (default yes) when
+  stdin+stdout are TTYs, otherwise prints usage exactly as before. Asked-state
+  is a `.init.json` marker at the data root — init writes it on success, a
+  declined offer writes it too, so the question is asked once; `uninstall`
+  removes it (unwiring is the reverse of init, so the next bare run offers to
+  wire again). The marker is a dotfile and export builds from DB rows, so it
+  can't leak into bundles. The offer re-execs `open-memex init` as a child
+  with inherited stdio rather than calling init in-process — the offer's own
+  readline already consumed stdin's buffer, and a second readline on the same
+  stream would see EOF on burst input (verified with a pty test).
+  *Rationale: install ≠ setup, and the gap only shows up on a fresh machine —
+  exactly when the user has the least context. A printed hint covers the
+  install moment; the interactive offer covers the first-run moment; neither
+  can hang a pipeline. Approved 2026-09-30.*
+- **D51** — close the init→first-use gap (0.6.0-alpha.2). D50 gets the user to
+  a wired editor; a first-time user then stops at "it's wired" with no idea
+  what to do next. `init` now ends with one concrete next step:
+  ``Next step: `open-memex add "standup is at 9:30"` — then ask your agent what
+  it remembers.`` One line, printed unconditionally — the cheapest possible
+  onboarding after wiring. *Rationale: the CLI is editor-independent, so the
+  hint works no matter which client was wired; `add` + recall is the smallest
+  loop that proves the whole system works. Approved 2026-09-30.*
+
+- **D52** — agent-prompt clarity rewrite (0.6.0-alpha.3). Both agent-facing
+  prompts (MCP `initialize` instructions in `src/mcp.ts`, init instruction
+  template in `src/init.ts`) are rewritten to fix ambiguities found on review:
+  (1) the proactive-save vs approval-gate contradiction is resolved by naming
+  the two cases — facts the user *states* are saved proactively, conclusions
+  the agent *infers* are proposed first and saved only on approval;
+  (2) `memory_status`/`memory_search` are excluded from the "after any
+  memory_* action" checkpoint trigger (self-trigger loop);
+  (3) tool names use the full `memory_*` form in both prompts;
+  (4) the four checkpoints are defined once as "Checkpoints" and referenced,
+  with an operational heuristic ("a task the user would describe in one
+  sentence") replacing "meaningful chunk of work";
+  (5) empty outbox → do nothing; "the user commits" → "any git commit in this
+  session"; `type "reference"` named explicitly; PR-base mechanics spelled out
+  per D28. *Rationale: these prompts are the product's UI for agents — a
+  literal-minded agent must execute them correctly without guessing.
+  Approved 2026-10-01.*
+
+- **D53** — push-not-poll outbox: the checkpoint mechanism is retired; code
+  pushes state to the agent instead (0.6.0-alpha.4). `src/submit.ts` gains
+  `outboxDraftCount()` (one indexed SQLite COUNT on the current scope's outbox,
+  no git I/O); `src/tools/ops.ts` gains `withOutboxNote()`, which appends
+  `[open-memex: N draft(s) waiting in the project outbox — call memory_status
+  to review]` to mutating tool results, only when N > 0. It is wired into the
+  five MCP mutating tools (`memory_add`, `memory_supersede`, `memory_forget`,
+  `memory_submit`, `memory_propose`) and the three opencode-plugin mutating
+  tools (`memory_add`, `memory_supersede`, `memory_forget` — there the note
+  stays generic because the plugin has no `memory_status`). The MCP server
+  also appends the live draft count to the `initialize` instructions when N >
+  0 (stdio servers start fresh per session, so construction-time state is
+  session-start state). Both agent-facing prompts drop the Checkpoints section
+  and the post-`memory_submit`/`memory_propose` status checks; the sync rule
+  becomes one line ("when the server reports drafts waiting, call
+  `memory_status`") plus the existing "sync memory" trigger. The static init
+  template keeps one explicit session-start `memory_status` call, since a
+  static file cannot carry live state. An anti-nag clause is added: if the
+  agent already asked about these drafts this session, it does not ask again.
+  *Rationale: the server knows the outbox state; making the agent poll for it
+  on a timer wastes tool calls and teaches a habit that scales badly. The note
+  is silent when the outbox is empty, so the common case costs nothing.
+  `memory_submit` drains the outbox, so its own note is naturally silent.
+  Approved 2026-10-01.*
 
 ## Open Questions
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "open-memex",
-  "version": "0.5.1",
+  "version": "0.6.0-alpha.4",
   "description": "Local-first memory layer and protocol for AI coding agents. Markdown source of truth, SQLite FTS5 index, zero cloud.",
   "type": "module",
   "license": "Apache-2.0",
@@ -18,7 +18,8 @@
     "cli": "node --experimental-strip-types src/cli.ts",
     "mcp": "node --experimental-strip-types src/mcp.ts",
     "build": "tsc -p tsconfig.build.json",
-    "prepublishOnly": "npm run build"
+    "prepublishOnly": "npm run build",
+    "postinstall": "node scripts/postinstall.js"
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.30.1",

package/scripts/postinstall.js

@@ -0,0 +1,9 @@
+#!/usr/bin/env node
+// D50: `npm install -g open-memex` only puts the CLI on PATH — the editor
+// wiring is `init`'s job. postinstall must never prompt (it runs in CI,
+// Docker builds and `npm ci` where stdin isn't a terminal), so this only
+// prints the pointer. Plain JS, no dependencies.
+console.log(
+  "\nopen-memex installed. Run `open-memex init` to wire it into your editors — " +
+    "it auto-detects VS Code, Cursor and opencode.\n",
+);

package/src/cli.ts

@@ -556,7 +556,28 @@ function printMcpConfig(client: string): never {
 
 async function main() {
   const [cmd, ...rest] = process.argv.slice(2);
-  if (!cmd || cmd === "--help" || cmd === "-h" || cmd === "help") usage(0);
+  if (!cmd) {
+    // D50: fresh machine + interactive terminal → offer init instead of bare usage.
+    // Non-interactive (CI/scripts/pipes) prints usage exactly as before.
+    const { offerFirstRunInit } = await import("./first-run.ts");
+    const outcome = await offerFirstRunInit(async () => {
+      // Re-exec `open-memex init` as a child with inherited stdio instead of
+      // calling initProject() in-process: the offer's readline already
+      // consumed stdin's buffer, and a second readline on the same stream
+      // would see EOF on burst input instead of the user's next answers.
+      const { spawnSync } = await import("node:child_process");
+      const r = spawnSync(
+        process.execPath,
+        [...process.execArgv, fileURLToPath(import.meta.url), "init"],
+        { stdio: "inherit" },
+      );
+      if (r.error) throw r.error;
+      if ((r.status ?? 1) !== 0) process.exit(r.status ?? 1);
+    });
+    if (outcome !== "initialized") usage(0);
+    return;
+  }
+  if (cmd === "--help" || cmd === "-h" || cmd === "help") usage(0);
 
   if (cmd === "--version" || cmd === "-v") {
     // package.json sits two levels above this file in both layouts

package/src/distill-agents.ts

@@ -68,12 +68,13 @@ export function distillAgentsMarkdown(opts: DistillAgentsOptions): string {
   }
   // D43 — §3.5 memory-hygiene footer (double insurance for opencode users,
   // who never see the MCP handshake / init instructions): teach the agent
-  // reading this AGENTS.md to propose distilled captures at checkpoints.
+  // reading this AGENTS.md to propose distilled captures when a task ends
+  // (D53: the checkpoint mechanism is gone).
   lines.push(`### Memory hygiene (open-memex)`);
   lines.push(``);
   lines.push(
-    `- At checkpoints (session start, end of a work chunk, after the user commits),`,
-    `  distill the session: propose 1–3 short memories capturing the useful`,
+    `- When you finish a task the user would describe in one sentence, distill`,
+    `  the session: propose 1–3 short memories capturing the useful`,
     `  conclusion — what was learned or decided, how an issue was resolved, what`,
     `  to avoid, where the authoritative doc lives — not the raw transcript.`,
     `  Save nothing without user approval.`,

package/src/first-run.ts

@@ -0,0 +1,96 @@
+/**
+ * D50: first-run init offer. `npm install -g open-memex` only puts the CLI on
+ * PATH — the editor wiring is `init`'s job, and a clean reinstall wipes it.
+ * When bare `open-memex` runs on a machine where init never completed, offer
+ * to run it instead of just printing usage.
+ *
+ * The "asked" state is a marker file at the data root (`init` writes it on
+ * success, a declined offer writes it too), so the question is asked exactly
+ * once. `uninstall` removes it — unwiring is the reverse of init, so the next
+ * bare run offers to wire again. The marker is a dotfile: export builds from
+ * DB rows, never by walking the data root, so it can't leak into bundles.
+ */
+import fs from "node:fs";
+import path from "node:path";
+import readline from "node:readline";
+import { dataRootPath } from "./paths.ts";
+
+const MARKER = ".init.json";
+
+export type FirstRunState = "initialized" | "declined";
+
+export function firstRunMarkerPath(root: string = dataRootPath()): string {
+  return path.join(root, MARKER);
+}
+
+/** True when init has neither run nor been declined on this machine. */
+export function isFirstRun(root?: string): boolean {
+  return !fs.existsSync(firstRunMarkerPath(root ?? dataRootPath()));
+}
+
+/** Record the outcome — best effort; a missing marker just asks again next time. */
+export function markFirstRunDone(state: FirstRunState): void {
+  const file = firstRunMarkerPath();
+  try {
+    fs.mkdirSync(path.dirname(file), { recursive: true });
+    fs.writeFileSync(file, JSON.stringify({ v: 1, state, at: new Date().toISOString() }) + "\n");
+  } catch {
+    /* ignore */
+  }
+}
+
+export function clearFirstRunMarker(): void {
+  try {
+    fs.rmSync(firstRunMarkerPath(), { force: true });
+  } catch {
+    /* ignore */
+  }
+}
+
+export interface TtyProbe {
+  stdinTTY: boolean | undefined;
+  stdoutTTY: boolean | undefined;
+}
+
+/** Pure decision, kept separate for tests: prompt only on an interactive
+ *  terminal — scripts, CI and piped runs never get the question. */
+export function shouldOfferFirstRun(
+  tty: TtyProbe = { stdinTTY: process.stdin.isTTY, stdoutTTY: process.stdout.isTTY },
+  firstRun: boolean = isFirstRun(),
+): boolean {
+  return firstRun && !!tty.stdinTTY && !!tty.stdoutTTY;
+}
+
+function askYesNo(question: string): Promise<boolean> {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise((resolve) => {
+    rl.question(question, (ans) => {
+      rl.close();
+      resolve(!/^\s*(n|no)\s*$/i.test(ans));
+    });
+  });
+}
+
+export type FirstRunOutcome = "initialized" | "declined" | "skipped";
+
+/**
+ * Bare-`open-memex` first-run flow. `runInit` is injected so tests don't need
+ * the real init. Returns "skipped" when there's nothing to ask (already set
+ * up, or non-interactive) — the caller then prints usage as before.
+ */
+export async function offerFirstRunInit(
+  runInit: () => Promise<void>,
+): Promise<FirstRunOutcome> {
+  if (!shouldOfferFirstRun()) return "skipped";
+  console.log(
+    `It looks like open-memex hasn't been set up on this machine yet.\n` +
+      "`open-memex init` wires it into your editors (auto-detects VS Code, Cursor and opencode).\n",
+  );
+  if (await askYesNo("Run it now? [Y/n] ")) {
+    await runInit();
+    return "initialized";
+  }
+  markFirstRunDone("declined");
+  console.log("No problem — run `open-memex init` any time.");
+  return "declined";
+}

package/src/init.ts

@@ -7,6 +7,7 @@ import { createInterface } from "node:readline/promises";
 import { pathToFileURL, fileURLToPath } from "node:url";
 import { DEFAULT_CONFIG, saveConfig } from "./config.ts";
 import { projectRoot } from "./paths.ts";
+import { markFirstRunDone, clearFirstRunMarker } from "./first-run.ts";
 
 const MARKER = "<!-- open-memex -->";
 
@@ -51,54 +52,70 @@ const INSTRUCTIONS = `${MARKER}
 > Applies only when the \`open-memex\` MCP server is available in this session
 > (the \`memory_*\` tools exist). Otherwise ignore this section.
 
-You have a local memory MCP server (\`open-memex\`) with eleven tools:
-\`memory_add\`, \`memory_search\`, \`memory_list\`, \`memory_supersede\`, \`memory_forget\`,
-\`memory_status\`, \`memory_submit\`, \`memory_propose\`, \`memory_promote\`, \`memory_resolve\`,
-\`memory_pr_status\`.
-
-- BE PROACTIVE. When the user shares something worth remembering across sessions
-  (a decision, a preference, a project convention, a fix and its cause), call
-  \`memory_add\` without being asked. Keep each memory to one self-contained statement.
-- At checkpoints (session start, end of a work chunk, after the user commits, after
-  any memory_* action), DISTILL the session: propose 1–3 short memories capturing the
-  useful conclusion — what was learned or decided, how an issue was resolved, what to
-  avoid, where the authoritative doc lives — not the raw transcript. Save NOTHING the
-  user did not approve; on approval call \`memory_add\` with source "inference" at the
-  confirmed scope. If the knowledge already lives in project docs, save a \`reference\`
-  memory pointing at the doc instead of copying it. Long-form notes are fine ONLY when
-  the user explicitly asks to save one.
-- Before asking the user about past decisions, conventions, or preferences they may
-  have told you before, call \`memory_search\` first — try a few keyword variants
-  (including the user's own language) when the first search comes up empty.
-- Memories default to this project's scope; use the \`personal\` scope for facts about
-  the user that hold across all projects. When a saved fact becomes outdated, call
-  \`memory_supersede\` instead of adding a duplicate.
+You have a local memory MCP server (\`open-memex\`). Its tools are
+\`memory_add\`, \`memory_search\`, \`memory_list\`, \`memory_supersede\`,
+\`memory_forget\`, \`memory_status\`, \`memory_submit\`, \`memory_propose\`,
+\`memory_promote\`, \`memory_resolve\`, \`memory_pr_status\` — always call them by
+these full names.
+
+- The server tells you when project outbox drafts are waiting for review — in
+  tool results. At session start, call \`memory_status\` once to check. When
+  drafts are waiting, summarize them (one line each) and ask the user which
+  ones to sync into the repo; sync NOTHING the user did not name. If you
+  already asked about these drafts this session, don't ask again. When the
+  server reports none waiting, do nothing.
+- BE PROACTIVE about facts the user states directly: when the user shares a
+  decision, preference, project convention, or fix-and-cause worth remembering
+  across sessions, call \`memory_add\` without being asked. Keep each memory to
+  one self-contained statement, and add a brief "(noted in memory)" so the
+  user sees it worked.
+- For conclusions YOU infer (the user never stated them): when you finish a
+  task the user would describe in one sentence, consider distilling the
+  session — if there is something worth keeping,
+  propose 1–3 short memories capturing the useful conclusion (what was learned
+  or decided, how an issue was resolved, what to avoid, where the authoritative
+  doc lives — not the raw transcript), each with its proposed scope. Save
+  NOTHING the user did not approve; on approval call \`memory_add\` with source
+  "inference" at the approved scope. If the knowledge already lives in project
+  docs, save it as type "reference" pointing at the doc instead of copying it.
+  Long-form notes are fine ONLY when the user explicitly asks to save one.
+- Before asking the user about past decisions, conventions, or preferences
+  they may have told you before, call \`memory_search\` first — try a few
+  keyword variants (including the user's own language) when the first search
+  comes up empty.
+- Memories default to this project's scope; use the \`personal\` scope for facts
+  about the user that hold across all projects. When a saved fact becomes
+  outdated, call \`memory_supersede\` (find the old memory's id with
+  \`memory_search\` first) instead of adding a duplicate.
 
 ## Syncing project memories for review (D26)
 
-Project memories you save land in a local outbox first — they are NOT in git yet.
-Syncing them into the repo for review is an explicit, user-approved step:
-
-- At session start, when you finish a meaningful chunk of work, after the user
-  commits (git commit), and after any memory_* action completes, call
-  \`memory_status\`. If the outbox has drafts, summarize them (one line each) and ask
-  the user which ones to sync. Sync NOTHING the user did not name.
-- When the user says "sync memory" (or "同步记忆"), treat it as a request to run
-  the sync flow above: call \`memory_status\`, summarize the outbox drafts, and ask
-  which ones to sync.
-- When the user approves, call \`memory_submit\` with the approved ids. It copies
-  the drafts into the repo as \`proposed\`, commits locally on the CURRENT branch,
-  and prints the push + PR commands. It NEVER creates a branch on its own.
+Project memories you save land in a local outbox first — they are NOT in git
+yet. Syncing them into the repo for review is an explicit, user-approved step:
+
+- When the server reports drafts waiting for review, call \`memory_status\` to
+  see them. Summarize the drafts (one line each) and ask the user which ones
+  to sync. Sync NOTHING the user did not name.
+- When the user says "sync memory" (or "同步记忆"), run the sync
+  flow above: call \`memory_status\`, summarize the outbox drafts, and ask which
+  ones to sync. ALWAYS use the \`memory_status\` tool for this — never browse
+  the memory data directory directly.
+- When the user approves, call \`memory_submit\` with the approved ids. It
+  copies the drafts into the current project's \`.ai/open-memex/\` directory as
+  \`proposed\` and commits locally on the CURRENT branch. It NEVER creates a
+  branch on its own.
 - After the submit, ask ONE follow-up: "want me to create a branch + push +
-  open the PR, or will you handle it yourself?" A "yes, you do it" answer covers
-  the whole chain — branch creation, push, PR creation — do NOT re-ask at each
-  step. If the user says they will do it themselves, hand them the printed
-  push/PR commands and do nothing. NEVER create branches, push, or open PRs
-  without their explicit approval.
-- Base branch for the memory PR defaults to the branch you are on; the user may
-  redirect it to the integration branch (main) for branch-independent knowledge.
-- If anything conflicts (same id with different content, push rejected), STOP and
-  let the user judge — never overwrite.
+  open the PR, or will you handle it yourself?" A "yes, you do it" answer
+  covers the whole chain — branch creation, push, PR creation — do NOT re-ask
+  at each step. If the user says they will do it themselves, hand them the
+  printed push/PR commands and do nothing. NEVER create branches, push, or open
+  PRs without their explicit approval.
+- If the user wants the memories reviewed on a separate branch, create the
+  branch first (the commit comes along), then push and open the PR. The PR base
+  defaults to the branch submit ran on; \`--base\` overrides it (e.g. \`main\` for
+  branch-independent knowledge).
+- If anything conflicts (same id with different content, push rejected), STOP
+  and let the user judge — never overwrite.
 - After the PR merges, call \`memory_pr_status\` (with \`apply\` when the user
   approves) to map the PR's review state back onto each memory — merged means
   \`published\`, an approval means \`approved\` (credited to the reviewer).
@@ -720,6 +737,11 @@ export async function initProject(opts: {
     writeInstructions(root, scope, clients.find((c) => c !== "opencode")!);
   }
   console.log(`\nDone. Reload your editor window to start the open-memex MCP server.`);
+  // D51: close the init→first-use gap — one concrete next step so a new user
+  // sees what "it works" looks like instead of stopping at "it's wired".
+  console.log(`  Next step: \`open-memex add "standup is at 9:30"\` — then ask your agent what it remembers.`);
+  // D50: init completed — the bare-`open-memex` first-run offer won't ask again.
+  markFirstRunDone("initialized");
 }
 
 // ---------------------------------------------------------------------------
@@ -909,4 +931,7 @@ export async function uninstallProject(opts: {
       : "\nDone. Nothing to remove — no open-memex wiring found.",
   );
   console.log("Your memories are untouched (uninstall never deletes data).");
+  // D50: unwiring is the reverse of init — drop the first-run marker so the
+  // next bare `open-memex` offers to wire again.
+  if (changed > 0) clearFirstRunMarker();
 }

package/src/mcp.ts

@@ -52,8 +52,10 @@ import {
   memoryResolveArgs,
   memoryPrStatusArgs,
   TOOL_DESCRIPTIONS,
+  withOutboxNote,
   type ToolResult,
 } from "./tools/ops.ts";
+import { outboxDraftCount } from "./submit.ts";
 
 // Server version tracks package.json — never hardcode it here again.
 // package.json sits two levels above this file in both layouts
@@ -75,40 +77,49 @@ const SERVER_VERSION: string = (() => {
  * client at connect time. Still advisory — no MCP consumer offers a hard
  * session-start hook — but it is the strongest signal available.
  */
-const SERVER_INSTRUCTIONS = `You are connected to an open-memex local memory MCP server
-(eleven memory_* tools: add, search, list, supersede, forget, status, submit,
-propose, promote, resolve, pr_status).
+const SERVER_INSTRUCTIONS = `You are connected to an open-memex local memory MCP server.
+Its tools are memory_add, memory_search, memory_list, memory_supersede,
+memory_forget, memory_status, memory_submit, memory_propose, memory_promote,
+memory_resolve, memory_pr_status — always call them by these full names.
 
-- At the START of this session, when you finish a meaningful chunk of work,
-  after the user commits (git commit), and after any memory_* action completes,
-  call memory_status. If the project outbox has drafts waiting for review,
+- The server tells you when project outbox drafts are waiting for review —
+  in tool results, and in these session-start instructions. When it does,
   summarize them (one line each) and ask the user which ones to sync into the
-  repo. Sync NOTHING the user did not name.
-- When the user says "sync memory" (or "同步记忆"), treat it as a request to run
-  the sync flow: call memory_status, summarize the outbox drafts, and ask which
-  ones to sync. ALWAYS use the memory_status tool for this — never browse the
-  appdata directory directly.
+  repo; sync NOTHING the user did not name. If you already asked about these
+  drafts this session, don't ask again. When the server reports none waiting,
+  do nothing.
+- When the user says "sync memory" (or "同步记忆"), call memory_status,
+  summarize the outbox drafts (one line each), and ask which ones to sync.
+  ALWAYS use the memory_status tool for this — never browse the memory data
+  directory directly.
 - After memory_submit, ask ONE follow-up: "want me to create a branch + push +
   open the PR, or will you handle it yourself?" NEVER create branches, push, or
   open PRs without the user's explicit approval. A "yes, you do it" covers the
   whole chain — do NOT re-ask at each step.
-- BE PROACTIVE: when the user shares something worth remembering across sessions
-  (a decision, a preference, a project convention, a fix and its cause), call
-  memory_add without being asked. Keep each memory to one self-contained statement.
-- At the same checkpoints (session start, end of a work chunk, after the user
-  commits, after any memory_* action), DISTILL the session: propose 1–3 short
-  memories capturing the useful conclusion — what was learned or decided, how an
-  issue was resolved, what to avoid, where the authoritative doc lives — not the
-  raw transcript. Save NOTHING the user did not approve; on approval call
-  memory_add with source "inference" at the confirmed scope. If the knowledge
-  already lives in project docs, save a \`reference\` memory pointing at the doc
-  instead of copying it. Long-form notes are fine ONLY when the user explicitly
-  asks to save one.
+- BE PROACTIVE about facts the user states directly: when the user shares a
+  decision, preference, project convention, or fix-and-cause worth remembering
+  across sessions, call memory_add without being asked. Keep each memory to one
+  self-contained statement, and add a brief "(noted in memory)" so the user
+  sees it worked.
+- For conclusions YOU infer (the user never stated them): when you finish a
+  task the user would describe in one sentence, consider distilling the
+  session — if there is something worth keeping,
+  propose 1–3 short memories capturing the useful conclusion (what was learned
+  or decided, how an issue was resolved, what to avoid, where the authoritative
+  doc lives — not the raw transcript), each with its proposed scope. Save
+  NOTHING the user did not approve; on approval call memory_add with source
+  "inference" at the approved scope. If the knowledge already lives in project
+  docs, save it as type "reference" pointing at the doc instead of copying it.
+  Long-form notes are fine ONLY when the user explicitly asks to save one.
 - Before asking the user about past decisions, conventions, or preferences they
-  may have told you before, call memory_search first.
+  may have told you before, call memory_search first — try a few keyword
+  variants (including the user's own language) when the first search comes up
+  empty.
 - Memories default to this project's scope; use the personal scope for facts
-  about the user that hold across all projects.
-- personal scope memories NEVER leave this machine.`;
+  about the user that hold across all projects. When a saved fact becomes
+  outdated, call memory_supersede (find the old memory's id with memory_search
+  first) instead of adding a duplicate.
+`;
 
 /** Adapt a framework-agnostic op result to an MCP tool response. */
 function toMcp(p: Promise<ToolResult>) {
@@ -164,9 +175,17 @@ export async function runMcpServer() {
     };
   };
 
+  // D53: session-start outbox state, pushed. The stdio server starts fresh per
+  // session, so construction-time state ≈ session-start state.
+  const n = outboxDraftCount(scope.key);
+  const instructions =
+    n > 0
+      ? `${SERVER_INSTRUCTIONS}\n\nSession start: the project outbox has ${n} draft${n === 1 ? "" : "s"} waiting for review — call memory_status to see them.`
+      : SERVER_INSTRUCTIONS;
+
   const server = new McpServer(
     { name: "open-memex", version: SERVER_VERSION },
-    { instructions: SERVER_INSTRUCTIONS },
+    { instructions },
   );
 
   server.registerTool(
@@ -175,7 +194,7 @@ export async function runMcpServer() {
       description: TOOL_DESCRIPTIONS.memory_add,
       inputSchema: z.object(memoryAddArgs),
     },
-    withSync((args) => toMcp(addMemory(getScope, cfg, args))),
+    withSync((args) => toMcp(withOutboxNote(getScope().key, addMemory(getScope, cfg, args), "call memory_status to review"))),
   );
 
   server.registerTool(
@@ -204,7 +223,7 @@ export async function runMcpServer() {
       description: TOOL_DESCRIPTIONS.memory_supersede,
       inputSchema: z.object(memorySupersedeArgs),
     },
-    withSync((args) => toMcp(supersedeMemory(cfg, args))),
+    withSync((args) => toMcp(withOutboxNote(getScope().key, supersedeMemory(cfg, args), "call memory_status to review"))),
   );
 
   server.registerTool(
@@ -214,7 +233,7 @@ export async function runMcpServer() {
       inputSchema: z.object(memoryForgetArgs),
       annotations: { destructiveHint: true },
     },
-    withSync((args) => toMcp(forgetMemory(args))),
+    withSync((args) => toMcp(withOutboxNote(getScope().key, forgetMemory(args), "call memory_status to review"))),
   );
 
   server.registerTool(
@@ -233,7 +252,7 @@ export async function runMcpServer() {
       description: TOOL_DESCRIPTIONS.memory_submit,
       inputSchema: z.object(memorySubmitArgs),
     },
-    withSync((args) => toMcp(submitMemoriesOp(args))),
+    withSync((args) => toMcp(withOutboxNote(getScope().key, submitMemoriesOp(args), "call memory_status to review"))),
   );
 
   server.registerTool(
@@ -242,7 +261,7 @@ export async function runMcpServer() {
       description: TOOL_DESCRIPTIONS.memory_propose,
       inputSchema: z.object(memoryProposeArgs),
     },
-    withSync((args) => toMcp(proposeMemoriesOp(args))),
+    withSync((args) => toMcp(withOutboxNote(getScope().key, proposeMemoriesOp(args), "call memory_status to review"))),
   );
 
   server.registerTool(

package/src/paths.ts

@@ -21,6 +21,15 @@ export interface Paths {
 
 let _cached: Paths | null = null;
 
+/**
+ * Read-only data-root path — never creates the directory. For existence
+ * checks (D50 first-run detection) that must not pollute storage; contrast
+ * `paths()`, which mkdirs as a side effect.
+ */
+export function dataRootPath(): string {
+  return dataRoot();
+}
+
 export function paths(): Paths {
   if (_cached) return _cached;
   const root = dataRoot();