@zaip-ai/cli 1.3.0 → 1.3.2

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-4jZLTWE_.js → DashboardHelpDialog-BXy6nti1.js}

@@ -1,4 +1,4 @@
-import{S as e,b as t}from"./cost-monitor-N5Csr0RP.js";import{t as n}from"./dashboard-localization-CLJ0lT9v.js";var r=`# Primeiros passos
+import{S as e,b as t}from"./cost-monitor-DKwP1stV.js";import{t as n}from"./dashboard-localization-CLJ0lT9v.js";var r=`# 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.
@@ -22,6 +22,11 @@ Use Requirement para uma obrigacao duravel e testavel.
 6. Promova somente depois de validar consistencia e rastreabilidade.
 
 Um bom criterio responde inequivocamente: passou ou falhou?
+
+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
 
 Use Task para uma entrega pequena, independente e com um resultado claro.
@@ -105,13 +110,22 @@ Toda Execution originada por PRD usa velocidade \`standard\` em todas as SPECs,
 3. Inspecione o diff e preserve alteracoes alheias.
 4. Use Sub-Runs para cada subagente; a Run raiz aguarda todos os descendentes ativos.
 5. Implemente o menor incremento coerente e rode verificacoes focadas.
-6. Registre decisoes consequenciais, evidencias e desvios.
-7. Depois dos demais descendentes, execute \`zaip-agent-finalizer\` como ultimo Sub-Run da Execution. Nenhum filho novo pode iniciar depois dele.
-8. Finalize a Run raiz com status tecnico e resultado terminal da Task separados.
-9. Execute os gates finais e documente rollback.
+6. Registre decisoes consequenciais, observações por AC, evidencias e desvios.
+7. Antes de encerrar, execute os gates finais aplicáveis, documente rollback,
+   produza o commit isolado quando houver mutação e persista Validation/Evidence
+   do candidato exato. Falta de prova permanece pendência.
+8. Depois dos demais descendentes e das provas, execute \`zaip-agent-finalizer\`
+   como último filho. Nenhum filho novo pode iniciar depois dele.
+9. Aplique a decisão terminal pela CLI: Task, Change e Execution; atualize os
+   manifests e finalize a Run raiz, separando status técnico e resultado da Task.
 
 Nao marque conclusao por esforco: conclua pelo resultado verificavel. Gate insuficiente ou finalizador ausente usa blocked; erro tecnico impeditivo usa failed; cancelamento exige pedido explicito.
 
+Quando a entrega requer observação, siga o contrato de
+[prova observável](../../skills/zaip-skill-change/references/observable-evidence.md):
+o registro descreve o resultado declarado e seus limites, mas não executa o
+procedimento nem aprova o AC sozinho.
+
 \`execute\` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” volta a planejamento/rework e exige nova promoção.
 
 ## Modelo, effort e velocidade por origem
@@ -129,6 +143,13 @@ Nao marque conclusao por esforco: conclua pelo resultado verificavel. Gate insuf
 4. Verifique seguranca, compatibilidade, documentacao e rollback.
 5. Classifique achados por impacto e cite evidencia concreta.
 6. Registre o resultado sem alterar implementacao em uma revisao read-only.
+
+Para ACs que exigem observação, confira cenário, expectativa, resultado,
+candidato, ambiente, locators e limitações segundo o contrato de
+[prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
+\`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
 
 1. Comece por \`project.yaml\`, \`core.md\` e pelos manifests de \`.agents/records/lifecycle/\`.
@@ -350,6 +371,29 @@ Essas camadas reduzem probabilidade e impacto, mas podem conter bugs ou lacunas.
 nativos de \`zaip-aios-security\` oferecem proteção adicional ao negar escrita fora do workspace
 e egress para destinos diferentes de \`github.com\` antes que a operação alcance o sistema ou a rede.
 
+## Proteções do candidato e limites
+
+O Dashboard é um serviço local: antes de criar a sessão ou atender rotas,
+aceita somente autoridades HTTP \`localhost\` e \`127.0.0.1\`, com porta válida.
+Hostnames arbitrários não recebem o cookie de bootstrap, mesmo que apontem
+para loopback. Isso complementa a sessão e as verificações de origem; não
+autoriza expor o serviço por proxy ou na rede pública.
+
+Na gravação de Validation, Evidence, Observation e eventos de Run, padrões
+conhecidos de credenciais são rejeitados com erro sanitizado. Isso inclui
+Bearer/Basic, chaves privadas, atribuições explícitas de senha/chave e URLs
+com credenciais ou parâmetros sensíveis. Valores sanitizados como
+\`[REDACTED]\` e métricas numéricas de tokens continuam aceitos. A proteção não
+é um scanner universal de segredos: sanitize o conteúdo antes de registrá-lo
+e não use o aceite do parser como prova de ausência de dados sensíveis.
+Leitura de histórico não o sanitiza nem altera retroativamente sua validade.
+
+Operações concorrentes de lock preservam a contenção física. Se uma entrada
+desaparecer durante a resolução no Windows, apenas \`ENOENT\` na entrada
+lógica permite subir ao pai e revalidá-lo. Symlink/junction existente fora
+da raiz e outros erros continuam bloqueando a escrita; não existe exceção
+por nome de diretório temporário do sistema.
+
 ## Escolha do perfil
 
 Use \`zaip-aios-security\` quando:
@@ -404,7 +448,7 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 | \`.codex/hooks/zaip-pre-tool-use.mjs\` | guarda adicional de comandos |
 | \`.codex/rules/\` | decisões determinísticas de comandos permitidos e proibidos |
 | este guia | contrato operacional e comparação dos perfis |
-`,p="# Observabilidade e custos\n\n1. Selecione o Run pelo ID.\n2. Verifique duracao, tokens, custo, retries e retrabalho.\n3. Compare aceite planejado com evidencia produzida.\n4. Identifique gates lentos, contexto excessivo e chamadas repetidas.\n5. Agregue tendencias sem expor prompts ou segredos sensiveis.\n6. Converta achados recorrentes em Rule, Requirement ou melhoria de skill.\n\nRun e o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo identifica esse nivel. Sub-Run e a chamada de qualquer subagente e possui `parent_run_id`. Ambas fixam modelo e effort e agregam Calls, segmentos de uso, tokens e custo. Calls nao possuem tela ou lifecycle proprio. Operacao 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 so pode ser atribuido uma vez; uma correcao de duplicidade registra supersessao e preserva o evento historico. Inspecione `run_purpose`, pai e `agent_name`; agentes do catalogo usam `zaip-agent-*`. Diferencie status tecnico da chamada de agente e resultado terminal da Task. Reconcilie lifecycle globalmente apenas por comando humano explicito ou pelo popup confirmado; isso nao 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 foram observados ou reconciliados; valores indisponíveis permanecem `null`. Pensar sem criar permanece apenas em Conversas. Nunca atribua telemetria indisponível nem transforme ausência em zero.\n",m=`# Instalacao e upgrade
+`,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
 
 1. Verifique versao atual e estado limpo ou conscientemente preservado.
 2. Execute doctor/integrity antes da mudanca.
@@ -423,15 +467,18 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 - Prefira configuracao explicita a convencoes ocultas.
 - Leia contexto sob demanda e preserve o budget de tokens.
 - Trate documentacao, observabilidade e rollback como parte da entrega.
