@zaip-ai/cli 3.0.0 → 3.2.0

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

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "version": "3.0.0",
+  "version": "3.2.0",
   "files": [
     {
       "path": "DATA-DICTIONARY.md",
@@ -15,16 +15,16 @@
       "sha256": "3f4fc781faa21265aef25968176a9c2177749bea7108aeb4d3b2dc1ffca6ad43"
     },
     {
-      "path": "apps/frontend/dist/assets/DashboardHelpDialog-Je5nK-Et.css",
-      "sha256": "aafa708825ff8417d2de8ce9f45b94c899aa9ae5c5068bf5ce4def13e9c00643"
+      "path": "apps/frontend/dist/assets/DashboardHelpDialog-BzaUTZDx.js",
+      "sha256": "2dc5076e390a916fa30aa33cdd7e2293714a3a7d0e05dd972ac3972f2222a1ce"
     },
     {
-      "path": "apps/frontend/dist/assets/DashboardHelpDialog-TnrL1ZyZ.js",
-      "sha256": "322676a006e5186a18b9974750e488ad6bce1d2d85ae6f640dcd32db6e8c5af8"
+      "path": "apps/frontend/dist/assets/DashboardHelpDialog-Je5nK-Et.css",
+      "sha256": "aafa708825ff8417d2de8ce9f45b94c899aa9ae5c5068bf5ce4def13e9c00643"
     },
     {
-      "path": "apps/frontend/dist/assets/PricingSettingsDialog-DjQpBqGU.js",
-      "sha256": "9b425e56fe8309acd40084e5e4043dab581ac029bdf68192426d0d3731cd4d7e"
+      "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-BQZXUnQu.js",
-      "sha256": "17167537ce118295cccb94f0bf4cb28fe84a357c963e61e9be1012515c0cd95f"
-    },
     {
       "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-Basaw1NR.js",
-      "sha256": "5becbb6d712a1893e8e4086c78c26f5a606731f68cfd16ed2ffb5429d4f380a7"
+      "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-BQe3zTvL.js",
-      "sha256": "3a6184f2e9ba3a6da6113fa9866e9349bb6ea3ae1edd26a452e642fe3a35afe4"
-    },
     {
       "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": "fb6bd884d9fb594ea77ca2fafd943ec61350d34a0ab4a7b4db5bad8d164fead3"
+      "sha256": "e3ea78ef652d7b16f51894fd324ee90724acd4070ff9808dc7c0df3f6c5e0441"
     },
     {
       "path": "apps/frontend/dist/logo_novo_azul.png",
@@ -104,7 +104,7 @@
     },
     {
       "path": "apps/frontend/package.json",
-      "sha256": "4e2ef258ea7c6de221e3690aa52cd1df60e508b798a6afd78f0fda2c68eded1d"
+      "sha256": "b8a2fb6b73df169736f26bc57ce8b32d3d1f35b993139d27b252ac6ea666897f"
     },
     {
       "path": "apps/frontend/playwright.dom.config.ts",
@@ -524,7 +524,7 @@
     },
     {
       "path": "modules/cost-monitor/package.json",
-      "sha256": "2b741addc003419541a70a9381b1933c782468ee571a8f24b504608278152cd0"
+      "sha256": "ead689f93a08bdbed9aeb39f44af20a5a84bcc6aed2e6b9a4f0735754e979565"
     },
     {
       "path": "modules/cost-monitor/src/agent-groups.test.ts",
@@ -892,7 +892,7 @@
     },
     {
       "path": "modules/operations/package.json",
-      "sha256": "00408130c19ea8396a66b287d19974d540e5b548fc3a08c639779105573d21e7"
+      "sha256": "75f6989f122fb6c88e229dc1854cb36d9a207a78b6e8b17499ba07cbc05385e0"
     },
     {
       "path": "modules/operations/src/contracts.ts",
@@ -1544,7 +1544,7 @@
     },
     {
       "path": "modules/traceability/package.json",
-      "sha256": "2b6e7565b0e9ec642741f0965e708dcb41ea9b88cb3e01f7c311ef1228121cac"
+      "sha256": "914a7f3be441833a64a8bef8817d6f9aba4f58b8b1d63c79e31d259c5fbf12d0"
     },
     {
       "path": "modules/traceability/src/contracts.ts",
@@ -1616,7 +1616,7 @@
     },
     {
       "path": "packages/branding/package.json",
-      "sha256": "2d7d3b54d70d230cb2a75d3e9c0b504f383d66c6c6103832d99f62663d467e84"
+      "sha256": "b229412a0309f918721b1f6251abb509e4b12e9410c19baaae6d1a975c7a6972"
     },
     {
       "path": "packages/branding/src/index.ts",
@@ -1628,7 +1628,7 @@
     },
     {
       "path": "packages/contracts/package.json",
-      "sha256": "85aa4362c5503bef637e379b53d861bc2bd7f8698449e20c150558e3433f20ad"
+      "sha256": "9057f94ea9367743635ca3c4e2a2821990016bb4fb067c106a94694a9bf8ed07"
     },
     {
       "path": "packages/contracts/src/export.ts",
@@ -1648,7 +1648,7 @@
     },
     {
       "path": "packages/data-export/package.json",
-      "sha256": "5257dccadc3582bb22732cdae13c797d5cb1b44ffb11afadd9f83052e3e8833c"
+      "sha256": "9d65d7c046d7cdb41e1d35e50388802c6234baf7b485bfa79da213f26c8859cc"
     },
     {
       "path": "packages/data-export/src/index.test.ts",
@@ -1672,15 +1672,15 @@
     },
     {
       "path": "packages/local-runtime/dist/server.cjs",
-      "sha256": "ef91f0689a81355a00bb52d6a54cf1b71e552966d9f1f05ca0685db46d50dbf8"
+      "sha256": "4f0833ead303c6e8624e832b89f66f32b43310a98a71b72b074d9d8a0f383d0e"
     },
     {
       "path": "packages/local-runtime/dist/sqlite-read-model.cjs",
-      "sha256": "427438e0caef5ff8cf44052e01fdef797d9e2d6e489b92021fc347d66ef85e1c"
+      "sha256": "81d95603efc97c81056bfb0224a0060b5917016331ddc2ddde5a9a62d072bf4d"
     },
     {
       "path": "packages/local-runtime/package.json",
-      "sha256": "c056880d49bc168bee49e47801c6265d1f975224da0c0b8fae4784573109b3d2"
+      "sha256": "558b1cba62b725eb2d36281172ba141bf21a7c28301bda5d146d289272c271b1"
     },
     {
       "path": "packages/local-runtime/scripts/build-sqlite-dashboard.mjs",
@@ -1716,7 +1716,7 @@
     },
     {
       "path": "packages/local-runtime/server.mjs",
-      "sha256": "a14377e0c316bfd80b6e2fe35c65837f64bf3ca2b759e1f3e0cbeeec16bfc906"
+      "sha256": "d9d8efc5c5de005ac82a170bebd4fba7ca000220d88ea3e6489a100979396b5a"
     },
     {
       "path": "packages/local-runtime/src/active-codex-telemetry.ts",
@@ -1990,6 +1990,14 @@
       "path": "packages/local-runtime/src/sqlite-artifact-counts.ts",
       "sha256": "d3848793a5ea15c111bdffee145567d9fe228d1ba4e05ac1bf1235b1a04230b5"
     },
+    {
+      "path": "packages/local-runtime/src/sqlite-calendar.ts",
+      "sha256": "51e94898a6d880540206be783bb58b5e769c6201dd59d022ad8c2f1ff2e084a8"
+    },
+    {
+      "path": "packages/local-runtime/src/sqlite-cold-parse.test.ts",
+      "sha256": "11038387fee61799588eab9e1ba653e7491a08bde923fea3c9780374ffd9bee7"
+    },
     {
       "path": "packages/local-runtime/src/sqlite-cost-agent-page.test.ts",
       "sha256": "dc08d1d3910fab570ceb3b4bffecd8242238275db66ee7e18d350bb742aef597"
@@ -2022,9 +2030,13 @@
       "path": "packages/local-runtime/src/sqlite-cost-group-page.ts",
       "sha256": "5a47bc2de937a1fc6c25e734ace484089db659b8821ace8846b3f71208a90698"
     },
+    {
+      "path": "packages/local-runtime/src/sqlite-cost-group-projection.test.ts",
+      "sha256": "2e2565ac2ab31571bc6ec3f8c40d4c4eb5ffcbd7b0c027571078352c94673fc2"
+    },
     {
       "path": "packages/local-runtime/src/sqlite-cost-group-projection.ts",
-      "sha256": "4ce520e135dfd6bd288b851f6492d70ff8914aeaa521108386ad614c890e2ea9"
+      "sha256": "525069fa2f244c845a28627814727e87253308f8db3a7352cf7745f04b78cd1f"
     },
     {
       "path": "packages/local-runtime/src/sqlite-cost-invocation-page.test.ts",
@@ -2038,6 +2050,14 @@
       "path": "packages/local-runtime/src/sqlite-cost-invocation-projection.ts",
       "sha256": "0b1c2ee187bd7325e9dddad5327cb78b7961c5de98d9370bc5b163a23935e087"
     },
+    {
+      "path": "packages/local-runtime/src/sqlite-duration-lookup.test.ts",
+      "sha256": "98e294c130b3917605ed3558bb353ce9567e441c00d6c523992a2338c658da60"
+    },
+    {
+      "path": "packages/local-runtime/src/sqlite-entity-label-views.test.ts",
+      "sha256": "06336df48d1cb6a79822acc9308e07aac17957e375702aa1e792929e7b18b2cb"
+    },
     {
       "path": "packages/local-runtime/src/sqlite-file-index.test.ts",
       "sha256": "1844385ffe7094c9aa3c8159f24e8e10f5612354f4245bf1d528e2384c9f3662"
@@ -2080,7 +2100,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-materialize-runs.ts",
-      "sha256": "aac0bf8d6546b208d1cbe7129705e12fefccf75f4474d47f359e524b4062d238"
+      "sha256": "6077a82fb259ba4211687ced44876127833ac1173d314f0803b6d7e7e735ef1f"
     },
     {
       "path": "packages/local-runtime/src/sqlite-metric-contract.test.ts",
@@ -2118,9 +2138,13 @@
       "path": "packages/local-runtime/src/sqlite-query-context.ts",
       "sha256": "3107a9a78277cd0a9d4c672055baa0aa9dfe09a0be58bb85f47592ebc1d3803d"
     },
+    {
+      "path": "packages/local-runtime/src/sqlite-query-entity-group.test.ts",
+      "sha256": "f9a651cff11bd58877df2fe71e1168e1f3b70eab25709e100a2e3c4395a999ec"
+    },
     {
       "path": "packages/local-runtime/src/sqlite-query-entity-group.ts",
-      "sha256": "7299ac4e8e6d04c7c1f2d6362fb54cf55bdf7108d4eee78d5dac6a76d7a18271"
+      "sha256": "b2228fdc36e4ef609f59e6824f7884fd0b4678e6c777d108352a01f93967d365"
     },
     {
       "path": "packages/local-runtime/src/sqlite-query-filtered-dimension.ts",
@@ -2160,11 +2184,11 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-canonical-parsing.ts",
-      "sha256": "c65eb3ff52070cb52c71e3887e13ad3c0c42620a1a4380e9e333492f43da36ab"
+      "sha256": "d723f12290cda7fa7d7d20e4e8cd3817984c36c2e07e010d244c946751021986"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-canonical.ts",
-      "sha256": "12b9a6e464e167177fe1cc2382e657bd525c3d170fc090ad6ff6b25e9a476d3c"
+      "sha256": "ab83b9595d91f57c24bc5871488531de6d0846d0c89908695980f81fd20eca58"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-counts-every-root-execution-day-returns.test.ts",
@@ -2184,7 +2208,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-keeps-orphan-telemetry-out-kanban-without.test.ts",
-      "sha256": "e5e2743281866223a380abda5f1ac08c8f3e8159d41bbf05f81fb2e65974eba8"
+      "sha256": "d84e1f629c678c6ed045327fc7c20ac4aaccf303708f0bc656ce373e335c759d"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-launch-progress.ts",
@@ -2208,7 +2232,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-rebuild.ts",
-      "sha256": "9b300847e09435846a4b6bab1e7ddfc6bd5e9b8469df4f3bc599594c22be07ad"
+      "sha256": "27b67f3e7923da48d2f9832a5e88a85776bfa9a77b49ff45a8dbdf12d6a2abfa"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-rebuilds-disposable-snapshot-serves-zaip-records.test.ts",
@@ -2216,7 +2240,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-schema.ts",
-      "sha256": "8e7fddc67eae853d8e74f404eac6f1ea76b722d7726fef01557e78610be26ca5"
+      "sha256": "bb94304b310285ed500872d1bb3742197a83681b6fc2489da1b9d95f44f45219"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model-source-fingerprint.test.ts",
@@ -2232,7 +2256,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model.test.ts",
-      "sha256": "98ae0ba22adfeb6d12920f1b33e52642ae9d67c70038f853ddbc8a6bdda6af65"
+      "sha256": "aa0ec4396c007d5ee60fbb97ea2a20e471abd8aca5a0f064df369dc179469cd8"
     },
     {
       "path": "packages/local-runtime/src/sqlite-read-model.ts",
@@ -2244,7 +2268,7 @@
     },
     {
       "path": "packages/local-runtime/src/sqlite-schema-base-views.ts",
-      "sha256": "6e85e008098125deabaeee529783b402470cba535be28b3256d612ca32d582fb"
+      "sha256": "d106f3a5ccdb54c32622d04912f30e3137d125b61c7f86d6e585eb76ec44aba7"
     },
     {
       "path": "packages/local-runtime/src/sqlite-schema-dashboard-views.ts",
@@ -2364,7 +2388,7 @@
     },
     {
       "path": "packages/ui/package.json",
-      "sha256": "91dfc651d17be8067bbe2db1a57bf188c8e03d8a4c3580b7219552d1cd8822a5"
+      "sha256": "f450f55b60edf5e7b4f2f494bd86b30f6565051934b3d03f7498de9055c56d7a"
     },
     {
       "path": "packages/ui/src/DashboardHeader.test.mjs",
@@ -2468,7 +2492,7 @@
     },
     {
       "path": "tests/e2e/package.json",
-      "sha256": "56ab5b978fcafe81879690ef5e093d5abcdfcf059428c0b17cc7327aa665d263"
+      "sha256": "d2826cbe221e4159c098fb21cf1c4f26df3b400390556f49ac02b84744a8b29e"
     },
     {
       "path": "tests/e2e/playwright.config.ts",

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-TnrL1ZyZ.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-Basaw1NR.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.
 
@@ -1816,13 +1816,19 @@ Testes passando comprovam validação técnica. Maturidade formal máxima exige
 
 Ausência de uma dessas provas permanece explícita; não é convertida em sucesso.
 
-## Novidades da v3 e qualificação pendente
+## Linha v3: implementação, qualificação e publicação
 
-As fontes em preparação incluem presets, diário durável por Task, replanejamento
-governado, relay de decisão Gui e configuração no Dashboard. Os manifests
-continuam em 2.6.0; este guia não promove versão nem certifica produção.
+A v3.0 foi publicada como \`@zaip-ai/cli@3.0.0\`, no commit
+\`ffc6c13867ec703211b7bba90c26b10a105c19fb\`. Presets, diário durável por Task,
+replanejamento governado, relay da decisão Gui e configuração no Dashboard estão
+implementados. A publicação possui qualificação local do candidato; não equivale
+a certificar todo workload de produção nem a concluir o PRD histórico.
 
-Para qualificar essas novidades, preserve um candidato único e comprove:
+Consulte a [matriz de implementação e prova](https://github.com/zaip-ai/zaip-aios/blob/main/docs/quality/v3-delivery-status.md).
+A versão atual vem dos manifests e de \`.agents/zaip-aios/VERSION\`; cada manutenção
+gera novo candidato e recibo, sem reutilizar aprovação ou mover a tag anterior.
+
+Para qualificar uma nova candidata dessa linha, preserve um SHA único e comprove:
 
 - Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente sem teto;
 - reservas antes do provider, replay/restart sem reset e resultado desconhecido
@@ -1843,10 +1849,15 @@ altera silenciosamente matrizes de CI publicadas. Relatórios de candidatos
 anteriores, testes simulados de modelos e evidência local não certificam
 o candidato final nem seu uso em produção.
 
-O [guia 19](19-assurance-e-autonomia.md) registra duas fronteiras ainda
-importantes: controle preventivo só no despacho gerenciado e compatibilidade
-do trabalho avulso direto com a barreira de executor capturado. Uma revisão
-documental não resolve esses limites por declaração.
+O [guia 19](19-assurance-e-autonomia.md) registra as fronteiras atuais: controle
+preventivo de cotas/modelos somente no despacho gerenciado; avulsa direta exige
+autorização explícita desde a captura e identidade observada, sem executor
+cerimonial. Revisão aplicável, Evidence e Gui continuam obrigatórios.
+
+O benchmark comparativo histórico T08 permanece sem aprovação. Otimizações
+com testes de correção e uma release publicada não comprovam economia ou SLA.
+Não repita automaticamente a matriz histórica falha: preserve o diagnóstico e
+defina uma medição independente com artefatos identificados e falhas observadas.
 `,A=`# Telemetria Git-native do Codex
 
 Este documento descreve o comportamento implementado da telemetria do Codex no ZAIP-AIOS. O
@@ -2415,6 +2426,10 @@ trabalho, fora do Kanban executável e dos indicadores operacionais sem rascunho
 
 ## Qualidade e evidências
 
+A [matriz de entrega da linha v3](docs/quality/v3-delivery-status.md) distingue
+melhorias implementadas, provas do candidato e tarefas históricas substituídas.
+Publicação não comprova economia nem conclui retroativamente o benchmark antigo.
+
 Qualidade faz parte da definição de pronto. Cada entrega combina testes, revisão e checks proporcionais ao seu risco, com comprovação objetiva dos Critérios de Aceite.
 
 As Evidence conectam validações aprovadas à Task, Change, Execution, Run, Critérios de Aceite e candidato. O [guia de revisão](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explica como registrar o procedimento realmente executado e seu resultado.
@@ -2796,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.0.0\` (produto \`3.0\`). A identificação do candidato não significa que o \`latest\` já foi publicado nem certifica produção. A release exige revisão exata, CI terminal, integridade do TGZ e instalação real do artefato. Tentativas e limitações ficam nas evidências da Change; resultados locais e publicação são estados distintos.
+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-DjQpBqGU.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-Basaw1NR.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-BQZXUnQu.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-BQe3zTvL.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-Basaw1NR.js → dashboard-localization-BkAm8-h4.js}

@@ -357,6 +357,10 @@ indicators that exclude drafts.
 
 ## Quality and evidence
 
+The [v3 delivery matrix](docs/quality/v3-delivery-status.md) distinguishes
+implemented improvements, candidate evidence and superseded historical work.
+Publication does not prove savings or retroactively approve the old benchmark.
+
 Quality is part of the definition of done. Each delivery combines tests, review, and checks proportionate to its risk, with objective proof of Acceptance Criteria. Evidence connects approved validations to the Task, Change, Execution, Run, Acceptance Criteria, and candidate. The [review guide](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explains how to record the procedure actually executed and its result.
 
 The current contract adds \`confirmed\`, \`limited\`, \`pending\`, \`failed\`, and \`not_applicable\` observations without replacing Validation/Evidence V2. The CLI validates structure and links; it does not run the declared command, inspect images, or query services automatically. Technical proof is not equivalent to visual proof, real integration, or production proof. Isolated or pending observations do not approve a delivery.
@@ -724,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.0.0\` (product \`3.0\`). 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.