@zaip-ai/cli 3.1.0 → 3.2.0

package/templates/.agents/dashboard/.zaip-managed.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "version": "3.1.0",
+  "version": "3.2.0",
   "files": [
     {
       "path": "DATA-DICTIONARY.md",
@@ -15,16 +15,16 @@
       "sha256": "3f4fc781faa21265aef25968176a9c2177749bea7108aeb4d3b2dc1ffca6ad43"
     },
     {
-      "path": "apps/frontend/dist/assets/DashboardHelpDialog-DIWDmvAS.js",
-      "sha256": "25ee6f081645e6ae46153ccb5795babd6cf53a7ef96474910a1fbf6e096bdd4c"
+      "path": "apps/frontend/dist/assets/DashboardHelpDialog-BzaUTZDx.js",
+      "sha256": "2dc5076e390a916fa30aa33cdd7e2293714a3a7d0e05dd972ac3972f2222a1ce"
     },
     {
       "path": "apps/frontend/dist/assets/DashboardHelpDialog-Je5nK-Et.css",
       "sha256": "aafa708825ff8417d2de8ce9f45b94c899aa9ae5c5068bf5ce4def13e9c00643"
     },
     {
-      "path": "apps/frontend/dist/assets/PricingSettingsDialog-BBRBKaHa.js",
-      "sha256": "fbd655650e3a8bbd65d4bd5391f880646a2e5f4033c2710bddb9cf9e3746ab31"
+      "path": "apps/frontend/dist/assets/PricingSettingsDialog-21cCJik-.js",
+      "sha256": "31b628635de02d6b99edadb7109b2945e701a54bee64a1f83e7c970df71ae9f7"
     },
     {
       "path": "apps/frontend/dist/assets/ProjectSettingsPage-B9GWkEyN.css",
@@ -34,14 +34,14 @@
       "path": "apps/frontend/dist/assets/ProjectSettingsPage-BAvLPAee.js",
       "sha256": "8b25f800f359b01362660c53aacddd93132314bfcb2e44ee63bffc98a1bea2d0"
     },
-    {
-      "path": "apps/frontend/dist/assets/TraceabilityWorkspace-C9dDhj34.js",
-      "sha256": "1906e1e29b756d1edef5683028b408f9129a1626cfbaa09528db9496c25ff85f"
-    },
     {
       "path": "apps/frontend/dist/assets/TraceabilityWorkspace-DvvavDLY.css",
       "sha256": "2dc93c190042edd2f5c585aab941bcaa5506aa1a8b5f26afa6e99996ce957e35"
     },
+    {
+      "path": "apps/frontend/dist/assets/TraceabilityWorkspace-wqW52uCx.js",
+      "sha256": "3e0367613fec5ee821f6d6e20646e6cc8965cfe2bae7e1439797cea5a0d215f4"
+    },
     {
       "path": "apps/frontend/dist/assets/cost-monitor-06__WZco.js",
       "sha256": "15eb72e8eb2b23f0fbe75595a5a3df94b4cfd1d0c18d9f662265d39064a7e2cc"
@@ -51,21 +51,21 @@
       "sha256": "158f796dfd3df65cf5bbddcafc1c2c62f4ad01b3df85674136a546640c284901"
     },
     {
-      "path": "apps/frontend/dist/assets/dashboard-localization-CoAVMZN6.js",
-      "sha256": "80e2218061595d8262fe2947214cb0b517351a84471281a89a2c8480fe070c8d"
+      "path": "apps/frontend/dist/assets/dashboard-localization-BkAm8-h4.js",
+      "sha256": "ab7a1944b494ef2f5b7e3fb86b73b51ada27b6dd13c5f2b11f8b3d119f981229"
     },
     {
       "path": "apps/frontend/dist/assets/icons-vendor-DEmo6Tn2.js",
       "sha256": "d9f5e923effa1a49d9d1856747b39f9606a098f292ec0a64ca9b91531d3118a0"
     },
-    {
-      "path": "apps/frontend/dist/assets/index-BVzw_Wux.js",
-      "sha256": "54378872be9cc1286afa9fd9e1fa2f1d72d117a1f31e6d88eecfb66d252e6851"
-    },
     {
       "path": "apps/frontend/dist/assets/index-Cmlx8OYH.css",
       "sha256": "555bd23c75cfa58812d58124f31c3897a581f6b94c7998ec9db7aff9fa8ddd29"
     },
+    {
+      "path": "apps/frontend/dist/assets/index-DqZKJS8y.js",
+      "sha256": "27f93f27e8c9da2cbf153b97105cc7b323d7d57b495d369102f88f86545da297"
+    },
     {
       "path": "apps/frontend/dist/assets/logo_novo_azul-BBx5pA2B.png",
       "sha256": "bb6043bda9fc53a111aaea4d6a004559b9ce8a3569691c060d217a7c6aafa0ae"
@@ -92,7 +92,7 @@
     },
     {
       "path": "apps/frontend/dist/index.html",
-      "sha256": "fd92ab8eb43435cb9729c099c05249f3ce38061ce5d13c945a580a4387895114"
+      "sha256": "e3ea78ef652d7b16f51894fd324ee90724acd4070ff9808dc7c0df3f6c5e0441"
     },
     {
       "path": "apps/frontend/dist/logo_novo_azul.png",
@@ -104,7 +104,7 @@
     },
     {
       "path": "apps/frontend/package.json",
-      "sha256": "760ed6b8e363479454c60d98a36e972763c2269ed341e85a001728daf16e7976"
+      "sha256": "b8a2fb6b73df169736f26bc57ce8b32d3d1f35b993139d27b252ac6ea666897f"
     },
     {
       "path": "apps/frontend/playwright.dom.config.ts",
@@ -524,7 +524,7 @@
     },
     {
       "path": "modules/cost-monitor/package.json",
-      "sha256": "123b7ade021f0402e9cc195ec70eecfc655bda082af32b2c284d8056bc63aee8"
+      "sha256": "ead689f93a08bdbed9aeb39f44af20a5a84bcc6aed2e6b9a4f0735754e979565"
     },
     {
       "path": "modules/cost-monitor/src/agent-groups.test.ts",
@@ -892,7 +892,7 @@
     },
     {
       "path": "modules/operations/package.json",
-      "sha256": "e6de6df73548f07e58ae046ab9fac7d6bd65274d4061d7106b8b9b087e69234d"
+      "sha256": "75f6989f122fb6c88e229dc1854cb36d9a207a78b6e8b17499ba07cbc05385e0"
     },
     {
       "path": "modules/operations/src/contracts.ts",
@@ -1544,7 +1544,7 @@
     },
     {
       "path": "modules/traceability/package.json",
-      "sha256": "55d4abeb5bedf99056e551de85b5180670b2177a331453be314bc1f7b8ec3434"
+      "sha256": "914a7f3be441833a64a8bef8817d6f9aba4f58b8b1d63c79e31d259c5fbf12d0"
     },
     {
       "path": "modules/traceability/src/contracts.ts",
@@ -1616,7 +1616,7 @@
     },
     {
       "path": "packages/branding/package.json",
-      "sha256": "da96feffe33880186526930eb777a44254375b71c81278a5e34b312ccbe78cbe"
+      "sha256": "b229412a0309f918721b1f6251abb509e4b12e9410c19baaae6d1a975c7a6972"
     },
     {
       "path": "packages/branding/src/index.ts",
@@ -1628,7 +1628,7 @@
     },
     {
       "path": "packages/contracts/package.json",
-      "sha256": "9fe4950036f24ebcff18d524ca3488f7b398262525708dfa4aa114ddbd77c5d7"
+      "sha256": "9057f94ea9367743635ca3c4e2a2821990016bb4fb067c106a94694a9bf8ed07"
     },
     {
       "path": "packages/contracts/src/export.ts",
@@ -1648,7 +1648,7 @@
     },
     {
       "path": "packages/data-export/package.json",
-      "sha256": "98bcc4776a4fbbb017bcc7a9d60416fe019c1f353ea8d6708cf8654819a4ea08"
+      "sha256": "9d65d7c046d7cdb41e1d35e50388802c6234baf7b485bfa79da213f26c8859cc"
     },
     {
       "path": "packages/data-export/src/index.test.ts",
@@ -1680,7 +1680,7 @@
     },
     {
       "path": "packages/local-runtime/package.json",
-      "sha256": "9ff6e2359301c4799a9defb2fd7f48d001fecf624d261215326adaf3387772f8"
+      "sha256": "558b1cba62b725eb2d36281172ba141bf21a7c28301bda5d146d289272c271b1"
     },
     {
       "path": "packages/local-runtime/scripts/build-sqlite-dashboard.mjs",
@@ -2388,7 +2388,7 @@
     },
     {
       "path": "packages/ui/package.json",
-      "sha256": "926db2d58db454127068cc6eb7c00726649bdc2cbe621637b43fccedd92d9c7b"
+      "sha256": "f450f55b60edf5e7b4f2f494bd86b30f6565051934b3d03f7498de9055c56d7a"
     },
     {
       "path": "packages/ui/src/DashboardHeader.test.mjs",
@@ -2492,7 +2492,7 @@
     },
     {
       "path": "tests/e2e/package.json",
-      "sha256": "3cf098e3df2fa4393ff41d95a60d5120f19d2cf58c1407b2a20eaea2b0efeb9f"
+      "sha256": "d2826cbe221e4159c098fb21cf1c4f26df3b400390556f49ac02b84744a8b29e"
     },
     {
       "path": "tests/e2e/playwright.config.ts",

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

@@ -1,4 +1,4 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{t as r}from"./dashboard-localization-CoAVMZN6.js";var i=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{t as r}from"./dashboard-localization-BkAm8-h4.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.
@@ -1158,7 +1158,7 @@ Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
 explicitamente autorizada, mesmo que existam Evidences aprovadas.
 
 O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statements e 75% para branches. Uma medição atual abaixo disso pode ser registrada como baseline observada para diagnóstico, mas o gate continua vermelho. Release crítica também exige unit, E2E, arquitetura, CQRS, módulos, profile, segurança, testes negativos, paridade da distribuição e cleanroom do candidato exato.
-`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- Git;\n- permissões de escrita no repositório consumidor.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nNovos templates mantêm a seleção do principal em `manual` e configuram\n`execution.runtime: managed` para PRD/SPEC, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.\nO Essencial nunca usa Astra automático. Principal avulso preserva a seleção\nmanual; filhos necessários seguem política divulgada. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e `CLAUDE.md`, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. `implemente` sem alvo abre apenas uma Conversation de planejamento, em `draft` finaliza o plano, em `ready` executa e em estados ativos/falhos continua, retoma ou cria rework. `desenvolva|melhore|aprimore` nunca executa automaticamente. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
+`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- permissões de escrita no repositório consumidor.\n\nGit, identidade de autor, repositório, commit inicial e configuração do GitHub\npodem ser preparados depois da instalação. O runtime exige Git e histórico local\nantes de iniciar entregas; essa exigência não bloqueia `init`.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Resumo e próximos passos\n\nA instalação informa a versão instalada com link para sua página no npm,\ncontagens reais de arquivos e resultados de SQLite e `doctor`. O link usa\n`https://www.npmjs.com/package/@zaip-ai/cli/v/<versão-instalada>`.\n\nQuando o GitHub ainda precisa de configuração, a última pergunta é:\n**Gostaria de ajuda para configurar o GitHub?**\nSe a configuração local já estiver identificada, a pergunta será:\n**Gostaria de ajuda com a configuração inicial do projeto?**\nConfiguração local não comprova autenticação remota.\n\nNo terminal, a pergunta é textual: o comando encerra normalmente. No chat,\nresponder “sim” encaminha à skill de GitHub ou de configuração do projeto.\nA skill apresenta o que pode configurar e coleta as escolhas antes de editar.\nConcluído o GitHub, oferece a configuração do projeto; concluído o projeto,\nencerra o onboarding. Uma recusa ou adiamento encerra a oferta sem insistência.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nNovos templates mantêm a seleção do principal em `manual` e configuram\n`execution.runtime: managed` para PRD/SPEC, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.\nO Essencial nunca usa Astra automático. Principal avulso preserva a seleção\nmanual; filhos necessários seguem política divulgada. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e `CLAUDE.md`, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. `implemente` sem alvo abre apenas uma Conversation de planejamento, em `draft` finaliza o plano, em `ready` executa e em estados ativos/falhos continua, retoma ou cria rework. `desenvolva|melhore|aprimore` nunca executa automaticamente. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
 
 Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
 
@@ -2811,7 +2811,7 @@ Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\`
 
 Use a versão de pnpm fixada em \`packageManager\` (\`corepack pnpm\` quando disponível). Para uma alteração delimitada, selecione os checks pertinentes ao risco e ao diff; a lista acima não exige repetir todos os testes a cada edição documental. Qualificação de release usa os gates completos do [guia 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) no candidato exato. Não confunda \`validate:github:prepared\`, execução local, push e CI terminal verde.
 
-Os manifests deste checkout registram o candidato \`3.1.0\` (produto \`3.1\`). A identificação do candidato não significa que o \`latest\` já foi publicado nem certifica produção. A release exige revisão exata, CI terminal, integridade do TGZ e instalação real do artefato. Tentativas e limitações ficam nas evidências da Change; resultados locais e publicação são estados distintos.
+Os manifests deste checkout registram o candidato \`3.2.0\` (produto \`3.2\`). A identificação do candidato não significa que o \`latest\` já foi publicado nem certifica produção. A release exige revisão exata, CI terminal, integridade do TGZ e instalação real do artefato. Tentativas e limitações ficam nas evidências da Change; resultados locais e publicação são estados distintos.
 
 A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.
 

package/templates/.agents/dashboard/apps/frontend/dist/assets/{PricingSettingsDialog-BBRBKaHa.js → PricingSettingsDialog-21cCJik-.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{n as r}from"./dashboard-localization-CoAVMZN6.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-06__WZco.js";import{n as r}from"./dashboard-localization-BkAm8-h4.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};

package/templates/.agents/dashboard/apps/frontend/dist/assets/{TraceabilityWorkspace-C9dDhj34.js → TraceabilityWorkspace-wqW52uCx.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{n as r}from"./traceability-BzKK8kK3.js";import{t as i}from"./index-BVzw_Wux.js";var a=e(t(),1),o=n();function s(e,t){let n=t.trim().toLocaleLowerCase();return n===``?[...e]:e.filter(e=>`${e.title} ${e.id}`.toLocaleLowerCase().includes(n))}function c(e,t,n){return n?[...e]:s(e,t)}function l(e){return`traceability-task-option-${e}`}function u({locale:e,loadingTaskId:t,hasMoreTasks:n,isLoadingTasks:s,onLoadMoreTasks:u,onSelectTask:d,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,selectedTaskId:h,tasks:g,trace:_}){let v=[...g].sort((e,t)=>Date.parse(t.created_at)-Date.parse(e.created_at)),y=v.find(e=>e.id===h),[b,x]=(0,a.useState)(()=>y?.title??h),[S,C]=(0,a.useState)(!1),[w,T]=(0,a.useState)(!1),[E,D]=(0,a.useState)(0),[O,k]=(0,a.useState)(12),A=(0,a.useMemo)(()=>c(v,b,w),[b,w,v]),j=A.slice(0,O),M=j.length<A.length,N=`traceability-task-search`,P=`traceability-task-results`,F=e===`pt-BR`?`Task selecionada`:`Selected task`,I=e===`pt-BR`?`Buscar task por nome ou ID`:`Search task by name or ID`,L=S?A[E]?.id:void 0;(0,a.useEffect)(()=>{x(y?.title??h),D(0)},[y?.title,h]);let R=e=>{x(e.title),C(!1),T(!1),d(e.id)},z=(e=!0)=>{C(!0),T(!0),e&&(D(0),k(12))};return(0,o.jsxs)(`section`,{className:`traceability-workspace`,children:[(0,o.jsxs)(`header`,{children:[(0,o.jsxs)(`div`,{children:[(0,o.jsx)(`label`,{htmlFor:N,children:F}),(0,o.jsx)(`input`,{"aria-activedescendant":L===void 0?void 0:l(L),"aria-autocomplete":`list`,"aria-controls":P,"aria-expanded":S,"aria-label":I,id:N,onChange:e=>{x(e.target.value),D(0),T(!1),k(12),C(!0)},onClick:()=>z(),onFocus:()=>z(),onKeyDown:e=>{if(e.key===`ArrowDown`)e.preventDefault(),z(!1),D(e=>Math.min(e+1,Math.max(0,v.length-1)));else if(e.key===`ArrowUp`)e.preventDefault(),z(!1),D(e=>Math.max(0,e-1));else if(e.key===`Enter`&&S){let t=A[E];t!==void 0&&(e.preventDefault(),R(t))}else e.key===`Escape`&&C(!1)},role:`combobox`,type:`search`,value:b}),S?(0,o.jsx)(`div`,{"aria-label":I,className:`traceability-task-results`,id:P,onScroll:e=>{let{clientHeight:t,scrollHeight:r,scrollTop:a}=e.currentTarget;a+t<r-32||(n&&u(),j.length<A.length&&k(e=>i(e,A.length,12)))},role:`listbox`,children:A.length>0?j.map((e,t)=>(0,o.jsx)(`div`,{role:`presentation`,children:(0,o.jsx)(`button`,{"aria-selected":e.id===h,className:t===E?`is-active`:void 0,id:l(e.id),onClick:()=>R(e),role:`option`,type:`button`,children:(0,o.jsx)(`strong`,{children:e.title})})},e.id)):(0,o.jsx)(`div`,{className:`traceability-task-no-results`,role:`status`,children:e===`pt-BR`?`Nenhuma task encontrada.`:`No tasks found.`})}):null,S&&A.length>0?(0,o.jsx)(`p`,{"aria-live":`polite`,className:`traceability-task-pagination-status`,role:`status`,children:s?e===`pt-BR`?`Carregando mais tasks…`:`Loading more tasks…`:M||n?e===`pt-BR`?`${j.length} de ${A.length} tasks exibidas. Role para carregar mais.`:`${j.length} of ${A.length} tasks shown. Scroll to load more.`:e===`pt-BR`?`${A.length} tasks exibidas. Fim da lista.`:`${A.length} tasks shown. End of list.`}):null]}),(0,o.jsx)(`small`,{children:e===`pt-BR`?`Selecione pelo nome para visualizar o ciclo completo sem precisar do ID.`:`Select by name to inspect the complete lifecycle without knowing the ID.`})]}),t?(0,o.jsx)(`div`,{"aria-live":`polite`,className:`traceability-workspace-loading`,children:e===`pt-BR`?`Carregando as 6 etapas…`:`Loading all 6 stages…`}):_?(0,o.jsx)(r,{embedded:!0,locale:e,onClose:()=>void 0,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,trace:_}):(0,o.jsx)(`p`,{children:e===`pt-BR`?`Nenhuma task disponível.`:`No task available.`})]})}export{u as TraceabilityWorkspace};
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-06__WZco.js";import{n as r}from"./traceability-BzKK8kK3.js";import{t as i}from"./index-DqZKJS8y.js";var a=e(t(),1),o=n();function s(e,t){let n=t.trim().toLocaleLowerCase();return n===``?[...e]:e.filter(e=>`${e.title} ${e.id}`.toLocaleLowerCase().includes(n))}function c(e,t,n){return n?[...e]:s(e,t)}function l(e){return`traceability-task-option-${e}`}function u({locale:e,loadingTaskId:t,hasMoreTasks:n,isLoadingTasks:s,onLoadMoreTasks:u,onSelectTask:d,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,selectedTaskId:h,tasks:g,trace:_}){let v=[...g].sort((e,t)=>Date.parse(t.created_at)-Date.parse(e.created_at)),y=v.find(e=>e.id===h),[b,x]=(0,a.useState)(()=>y?.title??h),[S,C]=(0,a.useState)(!1),[w,T]=(0,a.useState)(!1),[E,D]=(0,a.useState)(0),[O,k]=(0,a.useState)(12),A=(0,a.useMemo)(()=>c(v,b,w),[b,w,v]),j=A.slice(0,O),M=j.length<A.length,N=`traceability-task-search`,P=`traceability-task-results`,F=e===`pt-BR`?`Task selecionada`:`Selected task`,I=e===`pt-BR`?`Buscar task por nome ou ID`:`Search task by name or ID`,L=S?A[E]?.id:void 0;(0,a.useEffect)(()=>{x(y?.title??h),D(0)},[y?.title,h]);let R=e=>{x(e.title),C(!1),T(!1),d(e.id)},z=(e=!0)=>{C(!0),T(!0),e&&(D(0),k(12))};return(0,o.jsxs)(`section`,{className:`traceability-workspace`,children:[(0,o.jsxs)(`header`,{children:[(0,o.jsxs)(`div`,{children:[(0,o.jsx)(`label`,{htmlFor:N,children:F}),(0,o.jsx)(`input`,{"aria-activedescendant":L===void 0?void 0:l(L),"aria-autocomplete":`list`,"aria-controls":P,"aria-expanded":S,"aria-label":I,id:N,onChange:e=>{x(e.target.value),D(0),T(!1),k(12),C(!0)},onClick:()=>z(),onFocus:()=>z(),onKeyDown:e=>{if(e.key===`ArrowDown`)e.preventDefault(),z(!1),D(e=>Math.min(e+1,Math.max(0,v.length-1)));else if(e.key===`ArrowUp`)e.preventDefault(),z(!1),D(e=>Math.max(0,e-1));else if(e.key===`Enter`&&S){let t=A[E];t!==void 0&&(e.preventDefault(),R(t))}else e.key===`Escape`&&C(!1)},role:`combobox`,type:`search`,value:b}),S?(0,o.jsx)(`div`,{"aria-label":I,className:`traceability-task-results`,id:P,onScroll:e=>{let{clientHeight:t,scrollHeight:r,scrollTop:a}=e.currentTarget;a+t<r-32||(n&&u(),j.length<A.length&&k(e=>i(e,A.length,12)))},role:`listbox`,children:A.length>0?j.map((e,t)=>(0,o.jsx)(`div`,{role:`presentation`,children:(0,o.jsx)(`button`,{"aria-selected":e.id===h,className:t===E?`is-active`:void 0,id:l(e.id),onClick:()=>R(e),role:`option`,type:`button`,children:(0,o.jsx)(`strong`,{children:e.title})})},e.id)):(0,o.jsx)(`div`,{className:`traceability-task-no-results`,role:`status`,children:e===`pt-BR`?`Nenhuma task encontrada.`:`No tasks found.`})}):null,S&&A.length>0?(0,o.jsx)(`p`,{"aria-live":`polite`,className:`traceability-task-pagination-status`,role:`status`,children:s?e===`pt-BR`?`Carregando mais tasks…`:`Loading more tasks…`:M||n?e===`pt-BR`?`${j.length} de ${A.length} tasks exibidas. Role para carregar mais.`:`${j.length} of ${A.length} tasks shown. Scroll to load more.`:e===`pt-BR`?`${A.length} tasks exibidas. Fim da lista.`:`${A.length} tasks shown. End of list.`}):null]}),(0,o.jsx)(`small`,{children:e===`pt-BR`?`Selecione pelo nome para visualizar o ciclo completo sem precisar do ID.`:`Select by name to inspect the complete lifecycle without knowing the ID.`})]}),t?(0,o.jsx)(`div`,{"aria-live":`polite`,className:`traceability-workspace-loading`,children:e===`pt-BR`?`Carregando as 6 etapas…`:`Loading all 6 stages…`}):_?(0,o.jsx)(r,{embedded:!0,locale:e,onClose:()=>void 0,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,trace:_}):(0,o.jsx)(`p`,{children:e===`pt-BR`?`Nenhuma task disponível.`:`No task available.`})]})}export{u as TraceabilityWorkspace};

package/templates/.agents/dashboard/apps/frontend/dist/assets/{dashboard-localization-CoAVMZN6.js → dashboard-localization-BkAm8-h4.js}

@@ -728,7 +728,7 @@ pnpm build
 
 Before integrating a relevant change or preparing a release, \`pnpm verify\` runs the complete repository pipeline, including additional tool, contract, generation, workspace, runtime-parity, and release-test gates. This pipeline only validates the lock; if a managed file was intentionally changed, run sync first. Use the pnpm version fixed in \`packageManager\` (\`corepack pnpm\` when available). For a bounded change, choose checks appropriate to its risk and diff; the list does not require repeating every test for each documentation edit. Release qualification uses the complete gates in [guide 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) on the exact candidate. Do not conflate \`validate:github:prepared\`, local execution, push, and a green terminal CI.
 
-This checkout's manifests identify candidate \`3.1.0\` (product \`3.1\`). Candidate identity does not mean \`latest\` has been published or certify production. Release requires the exact revision, terminal CI, TGZ integrity, and a real artifact installation. Attempts and limitations remain in the Change evidence; local results and publication are distinct states.
+This checkout's manifests identify candidate \`3.2.0\` (product \`3.2\`). Candidate identity does not mean \`latest\` has been published or certify production. Release requires the exact revision, terminal CI, TGZ integrity, and a real artifact installation. Attempts and limitations remain in the Change evidence; local results and publication are distinct states.
 
 The detailed architecture is summarized in this README's [Application architecture](#application-architecture) section.