pbs-projects/Tech/Projects/ob1-deployment.md

---
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