--- project: ob1-deployment type: project-plan status: active path: Tech/Projects tags: - homelab - ai - memory - ob1 - supabase - mcp - addendum created: 2026-05-04 updated: 2026-05-04 --- # OB1 Deployment — Addendum This addendum amends the original `ob1-deployment` project plan based on architectural decisions made during the wiki-construct design session on 2026-05-04. It does not replace the original plan; it modifies specific phases and clarifies scope. Read this alongside the original plan. ## Context for the changes The wiki-construct session crystallized the framing for personal AI memory across the homelab: - **Wiki** is Travis's interface to his own thinking. Human- facing, organized for browsing in Obsidian. Agents read it only when explicitly pointed at a file. - **OB1** is Lovebug's working memory. Agent-facing, semantic search via MCP, captured automatically from sessions and conversations. The two systems are parallel and complementary, not unified. This framing changes the OB1 plan less than expected — most of the original plan still stands — but it sharpens scope around what OB1 is and isn't responsible for. ## Amendments to the original plan ### Phase 4 — Authelia and Traefik (deferred) The original plan put Authelia + Traefik fronting in Phase 4 as part of baseline deployment. **Defer this entire phase** until there is a concrete user-facing reason to expose OB1 outside Tailscale. Replacement scope for Phase 4: - Tailscale-only access for all OB1 surfaces (Studio UI, REST API, MCP server) - Document the URL map for the user (Tailscale hostnames / ports for each surface) - Confirm that the JWT-bearing MCP path stays Tailscale-only forever — even when Authelia is eventually added in front of browser surfaces, agent endpoints stay on Tailscale. This is a design invariant, not a phase choice. Authelia goes back on the roadmap when Jenny's interface lands or when there's another reason to put a browser surface on the public web. Not before. This shortens the deployment by an estimated 30-40% of the Phase 4 task list and removes the most complex coordination with the existing Traefik / Authelia config. ### Phase 3 — schema decisions (extended) The original Phase 3 deploys OB1's schema as-shipped. **Add one forward-looking schema decision** before applying migrations: - **User scoping from day one.** Schema includes a `user_id` or equivalent tenant column on every captured row, with RLS policies enforced, even though the deployment is single-user (Travis only) at first. Rationale: Jenny's eventual interface (PBS-public web surface served from the PBS site) will require multi-user support. Row- level security retrofitted later is painful. RLS designed in from day one is cheap. This is a "design choice, not a feature" addition — no UI for multi-user, no actual second user yet, just schema and policies in place so the door isn't accidentally closed. ### Phase 5 — client integration (refined) The original Phase 5 wires Claude Code, Claude Desktop, and the n8n markdown-summary flow to OB1. All three remain in scope. **Refinement:** the n8n flow modification should write to OB1 *in parallel* with the existing Obsidian write, not in place of it. The two systems serve different purposes: - The Obsidian write builds Travis's wiki (now structured per the wiki-construct project) - The OB1 write builds Lovebug's memory Same source, two destinations, neither replacing the other. The n8n node added in Phase 5 should: - POST the captured content to OB1's REST API - Map relevant frontmatter fields to OB1 metadata (project, domain, tags, dates) - Tag OB1 captures with their wiki-vault path so cross- reference is possible later if needed - Run after the Obsidian write succeeds (Obsidian is the primary destination; OB1 capture is additive) ### Phase 6 — operational hygiene (no changes) The original Phase 6 stands. Backups, monitoring, Ansible playbook, runbook, snapshot. Unchanged. ### Phase 7 — Dispatch pre-compact hook (promoted from out-of-scope) The original plan listed the Dispatch pre-compact hook as out- of-scope and "separate project". **Promote this to Phase 7 of this project**, immediately following Phase 6, as the closing phase. Reason: until the pre-compact hook is shipping captures into OB1, OB1 is not actually serving its primary purpose as Lovebug's working memory. Phases 1-6 deploy a database with Claude Code MCP captures and email-summary captures, but no Dispatch session captures. Dispatch sessions are where the bulk of Lovebug's work happens. Without the hook, OB1 has the wrong memory. Phase 7 scope: - Design what Dispatch sessions capture (full transcript, decisions only, summaries only — needs design work) - Design noise filtering (Dispatch sessions include a lot of routine command output that shouldn't end up in semantic memory) - Implement the pre-compact hook integration - Test capture end-to-end: run a Dispatch session, verify meaningful content lands in OB1, verify retrieval surfaces the right thing - Document the hook for future modification Phase 7 is its own meaningful design exercise — what to capture is not obvious. Treat it as a multi-session phase with its own design step before implementation. ## Scope clarifications (no plan change, just sharpening) ### What OB1 is for - Lovebug's working memory across Dispatch sessions - Lovebug's memory across Claude Code sessions - Captures of Travis's email-summary intake (the same content that builds the wiki, captured in parallel for semantic search) - Eventually: agent-execution session notes from coding projects (currently captured alongside code in the project repo; eventually flow into OB1 for cross-project recall) ### What OB1 is not for - Travis's curated knowledge (that's the wiki) - Long-form synthesis (that's the wiki) - Human browsing (Studio UI is for inspection and troubleshooting, not daily reference) - Replacement for the wiki — the two systems coexist ### How OB1 and the wiki interact In Phase 1 of both projects: they don't, beyond the parallel n8n write described above. Travis uses the wiki to think. Lovebug uses OB1 to remember its own work and conversations. In some Phase 2 future: a context assembler may query both layers when bundling prompts — semantic search across OB1 plus explicit wiki references when Travis points at specific pages. This is deferred and should not influence Phase 1 architecture decisions. The wiki should never be designed for OB1 to consume, and OB1 should never be designed to maintain wiki content. Keep them parallel. ## Dependencies and ordering The wiki-construct project does not block OB1. They can run in parallel. Travis's stated preference is wiki-first, but that's a bandwidth decision, not a technical dependency. If wiki-construct ships first: - The n8n markdown-summary flow will already be writing to a structured wiki when OB1 Phase 5 adds the parallel OB1 write - Frontmatter conventions will already be stable, simplifying the OB1 metadata mapping If OB1 ships first: - Wiki-construct's compile loop is unaffected (it doesn't read from OB1) - The Phase 5 n8n write will need to be revisited once the wiki's frontmatter conventions land Either order works. ## Open items - [ ] Decide cloud (OpenAI) vs. local (Ollama on RTX 3080) embeddings during Phase 3 (recommendation in original plan stands: local) - [ ] Phase 7 design: what to capture from Dispatch sessions and how to filter noise - [ ] Confirm OB1's schema supports `user_id` / tenant scoping cleanly during Phase 0 inventory; if not, this becomes a schema extension rather than a configuration choice ## Tasks (additions and changes only) ### Phase 0 — Repository inspection (one addition) - [ ] Confirm OB1's schema supports user-scoping or determine the minimal extension needed ### Phase 3 — Schema and MCP server (one addition) - [ ] Apply user-scoping schema extension if needed - [ ] Verify RLS policies enforce single-user access correctly (Travis sees only Travis's rows, even though there's only one user) ### Phase 4 — Tailscale-only access (replaces original Phase 4) - [ ] Document Tailscale URL map for all OB1 surfaces - [ ] Confirm MCP path is reachable over Tailscale from Travis's dev rig and from herbydev - [ ] Document the design invariant: MCP path stays Tailscale- only permanently - [ ] Defer Authelia + Traefik integration explicitly ### Phase 5 — Client integration (one refinement) - [ ] Confirm n8n write to OB1 runs in parallel with Obsidian write, not in place of it - [ ] Tag OB1 captures from the email flow with their wiki-vault path ### Phase 7 — Dispatch pre-compact hook (new) - [ ] Design: what Dispatch sessions capture - [ ] Design: noise filtering rules - [ ] Implementation: pre-compact hook integration - [ ] Test: end-to-end capture and retrieval from a Dispatch session - [ ] Document: hook configuration for future modification ## Phase 1 done when (amended) The original plan's "project complete" trigger stands, with one addition: **the Dispatch pre-compact hook is shipping captures into OB1 and Lovebug is using them.** Without that, OB1 is deployed but not yet doing its primary job. Consider OB1 truly operational only after Phase 7. Phases 1-6 deploy the substrate; Phase 7 turns it on. ## Notes - This addendum is not a re-plan. The original phases 1-3 and 6 are unchanged. Phase 4 is shrunk. Phase 5 is refined. Phase 7 is added. - The wiki-construct project is the sibling project. Its plan and skill bundle land separately. They do not depend on each other. - The framing decisions in this addendum (wiki for human, OB1 for agent, parallel not unified) are load-bearing. If anything in the deployment seems to push back on that framing — e.g., "should OB1 also serve the wiki?" or "should the wiki feed OB1 automatically?" — stop and confirm with Travis before proceeding. The instinct to unify is wrong; the instinct to keep parallel is correct. -- ...sent from Jenny & Travis