@rubytech/create-maxy-code 0.1.322 → 0.1.324

package/dist/index.js

@@ -608,6 +608,55 @@ function writeChromiumBinaryPathFile() {
     console.log(`  Wrote ${target} → ${RESOLVED_CHROMIUM_BIN}`);
     logFile(`  [snap-chromium] wrote ${target} contents=${RESOLVED_CHROMIUM_BIN}`);
 }
+// Arm the systemd system-manager hardware watchdog so a *kernel hang* (the
+// freeze mode: board powered but stuck, /dev/watchdog never petted) reboots the
+// board without a manual power cycle. Distinct from the brand user-service's
+// software watchdog (Type=notify WATCHDOG_USEC), which only restarts the UI
+// process — this resets the whole SoC. Idempotent host-wide drop-in; gated on
+// /dev/watchdog existing (driver loaded) and Linux. Best-effort: a failure
+// warns, never aborts the install. Cannot recover a latched-off brownout (no
+// power = no watchdog) — that needs the external power-cycler documented in
+// deployment.md.
+function configureHardwareWatchdog() {
+    try {
+        if (!isLinux()) {
+            logFile("  hardware watchdog: skipped (not Linux)");
+            return;
+        }
+        if (!existsSync("/dev/watchdog")) {
+            logFile("  hardware watchdog: skipped (/dev/watchdog absent)");
+            return;
+        }
+        const desired = "[Manager]\nRuntimeWatchdogSec=20s\nRebootWatchdogSec=2min\n";
+        const dropinDir = "/etc/systemd/system.conf.d";
+        const dropinPath = `${dropinDir}/10-maxy-watchdog.conf`;
+        let current = "";
+        if (existsSync(dropinPath)) {
+            try {
+                current = readFileSync(dropinPath, "utf-8");
+            }
+            catch {
+                // Unreadable existing drop-in — treat as changed so we rewrite.
+                current = "";
+            }
+        }
+        if (current === desired) {
+            logFile(`  hardware watchdog: already active (${dropinPath})`);
+            return;
+        }
+        const tmpPath = "/tmp/10-maxy-watchdog.conf";
+        writeFileSync(tmpPath, desired);
+        console.log("  [privileged] install systemd hardware watchdog drop-in (RuntimeWatchdogSec=20s RebootWatchdogSec=2min)");
+        shell("mkdir", ["-p", dropinDir], { sudo: true });
+        shell("cp", [tmpPath, dropinPath], { sudo: true });
+        spawnSync("rm", ["-f", tmpPath]);
+        spawnSync("sudo", ["systemctl", "daemon-reload"], { stdio: "inherit" });
+        logFile(`  hardware watchdog: enabled (wrote ${dropinPath}; arms on next boot or systemd re-exec)`);
+    }
+    catch (err) {
+        console.error(`  WARNING: failed to configure hardware watchdog: ${err instanceof Error ? err.message : String(err)}`);
+    }
+}
 function installSystemDeps() {
     log("1", TOTAL, "System dependencies and network...");
     const platform = requireSupportedPlatform(process.platform);
@@ -1566,8 +1615,10 @@ function ensureOllamaServing() {
 // `ollama.service` bounds llama-server to a fraction of the cores so peak
 // temperature plateaus below the limit regardless of batch shape or which
 // platform path issues the embeds — the caller-agnostic fix, inherited by every
-// install. Quota is half the cores (rounded down, min 1) so at least half stay
-// idle for the thermal budget: 200% on a 4-core Pi. Applied only when the ollama
+// install. Quota is one core (100%): an embedding burst then draws roughly a
+// quarter of a 4-core Pi's compute current instead of half, which both keeps
+// peak SoC temperature down and shaves the current spike that browns out a
+// marginal PSU. Ingest is slower in exchange. Applied only when the ollama
 // system service exists (the normal Linux path, where ollama's install.sh
 // registers `ollama.service`); a detached `ollama serve` has no unit to cap.
 // ollama is one shared host service across co-resident brands, so the drop-in is
@@ -1582,7 +1633,7 @@ function capOllamaServiceCpu() {
             return;
         }
         const coreCount = Math.max(1, cpus().length);
-        const quotaCores = Math.max(1, Math.floor(coreCount / 2));
+        const quotaCores = 1;
         const quotaPct = quotaCores * 100;
         const desired = `[Service]\nCPUQuota=${quotaPct}%\n`;
         const dropinDir = "/etc/systemd/system/ollama.service.d";
@@ -4188,6 +4239,7 @@ logDiagnostics("pre-flight");
 logFile(`  Neo4j instance: ${NEO4J_DEDICATED ? "dedicated" : "shared"} on bolt://localhost:${NEO4J_PORT}`);
 try {
     installSystemDeps();
+    configureHardwareWatchdog();
     installNodejs();
     installClaudeCode();
     installNeo4j();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.322",
+  "version": "0.1.324",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

package/payload/platform/plugins/admin/skills/insight/SKILL.md

@@ -19,6 +19,6 @@ Pass 2 — Operator-relationship updates. Walk this session for tonal signals, r
 
 Pass 3 — Graph completeness sweep. Walk this session for any node, edge, or commitment that was discussed but not written to the graph in-flight. For each missing write, delegate to `database-operator` via the Task tool. Count what you write.
 
-Pass 4 — Typed-edge auto-extraction. Delegate to `database-operator` via the Task tool with a prompt naming the typed-edge pass and the session-start timestamp. The specialist calls `memory-typed-edge-pass` with that timestamp and returns the counters. Capture `nodesProcessed` and the accepted count from its reply.
+Pass 4 — Typed-edge auto-extraction. Delegate to `typed-edge-classifier` via the Task tool with a prompt supplying the `accountId` and the session-start timestamp as `sinceIso`. The specialist reads prose nodes written since that timestamp, writes typed edges from the closed allowlist, and returns one line `typed-edge-classifier: nodesProcessed=… proposed=… accepted=… rejected=… ms=…`. Capture `nodesProcessed` and `accepted` from that line.
 
 Then reply with one short paragraph in your house voice summarising what you wrote — naming the five counts (learnings, preferences, graph-writes, typed-edges, nodesProcessed) — and carry on with the operator's work.

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:009036cb2953a53e5a5d85f5cdf3399d4a7dd12c40fa17e03ebcb46ebeec87a7
+content-hash: sha256:479e04a1e25ace04e44415db3c536ed28faac7ee30b9171524d38b7a667716d1
 brand: maxy-code
 product-name: Maxy
 ---
@@ -365,10 +365,10 @@ These are enabled during onboarding and can be added or removed at any time. Som
 | `whatsapp` | WhatsApp messaging, pairing, and conversation browsing | Personal assistant |
 | `replicate` | Image generation — three models for photorealistic, design, and fast draft images | Content producer, Research assistant |
 | `linkedin-import` | Import a LinkedIn Basic Data Export — Profile and Connections today, more CSVs as references land | Database operator |
-| `notion-import` | Import a Notion workspace export (markdown + CSV) — pages, databases, hierarchy, attachments, schema-bounded relations, `@person` mentions account-filtered | Database operator |
-| `obsidian-import` | Import an extracted Obsidian vault — pages map to `:KnowledgeDocument`, wikilinks resolve to intra-vault pages or existing entities, tags become `:DefinedTerm`, embedded images become `:DigitalDocument`. Two-phase tool (dry-run → operator disambiguation → commit). | Database operator |
-| `x-import` | Import an X (Twitter) Basic Data Export — tweet stream renders as one chronological transcript and ingests as a single `:KnowledgeDocument` (`source='x'`); each DM `sessionId` ingests as one `:ConversationArchive` (`source='x-dm'`, keyed on `conversationIdentity`) via `conversation-archive-ingest.sh`. Mentions, replies, and quote-tweet authors resolve to `:Person` on lowercased `xHandle`; every handle and DM senderId confirms against existing nodes (no auto-create). Per-thread KD granularity and `:Post` / `:DirectMessage` labels are explicitly rejected. | Database operator |
-| `substack-import` | Import a Substack "Export your data" archive — per-essay `:KnowledgeDocument {kind:'substack-post'}` via librarian/document-ingest with synthetic stable `attachmentId = "substack-post-${substackPostId}"` (survives Substack edits); one `:KnowledgeDocument {kind:'substack-subscriber-roster'}` per import run with `:MENTIONS {mentionContext:'substack-subscription', tier, totalOpens, totalClicks, lastOpenedAt, lastClickedAt, engagementWindowDays}` to each subscriber `:Person` MERGEd on `(accountId, email)`. Engagement aggregates parsed from `email_activity.csv` (or `subscriber_activity.csv` / `emails.csv`); overwrite-on-reimport. No new label, no new edge type, no new graph writer. Images attach via canonical `:HAS_ENCLOSURE` (or `:MENTIONS` fallback). Bulk-gate at >200 posts or >2000 subscribers. | Database operator |
+| `notion-import` | Import a Notion workspace export (markdown + CSV) — pages, databases, hierarchy, attachments, schema-bounded relations, `@person` mentions account-filtered | Librarian |
+| `obsidian-import` | Import an extracted Obsidian vault — pages map to `:KnowledgeDocument`, wikilinks resolve to intra-vault pages or existing entities, tags become `:DefinedTerm`, embedded images become `:DigitalDocument`. Two-phase tool (dry-run → operator disambiguation → commit). | Librarian |
+| `x-import` | Import an X (Twitter) Basic Data Export — tweet stream renders as one chronological transcript and ingests as a single `:KnowledgeDocument` (`source='x'`); each DM `sessionId` ingests as one `:ConversationArchive` (`source='x-dm'`, keyed on `conversationIdentity`) via `conversation-archive-ingest.sh`. Mentions, replies, and quote-tweet authors resolve to `:Person` on lowercased `xHandle`; every handle and DM senderId confirms against existing nodes (no auto-create). Per-thread KD granularity and `:Post` / `:DirectMessage` labels are explicitly rejected. | Librarian |
+| `substack-import` | Import a Substack "Export your data" archive — per-essay `:KnowledgeDocument {kind:'substack-post'}` via librarian/document-ingest with synthetic stable `attachmentId = "substack-post-${substackPostId}"` (survives Substack edits); one `:KnowledgeDocument {kind:'substack-subscriber-roster'}` per import run with `:MENTIONS {mentionContext:'substack-subscription', tier, totalOpens, totalClicks, lastOpenedAt, lastClickedAt, engagementWindowDays}` to each subscriber `:Person` MERGEd on `(accountId, email)`. Engagement aggregates parsed from `email_activity.csv` (or `subscriber_activity.csv` / `emails.csv`); overwrite-on-reimport. No new label, no new edge type, no new graph writer. Images attach via canonical `:HAS_ENCLOSURE` (or `:MENTIONS` fallback). Bulk-gate at >200 posts or >2000 subscribers. | Librarian |
 | `memory/skills/conversation-archive` | Source-agnostic conversation transcript ingest. One skill for WhatsApp `_chat.txt`, Telegram, Signal, LinkedIn DMs, Zoom transcript, meeting minutes, iMessage, Slack, X DMs — `--source <enum>` selects the per-source normaliser. Single Bash entry — `bash platform/plugins/memory/bin/conversation-archive-ingest.sh <archive> --source <enum> --participant-person-ids <csv> --scope <admin\|public>` — runs normalise → operator-confirms owner + every distinct sender (owner derived from env via Cypher, no flag) → sessionize at the fixed 8h gap → emit one JSON line carrying prepared sessions (turn-attributed text + per-session cursor). The dispatched specialist iterates the sessions in-turn, produces a typed-section JSON chunking for each, and calls the `memory-ingest` MCP tool with `conversationIdentity` set (writes `:ConversationArchive`, source=<enum>) once per session — chunks + cursor advance commit atomically inside one Cypher transaction, so a kill mid-archive resumes from the next session on re-issue without re-classifying anything already written. Re-imports are delta-append. Auto-creating participants is forbidden — any sender outside the operator-confirmed closed set LOUD-FAILs with `parser-miss`. Distinct from the live `whatsapp` plugin (Baileys). | Database operator |
 | `memory/skills/conversation-archive-enrich` | Phase 2 for any named `:ConversationArchive` — source-agnostic per-row insight derivation. Operator-triggered (never auto-fires on Phase 1 completion). Walks the parent's `:Section` chunks in pages via the read-only MCP tool `mcp__plugin_memory_memory__conversation-archive-list-chunks`; the dispatched specialist reads each chunk in-turn and emits claims under the four-kind contract (`mention`, `task`, `preference`, `observed-relationship`); the skill hands those claims to `mcp__plugin_memory_memory__conversation-archive-derive-insights` for per-kind cypher emission, then runs the per-row operator gate (`wire / skip / reject`). Idempotent on `(elementId(chunk), kind, contentHash)` — re-runs collapse identical claims. Confidence floor is a hedging-avoidance instruction the skill embeds in the specialist's per-chunk prompt, not a numeric post-filter; the LLM step runs in-turn from the dispatched specialist rather than as a server-side OAuth round-trip. | Database operator |
 
@@ -2290,6 +2290,18 @@ reserved for vertical / integration notes (LinkedIn extension,
 PropertyData, Real Agent standalone, MCP server inventory) — not for
 core-platform docs.
 
+## UI conventions
+
+**Icons are Lucide components only — no emoji.** Every glyph rendered in
+`platform/ui` JSX (the `/chat` web chat, the WhatsApp/channel readers, the
+admin shell, the `/data` grid) is a `lucide-react` component (e.g.
+`<Paperclip>`, `<FileText>`), never an emoji/emoticon character in the rendered
+string. The rule is enforced at build time by
+[`scripts/check-no-emoji-in-jsx.mjs`](../../../ui/scripts/check-no-emoji-in-jsx.mjs),
+which fails `prebuild` if any emoji codepoint appears in a `.ts`/`.tsx` file
+under `app/` (tests excluded). Inline an icon at the surrounding text size and
+colour (`size={14}` matches body text; Lucide inherits `currentColor`).
+
 ## Admin Hono routes
 
 Every admin sub-app is mounted by
@@ -3458,6 +3470,25 @@ Source: https://docs.getmaxy.com/deployment.md
 - Mac with macOS 14 (Sonoma) or newer — both Apple Silicon and Intel
 - 256GB storage minimum
 - Always-on power and network connection
+- **On a Pi 5: the official 27W USB-C power supply (5.1V / 5A) and a good cable.** This is not optional — see Power and recovery below.
+
+## Power and recovery (Raspberry Pi)
+
+A Pi 5 running Maxy draws hard during document ingest: the embedding model runs the CPU flat-out in bursts. An underpowered supply or a thin/long USB-C cable cannot hold 5V under that current spike, the board *browns out*, and you get one of two failures:
+
+- **A reset or freeze** — the board drops out mid-task and either reboots or hangs.
+- **A latched-off board** — the board goes dark and stays dark until you physically unplug and replug the power. No software can recover this, because there is no power to run any recovery.
+
+**The cure is hardware.** Use the official Raspberry Pi 5 27W PSU (5.1V / 5A) and a short, good-quality USB-C cable. A marginal phone charger or a cheap cable is the usual cause. This is the only thing that *prevents* a brownout.
+
+**Recovery seatbelts the installer sets up for you:**
+
+- **A hardware watchdog.** If the board *hangs* (powered but stuck), it reboots itself automatically within about two minutes — no manual power cycle. This only helps a hung board; it cannot help a board that has gone dark.
+- **Power-health logging.** The admin server writes a `[power-health]` line to `server.log` at boot and every 15 minutes, so a brownout shows up without waiting for a crash. A healthy line reads `throttled=0x0 ... undervolt_occurred=false`. Any `undervolt`-flag set, or `reboots_unclean_24h` above zero, means the board is browning out — fix the power before trusting it with heavy work.
+
+**For a board that latches off (the dark-board case):** put the Pi on a smart plug that you can power-cycle remotely, ideally one driven by a heartbeat (cut power and restore it when the box stops responding). This is the robust recovery for the dark-board failure and is an operator hardware choice, not something the installer can do.
+
+**Keep one address.** After a reboot the Pi can pick up a different DHCP address and look like it vanished. Add a **DHCP reservation** on your router that pins the Pi's MAC to a fixed LAN IP, so the box is always reachable at the same address. The boot `[power-health] op=boot lan_ip=<ip>` line records the address each boot — if it changes across reboots, the reservation is not in place.
 
 ## macOS install
 

package/payload/platform/plugins/docs/references/admin-ui.md

@@ -25,6 +25,18 @@ reserved for vertical / integration notes (LinkedIn extension,
 PropertyData, Real Agent standalone, MCP server inventory) — not for
 core-platform docs.
 
+## UI conventions
+
+**Icons are Lucide components only — no emoji.** Every glyph rendered in
+`platform/ui` JSX (the `/chat` web chat, the WhatsApp/channel readers, the
+admin shell, the `/data` grid) is a `lucide-react` component (e.g.
+`<Paperclip>`, `<FileText>`), never an emoji/emoticon character in the rendered
+string. The rule is enforced at build time by
+[`scripts/check-no-emoji-in-jsx.mjs`](../../../ui/scripts/check-no-emoji-in-jsx.mjs),
+which fails `prebuild` if any emoji codepoint appears in a `.ts`/`.tsx` file
+under `app/` (tests excluded). Inline an icon at the surrounding text size and
+colour (`size={14}` matches body text; Lucide inherits `currentColor`).
+
 ## Admin Hono routes
 
 Every admin sub-app is mounted by

package/payload/platform/plugins/docs/references/deployment.md

@@ -6,6 +6,25 @@
 - Mac with macOS 14 (Sonoma) or newer — both Apple Silicon and Intel
 - 256GB storage minimum
 - Always-on power and network connection
+- **On a Pi 5: the official 27W USB-C power supply (5.1V / 5A) and a good cable.** This is not optional — see Power and recovery below.
+
+## Power and recovery (Raspberry Pi)
+
+A Pi 5 running {{productName}} draws hard during document ingest: the embedding model runs the CPU flat-out in bursts. An underpowered supply or a thin/long USB-C cable cannot hold 5V under that current spike, the board *browns out*, and you get one of two failures:
+
+- **A reset or freeze** — the board drops out mid-task and either reboots or hangs.
+- **A latched-off board** — the board goes dark and stays dark until you physically unplug and replug the power. No software can recover this, because there is no power to run any recovery.
+
+**The cure is hardware.** Use the official Raspberry Pi 5 27W PSU (5.1V / 5A) and a short, good-quality USB-C cable. A marginal phone charger or a cheap cable is the usual cause. This is the only thing that *prevents* a brownout.
+
+**Recovery seatbelts the installer sets up for you:**
+
+- **A hardware watchdog.** If the board *hangs* (powered but stuck), it reboots itself automatically within about two minutes — no manual power cycle. This only helps a hung board; it cannot help a board that has gone dark.
+- **Power-health logging.** The admin server writes a `[power-health]` line to `server.log` at boot and every 15 minutes, so a brownout shows up without waiting for a crash. A healthy line reads `throttled=0x0 ... undervolt_occurred=false`. Any `undervolt`-flag set, or `reboots_unclean_24h` above zero, means the board is browning out — fix the power before trusting it with heavy work.
+
+**For a board that latches off (the dark-board case):** put the Pi on a smart plug that you can power-cycle remotely, ideally one driven by a heartbeat (cut power and restore it when the box stops responding). This is the robust recovery for the dark-board failure and is an operator hardware choice, not something the installer can do.
+
+**Keep one address.** After a reboot the Pi can pick up a different DHCP address and look like it vanished. Add a **DHCP reservation** on your router that pins the Pi's MAC to a fixed LAN IP, so the box is always reachable at the same address. The boot `[power-health] op=boot lan_ip=<ip>` line records the address each boot — if it changes across reboots, the reservation is not in place.
 
 ## macOS install
 

package/payload/platform/plugins/docs/references/plugins-guide.md

@@ -43,10 +43,10 @@ These are enabled during onboarding and can be added or removed at any time. Som
 | `whatsapp` | WhatsApp messaging, pairing, and conversation browsing | Personal assistant |
 | `replicate` | Image generation — three models for photorealistic, design, and fast draft images | Content producer, Research assistant |
 | `linkedin-import` | Import a LinkedIn Basic Data Export — Profile and Connections today, more CSVs as references land | Database operator |
-| `notion-import` | Import a Notion workspace export (markdown + CSV) — pages, databases, hierarchy, attachments, schema-bounded relations, `@person` mentions account-filtered | Database operator |
-| `obsidian-import` | Import an extracted Obsidian vault — pages map to `:KnowledgeDocument`, wikilinks resolve to intra-vault pages or existing entities, tags become `:DefinedTerm`, embedded images become `:DigitalDocument`. Two-phase tool (dry-run → operator disambiguation → commit). | Database operator |
-| `x-import` | Import an X (Twitter) Basic Data Export — tweet stream renders as one chronological transcript and ingests as a single `:KnowledgeDocument` (`source='x'`); each DM `sessionId` ingests as one `:ConversationArchive` (`source='x-dm'`, keyed on `conversationIdentity`) via `conversation-archive-ingest.sh`. Mentions, replies, and quote-tweet authors resolve to `:Person` on lowercased `xHandle`; every handle and DM senderId confirms against existing nodes (no auto-create). Per-thread KD granularity and `:Post` / `:DirectMessage` labels are explicitly rejected. | Database operator |
-| `substack-import` | Import a Substack "Export your data" archive — per-essay `:KnowledgeDocument {kind:'substack-post'}` via librarian/document-ingest with synthetic stable `attachmentId = "substack-post-${substackPostId}"` (survives Substack edits); one `:KnowledgeDocument {kind:'substack-subscriber-roster'}` per import run with `:MENTIONS {mentionContext:'substack-subscription', tier, totalOpens, totalClicks, lastOpenedAt, lastClickedAt, engagementWindowDays}` to each subscriber `:Person` MERGEd on `(accountId, email)`. Engagement aggregates parsed from `email_activity.csv` (or `subscriber_activity.csv` / `emails.csv`); overwrite-on-reimport. No new label, no new edge type, no new graph writer. Images attach via canonical `:HAS_ENCLOSURE` (or `:MENTIONS` fallback). Bulk-gate at >200 posts or >2000 subscribers. | Database operator |
+| `notion-import` | Import a Notion workspace export (markdown + CSV) — pages, databases, hierarchy, attachments, schema-bounded relations, `@person` mentions account-filtered | Librarian |
+| `obsidian-import` | Import an extracted Obsidian vault — pages map to `:KnowledgeDocument`, wikilinks resolve to intra-vault pages or existing entities, tags become `:DefinedTerm`, embedded images become `:DigitalDocument`. Two-phase tool (dry-run → operator disambiguation → commit). | Librarian |
+| `x-import` | Import an X (Twitter) Basic Data Export — tweet stream renders as one chronological transcript and ingests as a single `:KnowledgeDocument` (`source='x'`); each DM `sessionId` ingests as one `:ConversationArchive` (`source='x-dm'`, keyed on `conversationIdentity`) via `conversation-archive-ingest.sh`. Mentions, replies, and quote-tweet authors resolve to `:Person` on lowercased `xHandle`; every handle and DM senderId confirms against existing nodes (no auto-create). Per-thread KD granularity and `:Post` / `:DirectMessage` labels are explicitly rejected. | Librarian |
+| `substack-import` | Import a Substack "Export your data" archive — per-essay `:KnowledgeDocument {kind:'substack-post'}` via librarian/document-ingest with synthetic stable `attachmentId = "substack-post-${substackPostId}"` (survives Substack edits); one `:KnowledgeDocument {kind:'substack-subscriber-roster'}` per import run with `:MENTIONS {mentionContext:'substack-subscription', tier, totalOpens, totalClicks, lastOpenedAt, lastClickedAt, engagementWindowDays}` to each subscriber `:Person` MERGEd on `(accountId, email)`. Engagement aggregates parsed from `email_activity.csv` (or `subscriber_activity.csv` / `emails.csv`); overwrite-on-reimport. No new label, no new edge type, no new graph writer. Images attach via canonical `:HAS_ENCLOSURE` (or `:MENTIONS` fallback). Bulk-gate at >200 posts or >2000 subscribers. | Librarian |
 | `memory/skills/conversation-archive` | Source-agnostic conversation transcript ingest. One skill for WhatsApp `_chat.txt`, Telegram, Signal, LinkedIn DMs, Zoom transcript, meeting minutes, iMessage, Slack, X DMs — `--source <enum>` selects the per-source normaliser. Single Bash entry — `bash platform/plugins/memory/bin/conversation-archive-ingest.sh <archive> --source <enum> --participant-person-ids <csv> --scope <admin\|public>` — runs normalise → operator-confirms owner + every distinct sender (owner derived from env via Cypher, no flag) → sessionize at the fixed 8h gap → emit one JSON line carrying prepared sessions (turn-attributed text + per-session cursor). The dispatched specialist iterates the sessions in-turn, produces a typed-section JSON chunking for each, and calls the `memory-ingest` MCP tool with `conversationIdentity` set (writes `:ConversationArchive`, source=<enum>) once per session — chunks + cursor advance commit atomically inside one Cypher transaction, so a kill mid-archive resumes from the next session on re-issue without re-classifying anything already written. Re-imports are delta-append. Auto-creating participants is forbidden — any sender outside the operator-confirmed closed set LOUD-FAILs with `parser-miss`. Distinct from the live `whatsapp` plugin (Baileys). | Database operator |
 | `memory/skills/conversation-archive-enrich` | Phase 2 for any named `:ConversationArchive` — source-agnostic per-row insight derivation. Operator-triggered (never auto-fires on Phase 1 completion). Walks the parent's `:Section` chunks in pages via the read-only MCP tool `mcp__plugin_memory_memory__conversation-archive-list-chunks`; the dispatched specialist reads each chunk in-turn and emits claims under the four-kind contract (`mention`, `task`, `preference`, `observed-relationship`); the skill hands those claims to `mcp__plugin_memory_memory__conversation-archive-derive-insights` for per-kind cypher emission, then runs the per-row operator gate (`wire / skip / reject`). Idempotent on `(elementId(chunk), kind, contentHash)` — re-runs collapse identical claims. Confidence floor is a hedging-avoidance instruction the skill embeds in the specialist's per-chunk prompt, not a numeric post-filter; the LLM step runs in-turn from the dispatched specialist rather than as a server-side OAuth round-trip. | Database operator |
 

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

@@ -129,7 +129,6 @@ hidden:
   - session-compact
   - session-compact-status
   - image-fetch
-  - memory-typed-edge-pass
 skills:
   - skills/conversational-memory/SKILL.md
   - skills/document-ingest/SKILL.md

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

@@ -49,7 +49,6 @@ import { conversationArchiveDeriveInsights, PROPOSAL_KINDS, } from "./tools/conv
 import { conversationArchiveListChunks } from "./tools/conversation-archive-list-chunks.js";
 import { conversationArchiveEnrichRejection } from "./tools/conversation-archive-enrich-rejection.js";
 import { fetchImageAsContent } from "./tools/image-fetch.js";
-import { memoryTypedEdgePass } from "./tools/memory-typed-edge-pass.js";
 import { memoryReportWrite } from "./tools/memory-report-write.js";
 import { memoryReportReadLatest } from "./tools/memory-report-read-latest.js";
 import { memoryReportList } from "./tools/memory-report-list.js";
@@ -2423,50 +2422,6 @@ lifelineTool(server, "image-fetch", [
     };
 });
 // ===================================================================
-// Typed-edge auto-extraction pass (Task 305)
-// ===================================================================
-//
-// Schema-bounded pass that reads prose-bearing nodes the operator's account
-// wrote since `sinceIso` and asks Haiku for typed-edge proposals against
-// `TYPED_EDGE_ALLOWLIST`. Owned by `database-operator`
-// (admin Task-spawns it during an on-demand `/insight` pass); NOT in
-// `ADMIN_CORE_TOOLS`. Backfill is via the CLI under `scripts/backfill-typed-edges.ts`,
-// bypassing this tool.
-lifelineTool(server, "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 for its insight-pass summary.", {
-    sinceIso: z.string().describe("ISO timestamp lower bound. Prose nodes with updatedAt >= sinceIso are processed."),
-    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");
-    const dbSession = getSession();
-    try {
-        // Cast: the McpServer instance is `any`-typed at the module level (see
-        // file-top comment on TS2589), so `args` infers as the loose
-        // ShapeOutput<ZodRawShapeCompat> instead of the Zod schema above.
-        // Runtime shape is enforced by the schema; this re-asserts the typed
-        // contract at the consumer boundary. Task 404.
-        const result = await memoryTypedEdgePass(args, dbSession, accountId);
-        return {
-            content: [{
-                    type: "text",
-                    text: JSON.stringify(result),
-                }],
-        };
-    }
-    catch (err) {
-        return {
-            content: [{
-                    type: "text",
-                    text: `Typed-edge pass failed: ${err instanceof Error ? err.message : String(err)}`,
-                }],
-            isError: true,
-        };
-    }
-    finally {
-        await dbSession.close();
-    }
-});
-// ===================================================================
 // Dream-cycle (Task 327, absorbs 330)
 // ===================================================================
 // Report MCP tools (Task 332) are registered earlier in this file.