@openlife/cli 1.7.3

package/docs/plans/2026-05-05-openlife-autonomous-domain-marketplace-masterplan.md

@@ -0,0 +1,122 @@
+# OpenLife Autonomous Domain Systems + Marketplace — Masterplan de Execução
+
+> Objetivo: construir uma plataforma para operar serviços autônomos por domínio, com times de agentes e redes de skills, contratáveis via marketplace.
+
+## 1) Ampliação solicitada (times de agentes + redes de skills)
+
+### 1.1 Times de agentes (Agent Teams)
+- Squad runtime por serviço: planner, executor, reviewer, synthesizer, compliance.
+- Escala horizontal por job (parallel branches) com arbitragem.
+- Orquestração por papéis e handoff automático por estado da missão.
+
+### 1.2 Redes de skills (Skill Networks)
+- Grafo de skills por capacidade/dominio/dependência.
+- Seleção dinâmica de skillset por tipo de missão e SLA alvo.
+- Reuso e promoção de skills baseado em performance histórica.
+
+### 1.3 Resultado esperado
+- Maior precisão: especialização por papel + skill routing.
+- Maior velocidade: paralelismo controlado + fallback inteligente.
+- Maior confiabilidade: revisão e síntese obrigatórias com trilha de execução.
+
+---
+
+## 2) Tese de produto
+OpenLife deve vender serviço completo com accountability, não “chat de IA”.
+
+Unidade comercial: Service Instance (serviço contratado) com:
+- objetivo
+- SLA
+- custo e limites
+- governança
+- prova de execução (trace + artefatos)
+
+---
+
+## 3) Arquitetura alvo
+
+### Núcleo
+- Control API
+- Runtime Orchestrator
+- Governance/Policy Engine
+- Agent Team Manager
+- Skill Network Router
+- Execution Trace Store
+- Billing Meter
+- Marketplace Service
+- Admin UI
+
+### Entidades
+- Tenant
+- ServiceTemplate
+- ServiceInstance
+- AgentTeam
+- SkillNetwork
+- MissionJob
+- ExecutionEvent
+- PolicyPack
+- Subscription
+
+---
+
+## 4) Roadmap (execução)
+
+## Fase 1 — Foundation (P0)
+1. Definir schemas de AgentTeam e SkillNetwork.
+2. Integrar resolução de time/skills ao OrchestrationLoop.
+3. Emitir tool traces estruturadas por missão.
+4. Expor status/config no painel (API primeiro).
+
+## Fase 2 — Service Templates (P0/P1)
+1. Template SDK com manifestos por domínio.
+2. Provisionamento 1-clique de ServiceInstance.
+3. Três templates iniciais: sales/social/support.
+
+## Fase 3 — Marketplace (P1)
+1. Publicar/instalar templates.
+2. Versionamento e update policy.
+3. Contratação + billing por assinatura/uso.
+
+## Fase 4 — Enterprise Hardening (P1/P2)
+1. RBAC avançado e auditoria expandida.
+2. Policy packs por domínio sensível (jurídico/saúde).
+3. SLO/SLA dashboard com alerting.
+
+---
+
+## 5) Backlog executável inicial
+
+### Sprint A (agora)
+- [ ] Criar modelos: AgentTeam.ts, SkillNetwork.ts.
+- [ ] Registrar catálogo de teams e skill networks.
+- [ ] Wiring no OrchestrationLoop para seleção dinâmica.
+- [ ] Testes unitários do roteamento.
+
+### Sprint B
+- [ ] Criar endpoints de administração (list/create/update) para teams/networks.
+- [ ] Adicionar trace completo por missão no formato Hermes-style.
+- [ ] Persistência de configuração por tenant.
+
+### Sprint C
+- [ ] Service template manifests por domínio.
+- [ ] Provisionamento via CLI/API.
+- [ ] Métricas de precisão, latência e custo.
+
+---
+
+## 6) Critérios de aceite
+- Serviço pode selecionar automaticamente time e skills por missão.
+- Execução produz trace operacional antes da resposta (modo always).
+- Admin consegue configurar teams/networks sem editar código.
+- Build + testes verdes.
+
+---
+
+## 7) Estratégia de execução aprovada
+Com base no seu “pode executar o plano completo”, iniciaremos incrementalmente:
+1) Foundation de times+skills (código + testes + docs)
+2) Admin/API
+3) Marketplace
+4) Hardening enterprise
+
+Cada etapa fecha com evidência: build, testes, smoke e commit em main.

