@openlife/cli 1.7.3 → 1.7.5

package/docs/OPENLIFE_AUDIT_2026-05-06.md

@@ -1,170 +0,0 @@
-# OpenLife — Auditoria Geral (2026-05-06)
-
-## Escopo
-
-Auditoria executada em `D:\\VSCODDE-DEV\\openlife-core-main` (`/mnt/d/VSCODDE-DEV/openlife-core-main`).
-
-Sem ações destrutivas, sem commit/push/deploy.
-
-## Estado geral
-
-- Repo correto: `https://github.com/GOOODZ/openlife-core.git`
-- Branch: `main`
-- Build TypeScript: OK
-- CLI principal: operacional via `node bin/openlife.js`
-- Testes oficiais de package:
-  - `npm run test:distribution`: OK
-  - `npm run test:orchestration`: OK
-- Skill `design-extractor`: instalada e reconhecida pelo OpenLife runtime.
-
-## Correções aplicadas após a auditoria
-
-- Runtime-source truth corrigido: `agents list` e `squads list` agora usam `.catalog/agents` e `.catalog/squads` por padrão.
-- `FileAgentProvider` e `FileSquadProvider` aceitam estrutura recursiva `.catalog/<tipo>/<id>/AGENT.md|SQUAD.md`.
-- `phase1-check` não falha mais falsamente quando a fixture de imagem não existe; o check multimodal vira skip explícito.
-- README atualizado para comandos reais (`install`, `system setup`, `up`, `start --daemon`, `chat`).
-- `npm audit fix` aplicado para `axios`/`follow-redirects`; resta apenas advisory moderado de `@anthropic-ai/sdk` com fix breaking.
-- `postinstall-check.sh` atualizado para npm moderno (`npm prefix -g`).
-- Adicionados `test:runtime-source` e `test:all`.
-- Material extra de referência encontrado em `LARA/OPEN-LIFE`; continua tratado como estratégia/documentação, não runtime.
-
-## Achados críticos remanescentes
-
-### 1. Railway último deploy falhou
-
-`railway status` aponta:
-
-- Project: `openlife-01`
-- Environment: `production`
-- Service: `openlife-01`
-
-Último deploy listado: `FAILED` (`efaa3b3f-97b4-4012-a4a2-d6f2f826dec6`).
-
-Logs via CLI não retornaram conteúdo útil nesta auditoria.
-
-Recomendação: investigar pelo Railway UI ou redeploy controlado somente com aprovação explícita.
-
-### 3. `phase1-check` falha em gateway-image
-
-Resultado:
-
-- `gateway-image`: falha por imagem de teste ausente em `.temp_images`.
-
-Recomendação: criar fixture estável de imagem de teste ou tornar o check opcional/skip explícito quando fixture não existir.
-
-### 4. Vulnerabilidades npm
-
-`npm audit --omit=dev` reportou:
-
-- `axios`: high
-- `follow-redirects`: moderate
-- `@anthropic-ai/sdk`: moderate, fix com breaking change
-
-Recomendação: aplicar `npm audit fix` para axios/follow-redirects e avaliar upgrade controlado do Anthropic SDK.
-
-## Achados importantes
-
-### 5. README tem drift de comandos
-
-README documenta:
-
-- `openlife agent start`
-
-Mas o CLI atual não lista comando `agent`; o caminho real é:
-
-- `openlife start --daemon`
-- `openlife up`
-
-Recomendação: atualizar README/INSTALL/docs/commands para superfície real.
-
-### 6. Doctor textual `system doctor` mostra Anthropic ausente como ❌
-
-Mesmo com `OPENLIFE_RUNTIME_PROFILE=oauth-only`, o comando textual `system doctor` ainda imprime `❌ env:ANTHROPIC_API_KEY`.
-
-O doctor universal (`openlife doctor`) classifica corretamente como `severity: info`.
-
-Recomendação: alinhar `system doctor` com severidade do doctor universal para não assustar operador.
-
-### 7. Railway variables parecem incompletas vs local
-
-Railway mostrou `GEMINI_API_KEY`, `TELEGRAM_BOT_TOKEN`, Nixpacks commands e Railway vars. Não apareceram no recorte:
-
-- `OPENLIFE_TELEGRAM_ALLOWED_USER_ID`
-- `OPENLIFE_RUNTIME_PROFILE`
-- `OPENLIFE_ALLOWED_LLM_EXECUTORS`
-- `OPENAI_API_KEY`
-
-Recomendação: validar vars de produção antes de redeploy/start.
-
-### 8. Não há daemon OpenLife local rodando
-
-Processos locais não mostram `openlife.js start --daemon`; só `telegram-proxy.js`.
-
-Recomendação: se a operação local for desejada, iniciar com `openlife up` após confirmar single-poller e token correto.
-
-## Pontos positivos
-
-- `npm run build`: OK
-- `node bin/openlife.js --help`: OK
-- `node bin/openlife.js status`: OK
-- `node bin/openlife.js doctor`: JSON com severidade e sem blocker de Anthropic no perfil oauth-only
-- Telegram token local valida com `getMe` para `@openlife_master_bot`
-- MCP real detecta `mcporter`, `claude`, `codex`
-- Inventário determinístico existe:
-  - 323 agentes
-  - 47 squads
-  - 71 skills
-- `design-extractor` aparece em `skills list` via `/home/rafaleao/skills/design-extractor/SKILL.md`
-- Segurança de delete tem testes dedicados.
-- `Procfile` e `NIXPACKS_START_CMD` usam `node dist/index.js start --daemon`.
-
-## Plano de ação recomendado
-
-### P0 — Estabilização operacional
-
-1. Remover dependência runtime de Obsidian/LARA para agents/squads.
-2. Corrigir Railway vars e investigar último deploy falho.
-3. Atualizar README/INSTALL para comandos reais (`install`, `up`, `start --daemon`).
-4. Corrigir `phase1-check gateway-image` com fixture ou skip controlado.
-
-### P1 — Segurança e governança
-
-1. Rodar upgrade controlado de `axios`/`follow-redirects`.
-2. Avaliar upgrade do `@anthropic-ai/sdk` sem reintroduzir Anthropic obrigatório.
-3. Trocar `execSync(curl ... token ...)` por `fetch`/axios sem interpolar token em shell em `InstallModules.ts`.
-4. Garantir que Railway usa `OPENLIFE_TELEGRAM_ALLOWED_USER_ID`.
-
-### P2 — Produto/UX
-
-1. Consolidar doctor único com severidade clara.
-2. Criar comando `openlife audit` ou `system audit`.
-3. Criar `media route-status` como alias de status, pois `media status` falha.
-4. Documentar separação Hermes vs OpenLife no README principal.
-
-### P3 — Qualidade contínua
-
-1. Criar script `test:all` para os 44 testes `src/test_*.ts`.
-2. Separar testes mutantes dos testes puros.
-3. Criar CI com build + audit + testes essenciais.
-4. Adicionar smoke Railway pós-deploy.
-
-## Comandos usados
-
-```bash
-npm run build
-node bin/openlife.js --help
-node bin/openlife.js system status
-OPENLIFE_RUNTIME_PROFILE=oauth-only node bin/openlife.js system doctor
-node bin/openlife.js doctor
-node bin/openlife.js status
-node bin/openlife.js agents list
-node bin/openlife.js squads list
-node bin/openlife.js skills list
-node bin/openlife.js mcp status --real
-node bin/openlife.js phase1-check
-npm run test:distribution
-npm run test:orchestration
-npm audit --omit=dev
-railway status
-railway deployment list
-```

