The six timeline pages tell the story stage by stage. This page is the other view: a straight list of what each build stage actually added, what’s live right now, and what’s still ahead — for a reader who wants the shape of the whole project in one scan rather than the narrative.
Stages
| Stage | Dates | What it added |
|---|---|---|
| Stage 0 — Foundation | 20–23 Jun 2026 | The six-tool MCP server built and deployed to the Gen8 MicroServer for the first time; a golden-set of test queries authored to give the build something real to check itself against, rather than trusting its own test suite. |
| Stage 1 — Core write path | 21 Jun – 8 Jul 2026 | The architecture from [[mem-local/02-architecture-decisions |
| Stage 1.1 — Debug & test-hardening | 9–13 Jul 2026 | Triggered by a real finding: the tests were green while the actual write path was broken. The acceptance battery was widened specifically to catch that class of false-positive again. |
| Stage 1.2 — Write-path vocabulary integrity | 14–16 Jul 2026 | Tightened the gated vocabularies (domain, entity_type/status/type on project and area nodes) so a proposal can’t silently smuggle in an unlisted value. |
| Stage 1.3 — Write-path reachability | 16–23 Jul 2026 | The largest single push (Decisions AO through AQ). Confirmed confidence is a dead field (AP-3, see [[mem-local/theme-human-approval-write-gate |
| Steady-state capture — ongoing since Aug 2026 | Aug 2026 → now | No more stage numbers — this is the system doing its actual job: individual propose/approve captures as things come up (the temporal-grounding skill in [[mem-local/05-conventions-and-discipline |
Where it stands right now
Pulled directly from the store’s own project node, not from chat history:
- Live and proven. Stage 1 plus all three hardening stages are built, deployed, and on-box-proven. The write path is fully reachable: a proposer sets
name,provenance, and the four vocabulary axes;local_onlyis set only at the approve door, never by the proposer; entity IDs mint on approval. - The decision backfill is done. Roughly 40 settled register decisions have been captured as twelve density-weighted nodes (
e3–e14), plus abuilds_onspine chaining Stage 0 → 1.1 → 1.2 → 1.3. - Running on: the Gen8 HP MicroServer under Unraid,
bge-base-en-v1.5embeddings served via Ollama off the Quadro P400, nginx/NPM fronting the connection over TLS with a fail-closed Origin check, replicated continuously to the desktop’s spare SSD via Litestream.
What’s next / still open
- Validate
SKILL.mdon its own (e2,e29) — take@meminto unrelated projects and treat every stumble as a documentation defect, not a one-off fix. Not yet done; a by-exception manual is deliberately ordered after this, not before. - Path 2 — historical semantic search — deliberately deferred, not built. The plan: deliberate-invocation compute on the Hackintosh’s RX 6600 XT, over a read-only replica of the store, re-embedding retained assertion text on demand rather than keeping every historical vector live. Two invariants protect it: the replica is read-only, and it never joins the live MCP path. Full detail: 06-open-questions.
- Hard deletion — left open by design. Append-only means no row is removed by default; a genuine erasure (for something that shouldn’t have entered the store) has a wider blast radius than the one row asked for. Explicitly parked, with the condition that it must be settled before anything genuinely sensitive enters the store.
- A personal-utility / exploration surface — named as a future aim in the store’s own project description, not yet scoped or started.
Multi-device and off-network access
Two different questions live under “can I use this on my phone,” and the chat history shows only one of them is actually solved.
- Any device on the home network — solved, and it’s why the transport is what it is. The original transport plan (stdio-over-SSH) was dropped specifically because David stated the requirement directly: “I would be able to call memory from any device on my local network (or perhaps even remotely) - so that’s currently a PC, macOS (hackintosh), Android phone, or iPad.” (18 Jun 2026). stdio can’t reach a mobile MCP client at all; Streamable HTTP, fronted by nginx, can. That’s Decision B, and it’s live today — PC, hackintosh, phone, and iPad can all reach mem-local over the LAN through the same connector config.
- Off-network (away from the house) — deliberately deferred, not built. The domain and certificate were chosen with this in mind: the DuckDNS hostname uses a real, publicly-issued Let’s Encrypt certificate (via DNS-01) rather than a self-signed
.localone, precisely because “if off-LAN access is even a maybe-someday… a real domain you own with a proper cert now means you’re not re-doing the cert story later.” But as deployed, that domain only resolves to the LAN IP via an internal AdGuard DNS rewrite — there’s no port-forward or public exposure behind it. The design register’s own plan for closing this gap names a specific mechanism, not yet acted on: “Stage 3 in the design has it as a deferred WireGuard/Tailscale question” — i.e. a VPN tunnel into the home network, not exposing the raw MCP endpoint to the open internet, consistent with the fail-closed philosophy running through the rest of the build. Nothing later in the export picks this back up. - One thing this can’t answer: whether the Claude mobile app itself currently supports adding a custom MCP connector at all, independent of mem-local’s own readiness. That’s a live product-capability question, not a design one, and it’s worth checking directly rather than assuming either way.
What’s actually in the mobile app’s “Add custom connector” dialog
Checked directly (1 Sep 2026): the mobile app does have this option — Name, MCP server URL, and OAuth Client ID/Secret if the server uses OAuth. The values are known (a name and the server’s /mcp URL, OAuth fields left blank since the front uses a bearer token, not OAuth), but two problems from the July build surface again here rather than being newly solved:
- No field carries the bearer token. This is the same “Custom Connector” UI Desktop tried first in July and abandoned — it reaches the server from Anthropic’s cloud, and its dialog has never had a plain-header field. Desktop’s actual working setup bypasses this UI entirely, editing
claude_desktop_config.jsondirectly to inject theAuthorizationheader viamcp-remote. Mobile has no equivalent local config file, so there is currently no known way to get the token into a mobile connector. - Reachability, independently. Because this path connects from Anthropic’s cloud rather than a device on the LAN, it also needs the hostname to resolve and route from the public internet — which, per the off-network gap above, it currently doesn’t.
Net: the mobile “Add custom connector” screen existing doesn’t mean off-network access is solved — it’s the same deferred gap, just visible from a different angle. Closing it needs both a token-delivery mechanism the mobile UI actually supports (OAuth on the front, most plausibly) and the WireGuard/Tailscale (or equivalent) exposure step above.
Sources: live mem-local store (proj:ai-memory-system and its immediate neighbourhood, queried 1 Sep 2026); 01-origin-and-requirements through 06-open-questions; conversation titles across the build (Memory system build stage 0 oversight, 20 Jun; Memory system build stage 1.1 development, 9 Jul; Local-memory build stage 1.2 oversight, 14 Jul; Stage 1.3 oversight and decision-making, 16 Jul; Inspection of approve_proposal directive and edge-creation reachability, 22 Jul).