@openlife/cli 1.7.4 → 1.7.5

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

package/docs/OPENLIFE_EVOLUTION_SURFACE_2026-05-07.md

@@ -1,53 +0,0 @@
-# OpenLife Evolution Surface — 2026-05-07
-
-## O que foi consolidado
-
-- O runtime agora lê o catálogo canônico do repo (`.catalog`) e não depende de leitura direta do Obsidian/LARA.
-- Foram espelhados agentes de referência de `LARA/Agentes` para `.catalog/agents/<id>/AGENT.md`.
-- O catálogo passou a conter mais de 300 agentes disponíveis no runtime.
-- Tokens/segredos detectados no material espelhado foram redigidos antes de commit.
-
-## Comandos adicionados/fortalecidos
-
-```bash
-openlife catalog doctor
-openlife catalog list
-openlife service list
-openlife service create <serviceId> --objective "..."
-openlife task list
-openlife task run "objetivo" --service <serviceId>
-openlife swarm run "objetivo"
-openlife aiobuilder create-agent <id>
-openlife aiobuilder create-squad <id>
-openlife aiobuilder validate-catalog
-openlife smoke railway
-openlife smoke telegram
-```
-
-## Garantias
-
-- `openlife catalog doctor` exige pelo menos 300 agentes.
-- `openlife agents list` deve retornar fonte em `.catalog/agents`.
-- `openlife swarm run` gera `.openlife/swarm-last-run.json`.
-- `openlife aiobuilder validate-catalog` valida que o AIOBUILDER tem catálogo suficiente para operar.
-- `openlife smoke railway` valida endpoint HTTP de produção sem expor segredos.
-- `openlife smoke telegram` usa `getMe` e só retorna metadados seguros do bot.
-
-## Teste de regressão
-
-```bash
-npm run test:evolution-surface
-```
-
-Esse teste cobre:
-
-- catálogo com 300+ agentes;
-- runtime agents vindo de `.catalog`;
-- swarm artifact;
-- AIOBUILDER catalog validation;
-- service create/list;
-- task run com serviço associado.
-
-## Observação arquitetural
-
-`LARA/Agentes` e `LARA/OPEN-LIFE` permanecem referência estratégica/histórica. O runtime operacional do OpenLife deve usar `.catalog` local/cloud como fonte canônica.