@zaip-ai/cli 1.0.4 → 1.0.7

package/templates/.agents/requirements/software-architecture.md

@@ -6,7 +6,7 @@ title: Layout modular e limites de código-fonte
 status: active
 version: 5
 source_change: null
-source_release: "1.0.4"
+source_release: "1.0.7"
 ---
 
 # Software architecture
@@ -34,7 +34,7 @@ O dashboard é uma ferramenta operacional local do ZAIP, não o frontend nem o s
 
 - `AC-ARCH-003-01`: o layout é `.agents/dashboard/apps/frontend`, `modules/{operations,cost-monitor,traceability}`, `packages` e `tests/e2e`, com o executável diretamente em `.agents/dashboard`; `apps/backend` não existe no dashboard.
 - `AC-ARCH-003-02`: o frontend renderiza e navega; `packages/local-runtime` hospeda o servidor loopback e projeta dados; regras de operações, custos e rastreabilidade pertencem aos módulos nomeados.
-- `AC-ARCH-003-03`: o dashboard lê coleções e contagens somente de `.agents/projections/runtime`; detalhes fazem leitura pontual de `.agents/records` por ID e nenhuma query edita artefatos.
+- `AC-ARCH-003-03`: o dashboard lê coleções lifecycle dos artefatos canônicos Git-native e invocações dos manifests `InvocationSummary`; detalhes fazem leitura pontual de `.agents/records` por ID, nenhuma query edita artefatos e não há cache ou projeção runtime como fonte de verdade.
 - `AC-ARCH-003-04`: site público e aplicações do produto não importam código interno do dashboard; a distribuição e o CLI projetam o dashboard executável em `.agents/dashboard` sem criar superfícies de produto.
 
 ## REQ-ARCH-004 — Tamanho de arquivo-fonte
@@ -43,7 +43,7 @@ Arquivos-fonte devem permanecer pequenos o suficiente para revisão humana e con
 
 - `AC-ARCH-004-01`: arquivos com 401 a 800 linhas físicas geram warning e não falham o gate isoladamente.
 - `AC-ARCH-004-02`: arquivos com 801 ou mais linhas geram erro.
-- `AC-ARCH-004-03`: código gerado, `dist`, vendor, `node_modules`, `.agents/records`, `.agents/data`, projeções locais e lockfiles não entram na medição.
+- `AC-ARCH-004-03`: código gerado, `dist`, vendor, `node_modules`, `.agents/records`, `.agents/data`, artefatos manifest-first gerados e lockfiles não entram na medição.
 - `AC-ARCH-004-04`: exceção temporária só cobre arquivo legado preexistente fora do dashboard, declara `max_lines`, `reason`, `owner` e `expires_on`, nunca permite crescimento e deixa de valer ao expirar.
 
 ## REQ-ARCH-005 — Validação de módulos, profile e planejamento técnico
@@ -51,7 +51,7 @@ Arquivos-fonte devem permanecer pequenos o suficiente para revisão humana e con
 Fronteiras modulares, o profile de stack e sua aplicação ao planejamento devem possuir contratos independentes e reproduzíveis.
 
 - `AC-ARCH-005-01`: `zaip modules validate` verifica o layout e as dependências públicas entre apps, modules e packages.
-- `AC-ARCH-005-02`: `zaip profile validate` valida o profile padrão; `--path PATH` permite validar outro contrato e suas fixtures declaradas.
+- `AC-ARCH-005-02`: `zaip profile validate` valida a definição de stack canônica em `.agents/config/project.yaml`, sem fixtures de exemplo no projeto consumidor.
 - `AC-ARCH-005-03`: `zaip architecture validate` e `zaip cqrs validate` permanecem gates distintos, aplicados conforme o escopo da mudança.
 - `AC-ARCH-005-04`: o schema canônico de PRD contém somente problema, públicos, outcomes, restrições e não objetivos; a skill de PRD proíbe escolhas de linguagem, framework, banco ou fornecedor, salvo quando registradas como restrição externa de negócio.
 - `AC-ARCH-005-05`: uma SPEC só pode ser preparada ou ativada quando registra `stack_profile` e `stack_overrides` iguais a `.agents/config/project.yaml`, `stack_description` contendo os componentes e versões exatas, e `stack_components` com ao menos uma linguagem e fontes workspace-relative existentes.

package/templates/.agents/requirements/strategic-improvements.md

@@ -0,0 +1,24 @@
+---
+schema_version: 2
+id: REQUIREMENTS-STRATEGIC-IMPROVEMENTS
+area: strategic-improvements
+title: Melhorias estratégicas de custo, qualidade e resiliência
+status: active
+version: 1
+source_change: null
+source_release: "1.0.7"
+---
+
+# Melhorias estratégicas de custo, qualidade e resiliência
+
+## REQ-STRATEGIC-IMPROVEMENTS-001 — Entrega mensurável e auditável por Task
+
+As capacidades estratégicas devem produzir contratos e resultados determinísticos em testes locais. Métricas de produção, percentuais de economia e qualidade observada só podem ser declarados quando houver dados observados e rastreáveis.
+
+- `AC-STRATEGIC-001`: o gate semântico rejeita uma claim sem Evidence tipada que cubra o AC declarado; um replay independente da mesma entrada preserva a decisão e não duplica a Evidence nem o resultado terminal.
+- `AC-STRATEGIC-002`: a medição por Task aceita somente um baseline equivalente identificado, registra modelo, effort, orçamento de contexto/cache, tentativas e rework, e só compara custo quando ambos os lados possuem uso observado; ausência de qualquer campo produz estado indisponível, não economia inferida. O quality floor bloqueia resultado abaixo do limiar declarado.
+- `AC-STRATEGIC-003`: o percurso Codex-first valida que a autenticação é provida pelo host e que nenhum VPS ou `API_KEY` é requisito para esse percurso; configurações que exigem provider externo, credencial ausente ou operação remota declaram a exceção e falham de modo discriminante.
+- `AC-STRATEGIC-004`: a suite de cenários de referência contém ao menos um fluxo multiagente com delegação, dependência e resultado terminal; também cobre conflito de write scope ou agente inelegível e verifica que não há execução paralela inválida.
+- `AC-STRATEGIC-005`: cada Task elegível para medição de qualidade vincula resultado, Evidences aceitas, validações executadas e rework a uma projeção/KPI; campos ausentes permanecem indisponíveis e um rework não é agregado como sucesso da tentativa anterior.
+- `AC-STRATEGIC-006`: a execução concorrente usa lease com proprietário e vencimento verificáveis; recuperação após expiração, crash ou retry preserva a configuração da tentativa, impede dois proprietários ativos e é idempotente para o mesmo evento.
+- `AC-STRATEGIC-007`: uma regressão de records e telemetria canônicos confirma que writer, manifesto e projeção mantêm a correlação de Task/Execution/Run, deduplicam a mesma invocação e preservam indisponibilidade explícita para uso, custo ou duração não observados.

