izanagi-ai 3.19.0 → 3.21.0

package/.manifest

@@ -1,11 +1,11 @@
 {
   "name": "izanagi-ai",
-  "version": "3.19.0",
+  "version": "3.21.0",
   "description": "Izanagi AI - Modular Skill-Oriented AI Prompt & Agent Framework for Autonomous Software Engineering",
   "author": "Pedro Henrique Sanches Leal",
   "license": "MIT",
   "homepage": "https://github.com/pedrohenriquesanchesleal4-debug/izanagi-ai#readme",
-  "generatedAt": "2026-09-04T12:48:45.274Z",
+  "generatedAt": "2026-09-08T13:31:23.174Z",
   "agents": [
     {
       "id": "adversarial-critic",
@@ -541,7 +541,7 @@
         },
         {
           "id": "ai-slop",
-          "name": "Anti AI-Slop (Zero \"Cara de IA\")",
+          "name": "anti-ai-slop",
           "version": "1.0.0",
           "path": "skills/anti-ai-slop/SKILL.md"
         },
@@ -565,7 +565,7 @@
         },
         {
           "id": "architect",
-          "name": "Software Architect",
+          "name": "software-architect",
           "version": "1.0.0",
           "path": "skills/software-architect/SKILL.md"
         },
@@ -619,7 +619,7 @@
         },
         {
           "id": "billing",
-          "name": "Skill Payments & Billing — Izanagi",
+          "name": "payments-billing",
           "version": "1.0.0",
           "path": "skills/payments-billing/SKILL.md"
         },
@@ -703,7 +703,7 @@
         },
         {
           "id": "conversion-copywriting",
-          "name": "Skill Conversion Copywriting — Izanagi",
+          "name": "conversion-copywriting",
           "version": "1.0.0",
           "path": "skills/conversion-copywriting/SKILL.md"
         },
@@ -739,7 +739,7 @@
         },
         {
           "id": "deep-research",
-          "name": "Deep Research — Pesquisa Multi-Fonte com Síntese",
+          "name": "deep-research",
           "version": "1.0.0",
           "path": "skills/deep-research/SKILL.md"
         },
@@ -751,7 +751,7 @@
         },
         {
           "id": "design-directions",
-          "name": "Design Directions (Style Selector por Indústria)",
+          "name": "design-directions",
           "version": "1.0.0",
           "path": "skills/design-directions/SKILL.md"
         },
@@ -763,7 +763,7 @@
         },
         {
           "id": "design-system",
-          "name": "UI/UX Pro Max — Design Intelligence",
+          "name": "ui-ux-pro-max",
           "version": "1.0.0",
           "path": "skills/ui-ux-pro-max/SKILL.md"
         },
@@ -793,7 +793,7 @@
         },
         {
           "id": "editorial-layout",
-          "name": "Skill Editorial Layout — Izanagi",
+          "name": "editorial-layout",
           "version": "1.0.0",
           "path": "skills/editorial-layout/SKILL.md"
         },
@@ -817,7 +817,7 @@
         },
         {
           "id": "fan-out",
-          "name": "Parallel Agents (Fan-Out & Swarm Orchestration)",
+          "name": "parallel-agents",
           "version": "1.0.0",
           "path": "skills/parallel-agents/SKILL.md"
         },
@@ -835,13 +835,13 @@
         },
         {
           "id": "frontend",
-          "name": "Skill Frontend — Izanagi",
+          "name": "frontend",
           "version": "1.0.0",
           "path": "skills/frontend/SKILL.md"
         },
         {
           "id": "graphql",
-          "name": "Skill GraphQL — Izanagi",
+          "name": "graphql",
           "version": "1.0.0",
           "path": "skills/graphql/SKILL.md"
         },
@@ -871,7 +871,7 @@
         },
         {
           "id": "iac-terraform",
-          "name": "Skill IaC & Terraform — Izanagi",
+          "name": "iac-terraform",
           "version": "1.0.0",
           "path": "skills/iac-terraform/SKILL.md"
         },
@@ -883,7 +883,7 @@
         },
         {
           "id": "logging",
-          "name": "Logging Expert",
+          "name": "logging-expert",
           "version": "1.0.0",
           "path": "skills/logging-expert/SKILL.md"
         },
@@ -895,7 +895,7 @@
         },
         {
           "id": "memoria-projeto",
-          "name": "Memória do projeto",
+          "name": "memoria-projeto",
           "version": "1.0.0",
           "path": "skills/memoria-projeto/SKILL.md"
         },
@@ -919,7 +919,7 @@
         },
         {
           "id": "observability",
-          "name": "Observability Expert (Tracing Distribuído e Logs Estruturados)",
+          "name": "observability-expert",
           "version": "1.0.0",
           "path": "skills/observability-expert/SKILL.md"
         },
@@ -961,7 +961,7 @@
         },
         {
           "id": "qa",
-          "name": "Quality Assurance — Manual Operacional",
+          "name": "qa",
           "version": "1.0.0",
           "path": "skills/qa/SKILL.md"
         },
@@ -1015,7 +1015,7 @@
         },
         {
           "id": "security-privacy",
-          "name": "Security & Privacy — Manual Operacional",
+          "name": "security-privacy",
           "version": "1.0.0",
           "path": "skills/security-privacy/SKILL.md"
         },
@@ -1069,7 +1069,7 @@
         },
         {
           "id": "tdd",
-          "name": "TDD — Test-Driven Development (Iron Law)",
+          "name": "tdd",
           "version": "1.0.0",
           "path": "skills/tdd/SKILL.md"
         },
@@ -1129,7 +1129,7 @@
         },
         {
           "id": "web-perf-engineer",
-          "name": "Web Performance & SEO — Manual Operacional",
+          "name": "web-perf-seo",
           "version": "1.0.0",
           "path": "skills/web-perf-seo/SKILL.md"
         },

package/AGENTS.md

@@ -1,6 +1,6 @@
 # AGENTS.md: Izanagi AI Framework Reference
 
-> Version 3.19.0
+> Version 3.21.0
 > Modular Skill-Oriented AI Prompt & Agent Framework for Autonomous Software Engineering
 > Multi-CLI: Opencode · Claude Code · Codex · Cursor · Copilot · Kimi (Smart Auto-Detection & Selective Generation)
 
@@ -8,7 +8,7 @@
 
 ## 1. Visão Geral do Framework
 