package/docs/quickstart.md

@@ -0,0 +1,60 @@
+# OpenLife Quickstart (Atualizado)
+
+## 0) Build local
+```bash
+npm install
+npm run build
+```
+
+## 1) Verificação inicial
+```bash
+openlife --help
+openlife status
+openlife doctor
+```
+
+## 2) Fluxo padrão (Task mode)
+```bash
+openlife ask "criar plano de integração" --mode task
+```
+
+## 3) Fluxo contínuo (Service mode)
+```bash
+openlife ask "monitorar sinais sociais diariamente" --mode service
+# depois consulte o serviceId retornado e opere:
+openlife service status <serviceId>
+openlife service pause <serviceId> --reason "janela de manutenção"
+openlife service resume <serviceId> --reason "retomar operação"
+openlife service events <serviceId> --limit 20
+```
+
+## 4) Jobs e runtime
+```bash
+openlife job list --limit 20
+openlife runtime probe
+openlife runtime list
+```
+
+## 5) DesignMD + Reversa
+```bash
+openlife designmd import
+openlife designmd list
+openlife reversa mode --set designmd --profile claude
+openlife reversa run-all --note "baseline contracts"
+openlife reversa export-json
+```
+
+## 6) AIOBUILDER com contratos estritos
+```bash
+openlife aiobuilder generate-ui dashboard --strict-contracts
+```
+
+## 7) Smoke test rápido
+```bash
+npm run build && \
+node dist/test_dual_mode.js && \
+node dist/test_service_guardrails_delete.js && \
+node dist/test_telegram_delete_guardrail.js && \
+node dist/test_reversa_contracts_e2e.js && \
+node dist/test_reversa_export_and_strict.js
+```

package/docs/release-process.md

