--- name: operate-ob1-openbrain-with-jarvis description: Use OB1/Open Brain with Hermes/Jarvis as a question, capture, weekly-review, and work-operating-model extraction layer rather than a simple memory database. version: 0.1.0-local author: Jarvis local integration worktree --- # Operate OB1 / Open Brain with Jarvis ## Use when - The user asks why OB1 was installed. - The user expects Hermes/Jarvis to ask questions, capture context, review patterns, or build operating files. - The user references Open Brain companion prompts, Work Operating Model Activation, USER.md, SOUL.md, HEARTBEAT.md, or weekly review. - The user says all Hermes surfaces should reflect OB1. ## Core interpretation Do not reduce OB1 to a dashboard or generic memory DB. For this user, OB1/Open Brain is the layer that turns tacit work knowledge into reusable operating context: ```text questions -> user confirmation -> structured capture -> review -> operating artifacts ``` Open Brain has two runtime layers: 1. **Core Open Brain MCP** - `search_thoughts` - `list_thoughts` - `thought_stats` - `capture_thought` 2. **Work Operating Model MCP** - `start_operating_model_session` - `save_operating_model_layer` - `query_operating_model` - `generate_operating_model_exports` If Work Operating Model tools are missing, say clearly that only core Open Brain is connected. ## Companion prompts operating order ### 1. Memory Migration Use after core Open Brain is connected and the user wants existing AI memory moved into Open Brain. Rules: - Extract only what actually exists in memory/session/local evidence. - Organize by category. - Preview before saving. - Save only approved items with `capture_thought`. - Each thought must be a standalone sentence another AI can understand. ### 2. Second Brain Migration Use only when the user explicitly wants Notion, Obsidian, Apple Notes, CSV, n8n logs, or text files copied into Open Brain. Rules: - Copy, do not move/delete originals. - Parse source format as-is. - Break into self-contained thoughts. - Preview batches before saving. - Preserve people, dates, decisions, and context. ### 3. Open Brain Spark Use when the user asks what to put into Open Brain or how OB1 should fit their actual workflow. Ask about: - daily tools - repeated decisions - what the user keeps re-explaining to AI - what they forget that costs time/quality - key people and stakeholders Output: - personalized first capture ideas - what to capture and why - not generic feature pitches ### 4. Quick Capture Templates Use as capture habits, not as architecture. Preferred patterns: ```text Decision: [what was decided]. Context: [why]. Owner: [who]. [Name] — [what happened or what you learned about them]. Insight: [the thing you realized]. Triggered by: [what made you think of it]. Meeting with [who] about [topic]. Key points: [important stuff]. Action items: [next steps]. Saving from [AI tool]: [key takeaway worth keeping]. ``` ### 5. Weekly Review Use after enough captures exist. Retrieve last 7 days of thoughts and action items, then produce: - Week at a Glance - Themes - Open Loops - Connections - Gaps If fewer than 3 thoughts exist, say the review will be weak and ask whether to do a quick brain dump first. ## External prompt-kit documents: how to absorb them When the user brings Google Docs / prompt kits about modern AI prompting, Open Brain companion prompts, constraint architecture, self-contained problem statements, or agent delegation, do **not** treat every document as the same kind of Hermes setting. Classify first: 1. **Agent delegation / specification / constraint documents** - Core concepts: self-contained problem statement, acceptance criteria, constraint architecture, decomposition, evaluation design. - Hermes use: compress into Jarvis operating constraints, not a full SOUL dump. - Best target: `SOUL.md` decision rules, `HEARTBEAT.md` checklist, and Work Operating Model `institutional_knowledge` / `friction` entries. - Key frame for this user: these documents prevent the “smart-but-wrong” failure where Jarvis technically answers but misses that OB1 setup is the urgent bottleneck. 2. **Open Brain companion prompt documents** - Core prompts: memory migration, second brain migration, brain spark, quick capture templates, weekly review. - Hermes use: OB1 operating playbook / capture habits, not general architecture. - Best target: Open Brain skill/playbook, Dashboard quick-capture cards, weekly review heartbeat, and approved OB1 captures. - Immediate use for this user: Brain Spark + Quick Capture. Defer bulk Memory Migration / Second Brain Migration until preview, dedupe, contamination filtering, and approval. 3. **Runtime setup docs** - Core use: provision or verify server/client tools. - Best target: read-only runtime checklist and fresh-session smoke tests before any persistence. Do not paste long prompt kits wholesale into `SOUL.md`; that makes the already-heavy `jarvis01` profile worse. Extract the shortest actionable rules: ```text MUST DO / MUST NOT DO / PREFER / ESCALATE ``` For this user, a minimal Jarvis Constraint Architecture should preserve: - MUST DO: prioritize OB1 server-brain rollout when the user says repeated explanation is killing them; verify current state before claiming; do safe work directly. - MUST NOT DO: drift into profile/GitHub/cofounder/document architecture when the user has identified OB1 setup as the urgent bottleneck; treat memory/Honcho/summary as canonical; secretly create or overwrite canonical docs. - PREFER: OB1 as server brain, local/GitHub docs as human-readable SSOT, worktree as safe workbench, Dashboard as cockpit, Paperclip later as execution control. - ESCALATE: canonical `SOUL/USER/HEARTBEAT` overwrite, external OB1 writes, DB migrations, gateway restart, GitHub publication/sharing, billing/auth/permission changes. Open Brain companion prompts should be sequenced for this user as:\n\n```text\nConstraint Architecture -> Brain Spark -> Quick Capture -> WOM remaining layers -> contradiction pass -> exports -> preview-only memory migration -> weekly review automation\n```\n\nAdditional operator rule from live use:\n- do not stop at tool/architecture mapping alone. This user reacts badly when the agent can describe OB1/GitHub/Paperclip/Honcho correctly but still fails to capture **who the representative is, how they work, what they hate repeating, and what they expect the operator to do without asking**.\n- before calling the continuity repaired, externalize a short representative-centered operating note alongside the technical state. In this session the useful pattern was a local file like `05_대표님_작동방식_초안.md` that records: repetition intolerance, engineer-not-chatbot expectation, CEO-facing report shape, anti-jargon preference, non-destructive-autonomous execution boundary, and the need to center the representative rather than the tool graph.\n- if the user says variants of “you didn't see me / 나를 안 봤다”, treat that as a first-class operating-model gap, not a tone issue. If the user asks “is this different?” answer first: constraint/spec documents govern **how Jarvis acts**; Open Brain companion prompts govern **what gets captured/reviewed in OB1**. They are complementary, not alternatives. ## Work Operating Model Activation Use when the user wants Jarvis to interview them and build operating files. Required tools: - core Open Brain search/capture - Work Operating Model start/save/query/export tools Fixed layers: 1. operating rhythms 2. recurring decisions 3. dependencies 4. institutional knowledge 5. friction Rules: - Start concrete: recent week, recent month, recent waits, recent misses. - Search results are hints, not facts. - Never save a retrieved hint unless the user confirms it or approves a synthesis. - Show checkpoint summary after each layer. - Do not stop at “승인해 주세요” if more local preparation is possible. Before asking for approval, prepare the exact `save_operating_model_layer` payload locally, validate it against the layer schema, attach critic review for important decisions, and record expected post-write verification. - Wait for explicit confirmation before calling `save_operating_model_layer`. - On approval, execute exactly one layer write, then immediately call `query_operating_model` read-only and verify checkpoint count, completed layer, pending layer advance, and saved entry presence before doing anything else. - After a verified layer save, continue proactively only on safe pre-work for the next layer: draft payload, schema validation, critic review, and local commit. Do not carry approval forward to the next OB1/Supabase write. - After each approved layer, capture one concise summary thought through core Open Brain only if separately approved or already covered by the user's explicit persistence approval for that step. - After all layers, run contradiction pass before export. - Generated `USER.md`, `SOUL.md`, and `HEARTBEAT.md` are draft artifacts. Do not overwrite local canonical files without review. - After all layers, run contradiction pass before export. - Generated `USER.md`, `SOUL.md`, and `HEARTBEAT.md` are draft artifacts. Do not overwrite local canonical files without review. ## Reporting and execution style for this user When the user is frustrated, confused, or says variants of “못 알아듣겠다”, “용어 그만”, “CEO에게 설명하듯 말해”, do not explain the whole architecture again. Do not defend, over-format, or re-teach OB1/Hermes basics after each step. Lead with the exact operational state and one next action. Use CEO-facing practical Korean. Technical terms are allowed only after translating them into what the user can decide: ```text 위치: 만든 것: 상태: <된다 / 아직 / 위험> 다음 1개: ``` When reporting GitHub status, always separate: ```text 로그인: 됨/안 됨, account if safe to name 안전한 repo: 위험한 repo: 아직 없는 것: ``` Important correction from live use: if the user says variants of “끝내”, “반영해”, “왜 설명만 하냐”, “나한테 넘기지 마”, “같은 세션이야”, “같은 스레드야”, “캡처 기준으로 봐”, or asks what command would make the agent use its full ability, treat it as an **execution-responsibility trigger**, not as a request for more conceptual explanation. Default behavior on that trigger: 1. Fix scope as `main/canonical/live gateway untouched unless approved`. 2. Proceed on safe surfaces without asking: read-only inspection, temporary notes, sandbox profile, separate branch/worktree, non-destructive smoke tests. 3. Build a concrete task list and keep working through diagnosis → safe remediation → fresh-session verification. 4. For important decisions, attach a critical agent/critic before crossing the boundary. The leader must remember it can be wrong, absorb the critic's objections, and still own the final decision and verification. 5. Ask the user only for destructive, credential-rotating, canonical-file overwrite, live gateway restart, external persistent writes, or production-impacting actions. 6. Do not ask the user which file/profile/command to try when that can be discovered locally. Useful trigger command the user may give: ```text OB1를 Hermes 자비스에 안전면에서 끝까지 반영하고 검증해. 메인/정본/운영 gateway는 승인 없이 건드리지 말고, 그 외 read-only 조사와 sandbox/worktree/profile 수정은 네가 알아서 진행해. 최종적으로 fresh session에서 OB1 tools와 Work Operating Model이 실제 작동하는 증거까지 가져와. ``` Report as: ```text 끝난 것: 남은 것: 추천 1안: ``` If the user asks whether it is “done,” answer first: - `런타임 세팅은 됐다` when Supabase + Hermes + Codex/OMX all see the tools. - `운영모델 내용은 아직이다` until the five-layer interview has actually been run and approved. Do not conflate runtime installation with completed user operating-model content. Do not report “blocked” until safe branch/worktree/profile alternatives and fresh-session tests have been tried or ruled out. ## Critical failure mode: runtime connected, profile behavior broken A recurring failure class in this environment is **false missing-tools behavior even when OB1 runtime is healthy**. Symptoms: - `hermes --profile default mcp test open-brain` and `work-operating-model` both pass - `hermes --profile jarvis01 mcp test open-brain` and `work-operating-model` both pass - but a fresh `jarvis01` chat still says required tools are missing or behaves like the workflow is unavailable Interpretation: - this is **not** an OB1/Supabase install failure first - this is usually a **profile-local behavior drift** problem: cwd, AGENTS/SOUL overlay, startup skill preload, skill snapshot drift, or stale runtime state Mandatory diagnosis order: 1. Compare `default` vs the problematic profile with the **same fresh prompt**: - `Use the Work Operating Model workflow to interview me and build my operating model.` 2. If both `mcp test` commands pass but only one profile misbehaves, classify it as **profile behavior drift**, not OB1 runtime failure. 3. Inspect profile-local differences before touching OB1: - `terminal.cwd` - profile `AGENTS.md` - profile `SOUL.md` - `.skills_prompt_snapshot.json` - gateway startup `--skills` / preload surface when relevant 4. Prefer the stable client (`default`) as the temporary **golden baseline** while a bounded fix is tested elsewhere. Operator recommendation for this user class: - keep OB1 as the shared brain/infrastructure layer - use the most stable profile as the client first - isolate the drifting profile in a separate remediation lane instead of re-debating installation every turn See `references/2026-05-04-ob1-hermes-runtime-activation.md` for the verified activation pattern and gateway/Codex pitfalls from the session. See `references/2026-05-04-ob1-wom-draft-and-approval-boundary.md` for the draft-pack pattern, mandatory critic review on important OB1 decisions, and the `save_operating_model_layer` approval boundary. See `references/2026-05-04-wom-layer-save-sequence.md` for the per-layer payload-prep → critic → approval → one-write → immediate-query verification loop. See `references/wom-per-layer-persistence-loop.md` for the per-layer payload-prep → critic → approval → one-write → immediate-query verification loop. See `references/2026-05-05-ob1-prompt-kit-absorption.md` for the Google Docs prompt-kit absorption lesson: separate Jarvis constraint architecture from Open Brain companion prompts, prioritize OB1 emergency rollout over GitHub/cofounder detours, and use public Docs export only as read-only retrieval. See `references/2026-05-05-bottleneck-audit-github-surface.md` for the evidence-first bottleneck audit workflow: pull local/session/runtime evidence, produce an internal draft, critic-check missing/overclaim/security risks, split private evidence vs public-safe versions, and prefer a new private GitHub repo over upstream OB1 for internal Jarvis bottlenecks. See `references/2026-05-05-same-thread-github-operating-model-recovery.md` for the same-thread screenshot/anchor recovery lesson, the Jarvis AI OS source-pack structure, GitHub safety split, and CEO-facing reporting format. See `references/2026-05-05-ob1-thread-anchor-github-externalization.md` for the same-thread anchor lesson: when the user points to the 01:30 `ob1세팅` screenshots/attachments, replay the same-day JSONL and attached docs first; the point is Jarvis AI OS private GitHub externalization and unhidden bottleneck docs, not a generic OB1 recap. See `references/2026-05-05-jarvis-ai-os-private-github-ready-docs.md` for the active-engineer workflow that produced GitHub-ready private docs: verify existing repos, avoid public/upstream/internal-doc confusion, create `README/CURRENT_STATE/BOTTLENECKS/TARGET_ARCHITECTURE/NEXT_ACTIONS`, add measurable 80% bottleneck criteria, run secret scan + critic review, commit locally, and ask only before external repo creation/push. ## Non-negotiable safety - Do not save memory without preview and approval. - Do not rotate `MCP_ACCESS_KEY` casually. - Do not modify live Hermes configs unless explicitly approved for that surface. - Do not treat dashboard success as OB1 workflow success. - Do not call the runtime setup complete until both MCP layers and required skills are visible from fresh Hermes and Codex/OMX sessions. - Treat `save_operating_model_layer`, `capture_thought`, `generate_operating_model_exports`, and any OB1/Supabase persistence as external writes: critic review first, then explicit user approval, then one write followed by immediate read-only verification. - Prefer a separate branch/worktree for OB1 runtime packaging; keep upstream `main` untouched unless the user explicitly asks to merge. - Before deploying Work Operating Model, verify schema is non-destructive enough for the current project: tables/functions may be `CREATE IF NOT EXISTS` / `CREATE OR REPLACE`, but watch for `DROP`, `TRUNCATE`, or broad `DELETE`. - Supabase CLI may be available via `npx -y supabase` even when `supabase` is missing from PATH. - Do not rotate `MCP_ACCESS_KEY`; reuse the existing key for sibling MCP functions unless a deliberate rotation plan updates every client. - Gateway restart is a separate verification step. If `hermes gateway restart` attaches to foreground logs or Telegram polling conflicts, verify actual PID freshness and MCP visibility from a fresh session instead of assuming failure or success.