@zaip-ai/cli 2.6.0 → 3.0.0

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

@@ -36,3 +36,16 @@ PRD cancelado permanece imutável. Novo planejamento cria sucessor `draft`, tag
 Qualquer dependência técnica entre duas frentes obriga reuni-las na mesma SPEC e expressar a ordem entre Tasks. Mais de cinco exige recortar o PRD ou registrar uma decisão de exceção.
 
 Toda Execution originada por PRD usa velocidade `standard` em todas as SPECs, Tasks, Runs e Sub-Runs descendentes. Não existe skill, hook ou override de Fast para esse fluxo. A única execução de produto mais rápida suportada é Task-first realmente independente, com Fast selecionado manualmente no Codex; uma urgência não autoriza remover a estrutura necessária de PRD/SPEC.
+
+## 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.

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

@@ -1,7 +1,7 @@
 # Execucao
 
-1. Confirme Task, Change, Execution, aceite e Run raiz do orquestrador.
-2. Antes da primeira mutacao persistente, confirme Task executing e Run raiz ativa no turno atual.
+1. Confirme Task, Change, Execution, aceite e Run do orquestrador responsável, preservando o pai quando delegado pelo macro.
+2. Antes da primeira mutacao persistente, confirme Task executing e Run responsável ativa no turno atual.
 3. Inspecione o diff e preserve alteracoes alheias.
 4. Use Sub-Runs para cada subagente; a Run raiz aguarda todos os descendentes ativos.
 5. Implemente o menor incremento coerente e rode verificacoes focadas.
@@ -10,7 +10,8 @@
    produza o commit isolado quando houver mutação e persista Validation/Evidence
    do candidato exato. Falta de prova permanece pendência.
 8. Depois dos demais descendentes e das provas, execute `zaip-agent-finalizer`
-   como último filho. Nenhum filho novo pode iniciar depois dele.
+   como último filho direto do responsável da Task, não do executor. Nenhum
+   filho novo pode iniciar depois dele.
 9. Aplique a decisão terminal pela CLI: Task, Change e Execution; atualize os
    manifests e finalize a Run raiz, separando status técnico e resultado da Task.
 
@@ -25,8 +26,22 @@ procedimento nem aprova o AC sozinho.
 
 ## Modelo, effort e velocidade por origem
 
-- Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex.
+- 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.
 - 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.
 - Selecionar uma Task descendente como menor grão não a transforma em Task-first nem remove a velocidade `standard` herdada do macro.
+
+## Reparação e finalização sem espera artificial
+
+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
+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.
+Após decisão persistida, reconcilie `closure_pending` sem executar outro Gui
+ou recomeçar os workers. Veja [recuperação](16-lifecycle-e-reconciliacao.md).

package/templates/.agents/zaip-aios/guides/07-revisao-e-validacao.md

@@ -13,3 +13,17 @@ candidato, ambiente, locators e limitações segundo o contrato de
 `confirmed` pode complementar uma Evidence compatível, mas não substitui
 validação, revisão independente nem finalizador. `pending`, `limited`,
 `failed` e `not_applicable` não são aprovação.
+
+## Preset não reduz prova
+
+Essencial não significa revisão superficial; Persistente não autoriza
+aceite com evidência faltante. O [perfil de autonomia](19-assurance-e-autonomia.md)
+controla persistência. Assurance segue risco e domínio: comportamento para
+software, fontes/briefing para conteúdo, dados/premissas para estratégia e Ops.
+Ao esgotar recuperação, registre ACs atendidos e pendentes, sem removê-los.
+
+A decisão do finalizador seleciona seus IDs imutáveis de Evidence antes de
+validá-los. Provas antigas permanecem preservadas, mas outro candidato,
+falha ou correlação incompatível não aprova a tentativa atual.
+Reutilização exige elegibilidade e vínculo real; nunca relabele um teste
+histórico como nova execução.

package/templates/.agents/zaip-aios/guides/08-contexto-e-tokens.md

@@ -15,9 +15,10 @@ Uma pergunta simples de Marketing, Sales, Growth ou Ops recebe o contexto do dom
 necessário à resposta. Não cria Task/Change artificial nem carrega instruções de
 engenharia ou diagnóstico Astra apenas por mencionar um departamento.
 
