Controlplane: cross-session chat search + memory layer (Claude's pattern)

[heavygee]

Problem

The controlplane / overseer notion (#10) is fundamentally a long-running agent that must:

• Know about every project, every PR, every session
• Remember decisions made days/weeks ago
• Track which issue spawned which session that spawned which PR

This is more context than any single session window can hold. Without persistent searchable memory, the controlplane becomes amnesiac after a few hundred messages and either forgets prior decisions or asks the operator to re-ground it every time.

Claude has shipped the primitive we need:

https://support.claude.com/en/articles/11817273-use-claude-s-chat-search-and-memory-to-build-on-previous-context

Cross-conversation search + memory that builds on previous context.

Proposal

Implement a memory + search layer for the controlplane (and optionally for all sessions):

1. Per-session memory -- already kind of exists in the message history.
2. Cross-session memory -- FTS5 (SQLite full-text search) over all messages for a given user/project, with metadata filters (session id, role, timestamp, channel source).
3. Memory tool -- agents call searchMemory({query, scope?: 'session' | 'project' | 'all'}) to retrieve past context relevant to the current turn.
4. Active recall -- agents emit "remember this" markers (<memory>...</memory>) for important decisions. The memory layer indexes these with higher weight.
5. Compaction-aware -- when a session's context window fills, the memory layer can serve compressed summaries of older turns from this store.

Inspiration: the context-mode MCP project that's already in use here uses FTS5 + auto-indexing for exactly this pattern. Steal liberally.

Acceptance

• Memory store backed by SQLite FTS5
• searchMemory tool callable from any session
• Controlplane (Tooling: agent-driven fileFutureIdea tool that posts to fork issues #10) wired to search across all sessions for a project by default
• Cross-session results surface session id + clickable refs (UX: TL;DR-first response rendering with expand-to-full setting #9)
• No PII / secret leakage across user boundaries (out of scope for single-user fork, but design with it in mind)

Notes

• Without this, Tooling: agent-driven fileFutureIdea tool that posts to fork issues #10 (project page / dispatcher) doesn't scale beyond a handful of sessions.
• The MCP context-mode server present in this dev environment is a working prototype of the same pattern -- maybe directly adopt as a HAPI integration?
• Pair with STT: OpenWhispr local listening pipeline -> HAPI things-to-do inbox #5 (TL;DR rendering) -- memory entries can themselves be TL;DR-rendered.

[heavygee]

Fleet Overseer architecture cross-reference (#19)

Absorbed: cross-session memory becomes the Overseer's saved-filter views over the events table. The substrate lands in #22 (events + event_links + FTS5) and the read query tools land in #25 (read-only Overseer tool set: query_events, query_inbox, etc.). Memory promotion rules are contracts §7. Track under the umbrella #19; this issue can be closed as absorbed once #22/#25 land, or kept as the "saved-filter views" sub-task.