+- Registre observação somente como resultado declarado e vinculado; ela não
+  executa comandos, não examina automaticamente telas e não aprova um AC.
+  Aplique o [contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
 - Nunca termine a Run raiz sem o Sub-Run finalizador ou com Task em executing/verifying.
 - Nao terminalize SPEC/PRD por causa do resultado isolado de uma Task filha.
 - Prefira reconciliacao manual sob demanda; hooks de escrita fazem checagem local sem varredura global.
 - Use uma SPEC por padrão; divida somente capacidades realmente independentes e paralelizáveis.
 - Não crie Tasks durante definição: mostre blueprints compactos e materialize somente em \`ready|execute\`.
 - Resolva verbos de lifecycle pelo alvo e status persistido, nunca por palavra isolada.
-`,g="# Troubleshooting\n\n1. Reproduza o problema com o menor comando possivel.\n2. Leia a mensagem completa e identifique o primeiro erro causal.\n3. Rode doctor, validadores focados e `git diff --check`.\n4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.\n5. Compare `manifest.json`, `summary.json`, índices e chunks de `records/lifecycle`, sem varrer records.\n6. Corrija a causa, repita a reproducao e depois os gates completos.\n\nSe uma Task estiver presa em executing/verifying, use o popup Reconciliar. O reparo aceita `task_complete` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. Nao habilite reconciliacao automatica por turno ou na abertura do dashboard.\n\nSe o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.\n\nSe “finalizar” tentou entregar um PRD `draft`, confira adapters/skills: o correto é lapidar e mover para `ready`. Se uma DAG nova cruza SPECs, una as capacidades em uma SPEC e mantenha a dependência entre suas Tasks. PRD cancelado não reabre; crie sucessor `rework`.\n",_="# Tools e setup do Codex\n\n1. Peça ao agente para listar ou ativar uma tool; ele usa `$zaip-skill-tool-setup`.\n2. A skill lê somente catálogo e manifesto aplicável.\n3. MCP confiável é registrado desabilitado em `.codex/config.toml` e validado antes da ativação.\n4. API sem MCP confiável aciona `$zaip-skill-api-to-mcp` para gerar um adaptador seguro.\n5. Secrets nunca são coladas no chat; nomes ficam em `.agents/.env.example` e valores em armazenamento local ignorado.\n6. Alterações de configuração devem ser reversíveis e preservar preferências existentes.\n\nAtive por padrão apenas integrações públicas, read-only e sem autenticação, como documentação oficial. Browser/Playwright deve ser opt-in do perfil de desenvolvimento, pois inicia processos e amplia a superfície operacional.\n\n## MCP local gerado de API\n\n1. Modele um `adapter.yaml` a partir de documentação oficial; use o exemplo da skill API-to-MCP.\n2. Execute `scaffold-local-mcp.mjs` para gerar `definition.json`, `server.mjs` e `cli.mjs`.\n3. Rode `node .agents/tools/servers/<id>/cli.mjs doctor`.\n4. Faça chamadas read-only com `cli.mjs call <tool> '<json>'`.\n5. Gere um preview do Codex com `configure-local-mcp.mjs <id>`.\n6. Revise e aplique com `--write`; use `--enable` somente quando o doctor estiver pronto.\n\nO servidor usa STDIO, não abre porta e não exige deploy. Escritas ficam bloqueadas sem aprovação e `ZAIP_ALLOW_MCP_WRITES=1`.\n\n## Documentacao OpenAI\n\nO perfil default habilita `openaiDeveloperDocs` em `.codex/config.toml`, sem credencial e em modo read-only. Perguntas sobre OpenAI API, modelos, SDKs, Codex ou MCP devem acionar `$zaip-skill-openai-docs`, pesquisar o MCP oficial e citar a pagina consultada.\n",v="# Lifecycle e reconciliacao\n\n## Entradas\n\n- Conversation: pergunta, feedback ou analise read-only; cria Run intake e nenhuma Task.\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 coordena a DAG de uma ou mais Tasks.\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\nO ultimo filho de qualquer Execution e sempre o `zaip-agent-finalizer`. Ele aguarda todos os outros descendentes, cria uma barreira contra filhos posteriores e retorna uma decisao terminal restrita para a CLI aplicar. Toda Execution exige antes ao menos um executor elegivel pelas capacidades do catalogo. Status tecnico da chamada de agente e resultado do trabalho sao 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\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
+`,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
 
-Cada valor começa na telemetria de uma chamada LLM. O dashboard não estima uso ausente: dado indisponível continua indisponível.
+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.
 
 ## 1. Separe os componentes de uso
 
@@ -442,7 +489,7 @@ Cada valor começa na telemetria de uma chamada LLM. O dashboard não estima uso
 
 ## 2. Aplique as tarifas publicadas do modelo
 
-O modelo e o tier de serviço escolhidos definem a tabela de tarifas. Para uma chamada, o total em USD é:
+O modelo e o tier de serviço efetivamente observados, quando disponíveis, definem a tabela de tarifas. Para uma chamada, o total em USD é:
 
 | Componente | Cálculo |
 | --- | --- |
@@ -450,17 +497,17 @@ O modelo e o tier de serviço escolhidos definem a tabela de tarifas. Para uma c
 | Cache | \`cache / 1.000.000 × tarifa de cache\` |
 | Output | \`output / 1.000.000 × tarifa de output\` |
 
-O dashboard soma esses componentes uma única vez. Quando uma tarifa publicada não existe, ela permanece indisponível em vez de ser inventada.
+O dashboard soma esses componentes uma única vez. Quando a identidade do modelo/tier, os tokens necessários ou uma tarifa do catálogo versionado não existem, o custo permanece indisponível em vez de ser inventado.
 
 ## 3. Considere contexto, velocidade e esforço
 
-Acima do limite de contexto longo de um modelo, o multiplicador publicado de input também vale para cache e o multiplicador de output vale para todo o output. Priority/Fast usa a sua tabela de tarifas publicada, quando disponível. O multiplicador exibido é apenas uma comparação com Standard, nunca uma cobrança extra.
+Acima do limite de contexto longo de um modelo, o multiplicador publicado de input também vale para cache e o multiplicador de output vale para todo o output. \`priority\` usa a tabela publicada correspondente quando disponível. \`fast\` do Codex pode ser apresentado apenas como cenário API Priority equivalente; não prova atendimento API em Priority. O multiplicador exibido é uma comparação com Standard, nunca uma cobrança extra.
 
 O esforço não possui multiplicador direto de preço. Ele só pode aumentar o custo indiretamente quando aumenta reasoning, output ou ciclos de execução registrados.
 
 ## 4. Converta para a moeda selecionada
 
-O total da chamada é calculado primeiro em USD. Em BRL, é usada a cotação registrada no período relevante; a cotação atual é mantida separadamente para conversões atuais. Mudar a moeda de exibição nunca altera a telemetria de tokens nem o cálculo em USD.
+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
 
 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.
@@ -478,6 +525,21 @@ O ZAIP-AIOS separa duas decisões que não devem ser confundidas: quanto de prov
 
 Uma única Evidence pode cobrir vários ACs nos perfis \`lite\` e \`standard\`, e nos perfis parentais que não exigem Evidence dedicada por AC. Em todos os casos, a cobertura precisa ser completa e a Evidence deve referenciar uma validação tipada aprovada da mesma Task, Change e Execution. Texto declarando que algo passou não é prova.
 
+## Observação por AC
+
+Para entrega nova ou verificação retomada, use o contrato de
+[prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).
+Uma observação descreve o cenário, expectativa, resultado, ambiente,
+candidato, locators e limitações. O CLI valida estrutura e vínculos, mas não
+executa o comando declarado, não examina pixels e não consulta banco
+automaticamente. Só observação \`confirmed\` e compatível pode complementar uma
+Evidence; nunca a aprova isoladamente. Históricos V2 sem observações continuam
+legíveis e não são promovidos retroativamente.
+
+Conteúdo de novos registros passa também por rejeição de padrões conhecidos
+de credenciais, sem ecoar valores no erro. Isso não valida a autenticidade
+da observação nem substitui sanitização e revisão humana dos locators.
+
 \`standard_depth: auto\` escolhe o perfil base quando \`verification_scope: scoped\` está persistido e o elevado para escopo mais amplo. Para registros históricos sem esse sinal, o fallback conservador usa mais de um write scope; ele não substitui a classificação nova. O perfil \`lite\` não é permitido como atalho para segurança, migração, irreversibilidade ou mudança multi-domínio crítica.
 
 Em \`critical\`, a revisão de qualidade independente é sempre exigida. Mutação é exigida apenas para segurança ou dados críticos; rollback para migração, irreversibilidade ou rollback não trivial; e Evidence por AC para segurança ou migração. Evidência de commit final é exigida para impacto em produção, ação externa ou migração. Esses controles são decididos pelos sinais de risco persistidos, não por quotas máximas de artefatos.
@@ -528,38 +590,40 @@ O driver autônomo:
 - limita \`lite\` a uma tentativa e \`standard\`/\`critical\` a no máximo três tentativas de desenvolvimento ou reparo;
 - usa verificador independente para critical, SPEC e PRD.
 
+Na Task autônoma, o adapter respeita o mesmo rigor calculado: \`lite\` não exige
+um teste quando a política permite outra modalidade; mutação e rollback
+exigidos precisam de provas tipadas, inclusive em Task crítica sem pai.
+Sinais de risco ausentes mantêm o fallback conservador. Artefatos históricos
+de outra Run ou candidato não aprovam a entrega atual nem impedem uma nova
+aprovação quando as provas atuais estão completas. Limites de invocação são
+reservados atomicamente e retomadas não zeram o consumo acumulado.
+
 Ativar \`autonomous\` não afirma que o runtime está validado em produção. A maturidade só avança quando o mesmo hash do candidato passa validação local, cleanroom, ambiente representativo e observação de produção, nessa ordem.
 
 ## 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 22 ou superior;\n- pnpm 11;\n- Git;\n- permissões de escrita no repositório consumidor.\n\n## Construir o CLI\n\nNo repositório-fonte:\n\n```bash\npnpm install\npnpm build\nnode packages/cli/dist/index.js version\n```\n\nNos exemplos abaixo, substitua `zaip` por `node /caminho/zaip-aios/packages/cli/dist/index.js` se o binário ainda não estiver no `PATH`.\n\n## Instalar ou atualizar\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. Toda mensagem é capturada por uma Execution e uma Run. Para pergunta, feedback ou análise pontual somente leitura, use `zaip conversation start` e `zaip conversation finish`: é criada uma Execution `interaction`, sem Task ou Change artificial. A criação ou o refinamento explícito de PRD/SPEC `draft` é a exceção de definição e pode persistir o macro e seu PreparedPlan na própria `interaction`, sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer alteração intencional e persistente em código, documentação, configuração ou outro arquivo do repositório ou do computador exige uma Execution `delivery`, Task materializada e Run raiz de orquestração ativa antes da primeira escrita.\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\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
+`,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
 
-Atualizado em 26 de julho de 2026.
+Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
 
 ## Escopo
 
-O Monitor de Custos é uma visão financeira de invocações LLM. Cada linha exibida deve possuir:
-
-- tokens coletados;
-- custo BRL calculável a partir dos tokens e do catálogo histórico;
-- duração de origem observada.
-
-Runs de lifecycle não são automaticamente linhas financeiras. Uma Run sem chamada LLM, ou com chamada sem correspondência local verificável, permanece no histórico de Operação e não entra no Monitor. Isso impede que \`0\` seja usado para esconder falta de coleta.
+O Monitor de Custos é uma visão financeira da população de Runs de Operação. Cada linha preserva a disponibilidade de suas métricas: tokens sem captura, custo sem componentes/tarifa/câmbio suficientes e duração sem fonte permanecem indisponíveis; não são convertidos em \`0\` nem removidos para produzir uma cobertura artificial. A elegibilidade de uma estimativa de custo exige tokens e identidade de preço verificáveis, mas uma Run de lifecycle não precisa ter chamada LLM para continuar visível com lacunas explícitas.
 
 ## Fonte e proveniência
 
 A projeção é **manifest-first**: usa os manifests e registros Git como fonte canônica e a telemetria local apenas para uma reconciliação com correspondência exata. O Dashboard não usa SQLite como fonte de dados do Monitor de Custos.
 
-Tokens, custo e duração exibidos no Monitor mantêm proveniência observada. Uma duração limitada de lifecycle com proveniência \`legacy_inferred\` pode permanecer em Operação e Rastreabilidade, mas não completa uma linha financeira nem entra em seus agregados.
+Tokens, custo e duração devem exibir sua proveniência. Tokens e configuração efetiva de modelo/effort só são observados quando a fonte os informa; defaults planejados não preenchem esses campos. A projeção pode exibir duração \`observed\`, \`reconciled\`, \`legacy_inferred\` ou \`estimated\`. Apenas \`observed\` é medição da fonte; as demais são derivadas e não satisfazem um critério que exija duração capturada.
 
 ## Cobertura e valores exibidos
 
-\`Cobertura de 100%\` neste monitor significa que todas as linhas financeiras exibidas têm tokens, custo e duração observada. A contagem e a cobertura precisam ser recalculadas após qualquer mudança no critério de elegibilidade; não reutilize uma auditoria anterior como prova do conjunto novo.
+Cobertura é calculada por métrica e pelo conjunto filtrado. \`100%\` para tokens, custo ou duração só significa que aquela métrica está completa segundo sua definição e proveniência declarada; não demonstra automaticamente que as outras estão completas ou que a duração foi observada. Recalcule a cobertura após qualquer mudança de critério e não reutilize uma auditoria anterior como prova do conjunto novo.
 
-Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual usam as mesmas invocações financeiras da tabela. Um agente configurado sem invocações no período é um agregado vazio real e exibe zero. Duração ausente exibe \`Indisponível\`; o valor bruto e sua proveniência continuam disponíveis para auditoria.
+Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual usam o mesmo conjunto filtrado da tabela e preservam as lacunas de cada métrica. Um agente configurado sem invocações no período é um agregado vazio real e exibe zero. Duração ausente exibe \`Indisponível\`; uma duração derivada deve mostrar sua proveniência e não ser lida como captura.
 
-Não se deve converter em zero um registro que esteja fora do conjunto financeiro por ausência de coleta. Na auditoria, 126 Runs de Operação estavam nessa condição: 111 sem chamada LLM e 15 sem correspondência local única. Elas não alteram a cobertura das linhas financeiras.
+Não use contagens, totais ou percentuais de auditorias passadas como diagnóstico atual. Consulte o período e os filtros da execução auditada; uma lacuna de coleta continua sendo lacuna, mesmo quando há estimativa ou reconciliação exibida.
 
 ## Filtros e totais
 
@@ -582,9 +646,9 @@ Filtros preenchidos somente com data são inclusivos: a data inicial começa em
    node scripts/validate-release-parity.mjs --release
    \`\`\`
 
-3. Consulte \`/api/v2/cost-monitor\` no período auditado e confirme, para cada grupo, que \`missing_tokens\`, \`missing_cost_brl\` e \`missing_duration\` são zero. Em seguida, compare o total de custo retornado com o card da Visão geral usando exatamente os mesmos filtros.
+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. Ação de reconciliação não autoriza estimar token, custo ou duração.
+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
 
 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.
@@ -607,6 +671,11 @@ Tentativa → gates e review
   correção necessária → classificar rework → recalibrar agente, modelo e esforço → nova tentativa
 \`\`\`
 
+Observação por AC é um checkpoint de prova, não um supervisor de tempo ou um
+atalho de aprovação: o registro não executa o procedimento, não transforma
+resultado pendente em verde e não dispensa review/finalizador. Consulte o
+[contrato canônico](../../skills/zaip-skill-change/references/observable-evidence.md).
+
 Em PRD/SPEC com \`model_orchestration.mode:auto\`, trabalho simples e delimitado pode usar Luna/low, execução padrão Terra/medium e ambiguidade, transversalidade ou rework estrutural Sol/high ou xhigh. Conversation e Task-first preservam a seleção manual do host/Codex. Criticidade amplia assurance; não eleva modelo mecanicamente.
 
 ## Entradas e planejamento
@@ -687,7 +756,7 @@ Quando \`model_orchestration.mode\` estiver como \`manual\`, o ZAIP:
 4. informa a recomendação antes de continuar;
 5. nunca altera a configuração automaticamente.
 
-O modo manual não usa hook nem tenta coletar a configuração efetiva no transcript. Quando algum valor não estiver disponível, usa \`default_model\`, \`default_effort\` e \`default_velocity\` de \`project.yaml\`. Nesta versão, os três fallbacks são literalmente \`manual\`; o aviso nunca usa \`não informado\` nem infere valores pelo comportamento aparente do modelo.
+O modo manual não usa hook nem tenta coletar a configuração efetiva no transcript. \`default_model\`, \`default_effort\` e \`default_velocity\` podem orientar uma recomendação, mas não comprovam o que o host executou. Quando modelo, effort ou velocidade efetivos não vierem de fonte observada, registre-os como indisponíveis/\`unknown\`; nunca os infira pelo comportamento aparente do modelo nem os substitua pelo default.
 
 Formato recomendado:
 
@@ -815,7 +884,7 @@ O catálogo mantém IDs internos estáveis como \`agent-builder\`, enquanto o ad
 | --- | --- | --- |
 | \`agent-orchestrator\` | Terra \`low\` | Sol \`medium\` para DAG complexa; \`high\` para síntese final crítica |
 | \`agent-builder\` | Terra \`medium\` | Sol \`medium\` para arquitetura, segurança ou migração |
-| \`agent-reviewer\` | Sol \`medium\` | Sol \`high\` para revisão complexa delimitada |
+| \`agent-reviewer\` | Terra \`medium\` no catálogo | Sol quando a política e os sinais da revisão justificarem elevação; \`high\` para revisão complexa delimitada |
 | \`agent-integrator\` | Terra \`medium\` | Sol \`medium\` somente quando outra regra explícita exigir raciocínio transversal |
 | \`agent-auditor\` e \`agent-security-auditor\` | Sol \`high\` | \`xhigh\` apenas quando elegível e medido |
 | \`agent-finalizer\` | Terra \`medium\` | sem elevação automática; avalia evidência já produzida |
@@ -1060,7 +1129,7 @@ policy.runtime_defaults explícito da Execution
 
 O runtime anuncia modelos, efforts e velocidades antes do dispatch. Modelo fora da allowlist, effort desconhecido, \`ultra\`, \`max\`, velocidade diferente de \`standard\` ou capacidade incompatível produzem erro tipado; não existe fallback silencioso.
 
-O cabeçalho de cada Run ou Sub-Run preserva a configuração resolvida, e \`model.selection.recorded\` registra a mesma decisão antes do dispatch; o default do catálogo não pode substituir o modelo realmente invocado. Telemetria efetiva e Calls conhecidas permanecem dentro da mesma chamada de agente. Run raiz é a chamada do orquestrador e possui \`parent_run_id: null\`; Sub-Run possui pai:
+Quando a seleção foi registrada, o cabeçalho da Run ou Sub-Run preserva a configuração resolvida e \`model.selection.recorded\` registra a decisão antes do dispatch; o default do catálogo não pode substituir o modelo realmente invocado. Telemetria efetiva e Calls conhecidas permanecem dentro da mesma chamada de agente. Capturas terminais sem metadados ricos mantêm modelo e effort indisponíveis; não devem receber uma seleção reconstruída. Run raiz é a chamada do orquestrador e possui \`parent_run_id: null\`; Sub-Run possui pai:
 
 \`\`\`yaml
 agent_run:
@@ -1085,7 +1154,7 @@ agent_run:
     - terra-implementation-baseline
 \`\`\`
 
-Requested e effective não devem ser confundidos, pois o runtime ou serviço pode aplicar fallback ou reroteamento.
+Requested e effective não devem ser confundidos, pois o runtime ou serviço pode aplicar fallback ou reroteamento. \`effective_*\` só pode ser preenchido por fonte observada; ausência dessa fonte não autoriza copiar \`requested_*\`.
 
 No dashboard, Runs e Sub-Runs são separados por \`parent_run_id\` e ordenados por \`started_at\` decrescente, independentemente do shard físico da projeção. A Run raiz usa a identidade visível \`zaip-agent-orchestrator\`; Sub-Runs usam o \`zaip-agent-*\` efetivamente selecionado. O Monitor de Custos agrupa e filtra pela identidade visível, mantém o modelo configurado de cada chamada em destaque e mostra o modelo efetivo separadamente. Quando o host não informou a configuração planejada, o modelo efetivo é rotulado como observado, nunca apresentado como se tivesse sido selecionado pelo catálogo.
 
@@ -1099,7 +1168,7 @@ O dashboard cria visões separadas para Runs e Sub-Runs, mas não cria entidade
 4. tokens e custo agregados na Run;
 5. divergência requested/effective sem dupla contagem.
 
-Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider aplicar fallback, a diferença aparece como configuração efetiva e não muda o cabeçalho. Valores indisponíveis permanecem \`null\`; prompt e reasoning privado nunca são armazenados.
+Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider aplicar fallback, a diferença aparece como configuração efetiva observada e não muda o cabeçalho. Valores indisponíveis permanecem \`null\`; prompt e reasoning privado nunca são armazenados.
 
 ## Garantias implementadas
 
@@ -1107,7 +1176,7 @@ Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider
 2. \`automatic_sources\` restringe a política a \`spec\` e \`prd\`; o schema rejeita \`task\`.
 3. Novos PreparedPlans de PRD/SPEC calculam risco e motivos a partir de sinais persistidos; planos históricos permanecem legíveis.
 4. O coordenador injeta a política somente em Executions elegíveis e resolve novamente no início de cada Agent Run de Task/fase.
-5. A captura de conversa registra o modelo explicitamente observado ou \`unknown\`; não infere o baseline automático para Task avulsa.
+5. A captura de conversa registra o modelo explicitamente observado ou \`unknown\`; modelo e effort efetivos não são inferidos a partir do baseline automático, do catálogo ou de uma Task avulsa.
 6. O resolvedor determinístico aplica allowlist, capacidades, overrides e motivos observáveis antes do dispatch.
 7. Testes cobrem a matriz de risco/modelo/effort, precedência, capacidades, rejeições e atribuição sem inferência.
 8. O ledger rejeita Calls com modelo, effort ou decisão de seleção solicitados diferentes dentro da mesma Agent Run.
@@ -1139,7 +1208,7 @@ Todas as Calls da mesma Run reutilizam a configuração planejada. Se o provider
 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
 
-Atualizado em 15 de julho de 2026.
+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.
 
 ## Objetivo e limite
 
@@ -1156,7 +1225,7 @@ O Fast do Codex é consumo de créditos da assinatura e não prova que uma requi
 
 ## Invariantes de telemetria
 
-O Monitor de Custos é uma superfície financeira: uma invocação só aparece quando possui tokens, custo e duração de origem observados. Lifecycle e telemetria parcial continuam disponíveis em Operação e Rastreabilidade. \`null\` permanece \`Indisponível\`; nunca é convertido em zero. Duração inferida de registros legados pode ser exibida apenas nessas superfícies não financeiras, identificada como inferida.
+O Monitor de Custos preserva a disponibilidade por métrica. Custo equivalente só é calculado quando os tokens, a identidade de preço e a tarifa necessária estão disponíveis. Lifecycle e telemetria parcial continuam visíveis com lacunas explícitas. \`null\` permanece \`Indisponível\`; nunca é convertido em zero. A projeção pode mostrar duração reconciliada, inferida ou estimada com proveniência, mas isso não é duração observada nem comprova uma medição da chamada.
 
 \`\`\`text
 cached_input <= input
@@ -1181,9 +1250,9 @@ BRL_total = USD_total × cotação_USD_BRL
 
 A conversão para BRL é a última etapa. Quando a moeda exibida é USD, não há conversão.
 
-## Exemplo prático — GPT-5.6 Sol, Standard
+## Exemplo didático — GPT-5.6 Sol, Standard
 
-Tarifas atuais do catálogo: input US$5, cache US$0,50 e output US$30 por 1M. Para 1.000.000 input, 800.000 cache, 100.000 output e 70.000 reasoning:
+No snapshot local consultado durante a redação, \`gpt-5.6-sol\` contém input US$5, cache US$0,50 e output US$30 por 1M. Esses números ilustram a fórmula; confira o catálogo e a fonte registrada antes de usar valores em uma decisão atual. Para 1.000.000 input, 800.000 cache, 100.000 output e 70.000 reasoning:
 
 \`\`\`text
 input sem cache = 1.000.000 - 800.000 = 200.000
@@ -1194,7 +1263,7 @@ reasoning = US$ 0,00 adicional (já está nos 100.000 output)
 total = US$ 4,40
 \`\`\`
 
-Com USD/BRL 5,45: \`4,40 × 5,45 = R$ 23,98\`.
+Com uma cotação **hipotética** USD/BRL de 5,45: \`4,40 × 5,45 = R$ 23,98\`.
 
 ## Service tier, contexto e dados incompletos
 
@@ -1202,11 +1271,11 @@ Com USD/BRL 5,45: \`4,40 × 5,45 = R$ 23,98\`.
 - Priority e contexto longo sem tarifa oficial combinada retornam custo indisponível, em vez de uma multiplicação inventada.
 - Regras de contexto longo só são usadas para modelos cujo catálogo traz limiar e tarifas publicadas.
 - Modelo sem correspondência, provedor incompatível ou tarifa ausente retorna \`null\` para custo.
-- Runs históricas sem billing mode, snapshot ou tier efetivo são estimativas equivalentes, nunca valores de fatura.
+- Runs históricas sem billing mode, snapshot ou tier efetivo não comprovam uma cobrança; se faltarem os componentes exigidos pelo cálculo, o custo equivalente permanece indisponível.
 
 ## Auditoria por Run
 
-Na aba Runs, confirme nesta ordem: modelo efetivo, velocidade observada, **Cenário velocidade API**, input, cache, output, reasoning, tarifas selecionadas, USD e BRL. \`Priority (derivado de Fast)\` significa cenário de estimativa, não cobrança API comprovada. \`USD/BRL registrado\` e \`BRL registrado\` são a fotografia histórica quando existirem; \`Estimativa API (BRL)\` usa a cotação global atual.
+Na aba Runs, confirme nesta ordem: fonte do modelo efetivo, velocidade observada, **Cenário velocidade API**, input, cache, output, reasoning, tarifas selecionadas, USD e BRL. Modelo/effort sem fonte observada permanecem indisponíveis. \`Priority (derivado de Fast)\` significa cenário de estimativa, não cobrança API comprovada. \`USD/BRL registrado\` e \`BRL registrado\` são fotografia histórica quando existirem; uma estimativa em BRL deve identificar a cotação usada, sem apresentá-la como valor atual por padrão.
 
 ## Prova real agregada por modelo
 
@@ -1214,7 +1283,7 @@ A aba **Modelos** não lista Runs. Cada linha agrega todas as Runs do modelo den
 
 As tarifas exibidas ali são **efetivas ponderadas**, não uma média simples: \`USD do componente × 1.000.000 / tokens cobráveis do componente\`. Assim, a taxa reproduz exatamente o custo agregado mesmo quando o modelo tiver Runs com contextos ou tarifas diferentes. Contexto, multiplicador de velocidade e cenário mostram \`Misto\` quando não forem uniformes; o dashboard não inventa uma média para multiplicadores.
 
-Para conferir a soma: \`USD estimado API = USD entrada + USD cache + USD saída + USD raciocínio\`; no catálogo atual o último normalmente é zero, porque reasoning já está incluído em output. O câmbio efetivo é \`BRL estimado / USD estimado\`, calculado somente depois da soma em USD.
+Para conferir a soma: \`USD estimado API = USD entrada + USD cache + USD saída + USD raciocínio\`; no snapshot local usado pela implementação, reasoning é parte de output e o componente adicional é zero quando \`reasoning_billed_separately\` é falso. O câmbio efetivo é \`BRL estimado / USD estimado\`, calculado somente depois da soma em USD.
 
 ## Implementação e testes
 
@@ -1224,7 +1293,7 @@ Para conferir a soma: \`USD estimado API = USD entrada + USD cache + USD saída
 - Testes: \`pnpm --filter @zaip-ai/costs test\` e \`pnpm --filter @zaip-ai/dashboard-cost-monitor test\`
 `,D=`# Fontes oficiais de preços OpenAI
 
-Consulta em 15 de julho de 2026. Valores operacionais ficam no catálogo versionado \`.agents/config/pricing/models.json\`; esta página é o registro de auditoria das fontes.
+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.
 
 | Tema | Fonte oficial | Uso na implementação |
 | --- | --- | --- |
@@ -1235,11 +1304,12 @@ Consulta em 15 de julho de 2026. Valores operacionais ficam no catálogo version
 
 ## Regras de atualização
 
-1. Atualize primeiro a fonte oficial e a data de consulta.
+1. Consulte novamente a fonte oficial e registre a data/hora da nova consulta; não promova esta tabela histórica a estado atual.
 2. Atualize o catálogo em uma alteração separada e registre o snapshot/versão quando disponível.
 3. Inclua testes com input, cached input e output.
 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
 
 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.
@@ -1250,29 +1320,111 @@ O candidato de release precisa passar gates locais, clean-room e distribuição
 
 - 80% de lines;
 - 80% de functions;
-- 70% de branches;
+- 75% de branches;
 - 80% de statements.
 
 O composition root executável \`packages/cli/src/index.ts\` é coberto pelos testes CLI/release E2E. O payload gerado \`packages/cli/src/dashboard-template.ts\` é coberto pela paridade do template. Ambos ficam fora da cobertura unitária para não misturar integração e geração de distribuição com unidade de domínio.
 
 O ratchet usa o maior valor entre o floor atual e o baseline versionado. Uma medição menor falha; o baseline não pode ser atualizado para encobrir regressão.
 
-## Ordem de qualificação
-
-1. \`pnpm validate:github:prepared\`
-2. \`pnpm test:coverage\`
-3. \`pnpm test:release-e2e\`
-4. \`pnpm turbo run test:e2e --filter=@zaip-ai/dashboard-e2e\`
-5. \`pnpm audit --prod --audit-level high\`
-6. \`pnpm --dir public-cli verify\`
-7. \`pnpm release:verify\` no worktree final limpo
-
-\`release:artifacts\` deve estabilizar os manifests antes de \`sync:framework-lock\`. Depois do lock, o template público é sincronizado e auditado novamente.
+## Gates agregados e diagnósticos
+
+O gate de PR é o job único \`github-equivalent\` de
+\`.github/workflows/quality.yml\`, em \`ubuntu-latest\`: instala dependências,
+instala Chromium e executa \`validate:github:prepared\`, auditoria de produção,
+cobertura, release E2E e dashboard E2E. Esses subchecks são etapas desse gate
+agregado; não são uma receita adicional que, isoladamente, aprove uma release.
+
+O workflow \`.github/workflows/publish-cli.yml\` é separado: seu job \`verify\`
+usa matriz real Node 22 e 24 para \`pnpm verify\`; a auditoria e o artefato de
+release ocorrem somente na linha Node 24, ambas em Ubuntu. Publicação e smoke
+só seguem após a matriz aprovada. Esse \`verify\` roda dentro de \`public-cli\`,
+não é o script homônimo da raiz. Os comandos abaixo são do checkout mantenedor;
+não presuma que existam no \`package.json\` do projeto consumidor.
+
+A publicação compara \`dist.integrity\` do registro com o SHA-512 do tarball
+verificado. Uma versão já existente só é aceita quando o conteúdo é idêntico.
+Somente \`E404\` estruturado indica ausência; autenticação, rede, resposta
+inválida ou integridade diferente impedem publicar. Após uma publicação
+autorizada, a confirmação do mesmo tarball usa retry finito de propagação.
+Esse controle não publica automaticamente quando a qualificação local passa.
+
+| Objetivo | Comando da raiz e alcance |
+| --- | --- |
+| Preparar artefatos | \`corepack pnpm release:artifacts\` compila e gera runtime/template. Não publica nem qualifica por si só. |
+| Atualizar integridade após mudança gerenciada intencional | \`corepack pnpm sync:framework-lock\`, depois \`corepack pnpm validate:framework-lock\`; não usar para aceitar drift desconhecido. |
+| Diagnosticar um check | Executar apenas o teste/check pertinente e registrar seu resultado. Isso não substitui a qualificação completa. |
+| Qualificar localmente | \`corepack pnpm release:verify\` agrega instalação pública, validação preparada, cobertura, release E2E, dashboard E2E, audit e árvore limpa. |
+| Verificação completa da raiz | \`corepack pnpm verify\` acrescenta orçamento de Rules e contrato antes de \`release:verify\`. Não precisa repetir manualmente cada subcomando no mesmo candidato. |
+
+Finalize as escritas gerenciadas antes de sincronizar o lock; após alterá-lo,
+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.
+
+### Falhas de desempenho no dashboard
+
+Reproduza a rota, período, filtro, offset e tamanho da página que falharam.
+Separe a primeira consulta sem resultado em cache da navegação já aquecida;
+uma página rápida em cache não comprova o custo de exportar páginas distintas.
+Correlacione o clique com a requisição, a espera pelo servidor, o retorno e o
+fechamento do arquivo. Registre a concorrência do teste e do ambiente.
+
+Timeout não autoriza aumentar limites nem remover a matriz de performance.
+Primeiro diferencie requisição ausente, cancelada, bloqueada e consulta lenta.
+Uma correção de consulta deve preservar filtros, ordenação, total, IDs únicos,
+offsets contíguos e exportação até \`has_more=false\`. Reexecute o cenário que
+falhou e o gate correspondente no candidato corrigido. Se o pacote anterior
+já estiver publicado, distribua a correção em nova versão imutável.
+
+## Histórico e nova qualificação em 30/08/2026
+
+Snapshot bloqueado em 2026-08-30 para o candidato
+\`d00851adfd78b4e4af8e888e270d55ace749607e\`: não há release verde declarada.
+A tentativa de reparo isolado do runtime passou 9 de 10 testes e
+falhou em \`reports a missing runtime and restores it transactionally\`:
+\`FLAT_FRAMEWORK_RULES\` não classifica
+\`.agents/rules/dashboard-ui-consistency.md\`, embora a regra esteja no template,
+e a restauração transacional retorna \`repaired.applied=false\`. A correção do
+instalador está fora daquele recorte e não foi aprovada nem validada.
+
+Também não está verde o teste completo de orçamento das Rules: a folga exigida
+para \`run-lifecycle-closure.md\` é 867 e o orçamento atual é 840. Isso é uma
+falha registrada, não um snapshot a ser tratado como aprovação. Sem corrigir e
+reexecutar esses gates no candidato apropriado, não declare clean-room,
+qualificação integral, produção ou release aprovados.
+
+O relatório-fonte deste snapshot é
+\`.agents/records/changes/2026/08/CHG-2026-08-30-18-18-EVIDENCIAS-OBSERVAVEIS-SEGURAS-K5WJ/artifacts/checks/verification-report.md\`
+no repositório mantenedor; ele não é distribuído como histórico do consumidor.
+O status central de readiness não é ligado aqui porque
+\`docs/PRODUCTION-COMMERCIAL-READINESS.md\` não faz parte do template público
+instalado; um link relativo seria enganoso para consumidores do pacote.
+
+A entrega corretiva posterior \`TASK-2026-08-30-19-51-LIBERAR-PRODUCAO-SEGURA-2NA6\`
+inclui a Rule ausente no instalador e reduz o texto de encerramento sem
+aumentar o orçamento 840. Os cenários focais de reparo e orçamento foram
+reexecutados com sucesso. O snapshot acima é histórico: não deve ser apagado
+nem usado como resultado do novo candidato. A aprovação da candidata nova
+depende de seus próprios gates completos, artefato, SHA e revisão independente.
+Os resultados finais ficam na Change correspondente no checkout mantenedor,
+não no histórico distribuído ao consumidor.
 
 ## Arquivos efêmeros
 
 \`test-results\`, \`playwright-report\`, \`coverage\`, \`.turbo\` e \`node_modules\` nunca pertencem ao pacote portável nem ao manifesto gerenciado. A embalagem e o clean-room aplicam a mesma política de exclusão.
 
+Antes de substituir \`public-cli/artifacts\` ou executar \`npm pack\`, o guard de
+release compara o inventário público efetivo do Dashboard com os arquivos
+rastreados pelo Git. Somente os dois outputs declarados do build SQLite,
+\`packages/local-runtime/dist/server.cjs\` e
+\`packages/local-runtime/dist/sqlite-read-model.cjs\`, podem ser gerados sem
+rastreamento. Outros arquivos não rastreados, inclusive diagnósticos ignorados
+pelo Git, impedem a embalagem. Uma consulta Git indisponível também bloqueia.
+O guard não remove, move, ignora ou adiciona arquivos ao Git; a limpeza deve
+ser resolvida pelo responsável autorizado, preservando os artefatos anteriores.
+Use o checkout limpo do candidato exato e não publique TGZs de diagnóstico.
+
 ## Evidência e aprovação
 
 Testes passando comprovam validação técnica. Maturidade formal máxima exige ainda:
@@ -1298,7 +1450,9 @@ O caminho implementado possui quatro camadas:
 4. leitura manifest-first no Monitor de Custos, complementada pelos dados de lifecycle já lidos dos manifests canônicos.
 
 O rollout amplo continua condicionado à cobertura observada. Ter o pipeline instalado não autoriza
-rotular métricas ausentes como completas nem transformar valores desconhecidos em zero.
+rotular métricas ausentes como completas nem transformar valores desconhecidos em zero. Duração,
+tokens e custo não capturados permanecem explicitamente indisponíveis; uma reconciliação ou
+estimativa só pode aparecer com proveniência e não passa a ser observação da fonte.
 
 ## Fluxo dos dados
 
@@ -1369,7 +1523,9 @@ Um resumo preserva:
 
 O custo histórico é agregado apenas quando preço, câmbio e componentes necessários são
 compatíveis. O leitor não reprecifica silenciosamente uma execução antiga. Se qualquer componente
-necessário estiver ausente, o total correspondente permanece \`null\`.
+necessário estiver ausente, o total correspondente permanece \`null\`. Modelo e reasoning effort
+efetivos também permanecem indisponíveis quando o host não os informou; não são derivados do
+catálogo, da seleção planejada ou do comportamento aparente.
 
 ### Chunks e manifestos
 
@@ -1406,7 +1562,8 @@ chunks incompatíveis antes da leitura. O leitor valida:
 Quando há summaries válidos para o período, tokens e custos vindos do manifesto são autoritativos.
 Os dados de lifecycle carregados de \`records/lifecycle\` continuam fornecendo campos que o resumo não
 conhece. Em particular, uma duração de lifecycle delimitada é preservada quando o summary não possui
-duração observável. Se não houver summaries aplicáveis, o Dashboard preserva os dados de lifecycle e
+duração observável. Essa preservação mantém a proveniência: duração reconciliada, inferida ou
+estimada não deve ser lida como duração capturada. Se não houver summaries aplicáveis, o Dashboard preserva os dados de lifecycle e
 a cobertura disponível; não lê nem recria uma projeção ou arquivo local, e nunca promove a cobertura
 para \`complete\`.
 
@@ -1451,17 +1608,17 @@ 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\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)
+`,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)
 
 ## Visão rápida
 
 O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
 
