Update ob1-deployment.md via n8n
This commit is contained in:
parent
53ab72a6ed
commit
ef87389fac
@ -10,248 +10,278 @@ tags:
|
|||||||
- ob1
|
- ob1
|
||||||
- supabase
|
- supabase
|
||||||
- mcp
|
- mcp
|
||||||
- docker
|
- addendum
|
||||||
created: 2026-05-04
|
created: 2026-05-04
|
||||||
updated: 2026-05-04
|
updated: 2026-05-04
|
||||||
---
|
---
|
||||||
# OB1 Deployment Project Plan
|
# OB1 Deployment — Addendum
|
||||||
|
|
||||||
Deploy OpenBrain (OB1) as the personal AI memory layer on the homelab.
|
This addendum amends the original `ob1-deployment` project plan
|
||||||
OB1 is a self-hosted Postgres-plus-Supabase stack exposing MCP server
|
based on architectural decisions made during the wiki-construct
|
||||||
access for any compatible AI client. This becomes the persistent
|
design session on 2026-05-04. It does not replace the original
|
||||||
memory layer underneath Claude Code Dispatch, Claude Desktop, and
|
plan; it modifies specific phases and clarifies scope. Read this
|
||||||
eventually Pi or other harnesses.
|
alongside the original plan.
|
||||||
|
|
||||||
This plan is structured for hand-off to an agent after the OB1 repo is
|
## Context for the changes
|
||||||
cloned. Each phase has explicit deliverables, validation steps, and
|
|
||||||
stop conditions. The agent should pause after each phase for review
|
|
||||||
before proceeding.
|
|
||||||
|
|
||||||
## Background context the agent needs
|
The wiki-construct session crystallized the framing for personal
|
||||||
|
AI memory across the homelab:
|
||||||
|
|
||||||
- OB1 source: `github.com/NateBJones-Projects/OB1`
|
- **Wiki** is Travis's interface to his own thinking. Human-
|
||||||
- Architecture: Supabase (Postgres + GoTrue + PostgREST + Kong +
|
facing, organized for browsing in Obsidian. Agents read it
|
||||||
Studio + Edge Functions) with OB1's MCP server layered on top
|
only when explicitly pointed at a file.
|
||||||
- Target deployment node: Proxmox VM on the existing homelab (assume a
|
- **OB1** is Lovebug's working memory. Agent-facing, semantic
|
||||||
fresh Ubuntu 24.04 LTS VM unless directed otherwise)
|
search via MCP, captured automatically from sessions and
|
||||||
- Network: Tailscale mesh for remote access; Traefik already running
|
conversations.
|
||||||
on the homelab as the reverse proxy with HTTPS
|
|
||||||
- Auth model: Authelia in front of web-facing surfaces (Studio UI);
|
|
||||||
GoTrue stays for application identity and JWT issuance for AI clients
|
|
||||||
- This is a personal single-user deployment initially. RLS policies
|
|
||||||
should be in place but expect future expansion to a second user
|
|
||||||
(Jenny) for shared PBS context
|
|
||||||
- The user prefers Ansible for deployments and Docker Compose for
|
|
||||||
service orchestration. UV for any Python work. Never use
|
|
||||||
--break-system-packages
|
|
||||||
|
|
||||||
## Phase 0 — Repository inspection and environment audit
|
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.
|
||||||
|
|
||||||
Goal: understand what the agent is actually deploying before touching anything.
|
## Amendments to the original plan
|
||||||
|
|
||||||
Tasks:
|
### Phase 4 — Authelia and Traefik (deferred)
|
||||||
- [ ] Read the OB1 README and any deployment or setup docs in the repo
|
|
||||||
- [ ] Inventory the docker-compose.yml — list every service, its
|
|
||||||
image, ports, volumes, dependencies
|
|
||||||
- [ ] Identify which Supabase services OB1 actually requires versus
|
|
||||||
which are bundled but unused (Realtime, Storage, ImgProxy, Logflare
|
|
||||||
are likely candidates for disabling)
|
|
||||||
- [ ] Check the OB1 MCP server implementation — language, runtime,
|
|
||||||
dependencies, how it connects to Supabase
|
|
||||||
- [ ] Note any environment variables, secrets, or external
|
|
||||||
dependencies the deployment requires
|
|
||||||
- [ ] Check schema or migration files — understand the data model
|
|
||||||
before touching it
|
|
||||||
|
|
||||||
Deliverable: a written summary of what OB1 deploys, what's optional,
|
The original plan put Authelia + Traefik fronting in Phase 4 as
|
||||||
what's required, and what external resources (API keys, URLs, secrets)
|
part of baseline deployment. **Defer this entire phase** until
|
||||||
the user needs to provide.
|
there is a concrete user-facing reason to expose OB1 outside
|
||||||
|
Tailscale.
|
||||||
|
|
||||||
Stop condition: present the summary and the proposed Phase 1 plan to
|
Replacement scope for Phase 4:
|
||||||
the user for review before proceeding.
|
|
||||||
|
|
||||||
## Phase 1 — VM provisioning and base setup
|
- 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.
|
||||||
|
|
||||||
Goal: clean Ubuntu 24.04 VM ready to run OB1.
|
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.
|
||||||
|
|
||||||
Tasks:
|
This shortens the deployment by an estimated 30-40% of the
|
||||||
- [ ] Confirm with user: VM hostname, target Proxmox node, resource
|
Phase 4 task list and removes the most complex coordination
|
||||||
allocation (suggest 4 vCPU, 8GB RAM, 60GB disk as starting point —
|
with the existing Traefik / Authelia config.
|
||||||
adjust based on Phase 0 findings)
|
|
||||||
- [ ] Provision the VM via Proxmox (the user can do this manually;
|
|
||||||
agent should provide exact specs)
|
|
||||||
- [ ] Install Docker Engine and Docker Compose v2 (not the deprecated
|
|
||||||
docker-compose v1)
|
|
||||||
- [ ] Install Tailscale and join the mesh
|
|
||||||
- [ ] Confirm Tailscale connectivity from the user's dev rig
|
|
||||||
- [ ] Set up a non-root user for service operation (suggest
|
|
||||||
`ob1admin`) with Docker group membership
|
|
||||||
- [ ] Install basic operational tooling: htop, ncdu, git, curl, jq
|
|
||||||
|
|
||||||
Deliverable: a working VM accessible over Tailscale, with Docker
|
### Phase 3 — schema decisions (extended)
|
||||||
installed and the OB1 repo cloned to `/opt/ob1/` (or wherever the user
|
|
||||||
prefers).
|
|
||||||
|
|
||||||
Stop condition: confirm with user that the VM is reachable and base
|
The original Phase 3 deploys OB1's schema as-shipped. **Add one
|
||||||
setup is complete before proceeding to Phase 2.
|
forward-looking schema decision** before applying migrations:
|
||||||
|
|
||||||
## Phase 2 — Trimmed Supabase deployment
|
- **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.
|
||||||
|
|
||||||
Goal: get the Supabase stack running with only the services OB1 actually uses.
|
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.
|
||||||
|
|
||||||
Tasks:
|
This is a "design choice, not a feature" addition — no UI for
|
||||||
- [ ] Based on Phase 0 inventory, modify docker-compose.yml to disable
|
multi-user, no actual second user yet, just schema and policies
|
||||||
services OB1 doesn't require. Likely candidates for removal: Realtime,
|
in place so the door isn't accidentally closed.
|
||||||
Storage, ImgProxy, Logflare, Vector
|
|
||||||
- [ ] Generate strong secrets for: Postgres password, JWT secret, anon
|
|
||||||
and service role keys, dashboard credentials. Use the Supabase secret
|
|
||||||
generation pattern; do not reuse defaults
|
|
||||||
- [ ] Configure Postgres with conservative resource settings:
|
|
||||||
max_connections=20, shared_buffers=256MB. These can be tuned upward
|
|
||||||
later if needed
|
|
||||||
- [ ] Configure Kong's routing to only expose the services that remain
|
|
||||||
- [ ] Bring up the stack with `docker compose up -d` and wait for all
|
|
||||||
services to report healthy
|
|
||||||
- [ ] Verify Postgres is reachable from inside the Docker network
|
|
||||||
- [ ] Verify GoTrue is issuing tokens by creating a test user via the auth API
|
|
||||||
- [ ] Verify PostgREST is serving the auto-generated REST API
|
|
||||||
- [ ] Access Supabase Studio UI via Tailscale and confirm it loads
|
|
||||||
|
|
||||||
Deliverable: a running, trimmed Supabase stack on the VM. All services
|
### Phase 5 — client integration (refined)
|
||||||
healthy. Studio UI reachable over Tailscale.
|
|
||||||
|
|
||||||
Stop condition: confirm with user that Supabase is up and Studio is
|
The original Phase 5 wires Claude Code, Claude Desktop, and the
|
||||||
accessible. Get approval before proceeding to Phase 3.
|
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:
|
||||||
|
|
||||||
## Phase 3 — OB1 schema and MCP server
|
- The Obsidian write builds Travis's wiki (now structured per
|
||||||
|
the wiki-construct project)
|
||||||
|
- The OB1 write builds Lovebug's memory
|
||||||
|
|
||||||
Goal: deploy OB1's database schema and MCP server on top of the
|
Same source, two destinations, neither replacing the other.
|
||||||
working Supabase stack.
|
|
||||||
|
|
||||||
Tasks:
|
The n8n node added in Phase 5 should:
|
||||||
- [ ] Apply OB1's database migrations to Postgres — create the
|
|
||||||
thoughts table, any related tables, RLS policies, indexes including
|
|
||||||
the pgvector HNSW index
|
|
||||||
- [ ] Configure OB1's MCP server with the Supabase connection details,
|
|
||||||
JWT secret, and any API keys it needs (OpenAI for embeddings, or
|
|
||||||
Ollama URL for local embeddings — user preference)
|
|
||||||
- [ ] Decide with the user: cloud embeddings (OpenAI) for higher
|
|
||||||
quality, or local embeddings (Ollama on the dev rig with the 3080) for
|
|
||||||
zero cost and full data locality. Recommend local embeddings given
|
|
||||||
user's homelab philosophy and existing Ollama setup
|
|
||||||
- [ ] Run the MCP server (likely as a Docker container alongside
|
|
||||||
Supabase, or as a systemd service depending on what OB1 ships)
|
|
||||||
- [ ] Verify the MCP server starts cleanly and connects to Postgres
|
|
||||||
- [ ] Test capture: insert a test thought via the MCP server's capture
|
|
||||||
endpoint and verify it lands in the thoughts table with embedding and
|
|
||||||
metadata populated
|
|
||||||
- [ ] Test retrieval: query the MCP server's search endpoint and
|
|
||||||
verify it returns the test thought via semantic search
|
|
||||||
|
|
||||||
Deliverable: OB1 MCP server running and operational. Test thought
|
- POST the captured content to OB1's REST API
|
||||||
captured and retrievable.
|
- 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)
|
||||||
|
|
||||||
Stop condition: confirm with user that capture and retrieval work
|
### Phase 6 — operational hygiene (no changes)
|
||||||
end-to-end before proceeding.
|
|
||||||
|
|
||||||
## Phase 4 — Authelia integration and Traefik routing
|
The original Phase 6 stands. Backups, monitoring, Ansible
|
||||||
|
playbook, runbook, snapshot. Unchanged.
|
||||||
|
|
||||||
Goal: put OB1 behind the homelab's existing Authelia/Traefik perimeter.
|
### Phase 7 — Dispatch pre-compact hook (promoted from out-of-scope)
|
||||||
|
|
||||||
Tasks:
|
The original plan listed the Dispatch pre-compact hook as out-
|
||||||
- [ ] Add Traefik labels (or update Traefik dynamic config) to route to:
|
of-scope and "separate project". **Promote this to Phase 7 of
|
||||||
- Supabase Studio UI (Authelia-protected)
|
this project**, immediately following Phase 6, as the closing
|
||||||
- PostgREST API (Authelia-protected for direct access; bypassed for
|
phase.
|
||||||
MCP server which uses JWTs)
|
|
||||||
- GoTrue auth endpoints (no Authelia — these need to be reachable
|
|
||||||
for JWT operations)
|
|
||||||
- OB1 MCP server endpoint (no Authelia — clients use JWTs, not
|
|
||||||
browser sessions)
|
|
||||||
- [ ] Configure Authelia access control rules for the new routes
|
|
||||||
- [ ] Verify HTTPS works for all exposed endpoints via Traefik
|
|
||||||
- [ ] Test browser access to Studio: should hit Authelia login, then
|
|
||||||
proceed to Studio
|
|
||||||
- [ ] Test MCP server access: should bypass Authelia and authenticate
|
|
||||||
via JWT only
|
|
||||||
- [ ] Document the final URL map for the user
|
|
||||||
|
|
||||||
Deliverable: OB1 properly fronted by Traefik with Authelia gating
|
Reason: until the pre-compact hook is shipping captures into
|
||||||
browser surfaces. JWT-based clients reach the MCP server directly.
|
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.
|
||||||
|
|
||||||
Stop condition: confirm full access pattern works from both browser
|
Phase 7 scope:
|
||||||
(Authelia path) and AI client (JWT path).
|
|
||||||
|
|
||||||
## Phase 5 — Client integration
|
- 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
|
||||||
|
|
||||||
Goal: connect Claude Code, Claude Desktop, and the existing n8n flows to OB1.
|
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.
|
||||||
|
|
||||||
Tasks:
|
## Scope clarifications (no plan change, just sharpening)
|
||||||
- [ ] Generate a long-lived JWT or service-role API token for AI
|
|
||||||
client use. Store in the user's KeePassXC database
|
|
||||||
- [ ] Configure Claude Code's MCP integration to point at OB1's MCP
|
|
||||||
server. Test capture and search from a Claude Code session
|
|
||||||
- [ ] Configure Claude Desktop's MCP integration similarly. Test
|
|
||||||
capture and search from a Desktop conversation
|
|
||||||
- [ ] Add a node to the existing n8n markdown-summary intake flow that
|
|
||||||
POSTs captured content to OB1's REST API in parallel with the existing
|
|
||||||
Obsidian write. Map frontmatter fields to OB1 metadata
|
|
||||||
- [ ] Test the full capture loop: send a test summary email through
|
|
||||||
the existing flow and verify it lands in both Obsidian and OB1
|
|
||||||
- [ ] Document the n8n flow modifications for the user
|
|
||||||
|
|
||||||
Deliverable: OB1 receiving captures from Claude Code, Claude Desktop,
|
### What OB1 is for
|
||||||
and the n8n email-intake pipeline. All three paths verified working.
|
|
||||||
|
|
||||||
Stop condition: confirm all three capture paths work and the user can
|
- Lovebug's working memory across Dispatch sessions
|
||||||
perform an end-to-end test from any AI client.
|
- 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)
|
||||||
|
|
||||||
## Phase 6 — Operational hygiene
|
### What OB1 is not for
|
||||||
|
|
||||||
Goal: make the deployment maintainable.
|
- 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
|
||||||
|
|
||||||
Tasks:
|
### How OB1 and the wiki interact
|
||||||
- [ ] Set up a daily Postgres backup via pg_dump to the Ubuntu NAS
|
|
||||||
over Tailscale
|
|
||||||
- [ ] Add the OB1 VM to existing monitoring (Uptime Kuma if it's
|
|
||||||
monitoring infra services)
|
|
||||||
- [ ] Document the deploy in an Ansible playbook so future
|
|
||||||
re-provisioning is automated
|
|
||||||
- [ ] Write a brief runbook covering: how to update OB1, how to
|
|
||||||
restore from backup, how to rotate the JWT secret, how to add a new
|
|
||||||
client
|
|
||||||
- [ ] Snapshot the VM via Proxmox once everything is verified working
|
|
||||||
|
|
||||||
Deliverable: backups running, monitoring in place, Ansible playbook
|
In Phase 1 of both projects: they don't, beyond the parallel
|
||||||
captures the deploy, runbook written, snapshot taken.
|
n8n write described above. Travis uses the wiki to think.
|
||||||
|
Lovebug uses OB1 to remember its own work and conversations.
|
||||||
|
|
||||||
Stop condition: project complete. Hand off to user for ongoing use.
|
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.
|
||||||
|
|
||||||
## Out of scope
|
The wiki should never be designed for OB1 to consume, and OB1
|
||||||
|
should never be designed to maintain wiki content. Keep them
|
||||||
|
parallel.
|
||||||
|
|
||||||
These are intentionally not part of this plan:
|
## Dependencies and ordering
|
||||||
|
|
||||||
- Building a custom technical-project extension for OB1 (separate
|
The wiki-construct project does not block OB1. They can run in
|
||||||
project, after baseline is operational)
|
parallel. Travis's stated preference is wiki-first, but that's a
|
||||||
- Adding Jenny as a second user with PBS-scoped access (separate
|
bandwidth decision, not a technical dependency.
|
||||||
project, after Jenny's content workflow lands)
|
|
||||||
- Pre-compact hook for Dispatch transcript capture (separate project —
|
|
||||||
needs design work on what to capture and how to filter noise)
|
|
||||||
- Migrating existing Obsidian content into OB1 retroactively (separate
|
|
||||||
project — bulk import path)
|
|
||||||
|
|
||||||
## Agent operating instructions
|
If wiki-construct ships first:
|
||||||
|
|
||||||
- Work one phase at a time. Stop and report at the end of each phase.
|
- The n8n markdown-summary flow will already be writing to a
|
||||||
Wait for user confirmation before proceeding to the next phase
|
structured wiki when OB1 Phase 5 adds the parallel OB1 write
|
||||||
- For any ambiguous decision, ask the user rather than guessing
|
- Frontmatter conventions will already be stable, simplifying
|
||||||
- Never expose the homelab to the public internet during this
|
the OB1 metadata mapping
|
||||||
deployment. Tailscale mesh is the only access path
|
|
||||||
- All secrets generated during deployment go into the user's KeePassXC
|
If OB1 ships first:
|
||||||
database. Never write them to disk in plaintext outside the running
|
|
||||||
Docker environment
|
- Wiki-construct's compile loop is unaffected (it doesn't read
|
||||||
- Use the user's preferred tooling: Docker Compose for orchestration,
|
from OB1)
|
||||||
Ansible for repeatable deployment steps, UV for any Python work
|
- The Phase 5 n8n write will need to be revisited once the
|
||||||
- If a step fails, do not retry blindly. Report the failure with the
|
wiki's frontmatter conventions land
|
||||||
actual error output and propose next steps
|
|
||||||
- The user prefers concise updates — report what was done, what's
|
Either order works.
|
||||||
next, and any blockers. Skip the celebratory framing
|
|
||||||
|
## 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
|
||||||
Loading…
Reference in New Issue
Block a user