package/docs/OPENLIFE_CONSOLIDATED_PLAN_2026-05-06.md

@@ -1,299 +0,0 @@
-# OpenLife — Plano Consolidado Pós-Auditoria
-
-Data: 2026-05-06
-Repo executável: `D:\\VSCODDE-DEV\\openlife-core-main`
-Referências estratégicas: `OPENLIFE_PRODUCTION/` e `LARA/OPEN-LIFE/`
-
-## Princípio operacional
-
-OpenLife deve permanecer funcional em dois modos:
-
-1. **CLI framework** — comandos determinísticos, instalação local, `openlife chat`, skills/squads/agentes/MCPs como catálogo.
-2. **Agente autônomo** — daemon contínuo, Telegram, governança, execução multi-executor, memória e auditoria.
-
-Obsidian é referência estratégica/documental. O runtime usa repo/cloud/catalog, não paths do Obsidian.
-
-## Correções já aplicadas nesta rodada
-
-### 1. Runtime-source truth
-
-Antes, agentes/squads caíam por padrão em:
-
-- `LARA/Agentes`
-- `LARA/Squads`
-
-Agora o default aponta para:
-
-- `.catalog/agents`
-- `.catalog/squads`
-
-Validação:
-
-```bash
-node bin/openlife.js agents list
-node bin/openlife.js squads list
-npm run test:runtime-source
-```
-
-### 2. Providers de catálogo local
-
-`FileAgentProvider` agora caminha recursivamente e aceita estrutura:
-
-```txt
-.catalog/agents/<id>/AGENT.md
-```
-
-`FileSquadProvider` aceita:
-
-```txt
-.catalog/squads/<id>/SQUAD.md
-```
-
-### 3. Phase1-check sem falso bloqueio multimodal
-
-`gateway-image` não falha mais quando `.temp_images` não existe. Ele registra skip explícito e mantém o check funcional.
-
-### 4. README alinhado aos comandos reais
-
-README agora prioriza:
-
-```bash
-openlife install
-openlife system setup --profile framework
-openlife system setup --profile autonomous
-openlife up
-openlife start --daemon
-openlife chat
-```
-
-Remove a dependência em comandos antigos `openlife agent start` como caminho principal.
-
-### 5. Segurança npm parcial
-
-`axios` / `follow-redirects` foram atualizados via `npm audit fix`.
-
-Pendente: `@anthropic-ai/sdk` ainda tem advisory moderado com fix breaking.
-
-### 6. Postinstall compatível com npm atual
-
-Substituído `npm bin -g` por `npm prefix -g` + `/bin`, evitando aviso falso no npm moderno.
-
-### 7. Test suite consolidada
-
-Adicionado:
-
-```bash
-npm run test:runtime-source
-npm run test:all
-```
-
-## Validação executada
-
-```bash
-bash scripts/postinstall-check.sh
-npm run test:all
-node bin/openlife.js phase1-check
-node bin/openlife.js status
-node bin/openlife.js doctor
-node bin/openlife.js agents list
-node bin/openlife.js squads list
-```
-
-Resultado: funcional.
-
-Observação: Gemini retornou 503 temporário em um check, mas fallback OpenAI funcionou e o phase1 passou.
-
-## O que ainda falta — plano priorizado
-
-## P0 — Operação confiável agora
-
-### P0.1 Railway produção
-
-Problema: último deploy Railway visto na auditoria estava `FAILED`.
-
-Ações:
-
-1. Verificar projeto correto no Railway.
-2. Validar variáveis sem expor segredos:
-   - `TELEGRAM_BOT_TOKEN`
-   - `OPENLIFE_TELEGRAM_ALLOWED_USER_ID`
-   - `OPENLIFE_RUNTIME_PROFILE`
-   - `OPENLIFE_ALLOWED_LLM_EXECUTORS`
-   - chaves/API ou OAuth conforme política.
-3. Rodar build em clone limpo GitHub.
-4. Redeploy apenas com aprovação explícita.
-5. Smoke pós-deploy:
-   - `/health` ou comando equivalente
-   - Telegram outbound/inbound
-   - `openlife status`
-   - `phase1-check` quando aplicável.
-
-### P0.2 Telegram autônomo real
-
-Ações:
-
-1. Garantir single long-poller.
-2. Validar `getMe` antes de iniciar daemon.
-3. Validar `OPENLIFE_TELEGRAM_ALLOWED_USER_ID`.
-4. Smoke Telegram no `@openlife_master_bot`.
-5. Confirmar persona Lara sem fallback mock enganoso.
-
-### P0.3 Catálogo mínimo real
-
-Hoje `.catalog/agents` e `.catalog/squads` têm exemplos/testes.
-
-Ações:
-
-1. Promover os agentes reais essenciais para `.catalog/agents`.
-2. Promover squads reais para `.catalog/squads`.
-3. Manter `LARA/OPEN-LIFE` e `OPENLIFE_PRODUCTION` como referência, não leitura runtime.
-4. Criar testes garantindo quantidade mínima real por categoria.
-
-## P1 — Agent OS vivo
-
-### P1.1 Service-centric architecture
-
-Implementar o serviço como verdade operacional contínua:
-
-- `service mode`
-- estado contínuo
-- loops de execução
-- missões/tasks como unidades transitórias
-- auditoria de decisões
-
-Entregáveis:
-
-- `ServiceRuntime`
-- `ServiceStateStore`
-- `service status`
-- `service loop --once`
-- artefato `.openlife/service-state.json`
-
-### P1.2 Dynamic Agent Builder real
-
-Do plano mestre: agentes temporários/permanentes sob demanda.
-
-Ações:
-
-1. Criar contrato `AgentSpec` completo.
-2. Gerar agente em `.catalog/agents/<id>/AGENT.md`.
-3. Validar governança antes de ativar.
-4. Registrar origem, motivo, score e expiração.
-
-### P1.3 Squads completas
-
-Regra de completude:
-
-1. agente principal
-2. índice de uso
-3. workflow inicial
-4. nota espelhada no Obsidian `LARA/Squads/`
-
-Mas runtime deve ler do repo/cloud, não do Obsidian.
-
-## P2 — Marketplace/catalogos seguros
-
-Baseado na visão `LARA/OPEN-LIFE`:
-
-- Agents
-- Squads
-- Skills
-- MCPs
-- modelos
-- workflows
-
-Ações:
-
-1. Expandir `sources guard-check`.
-2. Implementar import com scan obrigatório.
-3. Bloquear `.env`, `.git`, scripts perigosos, executáveis, `node_modules`.
-4. Criar `catalog promote` para promover material validado para `.catalog`.
-5. Registrar auditoria em `.artifacts/security-events.jsonl`.
-
-## P3 — Memória e aprendizado
-
-Do MASTERPLAN V2: memória como infraestrutura.
-
-Ações:
-
-1. Separar memória curta/média/longa.
-2. Criar promotion loop com score.
-3. Não depender de Obsidian como memória runtime.
-4. Criar `memory promote`, `memory audit`, `memory recall`.
-
-## P4 — Mídia, visão e criação
-
-Ordem de modelos de imagem definida:
-
-1. `gpt-image-2-2026-04-21`
-2. `gemini-3.1-flash-image-preview`
-3. `Qwen Image`
-4. `Nano Banana Pro / Gemini`
-
-Ações:
-
-1. Criar `ImageModelRouter`.
-2. Criar política de fallback com log.
-3. Integrar com assets/carrosséis/vídeo.
-4. Registrar decisões em `.openlife/media-routing.log.jsonl`.
-5. Usar FFmpeg/Remotion para composição final.
-
-## P5 — Segurança e governança enterprise
-
-Ações:
-
-1. Resolver advisory Anthropic SDK em branch dedicada.
-2. Redação/redaction universal de respostas Telegram.
-3. Consentimento para ações destrutivas/deploy/push.
-4. Policy por executor/modelo/projeto.
-5. Smoke CI obrigatório.
-
-## P6 — Produto instalável
-
-Ações:
-
-1. `openlife install` guiado completo.
-2. `openlife update`, `upgrade`, `restart`, `up` confiáveis.
-3. Instalação Windows/WSL limpa.
-4. Template `.env.example` seguro.
-5. Documentação com comandos reais.
-
-## Próximo bloco recomendado
-
-**Bloco 1 — Railway + Telegram produção**
-
-Motivo: o core local já passa build/test/phase1. Agora o maior risco é produção/daemon.
-
-Critérios de pronto:
-
-- Railway deploy `SUCCESS`.
-- Bot `@openlife_master_bot` responde via runtime OpenLife.
-- Sem segundo long-poller.
-- `openlife status`/`doctor` coerentes.
-- Sem fallback mock enganoso.
-
-**Bloco 2 — Catálogo real mínimo**
-
-Migrar do material estratégico para `.catalog`:
-
-- Lara core agent
-- AIOBUILDER agents
-- squads principais
-- workflows iniciais
-- skill networks
-
-Critérios de pronto:
-
-- `agents list` mostra agentes reais, não demos.
-- `squads list` mostra squads reais, não demos.
-- Teste impede fallback Obsidian/LARA.
-
-## Notas de fonte
-
-Materiais consultados/considerados:
-
-- `OPENLIFE_PRODUCTION/OPENLIFE_MASTERPLAN_V2.md`
-- `OPENLIFE_PRODUCTION/open-life-core/*`
-- `LARA/OPEN-LIFE/OPEN-LIFE Platform - Arquitetura Definitiva.md`
-- `LARA/OPEN-LIFE/00_MAPS/OPEN-LIFE - MAPA ESTRUTURAL CANÔNICO.md`
-- auditoria local `docs/OPENLIFE_AUDIT_2026-05-06.md`