package/templates/.agents/requirements/work-lifecycle.md

@@ -4,30 +4,31 @@ id: REQUIREMENTS-WORK-LIFECYCLE
 area: work-lifecycle
 title: Ciclo de vida do trabalho
 status: active
-version: 19
+version: 23
 source_change: null
-source_release: "1.0.4"
+source_release: "1.0.7"
 ---
 
 # Work lifecycle
 
-> `AC-WORK-001-12`: criar ou refinar PRD, Requirement ou SPEC em `draft` é trabalho de definição: cria somente Execution `interaction` e Run de conversa, vinculáveis ao artefato por `creation_run_id`, sem Task, Change ou Execution `delivery` artificial. A Execution `delivery` é reservada pelo PreparedPlan e só é materializada/iniciada pelo comando explícito `execute`.
+> `AC-WORK-001-09`: criar ou refinar PRD, Requirement ou SPEC em `draft` é trabalho de definição. Criação explícita persiste o macro e seu plano técnico com telemetria; `ready` materializa a DAG sem executá-la; `execute` inicia o menor grão nomeado.
 
 ## REQ-WORK-001 — Entradas opcionais e captura de chat
 
 O ZAIP-AIOS deve aceitar trabalho iniciado por Task, SPEC ou PRD, mantendo PRD e SPEC opcionais e capturando todo turno em uma Execution sem transformar conversa em Task executável.
 
 - `AC-WORK-001-01`: Task-first pode existir sem PRD ou SPEC sintética.
-- `AC-WORK-001-02`: pergunta, explicação, status ou análise pontual somente leitura cria exatamente uma Execution `interaction`, idempotente quando o cliente fornece `client_turn_id` observável; sem esse identificador, cada captura recebe identidade local única e não promete idempotência entre invocações. A Run raiz usa `zaip-agent-orchestrator`, entrypoint `conversation` e `task_id: null`, sem Task ou Change artificial; registros legados com `execution_id: null` permanecem legíveis sem backfill.
+- `AC-WORK-001-02`: pergunta, explicação, status ou análise pontual somente leitura cria exatamente uma Execution `interaction`, idempotente quando o cliente fornece `client_turn_id` observável; sem esse identificador, cada captura recebe identidade local única e não promete idempotência entre invocações. A Run raiz usa `zaip-agent-orchestrator`, entrypoint `conversation` e `task_id: null`, sem Task ou Change artificial; após a resposta entregue, a interaction read-only sem descendentes termina como `completed` sem Sub-Run executor ou finalizador; interaction com trabalho delegado segue a barreira de finalização; registros legados com `execution_id: null` permanecem legíveis sem backfill.
 - `AC-WORK-001-03`: PRD, SPEC e Task-first permanecem distinguíveis em status, métricas e custos.
 - `AC-WORK-001-04`: PRD pode permanecer em draft sem SPEC, mas prepare, execute e deliver exigem ao menos uma SPEC filha e nenhuma Change direta fora de SPEC.
 - `AC-WORK-001-05`: deliver de PRD avalia somente as SPECs selecionadas em seu PreparedPlan; SPECs filhas não selecionadas podem permanecer em draft sem bloquear a entrega.
 - `AC-WORK-001-06`: `conversation start|finish` coordena Executions e Runs idempotentes quando `client_turn_id` é observável; quando indisponível, cada captura usa uma identidade local única. O fluxo permite término sem Task e atualiza a projeção sem exigir comandos manuais intermediários.
 - `AC-WORK-001-07`: pergunta, análise pontual e classificação ausente ou de baixa confiança usam fallback `conversation`, nunca criam Task e preservam telemetria do Run.
 - `AC-WORK-001-08`: continuação, resposta a pergunta do agente, aprovação, refinamento e rework reutilizam o alvo explícito ou o último foco válido da mesma thread; não consultam trabalho global e não criam Task adicional salvo pedido explícito.
