@openlife/cli 1.7.4 → 1.7.5

package/docs/install/codex.md

@@ -1,64 +0,0 @@
-# OpenLife on `codex`
-
-## Status
-
-**Reserved for v1.1 follow-up** — this document is a forward-looking stub that captures the contract today and what changes when the real installer lands (tracked as a v1.1 follow-up to the multi-host installer epic).
-
-Today: `openlife init` and `openlife system setup --host codex` both **accept** this host, but the host-install step throws `HostNotYetSupportedError` and the dispatcher catches it gracefully — the runtime state dir `.openlife/` is still created, only the codex-specific artifacts are skipped.
-
-## Auto-detection signal
-
-The `InstallFlow.detectHostFromEnv()` resolver selects `codex` when:
-
-- `CODEX_HOME` is set
-
-To force-select `codex` regardless of environment, pass `--host codex`.
-
-## What gets installed (today)
-
-| Artifact          | Status (today)                                                          |
-|-------------------|--------------------------------------------------------------------------|
-| Host artifacts    | **None** — `HostInstaller.installCodex()` throws `HOST_NOT_YET_SUPPORTED` |
-| Runtime state dir | `<root>/.openlife/` — created normally                                  |
-| Install manifest  | `<root>/.openlife/install-manifest.json` — written with `hostInstall.ok = false` |
-
-The CLI return value documents the skip:
-
-```json
-{
-  "hostInstall": {
-    "ok": false,
-    "reason": "host_not_yet_supported",
-    "host": "codex"
-  }
-}
-```
-
-This is **degradação graciosa por design** — picking an unsupported host does not abort the install, so the rest of the surface (state dir, governance, catalogs) is still usable.
-
-## What gets installed (v1.1 follow-up)
-
-When the codex installer ships, the same `openlife system setup --host codex` command will write (planned layout, subject to host conventions):
-
-- Agents into `${CODEX_HOME}/agents/openlife-*.md`
-- Slash commands or prompt templates into `${CODEX_HOME}/commands/openlife/*.md`
-- MCP manifest staged for manual merge into the codex MCP config
-
-No CLI flag change will be required — the same command starts working once the installer is implemented.
-
-## What gets uninstalled
-
-Today: `openlife system uninstall --host codex` is also gated by `HOST_NOT_YET_SUPPORTED`. `.openlife/`, `.catalog/`, and the codex config are all preserved (nothing was installed in the first place).
-
-When the installer ships, uninstall will mirror the claude-code contract: prefix-scoped agent removal (`openlife-*` only), full namespace removal for `commands/openlife/`, and preservation of `.openlife/`, `.catalog/`, and the operator's codex global config.
-
-## MCP integration
-
-Deferred to the v1.1 follow-up. The staged MCP manifest format mirrors `dist-templates/claude-code/mcp/openlife-orchestrator.json`; the codex installer will adapt it to codex's MCP config convention when shipped.
-
-## Known limitations
-
-- `install` command returns `skipped` (with `HOST_NOT_YET_SUPPORTED`) — `.openlife/` is still created, but no codex host artifacts.
-- `uninstall` similarly no-ops gracefully — nothing to remove yet.
-- The wizard accepts `codex` and emits a warning in `WizardResult.warnings` ("host wiring deferred to v1.1 follow-up") so users are not surprised.
-- This stub will be replaced by the real per-host doc when the installer lands.

package/docs/install/gemini-cli.md