-Os agentes trabalham de forma integrada e em cadeia: planejam, executam, revisam, testam e validam o trabalho, acionando automaticamente o próximo especialista quando necessário. Em vez de o usuário precisar solicitar cada alteração, teste, revisão ou correção separadamente, o ZAIP-AIOS conduz o fluxo de ponta a ponta até que os critérios definidos sejam atendidos.
+Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios definidos ou registrar um bloqueio, falha ou limite de orçamento. Dependências externas e decisões fora da autoridade recebida continuam exigindo intervenção humana; autonomia não significa execução indefinida nem garantia de acerto.
 
-Essa abordagem reduz intervenções manuais, acelera o ciclo de execução e pode gerar uma redução de 34% a 62% no consumo de tokens, ao distribuir cada etapa para agentes especializados e evitar interações, contexto e retrabalho desnecessários.
+Essa abordagem busca reduzir intervenções, contexto desnecessário e retrabalho. Os percentuais de 34% e 62% apresentados adiante se referem a custo médio por tarefa e por hora nas séries históricas ilustradas, respectivamente; não medem diretamente redução de tokens nem garantem economia em uma nova entrega.
 
-Embora tenha nascido com forte foco em desenvolvimento de software, o ZAIP-AIOS também executa demandas de Operações, Growth, Marketing, Branding e Vendas, permitindo coordenar diferentes tipos de trabalho dentro da mesma arquitetura autônoma, sem consumo direto de APIs de IA e sem necessidade de infraestrutura própria em VPS.
+Embora tenha nascido com foco em software, o ZAIP-AIOS também coordena demandas de Operações, Growth, Marketing, Branding e Vendas. O framework e o Dashboard funcionam localmente, sem exigir VPS. Autenticação, franquia, cobrança e integrações dependem do host/provider escolhido; usar uma assinatura no Codex não transforma o custo equivalente estimado em cobrança de API.
 
 <img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
 