-- `AC-WORK-001-09`: edição persistente do repositório, novo resultado independente ou pedido explícito de nova Task cria exatamente uma Task `draft`, sua Change `draft`, uma Execution `delivery` e uma Run raiz `zaip-agent-orchestrator` antes de qualquer mutação; prepare e execute promovem e reutilizam esses mesmos agregados. Cada `client_turn_id` observável possui claim exclusivo e resolve global e atomicamente para exatamente uma Execution `interaction|delivery`; sem ID observável, cada captura recebe identidade local única. Reuso exige kind e origem compatíveis; kind e elegibilidade declarada no catálogo são persistidos, ao menos uma Sub-Run executora elegível é exigida e o encerramento ocorre somente após `zaip-agent-finalizer` ser o último filho concluído; `agent-task-finalizer` é aceito apenas na leitura histórica; write scopes ausentes permanecem vazios e título e objetivo são sínteses semânticas fornecidas pela IA.
+- `AC-WORK-001-09`: edição persistente do repositório, novo resultado independente ou pedido explícito de nova Task cria exatamente uma Task `draft`, sua Change `draft`, uma Execution `delivery` e uma Run raiz `zaip-agent-orchestrator` antes de qualquer mutação; prepare e execute promovem e reutilizam esses mesmos agregados. Draft de PRD/SPEC é exceção de definição: “pensar”, “explorar” ou “ajudar com” permanece Conversation, enquanto “criar” valida o pacote antes da escrita e persiste PRD/SPEC, SPECs técnicas selecionadas e PreparedPlan com criação exclusiva por arquivo e rollback compensatório em caso de falha, sem prometer transação atômica multiarquivo contra interrupção abrupta e sem Task, Change ou Execution `delivery`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo são agregados somente quando observados ou reconciliados e permanecem indisponíveis quando ausentes. A descoberta usa até cinco perguntas críticas por turno e no máximo três turnos; depois assume e registra decisões delegáveis, sem presumir autoridade externa/destrutiva, credencial, obrigação legal ou risco de segurança. Uma nova SPEC só existe para capacidade paralela e independentemente verificável, com contrato estável, sem dependência ou write scope conflitante entre SPECs; dependências ficam na DAG interna. `ready`, inclusive aliases de finalizar/concluir em `draft|ready`, lapida e materializa Changes, Tasks e Execution como `planned`, sem iniciar; toda Task `planned` nunca iniciada ou tentada aparece em Pronto para Executar, avulsa ou vinculada a SPEC. `execute` inicia o menor grão nomeado. Finalizar implementação em `active|verifying` continua Tasks e gates. `desenvolver|melhorar|aprimorar` planeja/refina/retrabalha; PRD cancelado permanece imutável e gera sucessor `draft`, tag `rework` e `rework_of_prd_id`. Cada `client_turn_id` observável possui claim exclusivo e resolve global e atomicamente para exatamente uma Execution `interaction|delivery`; sem ID observável, cada captura recebe identidade local única. Reuso exige kind e origem compatíveis; kind e elegibilidade declarada no catálogo são persistidos. Em `delivery` ou `interaction` com descendente delegado, ao menos uma Sub-Run executora elegível é exigida e o encerramento ocorre somente após `zaip-agent-finalizer` ser o último filho concluído; `interaction` read-only sem descendentes conclui após a resposta sem filhos. `agent-task-finalizer` é aceito apenas na leitura histórica; write scopes ausentes permanecem vazios e título e objetivo são sínteses semânticas fornecidas pela IA.
 - `AC-WORK-001-10`: a decisão de intake registra intenção, origem, confiança e motivos compactos no Run sem armazenar prompt, segredo ou raciocínio interno.
-- `AC-WORK-001-11`: qualquer mutação persistente intencional no repositório ou no PC exige Task materializada e Run raiz de orquestração antes da primeira escrita. São isentos apenas publicação Git/deploy sem mudança de produto, records/projections/telemetria ZAIP, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis; editar código, documentação ou configuração ZAIP nunca é isento.
+- `AC-WORK-001-11`: salvo a exceção de definição de PRD/SPEC `draft` descrita em `AC-WORK-001-09`, qualquer mutação persistente intencional no repositório ou no PC exige Task materializada e Run raiz de orquestração antes da primeira escrita. Também são isentos apenas publicação Git/deploy sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis; editar código, documentação ou configuração ZAIP nunca é isento.
+- Para pedido explícito no turno de `deploy|push|publicar|publicação GitHub`, a publicação Git-only inclui a reconciliação segura da branch/worktree selecionados e commits funcionais do diff pendente pretendido/evidenciado. Essa exceção não cria nem fabrica IDs de PRD/SPEC/Task: quando inexistentes, o commit é funcional sem trailers `ZAIP-*`; quando existentes, a linhagem real é preservada. A exceção exige pathspecs explícitos e verificação, e nunca permite `git add -A`, force, segredos ou worktrees alheios.
 
 ## REQ-WORK-002 — Change verificável
 
@@ -64,19 +65,28 @@ PRDs e SPECs devem permanecer no estágio em que foram criados até uma solicita
 - `AC-WORK-005-01`: `prd create`, `spec create`, refinamento e `prepare` preservam `status: draft`; `prepare` apenas valida e persiste o PreparedPlan.
 - `AC-WORK-005-02`: somente pedido explícito para mover a “Pronto para Executar” autoriza `prd ready` ou `spec ready`; revisão, aprovação de conteúdo, criação, refinamento ou planejamento não contam como autorização.
 - `AC-WORK-005-03`: pedido explícito para executar autoriza preparar, quando necessário, e executar sem exigir uma solicitação intermediária de movimento para `ready`.
-- `AC-WORK-005-04`: `prd ready` promove apenas o PRD e as SPECs selecionadas no PreparedPlan; SPECs não selecionadas e trabalho não relacionado permanecem inalterados.
+- `AC-WORK-005-04`: `prd ready` promove apenas o PRD e as SPECs selecionadas no PreparedPlan, e `spec ready` promove somente sua SPEC; ambos, na mesma operação idempotente, materializam a DAG selecionada como Execution, Changes e Tasks `planned`, sem ativá-las. SPECs não selecionadas e trabalho não relacionado permanecem inalterados.
 - `AC-WORK-005-05`: testes de repositório e CLI comprovam que `prepare` preserva `draft`, `ready` falha sem PreparedPlan e os caminhos explícitos `ready` e `execute` realizam somente suas transições autorizadas.
 
 ## REQ-WORK-006 — Convergência terminal entre Run e trabalho
 
