wiki-vault/Sources/Homelab/ob1-deployment.md

created	path	project	status	tags	type	updated
2026-05-04	Sources/Homelab	ob1-deployment	active	homelab ai memory ob1 supabase mcp addendum	project-plan	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