@openlife/cli 1.7.4 → 1.7.6

package/docs/openlife-install-spec.md

@@ -1,306 +0,0 @@
-# OpenLife Install Spec (Terminal-First, Dual Mode)
-
-## Command Goal
-`openlife install` is the single onboarding entrypoint with two primary modes:
-
-1. **Install CLI**
-2. **Install Autonomous Agent**
-
-Mandatory qualities:
-- modular architecture
-- idempotent execution
-- no silent mock fallback
-- real validation at each critical step
-- failure recovery with retry/resume
-- terminal chat functional at the end
-- Telegram setup available in both modes
-
----
-
-## High-Level Architecture
-
-- `install.entry.ts` — mode routing and flow orchestration
-- `install.wizard.ts` — interactive prompts + navigation
-- `modules/precheck.ts`
-- `modules/core-install.ts`
-- `modules/model-auth.ts`
-- `modules/model-routing.ts`
-- `modules/skills.ts`
-- `modules/agent-manager.ts`
-- `modules/telegram.ts`
-- `modules/chat-terminal.ts`
-- `modules/service-manager.ts`
-- `modules/validate.ts`
-- `modules/recovery.ts`
-- `modules/state-store.ts`
-
----
-
-## Main Flow Tree
-
-```text
-openlife install
- ├─ Welcome screen
- ├─ Mode selection
- │   ├─ [1] CLI
- │   └─ [2] Autonomous Agent
- ├─ Run selected mode flow
- ├─ Shared finalization
- │   ├─ terminal chat enable/validate
- │   ├─ install summary
- │   └─ next commands (copy/paste)
- └─ End
-```
-
----
-
-## Flow A — CLI Installation
-
-1. **Precheck**
-   - Node/npm/runtime checks
-   - path permission checks
-   - network checks
-   - optional auto-fix
-
-2. **Workspace selection**
-   - default or custom path
-
-3. **Core CLI install**
-   - install runtime artifacts/binary
-   - write baseline config
-
-4. **Initial CLI config**
-   - language
-   - log verbosity
-   - default profile
-
-5. **Telegram setup (optional, recommended)**
-   - collect `BOT_TOKEN`
-   - collect optional `CHAT_ID`
-   - validate token with Telegram API
-   - save secret securely
-   - optional send test message if `CHAT_ID` provided
-
-6. **Terminal chat setup (mandatory)**
-   - enable `openlife chat`
-   - run chat smoke test
-
-7. **Final validation**
-   - `openlife --version`
-   - `openlife doctor`
-   - `openlife status`
-   - `openlife chat --test`
-
----
-
-## Flow B — Autonomous Agent Installation
-
-1. **Autonomous precheck**
-   - dependency checks
-   - process manager availability (systemd/supervisor)
-
-2. **Agent runtime installation**
-   - install autonomous runtime
-   - install control commands
-
-3. **Model setup wizard**
-   User selects one option:
-   - only Model 1
-   - Model 1 + Model 2
-   - Model 1 + Model 2 + Model 3
-
-   For each selected model:
-   - choose auth method: API Key or OAuth/Auth
-   - input credentials
-   - validate immediately
-
-4. **Model routing/fallback**
-   - define order M1 → M2 → M3
-   - run real routing/fallback test
-
-5. **Optional skill installation**
-   - choose additional skills to install now
-   - configure required API credentials per skill
-   - validate skill readiness
-
-6. **Agent management (modular core)**
-   options:
-   - continue with default agent
-   - rename default agent (e.g. Lara → custom)
-   - create new agent
-   - create additional agent
-
-   rule:
-   - default agent always exists
-   - default name can be customized
-
-7. **Telegram setup (optional, recommended)**
-   - token/chat setup and validation
-   - anti-conflict polling checks
-
-8. **Continuous activation**
-   - install/start/enable service via systemd/supervisor
-
-9. **Terminal chat setup (mandatory)**
-   - `openlife chat` must work as manual control interface
-
-10. **End-to-end validation**
-   - service healthy
-   - agent responds
-   - model chain validated
-   - Telegram validated (if configured)
-   - terminal chat validated
-
----
-
-## Telegram Module Spec (Both Modes)
-
-### Prompt
-- “Connect Telegram now?”
-  - Yes / No
-
-If Yes:
-1. ask for `BOT_TOKEN`
-2. ask for optional `CHAT_ID`
-3. validate via `getMe`
-4. if `CHAT_ID` provided, run send test
-5. persist secure secret
-
-### Security Rules
-- mask token in UI/logs (`123456:ABC...XYZ`)
-- never log full token
-- support token rotation command post-install
-
-### Conflict-409 Protection
-Before polling start:
-- detect existing long-poller with same token
-- if conflict:
-  - option A: stop conflicting process
-  - option B: provide different token
-  - option C: skip Telegram for now
-
----
-
-## Terminal Chat Spec (Mandatory)
-
-### Command
-- `openlife chat`
-- optional direct alias: `openlife`
-
-### Minimum behavior
-- interactive prompt/reply loop
-- shows active agent/model/session status
-
-### Minimum slash commands
-- `/help`
-- `/model`
-- `/tools`
-- `/exit`
-
-### Test commands
-- `openlife chat --test`
-- `openlife chat --agent <name>`
-- `openlife chat --model <id>`
-
----
-
-## Official Wizard Prompt Sequence
-
-1. Welcome
-   - “How do you want to install OpenLife?”
-   - (1) CLI
-   - (2) Autonomous Agent
-
-2. Precheck
-   - “Run environment checks now?”
-
-3. Workspace
-   - “Choose installation directory: default/custom”
-
-4. Model setup (autonomous mode)
-   - “How many models to configure now?”
-   - 1 / 1+2 / 1+2+3
-
-5. For each model
-   - “Auth method: API Key or OAuth/Auth?”
-   - “Enter credential”
-   - “Validate now?”
-
-6. Skills (autonomous mode)
-   - “Install additional skills now?”
-
-7. Agent management (autonomous mode)
-   - use default / rename default / create new / create additional
-
-8. Telegram (both modes)
-   - “Connect Telegram now?”
-   - token + optional chat id + validation
-
-9. Terminal chat (both modes)
-   - mandatory setup and smoke validation
-
-10. Finish
-   - “Run full validation now?”
-
----
-
-## State Persistence + Resume
-
-State file: `.openlife/install-state.json`
-
-Stores:
-- selected mode
-- completed steps
-- current step
-- retries/errors
-- timestamps
-
-Resume command:
-- `openlife install --resume`
-
----
-
-## Error Handling + Recovery
-
-Per step:
-- show human-readable error + concise technical cause
-- provide actionable fix suggestions
-- offer:
-  - retry step
-  - skip optional step
-  - abort and save state
-
-Forbidden:
-- fake success
-- hidden auth/network failures
-
----
-
-## Definition of Done
-
-Installation status is **SUCCESS** only if:
-- chosen flow completed without critical failures
-- `openlife chat` works
-- autonomous mode: service active + responsive
-- Telegram mode (if enabled): valid token and no active polling conflict
-- final summary includes operational next commands
-
----
-
-## Final Output Commands (Always Show)
-
-- `openlife chat`
-- `openlife status`
-- `openlife doctor`
-- `openlife models list`
-- `openlife agents list`
-- `openlife telegram status` (if Telegram configured)
-
----
-
-## Future-Proof Extensions
-
-- `openlife install --mode cli|autonomous`
-- `openlife install --from-file setup.yaml`
-- `openlife install --headless` (CI/devops)
-- multi-profile install presets (dev/stage/prod)

