@openlife/cli 1.7.4 → 1.7.5

package/docs/capability-pack-schema.md

@@ -1,157 +0,0 @@
-# Capability Pack Schema — `capability.yaml`
-
-> Source of truth: `src/orchestrator/capability/CapabilityPackSchema.ts`
-> Parser: `src/orchestrator/capability/CapabilityPackParser.ts`
-> Stable error codes: `CAPABILITY_ERRORS`
-
-A **Capability Pack** is a bundled unit that combines workflows, squads,
-agents, skills, checklists, templates, and governance policies into one
-canonizable asset. Packs live under `.catalog/capabilities/<id>/`.
-
-## Minimal manifest
-
-```yaml
-capability:
-  id: my-cap
-  name: My Capability
-  description: short description
-  version: "1.0.0"
-  status: draft
-  objective: what the pack accomplishes when invoked
-```
-
-That's the smallest valid pack. Everything else is optional.
-
-## Full manifest
-
-```yaml
-capability:
-  id: deep-research
-  name: Deep Research
-  description: thorough research with cited sources
-  version: "1.0.0"
-  status: draft         # draft | tested | active | deprecated
-  objective: produce verifiable research reports with cited sources
-  success_criteria:
-    - "Every claim has a verifiable citation"
-    - "At least 3 contradicting sources considered"
-
-  agents:
-    - { id: research-lead, source: embedded, label: "Research Lead" }
-    - { id: writer, source: referenced, version: "1.0.0" }
-
-  skills:
-    - { id: source-credibility-scoring, source: embedded }
-
-  squads:
-    - { id: research-squad, source: embedded }
-
-  workflows:
-    - { id: deep-research-flow, source: embedded }
-
-  checklists:
-    - { id: quality-gate, path: checklists/quality-gate.md }
-
-  templates:
-    - { id: report, path: templates/report.md }
-
-  policies:
-    - { id: no-uncited-claims, rationale: "All claims must cite a source" }
-
-  metadata:
-    createdAt: 2026-05-12T17:30:00Z
-    updatedAt: 2026-05-12T17:30:00Z
-    contentSha256: ...
-    author: Genesis Engine
-    tags: [research, analysis]
-```
-
-## Asset refs
-
-Every reference carries a `source` discriminator:
-
-- **`embedded`** — the pack owns the file. Lives under
-  `<packDir>/<kind>/<id>.md|.yaml` or `<packDir>/<kind>/<id>/`. The
-  parser checks file existence when given a `packDir` context.
-- **`referenced`** — the pack points at an asset already in the global
-  registry. Used by `CapabilityGenesisEngine` when
-  `AssetReuseRouter.find()` finds a match >= 80%.
-
-## Directory layout
-
-```
-.catalog/capabilities/<id>/
-├── capability.yaml        # this manifest
-├── INDEX.md               # human-readable summary (generated)
-├── agents/                # <id>/<id>.md or <id>.md
-├── skills/                # <id>.md
-├── squads/                # <id>/SQUAD.md
-├── workflows/             # <id>.yaml
-├── checklists/            # *.md
-├── templates/             # *.md, *.txt, etc.
-└── policies/              # policy tag definitions (optional)
-```
-
-## Lifecycle
-
-Managed by `CapabilityPackStateStore`:
-
-```
-draft  ──(tested promote, needs validatedBy)──→  tested
-                                                    │
-                                                    ▼
-                                            (active promote, needs human actor)
-                                                    │
-                                                    ▼
-                                                 active
-                                                    │
-                                              (any time)
-                                                    ▼
-                                              deprecated
-```
-
-Lifecycle is fully audit-logged at `.openlife/capability-lifecycle.jsonl`.
-
-## Stable error codes
-
-| Code | Meaning |
-|---|---|
-| `capability_invalid_yaml` | YAML parse failed |
-| `capability_missing_root` | top-level `capability:` key missing |
-| `capability_missing_required_field` | id/name/description/version/objective absent |
-| `capability_invalid_status` | status not in {draft,tested,active,deprecated} |
-| `capability_invalid_type` | array/source malformed |
-| `capability_duplicate_asset_ref` | same id appears twice in one kind |
-| `capability_unknown_asset_ref` | referenced id not in registry (Story 1.4) |
-| `capability_id_dir_mismatch` | frontmatter id ≠ directory name |
-| `capability_embedded_ref_missing_file` | embedded ref has no backing file |
-
-## How to author
-
-Three paths:
-
-1. **CLI (recommended):**
-   ```bash
-   openlife create capability "<brief>" --mode quick|professional|elite
-   ```
-2. **Programmatic:**
-   ```ts
-   import { CapabilityGenesisEngine } from './orchestrator/capability/CapabilityGenesisEngine';
-   new CapabilityGenesisEngine().generate({
-     description: '...', packId: 'my-pack', mode: 'professional', actor: 'me',
-   });
-   ```
-3. **Hand-write** the `capability.yaml` and the embedded asset files,
-   then run `CapabilityPackParser.parseCapabilityPackFile()` to validate.
-
-## Promotion
-
-```bash
-# After authoring + manual test
-openlife aiobuilder canonize capability my-cap     # draft → active (via the
-                                                    # existing canonize shim
-                                                    # that also handles squads
-                                                    # and skills)
-
-# Or programmatically via CapabilityPackStateStore.promote()
-```