-O [guia 23](23-orquestracao-de-modelos.md) define a escalada excepcional. A
-[Rule Astra](../../rules/astra-diagnostic.md) só é carregada ao avaliar elegibilidade:
-prova da falha, dificuldade estruturada e, no caso preventivo, impacto crítico comprovado.
+O [guia 23](23-orquestracao-de-modelos.md) distingue os replanejamentos por
+preset do diagnóstico legado. Carregue [autonomia](../../rules/autonomy-decision.md)
+quando aplicável; a [Rule Astra](../../rules/astra-diagnostic.md) detalha a
+compatibilidade e a elegibilidade, sem liberar Astra automático no Essencial.
 A consulta diagnóstica usa contexto novo e delimitado, sem histórico integral ou ferramentas;
 o executor recebe a rota corrigida e preserva os critérios de aceite originais.
 

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

@@ -10,7 +10,9 @@ memorizar uma lista ou inventar uma identidade.
 1. Quebre o trabalho em subtarefas concretas, independentes e verificaveis.
 2. Escolha pelo conjunto de `capabilities`, `execution_eligibility`, ferramentas
    e `write_scopes` do catalogo, nao apenas pelo titulo do agente.
-3. Use apenas o `codex_name` e o `codex_task_name` exatos do registro. Nao use
+3. Use `agent_type` com o `codex_name` exato. Envie `task_name` somente se
+   existir no schema nativo, usando o `codex_task_name` exato. Preserve UUID e
+   nickname realmente retornados, inclusive sufixos; não invente `agent_path`. Não use
    `default`, `worker`, `explorer` ou nomes ad-hoc.
 4. Defina objetivo, escopo de escrita, entradas, criterio de aceite e formato de
    retorno antes da delegacao.
@@ -18,10 +20,10 @@ memorizar uma lista ou inventar uma identidade.
 
 ## Squads
 
-As seis squads coordenam contextos recorrentes: entrega critica, analise de
-produto, design e website, marca e marketing, growth e RevOps, e vendas e
-governanca. A squad e um roteador de capacidade; a delegacao continua usando o
-agente catalogado que satisfaz o trabalho concreto.
+Os seis squads organizacionais são Product, Admin & Operations, Development,
+Delivery Assurance, Infra & Security e Growth — Sales, Marketing and Branding.
+Squad não concede capacidade ou autoridade: o roteamento usa o catálogo e os
+write scopes da Task, não a organização visual.
 
 ## Execucao e fechamento
 
@@ -30,10 +32,10 @@ orquestrador coordena a DAG, preserva a separacao de telemetria entre raiz e
 Sub-Runs e captura metadados observados apos spawn e termino. Reviewer,
 auditor ou integrador so entram quando sua capacidade for necessaria.
 
-O ultimo filho e sempre `zaip-agent-finalizer`, depois que os demais
-descendentes terminaram. Ele nao reescreve evidencia: aplica uma decisao
-restrita baseada em testes, diffs e registros reais. O resultado so deve ser
-reportado apos a barreira de finalizacao estar satisfeita.
+Gui é o último filho direto do orquestrador responsável da Task, irmão dos
+executores, nunca filho de cada trabalhador. Ele avalia e retorna uma decisão
+restrita; o host autorizado a persiste e a CLI aplica a transição. Um macro
+coordena um responsável por tentativa de Task e seus gates parentais próprios.
 
 ## Boas praticas
 
@@ -43,3 +45,9 @@ reportado apos a barreira de finalizacao estar satisfeita.
 - Use paralelismo apenas quando reduzir o caminho critico sem elevar conflito.
 - 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.