-Izanagi AI é um **framework meta** para engenharia de software autônoma orientada a agentes: arquitetura em camadas (Routing → Orchestration → Evaluation → Healing → Memory), biblioteca de skills especializadas (catálogo v2 em `.skills/` convivendo com o legado `skills/`), **Skill Composer** (16 composições de skills encadeadas por domínio), **22 agentes especializados core + gerados**, **Memória Persistente Anti-Repetição** (`.agents/memoria/`), **Curadoria de Referências** (`references/`), **Checkpoint & Self-Healing Swarm Engine**, uma **CLI executável (`izanagi`)** publicada no npm (`izanagi-ai`) e uma **topologia poliglota** (Rust · Go · Python · TS — seção 3). Este repositório É o framework (não um app que o usa).
+Izanagi AI é um **framework meta** para engenharia de software autônoma orientada a agentes: arquitetura em camadas (Routing → Orchestration → Evaluation → Healing → Memory), biblioteca de skills especializadas (catálogo v2 em `.skills/` convivendo com o legado `skills/`), **Skill Composer** (16 composições de skills encadeadas por domínio), **22 agentes especializados core + gerados**, **Memória Persistente Anti-Repetição** (`.agents/memoria/`), **Curadoria de Referências** (`references/`), **Checkpoint & Self-Healing Swarm Engine**, uma **CLI executável (`izanagi`)** publicada no npm (`izanagi-ai`) e uma **topologia poliglota** (Rust · Go · Python · TS).<!-- izanagi:source-only --> A topologia está detalhada na seção 3. Este repositório É o framework (não um app que o usa).<!-- /izanagi:source-only -->
 
 ---
 
@@ -73,7 +73,7 @@ Coexistência **Strangler Fig** (ADR-001): o legado npm (`src/`, CLI `izanagi`)
 # Legado npm (raiz)
 npm install          # instala deps
 npm run build        # tsc && node dist/scripts/generate-manifest.js
-npm test             # build + node --test dist/runtime/tests/*.test.js (764 testes)
+npm test             # build + node --test dist/runtime/tests/*.test.js (849 testes)
 npm run verify       # build + teste de instalação em sandbox (passa todos os pack IDs)
 npm run doctor       # node bin/izanagi.js doctor [--deep]: auditoria de integridade
 npm run bump:patch   # npm version patch --no-git-tag-version (também minor/major)
@@ -97,7 +97,7 @@ node packages/skill-migrator/cli.mjs --dry-run          # valida migração skil
 **Gotchas críticos:**
 - `dist/` é gitignored e `bin/izanagi.js` importa de `../dist/cli/index.js`: **rode `npm run build` antes de qualquer comando CLI local** (`doctor`, `polyglot status`, `export`...), senão roda código obsoleto ou quebra. O mesmo vale para `packages/*/dist`: rode o build do package antes de consumir SDK/CLI-next.
 - `doctor`: instalação completa do usuário = `.agents/agents/` contendo agentes em **JSON** (formato distribuído); os YAMLs derivados do repo-fonte não caracterizam instalação.
-- Há test runner real (`node:test`, 764 testes em `src/runtime/tests/`). Verificação = `npm test` + `npm run verify` + `npm run doctor` + suítes poliglotas da seção 3.
+- Há test runner real (`node:test`, 849 testes em `src/runtime/tests/`, 848 verdes no Windows: o vermelho `polyglot` depende de shebang). Verificação = `npm test` + `npm run verify` + `npm run doctor` + suítes poliglotas da seção 3.
 - Padrão de commit do repo: `chore: bump to vX.Y.Z` para bumps e `feat:`/`fix:`/`docs:` descritivos em PT-BR para mudanças.
 
 ---

package/CHANGELOG.md

@@ -4,6 +4,104 @@
 
 ---
 