@@ -1,64 +0,0 @@
-# OpenLife on `gemini-cli`
-
-## Status
-
-**Reserved for v1.1 follow-up** — this document is a forward-looking stub that captures the contract today and what changes when the real installer lands (tracked as a v1.1 follow-up to the multi-host installer epic).
-
-Today: `openlife init` and `openlife system setup --host gemini-cli` both **accept** this host, but the host-install step throws `HostNotYetSupportedError` and the dispatcher catches it gracefully — the runtime state dir `.openlife/` is still created, only the gemini-cli-specific artifacts are skipped.
-
-## Auto-detection signal
-
-The `InstallFlow.detectHostFromEnv()` resolver selects `gemini-cli` when:
-
-- `GEMINI_CONFIG_DIR` is set
-
-To force-select `gemini-cli` regardless of environment, pass `--host gemini-cli`.
-
-## What gets installed (today)
-
-| Artifact          | Status (today)                                                          |
-|-------------------|--------------------------------------------------------------------------|
-| Host artifacts    | **None** — `HostInstaller.installGeminiCli()` throws `HOST_NOT_YET_SUPPORTED` |
-| Runtime state dir | `<root>/.openlife/` — created normally                                  |
-| Install manifest  | `<root>/.openlife/install-manifest.json` — written with `hostInstall.ok = false` |
-
-The CLI return value documents the skip:
-
-```json
-{
-  "hostInstall": {
-    "ok": false,
-    "reason": "host_not_yet_supported",
-    "host": "gemini-cli"
-  }
-}
-```
-
-This is **degradação graciosa por design** — picking an unsupported host does not abort the install, so the rest of the surface (state dir, governance, catalogs) is still usable.
-
-## What gets installed (v1.1 follow-up)
-
-When the gemini-cli installer ships, the same `openlife system setup --host gemini-cli` command will write (planned layout, subject to host conventions):
-
-- Agents into `${GEMINI_CONFIG_DIR}/agents/openlife-*.md`
-- Slash commands into `${GEMINI_CONFIG_DIR}/commands/openlife/*.md`
-- MCP manifest staged for manual merge into the gemini-cli MCP config
-
-No CLI flag change will be required — the same command starts working once the installer is implemented.
-
-## What gets uninstalled
-
-Today: `openlife system uninstall --host gemini-cli` is also gated by `HOST_NOT_YET_SUPPORTED`. `.openlife/`, `.catalog/`, and the gemini-cli config are all preserved (nothing was installed in the first place).
-
-When the installer ships, uninstall will mirror the claude-code contract: prefix-scoped agent removal (`openlife-*` only), full namespace removal for `commands/openlife/`, and preservation of `.openlife/`, `.catalog/`, and the operator's gemini-cli global config.
-
-## MCP integration
-
-Deferred to the v1.1 follow-up. The staged MCP manifest format mirrors `dist-templates/claude-code/mcp/openlife-orchestrator.json`; the gemini-cli installer will adapt it to gemini-cli's MCP config convention when shipped.
-
-## Known limitations
-
-- `install` command returns `skipped` (with `HOST_NOT_YET_SUPPORTED`) — `.openlife/` is still created, but no gemini-cli host artifacts.
-- `uninstall` similarly no-ops gracefully — nothing to remove yet.
-- The wizard accepts `gemini-cli` and emits a warning in `WizardResult.warnings` ("host wiring deferred to v1.1 follow-up") so users are not surprised.
-- This stub will be replaced by the real per-host doc when the installer lands.

package/docs/install/runtime-profiles.md