package/docs/commands.md

@@ -1,82 +0,0 @@
-# OpenLife Command Manual (Atualizado)
-
-## Núcleo
-- `openlife --help`
-- `openlife start --daemon`
-- `openlife ask <mensagem...>`
-- `openlife ask <mensagem...> --mode <task|service>`
-- `openlife status`
-- `openlife doctor`
-
-## Instalação / Sistema
-- `openlife install`
-- `openlife system install`
-- `openlife system status`
-- `openlife system doctor`
-- `openlife system runtime-policy-status`
-- `openlife system runtime-policy-canary-start --intent <intent> --executor <executor>`
-- `openlife system runtime-policy-canary-observe --intent <intent> --ok <true|false>`
-- `openlife system runtime-policy-rollback --intent <intent>`
-
-## Auth
-- `openlife auth gemini`
-- `openlife auth openai`
-
-## Models
-- `openlife models status`
-- `openlife models set <provider/model>`
-- `openlife models fallbacks list`
-- `openlife models fallbacks add <provider/model>`
-- `openlife models fallbacks remove <provider/model>`
-- `openlife models fallbacks clear`
-
-## Governança
-- `openlife governance status`
-- `openlife governance audit`
-- `openlife governance risk-check <goal>`
-- `openlife governance consent <scope> <userId>`
-
-## Dual-mode (Task/Service)
-- `openlife task status <taskId>`
-- `openlife service status <serviceId>`
-- `openlife service pause <serviceId> [--reason <texto>]`
-- `openlife service resume <serviceId> [--reason <texto>]`
-- `openlife service events <serviceId> [--limit <n>]`
-
-## Jobs + Runtime
-- `openlife job list [--limit <n>]`
-- `openlife job events <jobId>`
-- `openlife runtime probe`
-- `openlife runtime list`
-
-## Reversa
-- `openlife reversa status`
-- `openlife reversa mode --set <default|designmd> --profile <profileId>`
-- `openlife reversa run-phase <reconnaissance|excavation|interpretation|generation|review> --note "..."`
-- `openlife reversa run-all --note "..."`
-- `openlife reversa export-json`
-
-## DesignMD
-- `openlife designmd import [--vendor <path>] [--source <awesome-design-md|open-design>]`
-- `openlife designmd list`
-- `openlife designmd show <profileId>`
-- `openlife designmd status`
-- `openlife designmd apply <profileId> <source> <title> <designPath>`
-
-## AIOBUILDER
-- `openlife aiobuilder mode --set <default|designmd> --profile <profileId>`
-- `openlife aiobuilder generate-ui <featureName>`
-- `openlife aiobuilder generate-ui <featureName> --strict-contracts`
-- `openlife aiobuilder generate-ui <featureName> --consistency-check`
-- `openlife aiobuilder generate-ui <featureName> --strict-contracts --consistency-check`
-
-## Conversação (ask)
-- `openlife ask "importe open design de vendor/open-design"`
-- `openlife ask "ative designmd perfil <profileId>"`
-- `openlife ask "gerar ui para <featureName>"`
-
-## Operações auxiliares
-- `openlife teammate list`
-- `openlife teammate upsert <id> <owner> <status> <title> [--blocker <texto>] [--comment <texto>]`
-- `openlife learning add <taskId> <summary>`
-- `openlife learning list`

