@zaip-ai/cli 2.2.0 → 3.0.0

package/templates/.agents/zaip-aios/guides/16-lifecycle-e-reconciliacao.md

@@ -15,7 +15,7 @@ Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro
 |---|---|
 | Definicao | somente PRD draft |
 | Planejamento | somente SPEC draft |
-| Pronto para Executar | PRD/SPEC ready e Task avulsa nao iniciada |
+| Pronto para Executar | PRD/SPEC ready e Task planned nunca iniciada/tentada, avulsa ou da DAG |
 | Execucao | Task executing e SPEC/PRD active |
 | Verificacao | Task verifying ou macro nos gates parentais |
 | Finais | completed/delivered, blocked, failed ou cancelled |
@@ -30,13 +30,32 @@ Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro
 - cada Run/Sub-Run fixa agente, modelo e effort; mudanca deliberada abre outra chamada de agente.
 - Calls e ferramentas sao eventos internos; quantidade, tokens e custo ficam agregados na Run/Sub-Run, sem tela propria.
 
-Toda delivery e interaction com descendentes exigem ao menos um executor
-elegível por capacidade e o `zaip-agent-finalizer` como último filho. Ele aguarda
+Toda delivery e interaction delegada exige o `zaip-agent-finalizer` como último filho.
+Sucesso também exige executor elegível por capacidade ou raiz Task direta autorizada. Gui aguarda
 os demais descendentes, bloqueia novas chamadas e retorna a decisão restrita
 para a CLI aplicar. Interaction read-only sem descendentes termina após a
 resposta, sem executor/finalizador. Publicação puramente Git não cria lifecycle.
 Status técnico da chamada de agente e resultado do trabalho são independentes.
 
