Memory & Search — Mallory Estate Briefing

Memory & Search

A searchable Memory surface plus a real, reviewable facts store — nothing activates without an explicit confirm.

Dated 2026-06-20Programme Memory & Search

Situation

The classifier types a turn as recall, searchCorpus runs, and a ## Recall block is injected — but there's no direct search, no browsable history, and no facts store; "what Mallory knows" today is just the FTS corpus. Phase 2 adds a first-class Memory surface: search/browse past conversations and vault notes directly, and a real facts memory Mallory applies in conversation.

Capture is deliberately conservative: explicit ("remember that …", instant) plus reviewed-auto (extraction proposes facts; nothing activates without a one-tap confirm) — no silent writes, ever.

Key decisions

Search surface and facts store, one spec

Designed together but built as two independently-shippable layers.

Capture: explicit + reviewed-auto

"Remember that X" writes instantly; a periodic extraction cron proposes candidate facts that require a one-tap confirm before they ever activate.

Storage: D1 canonical + vault backup

D1 is the fast, app-managed source of truth; a periodic Hub job exports active facts to a human-readable Memory/about-alex.md — one-way, edge to vault.

Usage: pinned core + retrieval

A small always-on ## About Alex block carries pinned facts on every turn; the rest join the normal FTS retrieval path and surface only when relevant.

Forget is real

A per-fact forget soft-deletes (forgotten_at) and drops from search/pinned/vault-export; a clear-all hard-deletes everything.

Architecture

Reuses the existing FTS engine and recall path; adds one new table and one new web surface.

memories table + memories_fts

Canonical facts store (proposed/active, explicit/extracted, pinned, soft-delete) mirroring the messages_fts contentless pattern.

GET /search

Runs the full three-corpus search (conversations, notes, facts) at a higher k for the web view; the in-turn recall path keeps its own smaller k.

Capture paths

POST /memory for explicit writes; a Worker extraction cron over recent conversations proposing deduped candidate facts via a cheap model.

Pinned-core injection

selectPinnedCore(facts, cap=10) — a pure, capped, always-on ## About Alex block injected into chat.ts's context assembly.

MemoryView.svelte (new)

Search box, browse/empty state, and a facts section (pin/forget) plus a review queue for proposed facts.

Hub vault-backup export

GET /memory/export (Access-gated) feeds a periodic cron job that writes the grouped, human-readable vault note.

Risks & guardrails

One-way vault export

Obsidian edits to the exported note aren't re-imported this phase — noted explicitly as a future option, not solved now.

Extraction cron cost/quality

Proposals depend on a cheap model over recent conversations; dedup against existing active/proposed facts must hold or the review queue floods.

No cross-device read-state

The review queue's read/seen state isn't synced across devices in this phase.

Delivery

Layer 1 — Search surface

GET /search (reuse searchCorpusWith) + MemoryView search/browse/jump. Ships first, mostly assembly.

Layer 2 — Facts store

Migration (memories + FTS), POST/GET /memory, explicit-capture intent, extraction cron, pinned-core injection, facts/review UI, Hub vault-backup export.

Out of scope

Obsidian → edge re-import of hand-edited factsAuto-activation of extracted facts (always reviewed)Cross-device read-state for the review queueActing on facts (writes/reminders) — Phase 4Relationship graphs / entity resolution beyond a flat categorised fact list

spec · docs/superpowers/specs/2026-06-20-memory-and-search-design.md
plan · docs/superpowers/plans/2026-06-20-memory-and-search.md

Mallory · Estate briefing