package/docs/operations/CLOUD_CUTOVER_AUDIT.md

@@ -1,37 +0,0 @@
-# Cloud Cutover Audit (Phase 1)
-
-## Escopo executado
-- Introduzida abstração de providers para registries:
-  - `src/orchestrator/providers/AgentProvider.ts`
-  - `src/orchestrator/providers/SquadProvider.ts`
-  - `src/orchestrator/providers/SkillProvider.ts`
-- Implementados providers de compatibilidade por arquivo:
-  - `FileAgentProvider.ts`
-  - `FileSquadProvider.ts`
-  - `FileSkillProvider.ts`
-- Refatorados registries para depender de provider (não parser inline):
-  - `AgentRegistry.ts`
-  - `SquadRegistry.ts`
-  - `SkillRegistryV2.ts`
-- Migração documental inicial (estudo -> git docs):
-  - `docs/imported-from-study/*`
-
-## Testes executados
-- Build TypeScript: ✅ `npm run build`
-
-## Resultado
-- Compatibilidade preservada com fonte por arquivo via provider.
-- Estrutura pronta para plugar `Cloud*Provider` sem quebrar API dos registries.
-
-## Pendências para fechar plano completo
-1. ~~Implementar `CloudAgentProvider`, `CloudSquadProvider`, `CloudSkillProvider`.~~ ✅
-2. ~~Habilitar cloud-first + fallback controlado por flag.~~ ✅ (composite providers)
-3. ~~Implementar Skill Manager (create/patch/activate/audit).~~ ✅ (módulo inicial)
-4. Auto-criação completa de squads (4 artefatos) no storage cloud.
-5. Persistência de subagentes com lifecycle.
-6. Learn-in-loop com detector de padrões e promoção.
-7. Módulo de engenharia reversa e rebuild AIOBUILDER.
-8. Smoke Telegram + auditoria final de produção.
-
-## Conclusão de auditoria desta fase
-**APROVADO (fase parcial)**: base técnica estável para evolução sem quebra.

