@zaip-ai/cli 1.0.6 → 1.0.7

package/templates/.zaip-aios/templates/config/agents/catalog.yaml

@@ -1,246 +0,0 @@
-schema_version: 1
-agents:
-  - id: agent-orchestrator
-    version: 1
-    purpose: Resolve the DAG and delegate only to capable least-privilege agents.
-    codex_name: zaip-agent-orchestrator
-    nickname_candidates: [zaip-agent-Atlas, zaip-agent-Conductor, zaip-agent-Nexus]
-    role: orchestrator
-    priority: 10
-    inherits: null
-    capabilities: [dag-orchestration, lifecycle-governance]
-    execution_eligibility: []
-    tools: [zaip-cli]
-    skills: [zaip-skill-execution]
-    write_scopes: []
-    permissions:
-      filesystem: { allow: [], deny: [workspace-write] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [zaip-cli], deny: [destructive] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [tool-use, structured-output]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 24, soft_input_tokens: 120000, max_repair_cycles: 2 }
-    contract:
-      inputs: [prepared-plan, active-work]
-      outputs: [delegation, execution-state]
-      evidence: [run-attribution]
-    review: { can_approve: false, cannot_review_roles: [orchestrator, builder] }
-    escalation: [agent-auditor]
-  - id: agent-builder
-    version: 1
-    purpose: Implement bounded TypeScript work inside declared scopes.
-    codex_name: zaip-agent-builder
-    nickname_candidates: [zaip-agent-Forge, zaip-agent-Maker, zaip-agent-Builder]
-    role: builder
-    priority: 20
-    inherits: null
-    capabilities: [typescript-delivery, test-authoring]
-    execution_eligibility: [delivery]
-    tools: [apply-patch, shell-read, test-runner]
-    skills: [zaip-skill-change]
-    write_scopes: [packages/*]
-    permissions:
-      filesystem: { allow: [declared-write-scope], deny: [outside-workspace] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [tests, typecheck, build], deny: [destructive, deploy] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [code, tool-use]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 40, soft_input_tokens: 180000, max_repair_cycles: 3 }
-    contract:
-      inputs: [task, requirements, context-pack]
-      outputs: [diff, test-results]
-      evidence: [acceptance-evidence]
-    review: { can_approve: false, cannot_review_roles: [builder] }
-    escalation: [agent-orchestrator]
-  - id: agent-task-executor
-    version: 1
-    purpose: Execute one bounded standalone Task end to end and return structured results to the orchestrator.
-    codex_name: zaip-agent-task-executor
-    nickname_candidates: [zaip-agent-Tasker, zaip-agent-Runner, zaip-agent-Executor]
-    role: task-executor
-    priority: 20
-    inherits: null
-    capabilities: [task-delivery, verification, evidence-production]
-    execution_eligibility: [delivery]
-    tools: [apply-patch, shell-read, test-runner]
-    skills: [zaip-skill-change]
-    write_scopes: [declared-write-scope]
-    permissions:
-      filesystem: { allow: [declared-write-scope], deny: [outside-workspace] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [tests, typecheck, build], deny: [destructive, deploy] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [tool-use, structured-output]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 32, soft_input_tokens: 160000, max_repair_cycles: 2 }
-    contract:
-      inputs: [task, requirements, context-pack]
-      outputs: [diff, verification, structured-outcome]
-      evidence: [acceptance-evidence]
-    review: { can_approve: false, cannot_review_roles: [task-executor, builder] }
-    escalation: [agent-orchestrator]
-  - id: agent-analyst
-    version: 1
-    purpose: Analyze interaction turns without manufacturing executable Tasks.
-    codex_name: zaip-agent-analyst
-    nickname_candidates: [zaip-agent-Analyst, zaip-agent-Insight, zaip-agent-Scout]
-    role: analyst
-    priority: 20
-    inherits: null
-    capabilities: [conversation-analysis, question-answering, repository-analysis]
-    execution_eligibility: [interaction]
-    tools: [shell-read]
-    skills: [zaip-skill-context]
-    write_scopes: []
-    permissions:
-      filesystem: { allow: [read-only], deny: [workspace-write] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [validation], deny: [mutation, deploy, destructive] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [reasoning, structured-output]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 16, soft_input_tokens: 80000, max_repair_cycles: 1 }
-    contract:
-      inputs: [interaction, context-pack]
-      outputs: [analysis, answer]
-      evidence: [run-attribution]
-    review: { can_approve: false, cannot_review_roles: [analyst] }
-    escalation: [agent-orchestrator]
-  - id: agent-finalizer
-    version: 1
-    purpose: Evaluate terminal Execution evidence as the mandatory final Sub-Run for interaction or delivery and return a restricted outcome.
-    codex_name: zaip-agent-finalizer
-    nickname_candidates: [zaip-agent-Finalizer, zaip-agent-Closer, zaip-agent-Settler]
-    role: execution-finalizer
-    priority: 30
-    inherits: null
-    capabilities: [lifecycle-finalization, gate-evaluation, structured-output]
-    execution_eligibility: []
-    tools: [zaip-cli, shell-read]
-    skills: [zaip-skill-execution]
-    write_scopes: []
-    permissions:
-      filesystem: { allow: [read-only], deny: [workspace-write] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [validation, zaip-cli-read], deny: [mutation, deploy, destructive] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [reasoning, structured-output]
-      preferred: [gpt-5.6-terra]
-      reasoning_effort: medium
-    budget: { soft_cycles: 8, soft_input_tokens: 40000, max_repair_cycles: 0 }
-    contract:
-      inputs: [task, descendant-results, gates, evidence]
-      outputs: [terminal-outcome, status-reason, evidence-refs]
-      evidence: [finalization-decision]
-    review: { can_approve: false, cannot_review_roles: [execution-finalizer] }
-    escalation: [agent-auditor]
-  - id: agent-reviewer
-    version: 1
-    purpose: Review changes independently and emit findings without mutating product files.
-    codex_name: zaip-agent-reviewer
-    nickname_candidates: [zaip-agent-Sentinel, zaip-agent-Lens, zaip-agent-Verifier]
-    role: reviewer
-    priority: 10
-    inherits: null
-    capabilities: [independent-review, architecture-review, security-review]
-    execution_eligibility: []
-    tools: [shell-read, test-runner]
-    skills: [zaip-skill-review]
-    write_scopes: []
-    permissions:
-      filesystem: { allow: [read-only], deny: [workspace-write] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [tests, validation], deny: [mutation, deploy] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [reasoning, tool-use]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 24, soft_input_tokens: 120000, max_repair_cycles: 0 }
-    contract:
-      inputs: [task, diff, requirements, evidence]
-      outputs: [findings, approval-state]
-      evidence: [review-report]
-    review: { can_approve: true, cannot_review_roles: [reviewer] }
-    escalation: [agent-auditor]
-  - id: agent-integrator
-    version: 1
-    purpose: Integrate reviewed worktrees and run combined gates.
-    codex_name: zaip-agent-integrator
-    nickname_candidates: [zaip-agent-Bridge, zaip-agent-Weaver, zaip-agent-Integrator]
-    role: integrator
-    priority: 10
-    inherits: null
-    capabilities: [git-integration, full-verification]
-    execution_eligibility: []
-    tools: [git, test-runner, zaip-cli]
-    skills: [zaip-skill-execution]
-    write_scopes: [integration-branch]
-    permissions:
-      filesystem: { allow: [reviewed-worktree], deny: [unreviewed-worktree] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [git-integrate, tests, build], deny: [force-push, deploy] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [tool-use, conflict-resolution]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 20, soft_input_tokens: 100000, max_repair_cycles: 1 }
-    contract:
-      inputs: [reviewed-diffs, dependency-state]
-      outputs: [integrated-diff, gate-results]
-      evidence: [integration-evidence]
-    review: { can_approve: false, cannot_review_roles: [integrator, builder] }
-    escalation: [agent-orchestrator]
-  - id: agent-auditor
-    version: 1
-    purpose: Reproduce evidence and issue the final independent audit.
-    codex_name: zaip-agent-auditor
-    nickname_candidates: [zaip-agent-Beacon, zaip-agent-Ledger, zaip-agent-Witness]
-    role: auditor
-    priority: 10
-    inherits: null
-    capabilities: [independent-review, release-audit, score-reproduction]
-    execution_eligibility: []
-    tools: [shell-read, test-runner, package-inspector]
-    skills: [zaip-skill-review]
-    write_scopes: []
-    permissions:
-      filesystem: { allow: [read-only], deny: [workspace-write] }
-      network: { allow: [], deny: [external] }
-      shell: { allow: [tests, validation, package-inspection], deny: [product-mutation, deploy] }
-      deployment: { allow: [], deny: [all] }
-    model:
-      required_capabilities: [reasoning, tool-use, structured-output]
-      preferred: [policy-selected]
-    budget: { soft_cycles: 32, soft_input_tokens: 180000, max_repair_cycles: 0 }
-    contract:
-      inputs: [rubric, evidence-manifest, release-candidate]
-      outputs: [audit-report, go-no-go]
-      evidence: [reproduced-score]
-    review: { can_approve: true, cannot_review_roles: [auditor] }
-    escalation: [agent-orchestrator]
-squads:
-  - id: squad-critical-delivery
-    version: 1
-    purpose: Deliver critical work with independent review and controlled integration.
-    members: [agent-orchestrator, agent-analyst, agent-task-executor, agent-finalizer, agent-builder, agent-reviewer, agent-integrator, agent-auditor]
-    max_parallelism: 5
-    delegation:
-      - { from: agent-orchestrator, to: agent-builder, capability: typescript-delivery }
-      - { from: agent-orchestrator, to: agent-task-executor, capability: task-delivery }
-      - { from: agent-orchestrator, to: agent-analyst, capability: conversation-analysis }
-      - { from: agent-orchestrator, to: agent-finalizer, capability: lifecycle-finalization }
-      - { from: agent-builder, to: agent-reviewer, capability: independent-review }
-      - { from: agent-reviewer, to: agent-integrator, capability: git-integration }
-      - { from: agent-integrator, to: agent-auditor, capability: release-audit }
-    review_policy:
-      independent: true
-      executor_roles: [analyst, builder, task-executor]
-      reviewer_roles: [reviewer, auditor]
-    escalation: [agent-auditor, agent-orchestrator]

package/templates/.zaip-aios/templates/requirements/autonomous-assurance.md

@@ -1,63 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-AUTONOMOUS-ASSURANCE
-area: autonomous-assurance
-title: Garantia adaptativa e execução autônoma
-status: active
-version: 1
-source_change: null
-source_release: "1.0.0"
----
-
-# Garantia adaptativa e execução autônoma
-
-## REQ-ASSURE-001 — Garantia proporcional para Tasks standalone
-
-Uma Task avulsa deve provar todos os Acceptance Criteria com profundidade proporcional ao risco, sem criar validação cerimonial.
-
-- `AC-ASSURE-001-01`: risco `lite` exige exatamente uma validação tipada aprovada e uma Evidence tipada aprovada; ambas podem cobrir vários ACs, mas a união precisa cobrir todos os ACs da Task.
-- `AC-ASSURE-001-02`: risco `standard` exige exatamente duas validações e duas Evidences no perfil base ou exatamente três de cada no perfil elevado; os artefatos usam modalidades distintas e incluem teste executado.
-- `AC-ASSURE-001-03`: `standard_depth: auto` seleciona o perfil elevado quando a Task possui mais de um write scope; `base` e `elevated` permitem configuração explícita.
-- `AC-ASSURE-001-04`: risco `critical` exige no mínimo três validações, Evidence dedicada por AC, teste, quality review independente, discriminação por mutação, rollback comprovado e artefatos frescos no commit final.
-- `AC-ASSURE-001-05`: uma Task sensível a segurança, migração, irreversibilidade ou múltiplos domínios não pode usar `lite` para contornar controles críticos.
-
-## REQ-ASSURE-002 — Garantia parental para SPEC e PRD
-
-Entregar uma SPEC ou PRD deve exigir prova no nível do produto planejado, além da soma dos testes das Tasks descendentes.
-
-- `AC-ASSURE-002-01`: SPEC e PRD exigem matriz completa de ACs, pelo menos três validações parentais e pelo menos três Evidences parentais aprovadas.
-- `AC-ASSURE-002-02`: SPEC exige integração, spec review e quality review; PRD exige cross-SPEC E2E, spec review e quality review.
-- `AC-ASSURE-002-03`: a revisão parental é feita por verificador diferente do autor e por Run diferente.
-- `AC-ASSURE-002-04`: todas as validações e Evidences parentais referenciam o commit final esperado; artefato de commit anterior não prova a entrega atual.
-- `AC-ASSURE-002-05`: PRD exige Evidence para cada outcome declarado, e descendants aprovados não substituem Evidence de integração ou outcome no nível parental.
-
-## REQ-AUTO-001 — Runtime autônomo opt-in e seguro
-
-O framework deve preservar execução manual como padrão e permitir autonomia somente por configuração explícita.
-
-- `AC-AUTO-001-01`: ausência de `execution` ou `execution.runtime: manual` materializa o trabalho sem invocar provider; `autonomous` exige provider, modelo, lease e paralelismo limitados.
-- `AC-AUTO-001-02`: o paralelismo efetivo é o menor limite entre projeto, plano, provider e squad; locks de DAG e write scopes continuam soberanos.
-- `AC-AUTO-001-03`: cada Task autônoma executa em Git worktree registrada, parte de raiz limpa, produz commit final, altera somente write scopes autorizados e aborta merge conflitante sem deixar merge parcial.
-- `AC-AUTO-001-04`: processos usam command allowlist, `shell: false`, diretório validado, ambiente mínimo allowlisted, limite de linha/stderr, timeout, cancelamento e budget de ferramentas/output.
-- `AC-AUTO-001-05`: checkpoints opacos de Codex ou Claude ficam somente em `.zaip-aios/local-data`, são retomáveis e removidos ao terminar; estado governado usa compare-and-swap.
-- `AC-AUTO-001-06`: Tasks `lite` têm uma tentativa; `standard` e `critical` têm no máximo três tentativas de desenvolvimento/reparo, sem loops ilimitados.
-- `AC-AUTO-001-07`: trabalho `critical` usa contexto fresco por Task e verificador independente; SPEC/PRD também exigem verificador independente mesmo quando suas Tasks são `lite`.
-
-## REQ-EVOL-001 — Delta, lições e maturidade derivada
-
-Aprendizado e alegações de maturidade devem ser derivados de fatos verificáveis do candidato atual.
-
-- `AC-EVOL-001-01`: rework recebe delta explícito de AC, write scopes, findings e baseline; contexto antigo não é copiado sem relevância observável.
-- `AC-EVOL-001-02`: lesson exige finding e locator verificável; opinião isolada não promove Rule, Requirement ou skill.
-- `AC-EVOL-001-03`: maturidade progride sequencialmente por `declared`, `implemented`, `locally_evidenced`, `cleanroom_validated`, `representative_validated` e `production_observed`.
-- `AC-EVOL-001-04`: Evidence de validação referencia o hash exato do candidato; cleanroom e estados posteriores exigem verificador independente, e produção exige Run observado.
-
-## REQ-QUALITY-001 — Gates de release e cobertura sem regressão
-
-O release deve falhar de modo discriminante quando código, distribuição ou evidência não atingirem o contrato publicado.
-
-- `AC-QUALITY-001-01`: release crítico inclui unit, E2E, arquitetura, CQRS, módulos, profile, segurança e testes negativos.
-- `AC-QUALITY-001-02`: cobertura usa baseline versionada e ratchet `max(piso, baseline anterior)` com pisos de 80% para lines/functions/statements e 75% para branches.
-- `AC-QUALITY-001-03`: baseline observada abaixo do piso pode ser registrada para transparência, mas não reduz o gate nem torna a release aprovada.
-- `AC-QUALITY-001-04`: release verifica paridade entre fonte canônica, template público e artefato distribuído, além de smoke/cleanroom sobre o candidato exato.
-

package/templates/.zaip-aios/templates/requirements/context-engine.md

@@ -1,44 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-CONTEXT-ENGINE
-area: context-engine
-title: Contexto mínimo, seguro e navegável
-status: active
-version: 8
-source_change: null
-source_release: "1.0.0"
----
-
-# Context engine
-
-## REQ-CONTEXT-001 — Seleção mínima
-
-Agentes devem construir contexto começando por configuração, Rule central, artefato ativo e Requirements referenciados, ampliando somente por relações explícitas.
-
-- `AC-CONTEXT-001-01`: o conjunto inicial não depende de artefatos globais legados.
-- `AC-CONTEXT-001-02`: eventos brutos de Run ficam fora do contexto padrão.
-- `AC-CONTEXT-001-03`: arquivos selecionados possuem motivo e budget declarado.
-- `AC-CONTEXT-001-04`: segredos, instruções não confiáveis e paths quebrados são bloqueados.
-- `AC-CONTEXT-001-05`: quando um artefato lifecycle é selecionado por ID, todos os Requirements e ACs declarados nele entram no conjunto obrigatório antes da busca lexical; o pack falha se o budget os omitir.
-
-## REQ-CONTEXT-002 — Ownership e namespaces de Rules
-
-Rules do framework e Rules específicas do projeto devem permanecer separadas, navegáveis e sem sobrescrita implícita.
-
-- `AC-CONTEXT-002-01`: Rules fornecidas pelo ZAIP existem somente em `.agents/rules/zaip/`, são registradas no `framework.lock.yaml` e nenhum arquivo de Rule existe diretamente em `.agents/rules/`.
-- `AC-CONTEXT-002-02`: Rules específicas existem somente em `.agents/rules/project/`, são preservadas por setup/upgrade e não entram no lock nem nos templates ou releases públicos.
-- `AC-CONTEXT-002-03`: setup, doctor, migração e context rejeitam ownership inválido e IDs duplicados; upgrades relocam Rules planas intactas e bloqueiam divergências antes de escrever.
-
-## REQ-CONTEXT-003 — Navegação escalável
-
-Coleções de trabalho devem ser navegadas por projeções locais descartáveis antes da leitura pontual do conteúdo Git-native.
-
-- `AC-CONTEXT-003-01`: listagens aceitam status, período, relação, limite e continuação estável, com limite padrão de 20 e máximo de 200 por página.
-- `AC-CONTEXT-003-02`: listagens de PRD, SPEC e Task omitem o PreparedPlan completo e retornam somente resumo de preparação.
-- `AC-CONTEXT-003-03`: corpos e eventos JSONL são lidos somente após selecionar IDs específicos.
-- `AC-CONTEXT-003-04`: operações comuns nunca varrem `.agents/records` ou `.agents/data`; rebuild completo exige comando e confirmação explícitos.
-- `AC-CONTEXT-003-05`: `.agents/projections/runtime` é local, ignorado pelo Git, incremental e reconstruível a partir dos records canônicos.
-- `AC-CONTEXT-003-06`: `.agents/data` e partições diárias anteriores são fallback legado somente leitura; novas escritas usam `.agents/records/<kind>/<ano>/<mês>`.
-- `AC-CONTEXT-003-07`: `context build` descobre paths e relações antes de ler conteúdo; inventário integral exige comando explícito.
-- `AC-CONTEXT-003-08`: uma consulta com ID lifecycle explícito não incorpora outros itens de `active-work`; fallback de path aceita somente o arquivo V3 canônico existente sem varrer records.
-- `AC-CONTEXT-003-09`: múltiplas entidades de uma mutação são anexadas em lote e atualizam snapshot uma única vez; reconciliação pontual recebe ID explícito e não executa full scan.

package/templates/.zaip-aios/templates/requirements/cost-observability.md

@@ -1,39 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-COST-OBSERVABILITY
-area: cost-observability
-title: Tokens, custos e cobertura
-status: active
-version: 9
-source_change: null
-source_release: "1.0.0"
----
-
-# Cost observability
-
-## REQ-COST-001 — Custo por nível e fase
-
-O sistema deve agregar tokens e custo por Task, SPEC e PRD, separados em Conversation, Planning e Execution, além de total e cobertura.
-
-- `AC-COST-001-01`: Task, SPEC e PRD expõem tokens e custo por fase e total.
-- `AC-COST-001-02`: valores indisponíveis permanecem nulos e não aparecem como zero.
-- `AC-COST-001-03`: dashboard, Kanban e Cost Monitor usam a mesma agregação sem dupla contagem.
-- `AC-COST-001-04`: métricas distinguem trabalho `new` e `rework`.
-- `AC-COST-001-05`: pergunta somente leitura possui Run com fase e entrypoint `conversation`, `task_id: null` e custo atribuível ao agregado de Conversation/projeto, sem Task artificial; uma tentativa explícita de executar usa Run de Execution mesmo quando não produz `changed_files`.
-
-## REQ-COST-002 — Consulta operacional escalável
-
-Runs devem poder ser localizadas e agregadas sem carregar seus eventos completos na resposta textual.
-
-- `AC-COST-002-01`: `zaip run list` oferece filtros por fase, entrypoint, tipo de trabalho e relações, com paginação compacta.
-- `AC-COST-002-02`: `zaip run aggregate` calcula tokens, custos e cobertura no escopo filtrado sem dupla contagem.
-- `AC-COST-002-03`: ausência de diff não reclassifica uma tentativa de execução como Conversation; o resultado e os arquivos alterados permanecem dimensões separadas.
-- `AC-COST-002-04`: cada métrica agregada expõe `known_sum`, quantidade desconhecida, completude e razão de cobertura, sem converter ausência em zero.
-- `AC-COST-002-05`: dashboard e CLI consultam snapshot incremental; JSONL canônico só é aberto para um Run explícito.
-- `AC-COST-002-06`: um único snapshot mantém contagens e somas diária, mensal e anual sem arquivos por período; records canônicos V3 são particionados fisicamente apenas por ano e mês, sem pasta diária.
-- `AC-COST-002-07`: decisões entram na mesma projeção incremental e preservam contagens por origem.
-- `AC-COST-002-08`: eventos de uso podem registrar timestamp da fonte e contagens sanitizadas de contexto, ferramentas, arquivos e trechos sem armazenar prompts.
-- `AC-COST-002-09`: Runs novos persistem um cabeçalho completo seguido de deltas compactos versionados; o parser mantém compatibilidade com JSONL V2 legado.
-- `AC-COST-002-10`: agregações expõem cobertura por Run para uso, tokens e custo com quantidades conhecidas, desconhecidas e razão; ausência de eventos nunca implica cobertura completa quando existem Runs no escopo.
-- `AC-COST-002-11`: snapshot expõe `source_latest_at` e `lag_ms` calculados a partir das entidades projetadas, sem usar horário de consulta como horário da fonte.
-- `AC-COST-002-12`: fechamento de Run sem medição persiste um evento de uso explicitamente indisponível; `context build --run` registra o tamanho estimado do pack sem armazenar prompts, e respostas resumidas omitem árvores internas disponíveis em `--view full`.

package/templates/.zaip-aios/templates/requirements/design-system.md

@@ -1,48 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-DESIGN-SYSTEM
-area: design-system
-title: Contrato visual e catálogo executável
-status: active
-version: 3
-source_change: null
-source_release: "1.0.0"
----
-
-# Design system
-
-## REQ-DESIGN-001 — Fonte visual canônica
-
-O repositório deve possuir uma fonte visual central, legível por humanos e estruturada para agentes.
-
-- `AC-DESIGN-001-01`: `.agents/design/DESIGN.md` contém frontmatter normativo com cores,
-  tipografia, espaçamento, raios e componentes, além de orientação de uso e acessibilidade.
-- `AC-DESIGN-001-02`: `.agents/design/tokens.json` preserva os tokens consumíveis por ferramentas e
-  um teste determinístico impede divergência nos grupos compartilhados com o frontmatter.
-- `AC-DESIGN-001-03`: mudanças globais de UI atualizam contrato, tokens, espécimes, stories e testes
-  na mesma Change; necessidades locais não criam tokens globais sem reutilização comprovada.
-
-## REQ-DESIGN-002 — Documentação visual
-
-O contrato deve ser demonstrado em componentes reais e navegável sem depender do produto.
-
-- `AC-DESIGN-002-01`: o catálogo oferece páginas distintas `design-system` e `components`, usando
-  os mesmos espécimes que alimentam o Storybook.
-- `AC-DESIGN-002-02`: o catálogo documenta ao menos cor, tipografia, espaçamento, botões, badges,
-  cards, métricas, formulários, tabela e estados vazio, desabilitado e erro.
-- `AC-DESIGN-002-03`: Storybook executa checks de acessibilidade e gera documentação estática; o
-  build do catálogo funciona em arquivo local por rotas hash e não depende do dashboard.
-
-## REQ-DESIGN-003 — Distribuição pelo CLI
-
-Instalações novas do ZAIP-AIOS devem receber o contrato e o catálogo visual completos.
-
-- `AC-DESIGN-003-01`: `.zaip-aios/design` contém fonte e builds estáticos alinhados com
-  `.agents/design`, cobertos por manifest e checksums.
-- `AC-DESIGN-003-02`: o template público aceita `design` como raiz V2, audita arquivos obrigatórios
-  e instala `.agents/design` com integridade validada.
-- `AC-DESIGN-003-03`: smoke de release confirma `DESIGN.md`, tokens, páginas e Storybook na pasta
-  `.agents` criada em um workspace vazio.
-- `AC-DESIGN-003-04`: `zaip-design.exe` abre o catálogo diretamente sem console, usa somente
-  loopback, incorpora o ícone canônico `.agents/config/src/icon_zaip.png` e reutiliza a mesma sessão
-  saudável por workspace em cliques repetidos.

package/templates/.zaip-aios/templates/requirements/execution-engine.md

@@ -1,60 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-EXECUTION-ENGINE
-area: execution-engine
-title: Preparação, materialização e DAG
-status: active
-version: 10
-source_change: null
-source_release: "1.0.0"
----
-
-# Execution engine
-
-## REQ-EXEC-001 — Preparação sem materialização
-
-`prepare` deve validar e persistir um plano idempotente com IDs pré-alocados e DAG global, sem criar trabalho executável.
-
-- `AC-EXEC-001-01`: preparar PRD/SPEC não cria Change, Task, Execution nem Run; preparar Task altera somente o draft já existente e não cria Change, Execution, Run de execução nem mutação no produto, sem apagar o Run de captura da mensagem.
-- `AC-EXEC-001-02`: repetir prepare de um plano já persistido reutiliza o mesmo hash e IDs.
-- `AC-EXEC-001-03`: referências e ciclos inválidos bloqueiam antes de persistir.
-- `AC-EXEC-001-04`: `zaip plan build` gera um PreparedPlan canônico a partir de um draft e `zaip plan validate` verifica o plano completo antes do prepare.
-
-## REQ-EXEC-002 — Execução idempotente
-
-`execute` deve materializar Changes, Tasks e Execution antes da primeira mutação, preservando snapshot da DAG para retomada e auditoria. A tentativa explícita já pertence à fase `execution`, independentemente de produzir diff.
-
-- `AC-EXEC-002-01`: repetir `execute` não duplica artefatos, e cada tentativa explicitamente iniciada possui Run atribuído.
-- `AC-EXEC-002-02`: cada Task executável possui dependências e Execution explícitas; Task encerrada como conversa read-only não materializa DAG sintética.
-- `AC-EXEC-002-03`: falha parcial pode ser retomada sem corromper o plano.
-- `AC-EXEC-002-04`: início da fase `execution` não implica mutação; `changed_files` e `result` registram separadamente se houve mudança real e qual foi o desfecho.
-- `AC-EXEC-002-05`: após materialização bem-sucedida, o PreparedPlan completo no artefato de origem é substituído por `plan_ref` com revisão, hash e Execution.
-
-## REQ-EXEC-003 — Paralelismo seguro
-
-Tasks prontas podem rodar em paralelo somente quando dependências e locks declarados permitirem.
-
-- `AC-EXEC-003-01`: a DAG é global por Execution e pode atravessar fronteiras de SPEC.
-- `AC-EXEC-003-02`: conflitos de arquivo, módulo, migration, ambiente e recurso impedem concorrência.
-- `AC-EXEC-003-03`: integração e gates finais são dependências explícitas.
-
-## REQ-EXEC-004 — Task manual em fases
-
-Task-first deve separar captura, preparação e execução para que mensagem persistida não seja confundida com trabalho materializado.
-
-- `AC-EXEC-004-01`: `task create` persiste somente uma Task `draft`, sem materializar Change ou Execution; um Run de captura pode ser criado e atribuído separadamente.
-- `AC-EXEC-004-02`: `task prepare` valida e persiste o PreparedPlan na Task, que passa a `planned` sem iniciar execução.
-- `AC-EXEC-004-03`: `task execute` materializa idempotentemente Change e Execution antes que a Task possa iniciar.
-- `AC-EXEC-004-04`: `task prepare TASK-ID` sem plano externo só aceita Task sem `depends_on`; Task com dependências exige PreparedPlan completo, contendo toda a DAG, gerado por `zaip plan build` e fornecido por `--plan`.
-
-## REQ-EXEC-005 — Budgets e verificação proporcional
-
-Execuções devem limitar repetição por checkpoints suaves e verificar somente o escopo necessário ao risco, preservando logs completos fora do prompt.
-
-- `AC-EXEC-005-01`: PreparedPlan pode declarar budget de ciclos, input, refresh de contexto e modo de verificação sem cancelar automaticamente trabalho válido.
-- `AC-EXEC-005-02`: Task-first gera para `lite` zero retries operacionais, zero ciclos de reparo, budget suave de 4 ciclos e 250.000 tokens de input; `standard` preserva 24 ciclos e 4.000.000 tokens; `critical` preserva checkpoint em 40 ciclos e 8.000.000 tokens.
-- `AC-EXEC-005-03`: `zaip verify --changed --risk` retorna síntese curta e grava output bruto somente em `.agents/projections/runtime/verify`.
-- `AC-EXEC-005-04`: risco `lite` executa exatamente uma validação scoped e registra exatamente uma Evidence cobrindo todos os ACs aplicáveis, sem exigir a bateria de lint, typecheck, teste, build, preview e screenshot; `standard` executa duas validações/evidências ou três no perfil elevado; `critical` executa o gate completo e os controles de garantia crítica.
-- `AC-EXEC-005-05`: a skill de execução exige refresh seletivo e checkpoint compacto ao atingir os budgets suaves.
-- `AC-EXEC-005-06`: quando um plano visível é útil, cada passo começa com `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, usa somente fases aplicáveis, contém no máximo 5 passos e combina ações triviais; tarefas simples podem omitir o plano.
-- `AC-EXEC-005-07`: checkpoints medem input não cacheado reportado pelo provider e usam tokens observáveis de contexto como fallback, preservando a origem da medição sem inventar valores ausentes.

package/templates/.zaip-aios/templates/requirements/kanban-dashboard.md

@@ -1,30 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-KANBAN-DASHBOARD
-area: kanban-dashboard
-title: Projeções operacionais e analíticas
-status: active
-version: 10
-source_change: null
-source_release: "1.0.0"
----
-
-# Kanban and dashboard
-
-## REQ-DASH-001 — Estado e visão macro
-
-Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir planejamento de execução.
-
-- `AC-DASH-001-01`: `Pronto para Executar` contém PRD/SPEC explicitamente promovido para `ready` e, excepcionalmente, Task avulsa preparada mas não executada (`planned`, `attempt_count: 0`, `started_at: null` e sem Execution iniciada). Task `draft` nunca aparece nessa coluna; Task iniciada ou tentada permanece em Execução, Verificação ou estado terminal e nunca retorna a `Pronto para Executar`.
-- `AC-DASH-001-02`: PRD agrega SPECs, Tasks, Executions e Runs descendentes.
-- `AC-DASH-001-03`: SPEC agrega Tasks, Executions e Runs descendentes.
-- `AC-DASH-001-04`: Task-first permanece analisável sem ancestrais sintéticos.
-- `AC-DASH-001-05`: projeções mostram cobertura de uso/preço e não alteram estado canônico silenciosamente.
-- `AC-DASH-001-06`: a UI consulta um snapshot coerente de operações e custos, atualiza-o silenciosamente em intervalo curto e exibe o timestamp real da fonte, não o horário local da consulta.
-- `AC-DASH-001-07`: Run de `conversation` sem Task permanece nas métricas e na rastreabilidade, mas nunca produz card no TaskBoard.
-- `AC-DASH-001-08`: PRD `draft` permanece em Definição e SPEC `draft` permanece em Planejamento durante criação, revisão, refinamento e `prepare`; somente promoção explícita para `ready` as coloca em Pronto para Executar.
-- `AC-DASH-001-09`: SPEC/PRD `active` permanece em Execução enquanto houver trabalho macro, inclusive entre Runs filhas e quando uma Task filha termina bloqueada ou falhada; somente gates parentais movem o macro para Verificação ou status final.
-- `AC-DASH-001-10`: invocação local ativa não revive Task terminal; `completed`, `blocked`, `failed` e `cancelled` prevalecem sobre heurísticas de atividade.
-- `AC-DASH-001-11`: o popup Reconciliar executa `run reconcile --open` somente após confirmação humana e aplica o resultado canônico; abrir o dashboard, atualizar automaticamente ou enviar novo turno não inicia reconciliação global.
-- `AC-DASH-001-12`: Operação e Monitor de Custos apresentam os filtros “Chamadas do agente orquestrador” (`parent_run_id: null`) e “Chamadas de subagentes” (`parent_run_id` preenchido), exibindo propósito, pai, `zaip-agent-*`, modelo/effort planejados, configuração efetiva, quantidade de Calls conhecida, tokens e custo; Calls não possuem tela própria.
-- `AC-DASH-001-13`: a tabela de Executions apresenta contagens sem dupla contagem de Runs, Sub-Runs, finalizadores, Tasks finalizadas e LLM Calls; ausência de captura completa de Calls é sinalizada como parcial, nunca convertida em zero conhecido.

package/templates/.zaip-aios/templates/requirements/model-orchestration.md

@@ -1,58 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-MODEL-ORCHESTRATION
-area: model-orchestration
-title: Seleção automática e observável de modelo e effort
-status: active
-version: 5
-source_change: null
-source_release: "1.0.0"
----
-
-# Orquestração de modelos
-
-## REQ-MODEL-001 — Configuração automática opt-in
-
-O projeto deve poder habilitar seleção automática de modelo, effort e velocidade sem alterar o comportamento dos modos existentes.
-
-- `AC-MODEL-001-01`: o schema aceita `model_orchestration.mode: auto` além de `manual` e `off`; ausência do bloco e os dois modos existentes mantêm o comportamento anterior em testes de compatibilidade.
-- `AC-MODEL-001-02`: o modo `auto` exige `default_model: gpt-5.6-terra`, `default_effort: medium`, `default_velocity: standard`, allowlist contendo exatamente `gpt-5.6-luna`, `gpt-5.6-terra` e `gpt-5.6-sol`, efforts automáticos restritos a `low|medium|high|xhigh` e teto automático `xhigh`.
-- `AC-MODEL-001-03`: setup, migration, adapters e templates preservam `manual` como default de projetos novos e existentes; `auto` só é ativado por configuração explícita do projeto e passa em `zaip doctor`.
-- `AC-MODEL-001-04`: o modo `auto` exige `automatic_sources: [spec, prd]`; `task` não é uma origem automática válida, preservando a seleção manual do host para Tasks avulsas.
-
-## REQ-MODEL-002 — Seleção governada por Agent Run
-
-Cada Run ou Sub-Run deve resolver uma configuração única a partir do agente do catálogo, dos metadados estruturados da Task e da fase, sem depender de instrução em linguagem natural.
-
-- `AC-MODEL-002-01`: o resolvedor aplica a precedência `override explícito da Execution -> override explícito da Task -> política automática -> defaults do projeto`, retornando modelo, effort, velocidade, origem, versão da política e ao menos um motivo enumerado.
-- `AC-MODEL-002-02`: a política considera fase, papel do agente, complexidade, risco, transversalidade, ambiguidade, rework e restrições de capacidade; risco governa assurance e não força sozinho modelo ou effort superior.
-- `AC-MODEL-002-03`: a política inicial usa Luna para trabalho simples, delimitado ou de alto volume, Terra como baseline de implementação e teste e Sol para planejamento, revisão ou reparo ambíguo/transversal; `xhigh` só é elegível para planejamento, replanejamento, auditoria ou rework estrutural delimitado quando as quatro condições e ao menos dois gatilhos observáveis do guia forem satisfeitos.
-- `AC-MODEL-002-04`: `ultra`, `max`, effort desconhecido e modelo fora da allowlist são rejeitados antes da chamada com erro tipado, sem fallback silencioso; `xhigh` é aceito quando vier de override explícito válido ou da política elegível.
-- `AC-MODEL-002-05`: a Run raiz usa a identidade visível `zaip-agent-orchestrator`; cada Execution delega por capacidade a ao menos um executor do catálogo, conversas podem usar `zaip-agent-analyst`, e o último Sub-Run usa `zaip-agent-finalizer`.
-
-## REQ-MODEL-003 — Configuração imutável por Agent Run
-
-A configuração selecionada deve ser aplicada quando o Agent Run começa e permanecer imutável até seu término.
-
-- `AC-MODEL-003-01`: o cabeçalho do Agent Run registra agente, papel, modelo e reasoning effort planejados; quando o host não expõe um campo, ele permanece `null` ou `unknown`, nunca inferido como observação.
-- `AC-MODEL-003-02`: toda Call interna herda exatamente o modelo, effort e velocidade `standard` do Agent Run; o ledger rejeita uma configuração solicitada divergente dentro da mesma Run.
-- `AC-MODEL-003-03`: mudança deliberada de modelo, effort, agente ou fase material exige encerrar a Run corrente e abrir outra Run relacionada; retry técnico e retomada por checkpoint preservam a configuração original.
-- `AC-MODEL-003-04`: fallback ou reroteamento feito pelo host/provider não altera a configuração planejada; modelo/effort efetivos e divergência requested/effective são observações internas da Run quando disponíveis.
-- `AC-MODEL-003-05`: o coordenador injeta a política automática somente em Executions cuja origem esteja em `automatic_sources`; Runs de conversa e Tasks avulsas preservam a seleção manual do host e registram `unknown`/`null` quando ela não for observável.
-
-## REQ-MODEL-004 — Telemetria agregada por Agent Run
-
-O Agent Run é a unidade visível e auditável. Calls permanecem eventos internos usados para consolidar consumo, retries e configuração efetiva sem criar um lifecycle ou uma visão paralela.
-
-- `AC-MODEL-004-01`: quando o host expõe Calls, cada `invocation_id` possui no máximo uma seleção e um terminal idempotentes dentro do Run; todos reutilizam a decisão imutável do Agent Run e não armazenam prompt, segredo ou reasoning privado.
-- `AC-MODEL-004-02`: contagem de Calls, terminais, falhas, cancelamentos, tokens, custo, latência e configuração efetiva são agregados no Agent Run; ausência de captura permanece `null`, nunca zero ou inferida.
-- `AC-MODEL-004-03`: projeções, CLI e Cost Monitor mostram separadamente Run e Sub-Run por `parent_run_id`, propósito, identidade canônica `zaip-agent-*`, modelo/effort planejados, configuração efetiva observada, Calls conhecidas, tokens e custo por chamada de agente.
-- `AC-MODEL-004-04`: o dashboard não cria `CallProjection` nem uma aba de Calls; filtros e agregações existentes de Run, Task, SPEC, PRD, agente e modelo continuam sem dupla contagem.
-
-## REQ-MODEL-005 — Rollout medido e documentação coerente
-
-O modo automático deve ser ativado com evals, rollback e documentação que distingam contrato, estado implementado e limitações do host.
-
-- `AC-MODEL-005-01`: uma suíte determinística cobre ao menos seleção lite, baseline Terra, planejamento Sol, risco crítico mecânico, rework estrutural, `xhigh` elegível, `xhigh` inelegível, `ultra` rejeitado, velocidade diferente de `standard` rejeitada, override explícito e capacidade incompatível.
-- `AC-MODEL-005-02`: o rollout compara sucesso por Acceptance Criteria, aprovação na primeira revisão, repair cycles, tokens, latência e custo por Task aprovada; regressão de qualidade bloqueia a ativação ampla mesmo quando houver economia.
-- `AC-MODEL-005-03`: o guia, adapters, templates e configuração distribuída descrevem os mesmos defaults e permitem rollback para `manual` sem migração destrutiva de Runs já registrados.

package/templates/.zaip-aios/templates/requirements/public-distribution.md

@@ -1,40 +0,0 @@
----
-schema_version: 2
-id: REQUIREMENTS-PUBLIC-DISTRIBUTION
-area: public-distribution
-title: Distribuição pública e ativação
-status: proposed
-version: 2
-source_change: null
-source_release: "1.0.0"
----
-
-# Distribuição pública e ativação
-
-## REQ-DIST-001 — Runtime público executável
-
-O pacote público deve entregar, verificar e reparar o mesmo runtime de lifecycle referenciado pelo guidance instalado, sem depender do checkout mantenedor nem criar autoridade implícita.
-
-- `AC-DIST-001-01`: o `.tgz` exato de `@zaip-ai/cli` e `create-zaip-aios` instala `.zaip-aios/bin/zaip.mjs` e seus metadados de supply chain; no workspace vazio, `doctor`, `status`, `conversation start`, `disable` e `enable` terminam com sucesso.
-- `AC-DIST-001-02`: `zaip.enabled` é a única chave gravada; a matriz canônica/legada `true|false|ausente` preserva compatibilidade, normaliza a próxima escrita e rejeita valores contraditórios antes de mutar o workspace.
-- `AC-DIST-001-03`: `template:sync` e `template:audit` cobrem `.agents` e `.zaip-aios`, recalculam o digest agregado, rejeitam path traversal, symlink, duplicata, descendente de arquivo allowlisted e checksum divergente.
-- `AC-DIST-001-04`: geração de runtime e manifest ocorre como uma única substituição recuperável; falhas injetadas antes e depois da troca preservam byte a byte o runtime e o manifest anteriores, e reinstalação autorizada restaura arquivo ausente.
-
-## REQ-DIST-002 — Qualificação e paridade de release
-
-A distribuição pública só pode ser candidata quando fonte canônica, template, artefato, documentação e smoke do pacote exato descrevem o mesmo contrato observável.
-
-- `AC-DIST-002-01`: o gate de release executa sync reproduzível, audit, typecheck, testes, pack, doctor, smoke e rollback sobre o candidato exato, sem substituir falha por evidência de outro checkout.
-- `AC-DIST-002-02`: o manifest registra versão, hashes e conteúdo efetivo de `.agents` e `.zaip-aios`; qualquer divergência entre fonte, template e pacote bloqueia a candidatura.
-- `AC-DIST-002-03`: README, guias de instalação, versão pública e comandos documentados permanecem alinhados ao pacote qualificado e não prometem capability ausente.
-
-## REQ-DIST-003 — Configuração global portátil do Codex
-
-O CLI público deve descobrir o diretório inicial do usuário em execução e instalar uma configuração global do Codex que não contenha paths ou identidades locais fixas.
-
-- `AC-DIST-003-01`: em uma instalação limpa, o CLI substitui `config.toml` em `<home-do-usuário>/.codex/` por conteúdo idêntico ao arquivo portátil instalado no projeto, sem referência a um nome de usuário ou path absoluto do ambiente de build.
-- `AC-DIST-003-02`: se a escrita global falhar, o CLI conclui a instalação do projeto sem ocultar a falha e informa o destino exato, a origem `<projeto>/.codex/config.toml` e os passos de cópia manual.
-
-## Verificação
-
-Validar por testes unitários de matriz e paths, falhas injetadas de transação, cleanroom do template, pack smoke do `.tgz` exato e auditoria independente. A promoção para `active` exige Evidence tipada no commit final e ausência de regressão conhecida nos gates públicos.