-Cada Execution `interaction|delivery` possui uma Run raiz de orquestração, ao menos um Sub-Run executor elegível pelas capacidades do catálogo e exatamente um Sub-Run finalizador, enquanto SPEC e PRD agregam suas Tasks e permanecem abertos até seus gates parentais.
+Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-only sem descendentes conclui depois da resposta entregue sem invocações delegadas; interaction com descendente delegado e `delivery` possuem ao menos uma Invocação Delegada executora elegível pelas capacidades do catálogo e exatamente uma Invocação Delegada finalizadora, enquanto SPEC e PRD agregam suas Tasks e permanecem abertos até seus gates parentais.
 
 - `AC-WORK-006-01`: uma Run raiz de `orchestration` governa exatamente uma tentativa de Task e permanece aberta enquanto seus Sub-Runs executam; antes de a Run terminar, a Task deve estar `completed`, `blocked`, `failed` ou `cancelled`. `executing` e `verifying` nunca são estados válidos no fim da tentativa.
-- `AC-WORK-006-02`: um registro `RUN-*` sem `parent_run_id` é uma Run; com `parent_run_id`, é um Sub-Run. Novas gravações usam somente `run_role: intake|orchestrator|subagent`; valores históricos `owner|contributor` permanecem legíveis e são normalizados na borda. Ambos usam o mesmo ledger e status técnico, sem entidade duplicada. A Run raiz não pode terminar enquanto qualquer descendente estiver ativo.
-- `AC-WORK-006-03`: o último filho de qualquer Execution é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que um executor elegível e os demais descendentes terminam, impede novos filhos e retorna uma decisão restrita; reviewer, auditor e integrator são permitidos antes da barreira. A CLI aplica deterministicamente o status terminal.
+- `AC-WORK-006-02`: `RUN-*` continua a chave física compatível do ledger, mas representa uma Invocação de Agente. `parent_run_id: null` e `invocation_kind: orchestrator` identificam exclusivamente a Invocação do Orquestrador; toda Invocação Delegada exige pai, raiz e profundidade positivos. Valores históricos permanecem legíveis e são normalizados na borda. A invocação raiz não pode terminar enquanto qualquer descendente estiver ativo.
+- `AC-WORK-006-03`: em `delivery` ou interaction com descendente delegado, o último filho é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que um executor elegível e os demais descendentes terminam, impede novos filhos e retorna uma decisão restrita; reviewer, auditor e integrator são permitidos antes da barreira. Uma `interaction` read-only sem descendentes não inicia filhos e a CLI a conclui deterministicamente após a resposta entregue.
 - `AC-WORK-006-04`: uma Run raiz de SPEC/PRD pode terminar sem terminalizar o macro. O pai passa a `active` quando uma Task filha inicia, permanece em Execução durante intervalos e só entra em Verificação depois de todas as Tasks concluírem; delivery exige gates parentais próprios.
 - `AC-WORK-006-05`: status técnico de Run/Sub-Run (`completed`, `failed`, `cancelled`) é independente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`); a orquestração pode concluir tecnicamente e bloquear a Task por falha de gate.
 - `AC-WORK-006-06`: continuação não preserva Task em `executing` ou `verifying`, e fechamento da tentativa não pode ser adiado. Retomada de `blocked` usa `resume`; `failed` usa `rework` na mesma Task e incrementa a tentativa; `completed` e `cancelled` são imutáveis.
 - `AC-WORK-006-07`: `run reconcile --open` executa somente após confirmação humana no popup Reconciliar, nunca ao abrir o dashboard, em cada turno ou por intervalo. Ele fecha apenas o `task_complete` local exato ou Run órfã após dez minutos sem invocação ativa; órfã termina como falha técnica.
 - `AC-WORK-006-08`: a reparação histórica é idempotente: conclusão só é inferida de `task_complete` exato e gates suficientes; gate insuficiente usa `blocked`; órfã usa `failed`; `cancelled` nunca é inferido.
 - `AC-WORK-006-09`: toda mutação de fechamento projeta Run, Sub-Runs e trabalhos alterados; dashboard e projeções exibem o status canônico sem reviver Task terminal por heurística de invocação local.
+
+## REQ-WORK-007 — Commit canônico isolado por Task
+
+Cada Task concluída com mutação deve possuir um commit canônico isolado e publicável sem reorganização no momento do deploy.
+
+- `AC-WORK-007-01`: o assunto usa o provider efetivo exclusivamente `CODEX` ou `CLAUDE` e não contém `AUTO`; em linhagem evidenciada usa blocos opcionais `[P:XXXX] [S:XXXX] [T:XXXX]`, Task sem PRD/SPEC usa `[Task-first:XXXX]` e commit funcional sem Task usa `[CODEX] <título funcional>` sem `ZAIP-Task`. Referências têm quatro caracteres do alfabeto ZAIP, blocos e trailers sem evidência são omitidos, o assunto nunca excede 96 caracteres e somente o título pode ser reduzido em limite de palavra.
+- `AC-WORK-007-02`: o corpo contém trailers `ZAIP-PRD`, `ZAIP-SPEC`, `ZAIP-Task`, `ZAIP-Change`, `ZAIP-Execution` e `ZAIP-Agent` com identificadores completos, omitindo apenas os ancestrais inexistentes; o commit de integração também registra `ZAIP-Product-Commit`.
+- `AC-WORK-007-03`: a integração recusa worktree pendente, mensagem não canônica, Task divergente, arquivo fora do write scope ou conflito; uma Task aprovada produz um merge `--no-ff` com a mesma atribuição canônica, preservando o candidato validado.
+- `AC-WORK-007-04`: pedido explícito de deploy/push é Git-only e autoriza reconciliar com segurança somente a branch e o worktree selecionados, além de particionar o trabalho pendente pretendido/evidenciado em commits funcionais com pathspecs explícitos. Sem IDs de PRD/SPEC/Task, não os fabrica nem inclui trailers `ZAIP-*`; nunca executa `git add -A`, adiciona feature não relacionada, combina grupos, reescreve histórico, força push, expõe segredo ou faz squash da hierarquia.

package/templates/.agents/requirements/zaip-strategic-95.md

@@ -0,0 +1,20 @@
+---
+schema_version: 2
+id: REQUIREMENTS-ZAIP-STRATEGIC-95
+area: strategic-95
+title: Evidências, custo por Task e autonomia por SPEC
+status: active
+version: 1
+source_change: null
+source_release: "1.0.7"
+---
+
+# Evidências, custo por Task e autonomia por SPEC
+
+## REQ-ZAIP-STRATEGIC-95-001 — Evidência determinística para execução autônoma
+
+As capacidades estratégicas devem ser verificáveis por estado persistido e testes reproduzíveis. Nenhuma métrica de produção, economia percentual ou autonomia é inferida de configuração, contagem de artefatos ou tentativa incompleta.
+
+- AC-ZAIP-STRATEGIC-95-001: uma execução com Sub-Run executor elegível e finalizer concorrentes preserva uma única captura terminal por Sub-Run, não permite finalizer antes do executor terminal e só persiste `finalization_barrier.satisfied: true` depois da Evidence exigida e do finalizer real concluído. Testes devem reproduzir a corrida create/capture/close e confirmar que replay idempotente não cria Evidence, terminal ou Sub-Run duplicados.
+- AC-ZAIP-STRATEGIC-95-002: uma coorte reproduzível de Tasks concluídas define população, intervalo temporal, timezone e chave de equivalência; cada linha inclui Task, tentativa, modelo, effort, custo/uso observados, quality floor, resultado de qualidade e rework. Agregação só compara custo quando baseline equivalente e ambos os custos são observados; exclusões e campos ausentes são explícitos, e não há percentual de economia sem numerador e denominador observados. Testes cobrem coorte vazia, dados incompletos, rework e agregação determinística.
+- AC-ZAIP-STRATEGIC-95-003: cada SPEC autônoma recebe execução isolada com DAG e write scopes próprios, orçamento/cancelamento próprios e executor/finalizer próprios. Cancelamento ou falha de uma SPEC não encerra nem consome o orçamento de SPEC independente; cada finalizer valida somente o candidato integrado da sua SPEC e encerra por último. Testes cobrem duas SPECs paralelas, colisão de scope, cancelamento isolado, budget esgotado e ordem de finalização.

package/templates/.agents/rules/{zaip/architecture.md → architecture.md}

@@ -7,7 +7,7 @@ requires:
   - RULE-CORE
 ---
 
-# Arquitetura, desenvolvimento e CQRS
+# Arquitetura, desenvolvimento e CQRS canônicos
 
 - Modele áreas do sistema como módulos coesos com fronteiras públicas explícitas.
 - Quando existirem, mantenha as superfícies do produto em `apps/frontend` (UI do produto), `apps/backend` (APIs e workers) e `apps/site` (landing page e site público). Não trate o dashboard ZAIP como nenhuma dessas superfícies.

package/templates/{.zaip-aios/templates/rules/zaip → .agents/rules}/context.md

@@ -7,13 +7,13 @@ requires:
   - RULE-CORE
 ---
 
-# Contexto e economia de tokens
+# Contexto e economia de tokens canônicos
 
-- Comece por `project.yaml`, `.agents/rules/zaip/core.md`, projeção de trabalho ativo e Requirements citados por ID; o lock não pertence ao prompt comum.
+- Comece por `project.yaml`, `.agents/rules/core.md`, projeção de trabalho ativo e Requirements citados por ID; o lock não pertence ao prompt comum.
 - Respeite `context.canonical_roots` e só abra `projection_roots` em setup, distribuição, release ou parity.
 - Carregue Rules, skills, módulos, símbolos, testes e decisões adicionais somente quando aplicáveis.
 - Prefira mapas, resumos e trechos focados a concatenar o repositório.
-- Liste trabalho por `.agents/projections/runtime/` com status, relação e paginação; abra um corpo canônico somente depois de selecionar o ID.
+- Liste trabalho pelos manifests canônicos em `.agents/records/lifecycle/`, com status, relação e paginação; abra um corpo canônico somente depois de selecionar o ID.
 - Nunca faça scan de `.agents/records/` nem de `.agents/data/` em operações comuns. Scan completo só é permitido em rebuild/migração explícitos e confirmados.
 - Trate `.agents/records/<kind>/<ano>/<mês>` como escrita canônica e leitura pontual. Partições diárias anteriores e `.agents/data/` são fallback legado somente leitura.
 - Não carregue eventos brutos de Run por padrão; use resumos e abra eventos específicos sob demanda.

package/templates/.agents/rules/core.md

@@ -0,0 +1,21 @@
+---
+id: RULE-CORE
+load: always
+priority: critical
+max_context_tokens: 1400
+requires: []
+---
+
+# Regras centrais
+
+- Leia `.agents/config/project.yaml`, esta Rule e somente Rules aplicáveis antes de agir. Preserve domínio independente de framework, infraestrutura e fornecedor; respeite escopo/autoridade e peça direção antes de ação destrutiva, irreversível ou externa.
+- Pensar/explorar PRD/SPEC é `conversation`; criar persiste o pacote `draft` e PreparedPlan com telemetria, e `ready|execute` materializa a DAG. PRD/SPEC são opcionais; a entrada pode ser Task, SPEC ou PRD. PRD cancelado é imutável: crie sucessor `rework`.
+- Classifique/capture o turno: pergunta, análise pontual ou baixa confiança cria só Run `conversation`; continuação/refinamento/rework reutiliza foco; edição persistente, resultado independente ou pedido explícito cria Task de título semântico (nunca copiado/truncado do prompt). Pedido explícito no turno de `deploy|push|publicar|publicação GitHub` seleciona `$zaip-skill-github-deploy`, é Git-only e não materializa lifecycle; autoriza reconciliação limitada e commits funcionais apenas do diff pretendido/evidenciado, com pathspecs explícitos e sem inventar IDs ausentes. A seleção não autoriza outro provider, `git add -A`, force, segredos ou worktrees alheios.
+- Criar/refinar PRD/SPEC `draft` persiste macro/PreparedPlan em Execution `interaction`, sem Task, Change ou delivery, vinculada à Run/`creation_run_id`; agregue telemetria apenas observada/reconciliada. Fora disso, antes de mutação persistente no repositório/PC materialize Task, Execution, Change e Run raiz; pedido avulso entra em Execução. Só Git/deploy sem produto, manifests/telemetria gerados, `.git`, cache, build, teste e temporário são isentos; código, documentação e configuração nunca são.
+- Faça no máximo cinco perguntas por turno e três turnos; depois registre decisões delegáveis. Autoridade, credencial, lei e segurança não delegáveis bloqueiam. Resolva verbos por alvo/status em `RULE-WORKFLOW`: `execute` usa o menor grão, `implemente` sem alvo conversa, `desenvolva|melhore|aprimore` planeja/rework. Nunca invente tokens, custo, decisão, Evidence, teste ou resultado.
+- Em modo manual carregue `RULE-MODEL-ORCHESTRATION` antes da primeira resposta visível; aviso não bloqueia nem altera seleção. Com Codex/delegação use apenas `codex_name` do catálogo, formato `zaip-agent-NOME`, recursivamente; proíba `default`, `worker`, `explorer` e tipos ad-hoc.
+- Cada `client_turn_id` observável tem uma Execution idempotente/claim atômico; sem ele use identidade local sem prometer idempotência. `interaction` read-only sem descendentes é conversa sem Task artificial e termina após a resposta entregue, sem executor ou finalizador; interaction com trabalho delegado e `delivery` exigem executor/finalizador. `delivery` é trabalho materializado e reuso exige kind/origem compatíveis. A raiz é `zaip-agent-orchestrator`; quando a barreira é exigida escolha executor por capacidade, permita reviewer/auditor/integrator e termine com `zaip-agent-finalizer` em `finalization`, após descendentes, bloqueando novas chamadas.
+- Hooks são best-effort: após cada spawn/terminal o orquestrador também executa `zaip subagent capture` idempotente com metadados reais. Use session/turn filhos, `agent-id=agent_path`, `parent-agent-id=client_thread_id` da raiz e turn distinto por chamada. Só terminal sem metadata do `zaip-agent-finalizer` usa `capture-terminal`, criando/fechando Sub-Run `finalization` com session/turn/model/provider/usage indisponíveis; nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
+- Em `model_orchestration.mode:auto`, selecione automaticamente apenas origens em `automatic_sources` (`spec`,`prd`); fixe modelo/effort no início de cada Run/Sub-Run distinta, herde nas calls internas e exija nova chamada para mudar. Task avulsa preserva seleção manual, sem inferir `default_model`.
+- Todo PreparedPlan PRD/SPEC traz `model_signals` por Task; o framework persiste `model_profile`, `task-risk-v1` e motivos, usando `runtime_defaults`, `runtime`, política/defaults sem `standard` silencioso. Não infira fase/complexidade/transversalidade/ambiguidade/rework/custo/capacidade por contagem de arquivos; use sinais, fase/agente e capacidades. Cabeçalho e `model.selection.recorded` repetem a seleção enviada.
+- Quando útil, plano visível usa `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, 3–4 passos (máximo 5); omita fase sem ação e combine trivialidades.

