@zaip-ai/cli 3.7.0 → 4.0.0

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
@@ -119,7 +121,7 @@ O setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no
 framework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos
 de ID ou contradições bloqueiam a operação; não existe override silencioso.
 
-Também gera adapters mínimos, como `AGENTS.md` e `CLAUDE.md`, sem sobrescrever conteúdo do usuário silenciosamente.
+Também gera adapters mínimos, como `AGENTS.md` e os wrappers de skills dos clientes, sem sobrescrever conteúdo do usuário silenciosamente.
 
 ## Migrar estado V1
 
@@ -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)
 

package/templates/.agents/zaip-aios/guides/23-orquestracao-de-modelos.md

@@ -4,7 +4,8 @@
 
 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.
@@ -15,13 +16,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
@@ -43,8 +47,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.
@@ -57,14 +61,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-5.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
 
@@ -93,9 +97,8 @@ não crie outra Task ou apague `.local` para renovar a quota.
 
 | Modelo | Papel dentro da política ZAIP |
 | --- | --- |
-| `gpt-5.6-luna` | Execução clara e delimitada, conforme catálogo e capacidade |
-| `gpt-5.6-terra` | Implementação, testes e integração cotidianos |
-| `gpt-5.6-sol` | Planejamento difícil, revisão especializada e primeiro replanejamento |
+| `gpt-6-luna` | Execução clara e delimitada, conforme catálogo e capacidade |
+| `gpt-6-sol` | Implementação, testes, integração, planejamento difícil, revisão especializada e primeiro replanejamento |
 | `gpt-6-astra` | Replanejamentos e exceção de execução permitidos pelo preset |
 
 Esses são papéis configurados pelo ZAIP, não alegações de benchmark dos
@@ -119,9 +122,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.
@@ -144,14 +147,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
 

package/templates/.agents/zaip-aios/guides/24-calculo-de-custos-openai.md

@@ -17,7 +17,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
@@ -42,20 +42,20 @@ BRL_total = USD_total × cotação_USD_BRL
 
 A conversão para BRL é a última etapa. Quando a moeda exibida é USD, não há conversão.
 
-## Exemplo didático — GPT-5.6 Sol, Standard
+## Exemplo didático — GPT-6 Sol, Standard
 
-No snapshot local consultado durante a redação, `gpt-5.6-sol` contém input US$5, cache US$0,50 e output US$30 por 1M. Esses números ilustram a fórmula; confira o catálogo e a fonte registrada antes de usar valores em uma decisão atual. Para 1.000.000 input, 800.000 cache, 100.000 output e 70.000 reasoning:
+No catálogo consultado em 2026-09-22, `gpt-6-sol` contém input US$2, cache US$0,20 e output US$10 por 1M. Esses números ilustram a fórmula; confira o catálogo e a fonte registrada antes de usar valores em uma decisão atual. Para 1.000.000 input, 800.000 cache, 100.000 output e 70.000 reasoning:
 
 ```text
 input sem cache = 1.000.000 - 800.000 = 200.000
-input = 0,2 × 5,00 = US$ 1,00
-cache = 0,8 × 0,50 = US$ 0,40
-output = 0,1 × 30,00 = US$ 3,00
+input = 0,2 × 2,00 = US$ 0,40
+cache = 0,8 × 0,20 = US$ 0,16
+output = 0,1 × 10,00 = US$ 1,00
 reasoning = US$ 0,00 adicional (já está nos 100.000 output)
-total = US$ 4,40
+total = US$ 1,56
 ```
 
-Com uma cotação **hipotética** USD/BRL de 5,45: `4,40 × 5,45 = R$ 23,98`.
+Com uma cotação **hipotética** USD/BRL de 5,45: `1,56 × 5,45 = R$ 8,50` (arredondado).
 
 ## Service tier, contexto e dados incompletos
 

package/templates/.agents/zaip-aios/guides/26-qualidade-e-release.md

@@ -2,6 +2,11 @@
 
 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:
@@ -39,8 +44,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.
 
@@ -77,8 +84,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
@@ -225,7 +234,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.
 

package/templates/.agents/zaip-aios/guides/27-telemetria-git-native.md

@@ -146,6 +146,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.

package/templates/.agents/zaip-aios/guides/28-lifecycle-completo.md

@@ -1,12 +1,119 @@
 # Lifecycle de Conversations, Tasks, SPECs e PRDs
 