@@ -0,0 +1,236 @@
+# OpenLife — Release Process
+
+> The pattern used for v1.2 → v1.6. Each milestone is a single branch
+> opened from `main`, with one atomic commit per closed story, merged
+> via PR and tagged on the merge commit.
+
+## 1. Open the milestone branch
+
+```bash
+git checkout main
+git pull --ff-only origin main
+git checkout -b feat/v<X.Y>-<theme>
+```
+
+Naming: `feat/v1.6-sandbox-rollout`, `feat/v1.5-evaluation`,
+`feat/v1.4-tenten`. The theme is one short hyphenated phrase, not a
+sprint or epic number.
+
+## 2. Execute stories as atomic commits
+
+Each story = **one commit**. Commit message format:
+
+```
+<type>(<scope>): <short summary> (Story <N>, v<X.Y>)
+```
+
+Types in use: `feat`, `fix`, `chore`, `docs`, `test`, `refactor`.
+Examples from the actual history:
+
+```
+feat(doctor): ProcessSandbox runtime check (Story 18.1, v1.6)
+feat(executor): OPENLIFE_PROCESS_SANDBOX opt-in for runShellCommand (Story 18.2, v1.6)
+chore(types): any 109 → 83 across Gatekeeper, TestHarness, VoiceManager, admin (Story 19.1, v1.6)
+docs(v1.6): consolidated changelog with sprint/story/commit map (Cap)
+```
+
+Co-Author trailer is required:
+
+```
+Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
+```
+
+## 3. Per-commit guardrails (locally)
+
+Before each story commit:
+
+```bash
+npm run build               # tsc clean — strict, no any leak
+npm run test:<story>        # the test added for the story
+```
+
+Before merging the milestone:
+
+```bash
+npm run test:all            # the full canonical suite (~5 min)
+```
+
+`prepublishOnly` runs `test:all` automatically, so publish is gated.
+
+## 4. Write the changelog
+
+One file per milestone: `docs/v<X.Y>-changelog.md`. Sections:
+
+- **Header** — branch name, predecessor tag, one-paragraph thesis.
+- **What landed by epic** — sprint × epic × commits table.
+- **Per-epic stories** — table mapping story id → commit sha → surface
+  touched → outcome.
+- **Calendar-gated deferrals** — if any (e.g., Story 13.5).
+- **Locked decisions** — explicit defaults that stay opt-in.
+- **Tests added** — markers count, what each new `test_*.ts` covers.
+- **Honest scorecard delta** — vs the previous milestone, no
+  inflation.
+
+The roadmap file (`docs/v<X.Y>-roadmap.md`) is **optional** and only
+needed when a milestone is multi-sprint with non-obvious sequencing.
+
+## 5. Open the PR
+
+```bash
+gh pr create --base main --title "<X.Y>: <theme>" \
+  --body "$(cat <<'EOF'
+## Summary
+- <one bullet per epic>
+
+## Verification
+- [x] npm run test:all green (<N> markers)
+- [x] docs/v<X.Y>-changelog.md committed
+- [x] No new env vars introduced without docs
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+EOF
+)"
+```
+
+## 6. Merge and tag
+
+After PR approval:
+
+```bash
+gh pr merge <number> --merge      # not squash — we keep the per-story commits
+git checkout main
+git pull --ff-only origin main
+git tag -a v<X.Y>.0 -m "v<X.Y>.0 — <theme>"
+git push origin v<X.Y>.0
+```
+
+Tag the **merge commit**, not the last feature commit. That keeps the
+tag pointing at a stable PR boundary.
+
+## 7. Maintenance cuts (rare)
+
+Used when a calendar-gate requires a second tag on a line that has
+already moved on. Pattern (see `v1.4.1`):
+
+```bash
+git worktree add /tmp/openlife-v<X.Y>.<Z> v<X.Y>.0
+cd /tmp/openlife-v<X.Y>.<Z>
+git checkout -b maint/v<X.Y>.<Z>
+# touch docs/v<X.Y>-changelog.md with the maintenance section
+git commit -am "docs(maint): v<X.Y>.<Z> lineage marker — <reason>"
+git tag -a v<X.Y>.<Z> -m "..."
+git push origin maint/v<X.Y>.<Z> v<X.Y>.<Z>
+cd -
+git worktree remove /tmp/openlife-v<X.Y>.<Z>
+```
+
+The worktree avoids disrupting any in-progress work on the main
+development branch.
+
+## 8. npm publish (via GitHub Actions — Story R.2)
+
+OpenLife publishes to npm via `.github/workflows/publish.yml`. The
+workflow runs on every `v*.*.*` tag push and can also be fired
+manually via `workflow_dispatch` for retro-publishing older tags.
+
+### One-time setup (per repo)
+
+The `NPM_TOKEN` GitHub secret must exist before any publish can
+succeed.
+
+1. **Create an npm account** if you don't have one
+   (https://www.npmjs.com/signup). Enable 2FA.
+2. **Generate a Granular Access Token:**
+   - npm web → Account → Access Tokens → Generate New Token →
+     **Granular Access Token**
+   - Allowed Packages: `@openlife/*`
+   - Permissions: `Read and Write`
+   - Expiration: ≤365 days (90 days recommended; rotate quarterly)
+   - **Copy the token immediately** — it's only shown once.
+3. **Register the token as a GitHub secret:**
+   - https://github.com/GOOODZ/openlife-core/settings/secrets/actions
+   - New repository secret → Name: `NPM_TOKEN` → Value: the token
+   - **Never paste tokens into chat, code, commits, or logs.** If
+     a token leaks (committed, posted in chat, exposed in a build
+     log), revoke it on npm immediately and generate a replacement.
+
+### Per-release publish flow
+
+For tags created **after** the workflow lands (v1.7.0 and beyond):
+
+1. Cut and push the tag as documented in step 6 of this runbook.
+2. The `Publish to npm` workflow fires automatically.
+3. Track progress at
+   https://github.com/GOOODZ/openlife-core/actions/workflows/publish.yml.
+4. On success, verify with `npm view @openlife/cli@<version>`.
+
+For tags created **before** the workflow existed (v1.4.0, v1.4.1,
+v1.5.0, v1.6.0):
+
+1. https://github.com/GOOODZ/openlife-core/actions/workflows/publish.yml
+   → Run workflow → enter version (e.g. `1.6.0`) → Run.
+2. The workflow checks out the corresponding `v<version>` tag,
+   builds, runs `prepublishOnly` (= `test:all`), and publishes.
+
+### Version contract
+
+The version embedded in `package.json` on `main` intentionally stays
+at `1.0.0`. The workflow uses `npm version --no-git-tag-version` at
+runtime to set the tarball's version from the git tag. This avoids
+the per-release `package.json` bump commit on `main`.
+
+### Verification after a successful publish
+
+```bash
+npm view @openlife/cli versions                # list all published
+npm view @openlife/cli@1.6.0                   # metadata for one
+npm audit signatures @openlife/cli@1.6.0       # verify provenance
+```
+
+### If a publish fails
+
+| Error | Cause | Remedy |
+|---|---|---|
+| 403 Forbidden | Token lacks scope `@openlife/*` | Re-issue token; update `NPM_TOKEN` secret |
+| 402 Payment Required | Scoped pkg default-private | `--access=public` (already in workflow) |
+| 409 Conflict | Version already published | Bump and re-tag |
+| `prepublishOnly` fails | A test in `test:all` doesn't pass on CI runners | Reproduce locally on Node 20, fix the test, push a maintenance tag |
+| ENEEDAUTH | `NPM_TOKEN` secret missing or wrong name | Recreate the GitHub secret with the exact name `NPM_TOKEN` |
+
+## 9. Registry announce (post R.1)
+
+Once `RemoteCatalogClient` and the canonical registry ship, this step
+will write a manifest pointer for the new milestone. Today this is
+NOT required to release — the milestone is fully usable from npm and
+GitHub without it.
+
+## Rollback
+
+If a tagged release is broken:
+
+1. **Do not delete the tag remotely.** A pushed tag is a public
+   contract; deletion creates lineage confusion across consumers.
+2. Cut a maintenance tag with the fix (`v<X.Y>.<Z+1>`) following
+   step 7.
+3. Update the milestone changelog with a "Known issue / superseded
+   by" callout near the affected story.
+
+For pre-tag failures (build broken on merge):
+
+1. `git revert <merge-commit>` on `main` via a new PR.
+2. Re-tag is allowed only if the original tag was **not** pushed yet
+   (purely local). Otherwise, follow the cut-forward pattern above.
+
+## Quick reference
+
+| Step | Owner | Command |
+|---|---|---|
+| Branch | dev | `git checkout -b feat/v<X.Y>-<theme>` |
+| Per-story commit | dev | one commit + matching `test_*.ts` |
+| Full suite | dev | `npm run test:all` |
+| Changelog | dev | edit `docs/v<X.Y>-changelog.md` |
+| PR | devops | `gh pr create --base main` |
+| Merge | devops | `gh pr merge --merge` |
+| Tag | devops | `git tag -a v<X.Y>.0 && git push origin v<X.Y>.0` |
+| Maintenance | devops | worktree + `maint/v<X.Y>.<Z>` |
+| npm publish | human | `npm login` then `npm publish` |

package/docs/roadmap/OPENLIFE_MASTER_PLAN_CLOUD_V3.md

@@ -0,0 +1,97 @@
+# OPENLIFE MASTER PLAN (Cloud-First, Zero Obsidian Runtime)
+
+## Premissas
+- Runtime nunca lê Obsidian.
+- Obsidian é somente fonte de estudo/migração documental.
+- Source of truth operacional: serviços cloud (API + DB + storage).
+- Entregáveis e documentação ficam no repositório `openlife-core-main`.
+
+## Sprint S1 — Foundation (sem quebra)
+1. Introduzir interfaces de provider:
+   - `AgentProvider`, `SquadProvider`, `SkillProvider`, `WorkflowProvider`, `LearningProvider`.
+2. Implementar adapters:
+   - `Cloud*Provider` (primário)
+   - `File*Provider` (compatibilidade temporária)
+3. Injetar providers via config/ENV + feature flags.
+4. Garantir default backward compatible para não quebrar runtime atual.
+
+## Sprint S2 — Registry Migration
+1. Refatorar `AgentRegistry`, `SquadRegistry`, `SkillRegistryV2` para depender da interface provider.
+2. Remover hardcodes de paths locais como fonte principal.
+3. Habilitar modo dual-read (cloud-first com fallback técnico controlado).
+
+## Sprint S3 — Skills Management
+1. Criar `SkillManager` (create, patch, activate, deprecate, audit).
+2. Versionamento + metadata de score.
+3. Validação de schema + testes mínimos por skill.
+
+## Sprint S4 — Squad Auto-Creation
+1. Pipeline `squad.autoCreate(goal)`.
+2. Gerar artefatos obrigatórios no storage cloud:
+   - agente principal
+   - índice de uso
+   - workflow inicial
+   - nota operacional espelho (cloud docs)
+3. Integrar com roteamento e scoring.
+
+## Sprint S5 — Agent/Subagent Lifecycle
+1. Evoluir `DynamicAgentBuilder` para persistência cloud.
+2. Estados: proposed → trial → active → archived.
+3. Métricas e governança por agente/subagente.
+
+## Sprint S6 — Learn in Loop
+1. Captura operacional por execução (intenção, rota, fallback, custo, resultado).
+2. Detector de padrões recorrentes.
+3. Promoção automática governada para skill/squad/subagente.
+
+## Sprint S7 — Engenharia Reversa AIOBUILDER
+1. Inventário de capacidades e papéis.
+2. Capability graph canônico.
+3. Blueprint executável de reconstrução.
+4. Comando de rebuild validado.
+
+## Sprint S8 — Executor Policy (Claude Code como ferramenta)
+1. Regras de roteamento por risco/custo/latência.
+2. Health-check, timeout, retry, fallback.
+3. Observabilidade por execução.
+
+## Auditoria Final (gate obrigatório)
+- Arquitetura:
+  - [ ] Zero leitura Obsidian em runtime
+  - [ ] Zero hardcode local como source of truth
+- Funcional:
+  - [ ] Registries usando providers cloud
+  - [ ] Skill manager operacional
+  - [ ] Auto-criação de squad operacional
+  - [ ] Subagentes persistentes
+  - [ ] Learn-in-loop ativo
+  - [ ] Rebuild AIOBUILDER validado
+- Operação:
+  - [ ] Smoke CLI
+  - [ ] Smoke Telegram
+  - [ ] Logs/auditoria rastreáveis
+
+## Testes (mínimos)
+1. Unitários: providers, registries, policy, promoção.
+2. Integração: orquestração fim-a-fim com cloud provider mock/real de staging.
+3. Regressão: intents básicas determinísticas + fallback.
+4. Smoke: `openlife doctor`, `openlife chat`, rota Telegram.
+
+## Migração de documentação (Obsidian -> Git)
+- Fonte: notas de estudo OPEN-LIFE no vault (somente leitura para migração).
+- Destino no repo:
+  - `docs/roadmap/`
+  - `docs/architecture/`
+  - `docs/operations/`
+- Processo:
+  1. copiar conteúdo relevante
+  2. normalizar nomenclatura canônica
+  3. remover dependências de vault
+  4. vincular aos componentes reais do código
+
+## Git flow de entrega
+1. branch de trabalho
+2. commits por sprint (mensagens semânticas)
+3. execução da auditoria + testes
+4. commit final de auditoria
+5. push para GitHub

package/docs/sandboxing-research.md

@@ -0,0 +1,117 @@
+# Research — Node `--permission` API as a v1.6 sandbox primitive
+
+**Status:** v1.5 research-track output. No production wiring yet.
+**Story:** 15.1 (deferred to v1.5; landed in Sprint 3).
+
+## What we're looking at
+
+Node.js 20 introduced an experimental
+[`--permission`](https://nodejs.org/docs/latest-v20.x/api/permissions.html)
+flag that lets the parent process restrict what a child node process can
+do:
+
+- `--allow-fs-read=<path>` / `--allow-fs-write=<path>` — filesystem
+  scoping.
+- `--allow-child-process` — gate spawning further children.
+- `--allow-worker` — gate worker threads.
+- `--allow-wasi` — gate WASI.
+- `--allow-addons` — gate native addons.
+
+Anything not explicitly allowed raises `ERR_ACCESS_DENIED` inside the
+child. Node 22 stabilised most of this and added more granular fs
+scopes.
+
+## Why we care
+
+OpenLife's existing governance is **library-boundary** — `ToolsetGuard`,
+`GovernanceLayer`, `SecurityDownloadGuard`. All of those run in the
+*same* process as the executor they protect; a successful prompt
+injection could in principle bypass them by calling the underlying APIs
+directly.
+
+A `--permission` boundary moves the enforcement to the **process
+boundary**: even if the in-process guards are bypassed, the Linux/macOS
+process cannot read files outside its allow-list. That's the same
+isolation model Deno ships by default, ported to Node via the new
+runtime flag.
+
+## What we're NOT doing in v1.5
+
+- We are **not** wiring this into the executor by default. The flag is
+  experimental on Node 20, stabilised on Node 22, and OpenLife's
+  declared minimum is Node 18. Default-on would break Node 18 users.
+- We are **not** trying to sandbox the parent process. Only spawned
+  children get the permission boundary.
+- We are **not** introducing a new toolset category — `terminal` and
+  `delegation` already carry the policy intent; the sandbox flag is an
+  *implementation* of those policies, not a separate axis.
+
+## Proposed v1.6 surface
+
+A `ProcessSandbox` utility class (small implementation lands alongside
+this doc in `src/orchestrator/ProcessSandbox.ts`). Surface:
+
+```ts
+const sandbox = new ProcessSandbox({
+  allowFsRead: [cwd],
+  allowFsWrite: [path.join(cwd, '.artifacts')],
+  allowChildProcess: false,
+  allowWorker: false,
+});
+const result = await sandbox.spawn('node', ['build-script.js']);
+```
+
+Behaviour:
+
+- Detects Node major version at construction time.
+- Node 20+ → injects `--permission --allow-fs-read=… --allow-fs-write=…`
+  ahead of the user's argv.
+- Node 18 → logs a `[sandbox] downgraded — Node 18 lacks --permission`
+  warning and spawns plain (no enforcement). The result envelope sets
+  `enforced: false`.
+- Node 22+ → uses the stabilised flag names where they differ from
+  Node 20.
+
+## Migration plan toward v1.6
+
+1. **v1.5 (this milestone):** Ship the `ProcessSandbox` class + this
+   doc. Not wired anywhere. Opt-in opt-in opt-in.
+2. **v1.5 maintenance release:** Wire `ProcessSandbox` into a single
+   non-critical site — `WorldClassCommands.doctor()` script execution
+   — so we can observe enforcement behaviour in real installs.
+3. **v1.6:** Add an opt-in `OPENLIFE_PROCESS_SANDBOX=on` flag that
+   routes `TaskExecutor.runShellCommand` through `ProcessSandbox` when
+   the active profile's `toolsetAllowed` would not have permitted the
+   wider filesystem write.
+4. **v1.7:** Flip default to ON on Node 22+ runners; keep OFF on
+   Node 18 with a deprecation warning.
+
+## Open questions for v1.6 planning
+
+- **WSL / Windows behaviour.** Node's permission model is POSIX-tested;
+  WSL works but native Windows behavior of `--allow-fs-write` with
+  Windows-style paths needs verification.
+- **Performance overhead.** Each permission check is a per-syscall
+  lookup. Anecdotally < 5 % for fs-heavy workloads, but we should
+  measure with `test_performance_latency.ts` once wired.
+- **Interaction with workflow steps that genuinely need
+  child_process.** A workflow that runs `git` will need
+  `--allow-child-process`. The profile-level toolset toggle should
+  drive this.
+- **Error UX.** `ERR_ACCESS_DENIED` from a deeply nested child can be
+  unhelpful. We may want to wrap the executor output with a clearer
+  message ("blocked by sandbox: write to /etc/passwd").
+
+## Risk register
+
+| Risk | Severity | Mitigation |
+|---|---|---|
+| Node 18 EOL pressure forces us to drop it before v1.7 | Low | Track Node's official EOL calendar; OpenLife min-Node bump goes in a major release |
+| Bypass via `vm.runInNewContext` or `eval` | Med | The permission model also restricts vm and eval; we lean on Node's coverage. Document the known gaps. |
+| Operator confusion ("why did my script fail?") | Med | Verbose mode shows the exact flag list applied; doctor command will print effective sandbox config when enforcement is on. |
+
+## Decision
+
+**Land `ProcessSandbox` in v1.5 as research-track. Defer production
+wiring to v1.6.** This gives OpenLife a tested wrapper to reach for
+when Node 22 becomes the soft floor (likely H2 2026).