package/docs/operations/PHASE_PROGRESS_CONTINUATION.md

@@ -1,24 +0,0 @@
-# Phase Continuation Progress
-
-## Newly implemented in this continuation
-
-### 1) Squad auto-creation (cloud asset bundle)
-- Module: `src/orchestrator/SquadAutoCreator.ts`
-- Generates required 4 artifacts in cloud assets dir:
-  1. principal-agent.json
-  2. usage-index.json
-  3. workflow-initial.json
-  4. operational-note.json
-
-### 2) Subagent lifecycle persistence
-- Module: `src/orchestrator/SubagentLifecycle.ts`
-- Lifecycle states:
-  - proposed
-  - trial
-  - active
-  - archived
-- Supports create, list, transition with persisted JSON backing store.
-
-## Notes
-- Runtime remains backward compatible.
-- This is implementation groundwork; wiring into orchestrator flow is next step.

package/docs/performance-benchmarks.md

@@ -1,83 +0,0 @@
-# OpenLife — performance benchmarks (Story 12.4)
-
-OpenLife ships a lightweight latency benchmark that runs inside `test:all`.
-It exists to catch order-of-magnitude regressions on hot paths between
-releases — not to do exact numerical profiling.
-
-## What it measures
-
-`src/test_performance_latency.ts` measures P50 / P95 / P99 / mean for three
-benchmarks:
-
-| Name | Function under test | Notes |
-|---|---|---|
-| `intent_classify_cold` | `IntentClassifier.classify(...)` | Cold path through the heuristic dispatcher. |
-| `toolset_guard_off` | `isToolsetAllowed('terminal')` | With enforcement OFF (default), should be ~ a few microseconds. |
-| `profile_manager_list` | `ProfileManager.list()` | Real disk read with 5 seeded profiles in a tmp dir. |
-
-Each benchmark runs 5 warm-up iterations + 200–500 timed iterations. Samples
-are sorted; percentiles are positional (`p[i] = sorted[floor((n-1) * i)]`).
-
-## Where the baseline lives
-
-`.artifacts/perf-baseline.json` — autogenerated on first run, then read on
-every subsequent run. The repo's `.gitignore` excludes `.artifacts/`, so
-each environment (dev machine, CI runner) seeds its own baseline. The CI
-job in `.github/workflows/test.yml` uploads the baseline as an artifact so
-operators can pull it down for inspection or to lock it across runs.
-
-## Regression threshold
-
-A run fails (process exit code 1) if any benchmark's **P95** is more than
-`PERF_REGRESSION_THRESHOLD_PCT` % above the baseline's P95. Default `30`.
-Override for a noisier CI runner:
-
-```bash
-PERF_REGRESSION_THRESHOLD_PCT=50 npm run test:performance-latency
-```
-
-The threshold is intentionally generous because Node's microbenchmark
-variance on shared CI runners is non-trivial (~10–20 %). Tighten it
-manually if you know your runner is dedicated.
-
-## Refreshing the baseline
-
-After a deliberate change that legitimately changes performance, lock the
-new baseline:
-
-```bash
-PERF_REFRESH_BASELINE=1 npm run test:performance-latency
-```
-
-Commit the resulting `.artifacts/perf-baseline.json` (force-add — it is
-otherwise gitignored) if you want it to travel with the repo. Most teams
-just keep it in CI artifact storage and re-seed locally as needed.
-
-## Reading the output
-
-```
-[perf] ✓ intent_classify_cold         P95 now=0.002ms vs baseline=0.002ms (+0.0%)
-[perf] ✓ toolset_guard_off            P95 now=0.001ms vs baseline=0.001ms (+0.0%)
-[perf] ❌ profile_manager_list         P95 now=12.500ms vs baseline=7.500ms (+66.7%)
-[perf] REGRESSION DETECTED:
-  • profile_manager_list: P95 +66.7% > threshold 30%
-```
-
-`✓` means within budget. `❌` flags a regression and exits non-zero.
-
-## Why not a CLI-spawn benchmark?
-
-The plan called for one (P50/P95/P99 of `openlife --help`, `workflow list`,
-etc.). That was discarded for three reasons:
-
-1. **Variance.** Spawning a fresh `node` process adds ~50 ms of cold-start
-   noise that swamps everything else.
-2. **Suite budget.** `test:all` already runs ~4 minutes. Adding a
-   spawn-benchmark would push it over the 5-minute target.
-3. **Signal/noise.** The hot paths we actually care about (Brain, intent
-   routing, toolset checks) are well-isolated library functions. Measuring
-   them directly gives more actionable telemetry.
-
-A spawn-based smoke test of the CLI surface still exists — see
-`src/test_cli_diagnostics.ts` — but it is correctness-focused, not
-latency-focused.

