@zaip-ai/cli 2.0.0 → 2.6.0

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

@@ -1,4 +1,4 @@
-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{C as t,x as n}from"./cost-monitor-B6aZfo5f.js";import{t as r}from"./dashboard-localization-CLJ0lT9v.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.
@@ -10,7 +10,7 @@ import{S as e,b as t}from"./cost-monitor-DbaLbU2q.js";import{t as n}from"./dashb
 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
+`,a=`# Requirements
 
 Use Requirement para uma obrigacao duravel e testavel.
 
@@ -27,7 +27,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.
 
@@ -45,7 +45,7 @@ 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
+`,s=`# SPECs
 
 Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
 
@@ -65,7 +65,7 @@ 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
+`,c=`# PRDs
 
 Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
 
@@ -103,7 +103,7 @@ 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
+`,l=`# 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.
@@ -135,7 +135,7 @@ procedimento nem aprova o AC sozinho.
 - 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
+`,u=`# Revisao e validacao
 
 1. Revise Requirements e criterios de aceite.
 2. Examine diff, limites arquiteturais e caminhos de erro.
@@ -150,17 +150,33 @@ 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
+`,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.
-3. Prefira indices, resumos e busca direcionada a arquivos completos.
+3. Prefira índices, resumos e busca direcionada a arquivos completos.
 4. Abra records apenas por lifecycle ID conhecido.
-5. Resuma fatos estaveis; preserve texto literal apenas quando normativo.
-6. Remova do contexto resultados superados e detalhes nao acionaveis.
+5. Resuma fatos estáveis; preserve texto literal apenas quando normativo.
+6. Remova do contexto resultados superados e detalhes não acionáveis.
 
 Para tools, leia \`catalog.yaml\`, escolha um ID e abra somente seu manifesto.
-`,d=`# Agentes e squads
+
+## Consulta simples e diagnóstico difícil
+
+Uma pergunta simples de Marketing, Sales, Growth ou Ops recebe o contexto do domínio
+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.
+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).
+`,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
@@ -205,7 +221,7 @@ 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
+`,p=`# Segurança dos perfis Codex ZAIP-AIOS
 
 ## Visão geral
 
@@ -444,21 +460,52 @@ 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=`# Instalacao e upgrade
+`,m="# 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",h=`# Instalação e upgrade
 
-1. Verifique versao atual e estado limpo ou conscientemente preservado.
-2. Execute doctor/integrity antes da mudanca.
-3. Faça dry-run da instalacao, migracao ou upgrade.
-4. Revise arquivos gerenciados, publicos e preservados.
+1. Verifique versão atual e estado limpo ou conscientemente preservado.
+2. Execute doctor/integrity antes da mudança.
+3. Faça dry-run da instalação, migração ou upgrade.
+4. Revise arquivos gerenciados, públicos e preservados.
 5. Aplique, valide adapters e rode gates.
-6. Teste rollback e confirme a versao final.
+6. Teste rollback e confirme a versão final.
+
+\`framework.lock.yaml\` é relevante neste fluxo; não o carregue no trabalho comum.
 
-\`framework.lock.yaml\` e relevante neste fluxo; nao o carregue no trabalho comum.
-`,h=`# Boas praticas
+## Atualizar pelo pacote público
+
+Na raiz do projeto consumidor:
+
+\`\`\`bash
+npx @zaip-ai/cli@latest init --dry-run
+npx @zaip-ai/cli@latest init
+npx @zaip-ai/cli@latest doctor --json
+node .agents/runtime/bin/zaip.mjs doctor --json
+\`\`\`
+
+O primeiro doctor verifica a instalação; o segundo verifica o runtime distribuído.
+Leia o plano antes de autorizar uma substituição com \`--force --yes\`. O upgrade
+preserva o perfil de instalação salvo e as escolhas do projeto.
+
+Os manuais instalados ficam em \`.agents/README.md\` (português) e
+\`.agents/README-ENG.md\` (inglês), com navegação em [INDEX.md](../INDEX.md).
+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.
+
+\`@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).
+`,g=`# Boas praticas
 
 - Comece pelo resultado e aceite, nao pela ferramenta.
 - Mantenha dominio independente de infraestrutura.
@@ -476,7 +523,7 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 - 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
+`,_="# 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",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\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",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.
 
@@ -508,7 +555,7 @@ 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. | 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',S=`# Assurance adaptativa e autonomia opt-in
 
 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.
 