+## [3.21.0]: 2026-09-08
+
+### Fixed
+- **`izanagi init` entregava a autodescrição do framework como se descrevesse o projeto de destino.** `installer.ts` copiava `AGENTS.md`, `SYSTEM.md` e `RULES.md` LITERALMENTE do pacote para a raiz do projeto do consumidor, e esses três são os documentos de desenvolvimento do repositório-fonte: o `AGENTS.md` manda rodar `cargo test --workspace`, `npm run build` e `(cd packages/sdk && npm test)`, e descreve a árvore `src/`/`crates/`/`packages/`. Num projeto que só instala o pacote nada disso tem referente, e a instância de IA seguinte lê comandos que não rodam e procura pastas que não estão lá. O caminho era automático: `postinstall` chama `installToProject` com todos os packs em todo `npm install izanagi-ai`, então o documento errado não dependia de ninguém digitar `izanagi init`. Encontrado rodando `/init` do Claude Code num workspace consumidor.
+- **A raiz do projeto passa a receber um `AGENTS.md` com a forma DELE.** `buildConsumerAgentsDoc()` deriva da fonte por SELEÇÃO de seções (1, 2, 6, 7, 8 valem em qualquer projeto) e omite as que descrevem o repo-fonte (3 Arquitetura Poliglota, 4 Comandos de Desenvolvimento, 5 Estrutura do Framework, 9 Release Flow), acrescentando só o que a fonte não pode saber: que este projeto consome o framework, e quais comandos existem aqui (`npx izanagi doctor|list|skill search|agent inspect|export|run`). Derivar em vez de reescrever é deliberado: prosa duplicada é prosa para divergir, que é o defeito que a correção fecha. O espelho fiel continua em `.agents/`, que é onde `resolveFrameworkRoot` o procura.
+- **Seção universal podia carregar afirmação que só vale no repo-fonte.** A seção 1 dizia "Este repositório É o framework (não um app que o usa)" e apontava para a seção 3, ausente na versão de consumidor: uma frase falsa dentro de uma seção correta, contradizendo o próprio documento três parágrafos acima. O mecanismo é declarativo (`<!-- izanagi:source-only -->` na fonte, removido pelo builder) porque heurística de frase removeria prosa correta e deixaria passar a errada.
+- **`init` destruía documento de raiz escrito à mão.** O `copyFileSync` sobrescrevia `AGENTS.md`/`SYSTEM.md`/`RULES.md` existentes sem uma linha de aviso. Agora arquivo sem o `GENERATED_MARKER` é de quem o escreveu e não é tocado (a CLI diz que manteve); arquivo com o marcador é regenerado, que é a mesma regra que o `izanagi export` já seguia.
+- **Rodar `init` dentro do próprio checkout do framework não toca mais os documentos de raiz.** `isFrameworkRepo()` reconhece o repo-fonte pelo nome no `package.json`. Sem isso a correção seria pior que o bug: a versão de consumidor apagaria as seções 3/4/5/9, que ali descrevem o projeto de verdade.
+- **`references/` ia no tarball e não era instalado em lugar nenhum.** `cli/commands/run.ts` monta `<baseDir>/references/` e injeta as referências curadas no prompt, e `cli/blueprint.ts` faz o mesmo. Com `.agents/` como `baseDir` de projeto inicializado e nenhum pack copiando o diretório, a injeção existia e nunca encontrava arquivo nenhum, em projeto nenhum. Entrou no pack `core`.
+- **`.izanagi/izanagi.config.json` declarava `version: '2.1.0'` fixo no código**, com o framework em 3.20.x: dezoito minors de diferença, num arquivo de configuração de todo projeto. Passa a ler a versão real do pacote. Número que se reporta é número que aconteceu, inclusive quando o número é a versão.
+- **`AGENTS.md` afirmava "764 testes" em dois lugares.** O medido é 849. O arquivo é justamente um dos que iam verbatim para a raiz de todo consumidor: o drift que o `HANDOFF.md` combate estava sendo empacotado e distribuído.
+
+### Added
+- `isFrameworkRepo(root)` e `buildConsumerAgentsDoc(packageDir)` exportados de `installer.ts`.
+
+### Verificação
+- **849 testes, 848 passando** (medido em 2026-09-08, no **Windows**; 11 novos em `installer-consumer-docs.test.ts`). O vermelho segue sendo só `polyglot`, que depende de shebang.
+- `node dist/scripts/verify-build.js`: instalação em sandbox com os 12 packs, `AGENTS.md` da raiz gerado na forma do consumidor.
+- Consumidor de verdade (`package.json` sem relação com o framework, todos os packs, como o `postinstall` faz): `izanagi doctor` sai **PASSED, 0 erros, 0 warnings**, e o `AGENTS.md` gerado tem zero ocorrência de `cargo test`, `packages/sdk` ou "Este repositório É o framework", e zero vazamento do marcador `source-only`.
+
+### Compatibility
+- Nenhuma breaking change de API. Muda o CONTEÚDO do `AGENTS.md` que o `init` escreve na raiz de um projeto consumidor, e passa a preservar os três documentos de raiz quando escritos à mão. Quem versionou o `AGENTS.md` gerado verá um diff na próxima execução de `init`/`postinstall`.
+
+---
+
+## [3.20.1]: 2026-09-08
+
+### Fixed
+- **`project.test` não executava nada no Windows, e a v3.20.0 foi publicada assim.** `spawn('npm.cmd', …, { shell: false })` sai `EINVAL`: desde o CVE-2024-27980 o Node recusa lançar `.cmd`/`.bat` sem shell. O `try/catch` do arquivo transformava o throw em `error` com `passed` ausente, o que é o comportamento correto para "não medi". O efeito, porém, era o item 1 da v3.20.0 (a métrica de teste vinda de um exit code) degradar para "não medi" em toda máquina Windows. Os dois testes de exit code de `project-test.test.ts` falhavam lá e passavam no Linux, e a Verificação da v3.20.0 afirmava "837, 837 passando" a partir de uma medição feita só no Linux, listando um único vermelho conhecido de Windows quando eram três.
+- **O conserto não custa a garantia do arquivo.** As duas saídas óbvias (`shell: true` e `cmd.exe /d /s /c`) recolocariam um interpretador de comandos no caminho, que é exatamente o que `shell: false` remove. A escolhida é outra: `resolveNpmCli()` acha o entrypoint JS do npm (ao lado do `node` no Windows, em `../lib/node_modules` em Unix) e o `spawn` passa a ser `process.execPath` com o npm como argumento de arquivo: sem shell, e com o binário mais confiável disponível, que é o mesmo node que executa o runtime. Se nenhum layout resolver, o chamador fica com o binário `npm` do PATH e o `EINVAL` volta a ser reportado como erro: "não medi" continua sendo ausência de `passed`, nunca reprovação.
+- **`TestRunner` ganhou `execFile`/`execArgs`, e o rótulo continua sendo o comando.** O que vai ao `spawn` e o que vai ao artefato deixaram de ser o mesmo par: `command`/`args` seguem `npm test --silent` nas duas plataformas, porque `node …/npm-cli.js test` diria COMO, não O QUÊ.
+
+### Verificação
+- **838 testes, 837 passando** (medido em 2026-09-08, no **Windows**). O único vermelho é `polyglot: bin Rust presente com --version barato`, anterior à rearquitetura: a fixture escreve um binário falso com shebang bash, e o Windows não honra shebang nem executa arquivo sem extensão conhecida. Continua aberto porque consertá-lo exigiria um condicional de plataforma, e o número deixaria de ser o mesmo nos dois sistemas.
+- O teste novo ("o que vai ao spawn nunca é um `.cmd`, e o rótulo continua sendo o comando") trava o motivo, não só o sintoma: afirma que o binário do `spawn` é `process.execPath` e que nenhum `.cmd` chega lá.
+
+### Compatibility
+- Nenhuma breaking change. `TestRunner.execFile` e `.execArgs` são opcionais, e `command`/`args` mantêm o valor de antes.
+
+---
+
+## [3.20.0]: 2026-09-05
+
+### Rodada de fechamento dos catorze itens abertos (2026-09-05)
+
+A auditoria de 2026-09-04 fechou doze tetos sem caller e deixou **catorze itens
+abertos**, cada um com critério de pronto escrito no `RUNTIME-PENDING.md`. Esta
+rodada fecha os catorze. O padrão que eles compartilhavam continua sendo o mesmo
+que o `HANDOFF.md` diz combater, agora numa segunda forma: não é o limite
+declarado que nada aplica, é a **evidência declarada que ninguém produz** —
+métrica de teste vinda de um texto que um agente escreveu, critério de aceite
+que fala da forma e nunca do pedido, memória que se escreve e não se lê, journal
+que se lê e não se consulta.
+
+### Added
+- **`project.test` e o check `exit-zero`: a métrica de teste passa a vir de um exit code.** A camada determinística tinha oito checks e nenhum executava nada; `testResults` vinha de um artefato `test-results` que um AGENTE escreveu, ou seja, do mesmo processo que deveria estar sendo testado. Com `--verify-tests`, o nó `verify-tests` roda o comando de teste do PROJETO no fim do grafo e `passed` é `exitCode === 0`, decidido pelo sistema operacional. **Isto não afrouxa o isolamento do `code.execute`:** a diferença é a fonte do comando. No `code.execute` o código vem do modelo, e por isso roda sem subprocesso, sem env herdado e sem rede confiável; aqui o comando vem do manifesto do projeto, o binário sai de uma allowlist fixa do runtime, o `spawn` é `shell: false` (sem expansão, sem `&&`, sem pipe) e nenhum campo de entrada carrega comando. Opt-in porque executa um processo do projeto com o ambiente herdado: a mesma confiança de digitar `npm test`.
+- **`--acceptance`: o critério do usuário passa a ser cobrado.** Todo critério era derivado do SCHEMA do artefato, então "adicionar paginação em GET /users" não produzia nenhum critério sobre paginação, e não existia flag, campo de SDK ou input para fornecer um. Prefixo conhecido (`contains:`, `not-contains:`, `matches:`, `min-size:`, `file-exists:`, `json-field:`, `references-exist`) vira check determinístico; prosa vira critério semântico, que precisa de juiz e sem juiz fica `UNVERIFIED`. O default é semântico de propósito: transformar uma frase em `contains` da frase inteira reprovaria toda entrega correta escrita com outras palavras, e um check inventado é pior que nenhum porque parece evidência.
+- **`--min-quality`: estratégias comparadas contra um piso.** Não existiam candidatos nem piso configurável (`minQuality`/`qualityFloor` tinham zero ocorrências no código), então "respeitando a qualidade mínima configurada" não tinha o que respeitar. Agora os modos até o sugerido viram candidatos, cada um estimado pelo mesmo caminho de roteamento da execução, e vence o mais barato que atinge o piso. Piso inalcançável **não sobe o modo em silêncio**: o plano segue no modo sugerido e declara que não cumpriu, porque subir seria o orçamento decidindo escopo.
+- **`--reuse-artifacts`: reuso de artefato entre runs.** `readContent` só era chamado por `izanagi explain`; um segundo run do mesmo objetivo refazia tudo. A parte que importa é a invalidação, e ela vem declarada antes do cache: a chave cobre tipo, objetivo, restrições, critérios, agente, papel, checksums dos insumos EM ORDEM e a impressão do projeto; run sem survey é chave DIFERENTE de run com survey; o prazo (7 dias) expira o que a chave não consegue ver. O artefato reaproveitado entra no lugar da CHAMADA e passa pela verificação inteira: o que se economiza é a chamada, não a prova.
+- **`--allow-tool` e `--verify-tests` na CLI.** A allowlist de tools existia no Orchestrator, no SDK e no caso de benchmark, e `izanagi run` não tinha flag para ela.
+- **`HUMAN_REQUIRED`: teto esgotado deixa de se confundir com falha por bug.** Cada abort por teto marca qual (`attempts`/`time`/`tokens`/`cost`) e o status do run muda. O veredito da AVALIAÇÃO continua `FAIL`, porque ela mede a entrega e a entrega não fechou: os dois campos convivem por medirem coisas diferentes. O exit code segue 1, não 2 — o 2 significa "retomável por `izanagi approve`", e um orçamento estourado não é.
+- **`ArtifactRegistry.lineage()` e `.compare()`.** As arestas de dependência estavam gravadas desde sempre e a leitura parava no primeiro vizinho; num grafo de sete nós, um salto nunca responde "de onde veio isto?". A travessia é em largura, com marca de visitado (ciclo termina em vez de girar), e `compare()` diz o que MUDOU entre versões, não só quanto o score caiu.
+- **`ArtifactRecord.checksum` (sha256 completo) e `.metadata` livre.** `hash` continua sha1 truncado em 12 hex porque é o que os registros gravados carregam: 48 bits bastam para "é o mesmo artefato de novo?", não para "este arquivo é exatamente o que eu gravei". `metadata` tem teto de 4KB e é recusado INTEIRO quando estoura.
+- **`EXTERNAL-TOOL-001`: tool registrada em runtime exige aprovação humana.** O default-allow da `PolicyEngine` permanece, com o motivo escrito (a `ToolRegistry` já nega o que o contrato não concedeu, a allowlist já nega o que não foi declarado, e se a política também fosse portão de concessão haveria três lugares decidindo a mesma coisa). O caso em que "não previsto" era perigoso ganhou regra própria. E `PolicyDecision.requiresApproval`, que existia e ninguém lia, virou pausa por `izanagi approve` em vez de falha que o healing retentaria contra uma porta fechada.
+- **`ExecutionEvidence.modelCalls` / `.agentCalls` / `.successRate` e `benchmark run --execute --compare`.** A comparação antigo vs novo cobria três dimensões e só sobre o PLANO. Chamadas contam por TENTATIVA, porque é o que a fatura conta, e nó reaproveitado não conta — é justamente a diferença que a comparação precisa enxergar.
+- **`triggers` e `capabilities` declarados nas 22 skills mais acionadas.** Das 106 skills, ZERO declaravam qualquer um dos dois: o haystack de `rankSkills` incluía dois arrays sempre vazios e o ranking escolhia entre 106 descrições soltas. Escritos à mão: derivar dos títulos de seção produziria "Identidade" e "Processo" como capacidade, e derivar da description colocaria as mesmas palavras duas vezes.
+- **`MemoryStore.appendKnowledge`.** A camada semântica era lida e nunca escrita pelo runtime: `.agents/memoria/semantica.md` só mudava quando uma pessoa o editava, e o que o runtime gravava (`addLearning`) vive numa lista plana que a busca não alcança.
+
+### Changed
+- **O Decision Journal deixa de ser write-only.** Cada decisão leva o objetivo do run; o fim do run carimba o veredito (`recordOutcome`, que não reescreve o que já foi carimbado); o planejamento consulta por semelhança de objetivo (`findRelevant`, só decisões com resultado conhecido). Um agente escolhido duas vezes para um objetivo semelhante, com os dois runs sem fechar e nenhum sucesso no meio, sai da disputa — e a troca vale também nos nós vindos do template do workflow. Duas falhas e não uma: um incidente pode ter sido provider fora do ar.
+- **`MemoryStore.search()` passa a ser consultado DURANTE o run.** Era chamado só pela CLI e pelo benchmark; dentro de um run, a única recuperação era padrão de falha. Agora o Context Resolver busca pelo objetivo de cada tarefa, com teto de 2 entradas e 600 chars, e um store por run. Numa rodada de correção o bloco fica de fora: o que falta ali é a correção, não mais contexto.
+- **`maxCost` vira limite do Healer.** `HealingInput` tinha tempo, tokens e tentativas; o custo só agia por `ExecutionBudget.spend`, ou seja DEPOIS de a chamada acontecer. Curar é decidir gastar mais uma chamada, e essa decisão passa a consultar o dinheiro antes.
+- **A nota de um caso de benchmark passa a incluir os validators.** Era só a razão de artefatos: um caso cujos arquivos apareceram e cujos validators reprovaram TODOS saía com `score: 1.00, passed: false`, e `compareBaselines` rankeia por `avgScore` — o baseline que acertou os nomes de arquivo e errou o conteúdo vencia o que acertou o conteúdo.
+
+### Fixed
+- **O total de tokens do trace saía 60% acima da telemetria do MESMO run.** `addTokens(result.tokens, result.tokens * 0.6)` soma os dois argumentos, e `result.tokens` é o total do provider (`input + output`), não a entrada. É o número que a CLI imprime, que `izanagi trace` mostra, que o dashboard exibe, que o webhook envia e que a Arena soma. Teste novo trava o invariante: trace e telemetria contam o mesmo run.
+- **Validators de um caso de benchmark liam o CAMINHO, não o arquivo.** Num output de diretório, `has-owasp` media se a palavra "owasp" estava no nome da pasta temporária: o validator passava ou reprovava por uma propriedade do diretório de trabalho.
+- **O registry de benchmark aceitava caso pela metade num `catch` vazio.** Um JSON sem `expectedArtifacts` chegava ao runner, estourava dentro do `try` da suíte, e o relatório culpava a execução por um defeito da definição. Caso recusado agora diz o motivo e o arquivo.
+- **Toda métrica declarada por um caso recebia a mesma razão de artefatos.** O relatório salvo mostrava `correctness`, `security` e `architecture` com o mesmo número: três medidas independentes que eram uma medida repetida três vezes. O que não é medido sai em `metricsNotMeasured`.
+- **A varredura anti-stub reprovava a evidência de uma suíte VERDE.** O runner de testes do Node imprime `ℹ todo 0` no resumo, e o artefato `test-run` de uma suíte 100% verde era reprovado por "stub detectado: TODO". A varredura pressupõe texto autoral; schema de saída capturada agora a desliga.
+- **`unmet` misturava reprovado com não-comprovado.** Um critério semântico sem juiz aparecia lado a lado com um check que de fato falhou, e quem lesse a linha (ou a restrição que o replanejamento deriva dali) trataria "não medi" como "está errado". Agora o não-comprovado vem marcado `[sem evidência]`.
+- **Dois objetos git vazios impediam o push.** `src/cli/commands/benchmark.ts` e `src/runtime/types.ts` tinham blobs truncados a zero byte no object store local, referenciados por oito dos nove commits da rodada. Reconstruídos byte a byte a partir dos blobs vizinhos legíveis, com o hash conferido antes de gravar: `git fsck` limpo, e nenhum commit reescrito.
+
+### Compatibility
+- Nenhuma breaking change. As quatro capacidades novas são **opt-in** (`--verify-tests`, `--acceptance`, `--min-quality`, `--reuse-artifacts`): sem elas, o plano, o grafo e o veredito são byte a byte os de antes, e há teste que mede isso.
+- `OrchestrationResult.status` e `IzanagiRunResult.status` ganharam o valor `HUMAN_REQUIRED`. Quem faz `switch` exaustivo sobre o status precisa tratá-lo; quem compara com `'PASS'` não muda. O exit code da CLI é o mesmo de antes.
+- `PlanEstimate.quality` é campo novo e obrigatório no tipo. Quem constrói um `PlanEstimate` à mão (fixtures de teste) precisa declará-lo; quem consome o que o `Commander.estimate` devolve não muda.
+- `ArtifactSchema.capturedOutput`, `ArtifactRecord.checksum`, `.metadata` e `.reuseKey` são opcionais: registro escrito por versão anterior continua legível.
+
+### Verificação
+- **837 testes, 837 passando** (medido em 2026-09-05, Linux). O vermelho conhecido de Windows (`polyglot: bin Rust presente com --version barato`) é anterior e independente. **Esta linha estava errada, e a 3.20.1 diz por quê:** no Windows eram três vermelhos, não um, e os dois extras eram justamente os de `project.test`.
+- `izanagi run "documentar a funcao de soma" --output docs --verify-tests --mode orchestrated` num projeto de fixture: suíte verde → `PASS`, 7/7 VERIFIED, `testResults=1`, score 1.00; suíte vermelha → `BLOCKED`, 6/7 VERIFIED, `testResults=0`, regressão nomeando `npm test --silent` com exit 1.
+- `izanagi run "..." --reuse-artifacts` duas vezes: run 1 gasta 900 tokens com cache 0/3; run 2 gasta **0 tokens** com cache 3/3, e continua `PASS` com 4/4 VERIFIED.
+- `izanagi run "..." --min-quality`: piso 0.4 escolhe `autonomous` ($0.0011, o único que atinge); piso 0.3 escolhe `assisted` ($0.0000, mesmo piso atingido por menos).
+- `izanagi benchmark run security --execute --compare`: tokens -300 (1500 → 1200), model calls -1 (5 → 4), agent calls -1 (3 → 2), latência +50ms, verificação n/a → 100%, sucesso 100% nos dois.
+
+---
+
 ## [3.19.0]: 2026-09-04
 
 > **A 3.18.0 nunca chegou ao npm.** Ela foi para o GitHub e o `npm publish` não