package/templates/.agents/rules/{zaip/evolution.md → evolution.md}

@@ -7,7 +7,7 @@ requires:
   - RULE-WORKFLOW
 ---
 
-# Evolução governada do framework
+# Evolução governada canônica
 
 - Trate aprendizado operacional como Finding com locator verificável; comentário ou opinião isolada não é evidência.
 - Antes de mudar um contrato do framework, registre Proposal com alternativas e Decision com origem humana ou AI, alternativa escolhida e consequência.

package/templates/.agents/rules/frontend-lite.md

@@ -0,0 +1,18 @@
+---
+id: RULE-FRONTEND-LITE
+load: auto
+priority: high
+max_context_tokens: 450
+requires:
+  - RULE-WORKFLOW
+---
+
+# Perfil frontend lite canônico
+
+- Classifique como `lite` somente mudança de frontend local, reversível e puramente visual, limitada a até 3 arquivos de um único componente, como trocar ícone, cor, espaçamento, texto curto ou classe CSS.
+- Promova para `standard` se houver lógica, estado, navegação, formulário, dados, API, persistência, dependência, configuração, token global, layout responsivo, semântica de acessibilidade ou alcance entre componentes.
+- Promova para `critical` se houver autenticação, autorização, segredo, pagamento, privacidade, perda de dados, contrato público ou ação irreversível.
+- Em `lite`, dispense plano visível, exploração ampla e anexos extras. Faça somente a delegação mínima obrigatória pelo lifecycle (executor elegível e finalizador), sem subagentes adicionais. Use um único critério de aceite que descreva exatamente a alteração pedida.
+- Em `lite`, valide somente o diff dos arquivos alterados. Não execute lint, typecheck, teste, build, preview, screenshot ou E2E, salvo pedido explícito do usuário ou lógica/regressão declarada.
+- Se o usuário já confirmou visualmente o resultado, encerre após conferir o diff; não repita validações.
+- Interrompa o perfil `lite` e reclassifique ao encontrar qualquer impacto fora dos critérios acima.