+[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.

package/templates/.agents/zaip-aios/guides/10-seguranca.md

@@ -242,3 +242,12 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 | `.codex/hooks/zaip-pre-tool-use.mjs` | guarda adicional de comandos |
 | `.codex/rules/` | decisões determinísticas de comandos permitidos e proibidos |
 | este guia | contrato operacional e comparação dos perfis |
+
+## Autonomia não é permissão
+
+Essencial, Equilibrado e Persistente controlam persistência, não sandbox.
+Persistente ilimitado não remove approvals, escopos, proteção de segredos,
+revisão ou autoridade para publicação. Replanejadores gerenciados têm ferramentas
+isoladas; executor e Gui conservam seus próprios limites.
+Hooks best-effort e prompts não substituem controle preventivo do host.
+Veja [limites do runtime](19-assurance-e-autonomia.md).

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

@@ -10,3 +10,72 @@
 Run é o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo identifica esse nível. Sub-Run é a chamada de qualquer subagente e possui `parent_run_id`. Ambas podem agregar Calls, segmentos de uso, tokens e custo; Calls não possuem tela ou lifecycle próprio. A configuração solicitada de modelo e effort pertence à Run. Modelo, effort e tier efetivos só devem ser reportados quando vierem de evento/provider observado: defaults do catálogo, seleção planejada ou comportamento aparente não os comprovam. Operação e Monitor de Custos apresentam “Chamadas do agente orquestrador” e “Chamadas de subagentes”; a Execution soma as duas categorias, finalizadores e Calls sem dupla contagem. Cada segmento de uso possui uma chave de origem e só pode ser atribuído uma vez; uma correção de duplicidade registra supersessão e preserva o evento histórico. Inspecione `run_purpose`, pai e `agent_name`; agentes do catálogo usam `zaip-agent-*`. Diferencie status técnico da chamada de agente e resultado terminal da Task. Reconcilie lifecycle globalmente apenas por comando humano explícito ou pelo popup confirmado; isso não ocorre em cada turno nem ao abrir o dashboard.
 
 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.
+
+## Contagem de autonomia e consultas compactas
+
+### Leitura dos números do Dashboard
+
+O total operacional de Tasks, a distribuição por risco e as contagens temporais
+de Tasks usam a população sem rascunhos. Runs e custos já observados de um
+rascunho continuam preservados; excluir a Task do indicador não apaga seu uso.
+PRDs/SPECs em definição mantêm seu próprio contrato de contagem.
+
+O rodapé de Provedores pertence à mesma consulta e aos mesmos filtros das
+linhas, antes da paginação. Não é substituído pelo custo global: chamadas sem
+atribuição ao provedor e outras populações podem tornar esses totais diferentes.
+Valores parciais conhecidos não comprovam custo total nem saldo da conta.
+
+O cartão de Tasks distingue `complete`, `partial` e `unavailable`. Uma soma
+conhecida aparece no cartão compacto **Custo Estimado**, sem ícone. O tooltip e a
+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
+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.
+
+Rascunhos de Task sem execução permanecem consultáveis na lista, mas não ocupam
+a coluna de Definição do Kanban: essa etapa pertence aos PRDs. A projeção de
+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.
+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.
+
+O inventário SQLite recalcula hashes de arquivos recém-alterados: gravações
+rápidas no Windows podem preservar tamanho, mtime e até ctime. Durante a janela
+de estabilização de dois segundos não reutiliza o hash; a primeira leitura após
+essa janela também confere o conteúdo antes de habilitar o cache histórico.
+Checkpoints anteriores a essa proteção são revalidados. Verificação explícita
+de conteúdo continua disponível; o cache não garante detectar adulteração de
+metadados nem oferece semântica de filesystem distribuído.
+
+As médias temporais são calculadas antes da paginação, sobre todo o período
+filtrado. Mudar de página não altera a média. Para tokens e custo, o denominador
+inclui os períodos com medição conhecida; ausência total permanece indisponível.
+
+Tentativas/replanejamentos vêm do diário durável da Task; não de duração,
+tokens, Calls ou contagem de testes. `attempt_count` do lifecycle mede outra
+transição. Custo equivalente é uma estimativa, não saldo de créditos.
+
+A CLI `run list`/`run aggregate` usa projeções de entidades Run, preservando
+identidade, ordenação, filtros e métricas conhecidas/parciais. Campos obrigatórios
+ausentes geram diagnóstico de rebuild explícito, não zeros sintéticos nem
+leitura global oculta dos JSONLs. `run show RUN-ID` é inspeção canônica explícita.
+`source_latest_at` e `lag_ms` precisam refletir a fonte, não a hora do refresh.
+
+Isso não comprova custo O(1), economia de tokens ou o benchmark completo de
+20 pares da v3. Projeções, API, DOM e produção requerem provas próprias.
+
+O Dashboard coleta uso de uma Run ativa por passagem, em rodízio a cada minuto
+(`run usage --active --limit 1 --disable-codex-raw`). Esse orçamento de coleta
+não limita a execução da tarefa. Com várias Runs ativas, a cobertura leva mais
+de uma passagem; não prometa atualização simultânea ou custo O(1). Uma falha de
+coleta aparece em `active_capture_failure`; falha de projeção aparece em
+`projection_refresh_failure`. Dados canônicos continuam atualizáveis mesmo
+quando a coleta falha, sem transformar a telemetria ausente em zero.

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

@@ -29,10 +29,15 @@ 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.
 
-Novas instalações mantêm seleção de modelo em `manual`. Instalar ou atualizar
-não ativa Astra automaticamente. O opt-in `auto` aplica-se a SPEC/PRD e a allowlist
-Astra habilita somente diagnóstico `high`, limitado e evidenciado, conforme o
-[guia 23](23-orquestracao-de-modelos.md). Conversas e Tasks avulsas preservam a seleção do host.
+Novos templates mantêm a seleção do principal em `manual` e configuram
+`execution.runtime: managed` para PRD/SPEC, 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
+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.

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

@@ -10,9 +10,15 @@
 - Registre observação somente como resultado declarado e vinculado; ela não
   executa comandos, não examina automaticamente telas e não aprova um AC.
   Aplique o [contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
-- Nunca termine a Run raiz sem o Sub-Run finalizador ou com Task em executing/verifying.
+- 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.
 - Use uma SPEC por padrão; divida somente capacidades realmente independentes e paralelizáveis.
 - 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.
+- 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

@@ -12,3 +12,21 @@ Se uma Task estiver presa em executing/verifying, use o popup Reconciliar. O rep
 Se o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.
 
 Se “finalizar” tentou entregar um PRD `draft`, confira adapters/skills: o correto é lapidar e mover para `ready`. Se uma DAG nova cruza SPECs, una as capacidades em uma SPEC e mantenha a dependência entre suas Tasks. PRD cancelado não reabre; crie sucessor `rework`.
+
+## Repetição, orçamento e recibos
+
+| Sintoma | Diagnóstico e próxima ação |
+| --- | --- |
+| Task longa, ainda com trabalho real | Examine progresso/logs; não encerre apenas pela duração |
+| `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 |
+| 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 |
+| Snapshot de Runs incompleto | Rebuild explícito dos manifests; não invente campos ou faça varredura JSONL oculta na query |
+
+A tolerância de dez minutos para Run órfã no reparo manual não é prazo de
+desistência de Task em atividade. Um timeout operacional também não comprova
+falha do produto. Veja [autonomia](19-assurance-e-autonomia.md) e
+[relay de fechamento](16-lifecycle-e-reconciliacao.md).

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

@@ -15,7 +15,7 @@ Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro
 |---|---|
 | Definicao | somente PRD draft |
 | Planejamento | somente SPEC draft |
-| Pronto para Executar | PRD/SPEC ready e Task avulsa nao iniciada |
+| Pronto para Executar | PRD/SPEC ready e Task planned nunca iniciada/tentada, avulsa ou da DAG |
 | Execucao | Task executing e SPEC/PRD active |
 | Verificacao | Task verifying ou macro nos gates parentais |
 | Finais | completed/delivered, blocked, failed ou cancelled |
@@ -30,13 +30,32 @@ Pensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro
 - cada Run/Sub-Run fixa agente, modelo e effort; mudanca deliberada abre outra chamada de agente.
 - Calls e ferramentas sao eventos internos; quantidade, tokens e custo ficam agregados na Run/Sub-Run, sem tela propria.
 
-Toda delivery e interaction com descendentes exigem ao menos um executor
-elegível por capacidade e o `zaip-agent-finalizer` como último filho. Ele aguarda
+Toda delivery e interaction delegada exige o `zaip-agent-finalizer` como último filho.
+Sucesso também exige executor elegível por capacidade ou raiz Task direta autorizada. Gui aguarda
 os demais descendentes, bloqueia novas chamadas e retorna a decisão restrita
 para a CLI aplicar. Interaction read-only sem descendentes termina após a
 resposta, sem executor/finalizador. Publicação puramente Git não cria lifecycle.
 Status técnico da chamada de agente e resultado do trabalho são independentes.
 
+Se nenhum executor pôde iniciar e não há raiz Task direta autorizada válida,
+Gui ainda pode registrar bloqueio/falha real, mas `executor_missing` impede
+`completed` mesmo com Evidence aprovada. Uma raiz direta válida satisfaz essa
+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
+
+A Task avulsa prefere o principal direto. 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
+observados, inclusive `ultra`, são preservados sem ampliar a allowlist automática.
+Raiz macro, filho ou captura incompleta não recebem esse contrato.
+
+Gui pode avaliar essa entrega sem um executor filho fictício. Evidências,
+revisão aplicável, candidato, descendentes terminados e decisão imutável continuam
+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`.
@@ -60,3 +79,35 @@ O reparo e idempotente: `task_complete` local exato permite tentar conclusao; ga
 ## Mutacoes
 
 Codigo, documentacao e configuracao exigem Task materializada e Run raiz ativa antes da escrita. Sao isentos deploy/publicacao Git sem mudanca de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e temporarios descartaveis. O hook pre-write faz checagem local do turno, sem tokens e sem reconciliacao global.
+
+## Um responsável e uma decisão real por tentativa
+
+Se a raiz já está atribuída à Task, ela é seu orquestrador: não crie outro Dave.
+O macro delega um responsável por Task elegível, com pai e profundidade reais.
+Executor/revisor retornam resultados; Gui é o último filho direto do responsável,
+irmão dos trabalhadores. O fechamento parental do PRD/SPEC é outro gate.
+
+A ordem canônica é **início observado → decisão real → Stop → fechamento**.
+Gui read-only avalia e retorna; não grava lifecycle nem precisa permanecer
+ativo esperando um recibo. O host autorizado retransmite a decisão com
+`subagent capture --event stop`, usando identidade rica real e campos
+`--task-outcome`, `--summary`, `--evidence` e `--changed-files`.
+A CLI autentica vínculos e persiste a decisão imutável antes do Stop canônico.
+
+- Gui nativamente terminal ainda pode ter sua decisão retransmitida se o
+  responsável estiver aberto. Status nativo `completed` não é aprovação.
+- Responsável fechado só aceita replay de decisão já persistida. Sem decisão,
+  requer recuperação/nova tentativa autorizada; não invente aprovação retroativa.
+- Gui sem decisão, executor inelegível, Evidence ausente/mista ou correlação
+  inválida continua bloqueando; nenhum recibo pode ser fabricado.
+- No gerenciado, `closure_pending` retoma apenas a conciliação da decisão,
+  sem despachar outro worker/reviewer/Gui.
+- 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,
+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.
+Revisão aplicável, Evidence e decisão real de Gui continuam obrigatórias;
+uma autorização humana apenas no texto não substitui o contrato capturado.

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

@@ -21,7 +21,7 @@ O schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos
 | Rafa | Tech Lead | `zaip-agent-builder` | `rafa_tech_lead_zaip_agent` | Cria/refina SPECs e executa delivery genérico, inclusive dashboard/local. | Definição técnica ou mudança sem especialista mais específico. | PRD, design central, website, frontend ou backend especializados. | `spec`, `architecture`, `decomposition`, `dashboard`, `local` |
 | Leo | Software Engineer | `zaip-agent-task-executor` | `leo_software_engineer_zaip_agent` | Executa Task genérica delimitada, inclusive dashboard/local, e produz evidência. | Task pronta, autocontida e sem escopo de especialista obrigatório. | Planejamento macro, coordenação ou revisão independente. | `task`, `implementation`, `verification`, `evidence`, `local` |
 | Bia | Product Manager | `zaip-agent-analyst` | `bia_product_manager_zaip_agent` | Cria/refina PRDs e analisa interações sem antecipar Tasks de delivery. | Problema de produto, PRD, descoberta, escopo ou refinamento. | SPEC, implementação, aprovação técnica ou deploy. | `prd`, `product`, `discovery`, `requirements`, `problem` |
-| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Obrigatoriamente como último Sub-Run de interação ou delivery. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |
+| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Último filho do responsável em delivery ou interaction delegada; não em conversa read-only sem filhos. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |
 | Nanda | Principal Engineer | `zaip-agent-reviewer` | `nanda_principal_engineer_zaip_agent` | Revisa Requirements, diff, testes e evidências sem mutar produto. | Mudança implementada que precisa de revisão independente. | Para implementar a própria correção ou integrar worktrees. | `review`, `findings`, `requirements`, `diff` |
 | Dani | Integration Engineer | `zaip-agent-integrator` | `dani_integration_engineer_zaip_agent` | Integra trabalho revisado e executa gates combinados. | Worktrees ou mudanças independentes já revisadas. | Antes da revisão ou para criar requisitos. | `integration`, `merge`, `combined-gates`, `worktree` |
 | Ana | Quality Auditor | `zaip-agent-auditor` | `ana_quality_auditor_zaip_agent` | Reproduz evidências e emite auditoria independente. | Risco alto, release ou alegação que exige reprodução final. | Implementação, correção ou autoria da evidência. | `audit`, `reproduce`, `release`, `quality` |
@@ -32,7 +32,6 @@ O schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos
 | Will | Backend Specialist | `zaip-agent-backend` | `will_backend_specialist_zaip_agent` | Implementa backend, APIs, persistência e integrações. | `apps/backend/**`, `modules/**` ou capability de backend. | Frontend, website ou design visual central. | `backend`, `api`, `persistence`, `integration` |
 | Jonny | Website Developer | `zaip-agent-website-developer` | `jonny_website_developer_zaip_agent` | Cria sites/LPs com stack do framework, SEO, GEO e acesso por agentes. | `apps/site/**`, site institucional, LP, SEO, GEO ou Markdown for Agents. | App de produto, backend ou mudança da regra central de design. | `website`, `landing-page`, `seo`, `geo`, `markdown-for-agents`, `agent-readiness` |
 | Manu | Product Designer | `zaip-agent-designer` | `manu_product_designer_zaip_agent` | Governa `DESIGN.md`, design tokens (cor, tipografia, espaçamento e raio), componentes centrais e páginas de catálogo digital. | Regra central de design, Design System, tokens, `design-system` ou `componentes`. | Word, PPT, imagem de marketing ou componente local que apenas consome regras existentes. | `design-system`, `design.md`, `tokens`, `central-components`, `componentes` |
-
 | Dan | Cloud Engineer | `zaip-agent-cloud-engineer` | `dan_cloud_engineer_zaip_agent` | Projeta e valida infraestrutura cloud declarada. | Infraestrutura cloud, provisionamento, containers, Terraform ou Docker. | Implementação de aplicação, deploy ou infraestrutura fora do escopo declarado. | `cloud`, `terraform`, `docker`, `provisioning` |
 | Luiz | Security Auditor | `zaip-agent-security-auditor` | `luiz_security_auditor_zaip_agent` | Audita segurança de forma independente e somente leitura. | Auditoria de segurança, mudança sensível ou release que exige avaliação independente. | Implementação, autoria de remediação ou deploy. | `security`, `audit`, `risk`, `release` |
 | Lucia | Marketing Analyst | `zaip-agent-marketing-analyst` | `lucia_marketing_analyst_zaip_agent` | Planeja marketing, copy, campanhas e briefs de imagem com evidência. | Estratégia de marketing, campanha, copy de landing page ou brief de imagem. | Implementação de produto, backend ou governança central de design. | `marketing`, `copy`, `campaign`, `image-brief` |
@@ -74,3 +73,12 @@ Nanda (`agent-reviewer`) usa `gpt-5.6-terra` com esforço `medium` e `soft_cycle
 ## Dashboard e segurança operacional
 
 A tela **Configurações > Catálogo de agentes** apresenta a persona e mantém a identidade técnica somente leitura. Ao salvar, o runtime valida o catálogo, deriva o único nickname, sincroniza adapters e reverte a escrita se a paridade falhar. Agentes de framework permitem alteração de persona e preferências de modelo/effort; propósito, capacidades e identidade técnica continuam protegidos.
+
+## Preset e configuração efetivamente executada
+
+Defaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,
+o preset e a seleção final do despacho gerenciado também são validados:
+Essencial veda Astra automático e não herda a exceção manual do principal.
+Informe ao usuário a delegação necessária e a possibilidade de modelos
+diferentes. Mantenha indisponível o que o host não informou.
+Consulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).