package/docs/planning/v1.3-capability-genesis.md

@@ -1,157 +0,0 @@
-# v1.3 Capability Genesis Engine — Planning Note
-
-**Status:** Backlog. To be opened as a formal epic after v1.2 (`feat/v1.2-royal-stack`) merges.
-
-**Source:** Hermes (Obsidian-stored knowledge agent) — 2026-05-12 conversational spec.
-
----
-
-## Why this exists
-
-The current v1.2 plan defines Workflow + Squad + Skill creators and the Workflow engine. The Hermes spec **goes deeper**:
-
-- Workflow is not just an executable YAML — it is a **living contract of execution** with 18 mandatory components (identity, objective, triggers, context, mode, agents, squads, skills, tools allowed/restricted/forbidden, policies, steps, decisions, checkpoints, validation, evidence, recovery, audit, learning).
-- Auto-creation is the **evolutionary mechanism**: the system detects capability gaps and converts experience into new workflows, skills, agents, squads automatically.
-- The atomic unit of evolution is a **Capability Pack** — a bundle of workflow + squad + agents + skills + checklists + templates + policies + tests, autocontido.
-
-This will be the v1.3 epic. v1.2 ships the foundation (engine, creators, atomic writes, locks, checkpoints, heartbeat); v1.3 ships the genesis loop.
-
----
-
-## v1.3 Epic Sketch — "Capability Genesis Engine"
-
-### Epic Goal
-Transform OpenLife from a "library of workflows" into a system that **builds its own library** as it operates.
-
-### Pillar 1 — Workflow Schema Evolution (extends v1.2 WorkflowSchema)
-
-New mandatory fields in `WorkflowSchema.ts`:
-- `mode: task | service` (currently implicit)
-- `triggers: [user_command | event | schedule | recurrence | failure_signal]`
-- `context_required: [paths or env keys]`
-- `tools: { allowed, restricted, forbidden }`
-- `policies: { require_human_approval, block_if, on_destructive }`
-- `validation: { quality_gates }` (not just `creates`)
-- `evidence: { required_artifacts, success_criteria }`
-- `failure_handling: { on_test_failure, on_deploy_failure, on_policy_block, retry, fallback, rollback }`
-- `audit: { emit_events, ledger_path }`
-- `learning: { update_memory, propose_skill_patch, propose_workflow_patch }`
-
-### Pillar 2 — Capability Pack as canonical bundle
-
-New artifact type:
-```
-deep-research.capability/
-├── workflow.yaml
-├── squad.yaml
-├── agents/*.yaml
-├── skills/*.md
-├── checklists/*.md
-├── templates/*.md
-├── policies.yaml
-├── tests/*.ts
-└── pack.json
-```
-
-CLI:
-- `openlife capability list`
-- `openlife capability show <id>`
-- `openlife capability publish <id>` (promote from draft → tested → active)
-- `openlife capability install <pack.tar.gz>`
-
-### Pillar 3 — Capability Genesis Engine (autocriação)
-
-Components:
-- `WorkflowCreator` — already planned in v1.2 (extend in v1.3)
-- `SquadCreator` — already planned
-- `SkillCreator` — already planned
-- `AgentCreator` — new
-- `ChecklistCreator` — new
-- `TemplateCreator` — new
-- `CapabilityValidator` — checks pack integrity
-- `CatalogPublisher` — publishes to `.catalog/` with status lifecycle
-
-Conversational UX:
-```
-openlife create capability "pesquisa profunda profissional"
-```
-→ IA detects this needs workflow + squad + 7 agents + 5 skills + 1 checklist + 1 template
-→ Asks ~10 calibration questions (modo rápido / profissional / elite)
-→ Generates the whole Capability Pack as `draft` status
-→ Validates internal consistency
-→ Returns to operator for review or executes in experimental mode
-
-### Pillar 4 — Genesis Loop (`Task Genesis Loop`)
-
-```
-User request → classify intent → lookup workflow → if exists, run
-                                               → if missing or insufficient:
-                                                 → Capability Genesis
-                                                   → create draft pack
-                                                   → execute draft
-                                                   → validate
-                                                   → if quality ≥ threshold and user permits:
-                                                     promote draft → active
-```
-
-States:
-- `draft` — IA-generated, not yet used by router
-- `tested` — passed at least one execution + validation
-- `active` — router may use without prompt
-- `deprecated` — replaced
-
-### Pillar 5 — Service Mode (long-running operations)
-
-Distinguish missions:
-- **Task mode** (default) — finite delivery, completes when validated
-- **Service mode** — continuous, has KPIs/events/health, never "completes"
-
-Examples:
-- Task: "Fix this bug" → ends when PR merges
-- Service: "Monitor this Telegram channel" → indefinite, with degraded states
-
-Engine: `WorkflowEngine` supports both. Service mode promotes lifecycle to `ServiceState` (already exists, now formalized as workflow target).
-
-### Pillar 6 — Learning Loop
-
-After every execution:
-- What worked? What failed?
-- Should a new skill be created? Workflow updated? Agent improved?
-- Any new risks discovered?
-- User preferences learned?
-
-Outputs:
-- `learning_proposals.jsonl` event log
-- `*-skill-patch.draft.md` candidates
-- `*-workflow-patch.draft.yaml` candidates
-
-User reviews proposals, promotes to active.
-
----
-
-## Canonical definition (from Hermes — to be added to root docs after v1.2)
-
-> Workflow, no OpenLife, é uma especificação operacional executável, governada, auditável e evolutiva que transforma uma intenção em resultado validado. Ele coordena agentes, squads, skills, ferramentas, memória, políticas, checkpoints, decisões, validações, evidências e mecanismos de recuperação para executar tarefas ou serviços de forma segura, reutilizável e continuamente aprimorável.
->
-> Além de organizar a execução, um workflow participa da evolução do próprio sistema: quando identifica lacunas, recorrências ou novos padrões de trabalho, pode acionar a autocriação ou atualização de skills, agentes, squads, checklists, templates e outros workflows, convertendo aprendizado operacional em capacidade permanente do OpenLife.
-
----
-
-## Mapping to v1.2 work
-
-| v1.2 deliverable | v1.3 extension |
-|---|---|
-| `WorkflowSchema` (Story 4.1) | Extend with 14 new mandatory fields (mode/triggers/context/tools/policies/validation/evidence/failure_handling/audit/learning) |
-| `WorkflowEngine` (Story 4.2) | Add tool-permission enforcement, policy blocks, learning hooks, service mode |
-| `SquadCreator` (Story 5.1) | Add to Capability Genesis pipeline as one of N creators |
-| `SkillCreator` (Story 5.2) | Same |
-| `AIOBuilder CLI` (Story 5.4) | `openlife create capability` becomes the universal entry; sub-creators are internal |
-| `dist-templates/workflows/` (Story 4.4) | Become "starter Capability Packs" not just standalone workflows |
-
----
-
-## Status
-
-- v1.2 finishes the foundation (target: ~ 14-18 days from 2026-05-12).
-- v1.3 epic to be opened immediately after v1.2 merges to `main`.
-- This document is the seed; the v1.3 plan will refine into ~25-30 stories across 6 pillars.