package/README.md

@@ -1,6 +1,6 @@
 # Izanagi AI
 
-> **v3.19.0** · Runtime de execução de trabalho orientado a agentes: **Commander** → contrato de tarefa → roteamento por papel (por TAREFA, não por run) → grafo → verificação por evidência → healing → replan → memória. O run **lê o projeto** antes de decidir e **entrega arquivo** no fim, os dois por nós de tool com permissão declarada. Todo teto declarado (tokens, custo, tempo, retries, agentes, tool calls, concorrência, allowlist de tool) **é aplicado e tem teste que mede o teto**; `Ctrl-C` cancela o run e o `resume` retoma do último batch gravado. 22 agentes especializados, catálogo de skills v2, CLI publicada no npm (`izanagi-ai`), SDK programático e **topologia poliglota** (Rust · Go · Python · TypeScript) ao lado do runtime legado.
+> **v3.21.0** · Runtime de execução de trabalho orientado a agentes: **Commander** → contrato de tarefa → roteamento por papel (por TAREFA, não por run) → grafo → verificação por evidência → healing → replan → memória. O run **lê o projeto** antes de decidir e **entrega arquivo** no fim, os dois por nós de tool com permissão declarada. Todo teto declarado (tokens, custo, tempo, retries, agentes, tool calls, concorrência, allowlist de tool) **é aplicado e tem teste que mede o teto**; `Ctrl-C` cancela o run e o `resume` retoma do último batch gravado. 22 agentes especializados, catálogo de skills v2, CLI publicada no npm (`izanagi-ai`), SDK programático e **topologia poliglota** (Rust · Go · Python · TypeScript) ao lado do runtime legado.
 
 **Filosofia:** Arquitetura primeiro. Código depois. Qualidade medida. Evolução contínua. Zero "cara de IA".
 