@@ -1477,7 +1634,7 @@ A comparação considera o ciclo completo de trabalho, planejamento, execução,
 
 <img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Análise comparativa: custo médio por hora caiu de R$ 410 para R$ 154" width="900">
 
-A fonte da verdade permanece no Git. Requisitos, decisões, implementações, testes, revisões e evidências são versionados no repositório e preservados no histórico publicado no GitHub.
+A fonte canônica permanece nos arquivos Git-native do repositório. Requisitos, decisões, implementações e provas podem ser versionados; só passam a estar no histórico remoto após commit e publicação explicitamente autorizada. Segredos e estado privado da máquina ficam fora desse histórico.
 
 O Dashboard utiliza um banco de dados local, descartável e reconstruível, apenas como camada de consulta e visualização. Nenhuma informação crítica depende exclusivamente dele.
 
@@ -1497,10 +1654,18 @@ No ZAIP-AIOS, uma Task não é considerada concluída apenas porque um agente te
 | Consultar os contratos técnicos | [Referência técnica e operacional](#referência-técnica-e-operacional) |
 | Manter o framework | [Desenvolvimento do framework](#desenvolvimento-do-framework) |
 | Configurar permissões com segurança | [Segurança com perfis de permissão](#segurança-com-perfis-de-permissão) |
+| Avaliar lançamento, suporte e comercialização | [Prontidão para produção e comercialização](docs/PRODUCTION-COMMERCIAL-READINESS.md) |
+| Navegar pelos 28 guias operacionais | [Índice completo do handbook](.agents/zaip-aios/INDEX.md) |
+
+### Como interpretar esta documentação
+
+Este README e o [handbook](.agents/zaip-aios/INDEX.md) descrevem o código-fonte deste repositório. Configuração efetiva, suporte do host, pacote instalado e candidato qualificado são dimensões distintas. \`@latest\` aponta para a versão publicada, que pode não conter alterações locais. As imagens do Dashboard são ilustrações de estados anteriores, não prova visual do candidato atual.
+
+A atualização documental não aprova uma release. Consulte o [registro de limites de qualificação](docs/PRODUCTION-COMMERCIAL-READINESS.md#limites-conhecidos-da-qualificação) antes de promover o código; testes locais, paridade, CI e validação em produção devem ser comprovados separadamente.
 
 ## Instalação em um comando
 
-Com Node.js 22 ou mais recente e Git disponíveis, a instalação acontece na raiz do repositório que receberá o ZAIP-AIOS:
+Com Git e uma versão compatível de Node.js, a instalação acontece na raiz do repositório que receberá o ZAIP-AIOS. O pacote declara Node.js 22+; para o Dashboard com \`node:sqlite\`, use uma versão que disponibilize esse módulo (o ambiente de referência deste checkout usa 22.16.0), não qualquer versão inicial da série 22:
 
 \`\`\`bash
 npx @zaip-ai/cli@latest init
@@ -1572,7 +1737,7 @@ Cada demanda pode começar como uma Task, uma SPEC ou um PRD. Em qualquer entrad
 
 O Codex permanece como ambiente de execução, enquanto o ZAIP-AIOS acrescenta organização, governança e visibilidade ao ciclo de desenvolvimento. Pelo Dashboard, é possível acompanhar o avanço das entregas, suas dependências, bloqueios e resultados.
 
-O sistema utiliza os tokens disponíveis na conta ChatGPT/Codex e apresenta, no Dashboard, uma estimativa do custo equivalente de API para fins de comparação e planejamento.
+Quando executado com a conta ChatGPT/Codex, o consumo segue as condições dessa conta. O Dashboard apresenta, quando há telemetria e preço compatível, uma estimativa de custo equivalente de API para comparação e planejamento; outros providers podem ter modalidades próprias de cobrança.
 
 ## Dashboard Local
 
@@ -1586,7 +1751,7 @@ Os registros Git-native continuam sendo a fonte oficial. Tudo o que aparece nas
 
 Os registros ZAIP canônicos permanecem na estrutura padrão em \`.agents/records\`. Para acelerar consultas e visualizações, o Dashboard reconstrói um SQLite descartável como *read model*. Esse arquivo não é fonte de verdade nem armazenamento canônico: é apenas uma projeção local reconstruível.
 
-Não é preciso instalar ou abrir servidor SQLite, DBeaver ou banco externo. O Node.js 22 já inclui \`node:sqlite\` para esse uso local.
+Não é preciso instalar servidor SQLite, DBeaver ou banco externo. O runtime usa \`node:sqlite\` e mantém a projeção em \`.local/dashboard-sqlite/read-model.sqlite\`. Abrir ou atualizar o Dashboard não autoriza reconciliação global de Runs: essa operação é separada e exige confirmação.
 
 
 ### Kanban
@@ -1715,7 +1880,13 @@ Tempo, tokens e custo são agregados sempre que essas informações estiverem di
 
 Qualidade faz parte da definição de pronto. Cada entrega combina testes, revisão e checks proporcionais ao seu risco, com comprovação objetiva dos Critérios de Aceite.
 
-As Evidence conectam o resultado observado à Task, à Change e à Execution que o produziram. Assim, é possível consultar o que foi validado, por qual método e em qual contexto, sem perder a linha de raciocínio da entrega.
+As Evidence conectam validações aprovadas à Task, Change, Execution, Run, Critérios de Aceite e candidato. O [guia de revisão](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explica como registrar o procedimento realmente executado e seu resultado.
+
+O contrato atual acrescenta observações \`confirmed\`, \`limited\`, \`pending\`, \`failed\` e \`not_applicable\`, sem substituir Validation/Evidence V2. A CLI valida estrutura e vínculos; não executa o comando declarado, não examina imagens e não consulta serviços automaticamente. Prova técnica não equivale a prova visual, integração real ou produção. Observações isoladas ou pendentes não aprovam uma entrega.
+
+Novos registros de Validation, Evidence, Observation e eventos de Run rejeitam padrões conhecidos de credenciais antes da persistência, sem repetir o valor sensível no erro. Use locators e resultados sanitizados; a proteção não certifica que um texto está livre de todo segredo ou dado pessoal. Históricos continuam legíveis e não são reescritos automaticamente.
+
+Para reduzir ciclos sem reduzir qualidade, escolha cedo o cenário que pode revelar uma direção errada. Repita após uma mudança concreta ou resultado que exija correção, não apenas porque o relógio avançou. A indisponibilidade da mesma ferramenta tem fallback finito e pendência explícita; a suficiência da prova continua sendo responsabilidade do executor/revisor. Consulte o [contrato canônico de prova observável](.agents/skills/zaip-skill-change/references/observable-evidence.md).
 
 Tests, reviews, checks e Evidence tornam a evolução do projeto mais previsível: elevam a confiança nas mudanças, facilitam revisões e mantêm decisões, validações e aprimoramentos plenamente rastreáveis.
 
@@ -1767,6 +1938,8 @@ O comando \`zaip cost cohort --input <arquivo.json> --json\` calcula coortes com
 
 ## Comparação com os principais frameworks concorrentes
 
+Esta seção preserva um recorte histórico, não uma pesquisa de mercado atualizada nem certificação de produção. As notas abaixo não substituem a qualificação do candidato atual e não foram recalculadas nesta revisão documental.
+
 Este recorte usa uma auditoria comparativa, consolidada em 6 de agosto de 2026, e posiciona cada produto a partir dos sinais encontrados em código, configuração, arquitetura, testes e documentação. A metodologia reúne dez critérios com o mesmo peso: cada tópico recebe de 0 a 10 pontos e a nota final, de 0 a 100, é a soma direta desses resultados. Na escala adotada, 9–10 indica uma referência clara no critério; 7–8, uma proposta forte e competitiva; 5–6, uma capacidade relevante ainda parcial; e 0–4, pouca evidência ou baixa ênfase no recorte analisado. A matriz detalhada torna a composição das notas transparente e permite atualizá-las conforme os produtos evoluem.
 
 | Produto | Nota /100 | Justificativa da nota | Posicionamento competitivo |
@@ -1833,7 +2006,7 @@ Os conceitos abaixo formam o vocabulário técnico usado para ligar intenção,
 | **Change** | Narrativa viva de uma mudança planejada e executada: decisões, arquivos afetados, desvios, testes, evidências, rollout, rollback e resultado. |
 | **Task** | Menor unidade executável, com objetivo, risco, prioridade, dependências, write scopes e critérios de aceite. |
 | **DAG** | Grafo acíclico que ordena dependências, identifica paralelismo seguro e impede execução fora da sequência necessária. |
-| **Execution** | Uma unidade idempotente por turno: \`interaction\` registra conversa sem Task artificial; \`delivery\` materializa e coordena trabalho, Changes e DAG quando aplicável. |
+| **Execution** | Unidade de interação ou entrega, correlacionada ao turno observável: \`interaction\` registra conversa/definição; \`delivery\` coordena trabalho materializado. A idempotência depende da identidade observada do turno; continuação pode reutilizar a delivery vigente. |
 | **Run / Sub-Run** | Run de captura ou do agente orquestrador possui \`parent_run_id: null\`; Sub-Run é cada chamada de subagente relacionada por \`parent_run_id\`. Novos registros usam \`run_role: intake|orchestrator|subagent\`; cada chamada fixa modelo e effort e agrega suas Calls internas. |
 | **Decision** | Decisão humana ou da IA com contexto, alternativa escolhida, motivo, consequências e possibilidade de rollback. |
 | **Evidence** | Prova associada à Task e aos Critérios de Aceite: teste, diff, review, check, relatório ou resultado reproduzível. |
@@ -1850,9 +2023,9 @@ Essa progressão permite começar de forma simples e acrescentar planejamento ap
 
 **Políticas técnicas de execução e assurance**
 
-Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex. Para executar trabalho de produto mais rápido, o único caminho suportado é uma Task-first realmente independente com Fast selecionado manualmente no Codex. Executions originadas por SPEC ou PRD usam sempre velocidade \`standard\`, inclusive em todas as Tasks descendentes; o ZAIP não oferece skill, hook ou override para mudar essa velocidade.
+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).
 
-Em todos os casos, cada turno observável resolve para uma Execution. \`prepare\` valida e congela o plano antes da mutação; \`execute\` reutiliza a Execution \`delivery\` para materializar Change e Task; cada Execution usa uma Run raiz do orquestrador, ao menos um Sub-Run executor elegível e o \`zaip-agent-finalizer\` obrigatório por último. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
+O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction com descendentes exigem executor elegível e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
 
 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).
 
@@ -1861,6 +2034,8 @@ A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo
 
 O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm o código sustentável, distribuem apenas o contexto necessário e exigem comprovação proporcional ao risco.
 
+O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout optou por \`autonomous\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
+
 - **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
 - **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
 - **Modularização e organização do código:** pastas, arquivos, módulos e componentes são estruturados por domínio e responsabilidade, com fronteiras explícitas, alta coesão e baixo acoplamento para facilitar navegação, manutenção, testes e evolução do software.
@@ -1870,7 +2045,7 @@ O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm
 - **Histórico recuperável:** decisões, mudanças, tentativas, falhas, retries, reparos e rollback permanecem vinculados, permitindo pausar, retomar e auditar o trabalho.
 - **Observabilidade honesta:** tokens, custo, tempo, cobertura e performance são medidos por escopo; ausência de telemetria permanece explícita em vez de gerar precisão fictícia.
 
-Toda mensagem do usuário cria uma Execution e uma Run de captura. Perguntas, feedbacks e análises read-only usam Execution \`interaction\`, sem Task ou Change artificial. A criação ou o refinamento explícito de PRD/SPEC \`draft\` é a exceção de definição: a própria \`interaction\` pode persistir esses macros e o PreparedPlan sem Task, Change ou Execution \`delivery\`. Fora dessa exceção, pedido avulso direto materializa e inicia a mesma Execution \`delivery\`, Task, Change e Run raiz de orquestração antes da primeira mutação; somente preparação explicitamente solicitada pode parar em Pronto para Executar. PRD \`draft\` ocupa Definição e SPEC \`draft\` ocupa Planejamento; Tasks nunca ocupam essas colunas.
+O intake captura uma vez por turno observável e reutiliza o foco válido em continuações; publicação puramente Git não cria lifecycle. Perguntas, feedbacks e análises read-only usam Execution \`interaction\`, sem Task ou Change artificial. A criação/refino explícito de PRD/SPEC \`draft\` pode persistir esses macros e o PreparedPlan em interaction, sem delivery. Fora dessa exceção, uma edição avulsa independente materializa e inicia Task, Change, delivery e Run antes da primeira mutação; preparação explicitamente solicitada pode parar em Pronto para Executar. PRD \`draft\` ocupa Definição e SPEC \`draft\` ocupa Planejamento; Tasks nunca ocupam essas colunas.
 
 ## Graph Engineering e Loop Engineering
 
@@ -1884,7 +2059,7 @@ O **Loop Engineering** orienta o que acontece quando a primeira tentativa não s
 
 ### Fluxo resumido
 
-O caminho normal é deliberadamente curto: **entrada → Dave → executor por capacidade → Nanda (review) → Gui (finalização)**. Todos os agentes são filhos da mesma orquestração; a sequência não significa que um trabalhador chama o próximo.
+Um fluxo de entrega com revisão independente é **entrada → Dave → executor por capacidade → Nanda (review) → Gui (finalização)**. A revisão deve atender ao perfil de assurance; não é obrigatório expandir todo trabalho para o mesmo conjunto de agentes. Todos os filhos são coordenados pela orquestração; a sequência não significa que um trabalhador chama o próximo.
 
 Os cenários completos ficam no [guia de fluxos e roteamento](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md), em texto estável para o GitHub.
 
@@ -1938,11 +2113,12 @@ As seções seguintes preservam os contratos necessários para instalação avan
 │   ├── tasks/<ano>/<mês>/
 │   ├── executions/<ano>/<mês>/
 │   ├── runs/<ano>/<mês>/
-│   ├── lifecycle/{manifest.json,summary.json,entity-snapshot.json}/
+│   ├── lifecycle/                    # manifests, índices e projeções
 │   └── telemetry/<ano>/<mês>/writers/<writer-id>/{manifest.json,chunks/}
 ├── rules/
-│   ├── zaip/{core,workflow,architecture,security,context,evolution}.md
-│   └── project/            # Rules personalizadas deste projeto
+│   ├── core.md
+│   ├── workflow.md
+│   └── *.md                          # Rules gerenciadas e locais, layout plano
 ├── requirements/
 ├── skills/
 ├── tools/
@@ -1955,20 +2131,22 @@ As seções seguintes preservam os contratos necessários para instalação avan
 ├── zaip-aios/
 │   ├── INDEX.md
 │   └── guides/
+├── runtime/
+│   └── bin/zaip.mjs                  # CLI instalado e metadados de distribuição
 ├── .env.example
 └── .gitignore
-.agents/runtime/
-└── local/                               # estado local ignorado pelo Git
-    ├── claims/                          # claims atômicos de lifecycle
-    └── codex-telemetry-spool/v1/        # captura sanitizada, privada e recuperável
+.local/                              # na raiz do workspace; ignorado pelo Git
+├── claims/                          # claims atômicos de lifecycle
+├── codex-telemetry-spool/v1/          # captura sanitizada, privada e recuperável
+└── dashboard-sqlite/                 # read model descartável
 \`\`\`
 
-As pastas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` são áreas de artefatos de negócio criadas sob demanda; por isso, não existem neste checkout até que um trabalho desses domínios precise registrá-los.
+As pastas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` são áreas de artefatos de negócio criadas sob demanda. A existência e o conteúdo variam por projeto; não é necessário criar pastas vazias.
 
 | Caminho | Responsabilidade |
 | --- | --- |
 | \`config/\` | Configuração do projeto, perfis de clientes e agentes, maturidade de capacidades e lock de integridade dos arquivos gerenciados. |
-| \`dashboard/\` | Dashboard operacional local com Kanban, custos, tempo, tokens e grafo de rastreabilidade; lê os manifests de lifecycle e os detalhes canônicos por ID, sem criar uma verdade paralela nem reconstruir arquivos locais. |
+| \`dashboard/\` | Dashboard operacional local com Kanban, custos, tempo, tokens e rastreabilidade; consulta projeções reconstruíveis dos registros canônicos, incluindo SQLite. |
 | \`design/\` | Design system do ZAIP, tokens visuais, catálogo de componentes e launcher local de inspeção. |
 | \`branding/\` | Artefatos de negócio de branding, como Brandbook, plataforma de marca e governança de identidade; é criada sob demanda. |
 | \`marketing/\` | Artefatos de negócio de estratégia, campanhas, conteúdo e ativos de marketing; é criada sob demanda. |
@@ -1980,11 +2158,11 @@ As pastas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` são áreas de
 | \`skills/\` | Workflows reutilizáveis que transformam conversas em Requirements, Tasks, SPECs e PRDs e orientam execução, revisão, segurança, custos, contexto e ferramentas. |
 | \`tools/\` | Catálogo de MCPs e APIs, políticas de aprovação e segredos, perfis de ativação, doctors e servidores locais gerados de maneira auditável. |
 | \`zaip-aios/\` | Handbook operacional com índice de baixo custo de contexto e guias de instalação, execução, revisão, agentes, custos, segurança e integração com Codex. |
-| \`.local/\` | Estado específico da máquina, como claims de lifecycle, writer ID e spool sanitizado de telemetria; fica fora do Git e não é uma fonte do dashboard. Segredos nunca devem ser gravados nos registros. |
+| \`../.local/\` | Diretório na raiz do workspace com claims, writer ID, spool sanitizado e SQLite descartável; fica fora do Git. O Dashboard consulta a projeção, mas os registros canônicos permanecem em \`records/\`. |
 
 \`framework.lock.yaml\` é a referência mecânica dos arquivos administrados pela distribuição, enquanto \`project.yaml\` descreve o projeto consumidor. Rules presentes no lock pertencem ao framework e podem ser atualizadas pelo setup; Rules ausentes do lock são locais e devem ser preservadas. O agente começa por \`rules/core.md\`, usa os manifests canônicos em \`records/lifecycle\` para descoberta e só abre um registro histórico quando já possui seu ID explícito.
 
-O código canônico do dashboard vive em \`.agents/dashboard\`, separado das aplicações do produto. Ele possui somente \`apps/frontend\`; o servidor loopback read-only é uma implementação técnica em \`packages/local-runtime\`, e não um \`apps/backend\`. Os módulos \`operations\`, \`cost-monitor\` e \`traceability\` formam os read models em memória a partir dos manifests canônicos. Os launchers \`zaip-dashboard-windows.exe\`, \`zaip-dashboard-linux.sh\` e \`zaip-dashboard-mac.command\` permanecem diretamente em \`.agents/dashboard\` e também são instalados pelo CLI oficial.
+O código canônico do Dashboard vive em \`.agents/dashboard\`, separado das aplicações do produto. Ele possui somente \`apps/frontend\`; o servidor loopback está em \`packages/local-runtime\`, não em \`apps/backend\`. Os módulos \`operations\`, \`cost-monitor\` e \`traceability\` consomem read models derivados, com consultas SQLite no runtime atual e caminhos de compatibilidade em memória. A API é predominantemente de leitura, com endpoints controlados para ações como configuração, prioridade, refresh e reconciliação explícita; isso não é permissão para alterações arbitrárias. Os launchers Windows, Linux e macOS ficam diretamente em \`.agents/dashboard\`; sua presença no template não comprova execução nos três ambientes.
 
 
 ## Arquitetura das aplicações
@@ -2005,7 +2183,7 @@ tests/e2e/          # fluxos que atravessam aplicações
 
 A direção de dependência é \`apps -> modules -> packages\`. Esta arquitetura descreve exclusivamente o código das aplicações do produto consumidor, não o dashboard ZAIP nem os domínios de negócio. As áreas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` ficam em \`.agents\` como pastas de artefatos de negócio criadas sob demanda; elas não são pastas de aplicação. \`apps/site\` nunca importa o dashboard, não lê \`.agents\` e não depende de implementação privada do backend. Pastas de superfícies ausentes não precisam ser criadas vazias. Testes unitários ficam junto do código; jornadas cross-app ficam em \`tests/e2e\`.
 
-Arquivos-fonte com 401–800 linhas geram warning e arquivos com 801 ou mais linhas geram erro. O gate ignora código gerado, distribuição, vendor, dados e lockfiles. Exceções temporárias cobrem somente legado não-dashboard, têm limite congelado, responsável, motivo e validade.
+Arquivos-fonte com 401–800 linhas geram warning e arquivos com 801 ou mais linhas geram erro, salvo exceções explícitas. O gate ignora código gerado, distribuição, vendor, dados e lockfiles. A lista em [source-size-baseline.json](scripts/source-size-baseline.json) inclui legado de pacotes e Dashboard, com limite congelado, responsável, motivo e validade; isso não autoriza aumentar os limites para ocultar crescimento.
 
 
 ## Desenvolvimento do framework
@@ -2062,6 +2240,10 @@ pnpm build
 
 Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\` executa a pipeline completa do repositório, incluindo gates adicionais de ferramentas, contratos, geração, workspace, paridade de runtime e testes de release. Essa pipeline apenas valida o lock; se um arquivo gerenciado tiver sido alterado intencionalmente, o sync deve acontecer antes.
 
+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 mesma versão; 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. O framework mantém seu cohort \`1.3.0\`, separado da versão pública. 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.
 
 
@@ -2102,7 +2284,7 @@ Os dois perfis mantêm camadas compensatórias que reduzem risco, mas elas não
 isolamento nativo oferecido pelo perfil restrito:
 
 - carregamento da política somente em repositório confiável e escopo explícito em \`AGENTS.md\`;
-- hook \`PreToolUse\`, que bloqueia escapes do repositório, referências diretas a segredos, Git destrutivo, force push, mutações de OS, ACL, persistência, elevação e banco destrutivo;
+- hook \`PreToolUse\`, com verificações para classes conhecidas de escapes, referências a segredos, Git destrutivo, force push, mutações de OS, ACL, persistência, elevação e banco destrutivo, quando o host efetivamente o executa;
 - regras Codex \`forbidden\`, instruções e skills que exigem autoridade explícita e limitam o escopo de cada operação;
 - deploy GitHub delimitado por pedido explícito, preflight, branch/remoto definidos e identidade SSH escopada;
 - proteção para que tokens, chaves privadas, credenciais e valores de ambiente não sejam impressos, registrados ou incluídos em commits;
@@ -2135,7 +2317,7 @@ O repositório versiona esse contrato, mas não instala um relógio em cada clon
 
 O arquivo \`.codex/config.toml\` é uma configuração de projeto carregada pelo Codex somente quando o repositório é confiável. Na configuração atual do ZAIP-AIOS, ele orienta a descoberta de \`AGENTS.md\` e habilita o MCP oficial e read-only da documentação OpenAI, permitindo que o agente consulte informações atuais sobre Codex, modelos, APIs, SDKs e MCP sem depender apenas da memória do modelo. O instalador também disponibiliza a skill ZAIP de descoberta, enquanto o próprio Codex fornece recursos estáveis como shell, subagentes, apps, hooks e busca web conforme a superfície, a conta e as políticas do ambiente.
 
-O navegador integrado não é ativado silenciosamente pelo CLI nem por \`.codex/config.toml\`. No app Codex/ChatGPT para desktop, o plugin Browser permite abrir páginas e aplicações locais, clicar, digitar, inspecionar o estado renderizado, capturar screenshots e verificar visualmente uma implementação, sempre sujeito às permissões de sites e às confirmações de ações sensíveis. O navegador integrado não está disponível no Codex CLI nem na extensão de IDE. Para automação por Playwright ou outro MCP de navegador, \`.agents/tools\` inclui um manifesto opt-in desabilitado por padrão; a implementação precisa ser escolhida, auditada e validada antes da ativação.
+A configuração deste checkout contém entradas habilitadas para plugins de navegador; isso não comprova instalação, disponibilidade nem permissão efetiva no host. Quando o Browser do app estiver disponível, ele pode apoiar navegação, interação e captura real da aplicação, sujeito às permissões e confirmações de ações sensíveis. Não presuma a mesma ferramenta em outra superfície Codex. Para Playwright ou outro MCP, consulte o manifesto e a política em \`.agents/tools\` antes de ativar uma implementação. Falha de captura deve ser registrada como pendência de prova, nunca como validação visual aprovada.
 
 ## Visualização opcional da rastreabilidade no Obsidian