package/docs/deep-research-capability.md

@@ -1,114 +0,0 @@
-# Deep Research Capability Pack
-
-> Location: `.catalog/capabilities/deep-research/`
-> Status: `draft`
-> Generated by: `CapabilityGenesisEngine` (Story 1.5 / 3.4)
-> Regression test: `src/test_deep_research_capability.ts`
-
-The first seed Capability Pack. Demonstrates the v1.3 capability stack
-end-to-end: schema, parser, providers, lifecycle, genesis engine, CLI.
-
-## Contents
-
-```
-.catalog/capabilities/deep-research/
-├── capability.yaml
-├── INDEX.md
-├── skills/
-│   ├── source-credibility-scoring.md
-│   ├── evidence-synthesis.md
-│   ├── contradiction-analysis.md
-│   ├── advanced-query-planning.md
-│   └── executive-briefing.md
-├── squads/
-│   └── research-squad/SQUAD.md
-├── workflows/
-│   └── deep-research-flow.yaml
-└── (agents/, checklists/, templates/ — empty directories ready for use)
-```
-
-## Why this pack
-
-The Hermes brief calls for an "elite" deep-research capability with five
-specific skills, one squad, and one workflow. Building it via the
-Genesis Engine doubles as a real test of the v1.3 pipeline: if you can
-run `openlife create capability "..."` and get this output, the
-end-to-end loop works.
-
-## How it was produced
-
-```bash
-node bin/openlife.js create capability \
-  "Deep research with cited sources and contradiction checks" \
-  --id deep-research \
-  --mode elite \
-  --actor v1.3-bootstrap \
-  --skills source-credibility-scoring,evidence-synthesis,contradiction-analysis,advanced-query-planning,executive-briefing \
-  --squads research-squad \
-  --workflows deep-research-flow
-```
-
-Every file inside the pack started as a draft stub. Operators are
-expected to refine each one before promoting the pack to `tested`.
-
-## Reuse-first verification
-
-The Genesis Engine called `AssetReuseRouter.find('Deep research…')`
-first. On a clean repo there are no promoted assets matching, so all 7
-assets land as `source: 'embedded'`. On a repo with prior research
-work, matching assets would surface as `source: 'referenced'`.
-
-## Lifecycle
-
-```
-draft (current)
-  │
-  │  After operators refine the stubs + run validation tests:
-  ▼
-tested  (requires validatedBy when calling
-         CapabilityPackStateStore.promote)
-  │
-  │  After explicit human canonization:
-  ▼
-active  (requires human actor — not 'system' or 'auto')
-```
-
-The pack is intentionally shipped at `draft` to keep the contract
-honest: a Genesis-produced pack is never automatically `active`.
-
-## What's stubbed today
-
-- **Skills** — frontmatter is real (id, name, status, source, version);
-  body sections are placeholder.
-- **Squad** — frontmatter is real; agent table is `TBD | TBD`.
-- **Workflow** — sequence is one placeholder step; operator fills in
-  the real plan.
-
-## How to refine
-
-1. Edit each skill `.md`: write the `When to use`, `Procedure`,
-   `Validation` sections.
-2. Edit `squads/research-squad/SQUAD.md`: fill out the agent table and
-   the squad's `## Mission` section.
-3. Edit `workflows/deep-research-flow.yaml`: add real phases and steps.
-4. Run the regression test:
-   ```bash
-   npm run test:deep-research-capability
-   ```
-5. Promote when ready:
-   ```ts
-   import { CapabilityPackStateStore } from './orchestrator/capability/CapabilityPackState';
-   new CapabilityPackStateStore().promote({
-     packId: 'deep-research',
-     to: 'tested',
-     actor: 'rafa',
-     validatedBy: 'deep-research-quality-gate',
-   });
-   ```
-
-## Future: real implementation
-
-v1.4 will replace the stubs with production content authored against
-the `tech-search` skill family already in `.claude/skills/`. The
-reuse-first contract means those references will appear as
-`source: 'referenced'` instead of embedded duplicates.

