@zaip-ai/cli 6.0.1 → 6.2.0

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

@@ -1,4 +1,4 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{t as r}from"./dashboard-localization-ykDJSpnb.js";var i=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{t as r}from"./dashboard-localization-CqicG5jJ.js";var i=`# Primeiros passos
 
 1. Leia \`.agents/config/project.yaml\` e \`.agents/rules/core.md\`.
 2. Consulte \`.agents/records/lifecycle/\` para descobrir o estado atual pelos manifests canônicos.
@@ -798,7 +798,7 @@ Consulte [instalação detalhada](20-instalacao-detalhada.md) e
 3. Rode doctor, validadores focados e \`git diff --check\`.
 4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.
 5. Compare \`manifest.json\`, \`summary.json\`, índices e chunks de \`records/lifecycle\`, sem varrer records.
-6. Corrija a causa, repita a reproducao e depois os gates completos.
+6. Corrija a causa e repita a reprodução e as verificações afetadas. Execute gates completos somente quando o impacto ou a qualificação final exigir; preserve provas ainda válidas do mesmo candidato e ambiente.
 
 Se uma Task estiver presa em executing/verifying, use o popup Reconciliar para o backlog global. O reparo aceita \`task_complete\` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. A v4 deve conciliar a tentativa **atual** no fechamento ou próximo evento Codex da mesma Task, sem varredura global automática na abertura do dashboard. Se o host parou e não houve novo evento, relate a pendência em vez de dizer que ela ainda está executando.
 
@@ -820,6 +820,11 @@ Se “finalizar o documento” tentou entregar um PRD \`draft\`, confira adapter
 | Responsável já fechado sem decisão | Recuperação autorizada/nova tentativa; reconciliação repetida não cria aprovação |
 | Perfil Essencial tentou Astra automático | Rejeite a seleção; não trate fallback/herança como autorização |
 | Snapshot de Runs incompleto | Rebuild explícito dos manifests; não invente campos ou faça varredura JSONL oculta na query |
+| \`executor_missing\` antes do Gui | Consulte \`run closure --id RUN-ID --preflight --json\`; executor iniciado/falho não satisfaz conclusão. Preserve \`blocked\`/\`failed\` quando cabível; não crie executor cerimonial. |
+| Recuperação acusa outro dono do turno | Confira recibo e identidade exatos. A exceção de observação passiva exige a forma canônica do guia 16; dono operacional continua bloqueando. |
+| Cache sem reaproveitamento | Inspecione \`--plan\` no rapid check do mantenedor e as razões por grupo. \`identity-changed\` difere de \`no-proof\`; não retire SHA, assinatura ou verificação de dependências para forçar um hit. |
+| \`run finish --view compact\` demora | Compacto descreve a saída, não o custo interno. Examine o processo iniciado, telemetria, locks e projeções; não dispare fechamento concorrente nem atribua a causa sem medição. |
+| Release GitHub existe, npm ainda não | Acompanhe o publicador até resultado terminal e confira versão/integridade no registry. Preserve tag/TGZ; reparo de controle exige a rota autenticada, não reempacotamento da mesma versão. |
 
 A tolerância de dez minutos para Run órfã no reparo manual não é prazo de
 desistência de Task em atividade. Um timeout operacional também não comprova
@@ -1000,6 +1005,48 @@ uma autorização humana apenas no texto não substitui o contrato capturado.
 No fluxo nativo atual, editar produto exige posse central de escrita: \`zaip task workspace TASK-ID --run RUN-ID\`. A posse usa a raiz Git comum entre chats e worktrees e valida o dono e a Run; indisponibilidade bloqueia edição. Registros canônicos de lifecycle têm bootstrap próprio. Mensagens entre chats coordenam, mas não substituem Task, Run e claim. Alterações de produto sem proveniência única no checkout compartilhado bloqueiam transferência e limpeza automática até reconciliação.
 
 Para checkout isolado terminal, \`zaip task workspace TASK-ID --run RUN-ID --close\` inventaria arquivos e ignorados, exige integração se a Task concluiu, cria e testa backup em \`.local/backup-branchs\` e \`.local/backup-worktrees\` e só então remove worktree e branch. Ignorados desconhecidos ou backup não recuperável bloqueiam. \`.local\` fica fora do Git; o usuário limpa seus backups manualmente depois de conferi-los.
+
+## Diagnóstico antecipado e respostas compactas
+
+Antes de despachar Gui, consulte \`zaip run closure --id RUN-ID --preflight --json\`.
+\`completion_preflight.completion_allowed\` verifica a autoridade para concluir:
+executor elegível **concluído** ou autorização direta válida desde a captura.
+Executor ausente ou falho retorna \`executor_missing\`. \`blocked_or_failed_allowed\`
+preserva uma avaliação verdadeira de inconclusão; não autoriza \`completed\`.
+\`active_descendant_ids\` e \`finalizer_dispatch_ready\` informam separadamente
+descendentes ativos e se já houve finalizador. Leia os campos em conjunto:
+prontidão de despacho não significa aprovação. \`execution native-next\` também
+fornece esse diagnóstico. O preflight é somente leitura; Evidence, revisão
+aplicável e as barreiras de \`run finalization\`/\`run finish\` continuam exigidas.
+
+\`zaip manifest reconcile --id ID --view compact --json\` e
+\`zaip run finish --id RUN-ID --status completed --view compact --json\` retornam
+resumos explícitos. O primeiro reconcilia a entidade indicada; o segundo só pode
+concluir quando os gates permitirem. O JSON padrão e \`--view full\` preservam
+o contrato anterior. Saída compacta reduz texto, não elimina coleta de telemetria,
+leitura de Runs ou cálculo de reconciliação.
+
+## Recuperação pós-publicação e histórico bloqueado
+
+Use \`task recover-post-publication\` e \`task resume-post-publication\` conforme
+a [skill de fechamento](../../skills/zaip-skill-lifecycle-closure/SKILL.md).
+O recibo autenticado vincula publicação imutável, manutenção concluída,
+autorização, Task/Execution e responsável único. Um avanço posterior do ciclo
+não apaga a publicação anterior: sua linha deve continuar única e conservar o
+SHA. A Task histórica não recebe autorização para editar produto antigo.
+
+Uma raiz observacional passiva pode compartilhar o turno sem ser dona da entrega.
+A exceção exige cliente/thread/turno exatos, forma canônica de observação,
+autor ausente ou compatível, ausência de Task/Change/Execution/Conversation,
+de autorização operacional e de descendentes. Outro responsável real continua
+sendo conflito. Não converta uma Run operacional em observação para liberá-la.
+
+\`task assurance TASK-ID --inherit-applicability-attempt N --run RUN-ID --json\`
+admite herança autenticada na recuperação Task-first, além da rota SPEC;
+preserva plano, critérios, Decisions e hashes e valida o recibo consumido e o
+turno observado. Não fabrica Evidence nova. Tasks bloqueadas por decisão humana
+permanecem bloqueadas até retomada autorizada e comprovada. Testes de interrupção
+e replay não concluem Tasks históricas reais.
 `,b=`# Como o custo é calculado
 
 Cada estimativa de custo começa em tokens de uma chamada LLM capturados por fonte aceita. O dashboard não estima uso ausente: tokens ou custo sem os componentes necessários permanecem indisponíveis. Uma duração estimada é uma derivação identificada por proveniência e não preenche telemetria de uso.
@@ -1032,7 +1079,7 @@ O esforço não possui multiplicador direto de preço. Ele só pode aumentar o c
 ## 4. Converta para a moeda selecionada
 
 O total da chamada é calculado primeiro em USD. Em BRL, a estimativa exige uma cotação identificada; a cotação histórica registrada e a cotação corrente são fontes distintas. Mudar a moeda de exibição nunca altera a telemetria de tokens nem o cálculo em USD.
-`,x='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| Rafa | Tech Lead | `zaip-agent-builder` | `rafa_tech_lead_zaip_agent` | Cria/refina SPECs e executa delivery genérico, inclusive dashboard/local. | Definição técnica ou mudança sem especialista mais específico. | PRD, design central, website, frontend ou backend especializados. | `spec`, `architecture`, `decomposition`, `dashboard`, `local` |\n| Leo | Software Engineer | `zaip-agent-task-executor` | `leo_software_engineer_zaip_agent` | Executa Task genérica delimitada, inclusive dashboard/local, e produz evidência. | Task pronta, autocontida e sem escopo de especialista obrigatório. | Planejamento macro, coordenação ou revisão independente. | `task`, `implementation`, `verification`, `evidence`, `local` |\n| Bia | Product Manager | `zaip-agent-analyst` | `bia_product_manager_zaip_agent` | Cria/refina PRDs e analisa interações sem antecipar Tasks de delivery. | Problema de produto, PRD, descoberta, escopo ou refinamento. | SPEC, implementação, aprovação técnica ou deploy. | `prd`, `product`, `discovery`, `requirements`, `problem` |\n| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Último filho do responsável em delivery ou interaction delegada; não em conversa read-only sem filhos. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |\n| Nanda | Principal Engineer | `zaip-agent-reviewer` | `nanda_principal_engineer_zaip_agent` | Revisa Requirements, diff, testes e evidências sem mutar produto. | Mudança implementada que precisa de revisão independente. | Para implementar a própria correção ou integrar worktrees. | `review`, `findings`, `requirements`, `diff` |\n| Dani | Integration Engineer | `zaip-agent-integrator` | `dani_integration_engineer_zaip_agent` | Integra trabalho revisado e executa gates combinados. | Worktrees ou mudanças independentes já revisadas. | Antes da revisão ou para criar requisitos. | `integration`, `merge`, `combined-gates`, `worktree` |\n| Ana | Quality Auditor | `zaip-agent-auditor` | `ana_quality_auditor_zaip_agent` | Reproduz evidências e emite auditoria independente. | Risco alto, release ou alegação que exige reprodução final. | Implementação, correção ou autoria da evidência. | `audit`, `reproduce`, `release`, `quality` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| Will | Backend Specialist | `zaip-agent-backend` | `will_backend_specialist_zaip_agent` | Implementa backend, APIs, persistência e integrações. | `apps/backend/**`, `modules/**` ou capability de backend. | Frontend, website ou design visual central. | `backend`, `api`, `persistence`, `integration` |\n| Jonny | Website Developer | `zaip-agent-website-developer` | `jonny_website_developer_zaip_agent` | Cria sites/LPs com stack do framework, SEO, GEO e acesso por agentes. | `apps/site/**`, site institucional, LP, SEO, GEO ou Markdown for Agents. | App de produto, backend ou mudança da regra central de design. | `website`, `landing-page`, `seo`, `geo`, `markdown-for-agents`, `agent-readiness` |\n| Manu | Product Designer | `zaip-agent-designer` | `manu_product_designer_zaip_agent` | Governa `DESIGN.md`, design tokens (cor, tipografia, espaçamento e raio), componentes centrais e páginas de catálogo digital. | Regra central de design, Design System, tokens, `design-system` ou `componentes`. | Word, PPT, imagem de marketing ou componente local que apenas consome regras existentes. | `design-system`, `design.md`, `tokens`, `central-components`, `componentes` |\n| Dan | Cloud Engineer | `zaip-agent-cloud-engineer` | `dan_cloud_engineer_zaip_agent` | Projeta e valida infraestrutura cloud declarada. | Infraestrutura cloud, provisionamento, containers, Terraform ou Docker. | Implementação de aplicação, deploy ou infraestrutura fora do escopo declarado. | `cloud`, `terraform`, `docker`, `provisioning` |\n| Luiz | Security Auditor | `zaip-agent-security-auditor` | `luiz_security_auditor_zaip_agent` | Audita segurança de forma independente e somente leitura. | Auditoria de segurança, mudança sensível ou release que exige avaliação independente. | Implementação, autoria de remediação ou deploy. | `security`, `audit`, `risk`, `release` |\n| Lucia | Marketing Analyst | `zaip-agent-marketing-analyst` | `lucia_marketing_analyst_zaip_agent` | Planeja marketing, copy, campanhas e briefs de imagem com evidência. | Estratégia de marketing, campanha, copy de landing page ou brief de imagem. | Implementação de produto, backend ou governança central de design. | `marketing`, `copy`, `campaign`, `image-brief` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO orquestrador mantém a Run raiz e cada Run delegada separadas na observabilidade. Duração, tokens e custo só são agregados quando observados ou reconciliados; ausência continua indisponível, nunca zero.\n\nNa v4, isso continua verdadeiro para records, API e cálculos. Apenas os\ncards/células numéricas do Dashboard carregado exibem `0` com cobertura\n“sem medição”; o catálogo não autoriza registrar zero observado fictício.\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-6-sol` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) usa `gpt-6-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) usa `gpt-6-sol`/`high` para auditoria de segurança explícita.\n\n## Dashboard e segurança operacional\n\nA tela **Configurações > Catálogo de agentes** apresenta a persona e mantém a identidade técnica somente leitura. Ao salvar, o runtime valida o catálogo, deriva o único nickname, sincroniza adapters e reverte a escrita se a paridade falhar. Agentes de framework permitem alteração de persona e preferências de modelo/effort; propósito, capacidades e identidade técnica continuam protegidos.\n\n## Preset e configuração efetivamente executada\n\nDefaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,\no preset e a seleção final do despacho gerenciado também são validados:\nEssencial veda Astra automático e não herda a exceção manual do principal.\nInforme ao usuário a delegação necessária e a possibilidade de modelos\ndiferentes. Mantenha indisponível o que o host não informou.\nConsulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).\n',S=`# Assurance adaptativa e perfis de autonomia
+`,x='# Catálogo de agentes\n\n`.agents/config/agents/catalog.yaml` é a única fonte canônica dos agentes ZAIP. Adapters Codex e Claude são projeções geradas: depois de qualquer alteração no catálogo, execute `node packages/cli/dist/index.js adapters build` e valide com `node packages/cli/dist/index.js adapters check --json`.\n\n## Identidade técnica e persona\n\nCada agente possui identidade técnica estável: `id` e `codex_name`. A persona editável é `persona.nome` e `persona.cargo`, ambos em snake_case. Ela produz, sem crescimento entre invocações, o `codex_task_name` e exatamente um candidato idêntico:\n\n```text\ncodex_task_name = "{nome}_{cargo}_zaip_agent"\nnickname_candidates = ["{nome}_{cargo}_zaip_agent"]\n```\n\nO schema e a API rejeitam um task name ou nickname manual, múltiplos candidatos ou valores que não sejam a derivação acima. O Dashboard omite esses campos no payload e envia somente a persona; uma edição de persona preserva a identidade técnica. Snapshots de Run usam a identidade de catálogo observada e não inventam persona.\n\n## Agentes canônicos\n\n| person | função | zaip-agent | codex_task_name | descrição resumida da função | quando chamar | quando não chamar | palavras-chave importantes para acionar agent |\n| --- | --- | --- | --- | --- | --- | --- |\n| Dave | Product Owner | `zaip-agent-orchestrator` | `dave_product_owner_zaip_agent` | Organiza a entrega, resolve a DAG e delega com menor privilégio. | Trabalho executável com mais de uma etapa ou especialista. | Implementação direta, revisão ou aprovação. | `orchestration`, `dag`, `delegation`, `lifecycle` |\n| Rafa | Tech Lead | `zaip-agent-builder` | `rafa_tech_lead_zaip_agent` | Cria/refina SPECs e executa delivery genérico, inclusive dashboard/local. | Definição técnica ou mudança sem especialista mais específico. | PRD, design central, website, frontend ou backend especializados. | `spec`, `architecture`, `decomposition`, `dashboard`, `local` |\n| Leo | Software Engineer | `zaip-agent-task-executor` | `leo_software_engineer_zaip_agent` | Executa Task genérica delimitada, inclusive dashboard/local, e produz evidência. | Task pronta, autocontida e sem escopo de especialista obrigatório. | Planejamento macro, coordenação ou revisão independente. | `task`, `implementation`, `verification`, `evidence`, `local` |\n| Bia | Product Manager | `zaip-agent-analyst` | `bia_product_manager_zaip_agent` | Cria/refina PRDs e analisa interações sem antecipar Tasks de delivery. | Problema de produto, PRD, descoberta, escopo ou refinamento. | SPEC, implementação, aprovação técnica ou deploy. | `prd`, `product`, `discovery`, `requirements`, `problem` |\n| Gui | Quality Assurance Lead | `zaip-agent-finalizer` | `gui_quality_assurance_lead_zaip_agent` | Avalia a barreira final e emite somente o resultado terminal permitido. | Último filho do responsável em delivery ou interaction delegada; não em conversa read-only sem filhos. | Antes de executor/revisor terminar ou para corrigir código. | `finalization`, `terminal`, `barrier`, `task-finalizer` |\n| Nanda | Principal Engineer | `zaip-agent-reviewer` | `nanda_principal_engineer_zaip_agent` | Revisa Requirements, diff, testes e evidências sem mutar produto. | Mudança implementada que precisa de revisão independente. | Para implementar a própria correção ou integrar worktrees. | `review`, `findings`, `requirements`, `diff` |\n| Dani | Integration Engineer | `zaip-agent-integrator` | `dani_integration_engineer_zaip_agent` | Integra trabalho revisado e executa gates combinados. | Worktrees ou mudanças independentes já revisadas. | Antes da revisão ou para criar requisitos. | `integration`, `merge`, `combined-gates`, `worktree` |\n| Ana | Quality Auditor | `zaip-agent-auditor` | `ana_quality_auditor_zaip_agent` | Reproduz evidências e emite auditoria independente. | Risco alto, release ou alegação que exige reprodução final. | Implementação, correção ou autoria da evidência. | `audit`, `reproduce`, `release`, `quality` |\n| Lia | Technical Writer | `zaip-agent-writer` | `lia_technical_writer_zaip_agent` | Produz resumo fiel, análise de transcrição com timestamps e documentação grounded em fontes. | Resumo delimitado, transcrição timestampada ou documentação com fontes declaradas. | Pesquisa sem fontes, decisão de produto ou afirmações não suportadas. | `summary`, `transcript`, `timestamps`, `source-grounding`, `documentation` |\n| Gabi | Data Analyst | `zaip-agent-data-analyst` | `gabi_data_analyst_zaip_agent` | Analisa datasets delimitados com método, incerteza e reprodução. | Métricas, dados estruturados ou diagnóstico quantitativo. | Sem dados, para implementar produto ou editar dashboard. | `data`, `metrics`, `analysis`, `dataset` |\n| Tati | Refactoring Specialist | `zaip-agent-refactoring-specialist` | `tati_refactoring_specialist_zaip_agent` | Planeja e executa refactors, migrações e modularização com inventário, mapa, slices reversíveis e gates. | Refactor, migração, arquitetura, modularização ou inventário de código. | Mudança pontual sem refactor, UI central de design ou deploy. | `refactor`, `migration`, `modularization`, `inventory`, `refactor-map`, `rollback` |\n| Doug | Frontend Specialist | `zaip-agent-frontend` | `doug_frontend_specialist_zaip_agent` | Implementa somente `apps/frontend/**`, acessibilidade e integração conforme `DESIGN.md`. | `apps/frontend/**` ou capability explícita de frontend. | Dashboard/local, website institucional, backend ou regra central de design. | `frontend`, `ui`, `accessibility`, `visual-contract` |\n| Will | Backend Specialist | `zaip-agent-backend` | `will_backend_specialist_zaip_agent` | Implementa backend, APIs, persistência e integrações. | `apps/backend/**`, `modules/**` ou capability de backend. | Frontend, website ou design visual central. | `backend`, `api`, `persistence`, `integration` |\n| Jonny | Website Developer | `zaip-agent-website-developer` | `jonny_website_developer_zaip_agent` | Cria sites/LPs com stack do framework, SEO, GEO e acesso por agentes. | `apps/site/**`, site institucional, LP, SEO, GEO ou Markdown for Agents. | App de produto, backend ou mudança da regra central de design. | `website`, `landing-page`, `seo`, `geo`, `markdown-for-agents`, `agent-readiness` |\n| Manu | Product Designer | `zaip-agent-designer` | `manu_product_designer_zaip_agent` | Governa `DESIGN.md`, design tokens (cor, tipografia, espaçamento e raio), componentes centrais e páginas de catálogo digital. | Regra central de design, Design System, tokens, `design-system` ou `componentes`. | Word, PPT, imagem de marketing ou componente local que apenas consome regras existentes. | `design-system`, `design.md`, `tokens`, `central-components`, `componentes` |\n| Dan | Cloud Engineer | `zaip-agent-cloud-engineer` | `dan_cloud_engineer_zaip_agent` | Projeta e valida infraestrutura cloud declarada. | Infraestrutura cloud, provisionamento, containers, Terraform ou Docker. | Implementação de aplicação, deploy ou infraestrutura fora do escopo declarado. | `cloud`, `terraform`, `docker`, `provisioning` |\n| Luiz | Security Auditor | `zaip-agent-security-auditor` | `luiz_security_auditor_zaip_agent` | Audita segurança de forma independente e somente leitura. | Auditoria de segurança, mudança sensível ou release que exige avaliação independente. | Implementação, autoria de remediação ou deploy. | `security`, `audit`, `risk`, `release` |\n| Lucia | Marketing Analyst | `zaip-agent-marketing-analyst` | `lucia_marketing_analyst_zaip_agent` | Planeja marketing, copy, campanhas e briefs de imagem com evidência. | Estratégia de marketing, campanha, copy de landing page ou brief de imagem. | Implementação de produto, backend ou governança central de design. | `marketing`, `copy`, `campaign`, `image-brief` |\n| Sarah | Branding Specialist | `zaip-agent-brand-strategist` | `sarah_branding_specialist_zaip_agent` | Define e governa plataforma de marca, Brandbook, posicionamento, arquétipos, diferencial semântico e arquitetura de marca com evidências. | Estratégia ou governança de marca, Brandbook, posicionamento, arquétipos, arquitetura de marca ou consistência de identidade como decisão principal. | Aplicação rotineira de marca aprovada, campanha, script comercial, análise quantitativa bruta ou documento geral sem decisão de marca. | `branding`, `brandbook`, `positioning`, `archetypes`, `semantic-differential`, `brand-architecture` |\n| Robert | Growth Strategist | `zaip-agent-growth-strategist` | `robert_growth_strategist_zaip_agent` | Orienta estratégia de crescimento, RevOps, experimentos, receita, custos e recomendações executivas baseadas em dados. | Estratégia de negócio, Growth, RevOps, modelo de negócio, priorização de portfólio ou impacto financeiro como decisão principal. | Campanha ou conteúdo, Brandbook, playbook comercial, validação quantitativa bruta ou ato comercial externo. | `growth`, `revops`, `experimentation`, `revenue`, `cost-optimization`, `business-strategy` |\n| Aaron | Sales Specialist | `zaip-agent-sales-specialist` | `aaron_sales_specialist_zaip_agent` | Cria processos, playbooks, qualificação, scripts, enablement e handoffs comerciais internos. | Metodologia comercial, qualificação, negociação preparada, processo SDR/closer, script, playbook ou handoff de pipeline. | Estratégia de Growth/RevOps, campanha ou copy de marketing, governança de marca, análise bruta de dados, política jurídica ou ato comercial externo. | `sales`, `qualification`, `sales-playbook`, `sales-script`, `sdr`, `closer`, `pipeline-handoff` |\n| Clara | Operations Generalist | `zaip-agent-general-operations` | `clara_operations_generalist_zaip_agent` | Executa artefatos operacionais delimitados fora de escopos especialistas: documentos, apresentações, planilhas, processos e comparativos. | Documento, apresentação, planilha, processo ou pesquisa comparativa sem capability especialista obrigatória. | Produto, design-system, marketing, dados, segurança, cloud, jurídico vinculante ou ato externo. | `operations`, `document`, `presentation`, `spreadsheet`, `process`, `comparison` |\n| Renata | Governance Compliance Specialist | `zaip-agent-governance-compliance` | `renata_governance_compliance_specialist_zaip_agent` | Prepara artefatos internos não vinculantes de RH, jurídico operacional, política, privacidade, fornecedores e risco. | Minuta, checklist, matriz de risco ou pacote interno de aprovação sem ato externo. | Parecer jurídico vinculante, assinatura, representação, protocolo, contratação ou decisão humana. | `governance`, `compliance`, `hr`, `legal-operations`, `privacy`, `vendor`, `risk` |\n\n## Squads organizacionais\n\nO catálogo contém 23 agentes agrupados visualmente em seis squads: **Product** (3), **Admin & Operations** (3), **Development** (6), **Delivery Assurance** (4), **Infra & Security** (2) e **Growth — Sales, Marketing and Branding** (5). A soma é 23.\n\nOs squads facilitam a leitura organizacional e a colaboração humana. Eles não são uma fonte de roteamento: `selectAgentForWork` continua a escolher o agente exclusivamente pelas capabilities mandatórias, escopos explícitos, prioridade e ID; cada agente conserva seus write scopes e permissões.\n\n## Roteamento determinístico\n\n`selectAgentForWork` deriva uma capacidade mandatória a partir de escopos explícitos antes de aplicar a seleção ordenada por prioridade e ID.\n\n- `.agents/design/*`, `.agents/design/**`, `DESIGN.md`, `tokens.json`, `apps/catalog/**` ou capability explícita de Design System/tokens/componentes/páginas seleciona Manu. Manu é a regra visual central; Doug somente a consome em `apps/frontend/**`.\n- `apps/site/**` ou capability explícita `website-delivery`, SEO, GEO, Markdown for Agents ou Agent Readiness seleciona Jonny.\n- `apps/frontend/**` seleciona Doug quando a capability é frontend; `apps/backend/**` e `modules/**` selecionam Will quando a capability é backend.\n- Capabilities de governança, RH, jurídico operacional, políticas, privacidade, fornecedores ou riscos selecionam Renata. Ela prepara o pacote revisável e a ação humana necessária, mas não executa ato vinculante ou externo.\n- Capabilities de plataforma ou governança de marca, Brandbook, posicionamento, arquitetura de marca, arquétipos ou diferencial semântico selecionam Sarah. Ela governa a identidade e encaminha aplicação de design system para Manu e ativação de marketing para Lucia.\n- Capabilities de estratégia de Growth, RevOps, experimentação, receita, custo, funil, unit economics ou recomendação executiva selecionam Robert. Dados quantitativos delimitados continuam com Gabi, e processos comerciais internos com Aaron.\n- Capabilities de metodologia comercial, qualificação, playbooks, scripts, SDR, closer ou handoff de pipeline selecionam Aaron. Ele não realiza ato comercial externo nem substitui Sarah, Lucia, Robert ou Gabi em suas fronteiras especializadas.\n- Capabilities de documentos, apresentações, planilhas, processos e comparativos — ou trabalho delimitado sem capability explícita e sem escopo obrigatório — selecionam Clara como fallback operacional contínuo.\n- Um diretório chamado `components` fora dos alvos canônicos não aciona Manu. O orquestrador usa a capability solicitada e os write scopes da Task.\n- `.agents/dashboard/**` e `.local/**` não selecionam Doug nem Manu: permanecem com Rafa ou Leo até que a Task declare um escopo obrigatório; artefatos operacionais não técnicos podem selecionar Clara.\n\nO orquestrador mantém a Run raiz e cada Run delegada separadas na observabilidade. Duração, tokens e custo só são agregados quando observados ou reconciliados; ausência continua indisponível, nunca zero.\n\nNa v4, isso continua verdadeiro para records, API e cálculos. Apenas os\ncards/células numéricas do Dashboard carregado exibem `0` com cobertura\n“sem medição”; o catálogo não autoriza registrar zero observado fictício.\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-6.1-sol` com esforço `medium` e `soft_cycles: 12`, proporcional à revisão standard. Ana (`agent-auditor`) usa `gpt-6.1-sol`/`high` para auditoria crítica ou explicitamente auditável; Luiz (`agent-security-auditor`) usa `gpt-6.1-sol`/`high` para auditoria de segurança explícita.\n\n## Dashboard e segurança operacional\n\nA tela **Configurações > Catálogo de agentes** apresenta a persona e mantém a identidade técnica somente leitura. Ao salvar, o runtime valida o catálogo, deriva o único nickname, sincroniza adapters e reverte a escrita se a paridade falhar. Agentes de framework permitem alteração de persona e preferências de modelo/effort; propósito, capacidades e identidade técnica continuam protegidos.\n\n## Preset e configuração efetivamente executada\n\nDefaults do catálogo não comprovam modelo/effort efetivos. Com `autonomy-v1`,\no preset e a seleção final do despacho gerenciado também são validados:\nEssencial veda Astra automático e não herda a exceção manual do principal.\nInforme ao usuário a delegação necessária e a possibilidade de modelos\ndiferentes. Mantenha indisponível o que o host não informou.\nConsulte [modelos](23-orquestracao-de-modelos.md) e [autonomia](19-assurance-e-autonomia.md).\n',S=`# Assurance adaptativa e perfis de autonomia
 
 Este guia descreve \`autonomy-v1\` existente e o contrato-alvo Codex-native da
 v4. A rota nova abaixo ainda precisa de implementação, qualificação do pacote
@@ -1541,7 +1588,7 @@ partir do terceiro, quando a rota válida o selecionar; não se torna reviewer
 ou finalizer. A exceção de execução não acrescenta tentativas nem amplia
 write scopes.
 
-Os dois primeiros replanejamentos usam \`gpt-6-sol\`; o terceiro e os
+Os dois primeiros replanejamentos usam \`gpt-6.1-sol\`; o terceiro e os
 seguintes permitidos usam \`gpt-6-astra\`. Executor e replanejador são
 invocações diferentes. Um plano Astra não obriga o executor a usar Astra.
 
@@ -1568,15 +1615,36 @@ telemetria de duração e checkpoints têm outras funções. Resultado desconhec
 não libera despacho duplicado. Para retomada, consulte o diário existente,
 não crie outra Task ou apague \`.local\` para renovar a quota.
 
+## Sol 6.1 e escolha de Luna/high
+
+Novas seleções Sol usam \`gpt-6.1-sol\`, inclusive baseline, revisão, Gui e os dois primeiros replanejamentos. Luna continua \`gpt-6-luna\` e Astra continua \`gpt-6-astra\`; Terra não participa de novas seleções. Defaults legados Sol 6 e Terra/Sol 5.6 são normalizados em memória ao ler a configuração. Histórico, custos antigos e cabeçalhos de Runs permanecem com as identidades originais.
+
+Na instalação/atualização autorizada, o instalador também persiste a migração dos IDs conhecidos no \`project.yaml\`, com backup, preservação de comentários e deduplicação da allowlist. Preferências manuais do Codex e identidades históricas não são reescritas.
+
+Um plano congelado com Sol 6 permanece legível, mas não autoriza novo despacho automático: exige replanejamento explícito. Ausência de Sol 6.1 no host bloqueia sem downgrade. Os perfis gerados precisam estar carregados na sessão do Codex; escrever o TOML não comprova recarga. A seleção manual do principal continua pertencendo ao usuário.
+
+Recomendação operacional, ainda sem benchmark comparativo neste projeto:
+
+| Situação | Recomendação |
+| --- | --- |
+| Mudança mecânica ou extração simples com aceite claro | Luna/low |
+| Problema local delimitado que exige mais raciocínio, com teste decisivo barato | Comparar Luna/high com Sol 6.1/medium |
+| Implementação em vários módulos, ambiguidade ou custo alto de correção | Sol 6.1/medium; high quando a dificuldade justificar |
+| Auditoria ampla, segurança ou arquitetura difícil | Sol 6.1/high; Astra só pela rota autorizada |
+
+Luna/high é permitido por override explícito válido, mas não é o default automático, não altera revisores/Gui e não recebe equivalência presumida com Sol/medium. Compare os mesmos ACs, ambiente e conjunto de tarefas: aprovação na primeira revisão, reparos, duração total e custo por tarefa aprovada. Se falhar por compreensão/hipótese, prefira a rota governada Sol 6.1 em vez de insistir com mais esforço no Luna; mantenha os limites de recuperação. Mais esforço pode aumentar tokens e latência.
+
+Fontes oficiais consultadas em 2026-10-10: [Sol 6.1](https://developers.openai.com/api/docs/models/gpt-6.1-sol), [Luna](https://developers.openai.com/api/docs/models/gpt-6-luna) e [reasoning effort](https://developers.openai.com/api/docs/guides/reasoning). Os preços API por 1M de tokens sem cache são US$2/US$10 (entrada/saída) para Sol 6.1 e US$0,10/US$0,50 para Luna: diferença de 20 vezes por token, não economia total garantida nem consumo equivalente da assinatura Codex.
+
 ## Família de modelos
 
 | Modelo | Papel dentro da política ZAIP |
 | --- | --- |
 | \`gpt-6-luna\` | Implementação/testes simples, locais e delimitados: low; alto volume delimitado conforme sinais |
-| \`gpt-6-sol\` | Execução padrão: medium; complexidade/ambiguidade alta: high; reviewer/Gui: medium; auditor: high |
+| \`gpt-6.1-sol\` | Execução padrão: medium; complexidade/ambiguidade alta: high; reviewer/Gui: medium; auditor: high |
 | \`gpt-6-astra\` | Diagnóstico crítico difícil evidenciado e replanejamento/execução autorizados a partir do terceiro plano: high |
 
-Os antigos \`gpt-5.6-terra\` e \`gpt-5.6-sol\` migraram para \`gpt-6-sol\`;
+Os antigos \`gpt-5.6-terra\` e \`gpt-5.6-sol\` migraram para \`gpt-6.1-sol\`;
 \`gpt-5.6-luna\` migrou para \`gpt-6-luna\`. A preferência Sol do catálogo é um
 baseline. Ela não substitui a política de um perfil persistido nem altera os
 nomes dos modelos em registros históricos.
@@ -1839,6 +1907,26 @@ Registro local de consulta em 15 de julho de 2026. Valores operacionais ficam no
 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.
 `,k=`# Qualidade e qualificação de release
 
+## Ajustes e publicação na v6.2
+
+Pedidos diretos de finalizar pendências, atualizar documentação e publicar uma
+versão explícita são reconhecidos pelo contrato. “Pode fazer os ajustes e
+publicar” segue a política do projeto e seu ciclo corrente; não infere versão
+arbitrária nem amplia o escopo. Perguntas, citações, negações e espera por
+aprovação humana permanecem sem autoridade de publicação.
+
+Para ajustes e publicação autorizados juntos, mantenha uma única Task crítica
+direta e use o modo \`--integrated-task\` do freeze. Uma Task já concluída não deve
+ser reutilizada para novos arquivos: normalmente o intake exige novo turno para
+outra entrega. Planejar o coordenador integrado desde a captura evita essa
+interrupção sem eliminar revisão, finalizador, CI ou qualificação assinada.
+
+Confira README, guias, templates e a instalação do TGZ final 6.2.0. Sol 6.1 e
+Luna/high estão detalhados no guia 23. Preserve as notas históricas de auditoria;
+esta mudança não constitui nova medição de qualidade ou redução de custo.
+
+## Critérios de qualificação
+
 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.
 
 As decisões de [lifecycle v4](28-lifecycle-completo.md#contrato-aprovado-para-a-v4-a-implementar-e-qualificar)
@@ -2102,6 +2190,89 @@ defina uma medição independente com artefatos identificados e falhas observada
 
 ## Evolução de confiabilidade e documentação
 
+A evolução recente, as provas da v6.1 e os limites da auditoria estão nas seções
+seguintes. Os registros abaixo preservam sua data e seu candidato.
+
+### Patch imutável e fechamento separado
+
+A linha corretiva separa produto \`N.N\`, pacote \`N.N.P\` e tag \`vN.N.P\`. Patch exige
+pedido explícito e contrato assinado próprio; não substitui bytes publicados nem
+avança por si só o ciclo de produto. O parser distingue pedido direto de citação,
+negação, pergunta e condição. Misturar patch e minor ou informar versões ambíguas
+não autoriza publicação. Consulte a [skill de deploy](../../skills/zaip-skill-github-deploy/SKILL.md).
+
+Se o publicador falhar depois da Release, preserve candidato e TGZ. Reparo de
+controle usa SHA e CI próprios, ancestralidade e inventário restrito; cada commit
+intermediário é inspecionado. O publicador instala dependências do lockfile com
+scripts desabilitados antes do verificador, sem recompilar o produto assinado.
+O CI do reparo não substitui a qualificação do pacote.
+
+Distinga qualificação do candidato, publicação GitHub, versão/integridade npm e
+fechamento Task/Change/Execution. O commit posterior de metadata tem CI próprio
+e conserva a tag no SHA publicado. Alterar documentação ou sincronizar templates
+localmente não modifica o pacote no npm; novos bytes exigem nova versão publicada.
+
+### Eficiência medida e prevenção de retrabalho
+
+O rapid check do mantenedor resume contagens, seleção e cache no console;
+\`--plan\` conserva o diagnóstico completo. Grupos limitados a dependências estáticas
+comprovadas podem usar sua identidade; os demais preservam SHA exato e limpeza
+do checkout. Uma mudança de identidade pode invalidar provas legítimas.
+Reuso exige identidade, dependências, ambiente, política e autoridade compatíveis.
+
+Antecipe formatação, paridade e contratos baratos antes dos gates longos.
+Após correção, revalide o impacto e a prova invalidada; não repita testes só para
+criar artefatos. Registre preparo, qualificação, pre-main, CI, publicação e
+fechamento separadamente, com hits/misses e causas. Duração de uma etapa,
+quantidade de testes e resposta curta não demonstram economia total.
+
+### Fotografia da auditoria de 10/10/2026 — v6.1
+
+Escopo: delta de código, evidências existentes e consultas de Release/npm/CI;
+sem nova suíte completa, teste de intrusão, ensaio visual ou operação prolongada.
+As notas são avaliações técnicas do chat, não certificações nem gates.
+
+| Dimensão | Nota / 10 |
+| --- | ---: |
+| Funcionalidade e CLI | 8,7 |
+| Governança e fechamento | 8,5 |
+| Eficiência e prevenção de retrabalho | 7,0 |
+| Recuperação e resiliência | 8,0 |
+| Segurança e controles | 8,7 |
+| Testes e qualidade das evidências | 8,8 |
+| Distribuição e publicação | 9,2 |
+| Arquitetura e manutenção | 8,0 |
+| Observabilidade e rastreabilidade | 8,0 |
+| Documentação e README | 8,7 |
+
+Média simples arredondada: **8,4/10**; prontidão para produção avaliada
+separadamente: **8,2/10**, com acompanhamento. A qualificação assinada passou
+20 gates em 871096 ms (14min31s); pre-main passou 28 grupos com 837 arquivos
+selecionados e zero hits (26 \`identity-changed\`, dois \`no-proof\`). O gate de
+tamanho registrou 2332 arquivos, 181 avisos e zero erros. Esses números pertencem
+ao candidato e ambiente observados, não são SLA nem medição dos consumidores.
+
+Candidato: \`7bf498e2bea42f8739a73e1bd32b8c2105834a85\`;
+[Release v6.1](https://github.com/zaip-ai/zaip-aios/releases/tag/v6.1),
+[npm 6.1.0](https://www.npmjs.com/package/@zaip-ai/cli/v/6.1.0),
+[CI do candidato](https://github.com/zaip-ai/zaip-aios/actions/runs/38083472311),
+[publicador](https://github.com/zaip-ai/zaip-aios/actions/runs/38083583146) e
+[CI do fechamento](https://github.com/zaip-ai/zaip-aios/actions/runs/38084917032)
+foram confirmados; \`latest\` apontava para 6.1.0 na consulta. Task, Change e
+Execution da entrega estavam \`completed\`; a captura do finalizador usou fallback
+oficial, sem inventar telemetria. O commit de fechamento foi
+\`9e0417f4826615d4723d2bb768808581c0c6a8f5\`. As Tasks históricas v5.7/v5.8
+permaneceram bloqueadas por decisão humana, sem impedir essa conclusão.
+
+Pendências propostas, **não implementadas por esta revisão documental**:
+ampliar cache por dependências comprovadas; medir e reduzir cálculo interno do
+fechamento; antecipar checks baratos; exercitar consumidor limpo com hooks nativos,
+interrupção, retomada e fechamento automático; reduzir avisos por refatorações
+coesas. A recuperação tem provas em fixtures integradas; isso não comprova
+fechamento histórico real nem estabilidade prolongada.
+
+### Referências das linhas anteriores
+
 A [matriz de evolução](https://github.com/zaip-ai/zaip-aios/blob/main/docs/quality/v50-documentacao-editorial.md)
 vincula as dez frentes aos seus comandos, provas, rollback e limitações.
 READMEs PT/EN descrevem o mesmo contrato: \`essential-v3\` por padrão,
@@ -2320,6 +2491,18 @@ combinação de hashes válidos, cobertura explícita e leitura do período real
 
 ## Caminho atual de consulta e limites de performance
 
+Em recuperação com \`same_turn_handoff\`, predecessor e sucessor lógico podem
+compartilhar uma invocação física. Correlação e tokens observados permanecem
+no proprietário original: coleta individual, em lote e no fechamento não devem
+contabilizar o mesmo transcript novamente. Sem fronteira observável de consumo,
+o sucessor mantém uso indisponível, não zero nem estimativa apresentada como medida.
+Hooks e tracking continuam independentes da autorização de entrega.
+
+Se a identidade rica do filho não puder ser resolvida, somente o fallback oficial
+elegível de captura terminal pode registrar o evento observado. Modelo, effort,
+tokens e custo ausentes continuam indisponíveis. Isso não comprova que a correlação
+nativa rica funcionou e não autoriza duplicar um agente já concluído.
+
 A descrição manifest-first acima inclui o caminho de compatibilidade.
 No runtime SQLite, a primeira dobra do Monitor usa agregados compactos;
 detalhes de Runs ficam em endpoints paginados explícitos. Queries preservam
@@ -2335,7 +2518,7 @@ legados, substituição, truncamento, exclusão e concorrência exigem verifica
 de integridade e fallback completos. Redução mensurada, baseline equivalente,
 cobertura e carga concorrente precisam constar do benchmark; não declarar a
 matriz de performance aprovada apenas porque consultas focadas passaram.
-`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento separa o lifecycle existente do contrato aprovado para a v4.\nStatus persistido, Run, coluna do Kanban e reconciliação possuem\nresponsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Contrato aprovado para a v4 (a implementar e qualificar)\n\nAs regras a seguir são decisões de produto, **não** prova de que o runtime,\nhooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve\ncomparar código-fonte, artefato empacotado e uso real no Codex.\n\n1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de\n   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo\n   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro\n   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`\n   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter\n   automaticamente nem paralisar a ação já autorizada.\n2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A\n   definição usa sua Run `interaction`; a implementação usa outra Run\n   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a\n   Run de definição como se tivesse executado o produto. “Crie” isolado\n   termina em `draft`; `ready` não executa; `execute` não precisa passar\n   temporariamente pelo card Pronto para Executar.\n3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de\n   PRD/SPEC em DAG planejada, com independência, escopos e recursos\n   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,\n   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de\n   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;\n   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as\n   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma\n   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e\n   dos gates parentais o macro pode ser entregue ou terminalizado com causa.\n4. Cada rodada horária, se o usuário tiver instalado a automação Codex,\n   reivindica somente **um** item superior `ready`: PRD, depois SPEC\n   independente, depois Task avulsa. Dentro da classe respeita a prioridade\n   manual do Kanban. Descendentes, ativos e terminais não são candidatos.\n   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não\n   acordam o Codex; não prometa trabalho após o host parar.\n5. O preset `balanced` admite três replanejamentos reais por Task, com\n   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,\n   evento observado, hipótese nova, teste discriminante e ledger imutável\n   evitam recontagem ou alegação de tentativa não executada. O controle\n   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4\n   precisa implementar um preflight compatível com o host e bloquear quando\n   modelo, effort ou ferramenta requeridos não puderem ser assegurados.\n6. A reconciliação global do backlog continua manual. A tentativa **atual**\n   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento\n   observável da mesma Task/turno; não há garantia de código rodando após o\n   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos\n   canônicos, sem inferir aprovação.\n7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem\n   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram\n   também cobertura/tooltip “sem medição”, pois zero observado é diferente.\n   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e\n   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a\n   fonte canônica nem entra em somas como observação.\n\nO candidato local v4 usa `codex_native` no schema e no template npm. O modo\nnão inicia um processo autônomo separado; a efetividade da rota nativa ainda\ndepende da capacidade real da sessão Codex. Compatibilidade legada permanece\nseparada do caminho padrão novo. Isso não comprova publicação no npm.\n\n## Fronteiras nativas e prova de compatibilidade\n\nEsta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule\nou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,\nnão intercepta toda chamada e não cria um relógio. O caminho v4 usa as\nferramentas reais do Codex e valida capacidades disponíveis na sessão antes\nde prometer uma garantia.\n\n| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |\n| --- | --- | --- |\n| Intake | Separar Conversation de ação e correlacionar turno, intenção e alvo sem Task artificial. | Fixtures para pergunta, ação avulsa, criação `draft`, `ready`, execução e “crie e execute”; ausência de artefatos indevidos. |\n| Subagente nativo | Em toda Task avulsa, despachar um filho real e aguardar seu resultado; execução produtiva sequencial. Só uma DAG de PRD/SPEC autoriza filhos produtivos paralelos. | Captura de `spawn_agent`, identidade, modelo/effort solicitados e efetivamente observáveis, resultado terminal e nenhuma Task concorrente fora da DAG. |\n| Modelo e esforço | Consultar agente/perfil que o host disponibiliza. Validar a rota antes do spawn; preservar seleção manual do principal e distinguir intenção de configuração efetiva. | Teste com agente GPT-6 válido, modelo não disponível e fallback inesperado. Sem comprovação da configuração efetiva, manter telemetria `null` e bloquear a garantia automática. |\n| Replan | Reservar e registrar até três diagnósticos reais no Equilibrado, Sol/high, Sol/high, Astra/high; plano exige hipótese nova e teste que distingue a causa. | Ledger idempotente, casos de erro, interrupção, retry e capacidade ausente; não contar prompt, timeout ou reserva sem execução como diagnóstico concluído. |\n| Fechamento | Aguardar filhos e provas, executar Gui como último filho e aplicar sua decisão. Se Gui não iniciar, falhar ou a Run parar, o caminho confiável de fechamento registra `blocked` com motivo e retomada, sem inventar decisão de Gui. | Testes de Stop, interrupção e replay; nenhuma tentativa **formalmente encerrada** fica `executing`/`verifying`; recibo recuperável quando a escrita falha. |\n| Agenda | Instalar somente a pedido uma tarefa agendada nativa do desktop para um item superior `ready` por rodada, com lease e prioridade do Kanban. | Inspeção da automação realmente criada, duas rodadas sem duplicação e teste de worktree/local; sem app/máquina ativa, informar ausência de execução. |\n| Dados e UI | Reconciliar fontes canônicas e worktrees; mostrar skeleton durante carga e `0` visual nos campos numéricos sem medição, com cobertura explícita. | Comparar records → SQLite → API → cards/tabelas; `null` continua em API/export/cálculo, inclusive nos períodos Hoje/Ontem/Esta Semana. |\n| Distribuição | Builder e projeto novo/atualizado pelo npm instalam os mesmos adapters, Rules, skills e configuração suportada. | Testar TGZ exato em fixture limpa e atualização Windows/PowerShell, `doctor`, adaptadores, ciclo Codex e idempotência. |\n\nOs [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)\npermitem perfis próprios e herança de modelo/effort; a disponibilidade\nconcreta e o agente escolhido dependem da sessão. Os\n[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas\nferramentas locais, mas admitem caminhos especializados fora dessa cobertura.\n`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova\ncontinuação, não provar que o trabalho terminou, nem impedir uma interrupção\nhumana. Por isso o hook é checkpoint e reparo observável, nunca substituto\nuniversal de estado canônico, Gui ou ferramenta de despacho. As\n[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução\nprópria do app; em projeto local dependem de computador ligado e app ativo.\nO agendamento não é instalado só porque os arquivos existem no Git.\n\nSe o processo for encerrado antes do Stop ou da escrita, nenhum componente\nlocal consegue garantir a transição **naquele instante**. A garantia honesta é\num evento durável recuperável e a conciliação na próxima execução observável;\naté lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não\ninventar um terminal. Esse limite do host não autoriza encerrar a Run com\n`executing` como se fosse sucesso.\n\nLacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão\nde Gui, mas `run finish` aplica `blocked` como fallback quando é realmente\nchamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar\na Task em `executing` até a retomada/reconciliação. A fila agendada agora\nreivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada\npara toda chamada nativa. São itens de implementação, não decisões humanas\npendentes. A documentação é aprovada quando descreve essas lacunas; o produto\nsó está pronto quando a matriz passa no Codex e no pacote instalado.\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\nNo contrato atual, `implemente` sem alvo abre Conversation de planejamento; na v4, quando houver objetivo independente de ação, entra como Task avulsa. Em PRD/SPEC `draft`, só executa com intenção explícita de executar o macro; criar/refinar isoladamente mantém `draft`. Em `ready`, executar inicia; em `active|blocked|failed`, continua/retoma/rework conforme estado. `desenvolva|melhore|aprimore` com intenção explícita de ação independente também não é reduzido a planejamento só pelo verbo. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição após a decisão real. 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. **Contrato-alvo v4:** finalizador ausente, incompleto ou falho produz `blocked` por um caminho confiável separado, nunca uma aprovação sintética. No candidato atual, a CLI ainda pode deixar a Task em `executing` porque rejeita bloqueio direto sem Gui; essa lacuna precisa de correção e teste.\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\nDepois de capturar a decisão real do finalizador, o orquestrador pode aplicar\no fechamento pela CLI. O trecho abaixo **não** funciona como atalho para\n`task block` ou `run finish` sem essa decisão já persistida:\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 **formalmente persistido** 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 exige recuperação retomável; quando o evento de\ninterrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte\nabrupta do processo pode deixar o estado pendente até o próximo evento\nobservável, como descrito acima. “Cancelar a Task” é decisão explícita e\nresulta em `cancelled` somente quando persistida.\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 da DAG ficam terminais, o macro pode entrar em\n  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis\n  são fechados com causa antes de decidir o resultado parental.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence\n  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.\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. O contrato-alvo v4 acrescenta conciliação **direcionada à tentativa atual** no fechamento/Stop observado ou no próximo evento Codex da mesma Task, nunca uma varredura global silenciosa.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A exceção de raiz avulsa direta\nautorizada pertence à compatibilidade do contrato atual; no padrão Codex-native\nda v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois\ncaminhos dispensa Evidence, gates e decisão real de Gui.\n\n## Regra operacional de checkout e release\n\nBranch é uma linha de commits; worktree é outra pasta de checkout que pode apontar para uma branch. Task avulsa ou PRD/SPEC serial usa um único checkout e um escritor por Task/Run registrado na raiz Git comum. Assim, uma edição pequena não cria branch. Só frentes paralelas independentes, com concorrência ativa, dependências resolvidas e `write_scopes` disjuntos, recebem branch e worktree separados. Um teste isolado pode usar worktree detached temporário em `.local/worktrees/validation`.\n\nNo fim da Task isolada, integre trabalho concluído, inventarie arquivos e ignorados, faça bundle/snapshot verificáveis em `.local/backup-branchs` e `.local/backup-worktrees` e feche branch/worktree. Se a Task estiver bloqueada, preserve o trabalho no backup antes de liberar o checkout. A limpeza dos backups é manual. No checkout compartilhado, alterações de várias Tasks sem atribuição verificável bloqueiam fechamento automático.\n\nO ciclo em `.agents/config/release-cycle.json` admite drafts de PRD/SPEC futuros, mas execução só do release corrente. `freeze`, `audit` e `advance` exigem prova de SHA, estado canônico e branches/worktrees. Para release/crítico, checks locais fixos antecedem o push de `main`; CI remoto do mesmo SHA antecede a Release. A exceção de uma Task de coordenação de release exige identidade explícita no manifesto congelado, Run ativa no freeze, risco crítico, alvo corrente e escopos somente de release. Ela termina e integra seus records no candidato antes de `audit`; audit/advance conferem os records no SHA. Até a auditoria ficar verde, o release permanece pendente.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
+`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento separa o lifecycle existente do contrato aprovado para a v4.\nStatus persistido, Run, coluna do Kanban e reconciliação possuem\nresponsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Contrato aprovado para a v4 (a implementar e qualificar)\n\nAs regras a seguir são decisões de produto, **não** prova de que o runtime,\nhooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve\ncomparar código-fonte, artefato empacotado e uso real no Codex.\n\n1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de\n   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo\n   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro\n   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`\n   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter\n   automaticamente nem paralisar a ação já autorizada.\n2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A\n   definição usa sua Run `interaction`; a implementação usa outra Run\n   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a\n   Run de definição como se tivesse executado o produto. “Crie” isolado\n   termina em `draft`; `ready` não executa; `execute` não precisa passar\n   temporariamente pelo card Pronto para Executar.\n3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de\n   PRD/SPEC em DAG planejada, com independência, escopos e recursos\n   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,\n   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de\n   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;\n   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as\n   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma\n   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e\n   dos gates parentais o macro pode ser entregue ou terminalizado com causa.\n4. Cada rodada horária, se o usuário tiver instalado a automação Codex,\n   reivindica somente **um** item superior `ready`: PRD, depois SPEC\n   independente, depois Task avulsa. Dentro da classe respeita a prioridade\n   manual do Kanban. Descendentes, ativos e terminais não são candidatos.\n   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não\n   acordam o Codex; não prometa trabalho após o host parar.\n5. O preset `balanced` admite três replanejamentos reais por Task, com\n   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,\n   evento observado, hipótese nova, teste discriminante e ledger imutável\n   evitam recontagem ou alegação de tentativa não executada. O controle\n   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4\n   precisa implementar um preflight compatível com o host e bloquear quando\n   modelo, effort ou ferramenta requeridos não puderem ser assegurados.\n6. A reconciliação global do backlog continua manual. A tentativa **atual**\n   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento\n   observável da mesma Task/turno; não há garantia de código rodando após o\n   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos\n   canônicos, sem inferir aprovação.\n7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem\n   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram\n   também cobertura/tooltip “sem medição”, pois zero observado é diferente.\n   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e\n   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a\n   fonte canônica nem entra em somas como observação.\n\nO candidato local v4 usa `codex_native` no schema e no template npm. O modo\nnão inicia um processo autônomo separado; a efetividade da rota nativa ainda\ndepende da capacidade real da sessão Codex. Compatibilidade legada permanece\nseparada do caminho padrão novo. Isso não comprova publicação no npm.\n\n## Fronteiras nativas e prova de compatibilidade\n\nEsta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule\nou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,\nnão intercepta toda chamada e não cria um relógio. O caminho v4 usa as\nferramentas reais do Codex e valida capacidades disponíveis na sessão antes\nde prometer uma garantia.\n\n| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |\n| --- | --- | --- |\n| Intake | Separar Conversation de ação e correlacionar turno, intenção e alvo sem Task artificial. | Fixtures para pergunta, ação avulsa, criação `draft`, `ready`, execução e “crie e execute”; ausência de artefatos indevidos. |\n| Subagente nativo | Em toda Task avulsa, despachar um filho real e aguardar seu resultado; execução produtiva sequencial. Só uma DAG de PRD/SPEC autoriza filhos produtivos paralelos. | Captura de `spawn_agent`, identidade, modelo/effort solicitados e efetivamente observáveis, resultado terminal e nenhuma Task concorrente fora da DAG. |\n| Modelo e esforço | Consultar agente/perfil que o host disponibiliza. Validar a rota antes do spawn; preservar seleção manual do principal e distinguir intenção de configuração efetiva. | Teste com agente GPT-6 válido, modelo não disponível e fallback inesperado. Sem comprovação da configuração efetiva, manter telemetria `null` e bloquear a garantia automática. |\n| Replan | Reservar e registrar até três diagnósticos reais no Equilibrado, Sol/high, Sol/high, Astra/high; plano exige hipótese nova e teste que distingue a causa. | Ledger idempotente, casos de erro, interrupção, retry e capacidade ausente; não contar prompt, timeout ou reserva sem execução como diagnóstico concluído. |\n| Fechamento | Aguardar filhos e provas, executar Gui como último filho e aplicar sua decisão. Se Gui não iniciar, falhar ou a Run parar, o caminho confiável de fechamento registra `blocked` com motivo e retomada, sem inventar decisão de Gui. | Testes de Stop, interrupção e replay; nenhuma tentativa **formalmente encerrada** fica `executing`/`verifying`; recibo recuperável quando a escrita falha. |\n| Agenda | Instalar somente a pedido uma tarefa agendada nativa do desktop para um item superior `ready` por rodada, com lease e prioridade do Kanban. | Inspeção da automação realmente criada, duas rodadas sem duplicação e teste de worktree/local; sem app/máquina ativa, informar ausência de execução. |\n| Dados e UI | Reconciliar fontes canônicas e worktrees; mostrar skeleton durante carga e `0` visual nos campos numéricos sem medição, com cobertura explícita. | Comparar records → SQLite → API → cards/tabelas; `null` continua em API/export/cálculo, inclusive nos períodos Hoje/Ontem/Esta Semana. |\n| Distribuição | Builder e projeto novo/atualizado pelo npm instalam os mesmos adapters, Rules, skills e configuração suportada. | Testar TGZ exato em fixture limpa e atualização Windows/PowerShell, `doctor`, adaptadores, ciclo Codex e idempotência. |\n\nOs [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)\npermitem perfis próprios e herança de modelo/effort; a disponibilidade\nconcreta e o agente escolhido dependem da sessão. Os\n[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas\nferramentas locais, mas admitem caminhos especializados fora dessa cobertura.\n`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova\ncontinuação, não provar que o trabalho terminou, nem impedir uma interrupção\nhumana. Por isso o hook é checkpoint e reparo observável, nunca substituto\nuniversal de estado canônico, Gui ou ferramenta de despacho. As\n[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução\nprópria do app; em projeto local dependem de computador ligado e app ativo.\nO agendamento não é instalado só porque os arquivos existem no Git.\n\nSe o processo for encerrado antes do Stop ou da escrita, nenhum componente\nlocal consegue garantir a transição **naquele instante**. A garantia honesta é\num evento durável recuperável e a conciliação na próxima execução observável;\naté lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não\ninventar um terminal. Esse limite do host não autoriza encerrar a Run com\n`executing` como se fosse sucesso.\n\nLacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão\nde Gui, mas `run finish` aplica `blocked` como fallback quando é realmente\nchamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar\na Task em `executing` até a retomada/reconciliação. A fila agendada agora\nreivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada\npara toda chamada nativa. São itens de implementação, não decisões humanas\npendentes. A documentação é aprovada quando descreve essas lacunas; o produto\nsó está pronto quando a matriz passa no Codex e no pacote instalado.\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\nNo contrato atual, `implemente` sem alvo abre Conversation de planejamento; na v4, quando houver objetivo independente de ação, entra como Task avulsa. Em PRD/SPEC `draft`, só executa com intenção explícita de executar o macro; criar/refinar isoladamente mantém `draft`. Em `ready`, executar inicia; em `active|blocked|failed`, continua/retoma/rework conforme estado. `desenvolva|melhore|aprimore` com intenção explícita de ação independente também não é reduzido a planejamento só pelo verbo. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição após a decisão real. 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. **Contrato-alvo v4:** finalizador ausente, incompleto ou falho produz `blocked` por um caminho confiável separado, nunca uma aprovação sintética. No candidato atual, a CLI ainda pode deixar a Task em `executing` porque rejeita bloqueio direto sem Gui; essa lacuna precisa de correção e teste.\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\nDepois de capturar a decisão real do finalizador, o orquestrador pode aplicar\no fechamento pela CLI. O trecho abaixo **não** funciona como atalho para\n`task block` ou `run finish` sem essa decisão já persistida:\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 do último Gui, consulte o [preflight do guia 16](16-lifecycle-e-reconciliacao.md#diagnóstico-antecipado-e-respostas-compactas).\nEle separa autoridade para `completed`, descendentes ativos e prontidão de\ndespacho; não substitui decisão nem gates. Recuperação pós-publicação revalida\nrecibo, publicação e proprietário único; observação passiva elegível não é outro\nexecutor. Em `same_turn_handoff`, a telemetria física é atribuída uma única vez,\nconforme o [guia 27](27-telemetria-git-native.md). Saída compacta preserva o cálculo\ninterno e não comprova menor duração.\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 **formalmente persistido** 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 exige recuperação retomável; quando o evento de\ninterrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte\nabrupta do processo pode deixar o estado pendente até o próximo evento\nobservável, como descrito acima. “Cancelar a Task” é decisão explícita e\nresulta em `cancelled` somente quando persistida.\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 da DAG ficam terminais, o macro pode entrar em\n  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis\n  são fechados com causa antes de decidir o resultado parental.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence\n  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.\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. O contrato-alvo v4 acrescenta conciliação **direcionada à tentativa atual** no fechamento/Stop observado ou no próximo evento Codex da mesma Task, nunca uma varredura global silenciosa.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A exceção de raiz avulsa direta\nautorizada pertence à compatibilidade do contrato atual; no padrão Codex-native\nda v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois\ncaminhos dispensa Evidence, gates e decisão real de Gui.\n\n## Regra operacional de checkout e release\n\nBranch é uma linha de commits; worktree é outra pasta de checkout que pode apontar para uma branch. Task avulsa ou PRD/SPEC serial usa um único checkout e um escritor por Task/Run registrado na raiz Git comum. Assim, uma edição pequena não cria branch. Só frentes paralelas independentes, com concorrência ativa, dependências resolvidas e `write_scopes` disjuntos, recebem branch e worktree separados. Um teste isolado pode usar worktree detached temporário em `.local/worktrees/validation`.\n\nNo fim da Task isolada, integre trabalho concluído, inventarie arquivos e ignorados, faça bundle/snapshot verificáveis em `.local/backup-branchs` e `.local/backup-worktrees` e feche branch/worktree. Se a Task estiver bloqueada, preserve o trabalho no backup antes de liberar o checkout. A limpeza dos backups é manual. No checkout compartilhado, alterações de várias Tasks sem atribuição verificável bloqueiam fechamento automático.\n\nO ciclo em `.agents/config/release-cycle.json` admite drafts de PRD/SPEC futuros, mas execução só do release corrente. `freeze`, `audit` e `advance` exigem prova de SHA, estado canônico e branches/worktrees. Para release/crítico, checks locais fixos antecedem o push de `main`; CI remoto do mesmo SHA antecede a Release. A exceção de uma Task de coordenação de release exige identidade explícita no manifesto congelado, Run ativa no freeze, risco crítico, alvo corrente e escopos somente de release. Ela termina e integra seus records no candidato antes de `audit`; audit/advance conferem os records no SHA. Até a auditoria ficar verde, o release permanece pendente.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
 
 [English](README-ENG.md) | Português
 
@@ -2343,10 +2526,18 @@ matriz de performance aprovada apenas porque consultas focadas passaram.
 
 ## Visão rápida
 
+As mudanças da v6.2 estão descritas no [contrato de modelos e publicação](docs/quality/v62-modelos-e-publicacao.md): novas rotas Sol 6.1, migração de configurações com preservação do histórico, critérios de Luna/high e reconhecimento dos pedidos diretos de ajustes com publicação. A identidade local não substitui a verificação da Release e do pacote npm.
+
 A v6.0 trata a [recuperação de estados parciais e fechamentos sequenciais](docs/quality/v60-recuperacao.md), a [identidade da instalação no cache](docs/quality/v60-eficiencia.md) e o [planejamento explícito de major](docs/quality/v60-ciclo-major.md). O [plano de aceite](docs/quality/v60-plano-de-aceite.md) distingue testes locais, provas do candidato, publicação e fechamento histórico; notas e economia exigem resultados observados.
 
 A [correção v6.0.1](docs/quality/v601-fechamento-e-publicacao-corretiva.md) documenta a herança de verificações da Task-first, a prova do reparo posterior do publicador e a propriedade única de telemetria em retomadas no mesmo turno. Pacotes anteriores permanecem imutáveis; o estado publicado deve ser conferido no npm e no GitHub.
 
+O [contrato de fechamento v6.1](docs/quality/v61-fechamento-eficiente.md) descreve o preflight de executor antes do Gui, a observação passiva na retomada histórica e a saída compacta opcional sem alterar o JSON padrão.
+
+Os procedimentos estão no [guia 16](.agents/zaip-aios/guides/16-lifecycle-e-reconciliacao.md), os diagnósticos no [guia 14](.agents/zaip-aios/guides/14-troubleshooting.md) e a atribuição única da telemetria no [guia 27](.agents/zaip-aios/guides/27-telemetria-git-native.md). A [auditoria datada no guia 26](.agents/zaip-aios/guides/26-qualidade-e-release.md#fotografia-da-auditoria-de-10102026--v61) registra média 8,4/10 e prontidão 8,2/10 como avaliações técnicas, sem certificação: governança 8,5; eficiência 7,0. Na v6.1, 20 gates e 28 grupos passaram, mas houve zero reaproveitamento de cache; saída compacta não prova menor custo interno. Recuperação prolongada em ambiente real e novas otimizações permanecem propostas.
+
+A [Release v6.1](https://github.com/zaip-ai/zaip-aios/releases/tag/v6.1) e [npm 6.1.0](https://www.npmjs.com/package/@zaip-ai/cli/v/6.1.0) foram confirmados em 10/10/2026, com fechamento próprio concluído. As Tasks v5.7/v5.8 permanecem bloqueadas por decisão humana. Guias e READMEs são projetados nos templates npm e instalados sob \`.agents/\`; atualizar documentação local não altera os bytes do pacote já publicado.
+
 A v5.9 corrige a ordem de persistência do [fechamento retomável](docs/quality/v59-fechamento-retomavel.md) e evita que o cache interno do Vitest invalide o cache assinado do ZAIP. O [relatório de eficiência](docs/quality/v59-eficiencia-medida.md) registra o experimento, os limites da prova e as métricas para comparar entregas sem atribuir notas automáticas.
 
 O [guia da v5.8](docs/quality/v58-fechamento-eficiencia.md) explica o fechamento com SHAs separados de pacote e reparo do publicador, os contratos antecipados antes do build e a remoção de uma execução duplicada. O histórico bloqueado é preservado até recuperação comprovada; notas e economia dependem das medidas da entrega.
@@ -3348,6 +3539,10 @@ A Task de coordenação do corte pode continuar executando durante publicação
 ## Nota operacional após a publicação v5.0
 
 A recuperação do publisher, o timeout explícito da validação parental e o reconhecimento das Evidence parentais na barreira final estão documentados em [Recuperação do publisher v5.0](docs/quality/v50-publisher-recovery.md). A SPEC v5.0 está entregue, com dez Tasks concluídas. São correções operacionais posteriores na main; o pacote npm 5.0.0 e a tag v5.0 permanecem imutáveis.
+
+## Seleção atual de modelos
+
+As novas rotas Sol usam **GPT-6.1 Sol**, com GPT-6 Luna para trabalho simples e GPT-6 Astra nas recuperações autorizadas. Luna/high é uma opção para avaliação em tarefas delimitadas; o default Luna/low permanece. Configuração antiga é normalizada em memória, sem reescrever Runs históricos. Perfis Codex precisam ser recarregados pelo host para que novos filhos usem a configuração atualizada. Consulte o [guia de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md) para critérios, limites e recomendação de custo total.
 `,P=n(),F=Object.assign({"../../../../zaip-aios/guides/01-primeiros-passos.md":i,"../../../../zaip-aios/guides/02-requirements.md":a,"../../../../zaip-aios/guides/03-tasks.md":o,"../../../../zaip-aios/guides/04-specs.md":s,"../../../../zaip-aios/guides/05-prds.md":c,"../../../../zaip-aios/guides/06-execucao.md":l,"../../../../zaip-aios/guides/07-revisao-e-validacao.md":u,"../../../../zaip-aios/guides/08-contexto-e-tokens.md":d,"../../../../zaip-aios/guides/09-agentes-e-squads.md":f,"../../../../zaip-aios/guides/10-seguranca.md":p,"../../../../zaip-aios/guides/11-observabilidade-e-custos.md":m,"../../../../zaip-aios/guides/12-instalacao-e-upgrade.md":h,"../../../../zaip-aios/guides/13-boas-praticas.md":g,"../../../../zaip-aios/guides/14-troubleshooting.md":_,"../../../../zaip-aios/guides/15-tools-e-codex.md":v,"../../../../zaip-aios/guides/16-lifecycle-e-reconciliacao.md":y,"../../../../zaip-aios/guides/17-como-o-custo-e-calculado.md":b,"../../../../zaip-aios/guides/18-catalogo-de-agentes.md":x,"../../../../zaip-aios/guides/19-assurance-e-autonomia.md":S,"../../../../zaip-aios/guides/20-instalacao-detalhada.md":C,"../../../../zaip-aios/guides/21-telemetria-monitor-custos.md":w,"../../../../zaip-aios/guides/22-fluxos-e-roteamento.md":T,"../../../../zaip-aios/guides/23-orquestracao-de-modelos.md":E,"../../../../zaip-aios/guides/24-calculo-de-custos-openai.md":D,"../../../../zaip-aios/guides/25-fontes-de-precos-openai.md":O,"../../../../zaip-aios/guides/26-qualidade-e-release.md":k,"../../../../zaip-aios/guides/27-telemetria-git-native.md":A,"../../../../zaip-aios/guides/28-lifecycle-completo.md":j});function I({locale:e,onClose:t}){let n=(0,M.useMemo)(()=>r(e,N,F),[e]),i=n.filter(e=>e.id!==`readme`),[a,o]=(0,M.useState)(`readme`),[s,c]=(0,M.useState)(`rendered`),l=n.find(e=>e.id===a)??n[0];return(0,P.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,P.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,P.jsxs)(`header`,{children:[(0,P.jsxs)(`div`,{children:[(0,P.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,P.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,P.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,P.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,P.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,P.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,P.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,P.jsxs)(`article`,{children:[(0,P.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,P.jsx)(`h3`,{children:l?.title}),(0,P.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,P.jsx)(`button`,{"aria-pressed":s===`rendered`,className:s===`rendered`?`is-active`:void 0,onClick:()=>c(`rendered`),type:`button`,children:e===`pt-BR`?`Renderizado`:`Rendered`}),(0,P.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,P.jsx)(`div`,{className:`dashboard-help-sections`,children:W(l?.content??``,e).map(e=>(0,P.jsxs)(`section`,{children:[(0,P.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,P.jsx)(L,{content:e.content}):(0,P.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function L({content:e}){return U(R(e),H).map(({key:e,value:t})=>t.kind===`table`?(0,P.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,P.jsxs)(`table`,{children:[(0,P.jsx)(`thead`,{children:(0,P.jsx)(`tr`,{children:U(t.headers,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`th`,{children:V(t)},e))})}),(0,P.jsx)(`tbody`,{children:U(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,P.jsx)(`tr`,{children:U(t,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`td`,{children:V(t)},e))},e))})]})},e):(0,P.jsx)(`pre`,{children:t.content},e))}function R(e){let t=e.split(`
 `),n=[],r=[],i=()=>{let e=r.join(`
 `).trim();e&&n.push({kind:`text`,content:e}),r=[]};for(let e=0;e<t.length;e+=1){let a=t[e],o=t[e+1];if(a?.includes(`|`)&&o&&z(o)){i();let r=B(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(B(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function z(e){return B(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function B(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function V(e){return U(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,P.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,P.jsx)(M.Fragment,{children:t},e))}function H(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function U(e,t){let n=new Map;return e.map(e=>{let r=t(e),i=(n.get(r)??0)+1;return n.set(r,i),{key:`${r}#${i}`,value:e}})}function W(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`

package/templates/.agents/dashboard/apps/frontend/dist/assets/{PricingSettingsDialog-Cctm7uaW.js → PricingSettingsDialog-DlkxF4w_.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{n as r}from"./dashboard-localization-ykDJSpnb.js";var i=e(t(),1),a=n();function o({catalog:e,fxRate:t,locale:n,onClose:o,onSave:c,onSaveFxRate:l}){let u=r[n],[d,f]=(0,i.useState)(e),[p,m]=(0,i.useState)(t?.rate??0),[h,g]=(0,i.useState)(!1),_=(e,t)=>f(n=>({...n,models:n.models.map((n,r)=>r===e?{...n,...t}:n)})),v=e=>Math.max(0,Number(e)||0);return(0,a.jsx)(`main`,{className:`pricing-backdrop`,children:(0,a.jsxs)(`section`,{"aria-labelledby":`pricing-page-title`,className:`pricing-dialog`,children:[(0,a.jsxs)(`header`,{children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`small`,{children:u.eyebrow}),(0,a.jsx)(`h1`,{id:`pricing-page-title`,children:u.title}),(0,a.jsx)(`p`,{children:u.description})]}),(0,a.jsxs)(`button`,{className:`pricing-back-button`,onClick:o,type:`button`,children:[(0,a.jsx)(`span`,{"aria-hidden":`true`,children:`←`}),` `,u.back]})]}),(0,a.jsxs)(`div`,{className:`pricing-fx-settings`,children:[(0,a.jsxs)(`div`,{className:`pricing-fx-copy`,children:[(0,a.jsx)(`strong`,{children:u.fxTitle}),(0,a.jsx)(`p`,{children:u.fxDescription})]}),(0,a.jsxs)(`label`,{children:[(0,a.jsx)(`span`,{children:u.fxLabel}),(0,a.jsxs)(`div`,{className:`pricing-fx-input`,children:[(0,a.jsx)(`span`,{children:`R$`}),(0,a.jsx)(`input`,{"aria-label":u.fxAriaLabel,min:`0.0001`,onChange:e=>m(Math.max(1e-4,Number(e.target.value)||0)),step:`0.0001`,type:`number`,value:p})]})]})]}),(0,a.jsxs)(`div`,{className:`pricing-table-heading`,children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`strong`,{children:u.catalog}),(0,a.jsx)(`p`,{children:u.pricesPerMillion})]}),(0,a.jsxs)(`span`,{children:[d.models.length,` `,u.models]})]}),(0,a.jsx)(`div`,{className:`pricing-table-wrap`,children:(0,a.jsxs)(`table`,{children:[(0,a.jsx)(`thead`,{children:(0,a.jsxs)(`tr`,{children:[(0,a.jsx)(`th`,{children:u.model}),(0,a.jsx)(`th`,{children:u.provider}),(0,a.jsx)(`th`,{children:u.input}),(0,a.jsx)(`th`,{children:u.cache}),(0,a.jsx)(`th`,{children:u.output}),(0,a.jsx)(`th`,{children:u.reasoning}),(0,a.jsx)(`th`,{children:u.priorityInput}),(0,a.jsx)(`th`,{children:u.priorityCache}),(0,a.jsx)(`th`,{children:u.priorityOutput}),(0,a.jsx)(`th`,{children:u.priorityReasoning}),(0,a.jsx)(`th`,{children:u.contextLimit}),(0,a.jsx)(`th`,{children:u.inputMultiplier}),(0,a.jsx)(`th`,{children:u.outputMultiplier}),(0,a.jsx)(`th`,{})]})}),(0,a.jsx)(`tbody`,{children:d.models.map((e,t)=>(0,a.jsxs)(`tr`,{children:[(0,a.jsxs)(`td`,{children:[(0,a.jsx)(`input`,{"aria-label":u.model,onChange:e=>_(t,{id:e.target.value}),value:e.id}),(0,a.jsx)(`small`,{children:e.aliases.join(`, `)||u.noAliases})]}),(0,a.jsx)(`td`,{children:(0,a.jsxs)(`select`,{onChange:e=>_(t,{provider:e.target.value}),value:e.provider,children:[(0,a.jsx)(`option`,{value:`openai`,children:`OpenAI`}),(0,a.jsx)(`option`,{value:`anthropic`,children:`Anthropic`})]})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.input_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{cached_input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.cached_input_per_million_usd??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{output_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.output_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{reasoning_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.reasoning_per_million_usd??0})}),[`priority_input_per_million_usd`,`priority_cached_input_per_million_usd`,`priority_output_per_million_usd`,`priority_reasoning_per_million_usd`].map(n=>(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{[n]:v(e.target.value)}),step:`0.001`,type:`number`,value:e[n]??0})},n)),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{long_context_threshold_tokens:v(e.target.value)||null}),step:`1`,type:`number`,value:e.long_context_threshold_tokens??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_input_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_input_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_output_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_output_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`button`,{"aria-label":u.removeModel,onClick:()=>f(e=>({...e,models:e.models.filter((e,n)=>n!==t)})),type:`button`,children:`×`})})]},e.id))})]})}),(0,a.jsxs)(`footer`,{children:[(0,a.jsxs)(`button`,{onClick:()=>f(e=>({...e,models:[...e.models,s(n)]})),type:`button`,children:[`+ `,u.addModel]}),(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`button`,{onClick:o,type:`button`,children:u.cancel}),(0,a.jsx)(`button`,{disabled:h,onClick:async()=>{g(!0);try{await c(d),await l(p),o()}finally{g(!1)}},type:`button`,children:h?u.saving:u.save})]})]})]})})}function s(e=`pt-BR`){let t=r[e];return{id:t.newModel,provider:`openai`,aliases:[],input_per_million_usd:0,cached_input_per_million_usd:0,output_per_million_usd:0,reasoning_per_million_usd:0,priority_input_per_million_usd:null,priority_cached_input_per_million_usd:null,priority_output_per_million_usd:null,priority_reasoning_per_million_usd:null,reasoning_billed_separately:!1,long_context_threshold_tokens:null,long_context_input_multiplier:1,long_context_output_multiplier:1,source_label:t.manualOverride,source_url:`https://developers.openai.com/api/docs/pricing`,notes:[t.editedNote]}}export{o as PricingSettingsPage};
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{n as r}from"./dashboard-localization-CqicG5jJ.js";var i=e(t(),1),a=n();function o({catalog:e,fxRate:t,locale:n,onClose:o,onSave:c,onSaveFxRate:l}){let u=r[n],[d,f]=(0,i.useState)(e),[p,m]=(0,i.useState)(t?.rate??0),[h,g]=(0,i.useState)(!1),_=(e,t)=>f(n=>({...n,models:n.models.map((n,r)=>r===e?{...n,...t}:n)})),v=e=>Math.max(0,Number(e)||0);return(0,a.jsx)(`main`,{className:`pricing-backdrop`,children:(0,a.jsxs)(`section`,{"aria-labelledby":`pricing-page-title`,className:`pricing-dialog`,children:[(0,a.jsxs)(`header`,{children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`small`,{children:u.eyebrow}),(0,a.jsx)(`h1`,{id:`pricing-page-title`,children:u.title}),(0,a.jsx)(`p`,{children:u.description})]}),(0,a.jsxs)(`button`,{className:`pricing-back-button`,onClick:o,type:`button`,children:[(0,a.jsx)(`span`,{"aria-hidden":`true`,children:`←`}),` `,u.back]})]}),(0,a.jsxs)(`div`,{className:`pricing-fx-settings`,children:[(0,a.jsxs)(`div`,{className:`pricing-fx-copy`,children:[(0,a.jsx)(`strong`,{children:u.fxTitle}),(0,a.jsx)(`p`,{children:u.fxDescription})]}),(0,a.jsxs)(`label`,{children:[(0,a.jsx)(`span`,{children:u.fxLabel}),(0,a.jsxs)(`div`,{className:`pricing-fx-input`,children:[(0,a.jsx)(`span`,{children:`R$`}),(0,a.jsx)(`input`,{"aria-label":u.fxAriaLabel,min:`0.0001`,onChange:e=>m(Math.max(1e-4,Number(e.target.value)||0)),step:`0.0001`,type:`number`,value:p})]})]})]}),(0,a.jsxs)(`div`,{className:`pricing-table-heading`,children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`strong`,{children:u.catalog}),(0,a.jsx)(`p`,{children:u.pricesPerMillion})]}),(0,a.jsxs)(`span`,{children:[d.models.length,` `,u.models]})]}),(0,a.jsx)(`div`,{className:`pricing-table-wrap`,children:(0,a.jsxs)(`table`,{children:[(0,a.jsx)(`thead`,{children:(0,a.jsxs)(`tr`,{children:[(0,a.jsx)(`th`,{children:u.model}),(0,a.jsx)(`th`,{children:u.provider}),(0,a.jsx)(`th`,{children:u.input}),(0,a.jsx)(`th`,{children:u.cache}),(0,a.jsx)(`th`,{children:u.output}),(0,a.jsx)(`th`,{children:u.reasoning}),(0,a.jsx)(`th`,{children:u.priorityInput}),(0,a.jsx)(`th`,{children:u.priorityCache}),(0,a.jsx)(`th`,{children:u.priorityOutput}),(0,a.jsx)(`th`,{children:u.priorityReasoning}),(0,a.jsx)(`th`,{children:u.contextLimit}),(0,a.jsx)(`th`,{children:u.inputMultiplier}),(0,a.jsx)(`th`,{children:u.outputMultiplier}),(0,a.jsx)(`th`,{})]})}),(0,a.jsx)(`tbody`,{children:d.models.map((e,t)=>(0,a.jsxs)(`tr`,{children:[(0,a.jsxs)(`td`,{children:[(0,a.jsx)(`input`,{"aria-label":u.model,onChange:e=>_(t,{id:e.target.value}),value:e.id}),(0,a.jsx)(`small`,{children:e.aliases.join(`, `)||u.noAliases})]}),(0,a.jsx)(`td`,{children:(0,a.jsxs)(`select`,{onChange:e=>_(t,{provider:e.target.value}),value:e.provider,children:[(0,a.jsx)(`option`,{value:`openai`,children:`OpenAI`}),(0,a.jsx)(`option`,{value:`anthropic`,children:`Anthropic`})]})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.input_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{cached_input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.cached_input_per_million_usd??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{output_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.output_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{reasoning_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.reasoning_per_million_usd??0})}),[`priority_input_per_million_usd`,`priority_cached_input_per_million_usd`,`priority_output_per_million_usd`,`priority_reasoning_per_million_usd`].map(n=>(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{[n]:v(e.target.value)}),step:`0.001`,type:`number`,value:e[n]??0})},n)),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{long_context_threshold_tokens:v(e.target.value)||null}),step:`1`,type:`number`,value:e.long_context_threshold_tokens??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_input_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_input_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_output_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_output_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`button`,{"aria-label":u.removeModel,onClick:()=>f(e=>({...e,models:e.models.filter((e,n)=>n!==t)})),type:`button`,children:`×`})})]},e.id))})]})}),(0,a.jsxs)(`footer`,{children:[(0,a.jsxs)(`button`,{onClick:()=>f(e=>({...e,models:[...e.models,s(n)]})),type:`button`,children:[`+ `,u.addModel]}),(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`button`,{onClick:o,type:`button`,children:u.cancel}),(0,a.jsx)(`button`,{disabled:h,onClick:async()=>{g(!0);try{await c(d),await l(p),o()}finally{g(!1)}},type:`button`,children:h?u.saving:u.save})]})]})]})})}function s(e=`pt-BR`){let t=r[e];return{id:t.newModel,provider:`openai`,aliases:[],input_per_million_usd:0,cached_input_per_million_usd:0,output_per_million_usd:0,reasoning_per_million_usd:0,priority_input_per_million_usd:null,priority_cached_input_per_million_usd:null,priority_output_per_million_usd:null,priority_reasoning_per_million_usd:null,reasoning_billed_separately:!1,long_context_threshold_tokens:null,long_context_input_multiplier:1,long_context_output_multiplier:1,source_label:t.manualOverride,source_url:`https://developers.openai.com/api/docs/pricing`,notes:[t.editedNote]}}export{o as PricingSettingsPage};