@@ -1,83 +0,0 @@
-# Runtime profiles (Advanced)
-
-> **Advanced topic.** Casual users can skip this page — the defaults are correct
-> for the typical install where API keys are present in `.env`. This page is for
-> operators who run OpenLife against **OAuth-authenticated LLM CLIs only**
-> (`claude`, `codex`, `gemini`) and never set API keys.
-
-Runtime profiles tune how `openlife doctor world` **classifies** check
-severities at runtime. They do **not** change which providers `Brain.ts` calls
-or in what order — the fallback chain is unaffected.
-
-Cross-link: see [`../../INSTALL.md`](../../INSTALL.md), section 4 ("Profiles") for
-the install-time `framework` vs `autonomous` distinction. Install profiles and
-runtime profiles are orthogonal.
-
-## Env var contract
-
-| Env var | Value | Effect |
-|---|---|---|
-| `OPENLIFE_RUNTIME_PROFILE` | _unset_ (default) | Standard severity classifier in `WorldClassCommands.doctorWorldDetailed()`. Missing CLIs and env vars are flagged as `blocker`. |
-| `OPENLIFE_RUNTIME_PROFILE` | `oauth-only` (case-insensitive — `OAuth-Only` works too) | Failing checks `cli:ollama` (default: `blocker`), `env:OPENAI_API_KEY`, `env:GEMINI_API_KEY`, `env:ANTHROPIC_API_KEY` (default: `warning`) are all downgraded to `info`. All other checks keep their default severity. |
-
-The classifier lives at `src/cli/WorldClassCommands.ts` (`doctorWorldDetailed`)
-and is regression-tested by `src/test_runtime_profile_oauth_only.ts`.
-
-## When to use `oauth-only`
-
-Set `OPENLIFE_RUNTIME_PROFILE=oauth-only` when ALL of the following are true:
-
-- You are not using direct API keys (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`,
-  `GEMINI_API_KEY` are intentionally absent).
-- You drive OpenLife through OAuth-authenticated LLM CLIs that are on `PATH`
-  (e.g. `claude`, `codex`, `gemini`).
-- You are not running a local Ollama and do not want its absence flagged as a
-  blocker.
-- You still want `openlife doctor world` to show the four checks (for
-  transparency) — just as `info`, not as `blocker`.
-
-## Worked example
-
-Without the profile (defaults):
-
-```text
-$ openlife doctor world
-...
-❌ cli:ollama: CLI não encontrada no PATH                  [blocker]
-❌ env:OPENAI_API_KEY: Variável ausente                     [warning]
-❌ env:GEMINI_API_KEY: Variável ausente                     [warning]
-❌ env:ANTHROPIC_API_KEY: Variável ausente                  [warning]
-```
-
-With the profile:
-
-```text
-$ OPENLIFE_RUNTIME_PROFILE=oauth-only openlife doctor world
-...
-❌ cli:ollama: CLI não encontrada no PATH                  [info]
-❌ env:OPENAI_API_KEY: Variável ausente                     [info]
-❌ env:GEMINI_API_KEY: Variável ausente                     [info]
-❌ env:ANTHROPIC_API_KEY: Variável ausente                  [info]
-```
-
-The check still runs and still reports `ok=false`. Only the `severity` field
-changes, which is what release-gate / CI tooling reads when deciding to block.
-
-## What it does NOT do
-
-- It does **not** modify the LLM fallback chain in `src/orchestrator/Brain.ts`.
-- It does **not** disable any provider. If `OPENAI_API_KEY` is absent, the
-  OpenAI SDK path still won't authenticate — `oauth-only` just stops doctor
-  from flagging that as a blocker.
-- It does **not** affect `cli:codex`, `cli:claude`, `cli:gemini` checks — those
-  stay required because the oauth-only flow depends on them.
-- It does **not** affect `runtime:*` health checks, `env:TELEGRAM_BOT_TOKEN`,
-  or any state-dir / manifest checks.
-
-## Forward compatibility
-
-`OPENLIFE_RUNTIME_PROFILE` is intentionally a generic env var. `oauth-only`
-is the first value; future profiles (e.g. `air-gapped`, `local-only`) may use
-the same env var with different downgrade lists. Treat unknown values as
-"default behavior" — the classifier explicitly checks for `oauth-only` and
-falls through otherwise.

package/docs/openlife-agent-os-blueprint.md

@@ -1,114 +0,0 @@
-# OpenLife Agent OS — Blueprint
-
-> Version: v1.3 "Agent OS Integration" (May 2026)
-> Status: shipping
-> Audience: operators, framework contributors
-
-OpenLife is a TypeScript Agent OS: a runtime, a CLI framework, and an
-autonomous-agent daemon — all sharing a single codebase. v1.3 wires the
-nervous system that connects every existing organ. No greenfield, no
-Hermes/Obsidian runtime dependency.
-
-## Runtime source-of-truth contract (LOCKED)
-
-- **`.catalog/`** — runtime source-of-truth for agents, skills, squads,
-  workflows, MCPs, and **capability packs** (new in v1.3). Loaded by the
-  composite provider chain. Everything else is documentation or scratch.
-- **`.openlife/`** — runtime state (consents, queues, locks,
-  heartbeat, capability lifecycle, crons, profiles, active-profile pointer).
-- **`.artifacts/`** — output and audit (mission state, thought-traces,
-  service events, security events, cron events, soak reports).
-- **Hermes / Obsidian** — reference and product context. Never imported
-  at runtime. `test_openlife_runtime_source_truth.ts` guards this.
-
-## Two profiles, three modes
-
-OpenLife runs in two install profiles (set at `openlife system install`):
-- **framework** — interactive CLI for local operators
-- **autonomous** — long-running daemon with Telegram + HTTP gateway
-
-And three execution modes (selectable per workflow / mission):
-- **task** — one-shot mission, completes when sequence finishes. Default.
-- **service** — long-running, must be explicitly requested. The
-  WorkflowEngine refuses silent task→service promotion.
-- **swarm** — parallel multi-agent (existing, unchanged in v1.3).
-
-## The four pillars
-
-```
-   ┌─────────────────────────────────────────────────────────┐
-   │  CAPABILITY PACK (.catalog/capabilities/<id>/)           │
-   │   ├── workflows/    (how to do it — verb)                │
-   │   ├── squads/       (who does it — noun)                 │
-   │   ├── agents/                                            │
-   │   ├── skills/                                            │
-   │   ├── checklists/   (validation gates)                   │
-   │   ├── templates/    (output shells)                      │
-   │   └── policies/     (governance tags)                    │
-   └─────────────────────────────────────────────────────────┘
-                 │                            │
-                 ▼                            ▼
-   ┌────────────────────────┐   ┌─────────────────────────────┐
-   │ CapabilityGenesisEngine│   │ AIOBuilder CLI (16/16)      │
-   │ (reuse-first builder)  │   │   + `openlife create …`     │
-   └────────────────────────┘   └─────────────────────────────┘
-                 │                            │
-                 ▼                            ▼
-   ┌─────────────────────────────────────────────────────────┐
-   │  RUNTIME (CLI Framework  +  Autonomous Agent)            │
-   │   Gateway  +  Gatekeeper  +  GovernanceLayer             │
-   │   QueueScheduler  +  CronManager  +  DistributedLock     │
-   │   ProfileManager  +  ToolsetRegistry  +  WatchdogEmitter │
-   │   WorkflowEngine  +  MissionCheckpointStore              │
-   └─────────────────────────────────────────────────────────┘
-```
-
-## Canonical maestro: AIOBUILDER
-
-The AIOBuilder CLI is the single maestro. 16/16 verb parity (v1.2). v1.3
-adds `create-capability` (17 verbs) and a top-level `openlife create …`
-alias family that forwards to the same handlers. Per locked decision
-(2026-05-12): no duplicate logic; AIOBUILDER stays canonical.
-
-## What's new in v1.3
-
-1. **Capability Packs** — `.catalog/capabilities/<id>/` schema, parser,
-   lifecycle (`draft → tested → active → deprecated`), and providers.
-2. **CapabilityGenesisEngine** — reuse-first builder. Calls
-   `AssetReuseRouter.find()` before creating; novel assets are embedded
-   in the pack, matches are referenced.
-3. **Workflow Schema v2** — 15 new Hermes-mandated fields (status, mode,
-   triggers, objective, success_criteria, inputs, outputs,
-   required_context, skills, tools, policies, validation, evidence,
-   failure_handling, learning_rules). All optional, v1.2 YAMLs parse
-   unchanged.
-4. **Service-mode is explicit-only** — `WorkflowEngine.run()` refuses
-   silent task→service; `ServiceState.promoteTaskToService()` requires
-   human actor + consentScope.
-5. **GovernanceLayer expanded** — 4 new categories: production-deploy,
-   external-send, fake-fallback, conclusion-without-validation.
-6. **Gatekeeper × OutcomeSimulator** — best-effort pre-dispatch
-   prediction persisted to `.artifacts/missions/<id>.thought-trace.json`.
-7. **Gateway Telegram guardrails** — `validateBotToken()` via real
-   getMe; `redactBotToken()` strips token bodies from any log line.
-8. **CronManager** — native 5-field cron + `openlife cron …` CLI.
-9. **ProfileManager** — per-profile memory namespace, catalog scope,
-   toolset allowlist, model chain. `openlife profile …` CLI.
-10. **ToolsetRegistry** — 15 canonical categories with per-profile
-    allow/deny.
-11. **ExternalCatalogRegistry.import()** — trust-gated MCP install
-    policy decision (network fetch wired in v1.4).
-12. **OrchestrationLoop post-mission hook** — adds candidates to
-    `SkillLearningLoopStore` based on un-approved review findings.
-
-## Reading order for new contributors
-
-1. `CLAUDE.md` (root) — codebase contract
-2. `docs/openlife-agent-os-blueprint.md` (this file) — high-level map
-3. `docs/capability-pack-schema.md` — pack manifest details
-4. `docs/capability-genesis.md` — how packs are authored
-5. `docs/workflow-schema.md` — workflow v2 reference
-6. `docs/deep-research-capability.md` — seed-pack example
-
-Each commands runs `--help` clean (`node bin/openlife.js --help` < 2s)
-thanks to the lazy-require contract in `src/index.ts`.

package/docs/openlife-install-backlog.md

@@ -1,115 +0,0 @@
-# OpenLife Install — Backlog por Sprint
-
-## Sprint 1 — Foundation (iniciar já)
-Objetivo: criar base técnica para `openlife install` dual-mode com estado e wizard.
-
-### Entregas
-- [ ] Criar comando novo de entrada: `openlife install`
-- [ ] Implementar roteamento inicial de modo (CLI | Autonomous)
-- [ ] Criar `state-store` para checkpoint e resume (`.openlife/install-state.json`)
-- [ ] Criar contrato de etapas comuns (`precheck`, `telegram`, `chat-terminal`, `validate`)
-- [ ] Integrar com `InstallFlow` atual sem quebrar `system install`
-
-### Critérios de aceite
-- [ ] `openlife install` aparece no `--help`
-- [ ] `openlife install --resume` retoma estado salvo
-- [ ] `system install` continua funcional
-- [ ] Build TS sem erro
-
-### Testes
-- [ ] unit: salvar/ler/reset state
-- [ ] unit: seleção de modo gera etapa correta
-- [ ] smoke: `node dist/index.js install --help`
-
----
-
-## Sprint 2 — CLI Flow completo
-Objetivo: fechar trilha de instalação CLI.
-
-### Entregas
-- [ ] Precheck com saída estruturada + auto-fix opcional
-- [ ] Workspace selector (default/custom)
-- [ ] Core install + init config
-- [ ] Telegram opcional com validação real (`getMe`)
-- [ ] Chat terminal obrigatório (`openlife chat` + `--test`)
-- [ ] Validação final com relatório
-
-### Critérios de aceite
-- [ ] Fluxo CLI conclui com resumo final
-- [ ] Erro em token Telegram não passa silenciosamente
-- [ ] `openlife chat --test` retorna sucesso
-
-### Testes
-- [ ] unit: normalização de opções
-- [ ] integration: fluxo CLI happy path
-- [ ] integration: Telegram inválido falha com mensagem clara
-
----
-
-## Sprint 3 — Autonomous Flow completo
-Objetivo: fechar trilha de agente autônomo modular.
-
-### Entregas
-- [ ] Wizard de modelos: 1 | 1+2 | 1+2+3
-- [ ] Auth por modelo (API key/OAuth)
-- [ ] Roteamento/fallback real
-- [ ] Skills opcionais no setup
-- [ ] Gestão de agentes: padrão/renomear/novo/adicional
-- [ ] Ativação systemd/supervisor
-- [ ] Chat terminal obrigatório no final
-
-### Critérios de aceite
-- [ ] Serviço autônomo sobe com sucesso
-- [ ] Modelo fallback validado
-- [ ] Agente padrão existe sempre, mas nome pode mudar
-
-### Testes
-- [ ] integration: fluxo autônomo happy path
-- [ ] integration: escolha de 1 modelo sem fallback
-- [ ] integration: conflito em auth bloqueia etapa
-
----
-
-## Sprint 4 — Telegram hardening + UX recovery
-Objetivo: robustez de canal e recuperação de erro.
-
-### Entregas
-- [ ] Máscara de token em logs
-- [ ] Detecção de conflito 409 long polling
-- [ ] Fluxo de correção: parar instância concorrente/trocar token/pular
-- [ ] Retry por etapa com persistência de estado
-
-### Critérios de aceite
-- [ ] sem token completo em logs
-- [ ] conflito 409 guiado com ação corretiva
-
-### Testes
-- [ ] integration: caso conflito 409
-- [ ] security: redaction de secrets
-
----
-
-## Sprint 5 — UX final + modo headless
-Objetivo: productização final.
-
-### Entregas
-- [ ] `openlife install --mode cli|autonomous`
-- [ ] `openlife install --from-file setup.yaml`
-- [ ] `openlife install --headless`
-- [ ] relatório final padronizado + próximos comandos
-
-### Critérios de aceite
-- [ ] execução não interativa em CI
-- [ ] documentação final sincronizada
-
-### Testes
-- [ ] e2e: install headless CLI
-- [ ] e2e: install headless autonomous
-
----
-
-## Ordem de implementação recomendada (agora)
-1. Sprint 1 completo
-2. Sprint 2 completo
-3. Sprint 3 completo
-4. Sprint 4 + Sprint 5