@zaip-ai/cli 2.2.0 → 3.0.0

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-DaSllaJp.js → DashboardHelpDialog-TnrL1ZyZ.js}

@@ -1,16 +1,20 @@
-import{S as e,b as t}from"./cost-monitor-DbaLbU2q.js";import{t as n}from"./dashboard-localization-CLJ0lT9v.js";var r=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{t as r}from"./dashboard-localization-Basaw1NR.js";var i=`# Primeiros passos
 
 1. Leia \`.agents/config/project.yaml\` e \`.agents/rules/core.md\`.
 2. Consulte \`.agents/records/lifecycle/\` para descobrir o estado atual pelos manifests canônicos.
 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\`.
-`,i=`# Requirements
+
+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.
+`,a=`# Requirements
 
 Use Requirement para uma obrigacao duravel e testavel.
 
@@ -27,7 +31,7 @@ Para uma entrega nova ou retomada explicitamente, planeje também o cenário
 discriminante, ambiente e modalidade de observação por AC. O contrato de
 [prova observável](../../skills/zaip-skill-change/references/observable-evidence.md)
 define estados, limites e o que ainda depende de revisão humana.
-`,a=`# Tasks
+`,o=`# Tasks
 
 Use Task para uma entrega pequena, independente e com um resultado claro.
 
@@ -36,7 +40,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.
 
@@ -44,8 +48,21 @@ Em PRD/SPEC \`draft\`, a lista visível vem dos blueprints do PreparedPlan e nã
 
 ## 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.
-`,o=`# SPECs
+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.
+`,s=`# SPECs
 
 Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
 
@@ -65,7 +82,20 @@ 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.
-`,s=`# PRDs
+
+## 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.
+`,c=`# PRDs
 
 Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
 
@@ -103,10 +133,23 @@ PRD cancelado permanece imutável. Novo planejamento cria sucessor \`draft\`, ta
 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.
-`,c=`# 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.
+## 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.
+`,l=`# Execucao
+
+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.
@@ -115,7 +158,8 @@ Toda Execution originada por PRD usa velocidade \`standard\` em todas as SPECs,
    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.
 
@@ -130,12 +174,26 @@ 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.
-`,l=`# Revisao e validacao
+
+## 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).
+`,u=`# Revisao e validacao
 
 1. Revise Requirements e criterios de aceite.
 2. Examine diff, limites arquiteturais e caminhos de erro.
@@ -150,7 +208,21 @@ 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.
-`,u=`# Contexto e tokens
+
+## 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.
+`,d=`# Contexto e tokens
 
 1. Comece por \`project.yaml\`, \`core.md\` e pelos manifests de \`.agents/records/lifecycle/\`.
 2. Carregue somente a Rule, Requirement ou skill acionada.
@@ -167,16 +239,17 @@ 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.
 
 Menos texto de prompt não comprova menor custo total. Compare tokens, tempo, reparos e
 custo por tarefa aceita; mantenha separado o custo de uma pergunta simples. Consumo
 ausente permanece indisponível. Veja [observabilidade e custos](11-observabilidade-e-custos.md).
-`,d=`# Agentes e squads
+`,f=`# Agentes e squads
 
 O catalogo em \`.agents/config/agents/catalog.yaml\` e a fonte canonica para
 delegacao. Ele registra 23 agentes e 6 squads. Nomes exibidos, perfis e
@@ -188,7 +261,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.
@@ -196,10 +271,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
 
@@ -208,10 +283,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
 
@@ -221,7 +296,13 @@ 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.
-`,f=`# Segurança dos perfis Codex ZAIP-AIOS
+
+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.
+`,p=`# Segurança dos perfis Codex ZAIP-AIOS
 
 ## Visão geral
 
@@ -460,11 +541,102 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 | \`.codex/zaip-aios-security.config.toml\` | configuração dedicada do perfil restrito |
 | \`.codex/zaip-aios-full-access.config.toml\` | configuração dedicada do perfil completo |
 | \`.agents/skills/zaip-skill-security/SKILL.md\` | avaliação dos riscos e controles |
-| \`.agents/skills/zaip-skill-setup/SKILL.md\` | instalação, correção e validação dos perfis |
+| \`.agents/skills/zaip-skill-setup/SKILL.md\` | instalação inicial dos modelos de perfil entregues pelo release |
+| \`.agents/skills/zaip-skill-config/SKILL.md\` | seleção, personalização, correção e validação dos perfis |
 | \`.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 |
-`,p="# Observabilidade e custos\n\n1. Selecione a Run pelo ID e confirme a fonte de cada métrica.\n2. Verifique duração, tokens, custo, retries e retrabalho, distinguindo observado, reconciliado e estimado.\n3. Compare aceite planejado com evidência produzida.\n4. Identifique gates lentos, contexto excessivo e chamadas repetidas.\n5. Agregue tendências sem expor prompts ou segredos sensíveis.\n6. Converta achados recorrentes em Rule, Requirement ou melhoria de skill.\n\nRun é 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.\n\nA 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.\n",m=`# Instalação e upgrade
+
+## 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).
+`,m=`# Observabilidade e custos
+
+1. Selecione a Run pelo ID e confirme a fonte de cada métrica.
+2. Verifique duração, tokens, custo, retries e retrabalho, distinguindo observado, reconciliado e estimado.
+3. Compare aceite planejado com evidência produzida.
+4. Identifique gates lentos, contexto excessivo e chamadas repetidas.
+5. Agregue tendências sem expor prompts ou segredos sensíveis.
+6. Converta achados recorrentes em Rule, Requirement ou melhoria de skill.
+
+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.
+`,h=`# Instalação e upgrade
 
 1. Verifique versão atual e estado limpo ou conscientemente preservado.
 2. Execute doctor/integrity antes da mudança.
@@ -495,16 +667,21 @@ 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.
 Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 [qualificação do pacote](26-qualidade-e-release.md).
-`,h=`# Boas praticas
+`,g=`# Boas praticas
 
 - Comece pelo resultado e aceite, nao pela ferramenta.
 - Mantenha dominio independente de infraestrutura.
@@ -516,13 +693,164 @@ Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 - 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.
-`,g="# Troubleshooting\n\n1. Reproduza o problema com o menor comando possivel.\n2. Leia a mensagem completa e identifique o primeiro erro causal.\n3. Rode doctor, validadores focados e `git diff --check`.\n4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.\n5. Compare `manifest.json`, `summary.json`, índices e chunks de `records/lifecycle`, sem varrer records.\n6. Corrija a causa, repita a reproducao e depois os gates completos.\n\nSe 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.\n\nSe o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.\n\nSe “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`.\n",_="# Tools e setup do Codex\n\n1. Peça ao agente para listar ou ativar uma tool; ele usa `$zaip-skill-tool-setup`.\n2. A skill lê somente catálogo e manifesto aplicável.\n3. MCP confiável é registrado desabilitado em `.codex/config.toml` e validado antes da ativação.\n4. API sem MCP confiável aciona `$zaip-skill-api-to-mcp` para gerar um adaptador seguro.\n5. Secrets nunca são coladas no chat; nomes ficam em `.agents/.env.example` e valores em armazenamento local ignorado.\n6. Alterações de configuração devem ser reversíveis e preservar preferências existentes.\n\nAtive por padrão apenas integrações públicas, read-only e sem autenticação, como documentação oficial. Browser/Playwright deve ser opt-in do perfil de desenvolvimento, pois inicia processos e amplia a superfície operacional.\n\n## MCP local gerado de API\n\n1. Modele um `adapter.yaml` a partir de documentação oficial; use o exemplo da skill API-to-MCP.\n2. Execute `scaffold-local-mcp.mjs` para gerar `definition.json`, `server.mjs` e `cli.mjs`.\n3. Rode `node .agents/tools/servers/<id>/cli.mjs doctor`.\n4. Faça chamadas read-only com `cli.mjs call <tool> '<json>'`.\n5. Gere um preview do Codex com `configure-local-mcp.mjs <id>`.\n6. Revise e aplique com `--write`; use `--enable` somente quando o doctor estiver pronto.\n\nO servidor usa STDIO, não abre porta e não exige deploy. Escritas ficam bloqueadas sem aprovação e `ZAIP_ALLOW_MCP_WRITES=1`.\n\n## Documentacao OpenAI\n\nO perfil default habilita `openaiDeveloperDocs` em `.codex/config.toml`, sem credencial e em modo read-only. Perguntas sobre OpenAI API, modelos, SDKs, Codex ou MCP devem acionar `$zaip-skill-openai-docs`, pesquisar o MCP oficial e citar a pagina consultada.\n",v="# Lifecycle e reconciliacao\n\n## Entradas\n\n- Conversation: pergunta, feedback ou análise read-only; captura uma interaction e Run sem Task artificial.\n- Task avulsa: resultado independente. Pedido de acao entra em Execucao antes da primeira escrita; pedido apenas de preparacao pode parar em Pronto para Executar.\n- SPEC: planejamento tecnico de multiplas Tasks; draft fica em Planejamento.\n- PRD: definicao de produto; draft fica em Definicao.\n\nPensar/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.\n\n## Colunas\n\n| Coluna | Entidades |\n|---|---|\n| Definicao | somente PRD draft |\n| Planejamento | somente SPEC draft |\n| Pronto para Executar | PRD/SPEC ready e Task avulsa nao iniciada |\n| Execucao | Task executing e SPEC/PRD active |\n| Verificacao | Task verifying ou macro nos gates parentais |\n| Finais | completed/delivered, blocked, failed ou cancelled |\n\n## Execution, Runs, Sub-Runs e Calls\n\n- Execution `interaction` registra conversa/definição; `delivery` coordena o trabalho materializado e sua DAG quando aplicável.\n- Run e a chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id` nulo.\n- Sub-Run e cada chamada de subagente; possui `parent_run_id` e compartilha o mesmo ledger `RUN-*`.\n- Novas gravacoes usam somente `run_role: intake|orchestrator|subagent`; `owner|contributor` sao valores historicos aceitos apenas na leitura e normalizados imediatamente.\n- `run_purpose` distingue `orchestration`, `execution`, `review`, `audit` e `finalization`.\n- cada Run/Sub-Run fixa agente, modelo e effort; mudanca deliberada abre outra chamada de agente.\n- Calls e ferramentas sao eventos internos; quantidade, tokens e custo ficam agregados na Run/Sub-Run, sem tela propria.\n\nToda delivery e interaction com descendentes exigem ao menos um executor\nelegível por capacidade e o `zaip-agent-finalizer` como último filho. Ele aguarda\nos demais descendentes, bloqueia novas chamadas e retorna a decisão restrita\npara a CLI aplicar. Interaction read-only sem descendentes termina após a\nresposta, sem executor/finalizador. Publicação puramente Git não cria lifecycle.\nStatus técnico da chamada de agente e resultado do trabalho são independentes.\n\n`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.\n\n`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`.\n\n## SPEC e PRD\n\nAo 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.\n\nObservações declaradas seguem o contrato de\n[prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\nElas não mudam status da Task nem permitem à reconciliação inferir sucesso.\n\nNovas SPECs de um PRD não possuem dependências entre si: são capacidades paralelizáveis e verificáveis isoladamente. Dependências e ordem ficam nas Tasks da mesma SPEC; integração final é gate parental.\n\n## Reconciliacao\n\nO popup Reconciliar chama `run reconcile --open` somente depois da confirmacao humana. Nao existe varredura ao abrir o dashboard, por turno ou por intervalo.\n\nO 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.\n\n## Mutacoes\n\nCodigo, 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.\n",y=`# Como o custo é calculado
+
+- 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).
+`,_=`# Troubleshooting
+
+1. Reproduza o problema com o menor comando possivel.
+2. Leia a mensagem completa e identifique o primeiro erro causal.
+3. Rode doctor, validadores focados e \`git diff --check\`.
+4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.
+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 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).
+`,v="# Tools e setup do Codex\n\n1. Peça ao agente para listar ou ativar uma tool; ele usa `$zaip-skill-tool-setup`.\n2. A skill lê somente catálogo e manifesto aplicável.\n3. MCP confiável é registrado desabilitado em `.codex/config.toml` e validado antes da ativação.\n4. API sem MCP confiável aciona `$zaip-skill-api-to-mcp` para gerar um adaptador seguro.\n5. Secrets nunca são coladas no chat; nomes ficam em `.agents/.env.example` e valores em armazenamento local ignorado.\n6. Alterações de configuração devem ser reversíveis e preservar preferências existentes.\n\nAtive por padrão apenas integrações públicas, read-only e sem autenticação, como documentação oficial. Browser/Playwright deve ser opt-in do perfil de desenvolvimento, pois inicia processos e amplia a superfície operacional.\n\n## MCP local gerado de API\n\n1. Modele um `adapter.yaml` a partir de documentação oficial; use o exemplo da skill API-to-MCP.\n2. Execute `scaffold-local-mcp.mjs` para gerar `definition.json`, `server.mjs` e `cli.mjs`.\n3. Rode `node .agents/tools/servers/<id>/cli.mjs doctor`.\n4. Faça chamadas read-only com `cli.mjs call <tool> '<json>'`.\n5. Gere um preview do Codex com `configure-local-mcp.mjs <id>`.\n6. Revise e aplique com `--write`; use `--enable` somente quando o doctor estiver pronto.\n\nO servidor usa STDIO, não abre porta e não exige deploy. Escritas ficam bloqueadas sem aprovação e `ZAIP_ALLOW_MCP_WRITES=1`.\n\n## Documentacao OpenAI\n\nO perfil default habilita `openaiDeveloperDocs` em `.codex/config.toml`, sem credencial e em modo read-only. Perguntas sobre OpenAI API, modelos, SDKs, Codex ou MCP devem acionar `$zaip-skill-openai-docs`, pesquisar o MCP oficial e citar a pagina consultada.\n",y=`# Lifecycle e reconciliacao
+
+## Entradas
+
+- Conversation: pergunta, feedback ou análise read-only; captura uma interaction e Run sem Task artificial.
+- Task avulsa: resultado independente. Pedido de acao entra em Execucao antes da primeira escrita; pedido apenas de preparacao pode parar em Pronto para Executar.
+- 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.
+
+## Colunas
+
+| Coluna | Entidades |
+|---|---|
+| Definicao | somente PRD draft |
+| Planejamento | somente SPEC draft |
+| 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 |
+
+## Execution, Runs, Sub-Runs e Calls
+
+- Execution \`interaction\` registra conversa/definição; \`delivery\` coordena o trabalho materializado e sua DAG quando aplicável.
+- Run e a chamada raiz do \`zaip-agent-orchestrator\`; possui \`parent_run_id\` nulo.
+- Sub-Run e cada chamada de subagente; possui \`parent_run_id\` e compartilha o mesmo ledger \`RUN-*\`.
+- Novas gravacoes usam somente \`run_role: intake|orchestrator|subagent\`; \`owner|contributor\` sao valores historicos aceitos apenas na leitura e normalizados imediatamente.
+- \`run_purpose\` distingue \`orchestration\`, \`execution\`, \`review\`, \`audit\` e \`finalization\`.
+- 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 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\`.
+
+## 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.
+
+Observações declaradas seguem o contrato de
+[prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
+Elas não mudam status da Task nem permitem à reconciliação inferir sucesso.
+
+Novas SPECs de um PRD não possuem dependências entre si: são capacidades paralelizáveis e verificáveis isoladamente. Dependências e ordem ficam nas Tasks da mesma SPEC; integração final é gate parental.
+
+## 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 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.
+
+## 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.
+`,b=`# Como o custo é calculado
 
 Cada estimativa de custo começa em tokens de uma chamada LLM capturados por fonte aceita. O dashboard não estima uso ausente: tokens ou custo sem os componentes necessários permanecem indisponíveis. Uma duração estimada é uma derivação identificada por proveniência e não preenche telemetria de uso.
 
@@ -554,9 +882,182 @@ O esforço não possui multiplicador direto de preço. Ele só pode aumentar o c
 ## 4. Converta para a moeda selecionada
 
 O total da chamada é calculado primeiro em USD. Em BRL, a estimativa exige uma cotação identificada; a cotação histórica registrada e a cotação corrente são fontes distintas. Mudar a moeda de exibição nunca altera a telemetria de tokens nem o cálculo em USD.
-`,b='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| 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` |\n| 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` |\n| 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` |\n\n| 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` |\n| 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` |\n| 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` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO 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.\n\nO 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.\n\nO `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.\n\nNanda (`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.\n\n## Dashboard e segurança operacional\n\nA 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.\n',x=`# Assurance adaptativa e autonomia opt-in
+`,x='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| 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` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO 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.\n\nO 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.\n\nO `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.\n\nNanda (`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.\n\n## Dashboard e segurança operacional\n\nA 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.\n\n## Preset e configuração efetivamente executada\n\nDefaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,\no preset e a seleção final do despacho gerenciado também são validados:\nEssencial veda Astra automático e não herda a exceção manual do principal.\nInforme ao usuário a delegação necessária e a possibilidade de modelos\ndiferentes. Mantenha indisponível o que o host não informou.\nConsulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).\n',S=`# Assurance adaptativa e perfis de autonomia
+
+Este guia descreve \`autonomy-v1\`, implementado nas fontes em preparação para a
+v3. Não significa que \`@latest\` já distribua essas mudanças ou que a release
+esteja qualificada. Confira a versão instalada e o caminho de execução.
+
+## Quatro configurações independentes
+
+| Controle | Valores | O que decide |
+| --- | --- | --- |
+| Instalação | \`full\`, \`dev-lite\`, \`lite\` | Ferramentas instaladas, não orçamento de IA |
+| Assurance | risco \`lite\`, \`standard\`, \`critical\` e sinais persistidos | Provas necessárias para aceitar a entrega |
+| Autonomia | \`essential\`, \`balanced\`, \`persistent\` | Persistência e replanejamento por Task |
+| Runtime | \`manual\`, \`managed\` ou \`autonomous\` | Sem provider, PRD/SPEC gerenciados ou também Task gerenciada explícita |
+
+\`model_orchestration\` é a política de seleção, não o botão de ativação do
+runtime. Salvar um preset não inicia uma Task, não altera o seletor do Codex e
+não concede permissão externa.
+
+## Perfis por Task
+
+| Perfil | Execuções máximas | Replanejamentos máximos | Rota dos replanejamentos |
+| --- | --- | --- | --- |
+| Essencial (\`essential\`) | **4**: 1 inicial + 3 reparações | **1** | Sol/high; nunca Astra automático |
+| Equilibrado (\`balanced\`, padrão novo) | **10**: 1 inicial + 9 reparações | **3** | Sol/high → Astra/high → Astra/high |
+| Persistente (\`persistent\`, opt-in) | **Sem teto** | **Sem teto** | Sol/high primeiro; Astra/high nos seguintes |
 
-O ZAIP-AIOS separa duas decisões que não devem ser confundidas: quanto de prova uma entrega exige e quem executa a DAG. A primeira é governada por \`assurance\`; a segunda por \`execution\`. O modo manual continua sendo o padrão seguro e econômico.
+Cada replanejamento válido libera até três reparações. São tetos, não uma
+obrigação de falhar ou gastar todas as tentativas. Se o aceite passar antes,
+siga para revisão e fechamento. No Equilibrado não existe quarto
+replanejamento; no Persistente não existe teto oculto de 10, 24 ou três planos.
+
+Exemplo máximo do Equilibrado:
+
+1. Execução inicial: tentativa 1.
+2. Replanejamento 1 com Sol/high: reparações nas tentativas 2–4.
+3. Replanejamento 2 com Astra/high: reparações nas tentativas 5–7.
+4. Replanejamento 3 com Astra/high: reparações nas tentativas 8–10; Astra/high
+   também pode executar nesse bloco, se selecionado pela rota válida.
+5. Sem aceite, registrar entrega parcial e resultado verdadeiro; não abrir
+   outra rodada gratuita.
+
+Uma SPEC com dez Tasks Equilibradas admite até **100 execuções** (10 iniciais
++ 90 reparações) e **30 replanejamentos**. A quota pertence a cada Task estável,
+não ao PRD, à SPEC, à Execution ou ao subagente. Calls internas, ferramentas,
+testes individuais, revisões e finalização não são dez execuções de produto:
+o teto não significa dez chamadas totais ao modelo.
+
+Persistente pode continuar indefinidamente e consumir créditos até
+cancelamento humano; fica desligado por padrão. Não promete ultrapassar
+indisponibilidade do host, falta de autorização, segurança ou ausência de prova.
+
+## Configurar no projeto e no Dashboard
+
+Mescle este bloco na raiz de \`.agents/config/project.yaml\`, sem substituir
+as demais configurações:
+
+\`\`\`yaml
+autonomy:
+  version: 1
+  preset: balanced
+\`\`\`
+
+No Dashboard, abra **Configurações do projeto**, escolha **Perfil de autonomia**
+e salve. A UI explica os limites e o consumo potencial do Persistente; API e
+YAML usam a mesma enumeração. Recarregue e confira o valor persistido.
+\`essential\` e \`persistent\` são as outras escolhas válidas. Não invente campos
+para alterar cotas ou modelos da tabela: o schema desse bloco é estrito.
+
+A mudança vale para **novas Tasks**. Tasks já iniciadas conservam seu perfil e
+consumo. Projetos antigos sem \`autonomy\` conservam comportamento legado;
+selecionar/salvar um perfil não migra silenciosamente estados já materializados.
+
+## Contagem determinística e recuperação
+
+O coordenador gerenciado reserva a operação **antes** de chamar o provider em
+\`.local/autonomous/recovery/<hash-da-task>/ledger.json\`. O diário é durável,
+privado e vinculado à Task, com escrita exclusiva e transições idempotentes.
+Não é cache descartável nem deve ser removido para liberar uma nova tentativa.
+
+- Reinício, nova Execution, \`resume\`, \`rework\` ou alteração do YAML não zeram
+  esse consumo. O \`attempt_count\` do lifecycle não substitui o diário de
+  tentativas/replanejamentos do coordenador.
+- Replay compatível reutiliza a reserva; resultado conflitante é rejeitado.
+  Resultado desconhecido permanece pendente até recuperação observável.
+- Replanejamento inválido consome sua reserva e não autoriza reparação de
+  produto. Pode consumir o orçamento antes de alcançar dez execuções.
+- O relógio, tokens, contagem de testes e \`budget.soft_cycles\` não calculam
+  tentativas. Tempo continua útil para diagnóstico, não para desistir da Task.
+- Timeout de comando, lease, lock ou ausência de resposta do provider é um
+  problema operacional a investigar; não prova defeito do produto.
+- Preserve logs sanitizados e a hipótese já tentada; não repita testes caros
+  inalterados apenas por demora, nem diminua ACs para obter aprovação.
+
+## Tarefas avulsas e modelos
+
+A Task avulsa prioriza execução direta com o modelo/esforço escolhido pelo
+usuário. Exemplo: Astra/ultra manual no principal não é uma escalada automática.
+No Essencial essa é a única exceção Astra: não se estende a filhos, herança ou
+fallback.
+
+Delegação só por necessidade concreta, como especialidade, isolamento ou
+revisão/finalização exigida. Antes de delegar, informe que a orquestração ZAIP
+pode selecionar modelo/esforço diferentes para os subagentes. Não prometa que
+filhos usam Astra só porque o usuário selecionou Astra no principal.
+A configuração efetivamente observada permanece separada da planejada.
+
+O replanejador recebe contexto delimitado e não implementa produto. Fora do
+Essencial, Astra/high torna-se elegível como **executor a partir do terceiro
+replanejamento**, sem ampliar escopo, autoridade ou orçamento. Ele não
+substitui revisão independente nem Gui. Veja o [guia 23](23-orquestracao-de-modelos.md).
+
+## Quando continuar e quando encerrar
+
+| Situação após recuperação aplicável | Resultado |
+| --- | --- |
+| Resultado, ACs, gates e evidências suficientes | \`completed\`, após fechamento canônico |
+| Falta de verificação, evidência, acesso, decisão ou conclusão segura | \`blocked\`, com condição objetiva de retomada |
+| Impedimento técnico ou de integridade comprovado | \`failed\`, com causa e rework necessário |
+| Pedido humano explícito para cancelar | \`cancelled\` |
+
+Não reduza critérios de aceite ao esgotar tentativas. Preserve o que foi feito,
+liste ACs sem prova e informe quantas execuções/replanejamentos ocorreram.
+“Falhou após três replanejamentos” só é correto com causa técnica comprovada;
+sem prova suficiente o resultado é bloqueado. Tempo decorrido não escolhe
+entre esses estados.
+
+Na DAG, continue ramos independentes elegíveis; não execute dependentes de
+Task não concluída nem entregue o macro sem seus gates. Uma Task bloqueada
+não deve causar repetição de Tasks já concluídas.
+
+## Limites atuais e adoção
+
+A garantia de contagem/modelo vale **no despacho gerenciado**, antes da
+invocação. \`spawn_agent\` chamado diretamente pelo Codex fora desse caminho
+não é interceptado por prompt, hook best-effort ou captura posterior.
+Sem observar o caminho real, não alegue controle determinístico universal.
+
+Novos projetos usam Equilibrado e \`execution.runtime: managed\`: PRDs/SPECs
+passam pelo executor gerenciado e avulsas permanecem diretas. \`manual\` e
+configuração legada ausente continuam sem provider. \`autonomous\` permite
+também Task avulsa gerenciada por comando explícito. Salvar não executa.
+
+A captura direta usa \`conversation start ... --direct-authorization REFERÊNCIA\`
+ou \`run start\` com a mesma opção, somente para raiz de delivery atribuída a
+Task/Change/Execution e turno/modelo observados. O contrato fica imutável no
+início; não converte raízes antigas nem cria executor fictício. Gui, Evidence,
+revisão aplicável e sua barreira continuam obrigatórios. O [guia 16](16-lifecycle-e-reconciliacao.md) descreve o relay.
+
+Migração explícita: \`task migrate-autonomy TASK --execution EXEC --expected-revision N
+--legacy-attempts N --legacy-replans N --reason MOTIVO\` mostra o preview;
+acrescente \`--confirm\` somente após revisar a contagem histórica. Exige Task
+inativa, inventário de Runs terminado, contagens não inferiores ao histórico
+observado e motivo. Preserva registros, estados e Evidence; congela o diário
+durável por Task. Não reaproveita planos antigos como autorização atual: exige
+novo plano dentro da quota restante. Se a quota acabou, continua esgotada.
+
+Se o número histórico de replanejamentos não foi registrado, use
+\`--legacy-replans unknown --future-replans N\` com uma concessão humana explícita
+dentro do preset (até 3 no Equilibrado). O total histórico permanece desconhecido;
+\`N\` limita somente os replanejamentos futuros. \`--legacy-attempts N\` continua
+preservando as execuções já consumidas: a concessão não reinicia o limite de dez.
+No Persistente, \`--future-replans unlimited\` exige a escolha explícita desse perfil.
+
+Não há economia financeira garantida pelos presets. Compare custo/tokens por
+Task aceita com cobertura real, incluindo reparos, revisão e replanejamento.
+Testes simulados de modelos não comprovam cobrança nem execução paga no host.
+
+## Assurance por domínio
+
+O preset não escolhe o rigor. Desenvolvimento exige testes comportamentais,
+regressões, segurança e rollback conforme risco. Conteúdo de Marketing,
+Branding ou Vendas exige fidelidade a fontes/briefing e revisão apropriada;
+Growth e Ops exigem dados, premissas e critérios de decisão explícitos.
+Não imponha teste de código a uma peça textual, nem use “texto” para dispensar
+segurança, autorização externa ou validação factual.
 
 ## Matriz de validação
 
@@ -621,11 +1122,14 @@ execution:
 
 O projeto ZAIP-AIOS limita a concorrência produtiva a \`max_parallelism: 3\`, mas inicia em 1. A elevação só ocorre quando existem ramos sem dependência e sem sobreposição de write scope; o coordenador reivindica cada lote novamente com os locks do scheduler. O paralelismo efetivo é sempre o menor limite entre projeto, plano independente, provider e squad. \`budget.soft_cycles\` é aplicado ao agente escolhido em cada Task; tokens permanecem telemetria e custo, não checkpoint. \`zaip run aggregate --agent agent-ID\` filtra a identidade e retorna duração, ciclos observados, tokens, custo, cobertura e rework. Telemetria não capturada permanece indisponível, nunca zero.
 
-O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado, quota de orçamento e handoff próprios, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
+O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado e handoff próprios; em \`autonomy-v1\`, o orçamento de recuperação continua no diário estável de cada Task, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
 
 O driver autônomo:
 
-- usa protocolo nativo JSONL de Codex ou Claude, sem shell;
+- usa protocolo nativo JSONL, sem shell. O contrato legado suporta Codex ou Claude;
+  o despacho gerenciado com \`autonomy-v1\` atualmente exige Codex e rejeita Claude
+  antes de invocar o provider. Conversas diretas continuam disponíveis no provider
+  escolhido; isso não comprova suporte Claude à orquestração autônoma v1;
 - cria worktree Git por Task a partir de uma raiz limpa;
 - limita alterações aos write scopes;
 - exige commit final e valida os artefatos tipados dentro da worktree;
@@ -633,7 +1137,7 @@ O driver autônomo:
 - persiste estado com compare-and-swap;
 - serializa somente transições do estado durável e rebaseia cada Task, permitindo que invocações de ramos independentes executem em paralelo com segurança;
 - mantém checkpoints opacos somente em \`.local\`;
-- limita \`lite\` a uma tentativa e \`standard\`/\`critical\` a no máximo três tentativas de desenvolvimento ou reparo;
+- em \`autonomy-v1\`, usa exclusivamente os tetos por Task da tabela acima; somente no legado sem esse bloco mantém as quotas antigas por risco;
 - usa verificador independente para critical, SPEC e PRD.
 
 Na Task autônoma, o adapter respeita o mesmo rigor calculado: \`lite\` não exige
@@ -648,8 +1152,13 @@ Ativar \`autonomous\` não afirma que o runtime está validado em produção. A
 
 ## Cobertura e release
 
+Gui também pode registrar bloqueio/falha quando nenhum executor conseguiu iniciar.
+Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
+\`executor_missing\` rejeita conclusão sem executor elegível ou raiz Task direta
+explicitamente autorizada, mesmo que existam Evidences aprovadas.
+
 O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statements e 75% para branches. Uma medição atual abaixo disso pode ser registrada como baseline observada para diagnóstico, mas o gate continua vermelho. Release crítica também exige unit, E2E, arquitetura, CQRS, módulos, profile, segurança, testes negativos, paridade da distribuição e cleanroom do candidato exato.
-`,S='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- Git;\n- permissões de escrita no repositório consumidor.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx @zaip-ai/cli@latest init --dry-run\nnpx @zaip-ai/cli@latest init\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nO default de seleção de modelos é `manual`. O modo `auto` exige opt-in do projeto,\npermanece restrito a SPEC/PRD e mantém Astra como consultor diagnóstico opcional em\n`high`, com teto de três invocações por Task e devolução aos executores.\nVeja o [contrato de modelos e seus limites](23-orquestracao-de-modelos.md).\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e `CLAUDE.md`, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task criada ou preparada, mas não iniciada, aparece em Pronto\npara executar. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. `implemente` sem alvo abre apenas uma Conversation de planejamento, em `draft` finaliza o plano, em `ready` executa e em estados ativos/falhos continua, retoma ou cria rework. `desenvolva|melhore|aprimore` nunca executa automaticamente. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\n```bash\nzaip execution list\nzaip execution show EXEC-ID\nzaip execution start EXEC-ID\nzaip task next\nzaip task start TASK-ID\nzaip run start --short-name orquestrar-task --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\n# execute e verifique o trabalho\nzaip run start --short-name finalizar-execution --phase execution --run-purpose finalization --entrypoint task --work-type new --client codex-subagent --agent zaip-agent-finalizer --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --parent RUN-RAIZ-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run finish RUN-FINALIZADOR-ID --status completed\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\n```\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',C=`# Contrato de telemetria do Monitor de Custos
+`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- Git;\n- permissões de escrita no repositório consumidor.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nNovos templates mantêm a seleção do principal em `manual` e configuram\n`execution.runtime: managed` para PRD/SPEC, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.\nO Essencial nunca usa Astra automático. Principal avulso preserva a seleção\nmanual; filhos necessários seguem política divulgada. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e `CLAUDE.md`, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. `implemente` sem alvo abre apenas uma Conversation de planejamento, em `draft` finaliza o plano, em `ready` executa e em estados ativos/falhos continua, retoma ou cria rework. `desenvolva|melhore|aprimore` nunca executa automaticamente. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
 
 Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
 
