@zaip-ai/cli 2.6.0 → 3.0.0

package/templates/.agents/runtime/checksums.sha256

@@ -1,11 +1,11 @@
 b146bd0c7c60b1ab43c4f71e0b1d2262c6df6da6f7053a0425f834ccb77a6b48  LICENSE
 bc02cba77e8d51e5c580f43668863dc868eda66f1ff663bfaa49fcf3ca16320e  THIRD_PARTY_NOTICES.md
-6693435eadb673dda297a0652d241e293e361200bc40db949cf2501d18dd01ee  VERSION
-d0f72331e6ecf333e014dc5754b277167f905543324d6d94938d2b1af4c18718  bin/zaip.mjs
-d0a3d5ade8b74dc85716a279e433dea7c2ace641e334ca6b28f11a79d0d15d40  manifest.json
+2985be8b28d3ade858e8d8fb4bc22f565b1bf6020dff982dce141f7721b9999c  VERSION
+ea4542bdeaee90694dd1402fa015026af0e8f7d11cce0d36bd6b7384971476a8  bin/zaip.mjs
+c22da8ce06147f89a055bad9bb7800085768c9fc263728db5fb54e069825e052  manifest.json
 7f89219d7c567c82a51679ad136d84364bded7ac659492537e125d33b1d58a7a  migrations/001-layout-v1.json
 5f8c48b286d0b44d8fbb57a9a5d009a8a500439aa3148d750b8f193f72995c9f  migrations/002-layout-v2.json
-12aa001df694e40b5bfbacea33d0e7ea5fe4b28e17396ec640aaa52ede0371a3  pnpm-lock.sha256
-655631d84ef9c9d1fc763031f2510027b5bedcbe31933434b141bb811924b78a  provenance.json
-ea7aaa398e7ba981ec7b583059734ee05a085170da10b30118c900d23da7c4e2  sbom.cdx.json
+2d738247131a923ea6e3a32d0d1d6de763866fd96a8a8dc75d127a343809b0aa  pnpm-lock.sha256
+d04ab7db3df0f713e1805e4bd0b735015c46e1108e2bb2fc1ef0ee4ac5790b7e  provenance.json
+f6dc78ff791e700d82cc2dc76a76898849c1d6f4b9a7f283e5840e80e52479aa  sbom.cdx.json
 b3ffedf9e146be802a15b4009f33e031dec3071ca1525e12c67606fd964a3067  schemas/contracts.schema.json

package/templates/.agents/runtime/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "name": "zaip-aios",
-  "version": "2.6.0",
+  "version": "3.0.0",
   "node": ">=22",
   "files": [
     "LICENSE",

package/templates/.agents/runtime/pnpm-lock.sha256

@@ -1 +1 @@
-4a8b304fd8e27ed71d0d2c91a5e692e34fc240b477e3037b02a42301685c5601  pnpm-lock.yaml
+f8557f3600849eb880b8f245b63b80fed9a3e9addf2c5f2c6d492547af900219  pnpm-lock.yaml

package/templates/.agents/runtime/provenance.json

@@ -2,10 +2,10 @@
   "schema_version": 1,
   "statement_type": "self_reported_build_integrity",
   "authenticity": "unverified",
-  "version": "2.6.0",
+  "version": "3.0.0",
   "source_origin": "zaip-aios:local-build",
-  "lockfile_sha256": "4a8b304fd8e27ed71d0d2c91a5e692e34fc240b477e3037b02a42301685c5601",
-  "sbom_sha256": "ea7aaa398e7ba981ec7b583059734ee05a085170da10b30118c900d23da7c4e2",
-  "runtime_sha256": "3a46f3bdbb6a04372c76f7b1ac6949056b690ba950e5ad412ef46b8e67f277ca",
-  "statement_sha256": "d6d5244320a24c2fcf48255f769796a862671609e3663240eb372606a5aa8c18"
+  "lockfile_sha256": "f8557f3600849eb880b8f245b63b80fed9a3e9addf2c5f2c6d492547af900219",
+  "sbom_sha256": "f6dc78ff791e700d82cc2dc76a76898849c1d6f4b9a7f283e5840e80e52479aa",
+  "runtime_sha256": "f6b7e8a96164b8597d41077e8bd913beb40ae0407a88ec60b221ce08eee73bb5",
+  "statement_sha256": "64b394412fc8d6a391a88a1175c5edb8c2042f71054972b4cd37e6b163380bd2"
 }

package/templates/.agents/runtime/sbom.cdx.json

