@rubytech/create-maxy-code 0.1.158 → 0.1.159

package/payload/platform/plugins/email/references/email-reference.md

@@ -54,7 +54,7 @@ The tool accepts the `messageId` of the email being replied to (visible in `emai
 - **Reply to sender:** Default behaviour — replies to the original sender only.
 - **Reply all:** Set `replyAll: true` to include all original recipients (TO + CC). The agent's own address is automatically excluded from the recipient list.
 - **Threading:** The reply appears in the same conversation thread in Gmail, Apple Mail, Outlook, and other RFC 2822-compliant clients.
-- **Prerequisite:** The original email must exist in the graph (stored by the background polling job). If the email hasn't been fetched yet, the tool returns a clear error.
+- **Prerequisite:** The original email must exist in the graph (ingested via the operator-initiated `email-ingest` flow). If the message hasn't been ingested yet, the tool returns a clear error.
 
 Use `email-reply` when responding to a received email. Use `email-send` for new outbound messages.
 
@@ -71,26 +71,28 @@ When `agentAddress` is not set or matches the auth email, all tools behave as be
 
 ## Email Persistence
 
-Emails are fetched from IMAP and stored as `Email` nodes in the graph. The fetcher binary lives at `email/mcp/dist/scripts/email-fetch.js`. It is **not currently scheduled on any install** — migration to Desktop scheduled tasks (the canonical dispatch surface, see `maxy-code-prd.md` §Scheduled tasks) is tracked separately. Until that landing, new email is only ingested when an operator invokes the fetcher manually.
+Emails enter the graph as `:KnowledgeDocument {source:'email'}` thread documents via the **operator-initiated ingestion flow** (see `skills/email-ingest/SKILL.md`). There is no background poll, cron, or auto-classifier — new messages are written only when the operator says "check my emails" and approves each one.
 
-- **Polling:** After `email-setup` completes, the platform polls IMAP at the configured interval (default: every 5 minutes). Only emails addressed TO the agent's `agentAddress` are stored.
-- **Deduplication:** Each email is identified by its Message-ID header. Re-polling the same messages does not create duplicates, even if the agent's email address changes between poll cycles. A composite unique constraint on `(messageId, accountId)` provides database-level enforcement.
-- **Semantic search:** Stored emails are vector-indexed (subject + body preview), enabling natural-language search over email history via `email-graph-query`.
-- **Isolation:** Each agent sees only emails addressed to its own bound email address, even when sharing a catchall mailbox.
+The two ingestion tools:
 
-## Email Threading
+- **`email-fetch`** — lists new IMAP messages since the stored high-water mark (`lastFetchedUid` on the `:EmailAccount` node). Returns sender, subject, date, Message-ID, UID, and a body preview. Writes nothing to the graph; stages the batch in-memory for the follow-up `email-ingest` call.
+- **`email-ingest`** — takes a `decisions` array (`messageId` + `ingest` or `discard` per message). Writes only the `ingest` subset to the graph, advances `lastFetchedUid` to the batch's max UID, and consumes the staged batch. Refuses if any pending Message-ID lacks a decision.
 
-Emails are linked into conversation threads via `REPLY_TO` graph edges. When an email has an `In-Reply-To` header, the platform looks up the parent email by `Message-ID` within the same account and creates an edge. Thread linking happens as part of each fetch run (which is operator-invoked until the dispatcher is wired — see above).
+Properties of the persistence layer:
 
-- **Out-of-order delivery:** If a reply arrives before its parent, the edge is created later when the parent is stored (orphan back-fill).
-- **Thread context:** `email-read` and `email-search` include `Thread-Depth` (number of hops to the thread root) and `Thread-ID` (emailId of the root message) for any email that is part of a thread. Root emails (no parent) have no thread fields.
-- **Scope:** Thread edges never cross account boundaries — parent lookups are always scoped to the same account.
+- **Operator-initiated only.** No `setInterval`, cron, or systemd timer ever invokes `email-fetch`. The operator drives every cycle.
+- **Deduplication:** Each message is identified by Message-ID. Re-ingesting the same message MERGEs without duplicating; a composite unique constraint on `(messageId, accountId)` provides database-level enforcement.
+- **Alias filtering:** Only emails addressed TO the agent's `agentAddress` are listed and ingested.
+- **Semantic search:** Ingested threads are vector-indexed (subject + body preview), enabling natural-language search via `email-graph-query`.
+- **Isolation:** Each agent sees only emails addressed to its own bound email address, even when sharing a catchall mailbox.
 
-## Auto-Respond Audit Trail
+## Email Threading
 
-When auto-respond sends a reply, the outbound message is stored as an `Email` node with `direction: "outbound"` and a `REPLY_TO` edge to the original inbound email. This creates a queryable audit trail of every automated reply — what the agent said, when, and to whom.
+Ingested messages are linked into conversation threads as one `:KnowledgeDocument {source:'email'}` per thread, with `:Person` `FROM`/`TO`/`CC` edges. Threading is resolved by `In-Reply-To`/`References` headers at ingest time.
 
-Outbound email nodes have the same properties as inbound emails (subject, bodyPreview, fromAddress, toAddresses, timestamps) plus the `direction` property. They appear in thread traversals alongside inbound messages.
+- **Out-of-order arrival:** If a reply is ingested before its parent, the reply lives in its own thread until the parent is ingested, at which point future ingests fold them together via the shared root.
+- **Thread context:** `email-read` and `email-search` include `Thread-Depth` (number of hops to the thread root) and `Thread-ID` (emailId of the root message) for any message already in the graph. Root emails (no parent) have no thread fields.
+- **Scope:** Thread linkage never crosses account boundaries — parent lookups are always scoped to the same `accountId`.
 
 ### Agent-Email Binding
 
@@ -112,31 +114,9 @@ When the user asks about stored emails, email history, or email recall — use `
 
 ## Inbound Email Screening
 
-Every inbound email is classified by Claude Haiku before entering Neo4j. The classifier examines `fromAddress`, `fromName`, `subject`, and the first 1024 characters of `bodyPreview`.
-
-### Verdicts
-
-| Verdict | Stored? | Embedding? | Auto-respond? | Graph query? |
-|---------|---------|------------|---------------|--------------|
-| `clean` | Yes | Yes | Yes | Yes |
-| `suspicious` | Yes (with `screeningReason`) | Yes | No | Yes |
-| `discarded` | Yes (with `screeningReason`) | No | No | No (list mode) |
-
-- **clean** — legitimate personal or business correspondence
-- **suspicious** — phishing indicators (urgency + credential requests, mismatched sender), prompt injection patterns, or classification failure (safe default)
-- **discarded** — obvious spam, marketing bulk mail, auto-generated notifications with no actionable content
-
-### Prompt injection flag
+There is no automated screener. The operator screens by eye during the `email-ingest` skill flow: `email-fetch` lists the new messages with sender, subject, and a body preview; the operator picks which ones to ingest and which to discard. A `screening` property of `clean` is stamped on every operator-approved row as a provenance marker (operator-approved), and discarded messages never enter the graph.
 
-When `promptInjectionFlag` is true (body contains instruction-like patterns targeting an AI agent), auto-respond skips the email entirely regardless of verdict. No reply is generated. The email is visible in Neo4j for admin review.
-
-### Failure handling
-
-If the Haiku API is unavailable (network, rate limit, auth failure), the email defaults to `suspicious`. The entire fetch batch is never blocked — each email is classified independently. API key absence causes all emails in the batch to default to `suspicious`.
-
-### Logs
-
-Classification verdicts are logged to `{accountDir}/logs/email-fetch.log` with per-email detail (fromAddress, verdict, reason, promptInjectionRisk) and batch summaries.
+The previous Haiku classifier was removed in Task 424; the auto-respond binary that depended on it was removed alongside the screener. Both are intentionally absent — the doctrine is that every LLM-bearing pipeline is operator-initiated.
 
 ## Security
 
@@ -144,51 +124,7 @@ Classification verdicts are logged to `{accountDir}/logs/email-fetch.log` with p
 - IMAP and SMTP connections require TLS or STARTTLS — plaintext is rejected
 - Only the agent's own dedicated account is accessed — never the user's personal email
 - Email nodes have `scope: "admin"` — never visible to public agents
-- Inbound emails are classified by Haiku before storage — prompt injection and phishing are flagged
-
-## Auto-Respond
-
-When enabled, a public agent replies to incoming emails. The auto-respond binary lives at `email/mcp/dist/scripts/email-auto-respond.js` and, like the fetcher, is **not currently scheduled on any install** — see `maxy-code-prd.md` §Scheduled tasks for the canonical dispatch destination. Until that landing, auto-respond only runs when an operator invokes the script manually.
-
-### Setup
-
-To enable auto-respond, call `email-auto-respond-config` with `enabled: true`. The tool requires an `agentSlug`. When called without a slug, the tool returns available public agents — present these as a numbered list in plain chat so the admin can choose which agent handles responses, then call the tool again with the selected slug.
-
-### Configuration
-
-- `enabled` — `true` to enable, `false` to disable
-- `agentSlug` — slug of the public agent that responds (required when enabling)
-- `pollIntervalMinutes` — how often to check for new emails (default: 5, range: 1–60)
-- `hourlyLimit` — maximum auto-replies per clock hour UTC (default: 20, range: 1–1000)
-- `dailyLimit` — maximum auto-replies per calendar day UTC (default: 100, range: 1–10000)
-
-### Behaviour
-
-- Once the dispatcher is wired (see above), each account's poll is skipped if the configured interval hasn't elapsed since the last poll. The interval gate is enforced inside `email-auto-respond.js`, so the same skip logic applies whether the script is fired by the dispatcher or manually by an operator.
-- Only emails addressed TO the agent's email address are processed (alias filtering applies).
-- Auto-replies, mailing list messages, and emails from the agent's own address are automatically skipped (RFC 3834 loop prevention).
-- Outgoing replies include `In-Reply-To` and `References` headers for correct threading, and `Auto-Submitted: auto-replied` to prevent loops with other auto-responders.
-- Every reply includes a deterministic AI disclosure footer ("This reply was generated by an AI assistant.") appended after the agent's response. This is a regulatory requirement (EU AI Act Article 50) and is not dependent on the LLM including disclosure in its generated text.
-- The subject line carries a single `Re:` prefix (no doubling).
-
-### Rate Limiting
-
-Per-account send caps prevent runaway auto-replies from spam waves, mailing list explosions, or deliberate attacks. Two independent limits:
-
-- **Hourly limit** (default 20) — resets at each UTC clock-hour boundary
-- **Daily limit** (default 100) — resets at midnight UTC
-
-When either limit is reached, remaining emails in the poll cycle are skipped (not replied to). Auto-respond is **not** disabled — counters reset naturally at the next boundary. A medium-priority admin Task is created to notify the admin.
-
-Within a single poll cycle, only one auto-reply is sent per unique sender address. This prevents reply storms when an automated sender delivers multiple messages. Sender deduplication is case-insensitive.
-
-### Circuit Breaker
-
-After 3 consecutive failures (IMAP errors, API failures, SMTP rejections), auto-respond is automatically disabled and a high-priority Task is created for the admin. The admin sees this task at the start of their next session and can re-enable auto-respond after resolving the issue.
-
-### Disabling
-
-Call `email-auto-respond-config` with `enabled: false`. This clears the agent assignment and resets the failure counter.
+- Inbound messages enter the graph only when the operator approves them by eye via `email-ingest`
 
 ## OTP Integration
 

package/payload/platform/plugins/email/skills/email-ingest/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: email-ingest
+description: "Operator-initiated email ingestion. Activate when the operator asks to check, triage, or pull in new email ('check my emails', 'any new mail?', 'pull in the latest emails', 'what came in overnight'). Drives a list → summarise → ask → ingest loop using the email-fetch and email-ingest tools. Human-in-the-loop: nothing enters the graph without an explicit operator decision per message."
+---
+
+# Email ingestion
+
+Operator-initiated, human-in-the-loop ingestion of the agent's IMAP inbox into the graph. New messages enter the knowledge graph **only** when the operator says so, and only the ones they pick. There is no background poll, no automatic classifier, no silent writes.
+
+## When to activate
+
+Activate when the operator wants to bring new email into the agent's memory. Typical phrasings:
+
+- "Check my emails."
+- "Any new mail?"
+- "Pull in the latest emails."
+- "What came in overnight?"
+
+Do **not** activate for:
+
+- Searching, reading, or recalling email already in the inbox or the graph — those are `email-search`, `email-read`, `email-graph-query`.
+- Drafting or sending — that's `email-composition`.
+- Setup, status, or OTP extraction — those are direct tool calls.
+
+## Flow
+
+### 1. List
+
+Call `email-fetch`. It pulls new messages since the stored high-water mark (or a `since_uid` if the operator asked for a wider window) and stages them in-memory for the follow-up ingest. **It writes nothing to the graph.**
+
+If `email-fetch` returns "No new messages", say that and stop. There is nothing to ingest.
+
+### 2. Summarise
+
+Present the listed messages to the operator as a numbered or per-`Message-ID` summary. For each, surface:
+
+- Sender (name + address).
+- Subject.
+- A one-line gist drawn from the body preview (not the full preview — keep it tight).
+- A suggested disposition where the message is obviously one or the other (e.g., "newsletter — looks like discard", "thread reply from a known correspondent — looks like ingest"). The suggestion is a hint, never an action; the operator decides.
+
+Do not classify suspicious vs clean — there is no screener. If a message looks like phishing, surface that observation in plain English so the operator can discard it by eye.
+
+### 3. Ask
+
+Ask the operator to confirm a disposition for **every** message in the list. Either:
+
+- A blanket call ("ingest all", "discard everything"), which you turn into the per-message map.
+- An explicit per-message choice ("ingest 1, 2, 4; discard 3").
+
+If the operator answers ambiguously ("the work ones"), restate the messages you think they mean and confirm before proceeding. Never guess.
+
+### 4. Ingest
+
+Call `email-ingest` with a `decisions` array containing one entry per Message-ID returned by `email-fetch`. The tool refuses if any pending Message-ID is missing a decision — that's the safeguard against silent drops, not an error to retry around. If it refuses, go back to the operator and ask about the missing ones.
+
+On success the tool returns a one-line summary (ingested / discarded / thread counts) and advances the inbox high-water mark.
+
+### 5. Confirm
+
+Echo the tool's summary back to the operator in one sentence. If they want to draft a reply to anything that was just ingested, hand off to `email-composition`.
+
+## Edge cases
+
+| Situation | Behaviour |
+|-----------|-----------|
+| `email-fetch` returns zero new messages | Tell the operator and stop. Do not call `email-ingest`. |
+| A listed message has no `Message-ID` header | Surface it by UID and ask the operator how to handle it. `email-ingest` cannot apply a per-message decision to it, so either widen the search or skip it explicitly. |
+| Operator wants to ingest some now and review the rest later | Refuse cleanly. The high-water mark advances on every successful ingest, so a partial decision would silently drop the rest. Ask them to commit one way or the other on every message, or to wait. |
+| Operator abandons mid-flow | Do not call `email-ingest`. The staged batch stays in memory until the next `email-fetch` overwrites it; the high-water mark does not move. |
+| `email-fetch` errors (IMAP down, auth failure) | Surface the error verbatim. Do not retry silently. |
+
+## Out of scope
+
+- **Automatic re-screening or LLM classification.** The screener was removed; the operator is the screener now.
+- **Scheduled or recurring ingestion.** There is no cron, no interval, no background trigger. The operator initiates every cycle.
+- **Per-thread or per-sender allowlists.** Each message gets a fresh decision.
+- **Other channels.** WhatsApp and the public web have their own ingestion paths.
+
+## Observability
+
+Each tool emits a single tagged log line:
+
+- `[email-fetch] tag=email-fetch listed=<n> sinceUid=<uid>` — one per list call.
+- `[email-ingest] tag=email-ingest ingested=<n> discarded=<m>` — one per ingest call.
+
+A complete cycle is greppable as the pair `email-fetch` → `email-ingest` for the same session.

package/payload/platform/plugins/memory/PLUGIN.md

@@ -160,7 +160,7 @@ Writes targeting `:Person`, `:UserProfile`, `:AdminUser`, `:Organization`, `:Loc
 
 - **Workflow path — `producedByTaskId`.** `memory-write` accepts an optional `producedByTaskId` parameter. When set, the platform composes an inbound `:PRODUCED` edge from that `:Task` node into the write's `relationships` array before the write runs. The Task and the new node must share the same `accountId`; mismatch is rejected loud. The typical pattern: call `work-create` at the start of an autonomous flow (onboarding skill, cloudflare tunnel-login) with `kind` and `raisedDuringConversationKey`; capture the returned `taskId`; pass it as `producedByTaskId` on every subsequent `memory-write` for one of the gated labels.
 
-- **Direct-ask path — `CONVERSATION_NODE_ID` env-stamp.** When `producedByTaskId` is not provided (typical of direct admin asks like "add Anneke as person"), `memory-write` falls back to the `CONVERSATION_NODE_ID` env var. The admin server stamps it at PTY spawn time on both admin sessions and on the specialist subagent spawns the admin dispatches (Task 382 — listing-curator, content-producer, database-operator and friends inherit the same anchor). The value is the `conversationId` UUID of the active `:AdminConversation`; the wrapper's `injectConversationProvenance` MATCHes `(c:Conversation {conversationId, accountId})` so account isolation is enforced inside the natural key — a cross-account stamp returns zero rows and never injects. Autonomous spawns with no parent conversation (cron, scheduled-task) legitimately have no env-stamp; those must thread `producedByTaskId` via `work-create` instead. The env-stamp is invisible to the agent (no schema field changes); the LLM never decides whether to use it.
+- **Direct-ask path — `SESSION_NODE_ID` env-stamp.** When `producedByTaskId` is not provided (typical of direct admin asks like "add Anneke as person"), `memory-write` falls back to the `SESSION_NODE_ID` env var. The admin server stamps it at PTY spawn time on both admin sessions and on the specialist subagent spawns the admin dispatches (Task 382 — listing-curator, content-producer, database-operator and friends inherit the same anchor). The value is the `sessionId` UUID of the active `:AdminConversation`; the wrapper's `injectConversationProvenance` MATCHes `(c:Conversation {sessionId, accountId})` so account isolation is enforced inside the natural key — a cross-account stamp returns zero rows and never injects. Autonomous spawns with no parent conversation (cron, scheduled-task) legitimately have no env-stamp; those must thread `producedByTaskId` via `work-create` instead. The env-stamp is invisible to the agent (no schema field changes); the LLM never decides whether to use it.
 
 ## Graph Hygiene
 

package/payload/platform/plugins/memory/mcp/dist/index.js

@@ -676,7 +676,7 @@ if (!readOnly) {
                 keywords,
                 sourceWorkflow,
                 occurredAt,
-                conversationNodeId: process.env.CONVERSATION_NODE_ID,
+                conversationNodeId: process.env.SESSION_NODE_ID,
             });
             const status = result.created
                 ? `Report created`
@@ -1211,7 +1211,7 @@ if (!readOnly) {
                 "",
                 ...result.items.map((i) => {
                     const preview = i.firstUserMsgPreview ? ` userPreview=${JSON.stringify(i.firstUserMsgPreview)}` : "";
-                    return `- elementId=${i.elementId} conversationId=${i.conversationId ?? "null"} assistantMsgs=${i.assistantMsgCount} realUserMsgs=${i.realUserMsgCount}${preview}`;
+                    return `- elementId=${i.elementId} sessionId=${i.sessionId ?? "null"} assistantMsgs=${i.assistantMsgCount} realUserMsgs=${i.realUserMsgCount}${preview}`;
                 }),
             ];
             return { content: [{ type: "text", text: lines.join("\n") }] };
@@ -1473,7 +1473,7 @@ if (!readOnly) {
     }
     /** Format conversation header line with activity timestamps. Shared across metadata and inline modes. */
     function formatConversationHeader(opts) {
-        const label = opts.name ? `"${opts.name}"` : opts.conversationId.slice(0, 8) + "…";
+        const label = opts.name ? `"${opts.name}"` : opts.sessionId.slice(0, 8) + "…";
         const agentInfo = opts.agentSlug ? `${opts.agentType}/${opts.agentSlug}` : opts.agentType;
         const createdStr = shortIso(opts.createdAt) || "(no timestamp)";
         const updatedStr = shortIso(opts.updatedAt);
@@ -1492,12 +1492,12 @@ if (!readOnly) {
         return `${label} [${agentInfo}] · created ${createdStr} · active ${updatedStr}${agoStr} — ${opts.messageCount} messages`;
     }
     server.tool("conversation-list", "List conversations or retrieve messages from a specific conversation. " +
-        "Without conversationId: lists all conversations with message counts, ordered by most recent activity (updatedAt DESC). " +
+        "Without sessionId: lists all conversations with message counts, ordered by most recent activity (updatedAt DESC). " +
         "Headers show both creation time and last activity time; when they differ, the conversation was resumed. " +
-        "With conversationId: returns all messages in that conversation chronologically with per-message timestamps. " +
+        "With sessionId: returns all messages in that conversation chronologically with per-message timestamps. " +
         "With includeMessages: returns conversations with their timestamped messages inline (useful for batch review). " +
         "The since filter matches against activity time (updatedAt), not creation time.", {
-        conversationId: z
+        sessionId: z
             .string()
             .optional()
             .describe("If provided, returns messages for this conversation. If omitted, lists all conversations."),
@@ -1521,20 +1521,20 @@ if (!readOnly) {
             .number()
             .optional()
             .describe("Maximum results (default 50 for conversations, 200 for messages)"),
-    }, async ({ conversationId, agentType, agentSlug, since, includeMessages, limit }) => {
+    }, async ({ sessionId, agentType, agentSlug, since, includeMessages, limit }) => {
         if (!accountId)
             return refuseNoAccount("conversation-list");
         const startTime = Date.now();
         const dbSession = getSession();
         try {
-            if (conversationId) {
+            if (sessionId) {
                 // Messages mode — chronological listing for a specific conversation
                 const messageLimit = limit ?? 200;
-                const result = await dbSession.run(`MATCH (m:Message)-[:PART_OF]->(c:Conversation {conversationId: $conversationId, accountId: $accountId})
+                const result = await dbSession.run(`MATCH (m:Message)-[:PART_OF]->(c:Conversation {sessionId: $sessionId, accountId: $accountId})
              WHERE ${notTrashed("m")} AND ${notTrashed("c")}
              RETURN m.role AS role, m.content AS content, m.createdAt AS createdAt
              ORDER BY m.createdAt ASC
-             LIMIT $limit`, { conversationId, accountId, limit: int(messageLimit) });
+             LIMIT $limit`, { sessionId, accountId, limit: int(messageLimit) });
                 if (result.records.length === 0) {
                     return {
                         content: [{ type: "text", text: "No messages found for this conversation." }],
@@ -1546,7 +1546,7 @@ if (!readOnly) {
                     const ts = shortIso(String(r.get("createdAt") ?? ""));
                     return ts ? `[${role} ${ts}]\n  ${content}` : `[${role}]\n  ${content}`;
                 });
-                process.stderr.write(`[conversation-list] [${accountId}] mode=messages conversationId=${conversationId.slice(0, 8)}… count=${result.records.length} (${Date.now() - startTime}ms)\n`);
+                process.stderr.write(`[conversation-list] [${accountId}] mode=messages sessionId=${sessionId.slice(0, 8)}… count=${result.records.length} (${Date.now() - startTime}ms)\n`);
                 return {
                     content: [{ type: "text", text: formatted.join("\n---\n") }],
                 };
@@ -1579,7 +1579,7 @@ if (!readOnly) {
              OPTIONAL MATCH (m:Message)-[:PART_OF]->(c) WHERE ${trashedMsgFilter}
              WITH c, m ORDER BY m.createdAt ASC
              WITH c, collect({role: m.role, content: m.content, createdAt: m.createdAt})[0..${msgLimit}] AS messages
-             RETURN c.conversationId AS conversationId,
+             RETURN c.sessionId AS sessionId,
                     c.agentType AS agentType,
                     c.agentSlug AS agentSlug,
                     c.name AS name,
@@ -1594,11 +1594,11 @@ if (!readOnly) {
                     };
                 }
                 const formatted = result.records.map((r) => {
-                    const id = String(r.get("conversationId") ?? "");
+                    const id = String(r.get("sessionId") ?? "");
                     const msgCount = Number(r.get("messageCount") ?? 0);
                     const header = formatConversationHeader({
                         name: r.get("name"),
-                        conversationId: id,
+                        sessionId: id,
                         agentType: String(r.get("agentType") ?? ""),
                         agentSlug: r.get("agentSlug"),
                         createdAt: String(r.get("createdAt") ?? ""),
@@ -1634,7 +1634,7 @@ if (!readOnly) {
            ${whereStr ? whereStr + " AND " : "WHERE "}${trashedConvFilter}
            WITH c ORDER BY c.updatedAt DESC LIMIT $limit
            OPTIONAL MATCH (m:Message)-[:PART_OF]->(c) WHERE ${trashedMsgFilter}
-           RETURN c.conversationId AS conversationId,
+           RETURN c.sessionId AS sessionId,
                   c.agentType AS agentType,
                   c.agentSlug AS agentSlug,
                   c.name AS name,
@@ -1648,13 +1648,13 @@ if (!readOnly) {
                 };
             }
             const formatted = result.records.map((r) => {
-                const id = String(r.get("conversationId") ?? "");
+                const id = String(r.get("sessionId") ?? "");
                 const msgCount = typeof r.get("messageCount") === "number"
                     ? r.get("messageCount")
                     : Number(r.get("messageCount"));
                 return formatConversationHeader({
                     name: r.get("name"),
-                    conversationId: id,
+                    sessionId: id,
                     agentType: String(r.get("agentType") ?? ""),
                     agentSlug: r.get("agentSlug"),
                     createdAt: String(r.get("createdAt") ?? ""),
@@ -1691,7 +1691,7 @@ if (!readOnly) {
             .describe("How the preference was observed. Defaults to 'behavioural'."),
         mode: z.enum(["reinforce", "update", "contradict", "merge"]).optional()
             .describe("Update mode. Defaults to 'reinforce'."),
-        conversationId: z.string().optional()
+        sessionId: z.string().optional()
             .describe("Conversation ID for evidence linking"),
         profileFields: z.record(z.string(), z.unknown()).optional()
             .describe("Top-level UserProfile fields to update (e.g. timezone, locale, role)"),
@@ -1702,7 +1702,7 @@ if (!readOnly) {
             .describe("Operator-identity fields written to the OWNS-bound Person. Use canonical `telephone` (NOT `phone` — that is the schema synonym, not the canonical name). Tool throws if the AdminUser-OWNS-Person edge is missing rather than silently no-op."),
         mergeSourceIds: z.array(z.string()).optional()
             .describe("For mode 'merge': preferenceIds of sources to combine into this preference"),
-    }, async ({ category, key, value, source, mode, conversationId, profileFields, personFields, mergeSourceIds }) => {
+    }, async ({ category, key, value, source, mode, sessionId, profileFields, personFields, mergeSourceIds }) => {
         if (!accountId)
             return refuseNoAccount("profile-update");
         try {
@@ -1717,7 +1717,7 @@ if (!readOnly) {
                 value,
                 source,
                 mode,
-                conversationId,
+                sessionId,
                 profileFields: profileFields,
                 personFields,
                 mergeSourceIds,
@@ -1901,15 +1901,15 @@ if (!readOnly) {
         "(Message nodes) is immutable history and is never modified — only the derived :Memory payload that " +
         "memory-search would otherwise re-surface. Use when a single conversation polluted memory with claims " +
         "that should not propagate (e.g. wrong-account hostnames, fabricated identifiers).", {
-        conversationId: z.string().min(1).describe("The Conversation node's conversationId to scope the expunge to."),
+        sessionId: z.string().min(1).describe("The Conversation node's sessionId to scope the expunge to."),
         pattern: z.string().min(1).describe("The substring to scrub from string properties on linked :Memory nodes."),
-    }, async ({ conversationId, pattern }) => {
+    }, async ({ sessionId, pattern }) => {
         if (!accountId)
             return refuseNoAccount("conversation-memory-expunge");
         try {
-            const result = await conversationMemoryExpunge({ accountId, conversationId, pattern });
+            const result = await conversationMemoryExpunge({ accountId, sessionId, pattern });
             const lines = [
-                `Expunged "${result.pattern}" from conversation ${result.conversationId.slice(0, 8)}…`,
+                `Expunged "${result.pattern}" from conversation ${result.sessionId.slice(0, 8)}…`,
                 `:Memory nodes scanned: ${result.nodesScanned}`,
                 `Properties nulled: ${result.propertiesNulled}`,
             ];
@@ -1967,7 +1967,7 @@ eagerTool(server, "conversation-search", "Search conversation history using sema
         try {
             const conversationSessionId = resolveSessionId();
             const sessionClause = conversationSessionId
-                ? "AND node.conversationId = $sessionId"
+                ? "AND node.sessionId = $sessionId"
                 : "";
             const result = await dbSession.run(`CALL db.index.vector.queryNodes('message_embedding', $limit, $embedding)
            YIELD node, score
@@ -1979,7 +1979,7 @@ eagerTool(server, "conversation-search", "Search conversation history using sema
            RETURN node.messageId AS messageId,
                   node.role AS role,
                   node.content AS content,
-                  node.conversationId AS conversationId,
+                  node.sessionId AS sessionId,
                   c.name AS sessionName,
                   node.createdAt AS createdAt,
                   score
@@ -2000,7 +2000,7 @@ eagerTool(server, "conversation-search", "Search conversation history using sema
                 const content = r.get("content");
                 const score = typeof r.get("score") === "number" ? r.get("score") : Number(r.get("score"));
                 const createdAt = String(r.get("createdAt"));
-                const convId = r.get("conversationId");
+                const convId = r.get("sessionId");
                 const sessionName = r.get("sessionName");
                 const convPrefix = convId ? convId.slice(0, 8) : "unknown";
                 const convLabel = sessionName
@@ -2010,7 +2010,7 @@ eagerTool(server, "conversation-search", "Search conversation history using sema
             });
             // Diagnostic: log when admin search results span multiple conversations
             const distinctConvIds = new Set(result.records
-                .map((r) => r.get("conversationId"))
+                .map((r) => r.get("sessionId"))
                 .filter(Boolean));
             if (distinctConvIds.size > 1) {
                 const prefixes = [...distinctConvIds].map((id) => id.slice(0, 8));
@@ -2082,7 +2082,7 @@ server.tool("image-fetch", [
 // bypassing this tool.
 server.tool("memory-typed-edge-pass", "Run the typed-edge auto-extraction pass over prose-bearing nodes this account wrote since sinceIso. Reads Message/Page/Meeting/Email/Idea/Note/Post/Report nodes, batches them, asks Haiku for typed-edge proposals against the closed allowlist (ATTENDED, WORKS_AT, INVESTED_IN, FOUNDED, ADVISES, MENTIONS, AUTHORED, ATTACHED_TO, REFERENCES), validates each proposal inline, and MERGEs accepted edges with createdBy provenance. Returns the counters (nodes, proposed, accepted, rejected, failed, ms) for the caller to hand back to admin's session-retrospective-mark-complete.", {
     sinceIso: z.string().describe("ISO timestamp lower bound. Prose nodes with updatedAt >= sinceIso are processed."),
-    conversationId: z.string().optional().describe("Conversation id stamped onto the createdBy provenance of MERGEd edges. Defaults to CONVERSATION_ID env if absent."),
+    sessionId: z.string().optional().describe("Conversation id stamped onto the createdBy provenance of MERGEd edges. Defaults to SESSION_ID env if absent."),
 }, async (args) => {
     if (!accountId)
         return refuseNoAccount("memory-typed-edge-pass");