@@ -659,7 +1168,12 @@ O Monitor de Custos é uma visão financeira da população de Runs de Operaçã
 
 ## Fonte e proveniência
 
-A projeção é **manifest-first**: usa os manifests e registros Git como fonte canônica e a telemetria local apenas para uma reconciliação com correspondência exata. O Dashboard não usa SQLite como fonte de dados do Monitor de Custos.
+Os registros e manifests Git-native são canônicos. No runtime atual, o Monitor
+também consulta o SQLite reconstruível: o resumo recebe agregados compactos,
+enquanto páginas de Runs combinam fatos com manifests canônicos atuais.
+Caminhos de compatibilidade preservam a leitura manifest-first.
+SQLite não é outra fonte de verdade; consulta não autoriza reconciliação
+global nem alteração do histórico.
 
 Tokens, custo e duração devem exibir sua proveniência. Tokens e configuração efetiva de modelo/effort só são observados quando a fonte os informa; defaults planejados não preenchem esses campos. A projeção pode exibir duração \`observed\`, \`reconciled\`, \`legacy_inferred\` ou \`estimated\`. Apenas \`observed\` é medição da fonte; as demais são derivadas e não satisfazem um critério que exija duração capturada.
 
@@ -671,9 +1185,20 @@ Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual
 
 Não use contagens, totais ou percentuais de auditorias passadas como diagnóstico atual. Consulte o período e os filtros da execução auditada; uma lacuna de coleta continua sendo lacuna, mesmo quando há estimativa ou reconciliação exibida.
 
+Na Visão geral de Tasks, cobertura incompleta produz **Subtotal estimado
+conhecido**, com valor e contagem conhecida/total. Médias de custo por item/hora
+ficam indisponíveis nessa condição para não misturar populações.
+Cobertura completa permite o rótulo **Custo estimado**. Sem soma
+conhecida, o valor continua indisponível; um zero conhecido não é ocultado.
+Esses três estados não equivalem a saldo, fatura ou custo integral do provider.
+
 ## Filtros e totais
 
-Filtros preenchidos somente com data são inclusivos: a data inicial começa em \`00:00:00.000Z\` e a final termina em \`23:59:59.999Z\`. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
+Filtros preenchidos somente com data são inclusivos pelo calendário IANA
+\`America/Sao_Paulo\`: início à meia-noite local e fim imediatamente antes do
+próximo dia local, convertidos para UTC. Considere DST histórico; não fixe
+\`-03:00\` nem use o dia UTC como substituto. Timestamps explícitos conservam
+seu instante. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
 
 ## Verificação operacional
 
@@ -695,7 +1220,7 @@ Filtros preenchidos somente com data são inclusivos: a data inicial começa em
 3. Consulte \`/api/v2/cost-monitor\` no período auditado. Confirme que os campos de cobertura e proveniência são coerentes com o objetivo da auditoria; para alegar telemetria capturada, exija tokens, custo e duração observados, não apenas totais ou estimativas. Em seguida, compare o total de custo retornado com o card da Visão geral usando exatamente os mesmos filtros.
 
 Se houver uma lacuna, preserve-a como ausência até existir uma correspondência exata e única. Reconciliação ou estimativa podem ser exibidas com proveniência, mas não autorizam alegar token, custo ou duração capturados.
-`,w=`# Fluxos e roteamento ZAIP-AIOS
+`,T=`# Fluxos e roteamento ZAIP-AIOS
 
 Este guia preserva a explicação operacional detalhada sem tornar a página inicial pesada ou dependente do renderizador Mermaid do GitHub. Os fluxos são texto versionado e pesquisável; os ciclos de lifecycle que precisam de leitura visual usam PNG estático.
 
@@ -722,7 +1247,14 @@ atalho de aprovação: o registro não executa o procedimento, não transforma
 resultado pendente em verde e não dispensa review/finalizador. Consulte o
 [contrato canônico](../../skills/zaip-skill-change/references/observable-evidence.md).
 
-Em PRD/SPEC com \`model_orchestration.mode:auto\`, trabalho simples e delimitado pode usar Luna/low, execução padrão Terra/medium e ambiguidade, transversalidade ou rework estrutural Sol/high ou xhigh. Conversation e Task-first preservam a seleção manual do host/Codex. Criticidade amplia assurance; não eleva modelo mecanicamente.
+Com \`autonomy-v1\`, a recuperação segue o preset congelado por Task:
+Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente ilimitado.
+Replanejamentos usam Sol/high primeiro e Astra/high nos seguintes permitidos;
+Astra/high pode executar a partir do terceiro bloco fora do Essencial.
+Principal avulso preserva a seleção manual e prefere trabalho direto;
+delegação necessária informa que filhos podem usar outra configuração.
+Criticidade amplia assurance; não define a quota.
+Veja [autonomia](19-assurance-e-autonomia.md) e [modelos](23-orquestracao-de-modelos.md).
 
 ## Entradas e planejamento
 
@@ -760,7 +1292,12 @@ Task em execução → Orchestrator → Executor → Evidence e Decisions
                   → Auditor (quando necessário) → Finalizer → resultado
 \`\`\`
 
-O resultado pode ser concluído, bloqueado, falhado, cancelado ou exigir rework. Bloqueio e rework iniciam um novo ciclo controlado; cancelamento é uma decisão humana explícita. O finalizador fecha a Run somente depois da revisão e de qualquer auditoria exigida.
+O resultado pode ser concluído, bloqueado, falhado ou cancelado; rework é uma
+continuação autorizada, não outro estado terminal nem reset do orçamento.
+Sem evidência suficiente, bloqueie; com impedimento técnico comprovado, falhe.
+O host persiste a decisão de Gui e fecha pela CLI. Gui é último filho direto
+do responsável da Task, não de cada trabalhador; não aguarda recibos em loop.
+O controle de quotas depende do despacho gerenciado, não do desenho do fluxo.
 
 ## Lifecycle e operação
 
@@ -769,519 +1306,220 @@ O caminho de sucesso é Definição → Planejamento → Pronto para Executar
 ![Lifecycles de Task, SPEC e PRD](assets/diagrams/lifecycles-task-spec-prd.png)
 
 Para os contratos completos e comandos de lifecycle, consulte [28-lifecycle-completo.md](28-lifecycle-completo.md).
-`,T=`# Guia de orquestração de modelos e reasoning effort
-
-## Objetivo
-
-Este guia define como o ZAIP-AIOS recomenda modelo, \`reasoning effort\` e velocidade para cada trabalho. A política deve equilibrar quatro resultados:
-
-- alta assertividade na entrega;
-- baixo percentual de bugs e rework;
-- validação proporcional ao risco;
-- economia de tokens, custo e tempo total até a entrega verificada.
-
-Na implementação atual, a política suporta \`manual\`, \`off\` e \`auto\`. No projeto ZAIP-AIOS, \`auto\` está ativado somente para Executions originadas por SPEC ou PRD; Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex. \`manual\` continua disponível para rollback e permanece o default de novas instalações.
-
-Na política automática, Executions originadas por PRD ou SPEC solicitam velocidade \`standard\`, sem override para Fast. Em Conversation ou Task-first independente, a seleção de Fast pertence ao host/Codex; o ZAIP não a ativa, persiste nem herda. Velocidade do provider, paralelismo e tempo total até a tarefa aceita são medidas distintas.
-
-## Estado atual
-
-### Estado verificado do framework
-
-O schema canônico de \`project.yaml\` aceita \`manual\`, \`off\` e \`auto\`. O Agent Run registra agente, papel, pai, modelo e \`reasoning_effort\` planejados. O resolvedor aplica política e overrides quando a Run começa; Calls internas apenas herdam essa configuração e acumulam telemetria na própria Run.
-
-Uma mudança deliberada de modelo, effort, agente ou fase material exige uma nova Agent Run. Por isso, uma Task pode usar configurações diferentes em implementação, revisão e rework, desde que cada etapa possua sua própria Run relacionada. Retry técnico e retomada por checkpoint preservam a configuração original.
-
-### Modo manual
-
-Quando \`model_orchestration.mode\` estiver como \`manual\`, o ZAIP:
-
-1. usa modelo, esforço e velocidade somente quando estiverem explícitos no input ou contexto técnico do turno;
-2. classifica o trabalho;
-3. recomenda uma configuração;
-4. informa a recomendação antes de continuar;
-5. nunca altera a configuração automaticamente.
-
-O modo manual não usa hook nem tenta coletar a configuração efetiva no transcript. \`default_model\`, \`default_effort\` e \`default_velocity\` podem orientar uma recomendação, mas não comprovam o que o host executou. Quando modelo, effort ou velocidade efetivos não vierem de fonte observada, registre-os como indisponíveis/\`unknown\`; nunca os infira pelo comportamento aparente do modelo nem os substitua pelo default.
-
-Formato recomendado:
-
-\`\`\`text
-Você está usando o modelo <modelo>, esforço <esforço> e velocidade <velocidade>.
-Esta tarefa é <lite|padrão|crítico>; recomendo esforço <esforço> e velocidade
-<velocidade> porque <motivos observáveis>. Caso concorde, cancele esta tarefa
-e faça a configuração manual no Codex.
-\`\`\`
-
-### Modo automático por origem
-
-O modo automático resolve uma configuração antes de cada Agent Run elegível e preserva separadamente os valores planejados e os valores efetivamente observados. A decisão é metadado estruturado do runtime; instruções em linguagem natural como “use high effort” não garantem mudança real.
-
-O campo \`automatic_sources\` é a fronteira de aplicação. O contrato aceita exatamente \`spec\` e \`prd\`: somente as Tasks materializadas dentro dessas Executions recebem seleção automática, sempre com velocidade \`standard\`. Uma Execution originada diretamente de \`task\`, uma Conversation ou uma Task avulsa não recebe a política e não herda \`default_model\`, \`default_effort\` nem \`default_velocity\`; preserva os três valores escolhidos manualmente no Codex.
-
-Cada Task ou fase materialmente distinta deve executar em seu próprio Agent Run. Calls produzidas durante a Run usam o mesmo modelo e effort. Tasks paralelas podem usar configurações diferentes simultaneamente quando estiverem isoladas em Runs próprias.
-
-O modo automático é híbrido e governado: o modelo pode propor a configuração a partir dos metadados da Task elegível, mas um resolvedor determinístico limita a decisão à allowlist, aos caps e à precedência do projeto. Isso preserva a flexibilidade documentada pelo Codex sem transformar uma decisão de custo e qualidade em texto não auditável.
-
-### Escolha manual no Codex
-
-Um \`.codex/config.toml\` sem cabeçalho \`zaip-managed\` é tratado como overlay local do usuário. \`adapters build\` o preserva e \`adapters check\` o aceita sem mascarar drift nos hooks, regras, instruções e demais projeções gerenciadas. Isso impede que uma atualização do framework restaure silenciosamente um pin de modelo ou apague preferências locais.
-
-Os registros e perfis \`zaip-agent-*\` pertencem exclusivamente ao catálogo do projeto em \`.agents/config/agents/catalog.yaml\`. Para Codex, os perfis gerados ficam em \`.agents/config/clients/codex/agents/*.toml\`, e \`.codex/config.toml\` mantém apenas os registros que os referenciam e o bootstrap nativo. A inicialização não copia configuração de projeto para \`~/.codex\`; somente remove registros globais legados que reutilizem essas identidades técnicas e poderiam prevalecer ou conflitar com o projeto confiável.
-
-O Codex trata \`model\` e \`model_reasoning_effort\` em \`config.toml\` como defaults duráveis. A precedência relevante é: flags/overrides da CLI, \`.codex/config.toml\` do projeto confiável e \`~/.codex/config.toml\`. Portanto, o pin que bloqueia a preferência pessoal é o do projeto, porque ele prevalece sobre o global.
-
-Para permitir escolha manual em Conversation e Task-first, não fixe \`model\`, \`model_reasoning_effort\` nem \`service_tier\` no \`.codex/config.toml\` do projeto. O arquivo global pode guardar a última preferência escolhida manualmente pelo usuário; remova esses campos globais somente quando quiser voltar aos valores recomendados. Reinicie o Codex depois de uma edição externa e use \`/debug-config\` ou \`codex --strict-config\` quando houver dúvida sobre precedência.
-
-## Princípios de decisão
-
-1. **Qualidade é uma restrição, não uma média com custo.** Acceptance Criteria, testes e gates precisam passar antes de otimizar tokens.
-2. **Use o menor effort que entrega a qualidade necessária.** Aumente somente por necessidade observável ou ganho medido.
-3. **Modelo, effort e risco são dimensões diferentes.** O modelo segue a forma e a complexidade da Task; o agente fornece o effort-base; o risco define gates.
-4. **Validação reduz bugs melhor que effort isolado.** Testes determinísticos, revisão independente e auditoria não podem ser substituídos por mais reasoning.
-5. **Custo relevante é o total até a entrega verificada.** Planejamento barato que gera muitos reparos pode custar mais que um planejamento mais profundo.
-6. **Escalada exige evidência.** Ambiguidade, falha estrutural, finding ou rework justificam elevar um nível; volume mecânico não.
-7. **Toda decisão deve ser observável.** Registre a configuração planejada no Agent Run e, quando disponível, a configuração efetiva agregada de suas Calls.
+`,E=`# Guia de orquestração de modelos e reasoning effort
+
+## Objetivo e versão do contrato
+
+A política busca resolver a entrega com prova suficiente e reduzir retrabalho,
+sem economia acima da qualidade nem persistência ilimitada por padrão.
+Este guia descreve as fontes em preparação para a v3, não uma release publicada.
+O [guia 19](19-assurance-e-autonomia.md) contém configuração, contagem e limites
+de \`autonomy-v1\`. A configuração efetiva do projeto e a versão instalada
+prevalecem sobre exemplos.
+
+Há três decisões independentes: modelo/esforço da invocação, persistência por
+Task e rigor da verificação. Risco não é quantidade de tentativas; preset de
+autonomia não é perfil de instalação nem permissão.
+
+## Principal avulso e delegação
+
+Conversation e principal de Task avulsa preservam o modelo e esforço escolhidos
+manualmente no Codex. Priorize execução direta. O ZAIP não troca silenciosamente
+o seletor do usuário nem exige subagente para responder uma pergunta simples.
+
+Se a entrega precisar de especialidade, isolamento ou revisão/finalização
+exigida, delegue pelo catálogo com escopo e responsabilidade explícitos. Antes,
+informe:
+
+> Orquestração ZAIP: subagentes podem usar modelo e esforço diferentes do agente
+> principal, conforme o perfil de autonomia. A configuração efetivamente
+> observada será informada.
+
+Não há obrigação de herdar o modelo do principal. Selecionar Astra/ultra no
+Codex não significa que todos os filhos executarão Astra/ultra. Modelo/effort
+planejados e efetivos são campos distintos; só a observação do host/provider
+comprova os efetivos. Reutilizar um UUID nativo não comprova que o modelo da
+nova invocação permaneceu igual.
+
+Delegação flexível não autoriza outro chat, identidade inventada, alteração de
+permissões, perda da revisão independente ou segundo responsável pela mesma
+Task. Delivery exige executor capturado ou contrato de raiz direta autorizada
+desde o início; a preferência direta não dispensa Evidence, revisão ou Gui.
+
+## Escalada em autonomy-v1
+
+| Preset | Replanejamento 1 | Replanejamento 2 | Replanejamento 3 | Execução Astra |
+| --- | --- | --- | --- | --- |
+| \`essential\` | Sol/high | Não existe | Não existe | Nunca automática |
+| \`balanced\` | Sol/high | Astra/high | Astra/high | Elegível no bloco do terceiro replanejamento |
+| \`persistent\` | Sol/high | Astra/high | Astra/high, e seguintes sem teto | Elegível a partir do terceiro replanejamento |
+
+O Essencial permite no máximo quatro execuções de produto e um
+replanejamento. O Equilibrado permite dez execuções e três replanejamentos.
+O Persistente é opt-in genuinamente ilimitado; não recebe o teto legado de
+três diagnósticos Astra. Cada plano válido libera até três reparações.
+
+A única exceção Astra no Essencial é o **principal avulso selecionado
+manualmente**. A seleção automática final é revalidada depois de herança,
+fallback e configuração. Um modelo Astra configurado num agente não libera
+Astra automático no Essencial.
+
+Nos demais presets, Astra automático usa somente \`high\`: não \`xhigh\`,
+\`max\` ou \`ultra\`. Pode replanejar a partir do segundo plano e executar a
+partir do terceiro, quando a rota válida o selecionar; não se torna reviewer
+ou finalizer. A exceção de execução não acrescenta tentativas nem amplia
+write scopes.
+
+O primeiro replanejamento usa \`gpt-5.6-sol\`; os seguintes permitidos usam
+\`gpt-6-astra\`. Executor e replanejador são invocações diferentes. Planejar
+com Astra não obriga a executar com Astra no segundo bloco.
+
+## Replanejar não é repetir sem diagnóstico
+
+O replanejador recebe objetivo, ACs, falha observada, evidência, restrições e
+histórico compacto do que foi tentado. O retorno gerenciado é JSON estrito com
+\`hypothesis\`, \`test\` e \`executor_model\`; a rota conserva o escopo autorizado.
+O adaptador isola suas ferramentas e MCPs; esse papel não
+edita produto nem cria outros filhos.
+
+No gerenciado, o pacote serializado é delimitado a 48.000 bytes e declara
+8.000 tokens de saída. Bytes não são tokens faturados. O modelo/esforço e a
+reserva são validados antes do despacho, e o resultado é persistido de forma
+imutável. Plano inválido consome a reserva e não libera reparação.
+
+Uma reparação aplica uma hipótese verificável, testa o comportamento relevante
+e preserva os ACs. Ausência de progresso exige diagnóstico novo dentro do
+orçamento; testes repetidos sem mudança não constituem nova evidência.
+Falha de ferramenta, credencial ou ambiente não comprova falha de raciocínio.
+
+Não existe abandono da Task por 15 ou 60 minutos. Timeouts técnicos, leases,
+telemetria de duração e checkpoints têm outras funções. Resultado desconhecido
+não libera despacho duplicado. Para retomada, consulte o diário existente,
+não crie outra Task ou apague \`.local\` para renovar a quota.
 
 ## Família de modelos
 
-A política preserva GPT-5.6 para execução e acrescenta Astra somente para diagnóstico difícil evidenciado:
-
-| Modelo | Uso preferencial |
-| --- | --- |
-| \`gpt-5.6-luna\` | trabalho claro, repetitivo, determinístico e de alto volume |
-| \`gpt-5.6-terra\` | implementação, teste, diagnóstico e integração cotidiana |
-| \`gpt-5.6-sol\` | trabalho ambíguo, transversal, arquitetural, crítico ou de alto valor |
-| \`gpt-6-astra\` | diagnóstico excepcional, somente \`high\`, seguido de devolução ao executor |
-
-Os defaults iniciais ficam definidos assim:
-
-| Campo | Default |
-| --- | --- |
-| modelo fallback/baseline | \`gpt-5.6-terra\` |
-| effort fallback/baseline | \`medium\` |
-| velocidade fallback/baseline | \`standard\` |
-| modelo eficiente elegível | \`gpt-5.6-luna\` |
-| modelo frontier elegível | \`gpt-5.6-sol\` |
-| consultor diagnóstico excepcional | \`gpt-6-astra high\`; até três diagnósticos por Task |
-| teto automático de effort | \`xhigh\` |
-| \`xhigh\` automático | habilitado somente pelos critérios de elegibilidade |
-| \`max\` e \`Ultra\` automáticos | fora de escopo |
-| velocidade solicitada | sempre \`standard\`; não participa da seleção |
-
-Terra \`medium\` é o fallback quando os sinais forem insuficientes ou conflitantes. Sol não deve ser usado em tudo; Luna não deve ser usado quando a Task depende de julgamento arquitetural ou ambiguidade relevante.
-
-\`ultra\` e \`max\` não fazem parte da política: o ZAIP-AIOS nunca os seleciona. Luna, Terra e Sol usam effort \`low\`, \`medium\`, \`high\` ou \`xhigh\` conforme elegibilidade. Astra usa somente \`high\`; nem um override libera \`xhigh\`, \`max\` ou \`ultra\` para ele.
-
-### Astra: diagnóstico, correção de rota e devolução
-
-Sol permanece como escolha normal da faixa difícil. Astra recebe uma questão diagnóstica delimitada quando o ganho potencial de evitar novo reparo justifica seu uso. A regra canônica é [RULE-ASTRA-DIAGNOSTIC](../../rules/astra-diagnostic.md), carregada apenas nessa avaliação; o kernel e os prompts de Marketing, Sales, Growth e Ops não incorporam essa expansão.
-
-| Situação observada | Rota |
-| --- | --- |
-| Pergunta direta, copy, análise comercial simples, alteração mecânica | Luna/Terra conforme perfil existente |
-| Arquitetura ou problema difícil com caminho conhecido | Sol; execução delimitada em Luna/Terra |
-| Tentativa executora falhou por hipótese/raciocínio; complexidade ou ambiguidade alta e evidência disponível | Um diagnóstico Astra high antes do reparo seguinte |
-| Impacto material crítico e diagnóstico difícil, ambos evidenciados | Astra high preventivamente, antes da primeira implementação |
-| Falha de ambiente, credencial, ferramenta, sintaxe ou ausência de prova | Corrigir a condição ou obter prova com o executor; não acionar Astra |
-| Mesmo diagnóstico/plano sem progresso, ou três diagnósticos já reservados | Parar a escalada; executar rota útil ou registrar bloqueio concreto |
-
-A expressão “tarefa crítica”, o risco isolado, o departamento, a quantidade de arquivos e o tamanho do pedido nunca bastam. A política usa metadados estruturados e prova referenciada. Um reparo localizado não se torna diagnóstico difícil só porque a primeira tentativa falhou.
-
-Cada ciclo significa **uma invocação diagnóstica Astra governada**, com reserva atômica antes do dispatch. O teto é três por ID estável de Task, somando retomadas, Runs e Executions; normalmente basta uma consulta. Uma reserva consumida não permite repetir o dispatch nem é devolvida após timeout. Call interna, evento de uso e checkpoint não são contadores de diagnóstico.
-
-O pacote de entrada contém falha observada, tentativa anterior, evidência, restrições e critérios de aceite. É uma sessão nova, sem herdar histórico integral, sem ferramentas de execução nem filhos. O envelope limita a entrada serializada a 48000 bytes, declara até 8000 tokens de saída e termina após até 180 segundos. Bytes não equivalem a tokens; o runtime verifica o consumo informado pelo provider, sem transformar orçamento declarado em economia medida.
-
-Astra retorna JSON com \`findings\`, \`evidence\`, \`cause_or_hypothesis\`, \`route\`, \`scope\`, \`test_plan\`, \`executor\` e \`recommended_model\` restrito a Luna/Terra/Sol. O coordenador valida o retorno e entrega a correção ao executor. Astra não implementa, não substitui a revisão normal e não finaliza a entrega.
-
-O objetivo da segunda tentativa é aplicar uma hipótese corrigida e testável. Outra consulta precisa de evidência nova e mudança de hipótese/rota; não se permite repetir o mesmo plano alternando Astra e Sol. Se faltar prova para avançar, o retorno identifica a prova faltante, sem prometer resolução automática.
-
-A política \`model-orchestration-v2\` mantém legível a configuração anterior com três modelos. Incluir Astra na allowlist habilita apenas essa rota condicionada; removê-lo desativa novos diagnósticos preservando histórico e quota. Novas instalações continuam em \`manual\`. O modo automático permanece restrito a SPEC/PRD. O framework controla processos que ele próprio despacha; não consegue alterar ou limitar uma sessão manual já selecionada no aplicativo Codex.
-
-O isolamento é aplicado pelo adapter Codex antes da inferência: configuração transitória, sandbox de leitura, ferramentas de shell/apps/browser/multi-agent desabilitadas e cada servidor MCP efetivo desabilitado individualmente. Se a configuração não puder ser verificada, o diagnóstico não inicia. Um evento inesperado de ferramenta provoca cancelamento adicional; essa verificação posterior não substitui a restrição anterior.
-
-## Reasoning effort
-
-| Effort | Uso recomendado |
-| --- | --- |
-| \`low\` | execução clara, roteamento, busca delimitada, transformação e integração sem conflito |
-| \`medium\` | padrão para agentic coding, planejamento delimitado, implementação e revisão cotidiana |
-| \`high\` | debugging complexo, planejamento profundo, síntese final e auditoria crítica delimitada |
-| \`xhigh\` | exceção para planejamento, replanejamento, segurança, code review ou auditoria em problemas excepcionalmente difíceis |
-
-Regras adicionais:
-
-- \`xhigh\` é aceito pelo framework automático, mas permanece inelegível para trabalho comum.
-- \`xhigh\` e \`high\` não devem ser defaults de implementação extensa.
-- \`xhigh\` pode ser selecionado automaticamente somente quando os critérios de elegibilidade forem satisfeitos; os evals devem calibrar os gatilhos sem liberar uso genérico.
-- \`high\` e \`xhigh\` devem receber contexto e saída delimitados para evitar turnos abertos e excessivamente longos.
-- \`max\` não pertence à primeira versão automática e \`ultra\` é explicitamente inválido no modo \`auto\`.
-
-## Velocidade por origem
-
-Modelo e effort podem variar entre Agent Runs, nunca entre Calls da mesma Run. A origem da Execution define quem controla a velocidade:
-
-| Origem | Modelo e effort | Velocidade | Execução Fast |
-| --- | --- | --- | --- |
-| Conversation | seleção manual do Codex | seleção manual do Codex | não é execução de produto |
-| Task-first | seleção manual do Codex | seleção manual do Codex | somente por seleção manual no Codex |
-| SPEC | política automática ZAIP | sempre \`standard\` | não suportada |
-| PRD | política automática ZAIP | sempre \`standard\` | não suportada |
-
-No modo \`auto\`, toda Run de PRD ou SPEC solicita velocidade \`standard\`, e nenhum override de Task, PreparedPlan ou Execution pode mudá-la durante sua vigência. Tasks descendentes não podem escapar dessa regra. O \`service_tier\` efetivo retornado pelo host/provider continua sendo registrado como observação, mas não altera \`default_velocity\` nem retroalimenta o seletor.
-
-Selecionar Fast manualmente no Codex afeta somente Conversation ou Task-first, conforme o estado do host. O ZAIP não muda o seletor, não grava Fast em configuração persistente e não propaga a seleção para uma futura Execution de PRD ou SPEC. Se um trabalho urgente exige a DAG ou os gates parentais de uma SPEC/PRD, ele continua em \`standard\`; não fragmente artificialmente o macro em Task-first apenas para obter mais velocidade.
-
-## Separação entre risco e complexidade
-
-O ZAIP usa duas classificações independentes:
-
-- risco: \`lite\`, \`standard\`, \`critical\`;
-- complexidade: \`simple\`, \`standard\`, \`complex\`.
-
-O risco governa verificação e proteção. A complexidade influencia modelo e effort.
-
-| Risco | Gates mínimos esperados |
+| Modelo | Papel dentro da política ZAIP |
 | --- | --- |
-| \`lite\` | verificação scoped e Acceptance Criteria aplicáveis |
-| \`standard\` | testes dos packages afetados, revisão e evidência |
-| \`critical\` | verificação completa, revisão independente, segurança quando aplicável, rollout e rollback |
-
-Uma Task \`critical\` e mecânica pode ser executada em Terra \`medium\`, desde que receba gates críticos. Uma Task de risco \`standard\`, mas altamente ambígua e transversal, pode exigir Sol \`medium\` ou \`high\` no planejamento.
-
-## Política por agente
-
-O agente define um baseline, nunca a decisão inteira. A política combina papel, fase e metadados da Task quando o Agent Run começa:
-
-O catálogo mantém IDs internos estáveis como \`agent-builder\`, enquanto o adapter Codex os registra como \`zaip-agent-builder\`. O nome exibido vem de \`codex_task_name\` e coincide com o único \`nickname_candidates\`: \`nome_funcao_por_extenso_zaip_agent\`, sem repetir o cargo técnico. O adapter configura \`max_depth = 2\` e \`max_concurrent_threads_per_session = 5\`: essa é capacidade estrutural da squad, não permissão para executar cinco Tasks. A execução autônoma começa com uma Task e só eleva até três ramos realmente independentes.
-
-| Agente | Configuração-base | Elevação típica |
-| --- | --- | --- |
-| \`agent-orchestrator\` | Terra \`low\` | Sol \`medium\` para DAG complexa; \`high\` para síntese final crítica |
-| \`agent-builder\` | Terra \`medium\` | Sol \`medium\` para arquitetura, segurança ou migração |
-| \`agent-reviewer\` | Terra \`medium\` no catálogo | Sol quando a política e os sinais da revisão justificarem elevação; \`high\` para revisão complexa delimitada |
-| \`agent-integrator\` | Terra \`medium\` | Sol \`medium\` somente quando outra regra explícita exigir raciocínio transversal |
-| \`agent-auditor\` e \`agent-security-auditor\` | Sol \`high\` | \`xhigh\` apenas quando elegível e medido |
-| \`agent-finalizer\` | Terra \`medium\` | sem elevação automática; avalia evidência já produzida |
-| fallback \`codex\` | Terra \`medium\` | resolver novamente pela Task e pelos gates |
-
-Se nenhum agente do catálogo for selecionado, o nome do cliente/host é usado como fallback de identidade. No Codex:
-
-\`\`\`yaml
-agent: codex
-client: codex
-provider: openai
-\`\`\`
-
-\`agent\`, \`client\` e provider de inferência são dimensões diferentes. O fallback de agente continua \`codex\`; a inferência dos modelos GPT-5.6 usa provider \`openai\`. Identidade do agente e configuração do modelo são decisões separadas.
-
-## PRD e SPEC
-
-### PRD
-
-Use \`medium\` para descoberta e primeiro rascunho. Use \`high\` quando o PRD tiver múltiplos stakeholders, trade-offs relevantes ou várias SPECs. Reserve \`xhigh\` para uma passagem final em PRDs críticos que governem múltiplas SPECs, decisões de alto custo de reversão, compliance, segurança ou rollout complexo.
-
-### SPEC
-
-A SPEC tem maior potencial de retorno para reasoning elevado porque seus erros se propagam para DAG, Tasks e implementação. Use \`high\` em SPECs transversais ou arquiteturais. Uma passagem final \`xhigh\` pode ser elegível quando houver:
-
-- frontend, backend e persistência ou infraestrutura;
-- mudança de contrato de API;
-- múltiplos módulos dependentes;
-- migração e compatibilidade temporária;
-- autenticação, autorização, segurança ou dados críticos;
-- rollout e rollback complexos;
-- muitas Tasks paralelas ou locks relevantes;
-- rework anterior causado por falha de arquitetura;
-- Acceptance Criteria difíceis de transformar em testes.
-
-### Fluxo econômico de planejamento
-
-\`\`\`text
-Descoberta e rascunho       -> Terra ou Sol medium
-Estruturação do PRD/SPEC    -> Sol high, quando complexo
-Crítica e consolidação final -> Sol xhigh, somente quando elegível
-Execução da DAG             -> Luna low ou Terra medium
-Auditoria final             -> Sol medium ou high
-\`\`\`
-
-O melhor uso de \`xhigh\` é como crítico final de um documento já estruturado, não como autor a partir de uma página em branco. O turno deve receber Requirements, Acceptance Criteria, decisões, restrições, contratos, riscos, testes, rollout e rollback. A saída deve ficar limitada a contradições, lacunas, riscos, correções e decisão de prontidão.
-
-## DAG e múltiplas Tasks
-
-O resolvedor executa antes de cada Task pronta e novamente quando uma etapa materialmente distinta abre outro Agent Run:
-
-\`\`\`text
-Task pronta
--> resolver agente
--> resolver modelo e effort
--> validar capacidades do modelo
--> iniciar Agent Run
--> registrar configuração solicitada
--> executar e verificar
--> registrar configuração efetiva
-\`\`\`
-
-Se Tasks paralelas exigirem configurações diferentes, cada uma deve usar Agent Run isolada. Em uma mesma thread sequencial, cada nova Run recebe explicitamente modelo e effort para impedir herança acidental da configuração anterior.
-
-Para PRDs, o runtime materializa Executions-filhas somente quando as dependências permanecem dentro da SPEC e os write scopes são globalmente disjuntos. Cada filha recebe Agent Runs, estado, orçamento e handoff próprios. O pai aguarda os terminais, integra os commits sem reexecutar Tasks e aplica validação cross-SPEC antes do finalizer; ramos inelegíveis permanecem em sua DAG global.
-
-## Rework e escalada
-
-Comece na configuração mais barata considerada segura:
-
-\`\`\`text
-Luna low -> Terra medium -> Sol medium -> Sol high -> Sol xhigh
-\`\`\`
-
-Eleve apenas um nível por vez, em novo turno, quando houver:
-
-- ambiguidade material não resolvida;
-- falha de teste após tentativa válida de correção;
-- conflito arquitetural ou entre módulos;
-- finding de segurança;
-- rejeição do reviewer;
-- invalidação do PreparedPlan por aumento de complexidade;
-- evidência insuficiente para Acceptance Criteria;
-- rework estrutural causado por dependência, contrato, sequência, migração ou escopo.
-
-Não eleve por erro de sintaxe, teste localizado, código gerado, refatoração repetitiva ou simples quantidade de arquivos.
-
-### Elegibilidade para xhigh
-
-Exija as quatro condições:
-
-1. alta complexidade ou ambiguidade arquitetural;
-2. alto custo esperado de rework;
-3. efeito transversal ou crítico;
-4. turno delimitado de planejamento, replanejamento ou auditoria.
-
-Além disso, exija pelo menos dois gatilhos observáveis:
-
-- frontend, backend e persistência ou infraestrutura;
-- três ou mais módulos com contratos compartilhados;
-- migração, segurança, autenticação ou dados críticos;
-- rollout parcial e rollback necessário;
-- dois ciclos de reparo falharam pela mesma causa estrutural;
-- finding arquitetural do reviewer;
-- PreparedPlan invalidado;
-- alternativas arquiteturais com trade-offs materiais.
-
-Os números são critérios operacionais iniciais do ZAIP, não limites publicados pela OpenAI. Eles devem ser recalibrados por evals.
-
-## Medição e break-even
-
-O KPI principal é \`tokens totais até entrega verificada\`:
-
-\`\`\`text
-custo total = planejamento
-            + implementação
-            + testes e diagnóstico
-            + revisão e auditoria
-            + ciclos de reparo
-\`\`\`
-
-O break-even de \`xhigh\` é:
-
-\`\`\`text
-custo adicional do planejamento xhigh / custo médio de um ciclo de rework
-\`\`\`
-
-Se \`xhigh\` adicionar \`E\` tokens ao planejamento e um ciclo médio de rework custar \`R\`, ele precisa evitar ao menos \`E / R\` ciclos por Task para empatar em tokens. Latência, custo monetário e criticidade continuam como guardrails separados.
-
-### Métricas obrigatórias
+| \`gpt-5.6-luna\` | Execução clara e delimitada, conforme catálogo e capacidade |
+| \`gpt-5.6-terra\` | Implementação, testes e integração cotidianos |
+| \`gpt-5.6-sol\` | Planejamento difícil, revisão especializada e primeiro replanejamento |
+| \`gpt-6-astra\` | Replanejamentos e exceção de execução permitidos pelo preset |
 
-- sucesso da Task e dos Acceptance Criteria;
-- tokens totais e tokens de reasoning;
-- latência total até conclusão;
-- custo total até entrega verificada;
-- aprovação na primeira revisão;
-- quantidade de repair cycles;
-- findings arquiteturais e de segurança;
-- falhas de integração;
-- invalidações do PreparedPlan;
-- completude das evidências;
-- bugs encontrados depois da entrega.
+Esses são papéis configurados pelo ZAIP, não alegações de benchmark dos
+modelos. Disponibilidade e esforços aceitos precisam ser confirmados no host.
+Mais reasoning não substitui teste, reviewer ou evidência.
 
-### Piloto recomendado
+O catálogo define baselines por agente. Uma seleção deliberadamente diferente
+abre nova Run com sua identidade real. Calls internas preservam a configuração
+solicitada da Run; fallback do provider aparece como observado, sem reescrever
+o cabeçalho. Sem fonte efetiva, mantenha \`null\`/\`unavailable\`.
 
-Compare \`Sol high\` e \`Sol xhigh\` somente no planejamento, mantendo execução e revisão iguais:
+## Configuração e ativação
 
-\`\`\`text
-Grupo A: planejamento Sol high  -> execução Terra medium -> revisão Sol medium
-Grupo B: planejamento Sol xhigh -> execução Terra medium -> revisão Sol medium
-\`\`\`
-
-Ative \`xhigh\` para uma classe de trabalho somente quando o grupo correspondente demonstrar ganho de qualidade ou confiabilidade que compense tokens, custo e latência adicionais.
-
-## Contrato de configuração automática
-
-A configuração automática usada pelo projeto é:
-
-\`\`\`yaml
-model_orchestration:
-  mode: auto
-  default_model: gpt-5.6-terra
-  default_effort: medium
-  default_velocity: standard
-  allowed_models:
-    - gpt-5.6-luna
-    - gpt-5.6-terra
-    - gpt-5.6-sol
-  allowed_efforts:
-    - low
-    - medium
-    - high
-    - xhigh
-  max_auto_effort: xhigh
-  automatic_sources:
-    - spec
-    - prd
-  notice: mismatch
-\`\`\`
-
-Projetos novos continuam em \`manual\` até o rollout provar qualidade e custo. A mudança para \`auto\` é opt-in por projeto e por origem; \`task\` é rejeitado pelo schema. Rollback consiste em voltar para \`manual\`, sem reescrever Runs anteriores.
-
-Um novo PreparedPlan de PRD/SPEC não declara apenas \`risk: standard\`. Cada blueprint fornece \`model_signals\`, e \`createPreparedPlanV2\` calcula e persiste \`model_profile.risk\`, \`risk_policy_version: task-risk-v1\` e \`risk_reasons\`. Uma declaração de risco conflitante falha; PreparedPlans históricos sem perfil continuam legíveis, mas não entram em execução automática sem perfil.
-
-\`\`\`yaml
-model_signals:
-  phase: implementation
-  complexity: complex
-  transversality: cross_system
-  ambiguity: high
-  rework: none
-  rework_cost: high
-  bounded: true
-  high_volume: false
-  xhigh_triggers:
-    - shared_contracts_3_plus
-    - rollout_and_rollback
-  risk_signals:
-    production_impact: false
-    external_action: false
-    irreversible_change: false
-    security_or_critical_data: true
-    data_migration: false
-    broad_audit: false
-    rollback: planned
-    verification_scope: full
-\`\`\`
-
-O classificador retorna \`critical\` para impacto explícito em produção, ação externa, irreversibilidade, segurança/dados críticos, migração, auditoria ampla, rollback complexo, ambiguidade \`high\` transversal ou rework estrutural de alto custo. Retorna \`lite\` somente para trabalho simples, local, delimitado, reversível e com verificação scoped; todo caso restante é \`standard\`, sempre com motivo enumerado.
-
-O PreparedPlan pode declarar um override da Execution e cada Task pode sobrescrever campos:
+Mescle na raiz de \`.agents/config/project.yaml\`:
 
 \`\`\`yaml
-policy:
-  runtime_defaults:
-    client: codex
-    provider: openai
-    model: gpt-5.6-terra
-    reasoning_effort: medium
-
-blueprints:
-  tasks:
-    - id: TASK-IMPLEMENTAR
-      runtime:
-        model: gpt-5.6-terra
-        reasoning_effort: medium
-
-    - id: TASK-AUDITAR
-      runtime:
-        model: gpt-5.6-sol
-        reasoning_effort: high
-\`\`\`
-
-Precedência executada:
-
-\`\`\`text
-policy.runtime_defaults explícito da Execution
--> runtime explícito da Task
--> política automática por perfil, fase e agente
--> defaults do projeto
-\`\`\`
-
-O runtime anuncia modelos, efforts e velocidades antes do dispatch. Modelo fora da allowlist, effort desconhecido, \`ultra\`, \`max\`, velocidade diferente de \`standard\` ou capacidade incompatível produzem erro tipado; não existe fallback silencioso.
-
-Quando a seleção foi registrada, o cabeçalho da Run ou Sub-Run preserva a configuração resolvida e \`model.selection.recorded\` registra a decisão antes do dispatch; o default do catálogo não pode substituir o modelo realmente invocado. Telemetria efetiva e Calls conhecidas permanecem dentro da mesma chamada de agente. Capturas terminais sem metadados ricos mantêm modelo e effort indisponíveis; não devem receber uma seleção reconstruída. Run raiz é a chamada do orquestrador e possui \`parent_run_id: null\`; Sub-Run possui pai:
-
-\`\`\`yaml
-agent_run:
-  run_id: RUN-EXEC-TASK-BUILD-1
-  run_kind: sub_run
-  run_purpose: execution
-  parent_run_id: RUN-EXEC-TASK-ORCHESTRATOR
-  client: codex
-  provider: openai
-  agent: agent-task-executor
-  agent_name: zaip-agent-task-executor
-  requested_model: gpt-5.6-terra
-  requested_reasoning_effort: medium
-  effective_model: gpt-5.6-terra
-  effective_reasoning_effort: medium
-  call_count: 3
-  tokens: 42000
-  cost_brl: 1.84
-  selection_source: execution-override
-  selection_reasons:
-    - execution-override
-    - terra-implementation-baseline
+autonomy:
+  version: 1
+  preset: balanced
+execution:
+  runtime: manual
 \`\`\`
 
-Requested e effective não devem ser confundidos, pois o runtime ou serviço pode aplicar fallback ou reroteamento. \`effective_*\` só pode ser preenchido por fonte observada; ausência dessa fonte não autoriza copiar \`requested_*\`.
-
-No dashboard, Runs e Sub-Runs são separados por \`parent_run_id\` e ordenados por \`started_at\` decrescente, independentemente do shard físico da projeção. A Run raiz usa a identidade visível \`zaip-agent-orchestrator\`; Sub-Runs usam o \`zaip-agent-*\` efetivamente selecionado. O Monitor de Custos agrupa e filtra pela identidade visível, mantém o modelo configurado de cada chamada em destaque e mostra o modelo efetivo separadamente. Quando o host não informou a configuração planejada, o modelo efetivo é rotulado como observado, nunca apresentado como se tivesse sido selecionado pelo catálogo.
-
-### Calls como telemetria interna
-
-O dashboard cria visões separadas para Runs e Sub-Runs, mas não cria entidade ou aba separada para Calls. Quando o host fornece eventos por \`invocation_id\`, o ledger os conserva dentro da respectiva Run/Sub-Run para calcular:
+Esse exemplo configura o preset **sem iniciar provider**. Novos templates
+também mantêm seleção \`model_orchestration.mode: manual\`. O coordenador
+gerenciado usa \`execution.runtime: managed\` para PRD/SPEC (padrão novo), ou
+\`autonomous\` também para Task gerenciada explícita, provider/configuração
+válidos, execução autorizada e worktree elegível. Salvar o preset no Dashboard
+não faz essa ativação automaticamente.
+
+O bloco \`autonomy\` aceita somente \`version\` e \`preset\`. As sequências
+4/1, 10/3 e ilimitada vêm da política compartilhada, não de um campo de
+tentativas inventado no YAML. As Tasks iniciadas congelam a política; alteração
+no projeto vale para novas Tasks. Estados legados não são convertidos
+silenciosamente.
+
+A allowlist e as capacidades do provider continuam sendo verificadas.
+Não remova uma restrição para fazer uma seleção impossível parecer válida.
+No caminho gerenciado, o worker não pode contornar o orçamento iniciando
+filhos nativos não contabilizados via \`multi_agent\`.
+
+## Fronteira de garantia
+
+O runtime gerenciado controla o processo **antes** da inferência. Essa é a
+fronteira da contagem determinística e da seleção automática. Uma chamada
+nativa \`spawn_agent\` externa, feita diretamente pelo Codex, não é interceptada
+pelo diário: instrução e captura posterior não equivalem a controle preventivo.
+
+O padrão novo \`managed\` já seleciona PRD/SPEC gerenciados, sem prometer
+controle externo numa sessão manual. \`task migrate-autonomy\` exige preview,
+contagem histórica revisada e confirmação; não reinicia quotas ou aprova legados.
+
+A preferência do principal avulso, o catálogo gerado do filho e a configuração
+efetivamente observada devem aparecer separados. Se o host não suporta o
+override necessário, relate a limitação real; não afirme que um prompt mudou
+o modelo e não fabrique telemetria.
+
+## Compatibilidade: model_orchestration sem autonomy
+
+Configurações antigas mantêm o contrato legado, não os presets acima:
+
+- \`manual\` recomenda sem alterar o seletor; \`off\` desativa essa recomendação.
+- \`auto\` usa \`automatic_sources: [spec, prd]\`; \`task\` não é aceito nessa
+  allowlist legada. Isso não proíbe a política de filhos avulsos de
+  \`autonomy-v1\`.
+- Sinais persistidos de complexidade, ambiguidade, transversalidade, rework,
+  risco e papel definem o perfil e motivos. Quantidade de arquivos ou
+  departamento não substitui esses sinais.
+- Luna/Terra/Sol usam esforços permitidos pelo projeto; \`xhigh\` é
+  excepcional para planejamento/auditoria difícil, não um padrão para tudo.
+- Astra legado é diagnóstico read-only condicionado e limitado a três
+  invocações por Task estável. Esse teto **não se aplica** ao Persistente.
+- Overrides e allowlist legados não se sobrepõem às restrições de
+  \`autonomy-v1\`, em especial à proibição de Astra automático no Essencial.
+
+Consulte [RULE-ASTRA-DIAGNOSTIC](../../rules/astra-diagnostic.md),
+[RULE-AUTONOMY-DECISION](../../rules/autonomy-decision.md) e
+[RULE-MODEL-ORCHESTRATION](../../rules/model-orchestration.md), apenas quando
+aplicáveis. Não carregue o diagnóstico difícil para uma pergunta comercial
+simples.
 
-1. quantidade de Calls conhecida e quantidade terminal;
-2. falhas, cancelamentos, retries e latência observáveis;
-3. modelo, effort e service tier efetivos;
-4. tokens e custo agregados na Run;
-5. divergência requested/effective sem dupla contagem.
+## Velocidade por origem
 
-Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider aplicar fallback, a diferença aparece como configuração efetiva observada e não muda o cabeçalho. Valores indisponíveis permanecem \`null\`; prompt e reasoning privado nunca são armazenados.
+A seleção automática solicita \`standard\`. Fast manual de uma Conversation ou
+Task avulsa independente pertence ao host; o ZAIP não o ativa nem propaga
+para o runtime automático de SPEC/PRD. Não fragmente uma DAG para fugir de sua
+política. O tier efetivamente retornado é observação separada, não prova de
+que o catálogo ou o preset o selecionou.
 
-## Garantias implementadas
+## Medir resultado, sem prometer economia
 
-1. \`project.yaml\` possui branch \`auto\` estrito e mantém \`manual\` como default de distribuição.
-2. \`automatic_sources\` restringe a política a \`spec\` e \`prd\`; o schema rejeita \`task\`.
-3. Novos PreparedPlans de PRD/SPEC calculam risco e motivos a partir de sinais persistidos; planos históricos permanecem legíveis.
-4. O coordenador injeta a política somente em Executions elegíveis e resolve novamente no início de cada Agent Run de Task/fase.
-5. A captura de conversa registra o modelo explicitamente observado ou \`unknown\`; modelo e effort efetivos não são inferidos a partir do baseline automático, do catálogo ou de uma Task avulsa.
-6. O resolvedor determinístico aplica allowlist, capacidades, overrides e motivos observáveis antes do dispatch.
-7. Testes cobrem a matriz de risco/modelo/effort, precedência, capacidades, rejeições e atribuição sem inferência.
-8. O ledger rejeita Calls com modelo, effort ou decisão de seleção solicitados diferentes dentro da mesma Agent Run.
-9. O Sub-Run registra no cabeçalho e no ledger a seleção realmente enviada ao runtime.
-10. CLI, Rules, adapters e templates distribuídos descrevem a mesma fronteira.
+Compare Tasks equivalentes com os mesmos ACs e qualidade mínima, somando
+planejamento, implementação, reparos, testes e revisão. Inclua cobertura,
+configurações observadas e falhas; não compare só o preço do primeiro turno.
 
-## Não objetivos da primeira automação
+Tokens, tempo e custo continuam úteis para diagnóstico. Nenhum deles vira
+teto de abandono por tempo em \`autonomy-v1\`. Custo equivalente de API não é
+cobrança comprovada da assinatura. \`null\` não é zero e teste com runtime
+simulado não comprova economia real.
 
-- aceitar \`ultra\` no modo automático;
-- usar \`max\` como default;
-- selecionar ou sobrescrever velocidade diferente de \`standard\`;
-- mudar modelo ou effort dentro de uma Agent Run;
-- criar uma tela ou lifecycle independente para Calls;
-- escolher \`high\` ou \`xhigh\` apenas por quantidade de arquivos;
-- substituir testes, reviewer ou auditor por reasoning mais alto;
-- inferir configuração ausente pelo comportamento do modelo;
-- otimizar somente o custo do primeiro turno e ignorar rework.
+## Fontes executáveis para manutenção
 
-## Referências oficiais
+No repositório-fonte:
 
-- [GPT-5.6: seleção de modelo e effort](https://developers.openai.com/api/docs/guides/latest-model#update-api-and-model-parameters)
-- [Reasoning effort](https://developers.openai.com/api/docs/guides/reasoning#reasoning-effort)
-- [Modelos do Codex](https://learn.chatgpt.com/docs/models#pick-a-reasoning-effort)
-- [Codex App Server](https://learn.chatgpt.com/docs/app-server)
-- [Subagentes: escolha automática de modelos e reasoning](https://learn.chatgpt.com/docs/agent-configuration/subagents#choosing-models-and-reasoning)
-- [Configuração e precedência do Codex](https://learn.chatgpt.com/docs/config-file/config-basic#configuration-precedence)
-- [Checklist de deployment e comparação por custo por sucesso](https://developers.openai.com/api/docs/guides/deployment-checklist#choose-a-gpt-56-model)
+- \`packages/core/src/autonomy-policy.ts\`: presets, modelos e divulgação.
+- \`packages/core/src/autonomy-recovery.ts\`: reservas, contagens e resultados.
+- \`packages/tasks/src/autonomous/recovery-ledger.ts\`: diário persistente.
+- \`packages/tasks/src/autonomous/coordinator-autonomy.ts\`: replanejamento.
+- \`packages/tasks/src/autonomous/coordinator-autonomy-selection.ts\`: seleção.
+- \`packages/adapters/src/agent-runtime/autonomy-envelope.ts\`: isolamento.
+- \`AutonomySettings.tsx\` no frontend do Dashboard: UI dos mesmos presets.
 
-As referências oficiais orientam usar o menor effort que atinja a qualidade necessária, começar em \`medium\` para equilíbrio e reservar \`high\` ou \`xhigh\` para ganho de qualidade medido. A política operacional deste guia deve continuar sendo validada pela telemetria e pelos evals do ZAIP.
-`,E=`# Auditoria do cálculo de custo equivalente via API
+Esses paths são referências de mantenedor, não dependências que o consumidor
+precise compilar. Validação local, TGZ exato, revisão, fechamento canônico e
+produção são provas distintas; veja [qualidade e release](26-qualidade-e-release.md).
+`,D=`# Auditoria do cálculo de custo equivalente via API
 
 Este documento usa o snapshot versionado em \`.agents/config/pricing/models.json\`; não declara que as tarifas ou a cotação de exemplo são atuais fora desse snapshot.
 
@@ -1366,7 +1604,7 @@ Para conferir a soma: \`USD estimado API = USD entrada + USD cache + USD saída
 - Cálculo: \`packages/costs/src/pricing-math.ts\` e \`packages/costs/src/index.ts\`
 - Projeção: \`.agents/dashboard/modules/cost-monitor/src/server/build-cost-monitor-projection.ts\`
 - Testes: \`pnpm --filter @zaip-ai/costs test\` e \`pnpm --filter @zaip-ai/dashboard-cost-monitor test\`
-`,D=`# Fontes oficiais de preços OpenAI
+`,O=`# Fontes oficiais de preços OpenAI
 
 Registro local de consulta em 15 de julho de 2026. Valores operacionais ficam no catálogo versionado \`.agents/config/pricing/models.json\`; esta página preserva as fontes usadas naquele registro, não confirma preços atuais sem nova consulta.
 
@@ -1385,7 +1623,7 @@ Registro local de consulta em 15 de julho de 2026. Valores operacionais ficam no
 4. Não crie tarifa para uma combinação que a tabela oficial não publique.
 5. Não transforme créditos Codex em USD sem uma regra oficial explícita.
 6. Preserve modelo, tier e effort efetivos como indisponíveis quando não forem retornados por fonte observada; defaults de configuração não os substituem.
-`,O=`# Qualidade e qualificação de release
+`,k=`# Qualidade e qualificação de release
 
 O candidato de release precisa passar gates locais, clean-room e distribuição pública sem confundir validação técnica com aprovação de produção.
 
@@ -1404,18 +1642,32 @@ O ratchet usa o maior valor entre o floor atual e o baseline versionado. Uma med
 
 ## Gates agregados e diagnósticos
 
-O gate de PR é o job único \`github-equivalent\` de
-\`.github/workflows/quality.yml\`, em \`ubuntu-latest\`: instala dependências,
-instala Chromium e executa \`validate:github:prepared\`, auditoria de produção,
-cobertura, release E2E e dashboard E2E. Esses subchecks são etapas desse gate
-agregado; não são uma receita adicional que, isoladamente, aprove uma release.
-
-O workflow \`.github/workflows/publish-cli.yml\` é separado: seu job \`verify\`
-usa matriz real Node 22 e 24 para \`pnpm verify\`; a auditoria e o artefato de
-release ocorrem somente na linha Node 24, ambas em Ubuntu. Publicação e smoke
-só seguem após a matriz aprovada. Esse \`verify\` roda dentro de \`public-cli\`,
-não é o script homônimo da raiz. Os comandos abaixo são do checkout mantenedor;
-não presuma que existam no \`package.json\` do projeto consumidor.
+A preparação local do mantenedor executa a bateria completa \`full-v2\`, incluindo
+\`pnpm qualify:full\`, cobertura com ratchet, contratos, clean-room, Dashboard E2E
+e identidade do consumidor. Somente o SHA limpo aprovado recebe recibo assinado,
+manifesto, SBOM e TGZ. Falha ou dados incompletos não produzem aprovação.
+
+No GitHub, checks de fonte (\`quality.yml\`), commits (\`commit-policy.yml\`) e matriz
+completa (\`qualify-cli.yml\`) ficam manuais. As mesmas validações principais são
+executadas localmente pelo Codex/scripts antes da release.
+
+Após qualificação local assinada e cadastro autorizado da chave pública/política,
+o mantenedor ativa \`ZAIP_LOCAL_RELEASE_ENABLED=true\`. O deploy publica os quatro
+artefatos assinados no GitHub; \`publish-cli.yml\` confere assinatura, versão e SHA,
+executa um único smoke automático (instalação + doctor do runtime) sem credenciais
+de escrita e só então publica o mesmo TGZ no npm. A integridade no registry continua
+obrigatória; outra instalação remota é opcional por \`extended_verification=true\`
+no despacho manual. Não há teste de acesso ao rascunho privado.
+
+Chave privada nunca sai da máquina. Sem flag, o caminho legado exige qualificação
+remota manual; não é fallback para assinatura ausente. Uma Release GitHub publicada
+não prova publicação npm: acompanhe o job até a confirmação do registry. Os comandos
+abaixo são do mantenedor; não presuma que existam no projeto consumidor.
+
+Dados históricos incompletos do Dashboard conservam \`null\`/indisponível e sua
+cobertura conhecida. Não se exige reconstruir fatos que nunca foram capturados.
+Isso não dispensa paridade entre records, API e UI para o mesmo conjunto conhecido,
+testes dos dados novos, nem fechamento canônico de Tasks sem sucesso inventado.
 
 A publicação compara \`dist.integrity\` do registro com o SHA-512 do tarball
 verificado. Uma versão já existente só é aceita quando o conteúdo é idêntico.
@@ -1450,7 +1702,9 @@ contra o manifest do próprio pacote, incluindo a Rule Astra, e verifica que
 os READMEs da raiz do consumidor sobrevivem à instalação e à reinstalação.
 O relatório registra a quantidade de arquivos documentais conferidos.
 
-Novas instalações continuam em \`manual\`; a documentação não deve confundir
+Novos templates mantêm seleção do principal em \`manual\`, runtime \`managed\`
+para PRD/SPEC e preset Equilibrado; avulsas preferem execução direta.
+A documentação não deve confundir
 perfil de instalação com modelo/effort nem apresentar estimativas de tokens
 como economia financeira medida. O escopo automático e os limites Astra
 devem coincidir com o [guia 23](23-orquestracao-de-modelos.md).
@@ -1561,7 +1815,39 @@ Testes passando comprovam validação técnica. Maturidade formal máxima exige
 - CI terminal correspondente ao commit publicado.
 
 Ausência de uma dessas provas permanece explícita; não é convertida em sucesso.
-`,k=`# Telemetria Git-native do Codex
+
+## Novidades da v3 e qualificação pendente
+
+As fontes em preparação incluem presets, diário durável por Task, replanejamento
+governado, relay de decisão Gui e configuração no Dashboard. Os manifests
+continuam em 2.6.0; este guia não promove versão nem certifica produção.
+
+Para qualificar essas novidades, preserve um candidato único e comprove:
+
+- Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente sem teto;
+- reservas antes do provider, replay/restart sem reset e resultado desconhecido
+  sem despacho duplicado;
+- plano inválido sem reparação gratuita, ausência de abandono por tempo e
+  preservação dos ACs;
+- API/UI/YAML dos três presets com reload, além de isolamento e modelos efetivos;
+- decisão real imutável antes do Stop, fechamento pendente sem repetir agentes
+  e casos negativos de Evidence/identidade/candidato;
+- instalação/reinstalação/rollback pelo TGZ exato, preservação do consumidor e
+  matriz de upgrade com origem publicada ou build de tag identificada;
+- performance real e comparação equivalente, sem transformar redução de payload
+  em economia financeira.
+
+A qualificação local dessa manutenção foi delimitada a Windows por decisão
+humana. Linux/macOS/Docker não executados não contam como aprovados; isso não
+altera silenciosamente matrizes de CI publicadas. Relatórios de candidatos
+anteriores, testes simulados de modelos e evidência local não certificam
+o candidato final nem seu uso em produção.
+
+O [guia 19](19-assurance-e-autonomia.md) registra duas fronteiras ainda
+importantes: controle preventivo só no despacho gerenciado e compatibilidade
+do trabalho avulso direto com a barreira de executor capturado. Uma revisão
+documental não resolve esses limites por declaração.
+`,A=`# Telemetria Git-native do Codex
 
 Este documento descreve o comportamento implementado da telemetria do Codex no ZAIP-AIOS. O
 objetivo é preservar métricas auditáveis por invocação de agente sem versionar prompts, respostas,
@@ -1733,7 +2019,25 @@ node scripts/validate-text-encoding.mjs
 
 Os comandos acima são gates de desenvolvimento. A confirmação operacional continua sendo a
 combinação de hashes válidos, cobertura explícita e leitura do período real no Dashboard.
-`,A='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento é a referência pública do lifecycle implementado pelo ZAIP-AIOS. Status persistido, Run, coluna do Kanban e reconciliação possuem responsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\n`implemente` sem alvo abre somente uma Conversation de planejamento; em `draft` finaliza o plano sem executar, em `ready` executa e em `active|blocked|failed` continua, retoma ou cria rework. `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada Execution usa uma Run raiz do `zaip-agent-orchestrator`. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nExemplo:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks concluem, o macro entra em Verificação.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação global ao abrir o dashboard, em cada turno ou em intervalo automático.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n',j=e(),M=`# ZAIP-AIOS (6 Squads + 23 Agents)
+
+## Caminho atual de consulta e limites de performance
+
+A descrição manifest-first acima inclui o caminho de compatibilidade.
+No runtime SQLite, a primeira dobra do Monitor usa agregados compactos;
+detalhes de Runs ficam em endpoints paginados explícitos. Queries preservam
+os mesmos filtros, moeda e população, sem reabrir streams canônicos de Run
+indiscriminadamente. O SQLite é derivado, não substitui Git-native.
+
+O spool e o diário de autonomia são diferentes. O primeiro guarda uso
+sanitizado; o segundo reserva tentativas/replanejamentos antes do provider.
+Não derive quota de tokens ou duração nem apague um deles para renovar consumo.
+
+Existência de índice/cache não comprova leitura O(1) por invocação. Escritores
+legados, substituição, truncamento, exclusão e concorrência exigem verificações
+de integridade e fallback completos. Redução mensurada, baseline equivalente,
+cobertura e carga concorrente precisam constar do benchmark; não declarar a
+matriz de performance aprovada apenas porque consultas focadas passaram.
+`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento é a referência pública do lifecycle implementado pelo ZAIP-AIOS. Status persistido, Run, coluna do Kanban e reconciliação possuem responsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\n`implemente` sem alvo abre somente uma Conversation de planejamento; em `draft` finaliza o plano sem executar, em `ready` executa e em `active|blocked|failed` continua, retoma ou cria rework. `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nExemplo:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks concluem, o macro entra em Verificação.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação global ao abrir o dashboard, em cada turno ou em intervalo automático.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A preferência avulsa direta não remove\no gate de executor capturado ainda exigido pelo contrato atual.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
 
 [English](README-ENG.md) | Português
 
@@ -1743,7 +2047,7 @@ combinação de hashes válidos, cobertura explícita e leitura do período real
 
 O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
 
-Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios definidos ou registrar um bloqueio, falha ou limite de orçamento. Dependências externas e decisões fora da autoridade recebida continuam exigindo intervenção humana; autonomia não significa execução indefinida nem garantia de acerto.
+Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios ou registrar bloqueio/falha conforme evidências e orçamento. O perfil Persistente permite execução indefinida por escolha explícita; os demais têm cotas por Task. Nenhum perfil garante acerto nem amplia autoridade para ações externas.
 
 Essa abordagem busca reduzir intervenções, contexto desnecessário e retrabalho. Os percentuais de 34% e 62% apresentados adiante se referem a custo médio por tarefa e por hora nas séries históricas ilustradas, respectivamente; não medem diretamente redução de tokens nem garantem economia em uma nova entrega.
 
@@ -1788,22 +2092,34 @@ No ZAIP-AIOS, uma Task não é considerada concluída apenas porque um agente te
 
 ### Como interpretar esta documentação
 
+Os dois READMEs são mantidos em português e inglês. Na Ajuda do Dashboard,
+o README inglês vem de \`README-ENG.md\`; guias sem tradução mostram a fonte
+portuguesa atual com aviso de idioma, sem resumos paralelos desatualizados.
+
 Este README e o [handbook](.agents/zaip-aios/INDEX.md) descrevem o código-fonte deste repositório. Configuração efetiva, suporte do host, pacote instalado e candidato qualificado são dimensões distintas. \`@latest\` aponta para a versão publicada, que pode não conter alterações locais. As imagens do Dashboard são ilustrações de estados anteriores, não prova visual do candidato atual.
 
 A atualização documental não aprova uma release. Consulte o [registro de limites de qualificação](docs/PRODUCTION-COMMERCIAL-READINESS.md#limites-conhecidos-da-qualificação) antes de promover o código; testes locais, paridade, CI e validação em produção devem ser comprovados separadamente.
 
+Na entrega v3, a bateria completa fica na preparação local assinada (\`full-v2\`). O GitHub verifica o pacote exato, sua instalação e a publicação, sem repetir a bateria de fonte a cada push. A ativação exige qualificação local completa e confiança cadastrada. Há um único smoke automático de instalação antes do npm; checks de fonte e matriz remota ficam manuais, sem teste sobre rascunho privado. Veja o [guia de qualidade e release](.agents/zaip-aios/guides/26-qualidade-e-release.md). Lacunas históricas de telemetria permanecem explícitas, sem inventar números ou dispensar testes de dados novos.
+
 ## Instalação em um comando
 
 Com Node.js 22.16.0 ou superior e npm, execute a instalação na raiz do projeto que receberá o ZAIP-AIOS. Em uma instalação nova, o \`init\` usa o perfil completo (\`full\`): instala as dependências ausentes da stack e prepara o Terraform. Todos os perfis verificam os runtimes distribuídos e preparam e validam o SQLite local, sem driver separado. Versões de pacotes existentes no projeto são preservadas, com aviso das versões atual e configurada no ZAIP-AIOS:
 
 \`\`\`bash
-npx @zaip-ai/cli@latest init
+npx --yes @zaip-ai/cli@latest init --project-only
+node .agents/runtime/bin/zaip.mjs doctor --json
 \`\`\`
 
-Também é possível aceitar automaticamente o download inicial do CLI pelo \`npx\`:
+Esses são os dois passos do primeiro resultado verificável: \`init\` instala o
+framework no projeto selecionado sem alterar a configuração global do Codex, e
+\`doctor --json\` confirma o layout, checksums e adapters instalados. O resultado
+só está pronto quando o JSON retornar \`"valid": true\`.
+
+Antes de escrever no projeto, revise o plano:
 
 \`\`\`bash
-npx --yes @zaip-ai/cli@latest init
+npx --yes @zaip-ai/cli@latest init --project-only --dry-run
 \`\`\`
 
 Os dois comandos usam o perfil salvo no projeto ou \`full\` quando ainda não existe uma escolha. A opção \`--yes\` antes do nome do pacote apenas aceita o download inicial do CLI pelo \`npx\`; ela não força a substituição de dependências, arquivos ou versões já existentes.
@@ -1973,6 +2289,42 @@ A configuração da plataforma apresenta o estado de ativação do ZAIP-AIOS e u
 
 <img src=".agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="Dashboard ZAIP-AIOS, configuração da plataforma" width="100%">
 
+### Perfis de autonomia da v3
+
+As fontes em preparação para a v3 acrescentam um preset por Task, separado de
+instalação e assurance:
+
+| Perfil | Execuções de produto por Task | Replanejamentos | Modelos dos replanejamentos |
+| --- | --- | --- | --- |
+| Essencial (\`essential\`) | 4: 1 inicial + 3 reparações | 1 | Sol/high; nunca Astra automático |
+| Equilibrado (\`balanced\`, padrão novo) | 10: 1 inicial + 9 reparações | 3 | Sol/high → Astra/high → Astra/high |
+| Persistente (\`persistent\`, opt-in) | Sem teto | Sem teto | Sol/high primeiro; Astra/high nos seguintes |
+
+Mescle no arquivo \`.agents/config/project.yaml\` ou selecione **Perfil de
+autonomia** em **Configurações do projeto** no Dashboard e salve:
+
+\`\`\`yaml
+autonomy:
+  version: 1
+  preset: balanced
+\`\`\`
+
+O diário durável reserva antes do despacho gerenciado; reiniciar ou retomar
+não zera a quota. A alteração vale para novas Tasks. Não há abandono por tempo
+nem redução automática de critérios de aceite. Persistente pode consumir
+créditos indefinidamente até cancelamento humano; não amplia permissões.
+
+Uma SPEC de dez Tasks Equilibradas admite até 100 execuções (10 iniciais +
+90 reparações) e 30 replanejamentos; testes e Calls internas não são tentativas.
+A falta de verificação/conclusão segura termina \`blocked\`; impedimento técnico
+comprovado termina \`failed\`. Ramos independentes continuam elegíveis.
+
+**Limite atual:** os contadores são impostos no runtime gerenciado, não em
+\`spawn_agent\` externo feito diretamente pelo Codex. Novos projetos usam
+\`execution.runtime: managed\`: PRD/SPEC gerenciados e avulsas diretas. Salvar
+o preset não inicia provider. Legados exigem migração explícita, sem zerar
+consumo. Veja [autonomia e suas garantias](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+
 ### Stack de desenvolvimento
 
 A stack de desenvolvimento descreve cada responsabilidade separadamente, com tecnologia, versão exata e referência do pacote, imagem ou serviço. No projeto, esse contrato inclui TypeScript, Node.js, Hono, Kysely, PostgreSQL via Supabase, Supabase Auth + Storage, Redis e BullMQ, permitindo que as escolhas de desenvolvimento permaneçam registradas junto da configuração do projeto.
@@ -2012,7 +2364,7 @@ Por padrão, cada PRD utiliza apenas uma SPEC, buscando economia.
 
 Uma nova SPEC só deve ser criada quando existir uma capacidade que possa ser implementada e validada de forma independente e paralela. Quando existe dependência entre partes do trabalho, elas permanecem na mesma SPEC e são organizadas pela DAG de Tasks.
 
-No runtime atual, um PRD materializa uma Execution-filho determinística para cada SPEC elegível: suas dependências permanecem dentro da SPEC e seus write scopes não conflitam com nenhum outro ramo. Cada filha executa com coordinator, estado, quota de orçamento e handoff próprios, sob uma fila limitada pelo paralelismo efetivo e por um ledger parental único de invocações; a Execution do PRD aguarda os estados terminais, integra os candidatos no handoff parental e só então aplica validação cross-SPEC e finalização. SPECs com dependência externa ou conflito de escopo permanecem na DAG global coordenadora.
+No runtime atual, um PRD materializa uma Execution-filho determinística para cada SPEC elegível: suas dependências permanecem dentro da SPEC e seus write scopes não conflitam com nenhum outro ramo. Cada filha executa com coordinator, estado e handoff próprios; em \`autonomy-v1\`, a quota de recuperação continua por Task estável, sob uma fila limitada pelo paralelismo efetivo e por um ledger parental único de invocações; a Execution do PRD aguarda os estados terminais, integra os candidatos no handoff parental e só então aplica validação cross-SPEC e finalização. SPECs com dependência externa ou conflito de escopo permanecem na DAG global coordenadora.
 
 Antes de o PRD chegar ao estado \`ready\`, as Tasks são apenas definições de trabalho, ainda sem execução.
 
@@ -2049,6 +2401,17 @@ Toda criação de PRD ou SPEC é vinculada à Run responsável por meio do campo
 
 Tempo, tokens e custo são agregados sempre que essas informações estiverem disponíveis ou forem reconciliadas. Quando não houver dados suficientes, os valores permanecem como \`unknown\` ou \`null\`.
 
+Na Visão geral, uma cobertura incompleta não esconde a soma disponível: o Dashboard
+mantém o cartão compacto **Custo Estimado**, sem ícone. A descrição acessível e o
+tooltip informam a cobertura. O subtítulo divide o subtotal conhecido pelo número
+de tarefas e pelas horas registradas no mesmo recorte: são taxas estimadas de
+alocação, não médias de custos completos por tarefa. Com cobertura parcial, não
+estima os valores ausentes. Cada taxa fica \`—\` apenas se sua base estiver indisponível
+ou for zero; uma taxa válida não é escondida porque a outra está indisponível.
+O subtotal não é o custo integral nem a fatura da conta. Zero observado continua sendo zero;
+ausência de medição continua indisponível. Rascunhos de Task ficam na lista de
+trabalho, fora do Kanban executável e dos indicadores operacionais sem rascunhos.
+
 
 ## Qualidade e evidências
 
@@ -2197,24 +2560,33 @@ Essa progressão permite começar de forma simples e acrescentar planejamento ap
 
 **Políticas técnicas de execução e assurance**
 
-Conversation e Task-first preservam a seleção manual do host; o default do projeto não é aplicado automaticamente a uma Task avulsa. A política automática aceita origens SPEC/PRD configuradas em \`automatic_sources\`, com velocidade \`standard\`. Modelo e effort ficam fixos em cada Run/Sub-Run; capacidade ou velocidade indisponível no host não pode ser presumida pelo ZAIP. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
+Conversation e o principal de Task avulsa preservam a seleção manual do host, priorizando trabalho direto. Quando delegar for necessário, informe que os filhos podem usar modelos/esforços diferentes pela política ZAIP; não há obrigação de herdar o principal. Modelo e effort ficam fixos por Run, com observação efetiva separada da seleção planejada. A seleção automática solicita \`standard\`; capacidade não observada do host não pode ser presumida. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
 
 ### Política Astra
 
-Luna, Terra e Sol permanecem as rotas de uso simples e de execução. Astra não executa produto, não faz revisão geral nem finaliza uma Task: é uma rota read-only de diagnóstico ou replanejamento, com effort \`high\` como teto. Ela só pode ser usada após sinais estruturados — tentativa executora com falha de raciocínio/hipótese e ambiguidade ou complexidade difícil, ou impacto crítico material acompanhado de diagnóstico difícil. Palavras como “crítico” ou “complexo”, departamento, tamanho ou risco isolado não a habilitam.
+No Essencial, Astra nunca é selecionado automaticamente, inclusive em filhos ou fallback. A única exceção é o principal avulso com Astra escolhido manualmente pelo usuário. No Equilibrado, os três replanejamentos usam Sol/high, Astra/high e Astra/high; no terceiro bloco Astra/high também pode executar a reparação, sem ampliar a quota. Persistente mantém essa progressão sem teto total.
+
+O replanejador é isolado e não edita produto; executor, revisor e Gui são papéis distintos. Astra automático usa somente \`high\`, não substitui revisão/finalização e depende do despacho gerenciado. A regra antiga de até três diagnósticos Astra somente leitura permanece apenas no contrato legado sem \`autonomy\`; não limita Persistente. Contexto e assurance seguem o domínio: conteúdo exige fontes/briefing, engenharia exige comportamento verificável. Economia real precisa ser medida, não inferida do preset.
 
-Há no máximo três ciclos Astra cumulativos por Task. Cada diagnóstico produz provas, findings, causa ou hipótese, rota recomendada, escopo, plano curto de teste/correção e handback para executor Luna, Terra ou Sol. Prova repetida ou falta de progresso bloqueia novo ciclo. Hosts manuais podem não permitir que o framework imponha a seleção; Conversations e Task-first preservam essa escolha. Contexto comercial é condicional ao pedido e não recebe requisitos técnicos por padrão. Métricas históricas de custo não prometem economia real em uma nova Task.
+O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction delegada exige executor elegível (ou raiz Task direta autorizada) e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
 
-O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction com descendentes exigem executor elegível e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
+Cada tentativa de Task tem exatamente um orquestrador responsável. Gui é seu
+último filho direto, irmão dos executores, não finalizador de cada trabalhador.
+O host persiste a decisão real antes do Stop canônico; pode retransmitir Gui
+já terminal enquanto o responsável estiver aberto, sem obrigá-lo a esperar
+recibos. Ausência de decisão não é aprovação. A preferência por execução
+avulsa direta usa uma raiz observada com \`--direct-authorization REFERÊNCIA\`
+explícita; não cria executor fictício nem dispensa Evidence e Gui. Veja
+[fechamento e recuperação](.agents/zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
 
-A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. \`standard\` exige duas ou três validações conforme \`verification_scope\` e pelo menos uma Evidence consolidada; \`critical\` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. O runtime manual continua padrão; a autonomia por Codex ou Claude é opt-in, isolada em worktrees e limitada por write scopes, commits, budgets e gates tipados. Consulte [Assurance adaptativa e autonomia opt-in](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. \`standard\` exige duas ou três validações conforme \`verification_scope\` e pelo menos uma Evidence consolidada; \`critical\` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. Novos projetos usam runtime gerenciado para PRD/SPEC e direto para avulsas; a execução por Codex ou Claude é autorizada por pedido, isolada em worktrees e limitada por write scopes, commits, budgets e gates tipados. Consulte [Assurance adaptativa e autonomia opt-in](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
 
 
 ## Princípios de engenharia autônoma
 
 O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm o código sustentável, distribuem apenas o contexto necessário e exigem comprovação proporcional ao risco.
 
-O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout optou por \`autonomous\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
+O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout usa \`managed\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
 
 - **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
 - **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
@@ -2235,7 +2607,7 @@ O **Graph Engineering** transforma uma entrega complexa em uma sequência coorde
 
 Essa autonomia permanece governada: Dave coordena, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas adicionais entram quando existem sinais objetivos e Gui encerra o fluxo por último. O resultado é uma equipe ajustada à demanda, sem multiplicar agentes e custo sem necessidade.
 
-O **Loop Engineering** orienta o que acontece quando a primeira tentativa não satisfaz os critérios de qualidade. A falha ou o bloqueio é classificado, o próximo ciclo recebe uma configuração proporcional à dificuldade observada e cada tentativa permanece auditável. Em execuções originadas de PRD ou SPEC, o sistema pode evoluir de **Luna → Terra → Sol** e de **low → medium → high → xhigh**; Conversations e Tasks avulsas preservam a seleção manual do host/Codex. O modelo nunca muda silenciosamente dentro da mesma Run.
+O **Loop Engineering** usa o perfil congelado da Task para reservar execução e replanejamento antes do provider, registrar o resultado e escolher uma rota corrigida. No Equilibrado são 1 + 9 execuções e três planos Sol/high → Astra/high → Astra/high; Essencial não escala para Astra, Persistente não tem teto. O modelo não muda silenciosamente dentro da mesma Run. A preferência manual do principal avulso não obriga seus filhos a usar a mesma configuração.
 
 ### Fluxo resumido
 
@@ -2424,7 +2796,7 @@ Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\`
 
 Use a versão de pnpm fixada em \`packageManager\` (\`corepack pnpm\` quando disponível). Para uma alteração delimitada, selecione os checks pertinentes ao risco e ao diff; a lista acima não exige repetir todos os testes a cada edição documental. Qualificação de release usa os gates completos do [guia 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) no candidato exato. Não confunda \`validate:github:prepared\`, execução local, push e CI terminal verde.
 
-O pacote público \`@zaip-ai/cli\` usa a versão de produto \`2.2\`; nos metadados npm e nos artefatos SemVer ela é registrada como \`2.2.0\`. Consulte o npm para identificar o \`latest\` publicado. A versão em um checkout não comprova publicação: a qualificação deve registrar a revisão exata, o resultado terminal do CI, a integridade do TGZ e uma instalação nova do registro. Publicação manual com token autorizado não equivale a atestado OIDC. Resultados e ressalvas ficam nas evidências da Change de release, preservando as tentativas anteriores.
+Os manifests deste checkout registram o candidato \`3.0.0\` (produto \`3.0\`). A identificação do candidato não significa que o \`latest\` já foi publicado nem certifica produção. A release exige revisão exata, CI terminal, integridade do TGZ e instalação real do artefato. Tentativas e limitações ficam nas evidências da Change; resultados locais e publicação são estados distintos.
 
 A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.
 
@@ -2466,12 +2838,29 @@ Todo deploy GitHub consulta \`.agents/config/project.yaml\`. Para escolher a bra
 
 \`\`\`yaml
 deploy:
-  branch: main
+  # Publicação automatizada: ambiente de validação.
+  branch: beta
+  # Produção: somente promoção humana.
+  production_branch: main
 \`\`\`
 
-Troque \`main\` por outra branch, como \`production\`, quando necessário. Se o arquivo ou a chave
-não existir, o destino será \`main\`. A branch atual e o upstream não substituem essa configuração.
-O preflight valida o destino e o agente relê o arquivo antes do push, usando um refspec explícito.
+\`beta\` é o padrão editável: use outro nome de validação, como \`staging\` ou \`homolog\`, se o
+projeto precisar. O banco usa somente \`beta\` e a promoção para produção requer ação humana no
+GitHub. Frontend e backend seguem sua branch configurada, inclusive \`main\` quando essa escolha
+estiver salva na configuração.
+
+\`deploy.frontend.branch\` e \`deploy.backend.branch\` são autorização persistida e podem ser \`main\`.
+Migrations usam somente \`deploy.database.branch: beta\`, sem fallback para produção. A instalação
+não cria ambiente beta nem custo: integração GitHub/Supabase beta verificada e confirmação
+informada de custo são pré-requisitos; a promoção \`beta -> main\` continua humana.
+
+Se a pessoa recusar explicitamente a beta hospedada, use o [modo manual](.agents/skills/zaip-skill-database-migrations/references/manual-mode.md): ele exporta SQL em \`db-migrations/\` para execução humana no SQL Editor. O agente, pipeline e startup não aplicam esse arquivo. Após sucesso humano registrado, retome as dependências; o relato humano não substitui comprovação independente.
+
+Consultas Supabase usam contextos separados \`READ-ONLY-BETA\` e \`READ-ONLY-PROD\`, cada qual com
+\`project_ref\` próprio, permissões mínimas de leitura e credencial distinta da credencial do
+pipeline. Referência ausente, destinos iguais ou capacidade read-only não demonstrada significam
+"não configurado", sem fallback entre ambientes. Os snippets MCP documentam configuração e não
+criam conexão autenticada. Consulte o [contrato de ambientes e acessos](.agents/skills/zaip-skill-backend/references/deployment-environments.md), que usa o formato do [MCP oficial do Supabase](https://supabase.com/docs/guides/getting-started/mcp).
 
 ### Defesa em profundidade
 
@@ -2525,9 +2914,9 @@ node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs
 \`\`\`
 
 O [guia de Obsidian para rastreabilidade ZAIP](guide/CRIAR-PASTA-OBSIDIAN.md) documenta a instalação do aplicativo, a abertura da pasta como vault, a geração de uma única Task e a atualização da projeção após um \`git pull\`.
-`,N=t(),P=Object.assign({"../../../../zaip-aios/guides/01-primeiros-passos.md":r,"../../../../zaip-aios/guides/02-requirements.md":i,"../../../../zaip-aios/guides/03-tasks.md":a,"../../../../zaip-aios/guides/04-specs.md":o,"../../../../zaip-aios/guides/05-prds.md":s,"../../../../zaip-aios/guides/06-execucao.md":c,"../../../../zaip-aios/guides/07-revisao-e-validacao.md":l,"../../../../zaip-aios/guides/08-contexto-e-tokens.md":u,"../../../../zaip-aios/guides/09-agentes-e-squads.md":d,"../../../../zaip-aios/guides/10-seguranca.md":f,"../../../../zaip-aios/guides/11-observabilidade-e-custos.md":p,"../../../../zaip-aios/guides/12-instalacao-e-upgrade.md":m,"../../../../zaip-aios/guides/13-boas-praticas.md":h,"../../../../zaip-aios/guides/14-troubleshooting.md":g,"../../../../zaip-aios/guides/15-tools-e-codex.md":_,"../../../../zaip-aios/guides/16-lifecycle-e-reconciliacao.md":v,"../../../../zaip-aios/guides/17-como-o-custo-e-calculado.md":y,"../../../../zaip-aios/guides/18-catalogo-de-agentes.md":b,"../../../../zaip-aios/guides/19-assurance-e-autonomia.md":x,"../../../../zaip-aios/guides/20-instalacao-detalhada.md":S,"../../../../zaip-aios/guides/21-telemetria-monitor-custos.md":C,"../../../../zaip-aios/guides/22-fluxos-e-roteamento.md":w,"../../../../zaip-aios/guides/23-orquestracao-de-modelos.md":T,"../../../../zaip-aios/guides/24-calculo-de-custos-openai.md":E,"../../../../zaip-aios/guides/25-fontes-de-precos-openai.md":D,"../../../../zaip-aios/guides/26-qualidade-e-release.md":O,"../../../../zaip-aios/guides/27-telemetria-git-native.md":k,"../../../../zaip-aios/guides/28-lifecycle-completo.md":A});function F({locale:e,onClose:t}){let r=(0,j.useMemo)(()=>n(e,M,P),[e]),i=r.filter(e=>e.id!==`readme`),[a,o]=(0,j.useState)(`readme`),[s,c]=(0,j.useState)(`rendered`),l=r.find(e=>e.id===a)??r[0];return(0,N.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,N.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,N.jsxs)(`header`,{children:[(0,N.jsxs)(`div`,{children:[(0,N.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,N.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,N.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,N.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,N.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,N.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,N.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,N.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,N.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,N.jsxs)(`article`,{children:[(0,N.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,N.jsx)(`h3`,{children:l?.title}),(0,N.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,N.jsx)(`button`,{"aria-pressed":s===`rendered`,className:s===`rendered`?`is-active`:void 0,onClick:()=>c(`rendered`),type:`button`,children:e===`pt-BR`?`Renderizado`:`Rendered`}),(0,N.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,N.jsx)(`div`,{className:`dashboard-help-sections`,children:U(l?.content??``,e).map(e=>(0,N.jsxs)(`section`,{children:[(0,N.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,N.jsx)(I,{content:e.content}):(0,N.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function I({content:e}){return H(L(e),V).map(({key:e,value:t})=>t.kind===`table`?(0,N.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,N.jsxs)(`table`,{children:[(0,N.jsx)(`thead`,{children:(0,N.jsx)(`tr`,{children:H(t.headers,e=>e).map(({key:e,value:t})=>(0,N.jsx)(`th`,{children:B(t)},e))})}),(0,N.jsx)(`tbody`,{children:H(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,N.jsx)(`tr`,{children:H(t,e=>e).map(({key:e,value:t})=>(0,N.jsx)(`td`,{children:B(t)},e))},e))})]})},e):(0,N.jsx)(`pre`,{children:t.content},e))}function L(e){let t=e.split(`
+`,P=n(),F=Object.assign({"../../../../zaip-aios/guides/01-primeiros-passos.md":i,"../../../../zaip-aios/guides/02-requirements.md":a,"../../../../zaip-aios/guides/03-tasks.md":o,"../../../../zaip-aios/guides/04-specs.md":s,"../../../../zaip-aios/guides/05-prds.md":c,"../../../../zaip-aios/guides/06-execucao.md":l,"../../../../zaip-aios/guides/07-revisao-e-validacao.md":u,"../../../../zaip-aios/guides/08-contexto-e-tokens.md":d,"../../../../zaip-aios/guides/09-agentes-e-squads.md":f,"../../../../zaip-aios/guides/10-seguranca.md":p,"../../../../zaip-aios/guides/11-observabilidade-e-custos.md":m,"../../../../zaip-aios/guides/12-instalacao-e-upgrade.md":h,"../../../../zaip-aios/guides/13-boas-praticas.md":g,"../../../../zaip-aios/guides/14-troubleshooting.md":_,"../../../../zaip-aios/guides/15-tools-e-codex.md":v,"../../../../zaip-aios/guides/16-lifecycle-e-reconciliacao.md":y,"../../../../zaip-aios/guides/17-como-o-custo-e-calculado.md":b,"../../../../zaip-aios/guides/18-catalogo-de-agentes.md":x,"../../../../zaip-aios/guides/19-assurance-e-autonomia.md":S,"../../../../zaip-aios/guides/20-instalacao-detalhada.md":C,"../../../../zaip-aios/guides/21-telemetria-monitor-custos.md":w,"../../../../zaip-aios/guides/22-fluxos-e-roteamento.md":T,"../../../../zaip-aios/guides/23-orquestracao-de-modelos.md":E,"../../../../zaip-aios/guides/24-calculo-de-custos-openai.md":D,"../../../../zaip-aios/guides/25-fontes-de-precos-openai.md":O,"../../../../zaip-aios/guides/26-qualidade-e-release.md":k,"../../../../zaip-aios/guides/27-telemetria-git-native.md":A,"../../../../zaip-aios/guides/28-lifecycle-completo.md":j});function I({locale:e,onClose:t}){let n=(0,M.useMemo)(()=>r(e,N,F),[e]),i=n.filter(e=>e.id!==`readme`),[a,o]=(0,M.useState)(`readme`),[s,c]=(0,M.useState)(`rendered`),l=n.find(e=>e.id===a)??n[0];return(0,P.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,P.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,P.jsxs)(`header`,{children:[(0,P.jsxs)(`div`,{children:[(0,P.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,P.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,P.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,P.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,P.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,P.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,P.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,P.jsxs)(`article`,{children:[(0,P.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,P.jsx)(`h3`,{children:l?.title}),(0,P.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,P.jsx)(`button`,{"aria-pressed":s===`rendered`,className:s===`rendered`?`is-active`:void 0,onClick:()=>c(`rendered`),type:`button`,children:e===`pt-BR`?`Renderizado`:`Rendered`}),(0,P.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,P.jsx)(`div`,{className:`dashboard-help-sections`,children:W(l?.content??``,e).map(e=>(0,P.jsxs)(`section`,{children:[(0,P.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,P.jsx)(L,{content:e.content}):(0,P.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function L({content:e}){return U(R(e),H).map(({key:e,value:t})=>t.kind===`table`?(0,P.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,P.jsxs)(`table`,{children:[(0,P.jsx)(`thead`,{children:(0,P.jsx)(`tr`,{children:U(t.headers,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`th`,{children:V(t)},e))})}),(0,P.jsx)(`tbody`,{children:U(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,P.jsx)(`tr`,{children:U(t,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`td`,{children:V(t)},e))},e))})]})},e):(0,P.jsx)(`pre`,{children:t.content},e))}function R(e){let t=e.split(`
 `),n=[],r=[],i=()=>{let e=r.join(`
-`).trim();e&&n.push({kind:`text`,content:e}),r=[]};for(let e=0;e<t.length;e+=1){let a=t[e],o=t[e+1];if(a?.includes(`|`)&&o&&R(o)){i();let r=z(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(z(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function R(e){return z(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function z(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function B(e){return H(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,N.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,N.jsx)(j.Fragment,{children:t},e))}function V(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function H(e,t){let n=new Map;return e.map(e=>{let r=t(e),i=(n.get(r)??0)+1;return n.set(r,i),{key:`${r}#${i}`,value:e}})}function U(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`
+`).trim();e&&n.push({kind:`text`,content:e}),r=[]};for(let e=0;e<t.length;e+=1){let a=t[e],o=t[e+1];if(a?.includes(`|`)&&o&&z(o)){i();let r=B(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(B(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function z(e){return B(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function B(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function V(e){return U(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,P.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,P.jsx)(M.Fragment,{children:t},e))}function H(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function U(e,t){let n=new Map;return e.map(e=>{let r=t(e),i=(n.get(r)??0)+1;return n.set(r,i),{key:`${r}#${i}`,value:e}})}function W(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`
 `),i=r[0]?.match(/^#{1,2}\s+(.+)$/)?.[1];return{title:i??(n===0?t===`pt-BR`?`Introdução`:`Introduction`:t===`pt-BR`?`Seção ${n+1}`:`Section ${n+1}`),content:i?r.slice(1).join(`
 `).trim():r.join(`
-`).trim()}})}export{F as DashboardHelpDialog};
+`).trim()}})}export{I as DashboardHelpDialog};