@zaip-ai/cli 3.8.0 → 4.0.0

package/templates/.agents/README-ENG.md

@@ -6,6 +6,17 @@ English | [Português](README.md)
 
 ## Quick overview
 
+> **Approved v4 target, not a shipped guarantee:** the Codex-native intake,
+> subagent, scheduling, replanning, closure, and numeric display rules below
+> still require implementation and qualification in the exact candidate and
+> installed npm package. The [v4 lifecycle guide](zaip-aios/guides/28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar)
+> distinguishes this target from current behavior and lists observable gates.
+
+The [Codex-native compatibility contract](zaip-aios/guides/28-lifecycle-completo.md#fronteiras-nativas-e-prova-de-compatibilidade)
+separates subagents, hooks, scheduling, and installer requirements. An abrupt
+interruption can leave an attempt pending until the next observable host
+event; a Stop hook cannot guarantee execution after the app stops.
+
 ZAIP-AIOS is an operating system for autonomous work performed by AI agents. It coordinates 23 specialized agents, organized into six squads, within Codex.
 
 Agents plan, execute, review, test, and validate work under the orchestrator's coordination. Authorized execution continues until acceptance or an evidence- and budget-based blocked/failed outcome. Persistent permits indefinite execution by explicit choice; other presets have per-Task quotas. No preset guarantees success or expands authority for external actions.
@@ -202,7 +213,7 @@ The Work (Kanban) and Work (List) views switch between stage reading and detaile
 
 ### Cost Monitor
 
-It consolidates tokens, duration, estimated equivalent cost, and coverage by period and work unit without turning missing telemetry into zero.
+It consolidates tokens, duration, estimated equivalent cost, and coverage by period and work unit without turning missing telemetry into a **canonical** zero. In the v4 visual contract, loaded numeric cards and table cells display `0` rather than “Unavailable” when no measurement exists, with explicit “not measured” coverage; loading displays a skeleton. Records, APIs, exports, and calculations keep `null` for missing values.
 
 <img src="https://raw.githubusercontent.com/zaip-ai/zaip-aios/main/.agents/config/src/dashboard_pt_3_monitor_custos.png" alt="ZAIP-AIOS Dashboard, Cost Monitor" width="100%">
 
@@ -230,16 +241,17 @@ Platform configuration shows ZAIP-AIOS activation state and a summary of agents,
 
 <img src="https://raw.githubusercontent.com/zaip-ai/zaip-aios/main/.agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="ZAIP-AIOS Dashboard, platform configuration" width="100%">
 
-### v3 autonomy presets
+### Autonomy presets: approved v4 target
 
-The sources being prepared for v3 add a per-Task preset, separate from
-installation and assurance:
+The per-Task preset is separate from installation and assurance. The route
+below is approved for v4, but it does not describe the effective behavior of
+every current Codex-native call until implementation and qualification:
 
 | Preset | Product executions per Task | Replans | Replanning models |
 | --- | --- | --- | --- |
 | Essential (`essential`) | 4: 1 initial + 3 repairs | 1 | Sol/high; never automatic Astra |
-| Balanced (`balanced`, new default) | 10: 1 initial + 9 repairs | 3 | Sol/high → Astra/high → Astra/high |
-| Persistent (`persistent`, opt-in) | Unlimited | Unlimited | Sol/high first; Astra/high thereafter |
+| Balanced (`balanced`, v4 default) | 10: 1 initial + 9 repairs | 3 | Sol/high → Sol/high → Astra/high |
+| Persistent (`persistent`, opt-in) | Unlimited | Unlimited | Sol/high for the first two; Astra/high from the third onward |
 
 Merge into `.agents/config/project.yaml`, or select **Autonomy preset** in
 Dashboard **Project settings** and save:
@@ -261,10 +273,13 @@ Missing verification/safe conclusion ends as `blocked`; a proven technical
 impediment ends as `failed`. Independent branches remain eligible.
 
 **Current boundary:** counters are enforced in the managed runtime, not on
-external `spawn_agent` calls made directly by Codex. New projects use
-`execution.runtime: managed`: managed PRDs/SPECs and direct standalone Tasks.
-Saving a preset does not invoke a provider. Legacy Tasks need explicit migration
-without resetting consumption. See [autonomy and its guarantees](zaip-aios/guides/19-assurance-e-autonomia.md).
+every native `spawn_agent` call made directly by Codex. The v4 target makes
+native Codex delegation the default even for standalone Tasks: reserve before
+dispatch, capture observed events, and block when the required model, effort,
+or tool cannot be confirmed. Current templates still use
+`execution.runtime: managed`; saving a preset does not invoke a provider.
+Legacy Tasks need explicit migration without resetting consumption. See
+[autonomy and its guarantees](zaip-aios/guides/19-assurance-e-autonomia.md).
 
 ### Development stack
 
@@ -295,6 +310,13 @@ When they say **“Create a PRD”**, the AI asks up to five important questions
 - a `PreparedPlan`
 - a summarized list of Tasks
 
+“Create and execute this PRD/SPEC” may complete both phases in one Codex turn:
+creation remains an `interaction` Run and implementation uses a separate,
+linked `delivery` Run. “Create” alone remains `draft`; “make ready”
+materializes work without running it; “execute” may start directly without a
+temporary Ready to Execute transition. A critical standalone request may
+recommend a PRD/SPEC without creating or promoting one implicitly.
+
 Technical decisions that can be delegated are made and recorded by the AI.
 
 **Planning, decomposition, and command details**
@@ -325,14 +347,20 @@ When capabilities depend on one another, work must remain in the same SPEC. Proj
 
 ### Command behavior
 
-The `implemente` (“implement”) command considers the current work state:
+The `implemente` (“implement”) command considers intent, target, and state:
 
-* with no defined target, it opens a planning Conversation
-* in `draft`, it completes the plan
+* an independent action request without an explicit PRD/SPEC creates and
+  executes a standalone Task; a reference to an existing macro needs an
+  unambiguous target
+* a `draft` PRD/SPEC executes only when the user explicitly asks to execute
+  that macro; otherwise it remains in planning without promotion
 * in `ready`, it starts execution
 * in active or failed states, it continues, resumes, or starts rework
 
-The `desenvolva`, `melhore`, and `aprimore` (“develop”, “improve”, and “enhance”) commands always return to planning or rework.
+The `desenvolva`, `melhore`, and `aprimore` (“develop”, “improve”, and “enhance”)
+commands preserve intent: an independent action is a standalone Task, while
+refining an existing PRD/SPEC without an execution request remains in
+planning or rework.
 
 A canceled PRD cannot be changed. When necessary, a new rework PRD is created, preserving the link and audit history.
 
@@ -346,10 +374,12 @@ Overview retains the compact **Estimated cost** card. When coverage is incomplet
 the accessible description and tooltip explain coverage without an icon. The
 subtitle allocates known spend across the selected task count and recorded hours;
 these are estimated allocation rates, not averages of complete per-task costs.
-Missing costs are not imputed. Each rate independently displays `—` only when its
-denominator is unavailable or zero, without hiding the other valid rate.
-The subtotal is not the full account cost or a bill. Observed
-zero remains zero, while missing measurements remain unavailable. Unexecuted Task
+Missing costs are not imputed. Under the v4 visual contract, loaded numeric
+cards and cells display `0` with “not measured” coverage when the base is
+missing; loading uses a skeleton. A valid rate is not hidden because another
+rate is unmeasured. The subtotal is not the full account cost or a bill.
+Observed zero and absent measurement share a numeral in the UI but remain
+distinct in coverage and canonical data (`0` versus `null`). Unexecuted Task
 drafts remain in the work list, outside the executable Kanban stages and operational
 indicators that exclude drafts.
 
@@ -496,25 +526,51 @@ This progression allows a simple start, adding planning only when breadth, depen
 
 **Technical execution and assurance policies**
 
-Conversation and standalone Task principals preserve manual host selection and prefer direct work. When delegation is necessary, disclose that children may use different models/efforts under ZAIP policy; they need not inherit the principal. Model and effort remain fixed per Run, with observed configuration separate from planned selection. Automatic selection requests `standard`; unobserved host capabilities cannot be assumed. See the [model policy](zaip-aios/guides/23-orquestracao-de-modelos.md).
+A read-only Conversation preserves manual host selection and does not use
+subagents. In the v4 target, every standalone Task uses native Codex
+subagents; ZAIP chooses each child's model and effort by role, risk, and phase
+without necessarily inheriting the principal's selection. Standalone product
+work is sequential; only a planned PRD/SPEC DAG with independent scopes can
+parallelize it. Planned and observed model/effort remain separate. If the
+required host setting cannot be dispatched or verified, block rather than
+claim a prompt changed it. See the [model policy](zaip-aios/guides/23-orquestracao-de-modelos.md).
 
 ### Astra policy
 
-Essential never selects Astra automatically, including children or fallback. Its sole exception is a standalone principal with Astra selected manually by the user. Balanced replans use Sol/high, Astra/high, and Astra/high; in the third block Astra/high may also execute repairs without expanding the quota. Persistent retains that progression without an overall cap.
-
-Replanners are isolated and do not edit product files; executor, reviewer, and Gui are distinct roles. Automatic Astra uses only `high`, never replaces review/finalization, and depends on managed dispatch. The old cap of three read-only Astra diagnoses remains only in the legacy contract without `autonomy`; it does not limit Persistent. Context and assurance follow the domain: content needs sources/briefing, engineering needs verified behavior. Real savings must be measured, not inferred from a preset.
-
-Intake correlates the observable turn with the Execution. `prepare` validates the plan without authorizing implementation; `ready` materializes prepared work and `execute` starts authorized delivery. Every delivery and delegated interaction requires an eligible executor (or authorized direct Task root) and `zaip-agent-finalizer` last. A read-only interaction without descendants ends after the response, without that circuit. Purely Git publication is an exception: it does not materialize lifecycle records. SPEC/PRD remain active between child Runs and are delivered only through parent gates.
+Essential never selects Astra automatically, including children or fallback.
+Balanced's approved v4 route uses Sol/high, Sol/high, then Astra/high for
+three replans; in the third block Astra/high may also execute an eligible
+repair without expanding the quota. Persistent keeps the progression without
+an overall cap. The native host configuration and ledger still need evidence.
+
+Replanners are isolated and do not edit product files; executor, reviewer, and
+Gui are distinct roles. Automatic Astra uses only `high` and never replaces
+review/finalization. Its preventive control currently depends on managed
+dispatch; the Codex-native target needs preflight before each child spawn.
+The old cap of three read-only Astra diagnoses belongs only to the legacy
+contract without `autonomy`. Real savings must be measured, not inferred.
+
+Intake correlates the observable turn with the Execution. `prepare` validates
+the plan without authorizing implementation; `ready` materializes prepared
+work and `execute` starts authorized delivery. “Create and execute PRD/SPEC”
+uses separate linked definition and delivery Runs in one Codex turn. Delivery
+uses an eligible executor and `zaip-agent-finalizer` last; authorized direct
+Task roots remain a legacy compatibility route. A read-only interaction
+without descendants ends after the response. Purely Git publication is an
+exception. SPEC/PRD reach a terminal decision only after every DAG Task is
+terminal and their parent gates are evaluated.
 
 Each Task attempt has exactly one responsible orchestrator. Gui is its last
 direct child, a sibling of executors, not a finalizer for every worker.
 The host persists the real decision before canonical Stop; it may relay an
-already-terminal Gui while the responsible Run is open, without requiring
-receipt polling. No decision means no approval. Direct standalone work uses an
-observed Task root with explicit direct authorization; no invented executor,
-and no waiver of Evidence or Gui. See [closure and recovery](zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
+already-terminal Gui while the responsible Run is open. No decision means no
+approval. A trusted fallback must persist `blocked` with a reason when the
+finalizer cannot run; the current CLI does not yet prove that path for every
+native Stop or interruption. Direct standalone work with explicit direct
+authorization is a legacy route, not the v4 default. See
+[closure and recovery](zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
 
-Proof depth is adaptive: a standalone `lite` Task requires at least one typed validation and one Evidence, normally one of each, but accepts legitimate additional proof. `standard` requires two or three validations according to `verification_scope` and at least one consolidated Evidence; `critical` requires three or more, independent review, and persisted risk signals determining additional controls. SPEC and PRD deliveries add a parent matrix, at least three validations and three Evidences, real integration, and independent review. New projects default to managed PRDs/SPECs and direct standalone Tasks; Codex or Claude execution requires an explicit request, isolated in worktrees, and limited by write scopes, commits, budgets, and typed gates. See [Adaptive assurance and opt-in autonomy](zaip-aios/guides/19-assurance-e-autonomia.md).
+Proof depth is adaptive: a standalone `lite` Task requires at least one typed validation and one Evidence, normally one of each, but accepts legitimate additional proof. `standard` requires two or three validations according to `verification_scope` and at least one consolidated Evidence; `critical` requires three or more, independent review, and persisted risk signals determining additional controls. SPEC and PRD deliveries add a parent matrix, at least three validations and three Evidences, real integration, and independent review. Current templates use managed PRDs/SPECs and direct standalone Tasks; after implementation and installer qualification, v4 targets Codex-native as the operational default. Worktrees, write scopes, budgets, commits, and typed gates still apply where relevant. See [Adaptive assurance and opt-in autonomy](zaip-aios/guides/19-assurance-e-autonomia.md).
 
 ## Autonomous engineering principles
 
@@ -541,7 +597,7 @@ Intake captures once per observable turn and reuses valid focus in continuations
 
 This autonomy remains governed: Dave coordinates, each executor receives only the necessary scope, Nanda performs independent review, additional specialists join when objective signals exist, and Gui closes the flow last. The result is a team tailored to the request without unnecessarily multiplying agents and cost.
 
-**Loop Engineering** uses the Task's frozen preset to reserve execution and replanning before the provider, record the result, and choose a corrected route. Balanced allows 1 + 9 executions and three plans: Sol/high → Astra/high → Astra/high; Essential never escalates to Astra, Persistent has no cap. Models never change silently within a Run. A standalone principal's manual preference does not require children to use the same configuration.
+**Loop Engineering** uses the Task's frozen preset to reserve execution and replanning before dispatch, record the result, and choose a corrected route. The Balanced v4 target allows 1 + 9 executions and three plans: Sol/high → Sol/high → Astra/high; Essential never escalates to Astra, Persistent has no cap. Models never change silently within a Run. ZAIP selects child models subject to host capability.
 
 ### Summary flow
 
@@ -553,7 +609,7 @@ Complete scenarios are in the [flows and routing guide](zaip-aios/guides/22-flux
 
 The lifecycle follows **Definition → Planning → Ready to Execute → Execution → Verification → Completed**. Blocked, Failed, and Canceled are alternative outcomes.
 
-Task, SPEC, and PRD retain independent flows; Conversation uses an interaction Execution and creates no artificial Task. A direct Task starts immediately, while a prepared one awaits execute.
+Task, SPEC, and PRD retain independent flows; Conversation uses an interaction Execution and creates no artificial Task. Under the v4 target, a standalone action starts a Task with native subagents; a merely prepared Task awaits execute. Each physical Task attempt needs a terminal result before its responsible Run closes. SPEC/PRD terminalization waits for every DAG Task and the applicable parent gates.
 
 ![Task, SPEC, and PRD lifecycles](zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)
 
@@ -803,7 +859,7 @@ The [complete ZAIP-AIOS permission-profile security guide](zaip-aios/guides/10-s
 
 In Codex Desktop, hourly ready-queue scheduling is configured by the `$zaip-skill-instalar-agendamento` skill in a single conversation in the local checkout. The skill uses native scheduled-task automation to create or update one standalone task with a stable name; it does not duplicate records and fails closed if `automation_update` is unavailable. The scheduled task explicitly calls `$zaip-skill-executar-fila-pronta` each hour.
 
-Each round processes the eligible snapshot sequentially: ready PRDs first, then independent ready SPECs, then standalone Tasks materialized in **Ready to Execute**. Descendant, active, blocked, failed, and terminal items stay out. In **Dashboard > Work (Kanban) > Ready to Execute**, priority is set top to bottom within the PRD/SPEC/Task tier and persists for the scheduler in `.agents/dashboard/work-priority.json`. Accessible ordering controls update that numbering, and items without a number go last through deterministic fallback. A local lock/lease prevents overlapping rounds.
+Under the approved v4 target, each hourly round claims **one** eligible top-level item: ready PRDs first, then independent ready SPECs, then standalone Tasks in **Ready to Execute**. The visual route is Dashboard > Work (Kanban) > Ready to Execute. Descendants and active or terminal items are ineligible. Within each class, the Dashboard's up/down priority persists in `.agents/dashboard/work-priority.json`; items without a number use a deterministic fallback. A lock/lease prevents overlapping claims. The current executor still walks the whole eligible snapshot, so do not claim this one-item rule is implemented yet.
 
 The repository versions this contract but does not install a clock in each clone. The scheduled task belongs to the machine/user who created it and depends on the machine being on, Codex Desktop running, and native automation being available; without them the skill fails closed and does not promise future execution.
 

package/templates/.agents/README.md

@@ -6,6 +6,18 @@
 
 ## Visão rápida
 
+> **Contrato-alvo da v4.0:** as decisões de fluxo Codex-native, subagentes, fila,
+> replanejamento e apresentação de métricas descritas abaixo estão aprovadas para
+> implementação. Esta revisão documental não comprova que o runtime, os hooks,
+> o Dashboard ou o pacote publicado já as executem; cada garantia exige teste
+> no candidato exato e no consumidor instalado. O contrato completo está no
+> [guia de lifecycle v4](zaip-aios/guides/28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar).
+
+O [contrato de compatibilidade Codex-native](zaip-aios/guides/28-lifecycle-completo.md#fronteiras-nativas-e-prova-de-compatibilidade)
+explicita o que depende de subagentes, hooks, automação agendada e do
+instalador. Interrupção abrupta pode deixar uma tentativa pendente até o
+próximo evento do host; um Stop hook não garante execução após o app parar.
+
 O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
 
 Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios ou registrar bloqueio/falha conforme evidências e orçamento. O perfil Persistente permite execução indefinida por escolha explícita; os demais têm cotas por Task. Nenhum perfil garante acerto nem amplia autoridade para ações externas.
@@ -215,13 +227,13 @@ As visões Trabalho (Kanban) e Trabalho (Lista) permitem alternar entre leitura
 
 ### Monitor de Custos
 
-Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero.
+Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero **canônico**. No contrato visual v4, cards e tabelas numéricas já carregados mostram `0` em vez de “Indisponível”, acompanhados de cobertura “sem medição”; durante loading mostram skeleton. API e arquivos continuam `null` quando não há medição.
 
 <img src="https://raw.githubusercontent.com/zaip-ai/zaip-aios/main/.agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">
 
 O Monitor consolida tokens, tempo, custo e cobertura por Run, Task, SPEC e PRD. Isso permite comparar conversa, planejamento, execução, trabalho novo e rework, além de identificar médias e concentrações de consumo por dia, mês ou ano.
 
-Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam `unknown`, sem serem convertidos artificialmente em zero.
+Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam `unknown` na fonte; o `0` visual da v4 não entra nos cálculos.
 
 **Contrato técnico da telemetria**
 
@@ -250,16 +262,17 @@ A configuração da plataforma apresenta o estado de ativação do ZAIP-AIOS e u
 
 <img src="https://raw.githubusercontent.com/zaip-ai/zaip-aios/main/.agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="Dashboard ZAIP-AIOS, configuração da plataforma" width="100%">
 
-### Perfis de autonomia da v3
+### Perfis de autonomia: contrato-alvo da v4
 
-As fontes em preparação para a v3 acrescentam um preset por Task, separado de
-instalação e assurance:
+O preset por Task é separado de instalação e assurance. A rota abaixo é a
+decisão aprovada para a v4; o runtime atual ainda precisa ser alterado e
+qualificado antes que esta tabela descreva seu comportamento efetivo:
 
 | Perfil | Execuções de produto por Task | Replanejamentos | Modelos dos replanejamentos |
 | --- | --- | --- | --- |
 | Essencial (`essential`) | 4: 1 inicial + 3 reparações | 1 | Sol/high; nunca Astra automático |
-| Equilibrado (`balanced`, padrão novo) | 10: 1 inicial + 9 reparações | 3 | Sol/high → Astra/high → Astra/high |
-| Persistente (`persistent`, opt-in) | Sem teto | Sem teto | Sol/high primeiro; Astra/high nos seguintes |
+| Equilibrado (`balanced`, padrão) | 10: 1 inicial + 9 reparações | 3 | Sol/high → Sol/high → Astra/high |
+| Persistente (`persistent`, opt-in) | Sem teto | Sem teto | Sol/high nos dois primeiros; Astra/high no terceiro e seguintes |
 
 Mescle no arquivo `.agents/config/project.yaml` ou selecione **Perfil de
 autonomia** em **Configurações do projeto** no Dashboard e salve:
@@ -281,10 +294,16 @@ A falta de verificação/conclusão segura termina `blocked`; impedimento técni
 comprovado termina `failed`. Ramos independentes continuam elegíveis.
 
 **Limite atual:** os contadores são impostos no runtime gerenciado, não em
-`spawn_agent` externo feito diretamente pelo Codex. Novos projetos usam
-`execution.runtime: managed`: PRD/SPEC gerenciados e avulsas diretas. Salvar
-o preset não inicia provider. Legados exigem migração explícita, sem zerar
-consumo. Veja [autonomia e suas garantias](zaip-aios/guides/19-assurance-e-autonomia.md).
+`spawn_agent` externo feito diretamente pelo Codex. O contrato-alvo torna a
+colaboração nativa do Codex o caminho operacional padrão também para Tasks
+avulsas: cada tentativa reserva seu orçamento antes do despacho, usa
+subagente nativo e registra eventos observados. Se o host não oferecer o
+modelo, effort ou ferramenta exigidos, a tentativa bloqueia com causa
+explícita; instrução ou captura posterior não são controle preventivo.
+O candidato local v4 usa `execution.runtime: codex_native` no builder e no
+template do instalador; o npm publicado ainda precisa ser qualificado separadamente.
+Salvar o preset não inicia provider. Legados não têm
+quota zerada. Veja [autonomia e suas garantias](zaip-aios/guides/19-assurance-e-autonomia.md).
 
 ### Stack de desenvolvimento
 
@@ -347,12 +366,17 @@ Quando existe dependência entre capacidades, o trabalho deve permanecer na mesm
 
 O comando `implemente` considera o estado atual do trabalho:
 
-* sem alvo definido, abre uma Conversation de planejamento
-* em `draft`, conclui o plano
+* com pedido de ação independente, mas sem PRD/SPEC explícito, cria e executa
+  uma Task avulsa; referência a um macro existente exige alvo inequívoco
+* em PRD/SPEC `draft`, só executa se a intenção de execução do macro for
+  explícita; caso contrário, conclui o plano sem promover
 * em `ready`, inicia a execução
 * em estados ativos ou com falha, continua, retoma ou inicia o rework
 
-Os comandos `desenvolva`, `melhore` e `aprimore` sempre retornam ao planejamento ou ao rework.
+Os comandos `desenvolva`, `melhore` e `aprimore` preservam a intenção: com
+objetivo independente de ação, entram como Task avulsa; para lapidar um
+PRD/SPEC existente sem pedido de execução, permanecem no planejamento ou
+rework em `draft`.
 
 Um PRD cancelado não pode ser alterado. Quando necessário, um novo PRD de rework é criado, preservando o vínculo e o histórico de auditoria.
 
@@ -367,10 +391,13 @@ mantém o cartão compacto **Custo Estimado**, sem ícone. A descrição acessí
 tooltip informam a cobertura. O subtítulo divide o subtotal conhecido pelo número
 de tarefas e pelas horas registradas no mesmo recorte: são taxas estimadas de
 alocação, não médias de custos completos por tarefa. Com cobertura parcial, não
-estima os valores ausentes. Cada taxa fica `—` apenas se sua base estiver indisponível
-ou for zero; uma taxa válida não é escondida porque a outra está indisponível.
-O subtotal não é o custo integral nem a fatura da conta. Zero observado continua sendo zero;
-ausência de medição continua indisponível. Rascunhos de Task ficam na lista de
+estima os valores ausentes. No contrato visual da v4, cards e células numéricas
+já carregados exibem `0` quando a base não foi medida, com cobertura/tooltip
+“sem medição”; durante loading mostram esqueleto, não zero. Uma taxa válida não
+é escondida porque outra não foi medida. O subtotal não é custo integral nem
+fatura da conta. Zero observado e ausência de medição têm o mesmo numeral na
+interface, mas continuam distintos por cobertura e no dado canônico (`0` versus
+`null`). Rascunhos de Task ficam na lista de
 trabalho, fora do Kanban executável e dos indicadores operacionais sem rascunhos.
 
 
@@ -525,33 +552,33 @@ Essa progressão permite começar de forma simples e acrescentar planejamento ap
 
 **Políticas técnicas de execução e assurance**
 
-Conversation e o principal de Task avulsa preservam a seleção manual do host, priorizando trabalho direto. Quando delegar for necessário, informe que os filhos podem usar modelos/esforços diferentes pela política ZAIP; não há obrigação de herdar o principal. Modelo e effort ficam fixos por Run, com observação efetiva separada da seleção planejada. A seleção automática solicita `standard`; capacidade não observada do host não pode ser presumida. Consulte a [política de modelos](zaip-aios/guides/23-orquestracao-de-modelos.md).
+Conversation sem trabalho executável preserva a seleção manual do host e não usa subagentes. No contrato-alvo da v4, toda Task avulsa usa subagentes nativos Codex; o ZAIP seleciona modelo e effort de cada filho conforme papel, risco e fase, sem herdar necessariamente a seleção do principal. A Task avulsa é sequencial; paralelismo produtivo só ocorre em DAGs planejadas de PRD/SPEC com independência e escopos compatíveis. Modelo e effort ficam fixos por Run, com observação efetiva separada da seleção planejada. Se a configuração requerida não puder ser despachada/confirmada no host, bloqueie em vez de afirmar que o prompt trocou o modelo. Consulte a [política de modelos](zaip-aios/guides/23-orquestracao-de-modelos.md).
 
 ### Política Astra
 
-No Essencial, Astra nunca é selecionado automaticamente, inclusive em filhos ou fallback. A única exceção é o principal avulso com Astra escolhido manualmente pelo usuário. No Equilibrado, os três replanejamentos usam Sol/high, Astra/high e Astra/high; no terceiro bloco Astra/high também pode executar a reparação, sem ampliar a quota. Persistente mantém essa progressão sem teto total.
+No Essencial, Astra nunca é selecionado automaticamente, inclusive em filhos ou fallback. No Equilibrado, os três replanejamentos usam Sol/high, Sol/high e Astra/high; no terceiro bloco Astra/high também pode executar a reparação, se a rota elegível o selecionar, sem ampliar a quota. Persistente mantém essa progressão sem teto total. Essa é uma política-alvo: a configuração real do agente Codex e o ledger devem ser verificados, não inferidos do texto.
 
-O replanejador é isolado e não edita produto; executor, revisor e Gui são papéis distintos. Astra automático usa somente `high`, não substitui revisão/finalização e depende do despacho gerenciado. A regra antiga de até três diagnósticos Astra somente leitura permanece apenas no contrato legado sem `autonomy`; não limita Persistente. Contexto e assurance seguem o domínio: conteúdo exige fontes/briefing, engenharia exige comportamento verificável. Economia real precisa ser medida, não inferida do preset.
+O replanejador é isolado e não edita produto; executor, revisor e Gui são papéis distintos. Astra automático usa somente `high` e não substitui revisão/finalização. Hoje seu controle preventivo depende do despacho gerenciado; no contrato-alvo Codex-native, exige preflight efetivo antes de cada filho nativo. A regra antiga de até três diagnósticos Astra somente leitura permanece apenas no contrato legado sem `autonomy`; não limita Persistente. Contexto e assurance seguem o domínio: conteúdo exige fontes/briefing, engenharia exige comportamento verificável. Economia real precisa ser medida, não inferida do preset.
 
-O intake correlaciona o turno observável à Execution. `prepare` valida o plano, sem autorizar implementação; `ready` materializa trabalho preparado e `execute` inicia a entrega autorizada. Toda delivery e interaction delegada exige executor elegível (ou raiz Task direta autorizada) e `zaip-agent-finalizer` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
+O intake correlaciona o turno observável à Execution. `prepare` valida o plano, sem autorizar implementação; `ready` materializa trabalho preparado e `execute` inicia a entrega autorizada. “Crie e execute PRD/SPEC” cabe no mesmo turno do Codex, mas usa uma Run canônica de definição e outra de delivery, vinculadas: nunca se converte a primeira em Run de implementação. Toda delivery e interaction delegada exige executor elegível e `zaip-agent-finalizer` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
 
 Cada tentativa de Task tem exatamente um orquestrador responsável. Gui é seu
 último filho direto, irmão dos executores, não finalizador de cada trabalhador.
 O host persiste a decisão real antes do Stop canônico; pode retransmitir Gui
 já terminal enquanto o responsável estiver aberto, sem obrigá-lo a esperar
-recibos. Ausência de decisão não é aprovação. A preferência por execução
-avulsa direta usa uma raiz observada com `--direct-authorization REFERÊNCIA`
-explícita; não cria executor fictício nem dispensa Evidence e Gui. Veja
+recibos. Ausência de decisão não é aprovação. A compatibilidade com execução
+avulsa direta antiga usa uma raiz observada com `--direct-authorization REFERÊNCIA`
+explícita; não é o caminho padrão novo, não cria executor fictício nem dispensa Evidence e Gui. Veja
 [fechamento e recuperação](zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
 
-A profundidade de prova é adaptativa: Task standalone `lite` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. `standard` exige duas ou três validações conforme `verification_scope` e pelo menos uma Evidence consolidada; `critical` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. Novos projetos usam runtime gerenciado para PRD/SPEC e direto para avulsas; a execução por Codex ou Claude é autorizada por pedido, isolada em worktrees e limitada por write scopes, commits, budgets e gates tipados. Consulte [Assurance adaptativa e autonomia opt-in](zaip-aios/guides/19-assurance-e-autonomia.md).
+A profundidade de prova é adaptativa: Task standalone `lite` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. `standard` exige duas ou três validações conforme `verification_scope` e pelo menos uma Evidence consolidada; `critical` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. O candidato local v4 usa Codex-native como modo padrão; o npm publicado anteriormente mantém o contrato da sua versão e exige validação separada. Worktrees, write scopes, commits, budgets e gates tipados continuam exigidos onde aplicáveis. Compatibilidade de outros hosts não equivale à garantia Codex-native. Consulte [Assurance adaptativa e autonomia opt-in](zaip-aios/guides/19-assurance-e-autonomia.md).
 
 
 ## Princípios de engenharia autônoma
 
 O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm o código sustentável, distribuem apenas o contexto necessário e exigem comprovação proporcional ao risco.
 
-O padrão do schema é `execution.runtime: manual` quando a opção está ausente; este checkout usa `managed` em `project.yaml`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
+O padrão do schema é `execution.runtime: manual` quando a opção está ausente; este checkout usa `codex_native` em `project.yaml`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
 
 - **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
 - **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
@@ -572,7 +599,7 @@ O **Graph Engineering** transforma uma entrega complexa em uma sequência coorde
 
 Essa autonomia permanece governada: Dave coordena, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas adicionais entram quando existem sinais objetivos e Gui encerra o fluxo por último. O resultado é uma equipe ajustada à demanda, sem multiplicar agentes e custo sem necessidade.
 
-O **Loop Engineering** usa o perfil congelado da Task para reservar execução e replanejamento antes do provider, registrar o resultado e escolher uma rota corrigida. No Equilibrado são 1 + 9 execuções e três planos Sol/high → Astra/high → Astra/high; Essencial não escala para Astra, Persistente não tem teto. O modelo não muda silenciosamente dentro da mesma Run. A preferência manual do principal avulso não obriga seus filhos a usar a mesma configuração.
+O **Loop Engineering** usa o perfil congelado da Task para reservar execução e replanejamento antes do despacho, registrar o resultado e escolher uma rota corrigida. No contrato-alvo Equilibrado são 1 + 9 execuções e três planos Sol/high → Sol/high → Astra/high; Essencial não escala para Astra, Persistente não tem teto. O modelo não muda silenciosamente dentro da mesma Run. O modelo dos filhos é escolhido pelo ZAIP e precisa ser compatível com o host.
 
 ### Fluxo resumido
 
@@ -584,7 +611,7 @@ Os cenários completos ficam no [guia de fluxos e roteamento](zaip-aios/guides/2
 
 O lifecycle segue **Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído**. Bloqueado, Falhado e Cancelado são saídas alternativas.
 
-Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. A Task direta inicia imediatamente, enquanto a preparada aguarda execute.
+Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. Pedido avulso de ação inicia Task com subagentes no contrato-alvo; Task apenas preparada aguarda execute. Cada tentativa física de Task fecha como concluída, bloqueada, falhada ou cancelada antes do encerramento da Run raiz. SPEC/PRD só recebem estado terminal depois de todas as Tasks da DAG terem estado terminal e dos gates parentais aplicáveis.
 
 ![Lifecycles de Task, SPEC e PRD](zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)
 
@@ -859,7 +886,7 @@ rollout, rollback e comandos de verificação estão documentados no
 
 No Codex Desktop, o agendamento horário da fila pronta é configurado pela skill `$zaip-skill-instalar-agendamento` em uma única conversa no checkout local. A skill usa a automação nativa de tarefas agendadas para criar ou atualizar uma tarefa standalone com nome estável; ela não duplica registros e falha fechada se a capacidade `automation_update` não estiver disponível. A tarefa agendada chama explicitamente `$zaip-skill-executar-fila-pronta` em cada rodada horária.
 
-A rodada processa sequencialmente todo o snapshot elegível: primeiro PRDs em `ready`, depois SPECs `ready` independentes e, por último, Tasks avulsas materializadas em **Pronto para Executar**. Itens descendentes, ativos, bloqueados, falhos ou terminais ficam fora. Em **Dashboard > Trabalho (Kanban) > Pronto para Executar**, a prioridade é definida pela numeração de cima para baixo dentro do tier PRD/SPEC/Task e persiste para o scheduler em `.agents/dashboard/work-priority.json`; os controles acessíveis de ordenação atualizam essa numeração, e itens sem número vão para o fim pelo fallback determinístico. Um lock/lease local evita sobreposição entre rodadas.
+No contrato-alvo da v4, cada rodada horária reivindica **um único item de nível superior** elegível: primeiro PRDs em `ready`, depois SPECs `ready` independentes e, por último, Tasks avulsas em **Pronto para Executar**. A rota visual é Dashboard > Trabalho (Kanban) > Pronto para Executar. Nunca seleciona descendentes separadamente. Dentro de cada classe, segue as setas de prioridade do Dashboard, persistidas em `.agents/dashboard/work-priority.json`; itens sem número usam fallback determinístico. Itens ativos, bloqueados, falhos, cancelados ou concluídos ficam fora. O lock/lease impede sobreposição. A skill instala/atualiza a automação nativa somente a pedido do usuário; cada rodada exige um evento real do Codex e não executa sozinha depois que o host parar. O executor atual ainda percorre o snapshot inteiro e precisa mudar antes de se alegar esse comportamento.
 
 O repositório versiona esse contrato, mas não instala um relógio em cada clone. A tarefa agendada pertence à máquina/usuário que a criou e depende da máquina ligada, do Codex Desktop em execução e da automação nativa disponível; sem eles, a skill falha fechada e não promete execução futura.
 

package/templates/.agents/config/agents/discovery.json

@@ -1,5 +1,5 @@
 {
-  "_zaip_managed": "zaip-managed generated-do-not-edit source=agent-discovery version=3.8.0 sha256=3def7a2b43c1a751f8e68754ef94cb107a80b5d26e11f065af2b4cc145fc8897",
+  "_zaip_managed": "zaip-managed generated-do-not-edit source=agent-discovery version=4.0.0 sha256=3def7a2b43c1a751f8e68754ef94cb107a80b5d26e11f065af2b4cc145fc8897",
   "schema_version": 1,
   "source": {
     "path": ".agents/config/agents/catalog.yaml",

package/templates/.agents/config/clients/codex/agents/zaip-agent-orchestrator.toml

@@ -22,7 +22,7 @@ Do not use when: Direct implementation, independent review, or approval..
 Keep orchestrator and delegated Run telemetry distinct; preserve observed duration, tokens, and cost as unavailable when not captured.
 Coordinate bounded independent branches, then wait for terminal events; do not poll delegated agents or implement Task work directly.
 Load .agents/rules/specialist-routing.md before selecting commercial specialists; it defines the primary-output decision matrix and minimal-executor invariant.
-Load RULE-AUTONOMY-DECISION for a frozen autonomy-v1 Task: essential forbids automatic Astra, balanced uses Sol/high then two Astra/high replans (Astra executor eligible in the third block), persistent has no total cap. Legacy Tasks alone follow RULE-ASTRA-DIAGNOSTIC and its diagnostic-only quota. Never infer deterministic enforcement from this prompt: the host must reserve and validate the effective dispatch before calling a model.
+Load RULE-AUTONOMY-DECISION for a frozen autonomy-v1 Task: essential forbids automatic Astra, balanced uses Sol/high, Sol/high, then Astra/high replans (Astra executor eligible in the third block), persistent has no total cap. Legacy Tasks alone follow RULE-ASTRA-DIAGNOSTIC and its diagnostic-only quota. Never infer deterministic enforcement from this prompt: the host must reserve and validate the effective dispatch before calling a model.
 You are the dispatcher for your Task attempt. If the physical root already owns exactly this Task, it is the responsible orchestrator: it dispatches executors/reviewers and Gui directly, without an extra Dave child. A macro root dispatches one Task orchestrator per eligible Task and must not dispatch that Task's workers itself. Never create two responsible orchestrators or require two Guis for the same Task attempt. Never reassign your invocation to another Task.
 Tool names in the catalog are capability labels, not literal host tool names. Native collaboration permits spawn_agent, send_input, wait_agent and close_agent for authorized descendants. Discover deferred native tools through the host tool registry before declaring them unavailable. Read-only filesystem permissions do not prohibit native delegation or waiting; do not use discovery to run persistence commands, bypass permissions or create independent chats.
 Report child IDs and intermediate results as non-terminal progress, not a final response. Keep your native invocation open until the executor/reviewer and last Gui child have terminated. If you cannot remain active or complete that sequence, report an explicit blocked interruption; do not claim the attempt is finalized.

package/templates/.agents/config/project.yaml

@@ -51,14 +51,28 @@ deploy:
   branch: beta
   production_branch: main
   allow_production: false
+model_orchestration:
+  mode: auto
+  default_model: gpt-6-sol
+  default_effort: medium
+  default_velocity: standard
+  allowed_models:
+    - gpt-6-luna
+    - gpt-6-sol
+    - gpt-6-astra
+  allowed_efforts:
+    - low
+    - medium
+    - high
+    - xhigh
+  max_auto_effort: xhigh
+  automatic_sources:
+    - spec
+    - prd
+  notice: mismatch
 execution:
-  # Managed PRD/SPEC dispatch; standalone Tasks stay direct.
-  runtime: managed
-  autonomous:
-    provider: codex
-    model: gpt-6-sol
-    max_parallelism: 1
-    lease_ms: 60000
+  # Codex owns native Sub-Runs; no separate provider process is launched.
+  runtime: codex_native
 autonomy:
   version: 1
   preset: balanced