package/templates/{.zaip-aios/templates/rules/zaip → .agents/rules}/model-orchestration.md

@@ -7,7 +7,7 @@ requires:
   - RULE-CORE
 ---
 
-# Orquestração manual de modelo e esforço
+# Orquestração canônica de modelo e esforço
 
 Esta Rule só se aplica quando `model_orchestration.mode` for `manual`.
 

package/templates/.agents/rules/run-lifecycle-closure.md

@@ -0,0 +1,24 @@
+---
+id: RULE-RUN-LIFECYCLE-CLOSURE
+load: always
+priority: critical
+max_context_tokens: 840
+requires:
+  - RULE-CORE
+  - RULE-WORKFLOW
+---
+
+# Fechamento canônico de Runs e trabalho unificado
+
+- Toda Execution de `interaction` ou `delivery` tem uma Run raiz do `zaip-agent-orchestrator`. Interaction read-only sem descendentes conclui após a resposta sem executor/finalizador; interaction com descendente delegado e delivery aguardam a árvore inteira e exigem ao menos um executor elegível pelas capacidades do catálogo.
+- Cada Run raiz governa uma tentativa; antes de terminar, a Task já está em `completed`, `blocked`, `failed` ou `cancelled`. `executing` e `verifying` nunca sobrevivem ao fim da tentativa.
+- A raiz é a única invocação `orchestrator`, sem pai e em profundidade zero. Toda invocação delegada tem pai, raiz e profundidade positiva; `RUN-*` permanece somente sua chave física compatível.
+- O último filho é exatamente um Sub-Run do `zaip-agent-finalizer` com propósito `finalization` em interaction delegada ou delivery. Ele só inicia depois do executor elegível e dos demais descendentes; sua barreira impede novos Sub-Runs. Auto-settlement nunca fecha interaction com descendente ativo.
+- O finalizador avalia gates e Evidence e retorna somente `completed`, `blocked`, `failed` ou `cancelled`, com motivo e referências. A CLI aplica o estado terminal canônico. Finalizador ausente, incompleto ou falho bloqueia a Task antes de a Run raiz terminar.
+- O resultado da Task é separado do status técnico da Run/Sub-Run: uma orquestração tecnicamente `completed` pode produzir Task `blocked` se gate, validação ou Evidence não passar.
+- Use `completed` somente com gates e Evidences aprovados; `blocked` para dependência externa, autoridade ou informação ausente, gate/teste pendente, falta de Evidence, limite de tempo/contexto ou outra inconclusão. Registre o motivo e a condição objetiva de retomada.
+- Use `failed` somente para erro técnico ou de integridade comprovadamente impeditivo. Nunca use `failed` por tempo, silêncio do usuário, escopo incompleto ou gate pendente; esses casos são `blocked`. `cancelled` requer pedido humano explícito e nunca é inferido.
+- `blocked` retoma com `task resume`; `failed` exige `task rework` na mesma Task, incrementa a tentativa e inicia nova Run. A continuação não preserva Task em `executing` ou `verifying`; `completed` e `cancelled` são imutáveis.
+- Uma Run de SPEC/PRD não terminaliza o macro a cada turno ou Task: o pai fica `active` durante a execução, inclusive nos intervalos, e somente passa à Verificação depois de todas as Tasks terminarem, antes dos gates parentais de delivery.
+- `run reconcile --open` é reparação manual: só ocorre após confirmação humana no popup Reconciliar, nunca ao abrir/atualizar o dashboard, em cada turno ou por intervalo. Fecha somente `task_complete` local exato; Run órfã sem invocação ativa por dez minutos falha tecnicamente; gates ausentes bloqueiam; conclusão e cancelamento nunca são inferidos.
+- Dashboard e projeções exibem apenas o estado canônico persistido. Nenhum consumidor revive Task terminal por heurística de invocação local nem reaplica estado como se fosse reconciliação.

