@zaip-ai/cli 3.8.0 → 4.1.0

package/templates/.agents/zaip-aios/README.md

@@ -70,13 +70,13 @@ A documentação descreve `autonomy-v1`; publicação e qualificação devem ser
 confirmadas pelos artefatos da release, não apenas pela versão deste checkout.
 <!-- zaip-version-reference -->
 Consulte a versão instalada com `zaip version --json` e a identidade do checkout no manifesto raiz. Novos templates usam
-Equilibrado e `execution.runtime: managed`: PRDs/SPECs gerenciados e tarefas
-avulsas preferencialmente diretas. Configurações legadas sem essa opção mantêm
+Equilibrado e `execution.runtime: codex_native`: o Codex orquestra Sub-Runs
+nativos para PRDs, SPECs e Tasks avulsas. Configurações legadas sem essa opção mantêm
 o default manual do schema; salvar configuração não inicia execução.
 Não há desistência por duração nem diminuição automática de ACs.
 Gui finaliza a tentativa da Task como último filho direto, não cada trabalhador.
 
-O controle determinístico exige despacho gerenciado; chamadas nativas externas
-não recebem essa garantia por instrução. Tasks legadas não são migradas
+O controle determinístico da rota nativa exige preflight e observação do host;
+instrução isolada não garante modelo/effort. Tasks legadas não são migradas
 silenciosamente. O guia 19 descreve a autorização imutável da raiz Task direta;
 ela dispensa executor fictício, mas preserva revisão, Evidence e Gui.

package/templates/.agents/zaip-aios/VERSION

@@ -1 +1 @@
-3.8
+4.1

package/templates/.agents/zaip-aios/guides/01-primeiros-passos.md

@@ -5,12 +5,13 @@
 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.

package/templates/.agents/zaip-aios/guides/03-tasks.md

@@ -15,9 +15,10 @@ Em PRD/SPEC `draft`, a lista visível vem dos blueprints do PreparedPlan e não
 
 ## 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.
 
@@ -25,7 +26,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.

package/templates/.agents/zaip-aios/guides/04-specs.md

@@ -11,7 +11,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.
 
@@ -29,5 +29,8 @@ 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.

package/templates/.agents/zaip-aios/guides/05-prds.md

@@ -10,16 +10,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`.
 
@@ -47,5 +48,8 @@ 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.

package/templates/.agents/zaip-aios/guides/06-execucao.md

@@ -22,12 +22,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.
@@ -39,7 +41,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.

package/templates/.agents/zaip-aios/guides/09-agentes-e-squads.md

@@ -42,12 +42,16 @@ 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.

package/templates/.agents/zaip-aios/guides/11-observabilidade-e-custos.md

@@ -11,6 +11,12 @@ Run é o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo
 
 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
@@ -31,7 +37,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.
@@ -42,7 +49,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.

package/templates/.agents/zaip-aios/guides/12-instalacao-e-upgrade.md

@@ -29,17 +29,22 @@ 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).

package/templates/.agents/zaip-aios/guides/13-boas-praticas.md

@@ -13,12 +13,23 @@
 - 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).

package/templates/.agents/zaip-aios/guides/14-troubleshooting.md

@@ -7,7 +7,7 @@
 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`.
 
@@ -21,6 +21,8 @@ Se “finalizar” tentou entregar um PRD `draft`, confira adapters/skills: o co
 | `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 |

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

@@ -7,7 +7,7 @@
 - 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
 
@@ -43,9 +43,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
@@ -58,11 +61,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).
@@ -72,7 +75,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.
 
@@ -105,7 +108,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.

package/templates/.agents/zaip-aios/guides/17-como-o-custo-e-calculado.md

@@ -19,7 +19,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
 

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

@@ -64,6 +64,10 @@ Os squads facilitam a leitura organizacional e a colaboração humana. Eles não
 
 O 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.
 
+Na v4, isso continua verdadeiro para records, API e cálculos. Apenas os
+cards/células numéricas do Dashboard carregado exibem `0` com cobertura
+“sem medição”; o catálogo não autoriza registrar zero observado fictício.
+
 O 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.
 
 O `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.

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

@@ -1,8 +1,8 @@
 # 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
 
@@ -22,8 +22,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,
@@ -34,7 +34,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
@@ -94,14 +94,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.
 
@@ -136,8 +138,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.
 

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

@@ -63,14 +63,16 @@ O instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite
 e `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade
 de uma tarefa nem ativam um modelo mais caro.
 
-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 o alvo v4 Sol/high → Sol/high → Astra/high e execução elegível no
+terceiro bloco. Schema e template v4 já adotam Codex-native como padrão;
+adapters, pacote real e host ainda devem ser qualificados. O Essencial nunca usa Astra
+automático. Principal avulso preserva a seleção manual; filhos seguem a
+política ZAIP verificada no host. Projetos e estados legados
 não recebem migração silenciosa de quotas.
 
 ## Construir o CLI
@@ -210,7 +212,7 @@ zaip prd execute PRD-ID
 
 Na 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.
 
-`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.
+`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.
 
 ## Refinar sem executar
 
@@ -239,7 +241,7 @@ de Gui, nem interprete `run finish --status completed` como aprovação.
 O host captura spawn/terminal reais e persiste a decisão observada antes do
 Stop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).
 
-Tasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.
+Tasks `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.
 
 Cada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.
 
@@ -324,7 +326,9 @@ Reconciliação global não roda ao abrir o dashboard, a cada turno ou em interv
 quando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente
 `zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento
 terminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates
-em bloqueio; e nunca infere cancelamento ou sucesso sem evidência.
+em bloqueio; e nunca infere cancelamento ou sucesso sem evidência. A v4
+acrescenta recuperação idempotente apenas da tentativa atual no fechamento ou
+no próximo evento Codex observável; não mantém agente rodando após o host parar.
 
 ## Organizar frontend, backend e site
 

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

@@ -4,7 +4,7 @@ Este guia descreve o contrato e não declara cobertura, totais ou preços de um
 
 ## 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
 
@@ -21,7 +21,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.
 
@@ -29,7 +29,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

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

@@ -27,19 +27,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
 ```
@@ -79,7 +81,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)