@@ -603,7 +650,7 @@ Ativar \`autonomous\` não afirma que o runtime está validado em produção. A
 ## Cobertura e release
 
 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 compatível com o pacote (declara 22+); para Dashboard, confirme `node:sqlite` disponível, como no ambiente de referência 22.16.0;\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## 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\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',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.
 
@@ -649,7 +696,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.
 
@@ -723,7 +770,7 @@ 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
+`,E=`# Guia de orquestração de modelos e reasoning effort
 
 ## Objetivo
 
@@ -736,7 +783,7 @@ Este guia define como o ZAIP-AIOS recomenda modelo, \`reasoning effort\` e veloc
 
 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.
 
-Toda Execution originada por PRD ou SPEC solicita velocidade \`standard\`, sem exceção ou override para Fast. A única forma suportada de executar trabalho de produto mais rápido é iniciar uma Task-first realmente independente e selecionar Fast manualmente no Codex; o ZAIP não ativa, persiste nem herda essa velocidade.
+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
 
@@ -799,13 +846,14 @@ Para permitir escolha manual em Conversation e Task-first, não fixe \`model\`,
 
 ## Família de modelos
 
-A política automática deve permanecer inicialmente na família GPT-5.6:
+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:
 
@@ -816,6 +864,7 @@ Os defaults iniciais ficam definidos assim:
 | 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 |
@@ -823,7 +872,34 @@ Os defaults iniciais ficam definidos assim:
 
 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. A seleção usa somente Luna, Terra ou Sol com effort \`low\`, \`medium\`, \`high\` ou \`xhigh\`.
+\`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
 
@@ -1206,7 +1282,7 @@ Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider
 - [Checklist de deployment e comparação por custo por sucesso](https://developers.openai.com/api/docs/guides/deployment-checklist#choose-a-gpt-56-model)
 
 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
+`,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.
 
@@ -1291,7 +1367,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.
 
@@ -1310,7 +1386,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.
 
@@ -1362,6 +1438,27 @@ sincronize/audite novamente o template público. Execute gates geradores em
 checkout/worktree isolado para preservar trabalho concorrente. Gates locais,
 artefato exato, CI terminal e produção continuam sendo provas distintas.
 
+### Paridade de documentação no pacote npm
+
+Atualize primeiro \`README.md\` e \`README-ENG.md\` do repositório-fonte, mantendo
+português como principal e equivalência de seções, tabelas, exemplos e links.
+Atualize também os guias afetados, seu índice e os READMEs do CLI público.
+Sincronize o manifesto de integridade e o template por seus geradores oficiais.
+
+O \`pack:check\` de \`public-cli\` instala o TGZ real em um consumidor temporário:
+confere os hashes dos dois manuais, dos índices e de todos os arquivos do handbook
+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
+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).
+
+Esses checks comprovam paridade local do candidato. Publicação npm, a tag
+\`latest\`, CI remoto e economia em tarefas reais precisam de suas próprias evidências.
+
 ### Falhas de desempenho no dashboard
 
 Reproduza a rota, período, filtro, offset e tamanho da página que falharam.
@@ -1465,7 +1562,7 @@ 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
+`,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,
@@ -1637,7 +1734,7 @@ 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)
+`,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 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',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
 
 [English](README-ENG.md) | Português
 
@@ -1701,13 +1798,19 @@ A atualização documental não aprova uma release. Consulte o [registro de limi
 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.
@@ -1731,7 +1834,7 @@ Todos incluem o framework, os agentes, as skills e o Dashboard. O perfil \`lite\
 
 A escolha fica salva no projeto e é respeitada nas próximas atualizações. Para habilitar desenvolvimento depois de uma instalação \`lite\`, execute \`init --profile dev-lite\`; para incluir Terraform, execute \`init --profile full\`. Mudar para um perfil menor não desinstala pacotes nem ferramentas existentes.
 
-As opções também funcionam pelo inicializador npm: \`npm create zaip-aios@latest -- --profile lite\`. Use \`--dry-run --profile full\` para consultar a mudança antes de instalar.
+Use \`npx @zaip-ai/cli@latest init --profile lite\` para instalar esse perfil. Use \`--dry-run --profile full\` para consultar a mudança antes de instalar.
 
 | Dependência | Função | Versão padrão |
 | --- | --- | --- |
@@ -2103,6 +2206,12 @@ Essa progressão permite começar de forma simples e acrescentar planejamento ap
 
 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).
 
+### 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.
+
+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 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.
 
 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).
@@ -2322,7 +2431,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.
 
-Os dois pacotes públicos compartilham a versão \`2.0\`; nos metadados npm e nos artefatos SemVer ela é registrada como \`2.0.0\`. Consulte os links npm acima 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 dos TGZs 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.
+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.
 
 A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.
 
@@ -2364,12 +2473,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
 
@@ -2423,9 +2549,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};