package/templates/{.zaip-aios/templates/rules/zaip → .agents/rules}/security.md

@@ -7,7 +7,7 @@ requires:
   - RULE-CORE
 ---
 
-# Segurança e infraestrutura
+# Segurança e infraestrutura canônicas
 
 - Aplique least privilege e deny by default a identidade, filesystem, rede e automação.
 - Valide e limite input não confiável; bloqueie traversal, redirect inseguro, injection, replay e exaustão de recursos.

package/templates/.agents/rules/text-writing-utf8.md

@@ -0,0 +1,12 @@
+---
+id: RULE-TEXT-WRITING-UTF8
+load: always
+priority: high
+max_context_tokens: 120
+requires:
+  - RULE-CORE
+---
+
+# Escrita textual UTF-8 canônica
+
+- Ao escrever ou reescrever títulos e textos, preserve os caracteres Unicode legíveis no UTF-8 original e nunca persista caracteres corrompidos por recodificação (mojibake).

package/templates/.agents/rules/workflow.md

@@ -0,0 +1,25 @@
+---
+id: RULE-WORKFLOW
+load: auto
+priority: critical
+max_context_tokens: 2000
+requires:
+  - RULE-CORE
+---
+
+# Workflow e rastreabilidade canônicos
+
+- Pensar/explorar PRD/SPEC é Conversation sem artefato. Criar/refinar explicitamente persiste PRD/SPEC `draft`, PreparedPlan, Run e `creation_run_id` em Execution `interaction`, sem Task, Change ou delivery; agregue duração/tokens/custo só observados/reconciliados. `ready` explícito materializa DAG, Execution, Changes e Tasks `planned` sem iniciá-las; `execute` materializa e inicia. A interaction não rebaixa a visibilidade `draft`.
+- Fluxos: `PRD -> SPECs independentes -> PreparedPlan -> ready Tasks`, `SPEC standalone -> PreparedPlan -> ready`, ou Task-first. Use uma SPEC por padrão; outra requer paralelismo verificável, contrato estável e write scopes sem conflito. Dependências pertencem à SPEC; integração cross-SPEC é gate parental do PRD.
+- Colunas: Definição só PRD `draft`; Planejamento só SPEC `draft`; Pronto para Executar recebe macro `ready` e Task `planned`, não ativa/nunca iniciada ou tentada. Task `draft` não entra; iniciada/tentada fica em Execução, Verificação ou terminal e não retorna.
+- Todo turno tem Execution/Run raiz, mas só trabalho executável tem Task. Pergunta, explicação, status, análise pontual ou baixa confiança usa `interaction`, `phase: conversation`, `entrypoint: conversation`, sem Task/Change artificial. Continuação, resposta, aprovação, refinamento e rework reutilizam o alvo/thread; nova Task explícita prevalece. Fora da exceção draft, mutação persistente ou resultado independente cria Task antes de `prepare -> execute`; deploy/push/publicação puros são Git-only.
+- PRD pode ser draft sem SPEC, mas `prepare|execute|deliver` exige SPEC e veda Change direta fora dela; só SPECs selecionadas pelo PreparedPlan contam. `task create` só persiste draft; Run de captura é separado. `prepare` pré-aloca IDs/valida DAG sem produto, Change, Execution ou Run de execução; em PRD/SPEC não cria Task nem promove draft. Task auto-prepare só sem `depends_on`; dependência exige `zaip plan build` completo.
+- Só pedido humano explícito move PRD/SPEC a `ready`; executar autoriza `prepare` necessário e `execute`. Criação, revisão, refinamento, aprovação de conteúdo ou planejamento genérico não promovem. Até cinco perguntas críticas no primeiro turno e três de esclarecimento; depois decisão técnica IA delegável. Não presuma credencial, autoridade externa/destrutiva, obrigação legal ou segurança não delegável.
+- Resolva verbo por alvo/status: `finalize|conclua|deixe pronto` em `draft|ready` significa `ready`; conclusão de implementação em `active` continua Tasks/gates; `execute` usa o menor grão nomeado. `implemente` sem alvo conversa; em draft finaliza plano, ready executa, active|blocked|failed continua/retoma/rework. `desenvolva|melhore|aprimore` planeja/refina/rework e requer nova promoção. PRD cancelado é imutável; sucessor draft usa `tags:[rework]` e `rework_of_prd_id`.
+- `execute` é explícito/idempotente e materializa DAG antes da primeira mutação; `execution` inicia na tentativa mesmo sem diff, comprovado separadamente por `changed_files`/`result`. Pedido avulso de ação materializa/inicia Task, Change, Execution e Run raiz antes da mutação; só fica pronto se o usuário autorizou apenas planejamento/preparo. Refinamento draft é Git-native, incrementa `revision`/`updated_at`; após prepare gere revisão/rework, sem Task extra salvo pedido/resultado independente.
+- Toda mudança de código tem Change antes da implementação; `change.md` registra plano, decisão, Evidence, eval, teste e resultado. Requirements são verdade funcional/técnica; Change aplica delta só após AC/Evidence. Task é trabalho executável, Execution tem snapshot DAG, invocação orquestradora é inicial, delegada é subagente e chamada LLM é evento observável.
+- `RUN-*` é chave física de invocação: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva. `MCALL-*` é global e pertence a uma invocação; `owner|contributor` é legado normalizado. Interaction read-only sem descendentes conclui após a resposta, sem executor/finalizador. Interaction com descendente delegado e toda delivery usam raiz `zaip-agent-orchestrator`, executor por capacidade e último delegado `zaip-agent-finalizer`; reviewer/auditor/integrator podem precedê-lo, e auto-settlement nunca encerra interaction com filho ativo. Run filha não fecha macro; SPEC/PRD ficam active até Tasks/gates parentais. Status técnico é separado do resultado Task; `blocked` usa `task resume`, `failed` `task rework`, `completed|cancelled` são imutáveis.
+- Reconciliação global só após confirmação humana no popup, nunca abrir dashboard/turno/intervalo; usa `task_complete` exato ou falha órfã após dez minutos, sem inferir cancelamento/sucesso. Risco é `lite|standard|critical`; anexos só por risco/Evidence. Assurance V1: standalone lite uma validação/Evidence e teste só lógica/regressão; standard 2–3 validações, teste e Evidence consolidada; critical 3+ e quality review independente. Mutação, rollback, commit final e Evidence/AC dependem de sinais persistidos; sem sinal preserve gate conservador. SPEC/PRD adicionam matriz parental, 3 validações/Evidences, integração e revisão independente.
+- `execution.runtime` ausente/manual não invoca provider; autonomous é opt-in e integra somente commits de worktree limpa, write scopes e gates tipados. Toda Task concluída com mutação usa provider efetivo `CODEX|CLAUDE`, sem `AUTO`: a linhagem evidenciada usa `[P:XXXX] [S:XXXX] [T:XXXX]`, Task sem PRD/SPEC usa `[Task-first:XXXX]` e commit sem Task usa só `[CODEX] <título funcional>` sem `ZAIP-Task`; o assunto é ≤96 e só o título reduz por palavra, e IDs completos disponíveis ficam em trailers `ZAIP-*`.
+- Pedido explícito no turno de `deploy|push|publicar|publicação GitHub` autoriza o `$zaip-skill-github-deploy` a reconciliar com segurança somente a branch e o worktree selecionados e a formar commits funcionais apenas do diff pretendido/evidenciado, sempre com pathspecs explícitos. Esta autorização substitui a limitação anterior a uma frase específica; use `rebase` por padrão, ou `merge` quando o usuário o escolher, mantendo referência recuperável e stash nomeado. Quando PRD/SPEC/Task não existirem, o commit usa `[CODEX] <título funcional>` e não contém IDs ou trailers `ZAIP-*` inventados. Nunca autoriza staging amplo, `git add -A`, force, segredos, squash, feature alheia ou worktree não selecionado.
+- Plano visível: `DEFINE:` contexto/resultado/critério, `PLAN:` ciclo/DAG, `EXECUTE:` mudança, `VERIFY:` valida/Evidence/encerra; não use artefato como fase nem narre comandos internos. Registre decisão humana/IA com origem junto de Change/Execution; derive ledger do Git diff e preserve alterações do usuário. Estado novo fica em `.agents/records/<kind>/<ano>/<mês>`; diário, `.agents/data` e V1 são legado só leitura até migração explícita.