@zaip-ai/cli 3.8.0 → 4.1.0

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-CocoP9CA.js → DashboardHelpDialog-DlN5EMmD.js}

@@ -1,19 +1,20 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-zhY2JoLc.js";import{t as r}from"./dashboard-localization-058lag33.js";var i=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-D7PrDZy9.js";import{t as r}from"./dashboard-localization-CF7B1Hjn.js";var i=`# Primeiros passos
 
 1. Leia \`.agents/config/project.yaml\` e \`.agents/rules/core.md\`.
 2. Consulte \`.agents/records/lifecycle/\` para descobrir o estado atual pelos manifests canônicos.
 3. Classifique a entrada: Conversation, Task avulsa, SPEC ou PRD. Pergunta/análise read-only é Conversation e não cria Task.
 4. Carregue somente Rules, Requirements e skills aplicaveis.
 5. Defina aceite verificavel antes de editar.
-6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador; priorize trabalho direto na avulsa, delegue apenas quando necessário e respeite os gates de fechamento vigentes; teste e registre evidências no ciclo ativo.
+6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador. Na v4, Task avulsa usa executor subagente nativo Codex; Conversation read-only não delega. Respeite os gates de fechamento; teste e registre evidências no ciclo ativo.
 
 Evite varrer \`.agents/records/\`: abra um record apenas quando possuir seu ID.
 
-Para PRD/SPEC, diferencie conversa de criação: “me ajude a pensar” não cria artefato; “crie” persiste o pacote \`draft\` completo e sua telemetria. Faça até cinco perguntas críticas por turno, no máximo três turnos; depois registre decisões delegáveis da IA. Tasks reais só nascem em \`ready|execute\`.
+Para PRD/SPEC, diferencie conversa de criação: “me ajude a pensar” não cria artefato; “crie” persiste o pacote \`draft\` completo e sua telemetria. “Crie e execute” pode concluir ambos no mesmo turno Codex com Runs separadas. Faça até cinco perguntas críticas por turno, no máximo três turnos; depois registre decisões delegáveis da IA. Tasks reais só nascem em \`ready|execute\`. Pedido de ação sem macro explícito segue Task avulsa, mesmo se for crítico; recomende macro sem promovê-lo sozinho.
 
 Para os novos controles, leia [perfis de autonomia](19-assurance-e-autonomia.md)
 e [modelos](23-orquestracao-de-modelos.md): perfil não ativa provider nem migra
-Tasks legadas. O principal avulso mantém sua seleção; filhos seguem política divulgada.
+Tasks legadas. O principal avulso mantém sua seleção; o ZAIP define modelo e
+effort dos filhos, que precisam ser observados no host. O [contrato-alvo v4](28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar) ainda não certifica o runtime atual.
 `,a=`# Requirements
 
 Use Requirement para uma obrigacao duravel e testavel.
@@ -48,9 +49,10 @@ Em PRD/SPEC \`draft\`, a lista visível vem dos blueprints do PreparedPlan e nã
 
 ## Modelo, effort e velocidade
 
-Conversation e o principal de Task avulsa preservam a seleção manual do Codex e
-preferem execução direta. Se subagentes forem necessários, informe que modelo e
-esforço podem diferir conforme catálogo/preset ZAIP. A exceção de Astra manual
+Conversation e o principal de Task avulsa preservam a seleção manual do Codex.
+Conversation read-only não usa subagente; toda Task avulsa usa executor
+subagente nativo no contrato-alvo v4, com modelo/effort selecionados pelo
+ZAIP e execução produtiva sequencial. A exceção de Astra manual
 no Essencial só vale para o principal avulso. A seleção automática solicita
 velocidade \`standard\`; Fast manual não é herdado pelo fluxo gerenciado.
 
@@ -58,7 +60,7 @@ velocidade \`standard\`; Fast manual não é herdado pelo fluxo gerenciado.
 
 [Autonomia](19-assurance-e-autonomia.md) é por Task estável: Essencial 4/1,
 Equilibrado 10/3, Persistente ilimitado (execuções/replanejamentos).
-Reiniciar, retomar ou mudar o YAML não zera a quota. \`attempt_count\` do lifecycle
+No Equilibrado, os planos novos usam Sol → Sol → Astra. Reiniciar, retomar ou mudar o YAML não zera a quota. \`attempt_count\` do lifecycle
 e reservas de execução do diário não são o mesmo contador.
 Falta de prova termina \`blocked\`; erro técnico impeditivo comprovado termina
 \`failed\`. Não diminua ACs nem use duração como critério de desistência.
@@ -75,7 +77,7 @@ Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
 7. Mapeie cada Requirement para Tasks e evidencias.
 8. Valide a SPEC antes de iniciar execucao; bloqueie stack ausente, divergente ou sem versoes exatas e fontes existentes.
 9. Ao iniciar a primeira Task, mantenha a SPEC em Execucao entre todas as Runs filhas; resultado terminal de uma Task nao terminaliza a SPEC.
-10. Depois de todas as Tasks concluidas, rode verificacao e Evidence parentais antes de deliver.
+10. Feche todas as Tasks da DAG, inclusive dependentes inviabilizadas, antes de decidir o status parental; somente com todas concluídas rode verificação e Evidence parentais para \`deliver\`.
 
 Uma SPEC planeja a entrega; nao autoriza mudancas externas por si so.
 
@@ -93,6 +95,9 @@ filho direto. Gates parentais continuam separados.
 
 Se um nó ficar bloqueado/falhado, continue somente ramos independentes
 elegíveis; não repita nós concluídos nem libere dependentes sem conclusão.
+Ao encerrar a rodada macro, dependentes impossíveis recebem bloqueio terminal
+com causa, não permanecem \`planned\` indefinidamente. Só Tasks de DAG
+planejada com escopos independentes podem paralelizar.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.
 `,c=`# PRDs
@@ -107,16 +112,17 @@ Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
 6. Relacione riscos, rollout, observabilidade e rollback.
 7. Monte a DAG e confirme que todo aceite possui evidencia planejada.
 8. Mantenha PRD e SPECs selecionadas em Execucao enquanto restar trabalho; Runs filhas fecham Tasks, nao o macro.
-9. Conclua somente depois das Tasks, integracao, outcomes e gates parentais.
+9. Decida status terminal somente depois de todas as Tasks da DAG terminarem, inclusive dependentes inviabilizadas; entregue apenas com todas concluídas, integração, outcomes e gates parentais.
 
 ## Intenções
 
 - “Me ajude a pensar sobre um PRD”: Conversation, sem artefato.
 - “Crie um PRD”: até cinco perguntas críticas por turno e no máximo três turnos; depois persiste PRD, SPECs e PreparedPlan \`draft\`, vincula a Run e o \`creation_run_id\` ao macro e não cria Tasks reais. Duração, tokens e custo só são agregados quando observados ou reconciliados.
+- “Crie e execute um PRD”: no mesmo turno Codex, crie o macro em uma Run de definição e execute a DAG em outra Run de delivery vinculada; não converta a primeira em execução.
 - “Deixe pronto para executar” ou “finalize/conclua esse PRD” em \`draft\`: lapida, valida e materializa SPECs/Tasks/Changes/Execution como \`ready|planned\`, sem executar.
 - “Execute esse PRD”: executa todas as SPECs selecionadas. Pedido dirigido a SPEC ou Task usa o menor grão.
-- “Implemente”: sem alvo abre apenas uma Conversation de planejamento; em \`draft\` finaliza o plano; em \`ready\` executa; em \`active|blocked|failed\` continua, retoma ou cria rework.
-- “Desenvolva/melhore/aprimore”: sempre planeja/refina/rework e nunca executa automaticamente.
+- “Implemente”: sem PRD/SPEC explicitamente solicitado, trate o objetivo de ação como Task avulsa; macro \`draft\` só executa com intenção explícita de executar aquele macro; em \`ready\` executa; em \`active|blocked|failed\` continua, retoma ou cria rework.
+- “Desenvolva/melhore/aprimore”: preserve a intenção e o alvo; mudança independente explicitamente pedida executa como Task avulsa, enquanto mero planejamento/refino não promove o macro.
 
 PRD cancelado permanece imutável. Novo planejamento cria sucessor \`draft\`, tag \`rework\` e \`rework_of_prd_id\`.
 
@@ -144,6 +150,9 @@ filho direto. Gates parentais continuam separados.
 
 Se um nó ficar bloqueado/falhado, continue somente ramos independentes
 elegíveis; não repita nós concluídos nem libere dependentes sem conclusão.
+Antes de decidir o status do PRD, feche com causa os dependentes
+inviabilizados e confirme todos os resultados terminais; nunca entregue por
+sucesso isolado de um ramo. Paralelismo exige DAG e escopos independentes.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.
 `,l=`# Execucao
@@ -170,12 +179,14 @@ Quando a entrega requer observação, siga o contrato de
 o registro descreve o resultado declarado e seus limites, mas não executa o
 procedimento nem aprova o AC sozinho.
 
-\`execute\` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” volta a planejamento/rework e exige nova promoção.
+\`execute\` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” com ação independente segue Task avulsa; quando o pedido é só refinar macro, não o promove.
 
 ## Modelo, effort e velocidade por origem
 
-- Conversation e o principal avulso preservam a seleção manual. Ao delegar por
-  necessidade, avise que modelo/esforço dos filhos podem mudar pela política ZAIP.
+- Conversation e o principal avulso preservam a seleção manual. Conversation
+  read-only não delega; Task avulsa usa subagente nativo Codex no alvo v4. O
+  ZAIP escolhe modelo/esforço de cada filho e bloqueia se o host não puder
+  atender à configuração exigida. Não paralelize trabalho produtivo avulso.
 - Fast para execução de produto é suportado somente em Task-first realmente independente e deve ser selecionado manualmente no Codex.
 - Executions originadas por SPEC ou PRD usam sempre velocidade \`standard\`, inclusive em todas as Tasks, Runs e Sub-Runs descendentes.
 - O ZAIP não ativa, persiste ou herda Fast por skill, hook, PreparedPlan ou override de Execution.
@@ -187,7 +198,10 @@ Aplique o diário e o preset do [guia 19](19-assurance-e-autonomia.md) antes
 do despacho gerenciado. Não gere tentativas por tempo nem reexecute gates
 caros inalterados para preencher uma cota.
 
-O host persiste a decisão real do Gui antes do Stop canônico e aplica a mesma
+No Equilibrado v4, reserve no máximo três replans reais por Task: Sol/high,
+Sol/high e Astra/high. A tentativa atual deve terminar em estado terminal;
+o fechamento direcionado pode ser recuperado no próximo evento Codex, sem
+prometer execução após o host parar. O host persiste a decisão real do Gui antes do Stop canônico e aplica a mesma
 decisão no fechamento. Gui read-only pode retornar sem aguardar recibos;
 o relay aceita filho já terminal enquanto o responsável estiver aberto.
 Sem decisão, preserve a pendência; não infira aprovação do status nativo.
@@ -293,15 +307,19 @@ coordena um responsável por tentativa de Task e seus gates parentais próprios.
 - Centralize decisoes arquiteturais e integracao no responsavel adequado.
 - Exija caminhos de evidencia e resultados de comandos, nao declaracoes de
   conclusao.
-- Use paralelismo apenas quando reduzir o caminho critico sem elevar conflito.
+- Use paralelismo produtivo apenas em DAG de PRD/SPEC planejada com Tasks
+  independentes e write scopes/recursos compatíveis; Task avulsa é sequencial.
 - Escale bloqueios de autoridade, credencial, seguranca ou escopo; nao suponha
   permissao externa.
 
-Tarefas avulsas preferem execução direta; quando delegar for necessário, informe
-que filhos podem usar modelo/esforço diferentes da seleção manual do principal.
+No contrato-alvo v4, toda Task avulsa delega execução a um subagente nativo
+Codex. O ZAIP escolhe modelo/esforço dos filhos, que podem diferir da seleção
+manual do principal. Se o host não puder aplicar/confirmar a configuração,
+bloqueie com causa; não substitua por chat independente nem por executor
+cerimonial.
 [Essencial nunca escala automaticamente para Astra](23-orquestracao-de-modelos.md).
-A exigência canônica atual de executor elegível para delivery permanece:
-preferência por execução direta não permite inventar captura para aprovar gates.
+A exigência de executor elegível para delivery permanece: não invente captura
+para aprovar gates. Execução direta é somente compatibilidade legada.
 `,p=`# Segurança dos perfis Codex ZAIP-AIOS
 
 ## Visão geral
@@ -568,6 +586,12 @@ Run é o envelope da chamada do \`zaip-agent-orchestrator\`; \`parent_run_id\` n
 
 A criação explícita de PRD/SPEC vincula a Run de definição e o \`creation_run_id\` ao macro. Duração, tokens e custo aparecem no PRD/SPEC antes de existirem Tasks somente quando houver fonte capturada ou derivação identificada por proveniência. Um valor \`estimated\`, \`legacy_inferred\` ou \`reconciled\` não é dado observado e não comprova medição da chamada. Quando duração, tokens ou custo não foram capturados, eles permanecem explicitamente indisponíveis (\`null\`/\`unavailable\`); nunca atribua telemetria ausente nem transforme ausência em zero. Pensar sem criar permanece apenas em Conversas.
 
+No contrato visual da v4, a **interface** do Dashboard mostra \`0\` em cards e
+células numéricas depois de carregar, inclusive para valor canônico \`null\`,
+sem exibir “Indisponível” nesses lugares. Cobertura e tooltip distinguem
+“sem medição” de zero observado; skeleton representa loading. API, records,
+exportações e contas preservam \`null\`/cobertura, sem somar esse zero visual.
+
 ## Contagem de autonomia e consultas compactas
 
 ### Leitura dos números do Dashboard
@@ -588,7 +612,8 @@ descrição acessível explicam a quantidade de Runs precificadas e a cobertura.
 O subtítulo apresenta taxas estimadas de alocação: subtotal conhecido dividido pelo
 número de tarefas e pelas horas registradas do mesmo recorte. Isso não estima os
 custos faltantes nem representa a média de custos completos das tarefas. Cada
-denominador indisponível ou zero deixa apenas sua taxa como \`—\`. Não completar
+denominador indisponível ou zero deixa a taxa canônica sem valor; a UI v4
+mostra \`0\` com indicação “sem medição” quando for ausência. Não completar
 as Runs desconhecidas com zero nem apresentar o subtotal como gasto integral.
 Um subtotal observado igual a zero é diferente de ausência total de medição.
 SPECs/PRDs usam seus agregados próprios, não recebem o subtotal global de Tasks.
@@ -599,7 +624,8 @@ provedor normaliza aliases de Codex tanto na atividade quanto nos segmentos de
 uso; isso não altera identidade nem preços nos registros canônicos.
 
 Enquanto uma consulta de médias está pendente, a interface mostra carregamento,
-não zero. Zero observado, ausência de captura e carregamento são estados distintos.
+não zero. Depois da resposta, zero observado e ausência de captura mostram o
+mesmo numeral \`0\`, mas são estados distintos pela cobertura.
 A validação deve comparar API, linhas, rodapé e exportação no mesmo período,
 moeda e filtro. Um processo saudável não comprova que o snapshot foi atualizado;
 confirme também a revisão, a data da fonte e o estado da projeção.
@@ -667,18 +693,23 @@ Os manuais instalados ficam em \`.agents/README.md\` (português) e
 Os READMEs da raiz pertencem ao projeto consumidor e são preservados.
 As versões geradas em \`public-cli/packages/cli/templates\` vêm das fontes canônicas.
 
-Novos templates mantêm a seleção do principal em \`manual\` e configuram
-\`execution.runtime: managed\` para PRD/SPEC, com
+O candidato local v4 mantém a seleção do principal em \`manual\` e configura
+\`execution.runtime: codex_native\` para PRD/SPEC e Tasks avulsas, 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
+detalha a rota v4 Sol/high → Sol/high → Astra/high e sua execução elegível no
+terceiro bloco. Schema e template v4 já aceitam Codex-native; o TGZ e a
+execução real no host ainda exigem qualificação antes da publicação. O Essencial
+nunca usa Astra automático. Principal avulso preserva a seleção manual; filhos
+seguem a seleção ZAIP validada no host. Projetos e estados legados
 não recebem migração silenciosa de quotas.
 
 \`@latest\` entrega o que está publicado no npm. Uma atualização local das fontes ou
 um pacote validado localmente só chegará a esse comando após publicação.
+Na v4, a instalação limpa e a atualização devem comprovar \`doctor\`, adapters,
+preservação do conteúdo do consumidor e execução Codex-native por Task antes
+de se anunciar esse padrão como funcional.
 Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 [qualificação do pacote](26-qualidade-e-release.md).
 `,g=`# Boas praticas
@@ -696,14 +727,25 @@ Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 - Em delivery/interação delegada, use Gui como último filho do responsável e
   concilie a Task; conversa read-only sem filhos não precisa desse circuito.
 - Nao terminalize SPEC/PRD por causa do resultado isolado de uma Task filha.
-- Prefira reconciliacao manual sob demanda; hooks de escrita fazem checagem local sem varredura global.
+- Reconciliação global permanece manual; no alvo v4, concilie a tentativa
+  atual no fechamento/Stop observado ou no próximo evento Codex idempotente,
+  sem varredura global ou promessa de execução após o host parar.
 - Use uma SPEC por padrão; divida somente capacidades realmente independentes e paralelizáveis.
+- Task avulsa usa subagente Codex e execução produtiva sequencial; só uma DAG
+  de PRD/SPEC pode paralelizar Tasks independentes.
+- “Crie” PRD/SPEC fica \`draft\`; “crie e execute” pode avançar no mesmo turno,
+  com Runs separadas de definição e delivery.
+- A fila horária, quando instalada a pedido, seleciona um único macro/Task
+  superior \`ready\`, com prioridade PRD → SPEC independente → Task avulsa e
+  ordenação manual dentro da classe.
 - Não crie Tasks durante definição: mostre blueprints compactos e materialize somente em \`ready|execute\`.
 - Resolva verbos de lifecycle pelo alvo e status persistido, nunca por palavra isolada.
 
 - Prefira uma investigação útil a repetir a mesma hipótese; conte reservas reais
   pelo preset da Task, não por duração ou quantidade de testes.
 - Não transforme tempo decorrido em falha nem incompletude em aprovação.
+- Após o loading, cards/tabelas numéricas mostram \`0\` para métrica ausente,
+  com cobertura “sem medição”; records e API preservam \`null\`.
 - Preserve o diário de autonomia; ele não é cache. Veja [guia 19](19-assurance-e-autonomia.md).
 `,_=`# Troubleshooting
 
@@ -714,7 +756,7 @@ Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 5. Compare \`manifest.json\`, \`summary.json\`, índices e chunks de \`records/lifecycle\`, sem varrer records.
 6. Corrija a causa, repita a reproducao e depois os gates completos.
 
-Se uma Task estiver presa em executing/verifying, use o popup Reconciliar. O reparo aceita \`task_complete\` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. Nao habilite reconciliacao automatica por turno ou na abertura do dashboard.
+Se uma Task estiver presa em executing/verifying, use o popup Reconciliar para o backlog global. O reparo aceita \`task_complete\` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. A v4 deve conciliar a tentativa **atual** no fechamento ou próximo evento Codex da mesma Task, sem varredura global automática na abertura do dashboard. Se o host parou e não houve novo evento, relate a pendência em vez de dizer que ela ainda está executando.
 
 Se o problema for de instalacao ou integridade, consulte \`framework.lock.yaml\`.
 
@@ -728,6 +770,8 @@ Se “finalizar” tentou entregar um PRD \`draft\`, confira adapters/skills: o
 | \`RECOVERY_PENDING\` | Localize a reserva e resultado real; não despache outra invocação nem apague o diário |
 | \`ATTEMPT_BUDGET_EXHAUSTED\` / \`REPLAN_BUDGET_EXHAUSTED\` | Confira o preset congelado e consumo; registre o resultado parcial sem reset |
 | \`REPLAN_INCOMPLETE\` | Plano inválido não libera reparação; preserve a reserva consumida |
+| Segundo replan escalou para Astra no Equilibrado v4 | Divergência de política: a rota aprovada é Sol → Sol → Astra; confira ledger, catálogo e modelo observado |
+| Perfil nativo não suporta modelo/effort exigido | Bloqueie com causa; não substitua silenciosamente nem conclua por prompt |
 | Gui terminou sem recibo de início | Capture o evento real e use relay suportado com responsável aberto; não invente decisão |
 | Responsável já fechado sem decisão | Recuperação autorizada/nova tentativa; reconciliação repetida não cria aprovação |
 | Perfil Essencial tentou Astra automático | Rejeite a seleção; não trate fallback/herança como autorização |
@@ -746,7 +790,7 @@ falha do produto. Veja [autonomia](19-assurance-e-autonomia.md) e
 - SPEC: planejamento tecnico de multiplas Tasks; draft fica em Planejamento.
 - PRD: definicao de produto; draft fica em Definicao.
 
-Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro, SPECs e PreparedPlan \`draft\`, atribui telemetria e mantém apenas blueprints de Tasks. \`ready\` é o único ponto que materializa Tasks/Changes/Execution sem iniciar; \`execute\` materializa e inicia.
+Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro, SPECs e PreparedPlan \`draft\`, atribui telemetria e mantém apenas blueprints de Tasks. \`ready\` materializa Tasks/Changes/Execution sem iniciar; \`execute\` materializa e inicia. “Crie e execute” cabe no mesmo turno Codex com Runs canônicas separadas de definição (\`interaction\`) e delivery, ligadas pelo alvo; criar isoladamente não promove a \`ready\`.
 
 ## Colunas
 
@@ -782,9 +826,12 @@ Gui ainda pode registrar bloqueio/falha real, mas \`executor_missing\` impede
 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
+## Execução direta legada autorizada
 
-A Task avulsa prefere o principal direto. O host registra a referência humana
+A Task avulsa do contrato legado preferia o principal direto. A v4
+substitui essa preferência por executor subagente nativo observado para toda
+Task avulsa, com orquestração sequencial. Enquanto o caminho legado existir,
+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
@@ -797,11 +844,11 @@ 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\`.
+\`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; na v4, \`desenvolva|melhore|aprimore\` com objetivo independente de ação seguem Task avulsa, enquanto pedidos de refinamento do macro permanecem em planejamento/rework. PRD cancelado gera sucessor vinculado com tag \`rework\`.
 
 ## SPEC e PRD
 
-Ao iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai. Depois que todas as Tasks concluem, SPEC/PRD entram em verificacao parental; apenas gates de integracao, Acceptance Criteria, outcomes e Evidence entregam o macro.
+Ao iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai enquanto ramos independentes continuam. Antes de fechar SPEC/PRD, **todas** as Tasks da DAG, inclusive dependentes inviabilizadas, precisam de resultado terminal persistido. Só o conjunto concluído entra em verificação para entrega; bloqueios/falhas produzem decisão parental verdadeira depois do fechamento das filhas. Gates de integração, Acceptance Criteria, outcomes e Evidence continuam obrigatórios para \`delivered\`.
 
 Observações declaradas seguem o contrato de
 [prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
@@ -811,7 +858,7 @@ Novas SPECs de um PRD não possuem dependências entre si: são capacidades para
 
 ## Reconciliacao
 
-O popup Reconciliar chama \`run reconcile --open\` somente depois da confirmacao humana. Nao existe varredura ao abrir o dashboard, por turno ou por intervalo.
+O popup Reconciliar chama \`run reconcile --open\` somente depois da confirmacao humana. Nao existe varredura **global** ao abrir o dashboard, por turno ou por intervalo. O contrato-alvo v4 acrescenta conciliação idempotente **direcionada à tentativa atual** no Stop/fechamento observado ou no próximo evento Codex da mesma Task. Nenhum hook continua rodando após o host parar; não alegue recuperação invisível.
 
 O reparo e idempotente: \`task_complete\` local exato permite tentar conclusao; gate insuficiente usa blocked; Run sem invocacao ativa por dez minutos usa failed; cancelled nunca e inferido. Projecoes exibem o status persistido e nao revivem Task terminal por atividade local obsoleta.
 
@@ -844,7 +891,9 @@ A CLI autentica vínculos e persiste a decisão imutável antes do Stop canônic
 - 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,
+A política legada preferia Task avulsa direta, mas a v4 Codex-native passa a
+exigir executor subagente nativo em trabalho novo. Para compatibilidade antiga,
+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.
@@ -871,7 +920,7 @@ O modelo e o tier de serviço efetivamente observados, quando disponíveis, defi
 | Cache | \`cache / 1.000.000 × tarifa de cache\` |
 | Output | \`output / 1.000.000 × tarifa de output\` |
 
-O dashboard soma esses componentes uma única vez. Quando a identidade do modelo/tier, os tokens necessários ou uma tarifa do catálogo versionado não existem, o custo permanece indisponível em vez de ser inventado.
+O dashboard soma esses componentes uma única vez. Quando a identidade do modelo/tier, os tokens necessários ou uma tarifa do catálogo versionado não existem, o custo canônico permanece \`null\` em vez de ser inventado. No contrato visual v4, card/célula carregado mostra \`0\` com cobertura “sem medição”; esse numeral não entra na soma.
 
 ## 3. Considere contexto, velocidade e esforço
 
@@ -882,11 +931,11 @@ O esforço não possui multiplicador direto de preço. Ele só pode aumentar o c
 ## 4. Converta para a moeda selecionada
 
 O total da chamada é calculado primeiro em USD. Em BRL, a estimativa exige uma cotação identificada; a cotação histórica registrada e a cotação corrente são fontes distintas. Mudar a moeda de exibição nunca altera a telemetria de tokens nem o cálculo em USD.
-`,x='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO orquestrador mantém a Run raiz e cada Run delegada separadas na observabilidade. Duração, tokens e custo só são agregados quando observados ou reconciliados; ausência continua indisponível, nunca zero.\n\nO dispatch autônomo passa os `Task.write_scopes` a essa seleção **por Task** e persiste o builder escolhido na entrada de cada Task. Assim uma DAG com frontend e backend usa Doug e Will nas respectivas invocações, sem transformar a seleção de uma Task em builder global. A seleção é determinística, mas não concede autoridade: o agente ainda precisa respeitar seus write scopes e permissões do catálogo.\n\nO `budget.soft_cycles` também acompanha o agente selecionado por Task e governa seu checkpoint suave. Tokens continuam observados para telemetria e custo, mas não interrompem nem exigem checkpoint. Para comparar agentes, use `zaip run aggregate --agent agent-ID`; o resultado inclui duração coberta, ciclos de uso observados, tokens, custo, cobertura e Runs de rework.\n\nNanda (`agent-reviewer`) usa `gpt-6-sol` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) usa `gpt-6-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) usa `gpt-6-sol`/`high` para auditoria de segurança explícita.\n\n## Dashboard e segurança operacional\n\nA 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.\n\n## Preset e configuração efetivamente executada\n\nDefaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,\no preset e a seleção final do despacho gerenciado também são validados:\nEssencial veda Astra automático e não herda a exceção manual do principal.\nInforme ao usuário a delegação necessária e a possibilidade de modelos\ndiferentes. Mantenha indisponível o que o host não informou.\nConsulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).\n',S=`# Assurance adaptativa e perfis de autonomia
+`,x='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO orquestrador mantém a Run raiz e cada Run delegada separadas na observabilidade. Duração, tokens e custo só são agregados quando observados ou reconciliados; ausência continua indisponível, nunca zero.\n\nNa v4, isso continua verdadeiro para records, API e cálculos. Apenas os\ncards/células numéricas do Dashboard carregado exibem `0` com cobertura\n“sem medição”; o catálogo não autoriza registrar zero observado fictício.\n\nO dispatch autônomo passa os `Task.write_scopes` a essa seleção **por Task** e persiste o builder escolhido na entrada de cada Task. Assim uma DAG com frontend e backend usa Doug e Will nas respectivas invocações, sem transformar a seleção de uma Task em builder global. A seleção é determinística, mas não concede autoridade: o agente ainda precisa respeitar seus write scopes e permissões do catálogo.\n\nO `budget.soft_cycles` também acompanha o agente selecionado por Task e governa seu checkpoint suave. Tokens continuam observados para telemetria e custo, mas não interrompem nem exigem checkpoint. Para comparar agentes, use `zaip run aggregate --agent agent-ID`; o resultado inclui duração coberta, ciclos de uso observados, tokens, custo, cobertura e Runs de rework.\n\nNanda (`agent-reviewer`) usa `gpt-6-sol` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) usa `gpt-6-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) usa `gpt-6-sol`/`high` para auditoria de segurança explícita.\n\n## Dashboard e segurança operacional\n\nA 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.\n\n## Preset e configuração efetivamente executada\n\nDefaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,\no preset e a seleção final do despacho gerenciado também são validados:\nEssencial veda Astra automático e não herda a exceção manual do principal.\nInforme ao usuário a delegação necessária e a possibilidade de modelos\ndiferentes. Mantenha indisponível o que o host não informou.\nConsulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).\n',S=`# Assurance adaptativa e perfis de autonomia
 
-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.
+Este guia descreve \`autonomy-v1\` existente e o contrato-alvo Codex-native da
+v4. A rota nova abaixo ainda precisa de implementação, qualificação do pacote
+e prova no consumidor; não a atribua automaticamente a \`@latest\`.
 
 ## Quatro configurações independentes
 
@@ -906,8 +955,8 @@ não concede permissão externa.
 | 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 |
+| Equilibrado (\`balanced\`, padrão v4) | **10**: 1 inicial + 9 reparações | **3** | Sol/high → Sol/high → Astra/high |
+| Persistente (\`persistent\`, opt-in) | **Sem teto** | **Sem teto** | Sol/high nos dois primeiros; Astra/high no terceiro e 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,
@@ -918,7 +967,7 @@ 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.
+3. Replanejamento 2 com Sol/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
@@ -978,14 +1027,16 @@ Não é cache descartável nem deve ser removido para liberar uma nova tentativa
 
 ## 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.
+A Task avulsa usa subagentes nativos Codex no contrato-alvo v4. O principal
+preserva a escolha manual do usuário; o ZAIP define modelo/esforço dos filhos
+por papel/fase/risco. Exemplo: Astra/ultra manual no principal não é uma
+escalada automática para os filhos. No Essencial não há Astra automático,
+inclusive por 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
+Use o menor conjunto de filhos que cubra execução, revisão aplicável e
+finalização; não faça paralelismo produtivo na avulsa. 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.
 
@@ -1020,8 +1071,10 @@ 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
+O candidato local v4 usa Equilibrado e \`execution.runtime: codex_native\`:
+o Codex é responsável pelos Sub-Runs de PRDs, SPECs e avulsas. O npm
+publicado anteriormente conserva o contrato de sua versão até nova publicação.
+\`manual\` e
 configuração legada ausente continuam sem provider. \`autonomous\` permite
 também Task avulsa gerenciada por comando explícito. Salvar não executa.
 
@@ -1158,13 +1211,13 @@ Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
 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.
-`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- permissões de escrita no repositório consumidor.\n\nGit, identidade de autor, repositório, commit inicial e configuração do GitHub\npodem ser preparados depois da instalação. O runtime exige Git e histórico local\nantes de iniciar entregas; essa exigência não bloqueia `init`.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Resumo e próximos passos\n\nA resposta final do assistente mantém a frase inicial com o comando, a linha\n“Resumo:”, bullets e exatamente uma pergunta no final. Siga o modelo obrigatório\nde `.agents/skills/zaip-skill-setup/SKILL.md`, inclusive quando a instalação começou\nantes de as skills estarem disponíveis. Não converta o resumo em parágrafos.\nA versão instalada usa o rótulo `vVERSÃO` com link para sua página no npm,\ncontagens reais de arquivos e resultados de SQLite e `doctor`. O link usa\n`https://www.npmjs.com/package/@zaip-ai/cli/v/<versão-instalada>`.\n\nQuando o GitHub ainda precisa de configuração, a última pergunta é:\n**Deseja ajuda para configurar seu repositório Git?**\nSe a configuração local já estiver identificada, a pergunta será:\n**Deseja ajuda para realizar a configuração inicial do ZAIP-AIOS?**\nConfiguração local não comprova autenticação remota.\n\nNo terminal, a pergunta é textual: o comando encerra normalmente. No chat,\nresponder “sim” encaminha à skill de GitHub ou de configuração do projeto.\nA skill apresenta o que pode configurar e coleta as escolhas antes de editar.\nConcluído o GitHub, oferece a configuração do projeto; concluído o projeto,\nencerra o onboarding. Uma recusa ou adiamento encerra a oferta sem insistência.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nNovos templates mantêm a seleção do principal em `manual` e configuram\n`execution.runtime: managed` para PRD/SPEC, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.\nO Essencial nunca usa Astra automático. Principal avulso preserva a seleção\nmanual; filhos necessários seguem política divulgada. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e os wrappers de skills dos clientes, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-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`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. `implemente` sem alvo abre apenas uma Conversation de planejamento, em `draft` finaliza o plano, em `ready` executa e em estados ativos/falhos continua, retoma ou cria rework. `desenvolva|melhore|aprimore` nunca executa automaticamente. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `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.\n\nCada 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.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --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\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
+`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- permissões de escrita no repositório consumidor.\n\nGit, identidade de autor, repositório, commit inicial e configuração do GitHub\npodem ser preparados depois da instalação. O runtime exige Git e histórico local\nantes de iniciar entregas; essa exigência não bloqueia `init`.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Resumo e próximos passos\n\nA resposta final do assistente mantém a frase inicial com o comando, a linha\n“Resumo:”, bullets e exatamente uma pergunta no final. Siga o modelo obrigatório\nde `.agents/skills/zaip-skill-setup/SKILL.md`, inclusive quando a instalação começou\nantes de as skills estarem disponíveis. Não converta o resumo em parágrafos.\nA versão instalada usa o rótulo `vVERSÃO` com link para sua página no npm,\ncontagens reais de arquivos e resultados de SQLite e `doctor`. O link usa\n`https://www.npmjs.com/package/@zaip-ai/cli/v/<versão-instalada>`.\n\nQuando o GitHub ainda precisa de configuração, a última pergunta é:\n**Deseja ajuda para configurar seu repositório Git?**\nSe a configuração local já estiver identificada, a pergunta será:\n**Deseja ajuda para realizar a configuração inicial do ZAIP-AIOS?**\nConfiguração local não comprova autenticação remota.\n\nNo terminal, a pergunta é textual: o comando encerra normalmente. No chat,\nresponder “sim” encaminha à skill de GitHub ou de configuração do projeto.\nA skill apresenta o que pode configurar e coleta as escolhas antes de editar.\nConcluído o GitHub, oferece a configuração do projeto; concluído o projeto,\nencerra o onboarding. Uma recusa ou adiamento encerra a oferta sem insistência.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nO candidato local v4 mantém a seleção do principal em `manual` e configura\n`execution.runtime: codex_native` para PRD/SPEC e Tasks avulsas, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha o alvo v4 Sol/high → Sol/high → Astra/high e execução elegível no\nterceiro bloco. Schema e template v4 já adotam Codex-native como padrão;\nadapters, pacote real e host ainda devem ser qualificados. O Essencial nunca usa Astra\nautomático. Principal avulso preserva a seleção manual; filhos seguem a\npolítica ZAIP verificada no host. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e os wrappers de skills dos clientes, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-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`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. No alvo v4, pedido de ação como “implemente” sem PRD/SPEC explícito vira Task avulsa; menção genérica ao macro não autoriza criá-lo. Em `draft`, PRD/SPEC só executa quando essa intenção for explícita; “crie e execute” usa a mesma sessão/turno Codex, mas Runs separadas de definição e delivery. Em `ready` executa; em estados ativos/falhos continua, retoma ou cria rework. “Desenvolva/melhore/aprimore” preserva a intenção: ação independente é Task, mero refinamento mantém draft. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo **somente em PRD/SPEC com DAG planejada**. Task avulsa é sequencial. 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.\n\nCada 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.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --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\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência. A v4\nacrescenta recuperação idempotente apenas da tentativa atual no fechamento ou\nno próximo evento Codex observável; não mantém agente rodando após o host parar.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
 
 Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
 
 ## Escopo
 