package/docs/development/typescript-conventions.md

@@ -1,95 +0,0 @@
-# TypeScript Conventions — OpenLife CLI
-
-> Established by Story 7.1 (v1.2 Royal Stack).
-> Enforced by `tsconfig.json` strict mode + reviewer discipline.
-
-## Goal
-
-Keep the production tree honest about types so refactors stay safe. The repo
-already runs `strict: true` — these conventions cover the gaps strict mode
-doesn't enforce.
-
-## The `any` budget
-
-`grep` audit at v1.2 baseline (May 2026):
-
-| Scope | Allowed |
-|-------|---------|
-| `src/test_*.ts` | Unlimited — tests reach into private members via `(x as any).method` deliberately |
-| `src/**/*.ts` (non-test) | < 90 (was 126 at v1.1 close) |
-
-Target for v1.3: < 50. Target for v1.4: < 20.
-
-## Permitted patterns
-
-These show up across the codebase and are **kept on purpose**:
-
-### 1. Test seams — reach into private members
-```ts
-(brain as any).failureCount   // test_brain_fallback_chain.ts
-(gw as any).bot               // test_daemon_sigterm.ts
-```
-Tests stay tight against internals. If a method becomes public for testing
-only, it leaks. `as any` is the right escape valve here.
-
-### 2. Third-party SDK lacunas
-```ts
-const opts: any = { apiKey, baseURL };   // OpenAI constructor opts evolve faster than @types
-(wrapped as any).cause = error;          // Error.cause is Node 16.9+ but not in lib.dom.d.ts yet
-```
-Use only when SDK typings are demonstrably behind the runtime.
-
-### 3. Untyped JSON at the boundary
-```ts
-const data: unknown = await response.json();
-```
-Always prefer `unknown` over `any` for parsed JSON, then narrow with a type
-guard. The current codebase has some leftover `: any` here — convert to
-`unknown` opportunistically.
-
-### 4. Catch clauses on Error
-```ts
-} catch (err) {
-  const message = err instanceof Error ? err.message : String(err);
-}
-```
-TS 4.4+ defaults catch variables to `unknown` under strict mode. Don't
-re-annotate `catch (err: any)` — drop the annotation entirely and narrow
-inside the block.
-
-## Forbidden patterns
-
-### 1. `any` in public signatures
-```ts
-// BAD
-export function routeTask(task: any): any { ... }
-
-// GOOD
-export function routeTask(task: TaskIntent): TaskResult { ... }
-```
-
-### 2. Drive-by `as any` to silence the compiler
-```ts
-// BAD
-return (response as any).data;
-
-// GOOD — declare a narrow interface
-interface ResponseShape { data: string }
-return (response as ResponseShape).data;
-```
-
-### 3. `Function` / `Object` / `{}` as type
-These behave like `any` with worse ergonomics. Use a specific signature
-(`(x: number) => number`) or `Record<string, unknown>` instead.
-
-## Convention enforcement
-
-- **Local check before commit:** `grep -rEn ":\s*any\b|<any>|as any" src/ --include="*.ts" | grep -v test_ | wc -l` — should not exceed the documented budget.
-- **CI:** Story 7.4 wires a `tsc --noEmit --strict` gate so any new `any` that breaks compile fails fast.
-- **Review:** PRs that add `any` outside the permitted patterns should justify the addition in the PR body or split out a typing follow-up.
-
-## Migration plan
-
-Each story that touches a file with `any` should opportunistically reduce
-the count in that file. Do not block feature work on type cleanup — the
-budget is a ratchet, not a gate.