-Este 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.
+Este documento separa o lifecycle existente do contrato aprovado para a v4.
+Status persistido, Run, coluna do Kanban e reconciliação possuem
+responsabilidades distintas e não devem ser inferidos uns dos outros.
+
+## Contrato aprovado para a v4 (a implementar e qualificar)
+
+As regras a seguir são decisões de produto, **não** prova de que o runtime,
+hooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve
+comparar código-fonte, artefato empacotado e uso real no Codex.
+
+1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de
+   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo
+   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro
+   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`
+   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter
+   automaticamente nem paralisar a ação já autorizada.
+2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A
+   definição usa sua Run `interaction`; a implementação usa outra Run
+   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a
+   Run de definição como se tivesse executado o produto. “Crie” isolado
+   termina em `draft`; `ready` não executa; `execute` não precisa passar
+   temporariamente pelo card Pronto para Executar.
+3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de
+   PRD/SPEC em DAG planejada, com independência, escopos e recursos
+   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,
+   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de
+   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;
+   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as
+   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma
+   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e
+   dos gates parentais o macro pode ser entregue ou terminalizado com causa.
+4. Cada rodada horária, se o usuário tiver instalado a automação Codex,
+   reivindica somente **um** item superior `ready`: PRD, depois SPEC
+   independente, depois Task avulsa. Dentro da classe respeita a prioridade
+   manual do Kanban. Descendentes, ativos e terminais não são candidatos.
+   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não
+   acordam o Codex; não prometa trabalho após o host parar.
+5. O preset `balanced` admite três replanejamentos reais por Task, com
+   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,
+   evento observado, hipótese nova, teste discriminante e ledger imutável
+   evitam recontagem ou alegação de tentativa não executada. O controle
+   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4
+   precisa implementar um preflight compatível com o host e bloquear quando
+   modelo, effort ou ferramenta requeridos não puderem ser assegurados.
+6. A reconciliação global do backlog continua manual. A tentativa **atual**
+   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento
+   observável da mesma Task/turno; não há garantia de código rodando após o
+   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos
+   canônicos, sem inferir aprovação.
+7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem
+   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram
+   também cobertura/tooltip “sem medição”, pois zero observado é diferente.
+   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e
+   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a
+   fonte canônica nem entra em somas como observação.
+
+O candidato local v4 usa `codex_native` no schema e no template npm. O modo
+não inicia um processo autônomo separado; a efetividade da rota nativa ainda
+depende da capacidade real da sessão Codex. Compatibilidade legada permanece
+separada do caminho padrão novo. Isso não comprova publicação no npm.
+
+## Fronteiras nativas e prova de compatibilidade
+
+Esta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule
+ou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,
+não intercepta toda chamada e não cria um relógio. O caminho v4 usa as
+ferramentas reais do Codex e valida capacidades disponíveis na sessão antes
+de prometer uma garantia.
+
+| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |
+| --- | --- | --- |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+| 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. |
+
+Os [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)
+permitem perfis próprios e herança de modelo/effort; a disponibilidade
+concreta e o agente escolhido dependem da sessão. Os
+[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas
+ferramentas locais, mas admitem caminhos especializados fora dessa cobertura.
+`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova
+continuação, não provar que o trabalho terminou, nem impedir uma interrupção
+humana. Por isso o hook é checkpoint e reparo observável, nunca substituto
+universal de estado canônico, Gui ou ferramenta de despacho. As
+[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução
+própria do app; em projeto local dependem de computador ligado e app ativo.
+O agendamento não é instalado só porque os arquivos existem no Git.
+
+Se o processo for encerrado antes do Stop ou da escrita, nenhum componente
+local consegue garantir a transição **naquele instante**. A garantia honesta é
+um evento durável recuperável e a conciliação na próxima execução observável;
+até lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não
+inventar um terminal. Esse limite do host não autoriza encerrar a Run com
+`executing` como se fosse sucesso.
+
+Lacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão
+de Gui, mas `run finish` aplica `blocked` como fallback quando é realmente
+chamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar
+a Task em `executing` até a retomada/reconciliação. A fila agendada agora
+reivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada
+para toda chamada nativa. São itens de implementação, não decisões humanas
+pendentes. A documentação é aprovada quando descreve essas lacunas; o produto
+só está pronto quando a matriz passa no Codex e no pacote instalado.
 
 ## Classificação de entrada
 
 Aliases 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.
 
-`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`.
+No 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`.
 
 ## Criação completa de PRD e SPEC
 
@@ -66,7 +173,7 @@ Quando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais
 
 Cada 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.
 
-O 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`.
+O 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.
 
 No 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.
 
@@ -77,7 +184,9 @@ uma declaração versionada cujo vínculo só pode complementar Evidence quando
 `confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o
 [contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
 
-Exemplo:
+Depois de capturar a decisão real do finalizador, o orquestrador pode aplicar
+o fechamento pela CLI. O trecho abaixo **não** funciona como atalho para
+`task block` ou `run finish` sem essa decisão já persistida:
 
 ```bash
 zaip run finish RUN-ID \
@@ -96,9 +205,13 @@ Antes de uma Run raiz terminar, sua Task deve estar em um destes estados:
 - `failed`: erro técnico/integridade que impediu a execução válida;
 - `cancelled`: pedido humano explícito.
 
-`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.
+`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.
 
-Interromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.
+Interromper a geração exige recuperação retomável; quando o evento de
+interrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte
+abrupta do processo pode deixar o estado pendente até o próximo evento
+observável, como descrito acima. “Cancelar a Task” é decisão explícita e
+resulta em `cancelled` somente quando persistida.
 
 ## Agregação de SPEC e PRD
 
@@ -106,12 +219,15 @@ Quando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active
 
 - Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.
 - SPEC/PRD aguardam todas as Tasks e Runs filhas.
-- Depois que todas as Tasks concluem, o macro entra em Verificação.
-- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.
+- Depois que todas as Tasks da DAG ficam terminais, o macro pode entrar em
+  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis
+  são fechados com causa antes de decidir o resultado parental.
+- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence
+  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.
 
 ## Reconciliação manual
 
-O 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 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.
 
 O algoritmo é idempotente e conservador:
 
@@ -162,5 +278,7 @@ de reservas do runtime. Ausência de Evidence é bloqueio, erro técnico
 comprovado é falha e tempo não determina abandono.
 
 Fechamento técnico, estado canônico da Task, projeções e entrega parental
-precisam ser confirmados separadamente. A preferência avulsa direta não remove
-o gate de executor capturado ainda exigido pelo contrato atual.
+precisam ser confirmados separadamente. A exceção de raiz avulsa direta
+autorizada pertence à compatibilidade do contrato atual; no padrão Codex-native
+da v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois
+caminhos dispensa Evidence, gates e decisão real de Gui.