@@ -6,7 +6,7 @@
     "component": {
       "type": "application",
       "name": "zaip-aios",
-      "version": "2.6.0"
+      "version": "3.0.0"
     }
   },
   "components": [
@@ -2539,8 +2539,8 @@
     {
       "type": "library",
       "name": "hono",
-      "version": "4.12.34",
-      "purl": "pkg:npm/hono@4.12.34"
+      "version": "4.13.5",
+      "purl": "pkg:npm/hono@4.13.5"
     },
     {
       "type": "library",

package/templates/.agents/skills/zaip-skill-dev-environment/SKILL.md

@@ -5,6 +5,8 @@ description: Inspect and prepare a reproducible local development environment wi
 
 # Prepare development environment
 
+Follow RULE-CORE host protection: never restart or shut down the user's computer. Inspect prerequisite installers and suppress automatic reboot using documented options; stop the step if suppression is uncertain. A pending OS restart is for the user to perform manually. Restarting an identified project process must never restart the OS.
+
 Use for a new checkout, onboarding, or a local runtime failure. This concerns the consumer application; framework installation remains `$zaip-skill-setup`.
 
 1. Read project configuration and manifests before proposing prerequisites. Never install packages, start services, or execute package scripts during discovery.

package/templates/.agents/skills/zaip-skill-execution/SKILL.md

@@ -5,6 +5,8 @@ description: Execute prepared ZAIP work only on explicit intent; materialize its
 
 # Executar trabalho preparado
 
+Aplique a proteção do computador local de `RULE-CORE` antes de executar comandos e inclua-a no contexto de cada subagente. Nunca reinicie/desligue o PC, direta ou indiretamente, inclusive em validação, recuperação ou finalização. Reinício do SO fica exclusivamente a cargo do usuário.
+
 Carregue [a governança de execução e delegação](references/runtime-governance.md) antes da entrega ou dispatch. Perguntas read-only sem descendentes usam somente o kernel de RULE-CORE e a skill de domínio pertinente.
 
 Use esta skill somente quando o usuário pedir execução. `prepare` não autoriza mutação nem promoção para `ready`; quando a execução foi pedida explicitamente, prepare o PRD/SPEC ainda em `draft`, se necessário, e então execute sem exigir outra confirmação intermediária.
@@ -23,20 +25,41 @@ Use esta skill somente quando o usuário pedir execução. `prepare` não autori
 12. Para delegação Codex, Sub-Run é somente subagente nativo de colaboração (`spawn_agent`). `create_thread` e `fork_thread` criam chats independentes e só podem ocorrer por pedido explícito do usuário; nunca os use como Sub-Run, fallback, retry ou prova de delegação. Se delegação nativa estiver indisponível, relate a limitação em vez de criar chat independente. Nome de catálogo, `task_name`, título ou prompt não provam ancestralidade nativa. Antes de repetir a mesma delegação limitada, aguarde ou reutilize seu filho pendente; capture somente ancestralidade/metadados observados em resultados nativos de spawn/terminal do host ou eventos SubagentStart/SubagentStop.
 13. Interaction read-only sem descendentes termina após a resposta, sem executor/finalizador. Para interaction com descendente delegado e para delivery, depois que todos os Sub-Runs de trabalho terminarem invoque `zaip-agent-finalizer` como último filho com propósito `finalization`. Não inicie novos filhos depois dele; auto-settlement nunca fecha interaction com descendente ativo. Isso também vale para `cancelled`: o orquestrador aplica a decisão Gui pela CLI; comandos diretos Task/SPEC/PRD nunca terminalizam. Ausência, interrupção ou falha do Gui deixa a Execution inconclusiva como `blocked`.
 14. SPEC/PRD permanece `active` entre Runs filhas e só entra em verificação após todas as Tasks; a Run filha não entrega nem bloqueia automaticamente o pai.
-15. Resolva execução no menor grão explicitado: Task executa um nó elegível, SPEC executa sua DAG interna e PRD executa todas as SPECs selecionadas. Nunca amplie Task para SPEC/PRD por inferência.
+15. Resolva execução no menor grão que cubra o pedido inteiro: somente uma Task executa um nó elegível; toda a SPEC executa sua DAG interna; todo o PRD executa as SPECs selecionadas. Mencionar a primeira Task junto de “e as demais até terminar” não restringe um pedido macro a esse primeiro nó. Não amplie um pedido exclusivamente de Task para SPEC/PRD.
 16. “Conclua a execução” ou “finalize a implementação” em macro ativo continua Tasks e gates até resultado verdadeiro; não força `deliver`. “Desenvolva/melhore/aprimore” interrompe execução implícita, registra diagnóstico e cria plano/rework antes de nova promoção.
 
+## Captura correta antes de executar
+
+- Antes de capturar uma retomada ambígua, use `conversation resolve --intent continue --prd ID --json` (ou `--spec ID` / `--task ID`). A consulta não cria Run, não promove trabalho nem aprova gates; confira o alvo, a Execution e `start_args`. Sem alvo explícito, o foco vem da última raiz da mesma thread, nunca do último executor/revisor/Gui. Para um PRD conhecido use seu ID explícito, mesmo se a última raiz foi uma correção avulsa.
+- Resolva o alcance completo antes de iniciar a primeira parte. Em “Task X e o restante do PRD”, se X pertence à DAG, capture o PRD e delegue suas Tasks; mantenha Gui por Task e Gui parental ao final. Se X é uma entrega avulsa fora da DAG, não finja que pertence ao PRD: este runtime não possui coordenador multi-Execution. Identifique essa limitação antes de executar, preserve entregas já concluídas e não prometa uma sequência que exija trocar a raiz capturada. Uma correção avulsa já concluída não precisa ser reaberta para retomar o PRD.
+
+- Pedido para executar um PRD/SPEC existente é continuação da entrega, não nova autoria. Resolva o ID canônico e use `conversation start --intent continue --prd ID` (ou `--spec ID` / `--task ID` no menor grão pedido); inspecione a Run retornada e reutilize sua identidade. Não use `--definition` para executar um macro já criado.
+- `conversation start --intent new-work` já materializa e inicia Task, Change, Execution e Run. Não abra outra Run raiz para o mesmo turno. Uma repetição compatível deve reutilizar a identidade; intenção, alvo, modelo ou atribuição diferentes não são uma repetição compatível.
+- Antes de iniciar Tasks ou delegar, confira `execution_kind: delivery`, atribuição ao alvo e Execution correta. Uma Run `interaction` de definição não autoriza a implementação. Não reescreva seu header, altere IDs do cliente ou retire a proteção de correlação para convertê-la.
+- Quando a CLI rejeitar uma captura incompatível, preserve o estado e os IDs existentes e explique a divergência. Não avance manualmente as entidades para `executing` nem crie outro PRD/DAG como tentativa de recuperação. A proteção de um proprietário por invocação permanece obrigatória.
+
 ## Paralelismo
 
+### Execução nativa de uma DAG no Codex
+
+- `execution native-next EXEC --run RUN --contexts MAP.json --json` lê o PreparedPlan canônico e retorna envelopes; não inicia provider, não comprova autenticação nem constitui evidência de execução. O mapa associa IDs de Tasks a arquivos de contexto existentes construídos para o agente selecionado.
+- Inicie ou retome apenas Changes/Tasks elegíveis pelos comandos lifecycle. O macro despacha um `zaip-agent-orchestrator` por tentativa de Task, capturado com `subagent capture --event start ... --parent-run-id MACRO-RUN --task TASK`. A CLI deriva os ancestrais da DAG; a invocação delegada preserva `run_role: subagent`, propósito `orchestration` e pai nativo real. Não crie raízes fictícias nem atribua a mesma invocação a duas Tasks.
+- O orquestrador da Task despacha seus executores e revisores; eles retornam resultados e não criam filhos. Terminar um executor encerra somente sua Sub-Run. Após commit, integração aplicável, validações e `task verify`, Gui é o último filho direto do orquestrador da Task, irmão dos executores. Persista `run finalization TASK-RUN` com a decisão observada e IDs `EVD-*`. Encerrar o orquestrador sem Gui válido bloqueia somente sua Task; nunca aprova dependências bloqueadas.
+- Depois de cada Task, continue a DAG. Apenas após todas as Tasks e os gates de integração, use `execution verify`; o Gui do macro continua sendo o último filho do macro e decide seu fechamento. Um Gui de Task não entrega automaticamente a SPEC/PRD.
+- Uma invocação já atribuída a outra entrega não pode trocar de raiz no mesmo turno. Preserve sua identidade; não crie um novo trabalho independente ao retomar o PRD existente. O preflight deve detectar essa divergência antes da captura, não apenas após terminar a primeira parte. Não edite o PreparedPlan materializado nem reatribua Tasks históricas para contornar um conflito.
+- A hierarquia PRD/SPEC coordena a DAG, não exige níveis adicionais de agentes: o host despacha diretamente o orquestrador de cada Task, sem inserir um agente macro intermediário. Respeite profundidade, capacidade e orçamento reais; sequencie Tasks quando necessário. Sem delegação nativa no orquestrador, registre a limitação; não transfira a obrigação ao executor nem simule ancestralidade.
+- Perfis somente leitura retornam decisões/eventos; não gravam lifecycle. Aplique o relay do host autorizado descrito em `references/runtime-governance.md`, preservando Gui como último filho do orquestrador responsável. Não exija argumentos ausentes do schema nativo nem converta UUID em path. O host grava a decisão real antes do Stop canônico do Gui; ausência de captura ou persistência mantém resultado bloqueado e recuperável.
+- Aumento de escopo explicitamente autorizado em rework usa `task amend-scopes TASK --run RUN --expected-revision N --add-scopes PATH[,PATH] --reason MOTIVO`. O comando registra delta aditivo recuperável na Change, preservando snapshot, IDs, ACs, risco e contadores. Não use o motivo como substituto de autorização nem altere o PreparedPlan materializado.
+
 - A unidade de isolamento é a Task; a Execution mantém a DAG global, inclusive entre SPECs de um PRD.
 - O agente pode escolher execução sequencial mesmo com paralelismo permitido.
 - Toda integração final é uma dependência explícita e precisa repetir os gates relevantes no resultado combinado.
 
-## Runtime autônomo opt-in
+## Runtime gerenciado e compatibilidade
 
-1. Leia `execution.runtime`. Ausente ou `manual` preserva a execução materializada tradicional; somente `autonomous` autoriza invocar o provider configurado.
-2. Injete `model_orchestration` somente quando `mode` for `auto` e a origem da Execution estiver em `automatic_sources`. O contrato canônico permite apenas `spec` e `prd`; uma Execution de `task` preserva a seleção manual do host.
+1. Leia `execution.runtime`. Novo padrão `managed` despacha PRD/SPEC pelo provider, mantendo avulsas diretas. Ausente/manual preserva execução tradicional; `autonomous` também permite Task gerenciada explícita. Legados já tentados exigem `task migrate-autonomy` revisado; nenhum consumo é zerado.
+2. Com `autonomy.version: 1`, aplique `RULE-AUTONOMY-DECISION` e seu ledger estável por Task. A seleção manual fica no principal avulso; subagentes seguem política automática com aviso. Sem esse bloco, preserve `automatic_sources` legado (`spec`,`prd`). Não alegue enforcement de orçamento/modelo em ferramenta nativa que não passou pelo dispatch gerenciado.
 3. Em autonomia, exija raiz Git limpa, worktree registrada por Task, commit final canônico sem alterações pendentes, diff dentro dos write scopes e merge abortável em conflito. A integração cria outro commit canônico por Task no histórico first-parent e referencia o SHA do candidato em `ZAIP-Product-Commit`.
-4. Use o menor limite de paralelismo entre projeto, plano, provider e squad. Tasks `lite` têm uma tentativa; `standard` e `critical` no máximo três tentativas de desenvolvimento/reparo.
+4. Use o menor paralelismo entre projeto, plano, provider e squad. Em `autonomy-v1`, orçamento por Task vem exclusivamente do preset congelado: Essencial 4/1, Equilibrado 10/3, Persistente ilimitado (execuções/replans); tempo não encerra Task. Risco/domain definem assurance, não esse orçamento. Só no contrato legado use as quotas anteriores por risco.
 5. Checkpoints opacos ficam somente em `.local`; não copie token de retomada para records rastreados. Critical recebe contexto fresco e verificador independente.
 6. A validação tipada acontece dentro da worktree no commit candidato antes da integração. Falha de assurance não pode ser convertida em sucesso pelo coordenador.

package/templates/.agents/skills/zaip-skill-execution/references/runtime-governance.md

@@ -6,8 +6,22 @@ Carregue antes de executar uma entrega ou delegar. Este contrato detalha o kerne
 - Em modo manual carregue `RULE-MODEL-ORCHESTRATION` antes da primeira resposta visível; aviso não bloqueia nem altera seleção. Com Codex/delegação use apenas `codex_name` do catálogo, formato `zaip-agent-NOME`, recursivamente; proíba `default`, `worker`, `explorer` e tipos ad-hoc.
 - Para delegação Codex, Sub-Run ZAIP é somente subagente nativo de colaboração (`spawn_agent`). `create_thread` e `fork_thread` criam chats independentes e exigem pedido explícito do usuário; nunca são Sub-Run, fallback, retry ou prova de delegação. Se delegação nativa estiver indisponível, relate a limitação em vez de criar chat independente. Nome de catálogo, `task_name`, título ou prompt não prova ancestralidade nativa. Antes de repetir a mesma delegação limitada, aguarde ou reutilize seu filho pendente e capture somente ancestralidade/metadados observados em resultados nativos de spawn/terminal do host ou eventos SubagentStart/SubagentStop.
 - Cada `client_turn_id` observável tem uma Execution idempotente/claim atômico; sem ele use identidade local sem prometer idempotência. `interaction` read-only sem descendentes é conversa sem Task artificial e termina após a resposta entregue, sem executor ou finalizador; interaction com trabalho delegado e `delivery` exigem executor/finalizador. `delivery` é trabalho materializado e reuso exige kind/origem compatíveis. A raiz é `zaip-agent-orchestrator`; quando a barreira é exigida escolha executor por capacidade, permita reviewer/auditor/integrator e termine com `zaip-agent-finalizer` em `finalization`, após descendentes, bloqueando novas chamadas.
-- Hooks são best-effort: após cada spawn/terminal o orquestrador também executa `zaip subagent capture` idempotente com metadados reais. Use session/turn filhos, `agent-id=agent_path`, `parent-agent-id=client_thread_id` da raiz e turn distinto por chamada. Quando um evento terminal observado expõe somente agent_path, status, identidade catalogada e pai exato, `capture-terminal` aceita apenas `zaip-agent-finalizer` ou executor elegível para delivery com capacidade `task-delivery`; exige também `parent-run-id` igual ao `run_id` da raiz ativa exata, pois um client thread pode conter raízes concorrentes. O último segmento do agent_path deve ser seu `codex_task_name` canônico. O propósito deriva da identidade validada e session/turn/model/provider/usage permanecem indisponíveis; o fallback nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
-- Em `model_orchestration.mode:auto`, selecione automaticamente apenas origens em `automatic_sources` (`spec`,`prd`); fixe modelo/effort no início de cada Run/Sub-Run distinta, herde nas calls internas e exija nova chamada para mudar. Task avulsa preserva seleção manual, sem inferir `default_model`.
-- Somente ao avaliar escalada diagnóstica difícil para Astra, carregue `RULE-ASTRA-DIAGNOSTIC`: evidência obrigatória, `high`, quota persistente de três diagnósticos por Task e devolução para executor Luna/Terra/Sol. Não carregue essa expansão em consultas comuns.
+- Hooks são best-effort: após cada spawn/terminal, o host autorizado a serviço do orquestrador executa `zaip subagent capture` idempotente com metadados reais. Na captura rica, preserve session/turn observados, `agent-id` com a identidade nativa retornada e `parent-agent-id`/`parent-run-id` do pai imediato exato; cada invocação preserva seu turn. Quando um evento terminal observado expõe somente agent_path, status, identidade catalogada e pai exato, `capture-terminal` aceita apenas `zaip-agent-finalizer` ou executor elegível para delivery com capacidade `task-delivery`; exige também `parent-run-id` igual ao `run_id` da raiz ativa exata, pois um client thread pode conter raízes concorrentes. O último segmento do agent_path deve ser seu `codex_task_name` canônico. O propósito deriva da identidade validada e session/turn/model/provider/usage permanecem indisponíveis; o fallback nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
+- Em `autonomy-v1`, carregue `RULE-AUTONOMY-DECISION`. Task avulsa preserva seleção manual do principal, evita subagentes e só delega por necessidade concreta; quando delegar, informe que modelo/esforço dos filhos seguem a política ZAIP, sem obrigação de herdar o principal. Fixe configuração por chamada e registre seleção efetivamente observada. Sem `autonomy`, preserve o contrato legado de `automatic_sources` (`spec`,`prd`).
+- Escaladas seguem o perfil congelado: Essencial nunca Astra automático; Equilibrado Sol/high, Astra/high, Astra/high, com execução Astra/high elegível no terceiro bloco; Persistente sem quota total. `RULE-ASTRA-DIAGNOSTIC` descreve também compatibilidade legada. Não use título/volume como prova nem alegue mudança de modelo apenas pelo prompt.
 - Todo PreparedPlan PRD/SPEC traz `model_signals` por Task; o framework persiste `model_profile`, `task-risk-v1` e motivos, usando `runtime_defaults`, `runtime`, política/defaults sem `standard` silencioso. Não infira fase/complexidade/transversalidade/ambiguidade/rework/custo/capacidade por contagem de arquivos; use sinais, fase/agente e capacidades. Cabeçalho e `model.selection.recorded` repetem a seleção enviada.
 - Plano visível: `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, 3–4 passos (máximo 5); omita fase sem ação e combine trivialidades.
+
+## Limites do host e relay de persistência
+
+- Gui pode ser o último filho para avaliar uma entrega que não conseguiu iniciar executor. Isso não concede sucesso: `executor_missing` mantém `completed` bloqueado mesmo com Evidence aprovada; decisões reais `blocked`/`failed` seguem o relay normal e preservam o motivo. Não crie executor cerimonial para satisfazer o fechamento. A exceção direta continua restrita à raiz Task autorizada desde a captura.
+
+- `execution.runtime: managed` despacha PRD/SPEC pelo provider e mantém avulsas diretas. Para a raiz Task direta, registre a referência humana em `--direct-authorization` desde a captura. Identidade e intenção sozinhas não concedem autorização. Esse contrato substitui somente o executor filho; nunca Evidence, revisão aplicável, Gui ou identidade observada. Não autorize retroativamente uma raiz fechada, macro ou filho.
+
+- Há exatamente um orquestrador responsável por tentativa de Task. Quando a raiz física já é Task-scoped, ela despacha executor/revisor e Gui diretamente: não inicia um Dave adicional. Somente uma raiz macro delega orquestradores de Tasks distintas; seus trabalhadores e Gui pertencem ao respectivo orquestrador. Coordenação e aceite parental não representam uma segunda tentativa da mesma Task.
+- Os nomes de ferramentas no catálogo são capacidades, não nomes literais de ferramentas do host. O orquestrador pode descobrir ferramentas diferidas no registro nativo e usar spawn/send/wait/close dos descendentes autorizados, inclusive com filesystem read-only. Essa permissão não autoriza persistência pelo perfil, chats independentes ou ampliação de sandbox. Declarar indisponibilidade exige conferir o registro efetivamente exposto.
+
+- `agent_type` usa o `codex_name` exato. Envie `task_name` somente se o schema da ferramenta nativa o oferecer; nesse caso use o `codex_task_name` exato. Sem esse parâmetro, use o perfil catalogado e preserve o UUID/nickname retornado, inclusive sufixos atribuídos pelo host. Nunca transforme UUID ou nickname em `agent_path` nem use nome como prova de ancestralidade.
+- Orquestrador e Gui com perfil `read-only` não executam comandos que escrevem records, locks ou recibos. Eles retornam eventos e decisão ao host autorizado. O host é o escritor do lifecycle, não um executor/finalizador substituto: não altera a decisão, identidade, pai ou evidências do agente.
+- A ordem canônica é início real, decisão observada de Gui, Stop e fechamento com a mesma decisão. Não imponha ao Gui espera ativa por recibos: ele pode devolver seu resultado terminal; o host usa `subagent capture --event stop` com a decisão real nos campos `task-outcome`, `summary`, `evidence`, `changed-files`, persistindo-a antes do Stop canônico. O relay rico aceita filho já terminal com responsável aberto, sem trocar metadados por fallback. Responsável fechado sem decisão exige nova tentativa autorizada. Não confunda horário observado com gravação, nem status nativo com decisão.
+- O fallback `capture-terminal` continua restrito ao contrato de path, pai e identidade já descrito. UUID com `agent_path: null` não satisfaz esse fallback. Falta de prova rica, conflito de ancestry ou falha do escritor bloqueia a entrega, sem recriar Tasks, inventar metadados, ampliar sandbox ou pedir a um executor que delegue Gui.

package/templates/.agents/skills/zaip-skill-github-deploy/SKILL.md

@@ -42,7 +42,7 @@ Every product commit requires causal Task/Change/Execution records and matching
 
 1. Compose `$zaip-skill-release-qualification` and follow [local preparation](../zaip-skill-release-qualification/references/local-preparation.md). Synchronize and commit before preparing the clean exact SHA. Failed or stale evidence is not qualification.
 2. Resolve the previous Release, next canonical version and package identity using [release identity](references/release-identity.md). For the framework, `vN.N` maps to package `N.N.0`; only GitHub Actions publishes `@zaip-ai/cli` to npm.
-3. For `zaip-ai/zaip-aios`, use `scripts/local-release-deploy.mjs`. It prepares/verifies, pushes the exact SHA to configured `main`, uploads verified assets to a draft, then publishes the Release. Keep legacy GitHub qualification until the protected pilot is enabled; never enable it implicitly.
+3. For `zaip-ai/zaip-aios`, use `scripts/local-release-deploy.mjs`. It prepares/verifies, pushes the exact SHA to configured `main`, uploads verified assets to a draft, then publishes the Release. Enable the thin publisher only after explicit rollout authority, public trust enrollment and signed full local qualification. It validates published assets and runs one read-only installation smoke before npm; no private-draft pilot or write token is needed. GitHub Release publication and npm completion remain separate.
 4. Consumers use `scripts/consumer-release-preparation.mjs guarded-push` with their own policy and explicit branch, SHA and trusted receipt. They have no framework npm/TGZ requirement. See the preparation guide for bootstrap and guarded commands.
 5. Immediately before delivery, reread the configured target; if changed, restart preparation. Helpers bind the exact candidate to `HEAD:refs/heads/<configured branch>` (or its equivalent immutable-SHA refspec); do not bypass them with a manual push.
 6. After qualification, a missing Release is normal. Unless explicitly push-only, automatically create the draft for that SHA or resume a verified draft for the same SHA. Verify an already-published exact Release as a no-op; an API/authentication error never proves absence. Refuse conflicting tags/assets without overwrite.
@@ -50,14 +50,13 @@ Every product commit requires causal Task/Change/Execution records and matching
 
 ## Proportional validation
 
-Framework deploy uses `rapid-v1`: at most 40 focused tests, a 90-second test budget and
-an eight-minute preparation command budget, followed only by cleanup. Preserve lock, lint,
-types, version/parity, audit, exact TGZ and consumer identity checks. Full coverage, all skill
-tests, full cleanroom and full Dashboard E2E are explicit-only (`pnpm qualify:full` or the
-manual validate workflow). Never escalate to hundreds of tests automatically. A timeout or
-failed check emits no success receipt; diagnose once and repair the specific cause.
-Record the rapid profile and its limited regression coverage; do not call it full certification.
-GitHub queue, installation and publication timings are reported separately.
+Guarded local framework delivery requires a valid `full-v2` receipt with the mandatory full gate.
+Without explicit thin-path activation, the default GitHub publisher separately requires the legacy workflow's
+exact-candidate qualification receipt after its full gate and TGZ matrix.
+Rapid impact checks have no test-count ceiling and cannot substitute for release evidence.
+Use the budgets and failure rules in [local preparation](../zaip-skill-release-qualification/references/local-preparation.md).
+Consumer projects retain their own reviewed policy commands. Report qualification and
+publication separately; neither preparation nor this policy grants publication authority.
 
 ## Verify and close
 

package/templates/.agents/skills/zaip-skill-github-deploy/references/deployment-workflow.md

@@ -70,12 +70,16 @@ Run preflight once at the start of the authorized deployment. Classify a failure
 
 ## Validation budget
 
-Use `rapid-v1` by default: at most 40 focused tests, 90 seconds for tests and eight minutes
-for preparation commands. Full suites require explicit selection (`pnpm qualify:full` or
-manual validate workflow). Keep version, source/template parity, package, audit and consumer
-identity gates. Never rerun unchanged validation or substitute a rapid receipt for full
-coverage evidence. On timeout, terminate the command tree, retain the failing gate and
-repair its evidenced cause; do not extend the budget or start hundreds of tests implicitly.
+Guarded local framework preparation requires `full-v2` and its mandatory full gate.
+The default legacy GitHub publisher accepts its separate exact-candidate qualification
+receipt only after the remote full gate and TGZ matrix. Explicit administrator activation after signed full local qualification switches the
+publisher to the verified local receipt. One read-only install smoke then gates npm;
+no private-draft pilot is required. Activation is never implicit.
+Follow [local preparation](../../zaip-skill-release-qualification/references/local-preparation.md)
+for exact-candidate evidence, deadlines and rapid-preparation limits. Impact selection has
+no test-count ceiling; rapid results are not release receipts. Preserve consumer policy
+boundaries and reuse only valid matching evidence. On timeout, terminate the command tree,
+retain the failed gate and repair its evidenced cause; never omit gates to obtain success.
 
 ## Review and validate
 

package/templates/.agents/skills/zaip-skill-move-prd/SKILL.md

@@ -35,6 +35,8 @@ Use apenas comandos canônicos ZAIP. Não edite status diretamente no frontmatte
 
 ## Verificar
 
+Na continuação de um PRD preparado, reutilize a Execution de `plan_ref`/PreparedPlan. Para `blocked` ou `paused`, inspecione a causa e use a retomada canônica autorizada antes da captura; não repita `prd execute` contra um macro já materializado. `conversation start --intent continue --prd ID --execution EXEC` deve resolver a mesma Execution e fase `execution`, rejeitando divergências antes de escrever. Para colaboração nativa Codex, siga a seção de DAG nativa da skill de execução; `native-next` prepara envelopes e não substitui o spawn/capture observado nem os gates de entrega.
+
 1. Leia novamente o PRD e liste SPECs com `spec list --prd <PRD-ID> --json`.
 2. Após `prepare`, confirme que PRD e SPECs continuam `draft`; após `ready`, confirme que apenas as selecionadas ficaram `ready` e que Execution, Changes e Tasks permanecem `planned`.
 3. Confirme no resultado do cancelamento os arrays `cascade.specs`, `cascade.tasks`, `cascade.changes` e `cascade.executions`.

package/templates/.agents/skills/zaip-skill-prd/SKILL.md

@@ -50,6 +50,8 @@ Durante essa etapa, a Execution universal `interaction` e sua Run raiz continuam
 
 ## Handoff e analyze
 
+Ao receber “execute esse PRD” em outro turno, reutilize o ID canônico e delegue à skill de execução a captura inicial como continuação desse PRD. Não repita o intake `conversation --definition prd,spec` da autoria anterior e não recrie o pacote. Se o documento citado existir apenas como rascunho local, informe essa diferença: a existência de um arquivo de planejamento não comprova PRD canônico nem Run de delivery.
+
 1. Pare em Definição após `prepare`. Somente após pedido explícito de promoção, use `$zaip-skill-move-prd`: `prd ready` deixa PRD/SPECs selecionadas em `ready` e materializa a DAG sem executá-la; cada Task materializada `planned` e nunca iniciada aparece em Pronto para Executar, mesmo vinculada a SPEC. Somente após pedido explícito de execução, delegue a persistência da continuação, ativação e orquestração para `$zaip-skill-execution`.
 2. Na análise, mostre visão macro por PRD: SPECs, Tasks, Executions, Runs, outcomes, AC/evidência, retrabalho, tokens e custo por fase/total.
 

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

@@ -16,8 +16,8 @@ Consumer projects run their own policy commands through the distributed consumer
 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 changed candidate or invalid evidence requires new qualification.
-Legacy GitHub qualification remains mandatory until the protected pilot transition is enabled;
-during that transition some local and remote validation is intentionally duplicated.
+Full source qualification runs locally. Extended GitHub qualification is manual;
+the reduced publisher requires enrolled public trust and signed full local qualification.
 
 The only public npm package is `@zaip-ai/cli`; the installation entry point is
 `npx @zaip-ai/cli@latest init`. Verify that release automation, manifests, and
@@ -25,27 +25,25 @@ registry checks target only this package before qualifying the next publication.
 
 ## Proportional validation
 
-Framework deploy uses `rapid-v1`: at most 40 focused tests, a 90-second test budget and
-an eight-minute preparation command budget, followed only by cleanup. Preserve lock, lint,
-types, version/parity, audit, exact TGZ and consumer identity checks. Full coverage, all skill
-tests, full cleanroom and full Dashboard E2E are explicit-only (`pnpm qualify:full` or the
-manual validate workflow). Never escalate to hundreds of tests automatically. A timeout or
-failed check emits no success receipt; diagnose once and repair the specific cause.
-Record the rapid profile and its limited regression coverage; do not call it full certification.
-GitHub queue, installation and publication timings are reported separately.
-
-## Guarded local-pilot transition
-
-The legacy GitHub qualification and publisher remain the default. An administrator enables
-`ZAIP_LOCAL_RELEASE_ENABLED=true` only after a real pilot passes and protected repository variables
-provide `ZAIP_LOCAL_RELEASE_TRUSTED_PUBLIC_KEY_B64`, `ZAIP_LOCAL_RELEASE_POLICY_B64`, and
-`ZAIP_LOCAL_RELEASE_TRUSTED_KEY_ID`. The enabled thin job downloads only Release assets, bootstraps
-that public key and verifies V2 receipt and policy against the exact SHA. A job without OIDC runs
-the Linux TGZ smoke; its dependent publishing job binds the same receipt digest, reverifies the
-assets and uses npm OIDC provenance. A separate job without OIDC runs the registry consumer smoke.
-It never rebuilds or retests sources. The local `pilot` command checks reproducibility only:
-activation additionally requires successful remote qualification of the same candidate and
-administrator enrollment of the trusted public key and policy. Never upload a private key.
+Local framework preparation receipts require `full-v2`, including the mandatory `pnpm qualify:full`
+gate. The default legacy GitHub path retains its own qualification receipt after the full gate
+and exact-TGZ matrix; it does not use the local receipt format. Neither path accepts rapid-only
+evidence. A rapid check is diagnostic preparation, not release certification. Select rapid tests
+by impact without a count ceiling; a deadline must fail visibly, never truncate coverage.
+Follow [local preparation](references/local-preparation.md) for budgets, exact-candidate
+evidence and cache validity. A failed or timed-out gate emits no success receipt.
+Report local qualification, runtime matrix, GitHub and publication outcomes separately.
+
+## Guarded local qualification and single remote smoke
+
+An administrator explicitly enables `ZAIP_LOCAL_RELEASE_ENABLED=true` after full local
+qualification and public trust enrollment. The guarded helper publishes the exact signed
+GitHub Release assets. The read-only verifier validates receipt, policy, SHA and TGZ,
+then runs one Linux installation/doctor smoke before the isolated npm job receives
+publication credentials. No private-draft pilot or contents-write token is required.
+The publisher reverifies artifacts and registry integrity; additional registry installation
+is opt-in manual `extended_verification=true`. Missing proof never falls back to publishing.
+A published GitHub Release alone does not prove npm delivery. Never upload a private key.
 
 1. Identify the exact candidate revision, version, and intended distribution surface.
    Do not substitute current working-tree checks for candidate evidence.

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

@@ -19,13 +19,22 @@ node scripts/local-release-preparation.mjs prepare --repository <absolute-reposi
 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
 fails at the first failed gate. It validates source size before dependency installation; then runs
-the `rapid-v1` profile: build once, static integrity checks, at most 40 focused tests
-(90 seconds total), dependency audit, package validation and exact-TGZ consumer identity.
-Preparation commands share an eight-minute deadline, with process-tree termination and cleanup
-after expiry. A failure never produces a successful receipt. Full coverage, all skill tests,
-cleanroom/rollback and Dashboard E2E run only via explicit `pnpm qualify:full` or manual
-workflow selection. Normal deploy never escalates automatically to that full suite.
-Receipts distinguish `rapid-v1` from former full qualification; stale policies are rejected. It emits receipt, manifest, SBOM and TGZ.
+the `full-v2` profile: static integrity checks, dependency audit, package validation,
+mandatory `pnpm qualify:full` and exact-TGZ consumer identity. Preparation commands share
+a 60-minute deadline, with process-tree termination and cleanup after expiry. A failure
+never produces a successful receipt. Full qualification includes coverage, skill tests,
+cleanroom/rollback and Dashboard E2E; these gates are not optional for a release receipt.
+Former rapid-only receipts are invalid for this policy and require requalification.
+Successful preparation emits receipt, manifest, SBOM and TGZ.
+
+The separate rapid preparation helper has an eight-minute deadline and emits no signed
+release receipt; manual extended CI follows it with the mandatory full gate. `test:rapid` selects tests by
+impact, including critical baseline and affected consumers, without a count ceiling. Its
+90-second deadline fails closed instead of silently dropping selected tests. An unmapped
+change expands selection to the inventory. Neither rapid path proves full qualification.
+Retain Windows/Linux Node 22.16.0 and 24.x matrix outcomes against the same exact TGZ,
+recording the actual Node patch version and digest. A configured matrix is not proof that
+its jobs ran; unavailable runtime execution remains unverified, never passed.
 Reuse an existing output directory only with its complete valid signed candidate; an invalid cache
 is refused. Choose a new output path after repair instead of deleting or overwriting evidence.
 
@@ -75,11 +84,23 @@ After successful guarded push, create the consumer GitHub Release according to
 [release identity](../../zaip-skill-github-deploy/references/release-identity.md), attached to that
 verified SHA. This flow does not require a TGZ, npm version, npm channel or npm credentials.
 
-## Activate the reduced GitHub path after a pilot
+## Activate the reduced GitHub path
 
-Keep `ZAIP_LOCAL_RELEASE_ENABLED` unset/false until local preparation and a real legacy GitHub
-qualification succeed for the same candidate. The local `pilot` subcommand only rebuilds and
-compares the signed TGZ; it is not proof of Linux GitHub execution or npm publication.
+After explicit rollout authority, complete signed full-v2 local preparation and enroll
+only the reviewed public key, exact policy and key ID. Then explicitly enable
+`ZAIP_LOCAL_RELEASE_ENABLED=true` and use guarded delivery. The GitHub Release is published
+with its four signed assets before Actions validates them; the verifier needs only
+contents-read access. One Linux TGZ installation/doctor smoke gates npm publication.
+No private-draft pilot or write-token escalation is required. If the smoke fails, npm
+remains unpublished; retain the failure and distinguish it from GitHub Release creation.
+An extra registry installation is available only with manual `extended_verification=true`.
+The registry digest and channel are always verified by the isolated publisher.
+
+The default legacy publisher validates `qualification-receipt.json` from the successful
+GitHub qualification run, bound to candidate SHA, run/attempt, channel and exact TGZ. That
+workflow requires the full gate and runtime matrix before issuing its receipt. This is a
+separate accepted remote policy, not a `full-v2` local receipt or a rapid-only exemption.
+The guarded local helper still requires `full-v2` even while legacy remote checks are enabled.
 
 An administrator enrolls the public key, exact policy bytes and key ID in protected repository
 variables `ZAIP_LOCAL_RELEASE_TRUSTED_PUBLIC_KEY_B64`, `ZAIP_LOCAL_RELEASE_POLICY_B64` and
@@ -89,8 +110,11 @@ Protect edits to workflow, trust configuration and publishing environment. A sig
 that a trusted key endorsed the candidate; it does not make a compromised workstation trustworthy.
 
 Enabled GitHub publication verifies the signed assets and exact SHA, performs a Linux TGZ smoke,
-reverifies before OIDC publication, checks registry bytes and runs an installed registry smoke.
-PR/manual qualification remains available. Reverting the flag restores legacy remote gates.
+reverifies before OIDC publication, checks registry bytes and optionally runs an explicit manual registry installation.
+Source/commit checks are manual-only in GitHub; they remain required locally.
+Extended qualification remains available through manual `qualify-cli.yml` dispatch, including
+the full source suite and Windows/Linux runtime matrix; it no longer runs on every push.
+Reverting the flag requires manually qualifying the exact candidate through that legacy path.
 Missing/invalid evidence blocks publication; it never falls back to an unchecked publish.
 
 Measure preparation, push and Actions publication separately. Cache reuse can shorten repeat

package/templates/.agents/skills/zaip-skill-setup/SKILL.md

@@ -5,6 +5,8 @@ description: Install ZAIP-AIOS and its authorized prerequisites in a new workspa
 
 # Instalar ZAIP-AIOS
 
+Aplique a proteção do computador local de `RULE-CORE`: nunca reinicie/desligue o PC. Antes de executar instaladores, confirme opções documentadas que suprimam reinício automático; não use `--allow-reboot`. Se a supressão não puder ser garantida, pare essa etapa. Informe reinício pendente para ação manual do usuário.
+
 Para Supabase, a instalação nunca cria branch, preview ou custo hospedado. O fluxo protegido de migrations exige uma branch beta persistente e GitHub Integration verificada; explique o custo antes de qualquer provisionamento e registre confirmação informada na configuração. Sem beta, prepare localmente e pare: migrations nunca seguem para `main`. Somente uma recusa explícita da beta permite o modo manual: uma pessoa executa SQL exportado no SQL Editor; agente, pipeline e startup nunca o aplicam.
 
 Use somente o pacote público `@zaip-ai/cli`: `npx @zaip-ai/cli@latest init`.

package/templates/.agents/skills/zaip-skill-tool-setup/SKILL.md

@@ -5,6 +5,8 @@ description: Discover, install, configure, authenticate, enable, disable, and di
 
 # Configurar tools ZAIP
 
+Aplique a proteção do computador local de `RULE-CORE`: nunca reinicie/desligue o PC, inclusive por instaladores ou scripts de configuração. Suprima reinício automático com opções documentadas ou pare a etapa. Reiniciar/reabrir o Codex refere-se somente ao aplicativo; reinício do Windows fica a cargo do usuário.
+
 1. Leia `.agents/tools/catalog.yaml` e somente o manifesto da tool solicitada.
 2. Execute `scripts/inspect-tool.mjs <id> [mcp|api]` para produzir um plano sem segredos.
 3. Confirme que a implementacao ou URL MCP e oficial, verificavel ou mantida pelo ZAIP; nunca invente pacote.

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

@@ -29,7 +29,7 @@ introduzidos em releases mais novas.
 | Consultar instalação detalhada | [20 — Instalação detalhada](guides/20-instalacao-detalhada.md) |
 | Consultar telemetria do Monitor | [21 — Telemetria do Monitor de Custos](guides/21-telemetria-monitor-custos.md) |
 | Entender fluxos e roteamento | [22 — Fluxos e roteamento](guides/22-fluxos-e-roteamento.md) |
-| Escolher modelos e limitar o diagnóstico Astra | [23 — Orquestração de modelos](guides/23-orquestracao-de-modelos.md) |
+| Entender modelos, delegação e escalada por preset | [23 — Orquestração de modelos](guides/23-orquestracao-de-modelos.md) |
 | Entender cálculo e fontes de custo | [24 — Cálculo](guides/24-calculo-de-custos-openai.md) e [25 — Fontes](guides/25-fontes-de-precos-openai.md) |
 | Consultar qualidade e release | [26 — Qualidade e release](guides/26-qualidade-e-release.md) |
 | Entender a telemetria Git-native | [27 — Telemetria Git-native](guides/27-telemetria-git-native.md) |
@@ -60,3 +60,11 @@ introduzidos em releases mais novas.
 Guias são documentação, não certificado de release nem autorização para
 deploy, reabrir trabalho bloqueado, alterar permissões ou executar exemplos
 destrutivos. Relatórios históricos preservam o candidato e a data observados.
+
+## Ler as novidades da v3
+
+Comece por [19 — Perfis de autonomia](guides/19-assurance-e-autonomia.md):
+4/1, 10/3 e ilimitado; depois [23 — Modelos](guides/23-orquestracao-de-modelos.md)
+e [16 — Fechamento](guides/16-lifecycle-e-reconciliacao.md).
+Perfil de instalação, assurance e autonomia são configurações distintas.
+As fontes em qualificação não comprovam disponibilidade no npm nem produção.

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

@@ -40,8 +40,10 @@ presença de uma instrução ou screenshot não comprova execução naquele ambi
 - Use o guia 16 para entender status, reconciliacao e a ordem de finalizacao.
 - Use os guias 17 e 24 a 25 para interpretar tokens, precificacao e conversao de moeda.
 - Use o [guia 08](guides/08-contexto-e-tokens.md) para consultas com contexto enxuto e
-  o [guia 23](guides/23-orquestracao-de-modelos.md) para a divisão Luna/Terra/Sol e o
-  diagnóstico Astra em `high`, limitado a três invocações por tarefa.
+  o [guia 23](guides/23-orquestracao-de-modelos.md) para modelos, seleção manual do principal e escaladas governadas pelo preset.
+- Use o [guia 19](guides/19-assurance-e-autonomia.md) para Essencial (4/1),
+  Equilibrado (10/3) e Persistente ilimitado: execuções/replanejamentos por Task,
+  configuração no YAML/Dashboard e limites atuais do despacho gerenciado.
 - Use os guias 18 a 28 quando precisar do contrato completo de agentes, lifecycle, telemetria, qualidade, instalacao ou roteamento.
 
 O instalador npm projeta esta pasta da `.agents` canonica para o tarball e a
@@ -51,9 +53,28 @@ Os manuais completos em português e inglês são instalados como
 `.agents/README.md` e `.agents/README-ENG.md`; os READMEs da raiz do consumidor
 permanecem sob sua autoria.
 
+A Ajuda do Dashboard incorpora estes arquivos no build. Em inglês, carrega o
+README inglês canônico; os 28 guias atualmente têm fonte em português e são
+apresentados com aviso de idioma, sem traduções resumidas paralelas obsoletas.
+
 Para concluir trabalho, use [revisão e validação](guides/07-revisao-e-validacao.md)
 e o [contrato de prova observável](../skills/zaip-skill-change/references/observable-evidence.md).
 Registros estruturados validam vínculos, não substituem o exame do resultado.
 Consulte [qualidade e release](guides/26-qualidade-e-release.md) para distinguir
 checks locais, CI e aprovação de produção. Documentação não autoriza publicação
 nem reabertura de entregas históricas bloqueadas.
+
+## Novidades em preparação para v3
+
+A documentação descreve `autonomy-v1` sem declarar release publicada.
+Os manifests deste checkout identificam o candidato `3.0.0`. 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
+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
+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 @@
-2.6
+3.0

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

@@ -5,8 +5,12 @@
 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; execute Sub-Runs, teste e registre evidencias no ciclo de vida ativo.
+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.
 
 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 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.

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

@@ -7,7 +7,7 @@ Use Task para uma entrega pequena, independente e com um resultado claro.
 3. Vincule Requirements aplicaveis.
 4. Liste arquivos ou componentes provaveis, sem congelar a solucao.
 5. Defina verificacoes proporcionais ao risco.
-6. Use uma Run raiz do orquestrador por tentativa, finalize os Sub-Runs de trabalho e execute o finalizador como ultimo filho.
+6. Use um orquestrador responsável por tentativa; se delegado pelo macro, sua Run conserva o pai real. Finalize os Sub-Runs de trabalho e execute Gui como último filho direto desse responsável.
 7. Antes de a Run terminar, mova a Task para completed, blocked, failed ou cancelled; nunca deixe executing/verifying.
 8. Retome blocked com `task resume`; trate failed com `task rework` na mesma Task. Completed/cancelled sao imutaveis.
 
@@ -15,4 +15,17 @@ Em PRD/SPEC `draft`, a lista visível vem dos blueprints do PreparedPlan e não
 
 ## Modelo, effort e velocidade
 
-Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex. A única forma suportada de executar trabalho de produto mais rápido é usar Fast manualmente em uma Task-first realmente independente; o ZAIP não ativa nem persiste essa seleção. Uma Task descendente de PRD ou SPEC segue a orquestração automática do pai e executa sempre com velocidade `standard`, mesmo quando for acionada no menor grão.
+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
+no Essencial só vale para o principal avulso. A seleção automática solicita
+velocidade `standard`; Fast manual não é herdado pelo fluxo gerenciado.
+
+## Orçamento e retomada
+
+[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
+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

@@ -18,3 +18,16 @@ Uma SPEC planeja a entrega; nao autoriza mudancas externas por si so.
 Use uma SPEC por padrão. Separe outra somente quando as capacidades puderem ser implementadas e verificadas em paralelo contra contratos estáveis, sem dependência ou write scope conflitante. Dependências e ordem ficam na DAG de Tasks da mesma SPEC.
 
 Toda Execution originada por SPEC usa velocidade `standard` em suas Tasks, Runs e Sub-Runs. A seleção manual de Fast no Codex não substitui essa política. Se uma necessidade urgente for realmente pequena e independente da DAG e dos gates parentais, ela pode ser tratada como Task-first com velocidade manual; não fragmente uma SPEC artificialmente apenas para executar mais rápido.
+
+## Autonomia e continuidade da DAG
+
+O [preset](19-assurance-e-autonomia.md) é aplicado por Task, não como teto
+compartilhado do macro. Dez Tasks Equilibradas permitem até 100 execuções
+(10 iniciais + 90 reparações) e 30 replanejamentos, sem prazo de abandono.
+Use um orquestrador responsável por tentativa de Task e Gui como seu último
+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.
+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.