@@ -32,6 +32,10 @@ izanagi run "Converta 10 dólares para reais"                  # modo direct: 1
 izanagi run "Criar uma landing page de um SaaS de analytics"  # modo composto, com verificação
 izanagi run "..." --mode autonomous --max-cost 0.50           # teto de custo respeitado no plano
 izanagi run "adicionar paginação em GET /users" --output docs # lê o projeto e entrega o arquivo
+izanagi run "..." --acceptance "o endpoint aceita ?page e ?limit"  # o que o usuário pediu, cobrado
+izanagi run "..." --output src --verify-tests                # a métrica de teste vem do exit code do projeto
+izanagi run "..." --min-quality 0.3                          # a estratégia mais barata que atinge o piso
+izanagi run "..." --reuse-artifacts                          # segundo run da mesma pergunta não repaga a chamada
 
 # 3. Observabilidade, custo e auditoria
 izanagi trace            # spans, healing, graph, avaliação
@@ -66,7 +70,7 @@ Cada tarefa recebe o modelo do seu papel, não o modelo do run: `commander` (tie
 
 ### Verificação por evidência
 
-Nenhuma tarefa termina porque o agente disse que terminou. Cada contrato carrega critérios de aceite derivados do schema real do artefato, e a Verification Engine devolve `VERIFIED`, `FAILED` ou `UNVERIFIED`. Critério semântico é julgado por um modelo barato (papel `worker`, artefato resumido); com `--no-judge`, ou sem provider, ele **nunca vira aprovação**: fica `UNVERIFIED`, e o run reporta isso. Juiz que não conseguiu decidir também não reprova.
+Nenhuma tarefa termina porque o agente disse que terminou. Cada contrato carrega critérios de aceite derivados do schema real do artefato **e os que o usuário declarou** (`--acceptance`), e a Verification Engine devolve `VERIFIED`, `FAILED` ou `UNVERIFIED`. Com `--verify-tests`, um dos critérios é o **exit code** do comando de teste do projeto: a única camada do runtime que decide por execução, e não por leitura de texto. Critério semântico é julgado por um modelo barato (papel `worker`, artefato resumido); com `--no-judge`, ou sem provider, ele **nunca vira aprovação**: fica `UNVERIFIED`, e o run reporta isso. Juiz que não conseguiu decidir também não reprova.
 
 Com `--prompt-only`, apenas compila `izanagi-prompt.md` para colar manualmente em outra ferramenta, sem executar nada. Nós de aprovação (`human-in-the-loop`) pausam a execução até `izanagi approve <run-id>`.
 
@@ -165,7 +169,7 @@ CLI legado (`izanagi`, publicada no npm):
 | Comando | Descrição |
 |---|---|
 | `izanagi init [dir] [--packs a,b,c]` | Cria projeto com `.agents/` e seleção de packs de skills. |
-| `izanagi run [agent] --task "<task>"` | Commander decide o modo, roteia por papel, executa o grafo, verifica contra os critérios de aceite e persiste trace + telemetria de custo. Flags: `--mode direct\|assisted\|orchestrated\|autonomous`, `--budget N`, `--max-cost N`, `--model <id>`, `--local` (só providers locais, e serializa o pool: GPU única não ganha com paralelismo), `--max-concurrency N` (teto de tarefas em voo), `--cache`, `--output <dir>` (grava a entrega no projeto), `--survey` / `--no-survey` (força ou desliga o levantamento do projeto antes de decidir). **Ctrl-C cancela o run** em vez de matar o processo: o batch em voo é abortado, o progresso já gravado fica no checkpoint e `izanagi resume <run-id>` retoma dali, `--no-commander` (planejamento legado por categoria), `--no-judge` (desliga o juiz semantico), `--prompt-only`. |
+| `izanagi run [agent] --task "<task>"` | Commander decide o modo, roteia por papel, executa o grafo, verifica contra os critérios de aceite e persiste trace + telemetria de custo. Flags: `--mode direct\|assisted\|orchestrated\|autonomous`, `--budget N`, `--max-cost N`, `--model <id>`, `--local` (só providers locais, e serializa o pool: GPU única não ganha com paralelismo), `--max-concurrency N` (teto de tarefas em voo), `--cache`, `--output <dir>` (grava a entrega no projeto), `--survey` / `--no-survey` (força ou desliga o levantamento do projeto antes de decidir), `--acceptance "<critério>"` (repetível: o que a ENTREGA precisa cumprir, além do schema), `--verify-tests` (roda o comando de teste do projeto no fim do grafo e a métrica de teste passa a vir do exit code), `--min-quality 0..1` (compara estratégias e escolhe a mais barata que atinge o piso de VERIFICAÇÃO), `--reuse-artifacts` (reaproveita artefato de run anterior com a mesma pergunta), `--allow-tool <id>` (allowlist de tools do run). **Ctrl-C cancela o run** em vez de matar o processo: o batch em voo é abortado, o progresso já gravado fica no checkpoint e `izanagi resume <run-id>` retoma dali, `--no-commander` (planejamento legado por categoria), `--no-judge` (desliga o juiz semantico), `--prompt-only`. |
 | `izanagi models [--json]` | Catálogo de modelos, providers configurados e qual modelo cada papel (commander/specialist/worker) receberia agora, com custo por 10k tokens. |
 | `izanagi budget [run-id] [--json]` | Para onde foi o orçamento daquele run: tokens por fase, custo estimado, cache local e do provider, contexto poupado, escaladas, degradação e verificação por tarefa. |
 | `izanagi chat` | REPL interativo da CLI. |

package/ROADMAP.md

@@ -1,6 +1,6 @@
 # Roadmap
 
-> Versão atual: **3.19.0**. Estado atual e evolução planejada do **Izanagi AI: Adaptive Agent & Skill Runtime**.
+> Versão atual: **3.21.0**. Estado atual e evolução planejada do **Izanagi AI: Adaptive Agent & Skill Runtime**.
 > Legenda: ✅ Done · 🔧 In progress · 📋 Planned · 💡 Future idea
 > Histórico linha-a-linha de cada release em `CHANGELOG.md`: este arquivo resume por fase, não duplica o changelog.
 
@@ -466,6 +466,71 @@ defeitos que este runtime existe para combater.
 Testes: **764, 763 passando** (69 novos). Cada teto novo tem teste que mede o
 teto, não a contagem.
 
+## Fase 15: A evidência que ninguém produzia (v3.20.0) ✅
+
+Os catorze itens que a Fase 14 deixou abertos, fechados com implementação,
+teste e medição. O padrão que eles compartilhavam é o irmão do da fase
+anterior: lá era **um limite declarado que nada aplica**; aqui é **uma
+evidência declarada que ninguém produz**.
+
+Quatro exemplos do mesmo defeito, em lugares diferentes do runtime:
+
+- a métrica `testResults` da avaliação vinha de um artefato `test-results` que
+  um AGENTE escreveu — o runtime afirmava "testes passando" a partir de um
+  texto produzido pelo mesmo processo que deveria estar sendo testado;
+- todo critério de aceite era derivado do SCHEMA do artefato, então
+  "adicionar paginação em GET /users" não produzia nenhum critério sobre
+  paginação, e não havia por onde o usuário fornecer um;
+- a camada semântica da memória era lida e nunca escrita pelo runtime, e o
+  Decision Journal era escrito e nunca consultado: uma memória que não aprende
+  e um registro que não lembra;
+- das 106 skills, ZERO declaravam `triggers` ou `capabilities`, então o
+  ranking escolhia entre 106 descrições soltas com dois arrays sempre vazios
+  no haystack.
+
+### O que entrou
+
+| Capacidade | O que mudou na execução |
+|---|---|
+| `--verify-tests` | Nó `verify-tests` roda o comando de teste do PROJETO e o check `exit-zero` decide pelo exit code do processo. O comando vem do manifesto, o binário de uma allowlist fixa, `spawn` com `shell: false`, e nenhum campo de entrada carrega comando |
+| `--acceptance` | O critério do usuário entra nos contratos das tarefas terminais. Prefixo conhecido vira determinístico; prosa vira semântico. Entrada malformada é recusada em voz alta |
+| `--min-quality` | Os modos até o sugerido viram candidatos, cada um estimado pelo mesmo caminho de roteamento, e vence o mais barato que atinge o piso de VERIFICAÇÃO |
+| `--reuse-artifacts` | Artefato de run anterior com a mesma pergunta entra no lugar da chamada e passa pela verificação inteira. A invalidação vem declarada antes do cache |
+| `--allow-tool` | A allowlist que existia no Orchestrator, no SDK e no caso de benchmark ganhou flag |
+| `HUMAN_REQUIRED` | Teto esgotado deixa de se confundir com falha por bug. A avaliação continua `FAIL`: ela mede a entrega, o status carrega o fato do processo |
+| Decision Journal | Decisão leva o objetivo, o fim do run carimba o veredito, e o planejamento consulta por semelhança de objetivo. Agente queimado no mesmo objetivo sai da disputa |
+| Memória semântica | `appendKnowledge` escreve conhecimento reutilizável com barra de recorrência, e `search()` passa a ser consultado por tarefa pelo Context Resolver |
+| Linhagem e checksum | Travessia completa dos dois lados, comparação por conteúdo, `checksum` sha256 e `metadata` livre com teto |
+| `EXTERNAL-TOOL-001` | Tool registrada em runtime exige aprovação humana, e `requiresApproval` virou pausa por `izanagi approve` em vez de campo que ninguém lia |
+| Oito dimensões | `benchmark run --execute --compare` mede tokens, custo, latência, model calls, agent calls, retries, sucesso e verificação nos DOIS caminhos |
+| Metadado de skill | As 22 mais acionadas pelas chains declaram `triggers` e `capabilities`, com gate que quebra se o campo esvaziar em massa |
+
+### Compatibilidade
+
+As quatro capacidades novas são **opt-in**. Sem elas, o plano, o grafo e o
+veredito são byte a byte os de antes, e há teste que mede isso. A única adição
+ao tipo do resultado é o valor `HUMAN_REQUIRED`; o exit code da CLI não mudou.
+
+### O que esta fase deliberadamente NÃO fechou
+
+Nada da lista de gaps ficou aberto. O que continua registrado como **escolha,
+não dívida**, está em [`docs/RUNTIME-PENDING.md`](docs/RUNTIME-PENDING.md), e
+três limitações dali só deixam de ser limitações contra um provider real:
+grounding medido contra a ausência dele, a Arena com números de execução real,
+e o critique loop exercitado por um modelo de verdade.
+
+Duas limitações novas entraram na mesma lista, e as duas são de MEDIÇÃO, não de
+implementação: o nó de teste mede a suíte do projeto e não o efeito da entrega
+(quando o `--output` cai fora da árvore testada), e o piso de `--min-quality`
+mede o quanto o plano se compromete a verificar, nunca a qualidade do que vai
+ser entregue.
+
+Testes: **838, 837 passando** (74 novos nesta fase; medido no Windows, onde o
+único vermelho é `polyglot`, que passa no Linux). A fase foi publicada dizendo
+"837, 837 passando" a partir de uma medição só no Linux: dois testes de
+`project.test` falhavam no Windows, e o motivo virou linha na seção 3 do
+[`docs/HANDOFF.md`](docs/HANDOFF.md).
+
 ## Critérios de aceite das próximas fases
 
 Toda mudança no framework deve provar impacto em pelo menos uma dimensão:

package/RULES.md

@@ -1,6 +1,6 @@
 # IZANAGI AI: Operating Rules
 
-> Version 3.19.0
+> Version 3.21.0
 
 ---
 

package/SYSTEM.md

@@ -1,6 +1,6 @@
 # IZANAGI AI: System Foundation
 
-> Version 3.19.0
+> Version 3.21.0
 > Codename: "The Architect's Mind"
 
 ---
@@ -80,7 +80,7 @@ User Input / Comando CLI
 | **Context Resolver** (`orchestration/context-resolver.ts`) | Contexto mínimo por tarefa: objetivo, restrições e SÓ os artefatos dos quais ela depende, resumidos (começo + fim preservados) e referenciados por id. |
 | **Agent Capability Registry** (`registry/capabilities.ts`) | Descoberta de agentes em disco com capacidades, skills, chains, classe de custo, papel e domínios. Matching bilíngue por domínio, no lugar da lista fixa de agentes. |
 | **Agent-to-Agent Protocol** (`protocol/messages.ts`) | Mensagens tipadas com referência de artefato em vez de cópia de texto; crítica estruturada com parsing tolerante (saída não parseável vira `needs_revision`, nunca aprovação) e correção mínima só dos bloqueantes. |
-| **Verification Engine 2.0** (`verification/engine.ts`) | Três camadas: determinística, evidência e semântica. O juiz semântico default (`verification/judge.ts`) vem ligado na CLI e no SDK quando há provider, roda no papel `worker` e recebe o artefato resumido; sem juiz (`--no-judge` ou modo headless) o critério fica `UNVERIFIED` e NUNCA conta como aprovação. Juiz que não respondeu é `inconclusive`, nunca reprovação. Só `VERIFIED` encerra uma tarefa. |
+| **Verification Engine 2.0** (`verification/engine.ts`) | Três camadas: determinística, evidência e semântica. A camada determinística tem nove checks; oito leem o artefato (`artifact-valid`, `min-size`, `contains`, `not-contains`, `matches`, `json-field`, `file-exists`, `references-exist`) e um decide por EXECUÇÃO: `exit-zero`, alimentado pelo nó `verify-tests` (`--verify-tests`), que roda o comando de teste do projeto. Exit code ausente é `unknown`, nunca `pass`: um check de execução que aprova por ausência de evidência seria pior que a métrica derivada de artefato que ele substituiu. O juiz semântico default (`verification/judge.ts`) vem ligado na CLI e no SDK quando há provider, roda no papel `worker` e recebe o artefato resumido; sem juiz (`--no-judge` ou modo headless) o critério fica `UNVERIFIED` e NUNCA conta como aprovação. Juiz que não respondeu é `inconclusive`, nunca reprovação. Só `VERIFIED` encerra uma tarefa. |
 | **Budget Controller** (`token/execution-budget.ts`) | Custo em USD, tetos de tool call/agente/retry, tempo de parede e escada de degradação (contexto → saída → modelo → paralelismo → tarefas opcionais → aprovação humana). Gasto que estouraria um teto é recusado, e **registrado antes de ser recusado**: gasto recusado por teto ainda aconteceu na fatura. Desde 2026-09-04 `maxRetries` e `maxAgents` de fato BARRAM (antes contavam e o retorno era descartado), e `remainingTokens` alimenta o roteamento por nó. Teto estourado é `non-recoverable` no `Healer`: um teto não se move entre tentativas, então retentar é gastar orçamento numa porta fechada. |
 | **Response Cache** (`cache/response-cache.ts`) | Cache local por hash de (provider, modelo, system, mensagens, teto, temperatura), com TTL, eviction e versão de esquema. Opt-in (`--cache` / `IZANAGI_CACHE=1`). |
 | **SDK** (`src/sdk.ts`) | `izanagi.run({ objective })` e `izanagi.plan({ objective })`: mesma engine da CLI, sem saída no terminal, com eventos do run em tempo real. |
@@ -98,7 +98,7 @@ User Input / Comando CLI
 | **Failure Memory** (`memory/store.ts`) | `recordFailure` + `findRelevantFailures` por categoria: erros reais registrados são injetados como evidência em runs futuros (anti-repetição). |
 | **Memory Store** (`memory/store.ts`) | Stats por agente, learnings, histórico de runs (JSON em disco). |
 | **Trace Store** (`observability/tracer.ts`) | Traces de execução em JSON (um arquivo por run em `.izanagi/state/traces/`) com spans, load/close e retry de escrita. |
-| **Benchmarks** (`benchmarks/`) | 10 casos builtin executáveis via `izanagi benchmark` + `compare` entre builds, mais o Token Benchmark (`benchmark tokens`): legado vs Commander em chamadas, tokens e custo, de forma determinística. |
+| **Benchmarks** (`benchmarks/`) | 10 casos builtin executáveis via `izanagi benchmark` + `compare` entre builds, mais o Token Benchmark (`benchmark tokens`): legado vs Commander em chamadas, tokens e custo do PLANO, de forma determinística. `benchmark run --execute --compare` roda a mesma suíte pelos dois caminhos de planejamento, com o mesmo teto por caso, e mede oito dimensões de EXECUÇÃO: tokens, custo, latência, model calls, agent calls, retries, taxa de sucesso e taxa de verificação. Plano e execução nunca dividem o mesmo campo. |
 | **LLM Executor** (`llm/`) | Adapters reais OpenAI/Anthropic/Google com env key, timeout e propagação de erro HTTP. |
 | **Evidence System** (`research/evidence.ts`) | Claims FACT/ASSUMPTION/INFERENCE/UNKNOWN com fonte, confiança e hierarquia de sourceType (official docs > source code > tests > package metadata > reliable tech > community); relatório de claims críticas. ⚠️ Implementado e testado, mas **nenhum caller em produção** hoje: nem `Orchestrator` nem `planner.ts` o invocam; só o próprio teste do módulo o exercita. Roadmap: ligar à execução do agente `researcher`. |
 | **Token Budget 2.0** (`token/budget.ts`) | Orçamento por fase (planning/execution/evaluation/recovery) com tetos, pesos por complexidade e abort de fase: retry consome a fase recovery, nunca o execution. |
@@ -221,7 +221,7 @@ O ciclo completo de execução: `Objetivo → Classificação → Modo → Task
 1. **Understanding & Planning**: `requirements` decomposição de requisitos (artefatos em `contracts/artifacts.ts`), classificação da tarefa em categoria; Product Reasoner rotula claims de produto (FACT/ASSUMPTION/UNKNOWN) com confiança via Evidence System.
 2. **Execution Graph**: o Orchestrator monta um grafo por categoria (10 templates: fullstack, debugging, security_audit, architecture, automacao, frontend, implementation, database_design, devops_infra, testing) com `parallelBatches` (nós independentes em paralelo, nós dependentes em sequência) e hooks de execução (`produce`: agêntico / LLM / comando).
 3. **Adaptive Routing**: o resolver pontua skills por relevância + histórico de uso por categoria (scorer com decaimento temporal), nunca lista estática; agents são resolvidos pelo mesmo scoring.
-4. **Verification & Evaluation**: cada artefato é verificado contra os critérios de aceite do contrato (determinística → evidência → semântica) e só `VERIFIED` encerra a tarefa; `UNVERIFIED` é reportado como inconclusivo, nunca como sucesso. O nó em si SEGUE (sem juiz semântico todo critério semântico fica inconclusivo, e derrubar o nó transformaria "não medi" em "está errado"), mas desde 2026-09-04 ele carrega `metadata.unverified` com status, motivo e critérios não comprovados, mais uma mensagem A2A de tipo `evidence`: aprovado sem prova é distinguível de comprovado. A avaliação final agrega métricas ponderadas com thresholds e veredito derivado; sem métricas mensuradas → **UNKNOWN** com recomendação explícita de evidência.
+4. **Verification & Evaluation**: cada artefato é verificado contra os critérios de aceite do contrato — os derivados do schema do artefato e os que o usuário declarou em `--acceptance` (prefixo conhecido vira check determinístico, prosa vira critério semântico) — (determinística → evidência → semântica) e só `VERIFIED` encerra a tarefa; `UNVERIFIED` é reportado como inconclusivo, nunca como sucesso. O nó em si SEGUE (sem juiz semântico todo critério semântico fica inconclusivo, e derrubar o nó transformaria "não medi" em "está errado"), mas desde 2026-09-04 ele carrega `metadata.unverified` com status, motivo e critérios não comprovados, mais uma mensagem A2A de tipo `evidence`: aprovado sem prova é distinguível de comprovado. A avaliação final agrega métricas ponderadas com thresholds e veredito derivado; sem métricas mensuradas → **UNKNOWN** com recomendação explícita de evidência.
 5. **Self-Healing & Classification**: healing classificado (retry para transitório, `skill_replacement` para artefato inválido, fallback de modelo, abort por limite); cada healing é registrado com stats por agente.
 6. **Memory & Evolution**: `recordFailure` + `findRelevantFailures` (memória de falhas por categoria), learnings e traces; a memória curada `.agents/memoria/` é atualizada ao fim do ciclo.
 

package/dist/cli/commands/benchmark.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"benchmark.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/benchmark.ts"],"names":[],"mappings":"AAAA;;GAEG;AAmBH;;;;GAIG;AACH,wBAAsB,gBAAgB,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,QAAQ,SAAU,GAAG,OAAO,CAAC,IAAI,CAAC,CA0CzG"}
+{"version":3,"file":"benchmark.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/benchmark.ts"],"names":[],"mappings":"AAAA;;GAEG;AAmBH;;;;GAIG;AACH,wBAAsB,gBAAgB,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,QAAQ,SAAU,GAAG,OAAO,CAAC,IAAI,CAAC,CA+CzG"}