Offer mem0 as a place for shared memory to live

[ParallelEntrepreneur]

Summary

Shared memory gets a second provider beside files. Under Settings → Modules → Memory → Provider, mem0 keeps approved notes in your mem0 project through its Platform API (v3), and each colony's MEMORY.md lists the notes most relevant to its task first.

Nothing a colony can see or do changes, and that's deliberate.

• Review stays on the Mothership. Proposals queue locally as before, and mem0 only receives a note once you approve it.
• Notes are stored exactly as approved. Every write sends infer: false and immutable: true. With inference on, mem0's extraction model rewrites what it stores and later merges it with other memories, so a colony could read text nobody reviewed. add also treats a response without stored results as an error, because that's what an inferred write looks like.
• Colonies never talk to mem0 and never see the key. At boot the Mothership writes the colony's three scopes into its read-only session directory, in exactly the layout files mounts. memory_search, memory_propose and the prompt work with no change inside the guest.
• Other tools' memories are left alone. A scope is a mem0 user_id (colonizer:repo:<owner>/<repo> and so on), and every memory carries app_id: colonizer. Listing filters on both. Delete fetches the memory first and checks both, because a mem0 project can be shared.
• The key is stored like provider keys. It lives in config/memory-keys/mem0 (0600) with MEM0_API_KEY as a fallback, and is never written to modules.json or returned by the API. It gets its own row in Settings with Save, Remove and Check.

Failure never costs a colony or a proposal

When	What happens
mem0 is down at boot	The colony starts with an empty layout and logs a warning
An approval can't reach mem0	502 with the reason, and the proposal stays in the queue
Review is off and the store fails	The note is queued for review instead of dropped

One design choice worth a look

The relevance query is the task (issue title, instructions, issue body), not the prompt. The prompt was 2,225 characters in testing, and most of it is harness boilerplate shared by every colony. Sending it would pull every ranking toward the same notes, and a long preamble could push the task past the query limit. The query in the same test was 85 characters.

Test plan

• cargo test: 107 pass, 8 new. They cover the verbatim and immutable write, scope and app isolation on list and delete, refusing unsafe ids, a rejected key never appearing in an error, the colony layout ordered by relevance and rewritten on resume, and the task query.
• Clippy reports the same 11 warnings as main. tsc --noEmit and vite build are clean.
• End to end on a separate instance (its own port, data and config) against a local stand-in for the v3 API, since no mem0 key was available:
  • Picked mem0 in Settings, saved the key, and Check said "mem0 accepted the key". The key isn't in modules.json or in either API response, and the file is 0600 inside a 0700 directory.
  • Three notes reached the stand-in with the right scope user_id, app_id=colonizer, infer=false and immutable=true.
  • A real colony booted with shared memory: 3 notes from mem0, most relevant to this task first. Notes for another repo were left out.
  • Its agent read both indexes, found the mem0 note with memory_search, and proposed a note that came back through review.
  • Approving with mem0 stopped returned 502 and kept the proposal. Approving with mem0 back stored it with the colony and repo it came from.
• Against the real mem0 Platform with a real key. The stand-in follows mem0's published OpenAPI spec, but it isn't mem0.

Out of scope

• Self-hosted mem0 serves a different API. README and the Settings description say so.
• Semantic search from inside a colony. That would need a new colony-to-Mothership endpoint with scope enforcement, which deserves its own review rather than riding along here.