package/docs/OPENLIFE_DUAL_MODE_IMPLEMENTATION_PLAN.md

@@ -1,205 +0,0 @@
-# OpenLife Dual Mode (Task/Service) — Implementation Plan
-
-> **For Hermes:** execute in phases with build validation after each phase.
-
-**Goal:** Implement explicit user choice between Task and Service execution modes, with Task as default and Service opt-in.
-
-**Architecture:** Add a normalized execution intent (`mode`) at ingress, route execution through dedicated paths, and enforce mode-specific governance/observability while preserving current mission/service artifacts.
-
-**Tech Stack:** TypeScript, existing OpenLife orchestrator modules, npm build/test.
-
----
-
-## Phase 1 — Intent Contract (explicit mode)
-
-### Task 1.1: Add execution mode types
-**Files:**
-- Create: `src/orchestrator/ExecutionIntent.ts`
-
-**Changes:**
-- Add `ExecutionMode = 'task' | 'service'`
-- Add `ExecutionIntent` interface with `mode`, `goal`, optional `serviceId`, `riskProfile`, `budgetPolicy`, `origin`.
-
-**Verification:**
-- `npm run build`
-
-### Task 1.2: Wire mode into mission state
-**Files:**
-- Modify: `src/orchestrator/MissionState.ts`
-
-**Changes:**
-- Add `mode: 'task' | 'service'` to mission state schema.
-- Ensure persisted mission JSON includes `mode`.
-
-**Verification:**
-- `npm run build`
-
----
-
-## Phase 2 — Execution Router and split paths
-
-### Task 2.1: Add router
-**Files:**
-- Create: `src/orchestrator/ExecutionRouter.ts`
-
-**Changes:**
-- Implement `route(intent)` returning `task` or `service` path handler.
-- Default behavior when mode missing should be injected upstream (not inside router).
-
-### Task 2.2: Separate run methods in orchestration loop
-**Files:**
-- Modify: `src/orchestrator/OrchestrationLoop.ts`
-
-**Changes:**
-- Extract `runTaskMode(...)` and `runServiceMode(...)` from current monolithic flow.
-- Preserve existing consequence forecast and governance checks.
-- Ensure service path updates `ServiceStateStore`; task path does not require continuous service lifecycle.
-
-**Verification:**
-- `npm run build`
-- Existing consequence forecaster test remains green.
-
----
-
-## Phase 3 — Ingress normalization (CLI + Telegram)
-
-### Task 3.1: Normalize CLI input
-**Files:**
-- Modify: CLI command parser files (identify exact files in `src/` command layer)
-
-**Changes:**
-- Parse `--mode task|service`.
-- If absent, set `mode='task'`.
-
-### Task 3.2: Normalize Telegram input
-**Files:**
-- Modify: Telegram message handling files in gateway/orchestrator
-
-**Changes:**
-- Detect explicit phrases ("como tarefa", "como serviço").
-- If ambiguous, return concise disambiguation prompt.
-- Do not auto-promote task->service.
-
-**Verification:**
-- `npm run build`
-- Manual chat simulation for both modes.
-
----
-
-## Phase 4 — Governance by mode
-
-### Task 4.1: Task policy enforcement
-**Files:**
-- Modify: `src/orchestrator/GovernanceLayer.ts`
-
-**Changes:**
-- Apply per-run risk/consent/budget checks for task mode only.
-
-### Task 4.2: Service policy enforcement
-**Files:**
-- Modify: `src/orchestrator/GovernanceLayer.ts`
-- Modify: `src/orchestrator/ServiceState.ts`
-
-**Changes:**
-- Enforce service status gates (`paused`, `archived`, `critical` policy).
-- Add budget thresholds and hard-stop event emissions.
-
-**Verification:**
-- `npm run build`
-- Add targeted tests for hard-stop and paused-service blocking.
-
----
-
-## Phase 5 — Observability and control surface
-
-### Task 5.1: Service status/events commands
-**Files:**
-- Modify: command router/CLI handlers
-- Modify: Telegram command handlers
-
-**Changes:**
-- Add/read:
-  - `service status <id>`
-  - `service pause <id>`
-  - `service resume <id>`
-  - `service events <id>`
-  - `task status <taskId>`
-
-### Task 5.2: Read models for summaries
-**Files:**
-- Create: `src/orchestrator/ServiceReadModel.ts` (optional)
-
-**Changes:**
-- Build compact summary object for chat-safe output.
-
-**Verification:**
-- `npm run build`
-- Manual command checks.
-
----
-
-## Phase 6 — Opt-in conversion only
-
-### Task 6.1: Promote task to service (explicit)
-**Files:**
-- Modify: command handling layer
-- Modify: `src/orchestrator/ServiceState.ts`
-
-**Changes:**
-- Add explicit promote command path.
-- Record conversion event in service ledger.
-
-### Task 6.2: Service run-once
-**Files:**
-- Modify: orchestration command layer + loop
-
-**Changes:**
-- Execute one cycle from service context without changing service type.
-
-**Verification:**
-- `npm run build`
-- Add tests ensuring no implicit conversion occurs.
-
----
-
-## Phase 7 — Validation matrix
-
-### Required checks
-1. Build:
-- `npm run build`
-
-2. Existing tests:
-- `node dist/test_consequence_forecaster.js`
-
-3. New tests to add:
-- mode default = task
-- explicit service route
-- no auto-promotion task->service
-- service paused blocks execution
-- budget hard-stop triggers pause + event
-
-4. Artifact checks:
-- Task run writes only mission artifacts.
-- Service run writes mission + service + events.
-
----
-
-## Definition of Done
-- Mode is explicit end-to-end (`task|service`).
-- Task is default and remains lightweight.
-- Service is opt-in and lifecycle-managed.
-- No automatic task->service conversion.
-- Governance and observability are mode-aware.
-- CLI and Telegram support equivalent mode operations.
-- Build green + targeted tests passing.
-
----
-
-## Execution Order (recommended)
-1. Phase 1
-2. Phase 2
-3. Phase 3
-4. Phase 4
-5. Phase 5
-6. Phase 6
-7. Phase 7