@zaip-ai/cli 3.7.0 → 4.0.0

package/templates/.agents/skills/zaip-skill-github-deploy/scripts/github-deploy-contract.test.mjs

@@ -20,6 +20,13 @@ const managedDeployFiles = [
 
 test("framework lock matches the deploy guidance and executable contract", async () => {
   const lock = await readFile(resolve(root, "config", "framework.lock.yaml"), "utf8");
+  const installerPlaceholder = "# Generated transactionally by @zaip-ai/cli during installation.\n";
+  if (lock === installerPlaceholder) {
+    // The npm template deliberately ships no repository-specific hashes. The
+    // installer creates the complete lock only after projecting the selected
+    // profile into the consumer workspace.
+    return;
+  }
   for (const path of managedDeployFiles) {
     const digest = createHash("sha256")
       .update(await readFile(resolve(root, path)))
@@ -35,24 +42,52 @@ test("explicit Git publication verbs select the guarded deploy skill", async ()
     readFile(resolve(root, "rules", "core.md"), "utf8"),
   ]);
   assert.match(skill, /explicit current-turn request to `deploy`, `push`, `publicar`/);
-  assert.match(skill, /never grants publication automatically/);
+  assert.match(skill, /discussing or editing deployment does not authorize publication/);
   assert.doesNotMatch(skill, /standing automatic deployment|activate it automatically/);
   assert.match(openai, /\$zaip-skill-github-deploy/);
   assert.match(openai, /fa.a deploy/);
   assert.match(core, /seleciona/);
 });
 
-test("deploy guidance preserves the canonical Task subject and Git-only boundary", async () => {
+test("deploy guidance preserves canonical Task identity and builder-versus-consumer boundary", async () => {
   const [skill, workflow] = await Promise.all([
     readFile(resolve(skillRoot, "SKILL.md"), "utf8"),
     readFile(resolve(root, "rules", "workflow.md"), "utf8"),
   ]);
   assert.ok(skill.includes("[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>"));
   assert.match(skill, /exclusively `CODEX` or `CLAUDE`; `AUTO` is not part/);
-  assert.match(skill, /Git-only publication/);
+  assert.match(skill, /Consumer repositories follow their own GitHub-only policy/);
+  assert.match(
+    skill,
+    /“faça deploy” means the guarded push, GitHub Release and observation of the GitHub Actions npm publication/,
+  );
   assert.match(workflow, /commitar o diff evidenciado com pathspecs explícitos/);
 });
 
+test("framework deploy follows Release-triggered npm publication without claiming partial success", async () => {
+  const [skill, workflow, lock] = await Promise.all([
+    readFile(resolve(skillRoot, "SKILL.md"), "utf8"),
+    readFile(resolve(skillRoot, "references", "deployment-workflow.md"), "utf8"),
+    readFile(resolve(root, "config", "framework.lock.yaml"), "utf8"),
+  ]);
+  if (!lock.startsWith("# Generated transactionally by @zaip-ai/cli")) {
+    const publishWorkflow = await readFile(
+      resolve(root, "..", ".github", "workflows", "publish-cli.yml"),
+      "utf8",
+    );
+    assert.match(publishWorkflow, /release:\s*\n\s*types: \[published\]/);
+    assert.match(publishWorkflow, /npm publish /);
+  }
+  assert.match(skill, /publish-cli\.yml.*registry confirmation/s);
+  assert.match(skill, /npm fails or cannot be observed.*partial or blocked/);
+  assert.match(skill, /explicit push-only request.*does not create a Release or publish npm/);
+  assert.match(
+    workflow,
+    /private Ed25519 release key is distinct from the Git SSH key and a local `\.env` npm token/,
+  );
+  assert.match(workflow, /A published Release with failed or unobserved npm is partial/);
+});
+
 test("faça deploy authorizes the complete selected worktree with safety gates", async () => {
   const skill = await readFile(resolve(skillRoot, "SKILL.md"), "utf8");
   assert.match(skill, /commits covering all versionable pending changes/);
@@ -73,8 +108,8 @@ test("deploy permission and reconciliation remain explicit and recoverable", asy
   assert.match(skill, /Restore with `git stash apply`/);
   assert.match(skill, /local branch, recovery branch or detached state as the source candidate/);
   assert.match(skill, /configured deploy branch is the remote target/);
-  assert.match(openai, /worktree selecionado inteiro como escopo autorizado/);
-  assert.match(openai, /branch local ou detached como origem/);
+  assert.match(openai, /\$zaip-skill-github-deploy/);
+  assert.match(openai, /builder zaip-aios.*Release.*workflow npm/);
 });
 
 test("workflow retains the explicit publication routing contract", async () => {

package/templates/.agents/skills/zaip-skill-instalar-agendamento/SKILL.md

@@ -8,10 +8,10 @@ description: Install or update the native Codex hourly scheduler for the ready-w
 Use esta skill somente quando a pessoa solicitar instalar, atualizar ou verificar o agendamento local da fila pronta. Ela configura o relógio; não inicia uma execução por conta própria.
 
 1. Confirme que o repositório é ZAIP habilitado e que a automação nativa de tarefas agendadas do Codex Desktop está chamável, com capacidade `automation_update`. Pare com `blocked` se ela não estiver disponível. Nunca use o Agendador do Windows, um arquivo, Git ou uma promessa de execução futura como substituto.
-2. Use `codex_app list_projects` para resolver o projeto Codex atual e seu checkout local real; não invente identificador, diretório ou contexto. Crie ou atualize, sem duplicar, a tarefa standalone de nome estável `ZAIP-AIOS - Fila Pronta Horária`: a cada hora, no minuto 0, em nova conversa no projeto resolvido. Ela abre uma única invocação com o prompt explícito `Ignore Automation memory and $CODEX_HOME. Start immediately by validating the repository and ready queue. First call codex_app set_thread_title without threadId, using America/Sao_Paulo local time in the exact format [YYYY-MM-DD-T-HH-mm] Tarefa Agendada; record a rename failure but continue the queue. Use $zaip-skill-executar-fila-pronta; this user-installed schedule authorizes only canonically ready/eligible items, never promotes draft or resumes blocked or failed work; respect the persisted manual order in .agents/dashboard/work-priority.json.`
+2. Use `codex_app list_projects` para resolver o projeto Codex atual e seu checkout local real; não invente identificador, diretório ou contexto. Crie ou atualize, sem duplicar, a tarefa standalone de nome estável `ZAIP-AIOS - Fila Pronta Horária`: a cada hora, no minuto 0, em nova conversa no projeto resolvido. Ela abre uma única invocação com o prompt explícito `Ignore Automation memory and $CODEX_HOME. Start immediately by validating the repository and ready queue. First call codex_app set_thread_title without threadId, using America/Sao_Paulo local time in the exact format [YYYY-MM-DD-T-HH-mm] Tarefa Agendada; record a rename failure but continue the queue. Use $zaip-skill-executar-fila-pronta; execute at most one top-level eligible item in this invocation, even if it finishes or becomes ineligible; never promote draft or resume blocked or failed work; respect the persisted manual order in .agents/dashboard/work-priority.json.`
 3. Antes de gravar, valide o checkout: raiz Git existente, `.agents/config/project.yaml` com `zaip.enabled: true`, runtime ZAIP disponível e caminho absoluto sem credenciais. Falhe fechado se algum requisito faltar; não registre uma tarefa parcial.
 4. Consulte `$CODEX_HOME/automations/*/automation.toml` somente em leitura, exclusivamente pelo nome estável para resolver identidade e deduplicação. É proibido criar, editar ou apagar TOML, ou usá-lo como fallback. Todas as visualizações e mutações da automação são exclusivamente por `codex_app automation_update`. Se houver mais de uma tarefa com esse nome, pare e reporte o conflito sem apagar nada. Se houver uma, inspecione seu ID, ação, agenda horária, nova conversa e diretório de trabalho e atualize-a; se não houver, crie uma. Preserve tarefas agendadas fora desse nome.
-5. Verifique após criar/atualizar que existe exatamente uma tarefa com o nome, agenda a cada hora no minuto 0, nova conversa, checkout esperado e prompt da skill executora que respeita `.agents/dashboard/work-priority.json`. Registre somente a evidência observada; não afirme que uma hora futura será executada.
+5. Verifique após criar/atualizar que existe exatamente uma tarefa com o nome, agenda a cada hora no minuto 0, nova conversa, checkout esperado e prompt da skill executora que respeita `.agents/dashboard/work-priority.json` e limita a rodada a um item superior. Registre somente a evidência observada; não afirme que uma hora futura será executada.
 6. Explique que o agendamento pertence à máquina e ao usuário que o instalou. O repositório versiona a skill e o contrato, mas não cria um relógio em clones, nem funciona com a máquina desligada, o Codex Desktop fechado ou sem a automação nativa.
 
 Não use esta skill para selecionar itens, burlar bloqueios, executar todos os itens `planned`, alterar prioridades do Kanban ou fazer deploy/push.

package/templates/.agents/skills/zaip-skill-release-qualification/SKILL.md

@@ -19,6 +19,12 @@ policy, gate definitions, runtime, channel, version, trusted key, expiry and art
 Consumer projects run their own policy commands through the distributed consumer helper, with
 their configured branch (default `beta`) and no framework npm requirements.
 The deployment skill must call the guarded helper, which prepares and verifies before sending.
+A framework signing key is resolved from the stable private directory
+`~/.codex/release-keys/zaip-aios/<trusted-key-id>/` unless explicit paths are supplied.
+Run `scripts/local-release-key.mjs preflight` before expensive gates; compare the local key
+and trust with GitHub when publishing. A missing or mismatched key fails closed. Do not
+silently generate a replacement, reuse a key ID for different key material, or remove the
+signature gate. See the local preparation guide for testing and controlled rotation.
 A changed candidate or invalid evidence requires new qualification.
 Full source qualification runs locally. Extended GitHub qualification is manual;
 the reduced publisher requires enrolled public trust and signed local qualification.

package/templates/.agents/skills/zaip-skill-release-qualification/references/local-preparation.md

@@ -4,6 +4,43 @@ Preparation does not authorize publication. Use guarded delivery only for an exp
 Store keys, trust stores, receipts and artifacts outside the repository. Commit and synchronize first;
 every gate is bound to the resulting clean SHA. Repair changes require a new candidate.
 
+The signing key ID is the trusted identity, not a filename. Resolve it with
+`gh variable get ZAIP_LOCAL_RELEASE_TRUSTED_KEY_ID --repo zaip-ai/zaip-aios`.
+By default, the private key lives at
+`~/.codex/release-keys/zaip-aios/<key-id>/release-private.pem` and its local
+trust store at `~/.codex/release-keys/zaip-aios/<key-id>/trust/` on the current
+machine. This location is shared by the machine's worktrees but never by Git.
+Keep a secure backup and restrict OS access; Git ignore alone does not protect a
+private key. `.local/` may hold a pointer or disposable test evidence, but must not
+be the only copy of a production signing key.
+
+Run `node scripts/local-release-key.mjs preflight --key-id <trusted-key-id> --channel latest --github-repo zaip-ai/zaip-aios` before the expensive release
+gates. It checks the private/public pair, local trust and the GitHub public key
+without printing key material. Omit `--github-repo` to test completely offline.
+`prepare` and `local-release-deploy` resolve the stable paths automatically;
+`--private-key` and `--trust-store` remain explicit overrides. Missing/mismatched
+material blocks before qualification. Never auto-create a signing key during deploy.
+
+For a local-only proof, generate an ephemeral Ed25519 pair outside the repository,
+bootstrap a temporary trust store, then run `preflight` without `--github-repo` and
+the release helper with `--dry-run --offline-dry-run`, explicit temporary
+key/trust paths and an exact
+clean candidate. The receipt must verify against that temporary trust store; this
+does **not** authorize production publication or claim GitHub trust.
+
+If the production private key is genuinely unavailable, rotate only with explicit
+authorization. Use a **new** key ID and a new stable directory; never create a new
+pair under the old ID or overwrite an existing key. Bootstrap the new local trust,
+run offline preflight, then run
+`node scripts/local-release-key.mjs rotate --confirm-rotate --github-repo zaip-ai/zaip-aios --expected-old-key-id <old-id> --new-key-id <new-id> --public-key <new-public.pem> --backup-dir <new-external-backup-directory>`.
+The rotation saves the old public trust for rollback, updates only the trusted
+public key and ID, verifies readback, and attempts rollback on error. It does not
+alter the policy, publish a Release, or touch npm credentials. Do not rotate
+while a release publisher is running. Verify the resulting `preflight` with
+`--github-repo` before the next candidate qualification. Protect and separately
+back up the private key; the trust backup contains only public material. Restoring
+the old public trust alone cannot resume signing when the old private key is lost.
+
 ## Framework repository: main and GitHub Actions npm
 
 These commands exist only in the source repository `zaip-ai/zaip-aios`. Values in angle brackets
@@ -11,18 +48,29 @@ must be replaced with the authorized candidate and external paths. GitHub versio
 to tag `vN.N` and package version `N.N.0`.
 
 ```text
-node scripts/local-release-preparation.mjs keygen --output-dir <new-key-directory>
-node scripts/local-release-preparation.mjs bootstrap --trust-store <trust-directory> --public-key <public-key.pem> --key-id maintainer --channels latest
-node scripts/local-release-preparation.mjs prepare --repository <absolute-repository> --expected-repository zaip-ai/zaip-aios --sha <40-character-sha> --output-dir <candidate-artifacts> --policy <policy.json> --private-key <private-key.pem> --key-id maintainer --channel latest --version <N.N> --expires-at <future-ISO-within-seven-days> --trust-store <trust-directory> --profile essential
+node scripts/local-release-preparation.mjs keygen --output-dir <new-stable-private-key-directory>
+node scripts/local-release-preparation.mjs bootstrap --trust-store <new-stable-private-key-directory>/trust --public-key <new-stable-private-key-directory>/release-public.pem --key-id <new-key-id> --channels latest
+node scripts/local-release-key.mjs preflight --key-id <new-key-id> --channel latest
+node scripts/local-release-preparation.mjs prepare --repository <absolute-repository> --expected-repository zaip-ai/zaip-aios --sha <40-character-sha> --output-dir <candidate-artifacts> --policy <policy.json> --key-id <trusted-key-id> --channel latest --version <N.N> --expires-at <future-ISO-within-seven-days> --profile essential
 ```
 
 The framework policy is an administrator-reviewed file whose bytes must match the protected
-GitHub policy. Gates are fixed in the versioned helper, not supplied by the caller. Preparation
+GitHub policy before Release publication. The user's 2026-09-23 authorization permits the
+builder deploy to update only `ZAIP_LOCAL_RELEASE_POLICY_B64` for each exact new version after
+successful signed local qualification, with byte-for-byte readback and no key/trust rotation.
+The user separately authorized a one-time trust rotation on 2026-09-25 after the
+`maintainer-v3` private key could not be located. The active trust ID is now
+`maintainer-v4`; the old public trust is backed up outside the repository for
+rollback. This does not authorize future rotations without an explicit request.
+The policy must name the exact repository, `main`, channel, `N.N`/`N.N.0` versions, selected
+fixed qualification profile, `github-actions-only`, `signed-release-linux-smoke`, and disabled
+force/replacement/pilot flags. Do not reuse an older version's policy unchanged or ask again
+solely because its version is stale. Gates are fixed in the versioned helper, not supplied by the caller. Preparation
 fails at the first failed gate. The default `essential-v3` profile validates source size, locks,
 build/type integrity, package/SBOM/TGZ binding, dependency audit and one clean installed-consumer
 doctor/SQLite/API smoke. It does not run browser navigation across every dashboard tab or XLSX
 exports. `--profile full` explicitly selects `full-v2`, which also runs the full source suite,
-browser and XLSX qualification. Essential preparation has a 15-minute deadline; full preparation
+browser and XLSX qualification. Essential preparation has a 30-minute deadline; full preparation
 has a 60-minute deadline. Both use process-tree
 termination and cleanup after expiry. A failure never produces a successful receipt. Receipts bind
 the selected profile and its fixed gate list, so former receipts require requalification.
@@ -42,7 +90,7 @@ is refused. Choose a new output path after repair instead of deleting or overwri
 For an authorized release, call this command with the same arguments and paths:
 
 ```text
-node scripts/local-release-deploy.mjs --repository <absolute-repository> --expected-repository zaip-ai/zaip-aios --sha <40-character-sha> --branch main --output-dir <candidate-artifacts> --policy <policy.json> --private-key <private-key.pem> --key-id maintainer --channel latest --version <N.N> --expires-at <future-ISO-within-seven-days> --trust-store <trust-directory> --notes-file <reviewed-notes.md> --inventory-file <release-inventory.json> --from <previous-release-tag> --profile essential
+node scripts/local-release-deploy.mjs --repository <absolute-repository> --expected-repository zaip-ai/zaip-aios --sha <40-character-sha> --branch main --output-dir <candidate-artifacts> --policy <policy.json> --key-id <trusted-key-id> --channel latest --version <N.N> --expires-at <future-ISO-within-seven-days> --notes-file <reviewed-notes.md> --inventory-file <release-inventory.json> --from <previous-release-tag> --profile essential
 ```
 
 `--dry-run` prepares and verifies without sending. The live command verifies again around

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

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

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

@@ -1 +1 @@
-3.7
+4.0

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

@@ -5,12 +5,13 @@
 3. Classifique a entrada: Conversation, Task avulsa, SPEC ou PRD. Pergunta/análise read-only é Conversation e não cria Task.
 4. Carregue somente Rules, Requirements e skills aplicaveis.
 5. Defina aceite verificavel antes de editar.
-6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador; priorize trabalho direto na avulsa, delegue apenas quando necessário e respeite os gates de fechamento vigentes; teste e registre evidências no ciclo ativo.
+6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador. Na v4, Task avulsa usa executor subagente nativo Codex; Conversation read-only não delega. Respeite os gates de fechamento; teste e registre evidências no ciclo ativo.
 
 Evite varrer `.agents/records/`: abra um record apenas quando possuir seu ID.
 
-Para PRD/SPEC, diferencie conversa de criação: “me ajude a pensar” não cria artefato; “crie” persiste o pacote `draft` completo e sua telemetria. Faça até cinco perguntas críticas por turno, no máximo três turnos; depois registre decisões delegáveis da IA. Tasks reais só nascem em `ready|execute`.
+Para PRD/SPEC, diferencie conversa de criação: “me ajude a pensar” não cria artefato; “crie” persiste o pacote `draft` completo e sua telemetria. “Crie e execute” pode concluir ambos no mesmo turno Codex com Runs separadas. Faça até cinco perguntas críticas por turno, no máximo três turnos; depois registre decisões delegáveis da IA. Tasks reais só nascem em `ready|execute`. Pedido de ação sem macro explícito segue Task avulsa, mesmo se for crítico; recomende macro sem promovê-lo sozinho.
 
 Para os novos controles, leia [perfis de autonomia](19-assurance-e-autonomia.md)
 e [modelos](23-orquestracao-de-modelos.md): perfil não ativa provider nem migra
-Tasks legadas. O principal avulso mantém sua seleção; filhos seguem política divulgada.
+Tasks legadas. O principal avulso mantém sua seleção; o ZAIP define modelo e
+effort dos filhos, que precisam ser observados no host. O [contrato-alvo v4](28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar) ainda não certifica o runtime atual.

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

@@ -15,9 +15,10 @@ Em PRD/SPEC `draft`, a lista visível vem dos blueprints do PreparedPlan e não
 
 ## Modelo, effort e velocidade
 
-Conversation e o principal de Task avulsa preservam a seleção manual do Codex e
-preferem execução direta. Se subagentes forem necessários, informe que modelo e
-esforço podem diferir conforme catálogo/preset ZAIP. A exceção de Astra manual
+Conversation e o principal de Task avulsa preservam a seleção manual do Codex.
+Conversation read-only não usa subagente; toda Task avulsa usa executor
+subagente nativo no contrato-alvo v4, com modelo/effort selecionados pelo
+ZAIP e execução produtiva sequencial. A exceção de Astra manual
 no Essencial só vale para o principal avulso. A seleção automática solicita
 velocidade `standard`; Fast manual não é herdado pelo fluxo gerenciado.
 
@@ -25,7 +26,7 @@ velocidade `standard`; Fast manual não é herdado pelo fluxo gerenciado.
 
 [Autonomia](19-assurance-e-autonomia.md) é por Task estável: Essencial 4/1,
 Equilibrado 10/3, Persistente ilimitado (execuções/replanejamentos).
-Reiniciar, retomar ou mudar o YAML não zera a quota. `attempt_count` do lifecycle
+No Equilibrado, os planos novos usam Sol → Sol → Astra. Reiniciar, retomar ou mudar o YAML não zera a quota. `attempt_count` do lifecycle
 e reservas de execução do diário não são o mesmo contador.
 Falta de prova termina `blocked`; erro técnico impeditivo comprovado termina
 `failed`. Não diminua ACs nem use duração como critério de desistência.

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

@@ -11,7 +11,7 @@ Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
 7. Mapeie cada Requirement para Tasks e evidencias.
 8. Valide a SPEC antes de iniciar execucao; bloqueie stack ausente, divergente ou sem versoes exatas e fontes existentes.
 9. Ao iniciar a primeira Task, mantenha a SPEC em Execucao entre todas as Runs filhas; resultado terminal de uma Task nao terminaliza a SPEC.
-10. Depois de todas as Tasks concluidas, rode verificacao e Evidence parentais antes de deliver.
+10. Feche todas as Tasks da DAG, inclusive dependentes inviabilizadas, antes de decidir o status parental; somente com todas concluídas rode verificação e Evidence parentais para `deliver`.
 
 Uma SPEC planeja a entrega; nao autoriza mudancas externas por si so.
 
@@ -29,5 +29,8 @@ filho direto. Gates parentais continuam separados.
 
 Se um nó ficar bloqueado/falhado, continue somente ramos independentes
 elegíveis; não repita nós concluídos nem libere dependentes sem conclusão.
+Ao encerrar a rodada macro, dependentes impossíveis recebem bloqueio terminal
+com causa, não permanecem `planned` indefinidamente. Só Tasks de DAG
+planejada com escopos independentes podem paralelizar.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.

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

@@ -10,16 +10,17 @@ Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
 6. Relacione riscos, rollout, observabilidade e rollback.
 7. Monte a DAG e confirme que todo aceite possui evidencia planejada.
 8. Mantenha PRD e SPECs selecionadas em Execucao enquanto restar trabalho; Runs filhas fecham Tasks, nao o macro.
-9. Conclua somente depois das Tasks, integracao, outcomes e gates parentais.
+9. Decida status terminal somente depois de todas as Tasks da DAG terminarem, inclusive dependentes inviabilizadas; entregue apenas com todas concluídas, integração, outcomes e gates parentais.
 
 ## Intenções
 
 - “Me ajude a pensar sobre um PRD”: Conversation, sem artefato.
 - “Crie um PRD”: até cinco perguntas críticas por turno e no máximo três turnos; depois persiste PRD, SPECs e PreparedPlan `draft`, vincula a Run e o `creation_run_id` ao macro e não cria Tasks reais. Duração, tokens e custo só são agregados quando observados ou reconciliados.
+- “Crie e execute um PRD”: no mesmo turno Codex, crie o macro em uma Run de definição e execute a DAG em outra Run de delivery vinculada; não converta a primeira em execução.
 - “Deixe pronto para executar” ou “finalize/conclua esse PRD” em `draft`: lapida, valida e materializa SPECs/Tasks/Changes/Execution como `ready|planned`, sem executar.
 - “Execute esse PRD”: executa todas as SPECs selecionadas. Pedido dirigido a SPEC ou Task usa o menor grão.
-- “Implemente”: sem alvo abre apenas uma Conversation de planejamento; em `draft` finaliza o plano; em `ready` executa; em `active|blocked|failed` continua, retoma ou cria rework.
-- “Desenvolva/melhore/aprimore”: sempre planeja/refina/rework e nunca executa automaticamente.
+- “Implemente”: sem PRD/SPEC explicitamente solicitado, trate o objetivo de ação como Task avulsa; macro `draft` só executa com intenção explícita de executar aquele macro; em `ready` executa; em `active|blocked|failed` continua, retoma ou cria rework.
+- “Desenvolva/melhore/aprimore”: preserve a intenção e o alvo; mudança independente explicitamente pedida executa como Task avulsa, enquanto mero planejamento/refino não promove o macro.
 
 PRD cancelado permanece imutável. Novo planejamento cria sucessor `draft`, tag `rework` e `rework_of_prd_id`.
 
@@ -47,5 +48,8 @@ filho direto. Gates parentais continuam separados.
 
 Se um nó ficar bloqueado/falhado, continue somente ramos independentes
 elegíveis; não repita nós concluídos nem libere dependentes sem conclusão.
+Antes de decidir o status do PRD, feche com causa os dependentes
+inviabilizados e confirme todos os resultados terminais; nunca entregue por
+sucesso isolado de um ramo. Paralelismo exige DAG e escopos independentes.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.

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

@@ -22,12 +22,14 @@ Quando a entrega requer observação, siga o contrato de
 o registro descreve o resultado declarado e seus limites, mas não executa o
 procedimento nem aprova o AC sozinho.
 
-`execute` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” volta a planejamento/rework e exige nova promoção.
+`execute` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” com ação independente segue Task avulsa; quando o pedido é só refinar macro, não o promove.
 
 ## Modelo, effort e velocidade por origem
 
-- Conversation e o principal avulso preservam a seleção manual. Ao delegar por
-  necessidade, avise que modelo/esforço dos filhos podem mudar pela política ZAIP.
+- Conversation e o principal avulso preservam a seleção manual. Conversation
+  read-only não delega; Task avulsa usa subagente nativo Codex no alvo v4. O
+  ZAIP escolhe modelo/esforço de cada filho e bloqueia se o host não puder
+  atender à configuração exigida. Não paralelize trabalho produtivo avulso.
 - Fast para execução de produto é suportado somente em Task-first realmente independente e deve ser selecionado manualmente no Codex.
 - Executions originadas por SPEC ou PRD usam sempre velocidade `standard`, inclusive em todas as Tasks, Runs e Sub-Runs descendentes.
 - O ZAIP não ativa, persiste ou herda Fast por skill, hook, PreparedPlan ou override de Execution.
@@ -39,7 +41,10 @@ Aplique o diário e o preset do [guia 19](19-assurance-e-autonomia.md) antes
 do despacho gerenciado. Não gere tentativas por tempo nem reexecute gates
 caros inalterados para preencher uma cota.
 
-O host persiste a decisão real do Gui antes do Stop canônico e aplica a mesma
+No Equilibrado v4, reserve no máximo três replans reais por Task: Sol/high,
+Sol/high e Astra/high. A tentativa atual deve terminar em estado terminal;
+o fechamento direcionado pode ser recuperado no próximo evento Codex, sem
+prometer execução após o host parar. O host persiste a decisão real do Gui antes do Stop canônico e aplica a mesma
 decisão no fechamento. Gui read-only pode retornar sem aguardar recibos;
 o relay aceita filho já terminal enquanto o responsável estiver aberto.
 Sem decisão, preserve a pendência; não infira aprovação do status nativo.

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

@@ -42,12 +42,16 @@ coordena um responsável por tentativa de Task e seus gates parentais próprios.
 - Centralize decisoes arquiteturais e integracao no responsavel adequado.
 - Exija caminhos de evidencia e resultados de comandos, nao declaracoes de
   conclusao.
-- Use paralelismo apenas quando reduzir o caminho critico sem elevar conflito.
+- Use paralelismo produtivo apenas em DAG de PRD/SPEC planejada com Tasks
+  independentes e write scopes/recursos compatíveis; Task avulsa é sequencial.
 - Escale bloqueios de autoridade, credencial, seguranca ou escopo; nao suponha
   permissao externa.
 
-Tarefas avulsas preferem execução direta; quando delegar for necessário, informe
-que filhos podem usar modelo/esforço diferentes da seleção manual do principal.
+No contrato-alvo v4, toda Task avulsa delega execução a um subagente nativo
+Codex. O ZAIP escolhe modelo/esforço dos filhos, que podem diferir da seleção
+manual do principal. Se o host não puder aplicar/confirmar a configuração,
+bloqueie com causa; não substitua por chat independente nem por executor
+cerimonial.
 [Essencial nunca escala automaticamente para Astra](23-orquestracao-de-modelos.md).
-A exigência canônica atual de executor elegível para delivery permanece:
-preferência por execução direta não permite inventar captura para aprovar gates.
+A exigência de executor elegível para delivery permanece: não invente captura
+para aprovar gates. Execução direta é somente compatibilidade legada.

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

@@ -11,6 +11,12 @@ Run é o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo
 
 A criação explícita de PRD/SPEC vincula a Run de definição e o `creation_run_id` ao macro. Duração, tokens e custo aparecem no PRD/SPEC antes de existirem Tasks somente quando houver fonte capturada ou derivação identificada por proveniência. Um valor `estimated`, `legacy_inferred` ou `reconciled` não é dado observado e não comprova medição da chamada. Quando duração, tokens ou custo não foram capturados, eles permanecem explicitamente indisponíveis (`null`/`unavailable`); nunca atribua telemetria ausente nem transforme ausência em zero. Pensar sem criar permanece apenas em Conversas.
 
+No contrato visual da v4, a **interface** do Dashboard mostra `0` em cards e
+células numéricas depois de carregar, inclusive para valor canônico `null`,
+sem exibir “Indisponível” nesses lugares. Cobertura e tooltip distinguem
+“sem medição” de zero observado; skeleton representa loading. API, records,
+exportações e contas preservam `null`/cobertura, sem somar esse zero visual.
+
 ## Contagem de autonomia e consultas compactas
 
 ### Leitura dos números do Dashboard
@@ -31,7 +37,8 @@ descrição acessível explicam a quantidade de Runs precificadas e a cobertura.
 O subtítulo apresenta taxas estimadas de alocação: subtotal conhecido dividido pelo
 número de tarefas e pelas horas registradas do mesmo recorte. Isso não estima os
 custos faltantes nem representa a média de custos completos das tarefas. Cada
-denominador indisponível ou zero deixa apenas sua taxa como `—`. Não completar
+denominador indisponível ou zero deixa a taxa canônica sem valor; a UI v4
+mostra `0` com indicação “sem medição” quando for ausência. Não completar
 as Runs desconhecidas com zero nem apresentar o subtotal como gasto integral.
 Um subtotal observado igual a zero é diferente de ausência total de medição.
 SPECs/PRDs usam seus agregados próprios, não recebem o subtotal global de Tasks.
@@ -42,7 +49,8 @@ provedor normaliza aliases de Codex tanto na atividade quanto nos segmentos de
 uso; isso não altera identidade nem preços nos registros canônicos.
 
 Enquanto uma consulta de médias está pendente, a interface mostra carregamento,
-não zero. Zero observado, ausência de captura e carregamento são estados distintos.
+não zero. Depois da resposta, zero observado e ausência de captura mostram o
+mesmo numeral `0`, mas são estados distintos pela cobertura.
 A validação deve comparar API, linhas, rodapé e exportação no mesmo período,
 moeda e filtro. Um processo saudável não comprova que o snapshot foi atualizado;
 confirme também a revisão, a data da fonte e o estado da projeção.

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

@@ -29,17 +29,22 @@ Os manuais instalados ficam em `.agents/README.md` (português) e
 Os READMEs da raiz pertencem ao projeto consumidor e são preservados.
 As versões geradas em `public-cli/packages/cli/templates` vêm das fontes canônicas.
 
-Novos templates mantêm a seleção do principal em `manual` e configuram
-`execution.runtime: managed` para PRD/SPEC, com
+O candidato local v4 mantém a seleção do principal em `manual` e configura
+`execution.runtime: codex_native` para PRD/SPEC e Tasks avulsas, com
 `autonomy: { version: 1, preset: balanced }`. São controles diferentes:
 instalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)
 explica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)
-detalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.
-O Essencial nunca usa Astra automático. Principal avulso preserva a seleção
-manual; filhos necessários seguem política divulgada. Projetos e estados legados
+detalha a rota v4 Sol/high → Sol/high → Astra/high e sua execução elegível no
+terceiro bloco. Schema e template v4 já aceitam Codex-native; o TGZ e a
+execução real no host ainda exigem qualificação antes da publicação. O Essencial
+nunca usa Astra automático. Principal avulso preserva a seleção manual; filhos
+seguem a seleção ZAIP validada no host. Projetos e estados legados
 não recebem migração silenciosa de quotas.
 
 `@latest` entrega o que está publicado no npm. Uma atualização local das fontes ou
 um pacote validado localmente só chegará a esse comando após publicação.
+Na v4, a instalação limpa e a atualização devem comprovar `doctor`, adapters,
+preservação do conteúdo do consumidor e execução Codex-native por Task antes
+de se anunciar esse padrão como funcional.
 Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 [qualificação do pacote](26-qualidade-e-release.md).

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

@@ -13,12 +13,23 @@
 - Em delivery/interação delegada, use Gui como último filho do responsável e
   concilie a Task; conversa read-only sem filhos não precisa desse circuito.
 - Nao terminalize SPEC/PRD por causa do resultado isolado de uma Task filha.
-- Prefira reconciliacao manual sob demanda; hooks de escrita fazem checagem local sem varredura global.
+- Reconciliação global permanece manual; no alvo v4, concilie a tentativa
+  atual no fechamento/Stop observado ou no próximo evento Codex idempotente,
+  sem varredura global ou promessa de execução após o host parar.
 - Use uma SPEC por padrão; divida somente capacidades realmente independentes e paralelizáveis.
+- Task avulsa usa subagente Codex e execução produtiva sequencial; só uma DAG
+  de PRD/SPEC pode paralelizar Tasks independentes.
+- “Crie” PRD/SPEC fica `draft`; “crie e execute” pode avançar no mesmo turno,
+  com Runs separadas de definição e delivery.
+- A fila horária, quando instalada a pedido, seleciona um único macro/Task
+  superior `ready`, com prioridade PRD → SPEC independente → Task avulsa e
+  ordenação manual dentro da classe.
 - Não crie Tasks durante definição: mostre blueprints compactos e materialize somente em `ready|execute`.
 - Resolva verbos de lifecycle pelo alvo e status persistido, nunca por palavra isolada.
 
 - Prefira uma investigação útil a repetir a mesma hipótese; conte reservas reais
   pelo preset da Task, não por duração ou quantidade de testes.
 - Não transforme tempo decorrido em falha nem incompletude em aprovação.
+- Após o loading, cards/tabelas numéricas mostram `0` para métrica ausente,
+  com cobertura “sem medição”; records e API preservam `null`.
 - Preserve o diário de autonomia; ele não é cache. Veja [guia 19](19-assurance-e-autonomia.md).

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

@@ -7,7 +7,7 @@
 5. Compare `manifest.json`, `summary.json`, índices e chunks de `records/lifecycle`, sem varrer records.
 6. Corrija a causa, repita a reproducao e depois os gates completos.
 
-Se uma Task estiver presa em executing/verifying, use o popup Reconciliar. O reparo aceita `task_complete` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. Nao habilite reconciliacao automatica por turno ou na abertura do dashboard.
+Se uma Task estiver presa em executing/verifying, use o popup Reconciliar para o backlog global. O reparo aceita `task_complete` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. A v4 deve conciliar a tentativa **atual** no fechamento ou próximo evento Codex da mesma Task, sem varredura global automática na abertura do dashboard. Se o host parou e não houve novo evento, relate a pendência em vez de dizer que ela ainda está executando.
 
 Se o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.
 
@@ -21,6 +21,8 @@ Se “finalizar” tentou entregar um PRD `draft`, confira adapters/skills: o co
 | `RECOVERY_PENDING` | Localize a reserva e resultado real; não despache outra invocação nem apague o diário |
 | `ATTEMPT_BUDGET_EXHAUSTED` / `REPLAN_BUDGET_EXHAUSTED` | Confira o preset congelado e consumo; registre o resultado parcial sem reset |
 | `REPLAN_INCOMPLETE` | Plano inválido não libera reparação; preserve a reserva consumida |
+| Segundo replan escalou para Astra no Equilibrado v4 | Divergência de política: a rota aprovada é Sol → Sol → Astra; confira ledger, catálogo e modelo observado |
+| Perfil nativo não suporta modelo/effort exigido | Bloqueie com causa; não substitua silenciosamente nem conclua por prompt |
 | Gui terminou sem recibo de início | Capture o evento real e use relay suportado com responsável aberto; não invente decisão |
 | Responsável já fechado sem decisão | Recuperação autorizada/nova tentativa; reconciliação repetida não cria aprovação |
 | Perfil Essencial tentou Astra automático | Rejeite a seleção; não trate fallback/herança como autorização |

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

@@ -7,7 +7,7 @@
 - SPEC: planejamento tecnico de multiplas Tasks; draft fica em Planejamento.
 - PRD: definicao de produto; draft fica em Definicao.
 
-Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro, SPECs e PreparedPlan `draft`, atribui telemetria e mantém apenas blueprints de Tasks. `ready` é o único ponto que materializa Tasks/Changes/Execution sem iniciar; `execute` materializa e inicia.
+Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro, SPECs e PreparedPlan `draft`, atribui telemetria e mantém apenas blueprints de Tasks. `ready` materializa Tasks/Changes/Execution sem iniciar; `execute` materializa e inicia. “Crie e execute” cabe no mesmo turno Codex com Runs canônicas separadas de definição (`interaction`) e delivery, ligadas pelo alvo; criar isoladamente não promove a `ready`.
 
 ## Colunas
 
@@ -43,9 +43,12 @@ Gui ainda pode registrar bloqueio/falha real, mas `executor_missing` impede
 alternativa, sem dispensar os demais gates. `conversation finish` e `run finish` usam o mesmo escritor
 canônico, preservando a decisão imutável, os vínculos e o replay idempotente.
 
-## Execução direta autorizada
+## Execução direta legada autorizada
 
-A Task avulsa prefere o principal direto. O host registra a referência humana
+A Task avulsa do contrato legado preferia o principal direto. A v4
+substitui essa preferência por executor subagente nativo observado para toda
+Task avulsa, com orquestração sequencial. Enquanto o caminho legado existir,
+o host registra a referência humana
 com `--direct-authorization REFERÊNCIA` em `conversation start` ou `run start`,
 desde o início de uma raiz Task/Change/Execution observada. Thread, modelo ou
 classificação de intenção não são autorização por si só. Modelo/esforço manuais
@@ -58,11 +61,11 @@ necessários. Raízes antigas fechadas não recebem nova aprovação retroativa.
 
 `blocked` e retomavel com `task resume`; `failed` exige `task rework` na mesma Task e nova tentativa. `completed` e `cancelled` sao imutaveis. Interromper geracao bloqueia; cancelar a Task explicitamente cancela.
 
-`finalize|conclua` em macro `draft|ready` significa lapidar e deixar pronto; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. `implemente` é sensível ao estado; `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado gera sucessor vinculado com tag `rework`.
+`finalize|conclua` em macro `draft|ready` significa lapidar e deixar pronto; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. `implemente` é sensível ao estado; na v4, `desenvolva|melhore|aprimore` com objetivo independente de ação seguem Task avulsa, enquanto pedidos de refinamento do macro permanecem em planejamento/rework. PRD cancelado gera sucessor vinculado com tag `rework`.
 
 ## SPEC e PRD
 
-Ao iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai. Depois que todas as Tasks concluem, SPEC/PRD entram em verificacao parental; apenas gates de integracao, Acceptance Criteria, outcomes e Evidence entregam o macro.
+Ao iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai enquanto ramos independentes continuam. Antes de fechar SPEC/PRD, **todas** as Tasks da DAG, inclusive dependentes inviabilizadas, precisam de resultado terminal persistido. Só o conjunto concluído entra em verificação para entrega; bloqueios/falhas produzem decisão parental verdadeira depois do fechamento das filhas. Gates de integração, Acceptance Criteria, outcomes e Evidence continuam obrigatórios para `delivered`.
 
 Observações declaradas seguem o contrato de
 [prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
@@ -72,7 +75,7 @@ Novas SPECs de um PRD não possuem dependências entre si: são capacidades para
 
 ## Reconciliacao
 
-O popup Reconciliar chama `run reconcile --open` somente depois da confirmacao humana. Nao existe varredura ao abrir o dashboard, por turno ou por intervalo.
+O popup Reconciliar chama `run reconcile --open` somente depois da confirmacao humana. Nao existe varredura **global** ao abrir o dashboard, por turno ou por intervalo. O contrato-alvo v4 acrescenta conciliação idempotente **direcionada à tentativa atual** no Stop/fechamento observado ou no próximo evento Codex da mesma Task. Nenhum hook continua rodando após o host parar; não alegue recuperação invisível.
 
 O reparo e idempotente: `task_complete` local exato permite tentar conclusao; gate insuficiente usa blocked; Run sem invocacao ativa por dez minutos usa failed; cancelled nunca e inferido. Projecoes exibem o status persistido e nao revivem Task terminal por atividade local obsoleta.
 
@@ -105,7 +108,9 @@ A CLI autentica vínculos e persiste a decisão imutável antes do Stop canônic
 - Se a persistência falhar, mantenha evento/erro recuperável e condição objetiva;
   não declare que o estado canônico mudou antes de lê-lo.
 
-A política prefere Task avulsa direta. Uma raiz de delivery com Task, Change,
+A política legada preferia Task avulsa direta, mas a v4 Codex-native passa a
+exigir executor subagente nativo em trabalho novo. Para compatibilidade antiga,
+uma raiz de delivery com Task, Change,
 Execution, turno e modelo observados pode registrar `--direct-authorization`
 no início. Esse contrato imutável satisfaz a alternativa ao executor capturado,
 sem criar Sub-Run fictício nem converter retrospectivamente uma raiz antiga.

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

@@ -19,7 +19,7 @@ O modelo e o tier de serviço efetivamente observados, quando disponíveis, defi
 | Cache | `cache / 1.000.000 × tarifa de cache` |
 | Output | `output / 1.000.000 × tarifa de output` |
 
-O dashboard soma esses componentes uma única vez. Quando a identidade do modelo/tier, os tokens necessários ou uma tarifa do catálogo versionado não existem, o custo permanece indisponível em vez de ser inventado.
+O dashboard soma esses componentes uma única vez. Quando a identidade do modelo/tier, os tokens necessários ou uma tarifa do catálogo versionado não existem, o custo canônico permanece `null` em vez de ser inventado. No contrato visual v4, card/célula carregado mostra `0` com cobertura “sem medição”; esse numeral não entra na soma.
 
 ## 3. Considere contexto, velocidade e esforço
 

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

@@ -64,11 +64,15 @@ Os squads facilitam a leitura organizacional e a colaboração humana. Eles não
 
 O orquestrador mantém a Run raiz e cada Run delegada separadas na observabilidade. Duração, tokens e custo só são agregados quando observados ou reconciliados; ausência continua indisponível, nunca zero.
 
+Na v4, isso continua verdadeiro para records, API e cálculos. Apenas os
+cards/células numéricas do Dashboard carregado exibem `0` com cobertura
+“sem medição”; o catálogo não autoriza registrar zero observado fictício.
+
 O dispatch autônomo passa os `Task.write_scopes` a essa seleção **por Task** e persiste o builder escolhido na entrada de cada Task. Assim uma DAG com frontend e backend usa Doug e Will nas respectivas invocações, sem transformar a seleção de uma Task em builder global. A seleção é determinística, mas não concede autoridade: o agente ainda precisa respeitar seus write scopes e permissões do catálogo.
 
 O `budget.soft_cycles` também acompanha o agente selecionado por Task e governa seu checkpoint suave. Tokens continuam observados para telemetria e custo, mas não interrompem nem exigem checkpoint. Para comparar agentes, use `zaip run aggregate --agent agent-ID`; o resultado inclui duração coberta, ciclos de uso observados, tokens, custo, cobertura e Runs de rework.
 
-Nanda (`agent-reviewer`) usa `gpt-5.6-terra` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) permanece `gpt-5.6-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) permanece `gpt-5.6-sol`/`high` para auditoria de segurança explícita.
+Nanda (`agent-reviewer`) usa `gpt-6-sol` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) usa `gpt-6-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) usa `gpt-6-sol`/`high` para auditoria de segurança explícita.
 
 ## Dashboard e segurança operacional