package/docs/plans/2026-05-05-admin-interface-professional-dark-premium-plan.md

@@ -1,84 +0,0 @@
-# OpenLife Interface Profissional — Dark Premium Plan
-
-## Objetivo
-Evoluir de MVP para uma interface enterprise-grade para operação de serviços autônomos por domínio, com estética dark premium, alta densidade informacional e UX operacional (NOC-style).
-
-## Princípios de Design
-- Dark premium real: contraste alto, profundidade por camadas, tipografia forte, microinterações discretas.
-- "Operator-first": menos marketing, mais controle/estado/ação.
-- Everything traceable: toda decisão visível via timeline e tool-trace.
-- Segurança por default: RBAC, escopo por tenant, auditoria.
-
-## Arquitetura de Frontend (fase profissional)
-- Stack: Next.js + TypeScript + Tailwind + shadcn/ui + TanStack Query.
-- Design tokens: tema via CSS variables (color, spacing, radius, motion).
-- Estado: server-state com cache e optimistic updates.
-- Observabilidade UI: Sentry + OpenTelemetry web.
-
-## IA/Operação Screens (v1 profissional)
-1. Command Center
-- Health global (tenants, serviços ativos, incidentes, custo/h).
-- Event stream em tempo real.
-- Alert rail com severidade.
-
-2. Agent Fleet
-- Lista/grid de agentes por domínio e tenant.
-- Start/stop/pause, fallback chain, SLA profile.
-- Runtime trace (tool labels + duration + artifact links).
-
-3. Service Templates Marketplace
-- Catálogo por domínio (jurídico, saúde, vendas, social, suporte).
-- Install/provision wizard.
-- Versionamento, changelog, compatibilidade.
-
-4. Mission Console
-- Conversa com agente + painel de execução lado a lado.
-- Tree de passos (planner/executor/reviewer/synthesizer).
-- Evidências: arquivos, logs, auditoria e custo.
-
-5. Governance & Security
-- Policies, consentimentos, destructive-guard approvals.
-- ACL matrix por papel e tenant.
-- Auditoria filtrável/exportável.
-
-## Design System Dark Premium
-- Paleta base: graphite/navy + accent elétrico (indigo/cyan).
-- Tokens: bg/base/surface/elevated, border subtle/strong, semantic success/warn/error/info.
-- Tipografia: Inter + JetBrains Mono (telemetria).
-- Motion: 120–180ms, easing suave, sem animação excessiva.
-- Components: cards densos, tables virtuais, timeline, command palette, split pane.
-
-## Roadmap
-### Sprint A (7-10 dias)
-- Estrutura Next.js + auth + layout shell dark premium.
-- Telas: Teams/Networks/Status integradas à API já existente.
-- RBAC básico e sessão admin.
-
-### Sprint B (10-14 dias)
-- Agent Fleet + Mission Console (stream de estado).
-- Timeline de tool-trace e artifacts.
-- Filtros e busca global.
-
-### Sprint C (10-14 dias)
-- Marketplace templates + provisionamento guiado.
-- Billing preview + SLA visual.
-- Auditoria completa e export.
-
-## Critérios de Aceite
-- P95 de navegação < 250ms em tela quente.
-- 100% de ações críticas com log/auditoria.
-- Fluxo completo: contratar template -> provisionar serviço -> executar missão -> evidenciar entrega.
-- UX consistente em dark premium em todas as telas.
-
-## Dependências Técnicas
-- Endpoints adicionais: /admin/agents, /admin/missions, /admin/events, /admin/templates.
-- SSE/WebSocket para stream operacional.
-- Persistência de eventos em store dedicado (trace store).
-
-## Riscos e Mitigação
-- Risco: virar dashboard bonito sem operação real.
-  Mitigação: priorizar Mission Console + ações acionáveis.
-- Risco: custo de telemetria.
-  Mitigação: sampling + retenção por tenant/política.
-- Risco: complexidade multi-tenant.
-  Mitigação: isolamento por workspace desde o início.