+Se nenhum executor pôde iniciar e não há raiz Task direta autorizada válida,
+Gui ainda pode registrar bloqueio/falha real, mas `executor_missing` impede
+`completed` mesmo com Evidence aprovada. Uma raiz direta válida satisfaz essa
+alternativa, sem dispensar os demais gates. `conversation finish` e `run finish` usam o mesmo escritor
+canônico, preservando a decisão imutável, os vínculos e o replay idempotente.
+
+## Execução direta autorizada
+
+A Task avulsa prefere o principal direto. O host registra a referência humana
+com `--direct-authorization REFERÊNCIA` em `conversation start` ou `run start`,
+desde o início de uma raiz Task/Change/Execution observada. Thread, modelo ou
+classificação de intenção não são autorização por si só. Modelo/esforço manuais
+observados, inclusive `ultra`, são preservados sem ampliar a allowlist automática.
+Raiz macro, filho ou captura incompleta não recebem esse contrato.
+
+Gui pode avaliar essa entrega sem um executor filho fictício. Evidências,
+revisão aplicável, candidato, descendentes terminados e decisão imutável continuam
+necessários. Raízes antigas fechadas não recebem nova aprovação retroativa.
+
 `blocked` e retomavel com `task resume`; `failed` exige `task rework` na mesma Task e nova tentativa. `completed` e `cancelled` sao imutaveis. Interromper geracao bloqueia; cancelar a Task explicitamente cancela.
 
 `finalize|conclua` em macro `draft|ready` significa lapidar e deixar pronto; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. `implemente` é sensível ao estado; `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado gera sucessor vinculado com tag `rework`.
@@ -60,3 +79,35 @@ O reparo e idempotente: `task_complete` local exato permite tentar conclusao; ga
 ## Mutacoes
 
 Codigo, documentacao e configuracao exigem Task materializada e Run raiz ativa antes da escrita. Sao isentos deploy/publicacao Git sem mudanca de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e temporarios descartaveis. O hook pre-write faz checagem local do turno, sem tokens e sem reconciliacao global.
+
+## Um responsável e uma decisão real por tentativa
+
+Se a raiz já está atribuída à Task, ela é seu orquestrador: não crie outro Dave.
+O macro delega um responsável por Task elegível, com pai e profundidade reais.
+Executor/revisor retornam resultados; Gui é o último filho direto do responsável,
+irmão dos trabalhadores. O fechamento parental do PRD/SPEC é outro gate.
+
+A ordem canônica é **início observado → decisão real → Stop → fechamento**.
+Gui read-only avalia e retorna; não grava lifecycle nem precisa permanecer
+ativo esperando um recibo. O host autorizado retransmite a decisão com
+`subagent capture --event stop`, usando identidade rica real e campos
+`--task-outcome`, `--summary`, `--evidence` e `--changed-files`.
+A CLI autentica vínculos e persiste a decisão imutável antes do Stop canônico.
+
+- Gui nativamente terminal ainda pode ter sua decisão retransmitida se o
+  responsável estiver aberto. Status nativo `completed` não é aprovação.
+- Responsável fechado só aceita replay de decisão já persistida. Sem decisão,
+  requer recuperação/nova tentativa autorizada; não invente aprovação retroativa.
+- Gui sem decisão, executor inelegível, Evidence ausente/mista ou correlação
+  inválida continua bloqueando; nenhum recibo pode ser fabricado.
+- No gerenciado, `closure_pending` retoma apenas a conciliação da decisão,
+  sem despachar outro worker/reviewer/Gui.
+- Se a persistência falhar, mantenha evento/erro recuperável e condição objetiva;
+  não declare que o estado canônico mudou antes de lê-lo.
+
+A política prefere Task avulsa direta. Uma raiz de delivery com Task, Change,
+Execution, turno e modelo observados pode registrar `--direct-authorization`
+no início. Esse contrato imutável satisfaz a alternativa ao executor capturado,
+sem criar Sub-Run fictício nem converter retrospectivamente uma raiz antiga.
+Revisão aplicável, Evidence e decisão real de Gui continuam obrigatórias;
+uma autorização humana apenas no texto não substitui o contrato capturado.

package/templates/.agents/zaip-aios/guides/18-catalogo-de-agentes.md

@@ -21,7 +21,7 @@ O schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos
 | Rafa | Tech Lead | `zaip-agent-builder` | `rafa_tech_lead_zaip_agent` | Cria/refina SPECs e executa delivery genérico, inclusive dashboard/local. | Definição técnica ou mudança sem especialista mais específico. | PRD, design central, website, frontend ou backend especializados. | `spec`, `architecture`, `decomposition`, `dashboard`, `local` |
 | Leo | Software Engineer | `zaip-agent-task-executor` | `leo_software_engineer_zaip_agent` | Executa Task genérica delimitada, inclusive dashboard/local, e produz evidência. | Task pronta, autocontida e sem escopo de especialista obrigatório. | Planejamento macro, coordenação ou revisão independente. | `task`, `implementation`, `verification`, `evidence`, `local` |
 | Bia | Product Manager | `zaip-agent-analyst` | `bia_product_manager_zaip_agent` | Cria/refina PRDs e analisa interações sem antecipar Tasks de delivery. | Problema de produto, PRD, descoberta, escopo ou refinamento. | SPEC, implementação, aprovação técnica ou deploy. | `prd`, `product`, `discovery`, `requirements`, `problem` |
-| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Obrigatoriamente como último Sub-Run de interação ou delivery. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |
+| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Último filho do responsável em delivery ou interaction delegada; não em conversa read-only sem filhos. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |
 | Nanda | Principal Engineer | `zaip-agent-reviewer` | `nanda_principal_engineer_zaip_agent` | Revisa Requirements, diff, testes e evidências sem mutar produto. | Mudança implementada que precisa de revisão independente. | Para implementar a própria correção ou integrar worktrees. | `review`, `findings`, `requirements`, `diff` |
 | Dani | Integration Engineer | `zaip-agent-integrator` | `dani_integration_engineer_zaip_agent` | Integra trabalho revisado e executa gates combinados. | Worktrees ou mudanças independentes já revisadas. | Antes da revisão ou para criar requisitos. | `integration`, `merge`, `combined-gates`, `worktree` |
 | Ana | Quality Auditor | `zaip-agent-auditor` | `ana_quality_auditor_zaip_agent` | Reproduz evidências e emite auditoria independente. | Risco alto, release ou alegação que exige reprodução final. | Implementação, correção ou autoria da evidência. | `audit`, `reproduce`, `release`, `quality` |
@@ -32,7 +32,6 @@ O schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos
 | Will | Backend Specialist | `zaip-agent-backend` | `will_backend_specialist_zaip_agent` | Implementa backend, APIs, persistência e integrações. | `apps/backend/**`, `modules/**` ou capability de backend. | Frontend, website ou design visual central. | `backend`, `api`, `persistence`, `integration` |
 | Jonny | Website Developer | `zaip-agent-website-developer` | `jonny_website_developer_zaip_agent` | Cria sites/LPs com stack do framework, SEO, GEO e acesso por agentes. | `apps/site/**`, site institucional, LP, SEO, GEO ou Markdown for Agents. | App de produto, backend ou mudança da regra central de design. | `website`, `landing-page`, `seo`, `geo`, `markdown-for-agents`, `agent-readiness` |
 | Manu | Product Designer | `zaip-agent-designer` | `manu_product_designer_zaip_agent` | Governa `DESIGN.md`, design tokens (cor, tipografia, espaçamento e raio), componentes centrais e páginas de catálogo digital. | Regra central de design, Design System, tokens, `design-system` ou `componentes`. | Word, PPT, imagem de marketing ou componente local que apenas consome regras existentes. | `design-system`, `design.md`, `tokens`, `central-components`, `componentes` |
-
 | Dan | Cloud Engineer | `zaip-agent-cloud-engineer` | `dan_cloud_engineer_zaip_agent` | Projeta e valida infraestrutura cloud declarada. | Infraestrutura cloud, provisionamento, containers, Terraform ou Docker. | Implementação de aplicação, deploy ou infraestrutura fora do escopo declarado. | `cloud`, `terraform`, `docker`, `provisioning` |
 | Luiz | Security Auditor | `zaip-agent-security-auditor` | `luiz_security_auditor_zaip_agent` | Audita segurança de forma independente e somente leitura. | Auditoria de segurança, mudança sensível ou release que exige avaliação independente. | Implementação, autoria de remediação ou deploy. | `security`, `audit`, `risk`, `release` |
 | Lucia | Marketing Analyst | `zaip-agent-marketing-analyst` | `lucia_marketing_analyst_zaip_agent` | Planeja marketing, copy, campanhas e briefs de imagem com evidência. | Estratégia de marketing, campanha, copy de landing page ou brief de imagem. | Implementação de produto, backend ou governança central de design. | `marketing`, `copy`, `campaign`, `image-brief` |
@@ -74,3 +73,12 @@ Nanda (`agent-reviewer`) usa `gpt-5.6-terra` com esforço `medium` e `soft_cycle
 ## Dashboard e segurança operacional
 
 A tela **Configurações > Catálogo de agentes** apresenta a persona e mantém a identidade técnica somente leitura. Ao salvar, o runtime valida o catálogo, deriva o único nickname, sincroniza adapters e reverte a escrita se a paridade falhar. Agentes de framework permitem alteração de persona e preferências de modelo/effort; propósito, capacidades e identidade técnica continuam protegidos.
+
+## Preset e configuração efetivamente executada
+
+Defaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,
+o preset e a seleção final do despacho gerenciado também são validados:
+Essencial veda Astra automático e não herda a exceção manual do principal.
+Informe ao usuário a delegação necessária e a possibilidade de modelos
+diferentes. Mantenha indisponível o que o host não informou.
+Consulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).

package/templates/.agents/zaip-aios/guides/19-assurance-e-autonomia.md

@@ -1,6 +1,179 @@
-# Assurance adaptativa e autonomia opt-in
+# Assurance adaptativa e perfis de autonomia
 
-O ZAIP-AIOS separa duas decisões que não devem ser confundidas: quanto de prova uma entrega exige e quem executa a DAG. A primeira é governada por `assurance`; a segunda por `execution`. O modo manual continua sendo o padrão seguro e econômico.
+Este guia descreve `autonomy-v1`, implementado nas fontes em preparação para a
+v3. Não significa que `@latest` já distribua essas mudanças ou que a release
+esteja qualificada. Confira a versão instalada e o caminho de execução.
+
+## Quatro configurações independentes
+
+| Controle | Valores | O que decide |
+| --- | --- | --- |
+| Instalação | `full`, `dev-lite`, `lite` | Ferramentas instaladas, não orçamento de IA |
+| Assurance | risco `lite`, `standard`, `critical` e sinais persistidos | Provas necessárias para aceitar a entrega |
+| Autonomia | `essential`, `balanced`, `persistent` | Persistência e replanejamento por Task |
+| Runtime | `manual`, `managed` ou `autonomous` | Sem provider, PRD/SPEC gerenciados ou também Task gerenciada explícita |
+
+`model_orchestration` é a política de seleção, não o botão de ativação do
+runtime. Salvar um preset não inicia uma Task, não altera o seletor do Codex e
+não concede permissão externa.
+
+## Perfis por Task
+
+| Perfil | Execuções máximas | Replanejamentos máximos | Rota dos replanejamentos |
+| --- | --- | --- | --- |
+| Essencial (`essential`) | **4**: 1 inicial + 3 reparações | **1** | Sol/high; nunca Astra automático |
+| Equilibrado (`balanced`, padrão novo) | **10**: 1 inicial + 9 reparações | **3** | Sol/high → Astra/high → Astra/high |
+| Persistente (`persistent`, opt-in) | **Sem teto** | **Sem teto** | Sol/high primeiro; Astra/high nos seguintes |
+
+Cada replanejamento válido libera até três reparações. São tetos, não uma
+obrigação de falhar ou gastar todas as tentativas. Se o aceite passar antes,
+siga para revisão e fechamento. No Equilibrado não existe quarto
+replanejamento; no Persistente não existe teto oculto de 10, 24 ou três planos.
+
+Exemplo máximo do Equilibrado:
+
+1. Execução inicial: tentativa 1.
+2. Replanejamento 1 com Sol/high: reparações nas tentativas 2–4.
+3. Replanejamento 2 com Astra/high: reparações nas tentativas 5–7.
+4. Replanejamento 3 com Astra/high: reparações nas tentativas 8–10; Astra/high
+   também pode executar nesse bloco, se selecionado pela rota válida.
+5. Sem aceite, registrar entrega parcial e resultado verdadeiro; não abrir
+   outra rodada gratuita.
+
+Uma SPEC com dez Tasks Equilibradas admite até **100 execuções** (10 iniciais
++ 90 reparações) e **30 replanejamentos**. A quota pertence a cada Task estável,
+não ao PRD, à SPEC, à Execution ou ao subagente. Calls internas, ferramentas,
+testes individuais, revisões e finalização não são dez execuções de produto:
+o teto não significa dez chamadas totais ao modelo.
+
+Persistente pode continuar indefinidamente e consumir créditos até
+cancelamento humano; fica desligado por padrão. Não promete ultrapassar
+indisponibilidade do host, falta de autorização, segurança ou ausência de prova.
+
+## Configurar no projeto e no Dashboard
+
+Mescle este bloco na raiz de `.agents/config/project.yaml`, sem substituir
+as demais configurações:
+
+```yaml
+autonomy:
+  version: 1
+  preset: balanced
+```
+
+No Dashboard, abra **Configurações do projeto**, escolha **Perfil de autonomia**
+e salve. A UI explica os limites e o consumo potencial do Persistente; API e
+YAML usam a mesma enumeração. Recarregue e confira o valor persistido.
+`essential` e `persistent` são as outras escolhas válidas. Não invente campos
+para alterar cotas ou modelos da tabela: o schema desse bloco é estrito.
+
+A mudança vale para **novas Tasks**. Tasks já iniciadas conservam seu perfil e
+consumo. Projetos antigos sem `autonomy` conservam comportamento legado;
+selecionar/salvar um perfil não migra silenciosamente estados já materializados.
+
+## Contagem determinística e recuperação
+
+O coordenador gerenciado reserva a operação **antes** de chamar o provider em
+`.local/autonomous/recovery/<hash-da-task>/ledger.json`. O diário é durável,
+privado e vinculado à Task, com escrita exclusiva e transições idempotentes.
+Não é cache descartável nem deve ser removido para liberar uma nova tentativa.
+
+- Reinício, nova Execution, `resume`, `rework` ou alteração do YAML não zeram
+  esse consumo. O `attempt_count` do lifecycle não substitui o diário de
+  tentativas/replanejamentos do coordenador.
+- Replay compatível reutiliza a reserva; resultado conflitante é rejeitado.
+  Resultado desconhecido permanece pendente até recuperação observável.
+- Replanejamento inválido consome sua reserva e não autoriza reparação de
+  produto. Pode consumir o orçamento antes de alcançar dez execuções.
+- O relógio, tokens, contagem de testes e `budget.soft_cycles` não calculam
+  tentativas. Tempo continua útil para diagnóstico, não para desistir da Task.
+- Timeout de comando, lease, lock ou ausência de resposta do provider é um
+  problema operacional a investigar; não prova defeito do produto.
+- Preserve logs sanitizados e a hipótese já tentada; não repita testes caros
+  inalterados apenas por demora, nem diminua ACs para obter aprovação.
+
+## Tarefas avulsas e modelos
+
+A Task avulsa prioriza execução direta com o modelo/esforço escolhido pelo
+usuário. Exemplo: Astra/ultra manual no principal não é uma escalada automática.
+No Essencial essa é a única exceção Astra: não se estende a filhos, herança ou
+fallback.
+
+Delegação só por necessidade concreta, como especialidade, isolamento ou
+revisão/finalização exigida. Antes de delegar, informe que a orquestração ZAIP
+pode selecionar modelo/esforço diferentes para os subagentes. Não prometa que
+filhos usam Astra só porque o usuário selecionou Astra no principal.
+A configuração efetivamente observada permanece separada da planejada.
+
+O replanejador recebe contexto delimitado e não implementa produto. Fora do
+Essencial, Astra/high torna-se elegível como **executor a partir do terceiro
+replanejamento**, sem ampliar escopo, autoridade ou orçamento. Ele não
+substitui revisão independente nem Gui. Veja o [guia 23](23-orquestracao-de-modelos.md).
+
+## Quando continuar e quando encerrar
+
+| Situação após recuperação aplicável | Resultado |
+| --- | --- |
+| Resultado, ACs, gates e evidências suficientes | `completed`, após fechamento canônico |
+| Falta de verificação, evidência, acesso, decisão ou conclusão segura | `blocked`, com condição objetiva de retomada |
+| Impedimento técnico ou de integridade comprovado | `failed`, com causa e rework necessário |
+| Pedido humano explícito para cancelar | `cancelled` |
+
+Não reduza critérios de aceite ao esgotar tentativas. Preserve o que foi feito,
+liste ACs sem prova e informe quantas execuções/replanejamentos ocorreram.
+“Falhou após três replanejamentos” só é correto com causa técnica comprovada;
+sem prova suficiente o resultado é bloqueado. Tempo decorrido não escolhe
+entre esses estados.
+
+Na DAG, continue ramos independentes elegíveis; não execute dependentes de
+Task não concluída nem entregue o macro sem seus gates. Uma Task bloqueada
+não deve causar repetição de Tasks já concluídas.
+
+## Limites atuais e adoção
+
+A garantia de contagem/modelo vale **no despacho gerenciado**, antes da
+invocação. `spawn_agent` chamado diretamente pelo Codex fora desse caminho
+não é interceptado por prompt, hook best-effort ou captura posterior.
+Sem observar o caminho real, não alegue controle determinístico universal.
+
+Novos projetos usam Equilibrado e `execution.runtime: managed`: PRDs/SPECs
+passam pelo executor gerenciado e avulsas permanecem diretas. `manual` e
+configuração legada ausente continuam sem provider. `autonomous` permite
+também Task avulsa gerenciada por comando explícito. Salvar não executa.
+
+A captura direta usa `conversation start ... --direct-authorization REFERÊNCIA`
+ou `run start` com a mesma opção, somente para raiz de delivery atribuída a
+Task/Change/Execution e turno/modelo observados. O contrato fica imutável no
+início; não converte raízes antigas nem cria executor fictício. Gui, Evidence,
+revisão aplicável e sua barreira continuam obrigatórios. O [guia 16](16-lifecycle-e-reconciliacao.md) descreve o relay.
+
+Migração explícita: `task migrate-autonomy TASK --execution EXEC --expected-revision N
+--legacy-attempts N --legacy-replans N --reason MOTIVO` mostra o preview;
+acrescente `--confirm` somente após revisar a contagem histórica. Exige Task
+inativa, inventário de Runs terminado, contagens não inferiores ao histórico
+observado e motivo. Preserva registros, estados e Evidence; congela o diário
+durável por Task. Não reaproveita planos antigos como autorização atual: exige
+novo plano dentro da quota restante. Se a quota acabou, continua esgotada.
+
+Se o número histórico de replanejamentos não foi registrado, use
+`--legacy-replans unknown --future-replans N` com uma concessão humana explícita
+dentro do preset (até 3 no Equilibrado). O total histórico permanece desconhecido;
+`N` limita somente os replanejamentos futuros. `--legacy-attempts N` continua
+preservando as execuções já consumidas: a concessão não reinicia o limite de dez.
+No Persistente, `--future-replans unlimited` exige a escolha explícita desse perfil.
+
+Não há economia financeira garantida pelos presets. Compare custo/tokens por
+Task aceita com cobertura real, incluindo reparos, revisão e replanejamento.
+Testes simulados de modelos não comprovam cobrança nem execução paga no host.
+
+## Assurance por domínio
+
+O preset não escolhe o rigor. Desenvolvimento exige testes comportamentais,
+regressões, segurança e rollback conforme risco. Conteúdo de Marketing,
+Branding ou Vendas exige fidelidade a fontes/briefing e revisão apropriada;
+Growth e Ops exigem dados, premissas e critérios de decisão explícitos.
+Não imponha teste de código a uma peça textual, nem use “texto” para dispensar
+segurança, autorização externa ou validação factual.
 
 ## Matriz de validação
 
@@ -65,11 +238,14 @@ execution:
 
 O projeto ZAIP-AIOS limita a concorrência produtiva a `max_parallelism: 3`, mas inicia em 1. A elevação só ocorre quando existem ramos sem dependência e sem sobreposição de write scope; o coordenador reivindica cada lote novamente com os locks do scheduler. O paralelismo efetivo é sempre o menor limite entre projeto, plano independente, provider e squad. `budget.soft_cycles` é aplicado ao agente escolhido em cada Task; tokens permanecem telemetria e custo, não checkpoint. `zaip run aggregate --agent agent-ID` filtra a identidade e retorna duração, ciclos observados, tokens, custo, cobertura e rework. Telemetria não capturada permanece indisponível, nunca zero.
 
-O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado, quota de orçamento e handoff próprios, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
+O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado e handoff próprios; em `autonomy-v1`, o orçamento de recuperação continua no diário estável de cada Task, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
 
 O driver autônomo:
 
-- usa protocolo nativo JSONL de Codex ou Claude, sem shell;
+- usa protocolo nativo JSONL, sem shell. O contrato legado suporta Codex ou Claude;
+  o despacho gerenciado com `autonomy-v1` atualmente exige Codex e rejeita Claude
+  antes de invocar o provider. Conversas diretas continuam disponíveis no provider
+  escolhido; isso não comprova suporte Claude à orquestração autônoma v1;
 - cria worktree Git por Task a partir de uma raiz limpa;
 - limita alterações aos write scopes;
 - exige commit final e valida os artefatos tipados dentro da worktree;
@@ -77,7 +253,7 @@ O driver autônomo:
 - persiste estado com compare-and-swap;
 - serializa somente transições do estado durável e rebaseia cada Task, permitindo que invocações de ramos independentes executem em paralelo com segurança;
 - mantém checkpoints opacos somente em `.local`;
-- limita `lite` a uma tentativa e `standard`/`critical` a no máximo três tentativas de desenvolvimento ou reparo;
+- em `autonomy-v1`, usa exclusivamente os tetos por Task da tabela acima; somente no legado sem esse bloco mantém as quotas antigas por risco;
 - usa verificador independente para critical, SPEC e PRD.
 
 Na Task autônoma, o adapter respeita o mesmo rigor calculado: `lite` não exige
@@ -92,4 +268,9 @@ Ativar `autonomous` não afirma que o runtime está validado em produção. A ma
 
 ## Cobertura e release
 
+Gui também pode registrar bloqueio/falha quando nenhum executor conseguiu iniciar.
+Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
+`executor_missing` rejeita conclusão sem executor elegível ou raiz Task direta
+explicitamente autorizada, mesmo que existam Evidences aprovadas.
+
 O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statements e 75% para branches. Uma medição atual abaixo disso pode ser registrada como baseline observada para diagnóstico, mas o gate continua vermelho. Release crítica também exige unit, E2E, arquitetura, CQRS, módulos, profile, segurança, testes negativos, paridade da distribuição e cleanroom do candidato exato.

package/templates/.agents/zaip-aios/guides/20-instalacao-detalhada.md

@@ -17,12 +17,14 @@ o runtime distribuído. No checkout mantenedor, use o pnpm fixado em
 Na raiz do projeto-alvo:
 
 ```bash
-npx @zaip-ai/cli@latest init --dry-run
-npx @zaip-ai/cli@latest init
+npx --yes @zaip-ai/cli@latest init --project-only --dry-run
+npx --yes @zaip-ai/cli@latest init --project-only
 node .agents/runtime/bin/zaip.mjs doctor --json
 ```
 
-Revise o dry-run antes da instalação. `@latest` seleciona a versão publicada,
+Revise o dry-run antes da instalação. O primeiro sucesso verificável é a saída
+de `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters
+do projeto que recebeu a instalação. `@latest` seleciona a versão publicada,
 não alterações ainda locais neste repositório. O binário público `zaip` é o
 instalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação
 de `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho
@@ -36,10 +38,15 @@ O instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite
 e `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade
 de uma tarefa nem ativam um modelo mais caro.
 
-O default de seleção de modelos é `manual`. O modo `auto` exige opt-in do projeto,
-permanece restrito a SPEC/PRD e mantém Astra como consultor diagnóstico opcional em
-`high`, com teto de três invocações por Task e devolução aos executores.
-Veja o [contrato de modelos e seus limites](23-orquestracao-de-modelos.md).
+Novos templates mantêm a seleção do principal em `manual` e configuram
+`execution.runtime: managed` para PRD/SPEC, com
+`autonomy: { version: 1, preset: balanced }`. São controles diferentes:
+instalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)
+explica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)
+detalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.
+O Essencial nunca usa Astra automático. Principal avulso preserva a seleção
+manual; filhos necessários seguem política divulgada. Projetos e estados legados
+não recebem migração silenciosa de quotas.
 
 ## Construir o CLI
 
@@ -136,8 +143,8 @@ zaip task execute TASK-ID
 Task-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.
 
 Task-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as
-colunas Definição ou Planejamento. Uma Task criada ou preparada, mas não iniciada, aparece em Pronto
-para executar. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados
+colunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto
+para executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados
 antes da primeira mutação. Verificação e evidências sempre refletem registros reais.
 
 Para uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:
@@ -192,20 +199,21 @@ Para coleções grandes, use listagens compactas: `--status`, `--from`, `--to`,
 
 ## Executar e acompanhar a DAG
 
+Consultas de acompanhamento:
+
 ```bash
-zaip execution list
 zaip execution show EXEC-ID
-zaip execution start EXEC-ID
-zaip task next
-zaip task start TASK-ID
-zaip run start --short-name orquestrar-task --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID
-# execute e verifique o trabalho
-zaip run start --short-name finalizar-execution --phase execution --run-purpose finalization --entrypoint task --work-type new --client codex-subagent --agent zaip-agent-finalizer --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --parent RUN-RAIZ-ID --execution EXEC-ID --task TASK-ID --change CHG-ID
-zaip run finish RUN-FINALIZADOR-ID --status completed
-zaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts
+zaip task show TASK-ID
+zaip run show RUN-ID
 zaip run closure RUN-ID
 ```
 
+A execução deve reutilizar a identidade real capturada do turno e seu alvo.
+Não crie um `run start --agent zaip-agent-finalizer` para simular a existência
+de Gui, nem interprete `run finish --status completed` como aprovação.
+O host captura spawn/terminal reais e persiste a decisão observada antes do
+Stop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).
+
 Tasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.
 
 Cada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.

package/templates/.agents/zaip-aios/guides/21-telemetria-monitor-custos.md

@@ -8,7 +8,12 @@ O Monitor de Custos é uma visão financeira da população de Runs de Operaçã
 
 ## Fonte e proveniência
 
-A projeção é **manifest-first**: usa os manifests e registros Git como fonte canônica e a telemetria local apenas para uma reconciliação com correspondência exata. O Dashboard não usa SQLite como fonte de dados do Monitor de Custos.
+Os registros e manifests Git-native são canônicos. No runtime atual, o Monitor
+também consulta o SQLite reconstruível: o resumo recebe agregados compactos,
+enquanto páginas de Runs combinam fatos com manifests canônicos atuais.
+Caminhos de compatibilidade preservam a leitura manifest-first.
+SQLite não é outra fonte de verdade; consulta não autoriza reconciliação
+global nem alteração do histórico.
 
 Tokens, custo e duração devem exibir sua proveniência. Tokens e configuração efetiva de modelo/effort só são observados quando a fonte os informa; defaults planejados não preenchem esses campos. A projeção pode exibir duração `observed`, `reconciled`, `legacy_inferred` ou `estimated`. Apenas `observed` é medição da fonte; as demais são derivadas e não satisfazem um critério que exija duração capturada.
 
@@ -20,9 +25,20 @@ Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual
 
 Não use contagens, totais ou percentuais de auditorias passadas como diagnóstico atual. Consulte o período e os filtros da execução auditada; uma lacuna de coleta continua sendo lacuna, mesmo quando há estimativa ou reconciliação exibida.
 
+Na Visão geral de Tasks, cobertura incompleta produz **Subtotal estimado
+conhecido**, com valor e contagem conhecida/total. Médias de custo por item/hora
+ficam indisponíveis nessa condição para não misturar populações.
+Cobertura completa permite o rótulo **Custo estimado**. Sem soma
+conhecida, o valor continua indisponível; um zero conhecido não é ocultado.
+Esses três estados não equivalem a saldo, fatura ou custo integral do provider.
+
 ## Filtros e totais
 
-Filtros preenchidos somente com data são inclusivos: a data inicial começa em `00:00:00.000Z` e a final termina em `23:59:59.999Z`. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
+Filtros preenchidos somente com data são inclusivos pelo calendário IANA
+`America/Sao_Paulo`: início à meia-noite local e fim imediatamente antes do
+próximo dia local, convertidos para UTC. Considere DST histórico; não fixe
+`-03:00` nem use o dia UTC como substituto. Timestamps explícitos conservam
+seu instante. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
 
 ## Verificação operacional
 

package/templates/.agents/zaip-aios/guides/22-fluxos-e-roteamento.md

@@ -25,7 +25,14 @@ atalho de aprovação: o registro não executa o procedimento, não transforma
 resultado pendente em verde e não dispensa review/finalizador. Consulte o
 [contrato canônico](../../skills/zaip-skill-change/references/observable-evidence.md).
 
-Em PRD/SPEC com `model_orchestration.mode:auto`, trabalho simples e delimitado pode usar Luna/low, execução padrão Terra/medium e ambiguidade, transversalidade ou rework estrutural Sol/high ou xhigh. Conversation e Task-first preservam a seleção manual do host/Codex. Criticidade amplia assurance; não eleva modelo mecanicamente.
+Com `autonomy-v1`, a recuperação segue o preset congelado por Task:
+Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente ilimitado.
+Replanejamentos usam Sol/high primeiro e Astra/high nos seguintes permitidos;
+Astra/high pode executar a partir do terceiro bloco fora do Essencial.
+Principal avulso preserva a seleção manual e prefere trabalho direto;
+delegação necessária informa que filhos podem usar outra configuração.
+Criticidade amplia assurance; não define a quota.
+Veja [autonomia](19-assurance-e-autonomia.md) e [modelos](23-orquestracao-de-modelos.md).
 
 ## Entradas e planejamento
 
@@ -63,7 +70,12 @@ Task em execução → Orchestrator → Executor → Evidence e Decisions
                   → Auditor (quando necessário) → Finalizer → resultado
 ```
 
-O resultado pode ser concluído, bloqueado, falhado, cancelado ou exigir rework. Bloqueio e rework iniciam um novo ciclo controlado; cancelamento é uma decisão humana explícita. O finalizador fecha a Run somente depois da revisão e de qualquer auditoria exigida.
+O resultado pode ser concluído, bloqueado, falhado ou cancelado; rework é uma
+continuação autorizada, não outro estado terminal nem reset do orçamento.
+Sem evidência suficiente, bloqueie; com impedimento técnico comprovado, falhe.
+O host persiste a decisão de Gui e fecha pela CLI. Gui é último filho direto
+do responsável da Task, não de cada trabalhador; não aguarda recibos em loop.
+O controle de quotas depende do despacho gerenciado, não do desenho do fluxo.
 
 ## Lifecycle e operação