-O Monitor de Custos é uma visão financeira da população de Runs de Operação. Cada linha preserva a disponibilidade de suas métricas: tokens sem captura, custo sem componentes/tarifa/câmbio suficientes e duração sem fonte permanecem indisponíveis; não são convertidos em \`0\` nem removidos para produzir uma cobertura artificial. A elegibilidade de uma estimativa de custo exige tokens e identidade de preço verificáveis, mas uma Run de lifecycle não precisa ter chamada LLM para continuar visível com lacunas explícitas.
+O Monitor de Custos é uma visão financeira da população de Runs de Operação. Cada linha preserva a disponibilidade **canônica** de suas métricas: tokens sem captura, custo sem componentes/tarifa/câmbio suficientes e duração sem fonte permanecem \`null\`; não são convertidos em \`0\` na API, exportação ou cálculo nem removidos para produzir cobertura artificial. Na UI v4, cards/células numéricas carregados exibem \`0\` com cobertura “sem medição”, jamais o texto “Indisponível”; loading usa skeleton. A elegibilidade de uma estimativa de custo exige tokens e identidade de preço verificáveis, mas uma Run de lifecycle não precisa ter chamada LLM para continuar visível com lacunas explícitas.
 
 ## Fonte e proveniência
 
@@ -1181,7 +1234,7 @@ Tokens, custo e duração devem exibir sua proveniência. Tokens e configuraçã
 
 Cobertura é calculada por métrica e pelo conjunto filtrado. \`100%\` para tokens, custo ou duração só significa que aquela métrica está completa segundo sua definição e proveniência declarada; não demonstra automaticamente que as outras estão completas ou que a duração foi observada. Recalcule a cobertura após qualquer mudança de critério e não reutilize uma auditoria anterior como prova do conjunto novo.
 
-Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual usam o mesmo conjunto filtrado da tabela e preservam as lacunas de cada métrica. Um agente configurado sem invocações no período é um agregado vazio real e exibe zero. Duração ausente exibe \`Indisponível\`; uma duração derivada deve mostrar sua proveniência e não ser lida como captura.
+Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual usam o mesmo conjunto filtrado da tabela e preservam as lacunas de cada métrica. Um agente configurado sem invocações no período é um agregado vazio real e exibe zero. Duração ausente exibe \`0\` na UI v4 com marca de ausência, mas permanece \`null\` na fonte; uma duração derivada deve mostrar sua proveniência e não ser lida como captura.
 
 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.
 
@@ -1189,7 +1242,8 @@ 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.
+conhecida, o valor canônico continua \`null\`; a UI v4 mostra \`0\` e cobertura
+“sem medição”. Um zero conhecido não é ocultado e tem cobertura distinta.
 Esses três estados não equivalem a saldo, fatura ou custo integral do provider.
 
 ## Filtros e totais
@@ -1249,19 +1303,21 @@ resultado pendente em verde e não dispensa review/finalizador. Consulte o
 
 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;
+No contrato-alvo v4, replanejamentos usam Sol/high nos dois primeiros e
+Astra/high no terceiro e 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.
+Principal avulso preserva a seleção manual, mas delega a execução a
+subagente nativo Codex escolhido pelo ZAIP; Conversation não delega.
+Task avulsa não paraleliza. 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
 
 \`\`\`text
-Pergunta simples → resposta direta       Análise especializada → Interaction
-Mudança delimitada → Task-first          Problema de produto → PRD
-Definição técnica → SPEC                 Continuação → retomar foco
+Pergunta simples → resposta direta       Análise read-only → Interaction
+Mudança delimitada → Task-first          PRD pedido explicitamente → PRD draft
+SPEC pedida explicitamente → SPEC draft  Continuação → retomar foco
 Falha ou achado → rework                 Auditoria → audit
 Deploy ou push → Git-only
 \`\`\`
@@ -1301,7 +1357,7 @@ O controle de quotas depende do despacho gerenciado, não do desenho do fluxo.
 
 ## Lifecycle e operação
 
-O caminho de sucesso é Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído. Bloqueado, Falhado e Cancelado são saídas alternativas. Conversation usa uma Execution \`interaction\`; Task direta inicia imediatamente; Task preparada espera \`execute\`; SPEC coordena Tasks; PRD coordena SPECs selecionadas.
+O caminho de sucesso é Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído. Bloqueado, Falhado e Cancelado são saídas alternativas. Conversation usa uma Execution \`interaction\`; Task avulsa pedida para executar inicia com subagentes Codex no alvo v4; Task preparada espera \`execute\`; SPEC coordena Tasks; PRD coordena SPECs selecionadas. Criação explícita de macro permanece \`draft\`, salvo \`ready\`/\`execute\` também pedidos; criar e executar no mesmo turno usa Runs separadas.
 
 ![Lifecycles de Task, SPEC e PRD](assets/diagrams/lifecycles-task-spec-prd.png)
 
@@ -1312,7 +1368,8 @@ Para os contratos completos e comandos de lifecycle, consulte [28-lifecycle-comp
 
 A política busca resolver a entrega com prova suficiente e reduzir retrabalho,
 sem economia acima da qualidade nem persistência ilimitada por padrão.
-Este guia descreve as fontes em preparação para a v3, não uma release publicada.
+Este guia distingue o comportamento distribuído da política aprovada para a
+v4. A revisão documental não é release nem prova do despacho Codex-native.
 O [guia 19](19-assurance-e-autonomia.md) contém configuração, contagem e limites
 de \`autonomy-v1\`. A configuração efetiva do projeto e a versão instalada
 prevalecem sobre exemplos.
@@ -1323,13 +1380,16 @@ autonomia não é perfil de instalação nem permissão.
 
 ## Principal avulso e delegação
 
-Conversation e principal de Task avulsa preservam o modelo e esforço escolhidos
-manualmente no Codex. Priorize execução direta. O ZAIP não troca silenciosamente
-o seletor do usuário nem exige subagente para responder uma pergunta simples.
+Conversation sem ação preserva o modelo e esforço escolhidos manualmente no
+Codex e responde sem subagente. Para Task avulsa, a v4 exige subagentes
+nativos: o principal coordena, e o ZAIP escolhe modelo/effort de cada filho
+por papel, fase, criticidade e preset congelado. Não paralelize Tasks avulsas.
+O ZAIP não altera silenciosamente o seletor do principal do usuário.
 
-Se a entrega precisar de especialidade, isolamento ou revisão/finalização
-exigida, delegue pelo catálogo com escopo e responsabilidade explícitos. Antes,
-informe:
+Para cada Task avulsa no contrato-alvo v4, delegue pelo catálogo nativo com
+escopo e responsabilidade explícitos. Especialidade, isolamento e
+revisão/finalização exigida determinam quais papéis adicionais são necessários.
+Antes, informe:
 
 > Orquestração ZAIP: subagentes podem usar modelo e esforço diferentes do agente
 > principal, conforme o perfil de autonomia. A configuração efetivamente
@@ -1351,8 +1411,8 @@ desde o início; a preferência direta não dispensa Evidence, revisão ou Gui.
 | Preset | Replanejamento 1 | Replanejamento 2 | Replanejamento 3 | Execução Astra |
 | --- | --- | --- | --- | --- |
 | \`essential\` | Sol/high | Não existe | Não existe | Nunca automática |
-| \`balanced\` | Sol/high | Astra/high | Astra/high | Elegível no bloco do terceiro replanejamento |
-| \`persistent\` | Sol/high | Astra/high | Astra/high, e seguintes sem teto | Elegível a partir do terceiro replanejamento |
+| \`balanced\` (alvo v4) | Sol/high | Sol/high | Astra/high | Elegível no bloco do terceiro replanejamento |
+| \`persistent\` (alvo v4) | Sol/high | Sol/high | Astra/high, e seguintes sem teto | Elegível a partir do terceiro replanejamento |
 
 O Essencial permite no máximo quatro execuções de produto e um
 replanejamento. O Equilibrado permite dez execuções e três replanejamentos.
@@ -1365,14 +1425,14 @@ fallback e configuração. Um modelo Astra configurado num agente não libera
 Astra automático no Essencial.
 
 Nos demais presets, Astra automático usa somente \`high\`: não \`xhigh\`,
-\`max\` ou \`ultra\`. Pode replanejar a partir do segundo plano e executar a
+\`max\` ou \`ultra\`. Na v4 só pode replanejar a partir do terceiro plano e executar a
 partir do terceiro, quando a rota válida o selecionar; não se torna reviewer
 ou finalizer. A exceção de execução não acrescenta tentativas nem amplia
 write scopes.
 
-O primeiro replanejamento usa \`gpt-6-sol\`; os seguintes permitidos usam
-\`gpt-6-astra\`. Executor e replanejador são invocações diferentes. Planejar
-com Astra não obriga a executar com Astra no segundo bloco.
+Os dois primeiros replanejamentos usam \`gpt-6-sol\`; o terceiro e os
+seguintes permitidos usam \`gpt-6-astra\`. Executor e replanejador são
+invocações diferentes. Um plano Astra não obriga o executor a usar Astra.
 
 ## Replanejar não é repetir sem diagnóstico
 
@@ -1426,9 +1486,9 @@ execution:
   runtime: manual
 \`\`\`
 
-Esse exemplo configura o preset **sem iniciar provider**. Novos templates
-também mantêm seleção \`model_orchestration.mode: manual\`. O coordenador
-gerenciado usa \`execution.runtime: managed\` para PRD/SPEC (padrão novo), ou
+Esse exemplo configura o preset **sem iniciar provider**. Templates legados
+podem manter seleção \`model_orchestration.mode: manual\`. O coordenador
+gerenciado usa \`execution.runtime: managed\` para PRD/SPEC legados, ou
 \`autonomous\` também para Task gerenciada explícita, provider/configuração
 válidos, execução autorizada e worktree elegível. Salvar o preset no Dashboard
 não faz essa ativação automaticamente.
@@ -1451,14 +1511,26 @@ fronteira da contagem determinística e da seleção automática. Uma chamada
 nativa \`spawn_agent\` externa, feita diretamente pelo Codex, não é interceptada
 pelo diário: instrução e captura posterior não equivalem a controle preventivo.
 
-O padrão novo \`managed\` já seleciona PRD/SPEC gerenciados, sem prometer
-controle externo numa sessão manual. \`task migrate-autonomy\` exige preview,
+O candidato local v4 usa \`codex_native\`; o \`managed\` permanece para projetos
+legados, sem prometer controle externo numa sessão manual. \`task migrate-autonomy\` exige preview,
 contagem histórica revisada e confirmação; não reinicia quotas ou aprova legados.
 
-A preferência do principal avulso, o catálogo gerado do filho e a configuração
-efetivamente observada devem aparecer separados. Se o host não suporta o
-override necessário, relate a limitação real; não afirme que um prompt mudou
-o modelo e não fabrique telemetria.
+A escolha do principal, o catálogo gerado do filho e a configuração
+efetivamente observada devem aparecer separados. Na v4, o preflight precisa
+conferir capacidade e perfil Codex antes de reservar/despachar cada filho;
+captura posterior comprova o que ocorreu, não corrige uma chamada já feita.
+Se o host não suporta ou não permite confirmar o modelo/effort exigido,
+bloqueie a tentativa com razão explícita. Não afirme que um prompt mudou o
+modelo e não fabrique telemetria.
+
+No Codex, a configuração de um agente customizado em \`.codex/agents/*.toml\`
+(\`model\` e \`model_reasoning_effort\`) tem precedência sobre os defaults globais
+de \`[agents]\` e sobre a herança do principal. Por isso, conferir só o YAML do
+ZAIP não prova o modelo de um filho nativo: o preflight deve inspecionar o
+papel efetivamente disponível e sua configuração antes do despacho. Se o papel
+fixar um modelo aposentado ou incompatível com o plano, falhe explicitamente;
+não registre GPT-6 como executado com base apenas na intenção do plano.
+Veja a [documentação oficial de subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents).
 
 ## Compatibilidade: model_orchestration sem autonomy
 
@@ -1537,7 +1609,7 @@ O Fast do Codex é consumo de créditos da assinatura e não prova que uma requi
 
 ## Invariantes de telemetria
 
-O Monitor de Custos preserva a disponibilidade por métrica. Custo equivalente só é calculado quando os tokens, a identidade de preço e a tarifa necessária estão disponíveis. Lifecycle e telemetria parcial continuam visíveis com lacunas explícitas. \`null\` permanece \`Indisponível\`; nunca é convertido em zero. A projeção pode mostrar duração reconciliada, inferida ou estimada com proveniência, mas isso não é duração observada nem comprova uma medição da chamada.
+O Monitor de Custos preserva a disponibilidade por métrica. Custo equivalente só é calculado quando os tokens, a identidade de preço e a tarifa necessária estão disponíveis. Lifecycle e telemetria parcial continuam visíveis com lacunas explícitas. \`null\` permanece \`null\` nos registros, API, exportação e cálculo; nunca vira custo observado zero. Na UI v4, cards e células numéricas carregados exibem \`0\` e cobertura “sem medição”, sem o literal “Indisponível”; loading usa skeleton. A projeção pode mostrar duração reconciliada, inferida ou estimada com proveniência, mas isso não é duração observada nem comprova uma medição da chamada.
 
 \`\`\`text
 cached_input <= input
@@ -1626,6 +1698,11 @@ Registro local de consulta em 15 de julho de 2026. Valores operacionais ficam no
 
 O candidato de release precisa passar gates locais, clean-room e distribuição pública sem confundir validação técnica com aprovação de produção.
 
+As decisões de [lifecycle v4](28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar)
+estão documentadas antes da alteração estrutural. Documentação aprovada não
+equivale a implementação ou nota de produção; qualifique também a distribuição
+instalada, Codex real, modelo/effort observados, fila e UI.
+
 ## Cobertura
 
 \`pnpm test:coverage\` mede os módulos de domínio e aplica um ratchet versionado:
@@ -1663,8 +1740,10 @@ remota manual; não é fallback para assinatura ausente. Uma Release GitHub publ
 não prova publicação npm: acompanhe o job até a confirmação do registry. Os comandos
 abaixo são do mantenedor; não presuma que existam no projeto consumidor.
 
-Dados históricos incompletos do Dashboard conservam \`null\`/indisponível e sua
-cobertura conhecida. Não se exige reconstruir fatos que nunca foram capturados.
+Dados históricos incompletos conservam \`null\`/cobertura na fonte, API e
+exportação. Na UI v4, cards/células numéricas carregados mostram \`0\` com
+“sem medição”, sem exibir “Indisponível”; loading não mostra zero. Não se
+exige reconstruir fatos que nunca foram capturados.
 Isso não dispensa paridade entre records, API e UI para o mesmo conjunto conhecido,
 testes dos dados novos, nem fechamento canônico de Tasks sem sucesso inventado.
 
@@ -1701,8 +1780,10 @@ contra o manifest do próprio pacote, incluindo a Rule Astra, e verifica que
 os READMEs da raiz do consumidor sobrevivem à instalação e à reinstalação.
 O relatório registra a quantidade de arquivos documentais conferidos.
 
-Novos templates mantêm seleção do principal em \`manual\`, runtime \`managed\`
-para PRD/SPEC e preset Equilibrado; avulsas preferem execução direta.
+O candidato v4 mantém seleção do principal em \`manual\`, runtime
+\`codex_native\` para PRD/SPEC e Tasks avulsas, e preset Equilibrado.
+O npm publicado anteriormente mantém o contrato da sua versão; o TGZ v4
+e a execução real no Codex exigem qualificação própria.
 A documentação não deve confundir
 perfil de instalação com modelo/effort nem apresentar estimativas de tokens
 como economia financeira medida. O escopo automático e os limites Astra
@@ -1849,7 +1930,7 @@ anteriores, testes simulados de modelos e evidência local não certificam
 o candidato final nem seu uso em produção.
 
 O [guia 19](19-assurance-e-autonomia.md) registra as fronteiras atuais: controle
-preventivo de cotas/modelos somente no despacho gerenciado; avulsa direta exige
+preventivo de cotas/modelos somente no despacho gerenciado; avulsa direta legada exige
 autorização explícita desde a captura e identidade observada, sem executor
 cerimonial. Revisão aplicável, Evidence e Gui continuam obrigatórios.
 
@@ -2005,6 +2086,12 @@ indisponíveis. Por isso:
 - \`null\` significa desconhecido e nunca é convertido em \`0\`;
 - “sem custo observado” não significa “custo zero”.
 
+Essa regra governa fonte, API, agregação e exportação. A UI v4 apresenta
+\`0\` em cards e células numéricas **após** carregar, mesmo quando a fonte é
+\`null\`, sempre com cobertura/tooltip “sem medição”; não apresenta o texto
+“Indisponível” nesses componentes. Durante loading, use skeleton. O numeral
+visual não pode alimentar totais, médias, preços ou Evidence como zero real.
+
 ## Operação e recuperação
 
 1. Não edite nem remova manualmente o spool, chunks, manifestos ou writer ID.
@@ -2047,7 +2134,7 @@ legados, substituição, truncamento, exclusão e concorrência exigem verifica
 de integridade e fallback completos. Redução mensurada, baseline equivalente,
 cobertura e carga concorrente precisam constar do benchmark; não declarar a
 matriz de performance aprovada apenas porque consultas focadas passaram.
-`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento é a referência pública do lifecycle implementado pelo ZAIP-AIOS. Status persistido, Run, coluna do Kanban e reconciliação possuem responsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\n`implemente` sem alvo abre somente uma Conversation de planejamento; em `draft` finaliza o plano sem executar, em `ready` executa e em `active|blocked|failed` continua, retoma ou cria rework. `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nExemplo:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks concluem, o macro entra em Verificação.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação global ao abrir o dashboard, em cada turno ou em intervalo automático.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A preferência avulsa direta não remove\no gate de executor capturado ainda exigido pelo contrato atual.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
+`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento separa o lifecycle existente do contrato aprovado para a v4.\nStatus persistido, Run, coluna do Kanban e reconciliação possuem\nresponsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Contrato aprovado para a v4 (a implementar e qualificar)\n\nAs regras a seguir são decisões de produto, **não** prova de que o runtime,\nhooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve\ncomparar código-fonte, artefato empacotado e uso real no Codex.\n\n1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de\n   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo\n   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro\n   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`\n   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter\n   automaticamente nem paralisar a ação já autorizada.\n2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A\n   definição usa sua Run `interaction`; a implementação usa outra Run\n   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a\n   Run de definição como se tivesse executado o produto. “Crie” isolado\n   termina em `draft`; `ready` não executa; `execute` não precisa passar\n   temporariamente pelo card Pronto para Executar.\n3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de\n   PRD/SPEC em DAG planejada, com independência, escopos e recursos\n   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,\n   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de\n   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;\n   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as\n   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma\n   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e\n   dos gates parentais o macro pode ser entregue ou terminalizado com causa.\n4. Cada rodada horária, se o usuário tiver instalado a automação Codex,\n   reivindica somente **um** item superior `ready`: PRD, depois SPEC\n   independente, depois Task avulsa. Dentro da classe respeita a prioridade\n   manual do Kanban. Descendentes, ativos e terminais não são candidatos.\n   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não\n   acordam o Codex; não prometa trabalho após o host parar.\n5. O preset `balanced` admite três replanejamentos reais por Task, com\n   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,\n   evento observado, hipótese nova, teste discriminante e ledger imutável\n   evitam recontagem ou alegação de tentativa não executada. O controle\n   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4\n   precisa implementar um preflight compatível com o host e bloquear quando\n   modelo, effort ou ferramenta requeridos não puderem ser assegurados.\n6. A reconciliação global do backlog continua manual. A tentativa **atual**\n   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento\n   observável da mesma Task/turno; não há garantia de código rodando após o\n   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos\n   canônicos, sem inferir aprovação.\n7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem\n   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram\n   também cobertura/tooltip “sem medição”, pois zero observado é diferente.\n   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e\n   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a\n   fonte canônica nem entra em somas como observação.\n\nO candidato local v4 usa `codex_native` no schema e no template npm. O modo\nnão inicia um processo autônomo separado; a efetividade da rota nativa ainda\ndepende da capacidade real da sessão Codex. Compatibilidade legada permanece\nseparada do caminho padrão novo. Isso não comprova publicação no npm.\n\n## Fronteiras nativas e prova de compatibilidade\n\nEsta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule\nou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,\nnão intercepta toda chamada e não cria um relógio. O caminho v4 usa as\nferramentas reais do Codex e valida capacidades disponíveis na sessão antes\nde prometer uma garantia.\n\n| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |\n| --- | --- | --- |\n| Intake | Separar Conversation de ação e correlacionar turno, intenção e alvo sem Task artificial. | Fixtures para pergunta, ação avulsa, criação `draft`, `ready`, execução e “crie e execute”; ausência de artefatos indevidos. |\n| Subagente nativo | Em toda Task avulsa, despachar um filho real e aguardar seu resultado; execução produtiva sequencial. Só uma DAG de PRD/SPEC autoriza filhos produtivos paralelos. | Captura de `spawn_agent`, identidade, modelo/effort solicitados e efetivamente observáveis, resultado terminal e nenhuma Task concorrente fora da DAG. |\n| Modelo e esforço | Consultar agente/perfil que o host disponibiliza. Validar a rota antes do spawn; preservar seleção manual do principal e distinguir intenção de configuração efetiva. | Teste com agente GPT-6 válido, modelo não disponível e fallback inesperado. Sem comprovação da configuração efetiva, manter telemetria `null` e bloquear a garantia automática. |\n| Replan | Reservar e registrar até três diagnósticos reais no Equilibrado, Sol/high, Sol/high, Astra/high; plano exige hipótese nova e teste que distingue a causa. | Ledger idempotente, casos de erro, interrupção, retry e capacidade ausente; não contar prompt, timeout ou reserva sem execução como diagnóstico concluído. |\n| Fechamento | Aguardar filhos e provas, executar Gui como último filho e aplicar sua decisão. Se Gui não iniciar, falhar ou a Run parar, o caminho confiável de fechamento registra `blocked` com motivo e retomada, sem inventar decisão de Gui. | Testes de Stop, interrupção e replay; nenhuma tentativa **formalmente encerrada** fica `executing`/`verifying`; recibo recuperável quando a escrita falha. |\n| Agenda | Instalar somente a pedido uma tarefa agendada nativa do desktop para um item superior `ready` por rodada, com lease e prioridade do Kanban. | Inspeção da automação realmente criada, duas rodadas sem duplicação e teste de worktree/local; sem app/máquina ativa, informar ausência de execução. |\n| Dados e UI | Reconciliar fontes canônicas e worktrees; mostrar skeleton durante carga e `0` visual nos campos numéricos sem medição, com cobertura explícita. | Comparar records → SQLite → API → cards/tabelas; `null` continua em API/export/cálculo, inclusive nos períodos Hoje/Ontem/Esta Semana. |\n| Distribuição | Builder e projeto novo/atualizado pelo npm instalam os mesmos adapters, Rules, skills e configuração suportada. | Testar TGZ exato em fixture limpa e atualização Windows/PowerShell, `doctor`, adaptadores, ciclo Codex e idempotência. |\n\nOs [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)\npermitem perfis próprios e herança de modelo/effort; a disponibilidade\nconcreta e o agente escolhido dependem da sessão. Os\n[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas\nferramentas locais, mas admitem caminhos especializados fora dessa cobertura.\n`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova\ncontinuação, não provar que o trabalho terminou, nem impedir uma interrupção\nhumana. Por isso o hook é checkpoint e reparo observável, nunca substituto\nuniversal de estado canônico, Gui ou ferramenta de despacho. As\n[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução\nprópria do app; em projeto local dependem de computador ligado e app ativo.\nO agendamento não é instalado só porque os arquivos existem no Git.\n\nSe o processo for encerrado antes do Stop ou da escrita, nenhum componente\nlocal consegue garantir a transição **naquele instante**. A garantia honesta é\num evento durável recuperável e a conciliação na próxima execução observável;\naté lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não\ninventar um terminal. Esse limite do host não autoriza encerrar a Run com\n`executing` como se fosse sucesso.\n\nLacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão\nde Gui, mas `run finish` aplica `blocked` como fallback quando é realmente\nchamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar\na Task em `executing` até a retomada/reconciliação. A fila agendada agora\nreivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada\npara toda chamada nativa. São itens de implementação, não decisões humanas\npendentes. A documentação é aprovada quando descreve essas lacunas; o produto\nsó está pronto quando a matriz passa no Codex e no pacote instalado.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\nNo contrato atual, `implemente` sem alvo abre Conversation de planejamento; na v4, quando houver objetivo independente de ação, entra como Task avulsa. Em PRD/SPEC `draft`, só executa com intenção explícita de executar o macro; criar/refinar isoladamente mantém `draft`. Em `ready`, executar inicia; em `active|blocked|failed`, continua/retoma/rework conforme estado. `desenvolva|melhore|aprimore` com intenção explícita de ação independente também não é reduzido a planejamento só pelo verbo. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição após a decisão real. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. **Contrato-alvo v4:** finalizador ausente, incompleto ou falho produz `blocked` por um caminho confiável separado, nunca uma aprovação sintética. No candidato atual, a CLI ainda pode deixar a Task em `executing` porque rejeita bloqueio direto sem Gui; essa lacuna precisa de correção e teste.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nDepois de capturar a decisão real do finalizador, o orquestrador pode aplicar\no fechamento pela CLI. O trecho abaixo **não** funciona como atalho para\n`task block` ou `run finish` sem essa decisão já persistida:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim **formalmente persistido** da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração exige recuperação retomável; quando o evento de\ninterrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte\nabrupta do processo pode deixar o estado pendente até o próximo evento\nobservável, como descrito acima. “Cancelar a Task” é decisão explícita e\nresulta em `cancelled` somente quando persistida.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks da DAG ficam terminais, o macro pode entrar em\n  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis\n  são fechados com causa antes de decidir o resultado parental.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence\n  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação **global** ao abrir o dashboard, em cada turno ou em intervalo automático. O contrato-alvo v4 acrescenta conciliação **direcionada à tentativa atual** no fechamento/Stop observado ou no próximo evento Codex da mesma Task, nunca uma varredura global silenciosa.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A exceção de raiz avulsa direta\nautorizada pertence à compatibilidade do contrato atual; no padrão Codex-native\nda v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois\ncaminhos dispensa Evidence, gates e decisão real de Gui.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
 
 [English](README-ENG.md) | Português
 
@@ -2055,6 +2142,18 @@ matriz de performance aprovada apenas porque consultas focadas passaram.
 
 ## Visão rápida
 
+> **Contrato-alvo da v4.0:** as decisões de fluxo Codex-native, subagentes, fila,
+> replanejamento e apresentação de métricas descritas abaixo estão aprovadas para
+> implementação. Esta revisão documental não comprova que o runtime, os hooks,
+> o Dashboard ou o pacote publicado já as executem; cada garantia exige teste
+> no candidato exato e no consumidor instalado. O contrato completo está no
+> [guia de lifecycle v4](.agents/zaip-aios/guides/28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar).
+
+O [contrato de compatibilidade Codex-native](.agents/zaip-aios/guides/28-lifecycle-completo.md#fronteiras-nativas-e-prova-de-compatibilidade)
+explicita o que depende de subagentes, hooks, automação agendada e do
+instalador. Interrupção abrupta pode deixar uma tentativa pendente até o
+próximo evento do host; um Stop hook não garante execução após o app parar.
+
 O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
 
 Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios ou registrar bloqueio/falha conforme evidências e orçamento. O perfil Persistente permite execução indefinida por escolha explícita; os demais têm cotas por Task. Nenhum perfil garante acerto nem amplia autoridade para ações externas.
@@ -2264,13 +2363,13 @@ As visões Trabalho (Kanban) e Trabalho (Lista) permitem alternar entre leitura
 
 ### Monitor de Custos
 
-Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero.
+Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero **canônico**. No contrato visual v4, cards e tabelas numéricas já carregados mostram \`0\` em vez de “Indisponível”, acompanhados de cobertura “sem medição”; durante loading mostram skeleton. API e arquivos continuam \`null\` quando não há medição.
 
 <img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">
 
 O Monitor consolida tokens, tempo, custo e cobertura por Run, Task, SPEC e PRD. Isso permite comparar conversa, planejamento, execução, trabalho novo e rework, além de identificar médias e concentrações de consumo por dia, mês ou ano.
 
-Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam \`unknown\`, sem serem convertidos artificialmente em zero.
+Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam \`unknown\` na fonte; o \`0\` visual da v4 não entra nos cálculos.
 
 **Contrato técnico da telemetria**
 
@@ -2299,16 +2398,17 @@ A configuração da plataforma apresenta o estado de ativação do ZAIP-AIOS e u
 
 <img src=".agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="Dashboard ZAIP-AIOS, configuração da plataforma" width="100%">
 
-### Perfis de autonomia da v3
+### Perfis de autonomia: contrato-alvo da v4
 
-As fontes em preparação para a v3 acrescentam um preset por Task, separado de
-instalação e assurance:
+O preset por Task é separado de instalação e assurance. A rota abaixo é a
+decisão aprovada para a v4; o runtime atual ainda precisa ser alterado e
+qualificado antes que esta tabela descreva seu comportamento efetivo:
 
 | Perfil | Execuções de produto por Task | Replanejamentos | Modelos 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 |
+| Equilibrado (\`balanced\`, padrão) | 10: 1 inicial + 9 reparações | 3 | Sol/high → Sol/high → Astra/high |
+| Persistente (\`persistent\`, opt-in) | Sem teto | Sem teto | Sol/high nos dois primeiros; Astra/high no terceiro e seguintes |
 
 Mescle no arquivo \`.agents/config/project.yaml\` ou selecione **Perfil de
 autonomia** em **Configurações do projeto** no Dashboard e salve:
@@ -2330,10 +2430,16 @@ A falta de verificação/conclusão segura termina \`blocked\`; impedimento téc
 comprovado termina \`failed\`. Ramos independentes continuam elegíveis.
 
 **Limite atual:** os contadores são impostos no runtime gerenciado, não em
-\`spawn_agent\` externo feito diretamente pelo Codex. Novos projetos usam
-\`execution.runtime: managed\`: PRD/SPEC gerenciados e avulsas diretas. Salvar
-o preset não inicia provider. Legados exigem migração explícita, sem zerar
-consumo. Veja [autonomia e suas garantias](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+\`spawn_agent\` externo feito diretamente pelo Codex. O contrato-alvo torna a
+colaboração nativa do Codex o caminho operacional padrão também para Tasks
+avulsas: cada tentativa reserva seu orçamento antes do despacho, usa
+subagente nativo e registra eventos observados. Se o host não oferecer o
+modelo, effort ou ferramenta exigidos, a tentativa bloqueia com causa
+explícita; instrução ou captura posterior não são controle preventivo.
+O candidato local v4 usa \`execution.runtime: codex_native\` no builder e no
+template do instalador; o npm publicado ainda precisa ser qualificado separadamente.
+Salvar o preset não inicia provider. Legados não têm
+quota zerada. Veja [autonomia e suas garantias](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
 
 ### Stack de desenvolvimento
 
@@ -2396,12 +2502,17 @@ Quando existe dependência entre capacidades, o trabalho deve permanecer na mesm
 
 O comando \`implemente\` considera o estado atual do trabalho:
 
-* sem alvo definido, abre uma Conversation de planejamento
-* em \`draft\`, conclui o plano
+* com pedido de ação independente, mas sem PRD/SPEC explícito, cria e executa
+  uma Task avulsa; referência a um macro existente exige alvo inequívoco
+* em PRD/SPEC \`draft\`, só executa se a intenção de execução do macro for
+  explícita; caso contrário, conclui o plano sem promover
 * em \`ready\`, inicia a execução
 * em estados ativos ou com falha, continua, retoma ou inicia o rework
 
-Os comandos \`desenvolva\`, \`melhore\` e \`aprimore\` sempre retornam ao planejamento ou ao rework.
+Os comandos \`desenvolva\`, \`melhore\` e \`aprimore\` preservam a intenção: com
+objetivo independente de ação, entram como Task avulsa; para lapidar um
+PRD/SPEC existente sem pedido de execução, permanecem no planejamento ou
+rework em \`draft\`.
 
 Um PRD cancelado não pode ser alterado. Quando necessário, um novo PRD de rework é criado, preservando o vínculo e o histórico de auditoria.
 
@@ -2416,10 +2527,13 @@ mantém o cartão compacto **Custo Estimado**, sem ícone. A descrição acessí
 tooltip informam a cobertura. O subtítulo divide o subtotal conhecido pelo número
 de tarefas e pelas horas registradas no mesmo recorte: são taxas estimadas de
 alocação, não médias de custos completos por tarefa. Com cobertura parcial, não
-estima os valores ausentes. Cada taxa fica \`—\` apenas se sua base estiver indisponível
-ou for zero; uma taxa válida não é escondida porque a outra está indisponível.
-O subtotal não é o custo integral nem a fatura da conta. Zero observado continua sendo zero;
-ausência de medição continua indisponível. Rascunhos de Task ficam na lista de
+estima os valores ausentes. No contrato visual da v4, cards e células numéricas
+já carregados exibem \`0\` quando a base não foi medida, com cobertura/tooltip
+“sem medição”; durante loading mostram esqueleto, não zero. Uma taxa válida não
+é escondida porque outra não foi medida. O subtotal não é custo integral nem
+fatura da conta. Zero observado e ausência de medição têm o mesmo numeral na
+interface, mas continuam distintos por cobertura e no dado canônico (\`0\` versus
+\`null\`). Rascunhos de Task ficam na lista de
 trabalho, fora do Kanban executável e dos indicadores operacionais sem rascunhos.
 
 
@@ -2574,33 +2688,33 @@ Essa progressão permite começar de forma simples e acrescentar planejamento ap
 
 **Políticas técnicas de execução e assurance**
 
-Conversation e o principal de Task avulsa preservam a seleção manual do host, priorizando trabalho direto. Quando delegar for necessário, informe que os filhos podem usar modelos/esforços diferentes pela política ZAIP; não há obrigação de herdar o principal. Modelo e effort ficam fixos por Run, com observação efetiva separada da seleção planejada. A seleção automática solicita \`standard\`; capacidade não observada do host não pode ser presumida. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
+Conversation sem trabalho executável preserva a seleção manual do host e não usa subagentes. No contrato-alvo da v4, toda Task avulsa usa subagentes nativos Codex; o ZAIP seleciona modelo e effort de cada filho conforme papel, risco e fase, sem herdar necessariamente a seleção do principal. A Task avulsa é sequencial; paralelismo produtivo só ocorre em DAGs planejadas de PRD/SPEC com independência e escopos compatíveis. Modelo e effort ficam fixos por Run, com observação efetiva separada da seleção planejada. Se a configuração requerida não puder ser despachada/confirmada no host, bloqueie em vez de afirmar que o prompt trocou o modelo. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
 
 ### Política Astra
 
-No Essencial, Astra nunca é selecionado automaticamente, inclusive em filhos ou fallback. A única exceção é o principal avulso com Astra escolhido manualmente pelo usuário. No Equilibrado, os três replanejamentos usam Sol/high, Astra/high e Astra/high; no terceiro bloco Astra/high também pode executar a reparação, sem ampliar a quota. Persistente mantém essa progressão sem teto total.
+No Essencial, Astra nunca é selecionado automaticamente, inclusive em filhos ou fallback. No Equilibrado, os três replanejamentos usam Sol/high, Sol/high e Astra/high; no terceiro bloco Astra/high também pode executar a reparação, se a rota elegível o selecionar, sem ampliar a quota. Persistente mantém essa progressão sem teto total. Essa é uma política-alvo: a configuração real do agente Codex e o ledger devem ser verificados, não inferidos do texto.
 
-O replanejador é isolado e não edita produto; executor, revisor e Gui são papéis distintos. Astra automático usa somente \`high\`, não substitui revisão/finalização e depende do despacho gerenciado. A regra antiga de até três diagnósticos Astra somente leitura permanece apenas no contrato legado sem \`autonomy\`; não limita Persistente. Contexto e assurance seguem o domínio: conteúdo exige fontes/briefing, engenharia exige comportamento verificável. Economia real precisa ser medida, não inferida do preset.
+O replanejador é isolado e não edita produto; executor, revisor e Gui são papéis distintos. Astra automático usa somente \`high\` e não substitui revisão/finalização. Hoje seu controle preventivo depende do despacho gerenciado; no contrato-alvo Codex-native, exige preflight efetivo antes de cada filho nativo. A regra antiga de até três diagnósticos Astra somente leitura permanece apenas no contrato legado sem \`autonomy\`; não limita Persistente. Contexto e assurance seguem o domínio: conteúdo exige fontes/briefing, engenharia exige comportamento verificável. Economia real precisa ser medida, não inferida do preset.
 
-O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction delegada exige executor elegível (ou raiz Task direta autorizada) e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
+O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. “Crie e execute PRD/SPEC” cabe no mesmo turno do Codex, mas usa uma Run canônica de definição e outra de delivery, vinculadas: nunca se converte a primeira em Run de implementação. Toda delivery e interaction delegada exige executor elegível e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
 
 Cada tentativa de Task tem exatamente um orquestrador responsável. Gui é seu
 último filho direto, irmão dos executores, não finalizador de cada trabalhador.
 O host persiste a decisão real antes do Stop canônico; pode retransmitir Gui
 já terminal enquanto o responsável estiver aberto, sem obrigá-lo a esperar
-recibos. Ausência de decisão não é aprovação. A preferência por execução
-avulsa direta usa uma raiz observada com \`--direct-authorization REFERÊNCIA\`
-explícita; não cria executor fictício nem dispensa Evidence e Gui. Veja
+recibos. Ausência de decisão não é aprovação. A compatibilidade com execução
+avulsa direta antiga usa uma raiz observada com \`--direct-authorization REFERÊNCIA\`
+explícita; não é o caminho padrão novo, não cria executor fictício nem dispensa Evidence e Gui. Veja
 [fechamento e recuperação](.agents/zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
 
-A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. \`standard\` exige duas ou três validações conforme \`verification_scope\` e pelo menos uma Evidence consolidada; \`critical\` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. Novos projetos usam runtime gerenciado para PRD/SPEC e direto para avulsas; a execução por Codex ou Claude é autorizada por pedido, isolada em worktrees e limitada por write scopes, commits, budgets e gates tipados. Consulte [Assurance adaptativa e autonomia opt-in](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. \`standard\` exige duas ou três validações conforme \`verification_scope\` e pelo menos uma Evidence consolidada; \`critical\` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. O candidato local v4 usa Codex-native como modo padrão; o npm publicado anteriormente mantém o contrato da sua versão e exige validação separada. Worktrees, write scopes, commits, budgets e gates tipados continuam exigidos onde aplicáveis. Compatibilidade de outros hosts não equivale à garantia Codex-native. Consulte [Assurance adaptativa e autonomia opt-in](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
 
 
 ## Princípios de engenharia autônoma
 
 O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm o código sustentável, distribuem apenas o contexto necessário e exigem comprovação proporcional ao risco.
 
-O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout usa \`managed\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
+O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout usa \`codex_native\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
 
 - **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
 - **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
@@ -2621,7 +2735,7 @@ O **Graph Engineering** transforma uma entrega complexa em uma sequência coorde
 
 Essa autonomia permanece governada: Dave coordena, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas adicionais entram quando existem sinais objetivos e Gui encerra o fluxo por último. O resultado é uma equipe ajustada à demanda, sem multiplicar agentes e custo sem necessidade.
 
-O **Loop Engineering** usa o perfil congelado da Task para reservar execução e replanejamento antes do provider, registrar o resultado e escolher uma rota corrigida. No Equilibrado são 1 + 9 execuções e três planos Sol/high → Astra/high → Astra/high; Essencial não escala para Astra, Persistente não tem teto. O modelo não muda silenciosamente dentro da mesma Run. A preferência manual do principal avulso não obriga seus filhos a usar a mesma configuração.
+O **Loop Engineering** usa o perfil congelado da Task para reservar execução e replanejamento antes do despacho, registrar o resultado e escolher uma rota corrigida. No contrato-alvo Equilibrado são 1 + 9 execuções e três planos Sol/high → Sol/high → Astra/high; Essencial não escala para Astra, Persistente não tem teto. O modelo não muda silenciosamente dentro da mesma Run. O modelo dos filhos é escolhido pelo ZAIP e precisa ser compatível com o host.
 
 ### Fluxo resumido
 
@@ -2633,7 +2747,7 @@ Os cenários completos ficam no [guia de fluxos e roteamento](.agents/zaip-aios/
 
 O lifecycle segue **Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído**. Bloqueado, Falhado e Cancelado são saídas alternativas.
 
-Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. A Task direta inicia imediatamente, enquanto a preparada aguarda execute.
+Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. Pedido avulso de ação inicia Task com subagentes no contrato-alvo; Task apenas preparada aguarda execute. Cada tentativa física de Task fecha como concluída, bloqueada, falhada ou cancelada antes do encerramento da Run raiz. SPEC/PRD só recebem estado terminal depois de todas as Tasks da DAG terem estado terminal e dos gates parentais aplicáveis.
 
 ![Lifecycles de Task, SPEC e PRD](.agents/zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)
 
@@ -2908,7 +3022,7 @@ rollout, rollback e comandos de verificação estão documentados no
 
 No Codex Desktop, o agendamento horário da fila pronta é configurado pela skill \`$zaip-skill-instalar-agendamento\` em uma única conversa no checkout local. A skill usa a automação nativa de tarefas agendadas para criar ou atualizar uma tarefa standalone com nome estável; ela não duplica registros e falha fechada se a capacidade \`automation_update\` não estiver disponível. A tarefa agendada chama explicitamente \`$zaip-skill-executar-fila-pronta\` em cada rodada horária.
 
-A rodada processa sequencialmente todo o snapshot elegível: primeiro PRDs em \`ready\`, depois SPECs \`ready\` independentes e, por último, Tasks avulsas materializadas em **Pronto para Executar**. Itens descendentes, ativos, bloqueados, falhos ou terminais ficam fora. Em **Dashboard > Trabalho (Kanban) > Pronto para Executar**, a prioridade é definida pela numeração de cima para baixo dentro do tier PRD/SPEC/Task e persiste para o scheduler em \`.agents/dashboard/work-priority.json\`; os controles acessíveis de ordenação atualizam essa numeração, e itens sem número vão para o fim pelo fallback determinístico. Um lock/lease local evita sobreposição entre rodadas.
+No contrato-alvo da v4, cada rodada horária reivindica **um único item de nível superior** elegível: primeiro PRDs em \`ready\`, depois SPECs \`ready\` independentes e, por último, Tasks avulsas em **Pronto para Executar**. A rota visual é Dashboard > Trabalho (Kanban) > Pronto para Executar. Nunca seleciona descendentes separadamente. Dentro de cada classe, segue as setas de prioridade do Dashboard, persistidas em \`.agents/dashboard/work-priority.json\`; itens sem número usam fallback determinístico. Itens ativos, bloqueados, falhos, cancelados ou concluídos ficam fora. O lock/lease impede sobreposição. A skill instala/atualiza a automação nativa somente a pedido do usuário; cada rodada exige um evento real do Codex e não executa sozinha depois que o host parar. O executor atual ainda percorre o snapshot inteiro e precisa mudar antes de se alegar esse comportamento.
 
 O repositório versiona esse contrato, mas não instala um relógio em cada clone. A tarefa agendada pertence à máquina/usuário que a criou e depende da máquina ligada, do Codex Desktop em execução e da automação nativa disponível; sem eles, a skill falha fechada e não promete execução futura.