package/docs/host-installers.md

@@ -1,68 +0,0 @@
-# OpenLife — host installer coverage matrix
-
-OpenLife can install its agent + command + MCP surface into three host CLIs.
-Each one is reversible and uses the same `dist-templates/<host>/` layout.
-
-## Coverage matrix (v1.4)
-
-| Host | Status | `installFor<Host>` | `uninstallFor<Host>` | dist-templates path |
-|---|---|---|---|---|
-| `claude-code` | Real, original (v1.2 / v1.3) | ✅ | ✅ | `dist-templates/claude-code/` |
-| `gemini-cli` | Real (Story 9.3) | ✅ | ✅ | `dist-templates/gemini-cli/` |
-| `codex` | Real (Story 9.4) | ✅ | ✅ | `dist-templates/codex/` |
-
-All three share `HostInstaller.installForHost()` / `uninstallForHost()`
-private helpers so behavior stays consistent.
-
-## What gets installed
-
-For each host the installer copies:
-
-- `dist-templates/<host>/agents/*.md` → `<targetRoot>/.<host>/agents/*.md`
-- `dist-templates/<host>/commands/openlife/*.md` → `<targetRoot>/.<host>/commands/openlife/*.md`
-- `dist-templates/<host>/mcp/openlife-orchestrator.json` →
-  `<targetRoot>/.openlife/install-mcp-snippet-<host>.json` (a staged snippet —
-  the operator merges its `mcpServers` block into the host's own config file).
-
-For Claude Code (the original target) there are 5 agents (atlas, forge,
-genesis, lyra, maestro) and 4 commands (ask, doctor, dream, status). The
-other two hosts are seeded from the same content via Story 9.5.
-
-## Uninstall semantics
-
-Uninstall is reversible: it only removes files that match the
-`openlife-*.md` / `openlife/*.md` / `install-mcp-snippet-<host>.json`
-shape, so it never touches the operator's own host configuration files. A
-`.bak` is created for any pre-existing file that would have been
-overwritten by the corresponding install.
-
-## CLI surface
-
-```bash
-openlife system install --host claude-code --target .
-openlife system install --host gemini-cli  --target .
-openlife system install --host codex       --target .
-
-openlife system uninstall --host gemini-cli --target .
-```
-
-The `--host` flag accepts only the three values above. Anything else is
-rejected with `validateHost()`. If you omit `--host`, `detectHostFromEnv()`
-picks one from `OPENLIFE_HOST` or falls back to `claude-code`.
-
-## How to add a new host
-
-1. Seed `dist-templates/<new-host>/{agents,commands,mcp}/` with content
-   following the existing layout. Story 9.5 is the reference.
-2. Add `installFor<NewHost>()` + `uninstallFor<NewHost>()` to
-   `src/cli/HostInstaller.ts` — both should delegate to `installForHost()`
-   / `uninstallForHost()` with the host name and the dot-dir name.
-3. Extend the dispatcher branches in `install()` / `uninstall()`.
-4. Add the new host to `validateHost()` in `src/cli/InstallFlow.ts`.
-5. Mirror an integration test in `test_host_installers_<host>.ts`.
-
-## Multi-host parity
-
-`test_multi_host_docs_parity.ts` asserts that every host has the same
-agent count, command count, and required-file presence so the docs
-matrix never drifts silently.

package/docs/install/aiobuilder.md

@@ -1,70 +0,0 @@
-# AIOBuilder — CLI Reference
-
-> AIOBuilder is the orchestrator squad that turns intent into running software.
-> It owns 16 verbs spanning discovery → planning → build → release. This doc is
-> the canonical map between the verbs promised in
-> `.catalog/squads/01-meta-framework-ai-builder/SQUAD.md` and the CLI handlers
-> wired in `src/index.ts`.
->
-> A regression test (`src/test_aiobuilder_cli_parity.ts`) fails the build if
-> this mapping drifts.
-
-## Verb → Handler Map
-
-| Verb | CLI command | Notes |
-|------|-------------|-------|
-| `discover` | `openlife aiobuilder discover` | Delegates to `brownfield-discovery` workflow |
-| `plan` | `openlife aiobuilder plan` | Phase 1 of `story-development-cycle` |
-| `design` | `openlife aiobuilder generate-ui` (alias) | UI generation handler |
-| `build` | `openlife aiobuilder build` | Story 5.4 handler, runs greenfield phase 3 |
-| `test` | `openlife aiobuilder test` | Runs `npm run test:all` |
-| `preview` | `openlife aiobuilder preview` | Placeholder for v1.3 Vercel/Railway wire-up |
-| `release` | `openlife aiobuilder release` | Delegates to `qa-loop` workflow |
-| `infra` | `openlife aiobuilder infra` | Placeholder for v1.3 infra report |
-| `score` | `openlife aiobuilder score` | Reads `.artifacts/squad-scores.json` |
-| `route` | `openlife route intent` (top-level) | Routing lives at the root, not under aiobuilder |
-| `evolve` | `openlife aiobuilder evolve` | Runs `SquadCreator.analyze()` on all squads |
-| `ship` | `openlife aiobuilder ship` | Full pipeline: discover → plan → build → test → release |
-| `build-agent` | `openlife aiobuilder create-agent` (alias) | Uses SquadCreator-rendered template |
-| `build-squad` | `openlife aiobuilder create-squad` (alias) | Uses `SquadCreator.create()` |
-| `build-skill` | `openlife aiobuilder build-skill` | Uses `SkillCreator.create()` |
-| `canonize` | `openlife aiobuilder canonize <type> <id>` | Promotes draft → active, logs to `.openlife/canonization-log.jsonl` |
-
-## Authoring lifecycle (v1.2)
-
-```
-build-skill / build-squad      →   SquadCreator / SkillCreator render from
-                                   dist-templates/{squad,skill}-template/
-                                   into .catalog/{squads,skills}/<id>/
-                                   with status: draft
-
-canonize squad <id>            →   reads .catalog/squads/<id>/SQUAD.md
-                                   verifies via SquadCreator.validate()
-                                   sets frontmatter status: active
-                                   appends to .openlife/canonization-log.jsonl
-```
-
-A squad/skill stays in `status: draft` until it has been used in at least one
-real mission and `canonize` has been called explicitly. The
-`test_catalog_quality.ts` gate flags any auto-route draft older than 7 days as
-stale — promote it via `canonize` or delete it.
-
-## v1.3 — Deferred placeholders
-
-The following sub-commands return stable JSON envelopes today and will gain
-real integrations in v1.3 (see `docs/planning/v1.3-capability-genesis.md`):
-
-- `preview` — Vercel/Railway preview URL wiring
-- `infra` — live infra inventory report
-- `SquadCreator.design()` / `migrate()` / `extend()` / `publish()`
-- `SkillCreator.design()` / `migrate()` / `extend()` / `publish()`
-
-Each placeholder returns `{ ok: false, error: '<name>_not_implemented_until_v1_3' }`
-so callers can wire today and the real handler lands behind the same API.
-
-## Aliases preserved for backwards compatibility
-
-- `openlife aiobuilder create-agent` — kept as canonical name, alias for `build-agent` verb
-- `openlife aiobuilder create-squad` — same, alias for `build-squad`
-- `openlife aiobuilder generate-ui` — same, alias for `design`
-- `openlife route intent ...` — top-level routing, aliased by `route` verb

package/docs/install/claude-code.md

@@ -1,83 +0,0 @@
-# OpenLife on `claude-code`
-
-## Status
-
-**Supported (v1.0)** — this is the canonical host for OpenLife v1.0. Wizard and non-interactive paths both install real artifacts.
-
-## Auto-detection signal
-
-The `InstallFlow.detectHostFromEnv()` resolver selects `claude-code` when **either** of these environment variables is set:
-
-- `CLAUDECODE`
-- `CLAUDE_PROJECT_DIR`
-
-To force-select `claude-code` regardless of environment, pass `--host claude-code`.
-
-## What gets installed
-
-Running `openlife init` (wizard) or `openlife system setup --profile <p> --host claude-code` writes:
-
-| Artifact            | Destination                                         | Source                                                |
-|---------------------|-----------------------------------------------------|-------------------------------------------------------|
-| 5 starter agents    | `<root>/.claude/agents/openlife-*.md`               | `dist-templates/claude-code/agents/openlife-*.md`     |
-| 4 slash commands    | `<root>/.claude/commands/openlife/*.md`             | `dist-templates/claude-code/commands/openlife/*.md`   |
-| MCP manifest (stub) | Staged at `.openlife/mcp/openlife-orchestrator.json`| `dist-templates/claude-code/mcp/openlife-orchestrator.json` |
-| Runtime state dir   | `<root>/.openlife/`                                 | created from scratch                                  |
-| Install manifest    | `<root>/.openlife/install-manifest.json`            | written by `InstallFlow`                              |
-
-The 5 starter agents are: `openlife-maestro`, `openlife-lyra`, `openlife-forge`, `openlife-atlas`, `openlife-genesis`.
-
-The 4 starter slash commands are: `/openlife:status`, `/openlife:ask`, `/openlife:doctor`, `/openlife:dream`.
-
-## What gets uninstalled
-
-`openlife system uninstall --host claude-code` reverses **only** what we installed:
-
-| Removed                                              | Preserved                                  |
-|------------------------------------------------------|--------------------------------------------|
-| `.claude/agents/openlife-*.md` (prefix-scoped)       | `.claude/agents/*` (your own agents)       |
-| `.claude/commands/openlife/` (entire namespace dir)  | `.claude/commands/*` (other namespaces)    |
-| Staged MCP snippet at `.openlife/mcp/`               | `.openlife/` (state, missions, learning)   |
-|                                                      | `.catalog/` (runtime catalogs)             |
-|                                                      | `~/.claude.json` (operator merges manually)|
-
-The prefix-scoped agent deletion (`openlife-*.md` only) is the contract from Story 3.4: any agent file you authored manually stays untouched.
-
-## MCP integration
-
-The MCP manifest at `dist-templates/claude-code/mcp/openlife-orchestrator.json` is **staged** during install — it is copied to `.openlife/mcp/` but **not** auto-merged into `~/.claude.json`.
-
-To wire it up, the operator manually merges the snippet:
-
-```jsonc
-// ~/.claude.json (or your project .claude.json)
-{
-  "mcpServers": {
-    "openlife-orchestrator": {
-      // contents of .openlife/mcp/openlife-orchestrator.json
-    }
-  }
-}
-```
-
-The auto-merge is deferred because writing to `~/.claude.json` is a security/UX trap (clobbering operator config). Per Story 3.3, operator-driven merge is the chosen contract.
-
-## Known limitations
-
-- `bin/openlife-mcp.js` (the MCP server itself) is not yet shipped — the manifest is informational until a later v1.1 story lands the server.
-- After install, `openlife system doctor` will surface a "MCP server pending" note; that is expected.
-- The wizard does not auto-merge `~/.claude.json`; operator action required (see MCP integration above).
-
-## After install
-
-```bash
-openlife system doctor    # validate the install
-openlife system status    # surface runtime state
-```
-
-In Claude Code itself:
-
-- `/openlife:status` — runtime status surface
-- `/openlife:ask` — route a question through the Brain
-- `/openlife:doctor` — diagnostic check
-- `/openlife:dream` — Dream Organizer entry point