@polymorphism-tech/morph-spec 8.44.0 → 8.45.0

package/framework/skills/core/morph-proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-proposal
@@ -112,8 +112,8 @@ Critério objetivo em `MORPH.md` §2.1: a mudança cria ou altera superfície de
 ### 5. Invocar `Skill(morph-plan)`
 
 A skill lê `proposal.md` e produz:
-- `spec.md` — especificação técnica detalhada
-- `mandate.md` — contrato de implementação (stack defaults + padrões proibidos)
+- `usecases/UC-*.md` — o comportamento, com pós-condições testáveis
+- `spec.md` — especificação técnica, com a seção `## Contrato de implementação`
 - `tasks.json` — task breakdown estruturado validado contra `.morph/framework/schemas/tasks.schema.json`
 - `decisions.md` — apenas se houver decisões não triviais
 
@@ -130,7 +130,7 @@ Mesma mecânica do passo 3: a decisão já foi tomada e persistida pela `morph-p
 
 - Não pular o Gate 1 mesmo em trust:auto se houver divergência detectada.
 - Não escrever código nesta fase — apenas artefatos de planejamento.
-- Não perguntar sobre stack — o stack padrão está em MORPH.md / mandate.
+- Não perguntar sobre stack — o stack padrão está em MORPH.md.
 - Não rodar o pipeline completo de 5 fases num `chore` ou `bug` óbvio — o Passo 0 existe para dimensionar o trabalho pelo `workType`, não para ser pulado "para simplificar".
 
 ## Output esperado
@@ -138,7 +138,6 @@ Mesma mecânica do passo 3: a decisão já foi tomada e persistida pela `morph-p
 - `.morph/features/{feature}/0-proposal/proposal.md`
 - `.morph/features/{feature}/1-design/` (se o ramo uiux — passo 3a — foi tomado)
 - `.morph/features/{feature}/2-plan/spec.md`
-- `.morph/features/{feature}/2-plan/mandate.md`
 - `.morph/features/{feature}/2-plan/tasks.json`
 - Gates 1 e 2 registrados aprovados em `.morph/features/{feature}/feature.json` (autoritativo) — via `morph-spec approve`/`morph-spec advance` em auto, ou via hook state-sync no caminho manual.
 

package/framework/skills/core/morph-review/SKILL.md

@@ -4,455 +4,134 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-review
 
 ## Objetivo
-Verificar se a implementação atende ao mandate.md e produzir um review-report.md
-claro o suficiente para que o usuário tome a decisão de aprovação ou rejeição.
+Responder, com evidência, uma pergunta: **a entrega faz o que os use cases dizem, sem quebrar o que
+já funcionava?** O Gate 3 decide por veredito (`SHIP`/`FIX`) e bloqueadores tipados — não por nota.
 
 ## Quando invocar
-Ao iniciar a fase review — após todas as tasks de `tasks.json` estarem com status `done`
-e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `morph-apply`.
+Fase review, com todas as tasks `done` e o `recap.md` em dia. Normalmente chamada pela `morph-apply`.
 
-## O que fazer
-
-1. **Garanta que todos os artefatos de plano estão no seu contexto antes de revisar.** Se você não tem o conteúdo atual em contexto (sessão fresca, ou conteúdo possivelmente desatualizado), **use a tool Read para carregá-los** — não confie em cache de turnos anteriores que pode ter sido truncado ou evictado. Na dúvida, Read:
-   - `.morph/features/{feature}/2-plan/mandate.md` — critérios de done, standards obrigatórios, patterns proibidos.
-   - `.morph/features/{feature}/2-plan/spec.md` — arquitetura, FRs/NFRs, contratos esperados.
-   - `.morph/features/{feature}/2-plan/decisions.md` (se existir) — ADRs que devem ter sido seguidos pela implementação. Use para validar coerência entre decisão registrada e código produzido.
-
-   > O contrato é o conteúdo estar em contexto, não o número de chamadas a Read. Numa sessão quente onde você acabou de produzir esses artefatos, eles já estão disponíveis. Mas uma revisão sem o mandate em contexto não é uma revisão — é um chute. Nunca produza o review-report sem ter o mandate, spec e decisions disponíveis.
-
-2. **Use a tool Read em `.morph/features/{feature}/3-implement/recap.md`**. Verifique se todas as tarefas têm entrada e se os problemas foram resolvidos.
-
-3. Para cada critério do mandate.md, verifique se foi atendido:
-   - Se atendido: registre como "aprovado" com evidência (arquivo ou comportamento).
-   - Se não atendido: registre como "bloqueante" com descrição do gap.
-   - Se parcialmente atendido: registre como "pendência" com o que falta.
-
-   **Verificações mecânicas sempre-rodar** (independente do mandate mencionar ou não — cobrem bugs
-   reais já vistos em produção, ver `.morph/framework/evals/rubrics/architecture.md` → "Verificações
-   mecânicas obrigatórias"), quando o diff tocar endpoints minimal API ou fetch cross-camada:
-   - Todo serviço injetado numa lambda de endpoint tem `AddScoped`/`AddSingleton`/`AddTransient`
-     correspondente em `Program.cs`. Falha aqui é bloqueante — a app não sobe.
-   - Se há chamada server-direct ao backend e chamada client-side via proxy para o mesmo recurso,
-     confirme que usam duas constantes de prefixo nomeadas distintas, nenhuma reusada para o
-     outro propósito. Falha aqui é bloqueante — quebra silenciosa em runtime, não em build.
-
-4. **Antes de despachar, verifique se já existe um relatório íntegro** — inclusive em sessão
-   retomada. **Esta verificação NÃO é pulada porque a sessão foi retomada** — é exatamente esse o
-   cenário que já mordeu em produção: 4 sessões retomadas re-despacharam o avaliador do Gate 3 sem
-   nunca ler o `evaluator-report.md` que já existia, íntegro, desde o 1º dispatch (`APPROVED`, score
-   9.3) — e a 4ª sessão chegou a afirmar, falsamente, que "o avaliador nunca rodou". `SessionStart:
-   resume`/`init` não reseta este passo: ele roda sempre, a cada retomada de controle, antes de
-   cogitar um dispatch.
-   - Rode `morph-spec report-check {feature} --json` (sem `task`, modo feature inteira) e leia o
-     campo `evaluator` da resposta — ou, equivalente, leia `4-review/evaluator-report.md` direto e
-     confira: scores por dimensão presentes + a linha `**Composite-Score:**` presente = **íntegro**.
-   - **Se íntegro** (`evaluator.exists && evaluator.complete`): **NÃO despache de novo.** Pule direto
-     para "**Leia primeiro**" logo abaixo — leia o arquivo e siga para o passo 5 (síntese do
-     review-report a partir dele). Re-despachar aqui joga fora um veredito de Gate 3 já válido.
-   - **Se ausente, oco, ou sem scores por dimensão:** este é exatamente o caso de falha de protocolo
-     que este passo trata — prossiga com o dispatch abaixo.
-   - **Se `PARCIAL` na 1ª linha** (`evaluator.partial: true` no `report-check`): o avaliador anterior
-     parou no limite de turnos — não é ausente nem oco. Antes de um dispatch frio, siga o bullet
-     `PARCIAL` do "Leia primeiro" abaixo: continuar quem já provou metade custa menos que refazer a
-     rodada.
-
-   **Despache o avaliador independente** — o score do Gate 3 nunca é auto-atribuído por quem implementou:
-   - Rode `morph-spec verify {feature} --json` (escopo feature; exit 3 / `status: "busy"` é fila de slot pesado cheia, não vermelho: repita a chamada) e capture o JSON — é a saída real de build+testes+validadores+e2e que você anexa ao prompt do avaliador independente (`morph-evaluator`). **Sem `--filter`, sempre:** o `--filter` é do loop por task, onde o relógio de uma task não paga a suíte inteira; a prova que o avaliador lê tem de cobrir **todos** os nós de `nodes.tests.runs[]` (uma suíte filtrada aparece como `skip` nomeando o filtro — Gate 3 aberto sobre isso é verde sobre código não testado). Se a suíte inteira não couber numa chamada, rode-a em background; não a encolha com `--filter`. `verify {feature}` (sem task) **nunca recorta** — o recorte automático é só do escopo de task —, e um `verify {feature} --filter …` nem persiste o stamp (`persisted: false`, `reason: 'filtered'`) — o mesmo vale para `--skip-tests`/`--skip-build` no escopo de feature. Rode-o **depois** da última task: o `gate-check {feature} review` pausa quando o último stamp `verification` é de escopo `task:{id}`, porque aquela rodada cobriu só a task. Uma rodada por árvore: se o JSON vier com `repeatOf`, nada mudou fora de `.morph/` desde o verify de feature anterior — use aquele resultado em vez de rodar de novo; depois de uma correção a árvore mudou, e a nova rodada é a prova.
-   - **Confira o nó `e2e` do verify antes de despachar.** Ele carrega o estado do stack:
-     - `pass` → a aplicação subiu e está saudável; o avaliador pode navegá-la. **Passe a URL no prompt**
-       — cada feature roda no seu bloco de portas, não em `localhost:3000`; pegue de
-       `morph-spec e2e status {feature} --json` (`baseUrl`) e não deixe o avaliador adivinhar.
-     - `fail` → **não abra o Gate 3.** Volte ao loop de correção: a app não sobe, ou as specs quebraram.
-     - `skip` → **a classificação já é do `gate-check`, não sua.** A razão literal do skip viaja no
-       stamp `verification` (`e2eReason`) e `classifyE2eSkip` — em `risk-detector.js`, fonte única —
-       decide: `project` ("não containeriza") e `scope` ("o grupo de tasks não toca runtime") são
-       **dispensa legítima** e passam com o motivo gravado em `gateDecisions.review.signals`;
-       `environment` ("docker indisponível"), `requested` (`--skip-e2e`) e `unknown` (qualquer outra
-       razão, **inclusive razão nenhuma**) **pausam o Gate 3 sozinhos**. Não registre `gate-decision`
-       à mão para esses casos — deixou de ser necessário. O que continua sendo seu: dizer ao avaliador
-       que a app **não** foi exercida, e atacar a causa (rodar o e2e onde ele possa rodar) em vez de
-       despachar como se ela tivesse sido.
-   - **Confira também `traceability.warnings`** (advisory, nunca faz `verify` falhar): cada entrada é
-     um arquivo citado no `recap.md` sem task dona em `outputs` — repasse ao avaliador como sinal de
-     rastreabilidade para a dimensão de qualidade, não como bloqueio automático do gate.
-   - **Anexe o `reuse-map.md`** (`.morph/features/{feature}/2-plan/reuse-map.md`), quando existir: é o
-     que o plano decidiu por conceito (REUSAR/ESTENDER/CRIAR) e o único insumo que permite ao
-     avaliador julgar a dimensão `code-quality` **contra o codebase**, não só contra o diff — símbolo
-     recriado não aparece no diff como problema. Junto dele, repasse os achados do validador `reuse`
-     do nó `validators` do verify. Sem `reuse-map.md` (plano anterior a este passo), diga isso ao
-     avaliador em vez de deixá-lo supor que não havia conceito a reusar.
-   - **Anexe as evidências de runtime** (`.morph/features/{feature}/3-implement/evidencias/*.md`),
-     quando existirem — insumo, não veredito. São o que as tasks de critério sobre saída de LLM
-     gravaram rodando o eval (`morph-plan` §5); não confunda com `3-implement/reports/`, que diz o
-     que o sub-agente fez.
-   - Gere o **diff da implementação** (`git diff` do range da feature, ou a lista de arquivos do recap.md com seus conteúdos atuais).
-   - **Blast radius dos símbolos do diff (se houver grafo).** Para cada símbolo público que o diff tocou, rode `morph-spec graph affected <símbolo> --prod --json` e inclua o resultado no contexto do avaliador. É o que permite perguntar *"o que esta mudança pode ter quebrado FORA do diff"* sem que o avaliador leia o repositório inteiro. **Fallback:** `no-graph`, `not-found` ou `ambiguous` — siga sem o blast radius e **registre a ausência na seção de método do review-report**; o gate não depende disso. **Trate o resultado como possivelmente stale:** o refresh automático só cobre a raiz. Numa worktree o grafo é o semeado da raiz e não vê o que o diff trouxe — com `graph status --json` stale e `refresh.auto: false`, rode `morph-spec graph refresh` antes do blast radius; na raiz, enquanto o refresh em background corre (`refresh.running`), o grafo ainda é o anterior. E lembre que em frontend ele responde "quem importa", não "quem chama".
-   - **Tire a foto da árvore imediatamente antes do dispatch:** `morph-spec report-check {feature} --before-eval --json`, depois do verify e de qualquer correção sua. É contra ela que a higiene abaixo prova que o avaliador reverteu o que mutou.
-   - Despache o subagent registrado `morph-evaluator` (gerado de `agents.json` — a persona do avaliador é o system prompt dele, com Read/Glob/Grep + Bash somente para verificação + Playwright para navegar, sem Write/Edit), com contexto fresco:
-     ```
-     dispatch Agent (subagent_type: "morph-evaluator") with prompt:
-       contexto: mandate.md + spec.md + reuse-map.md + diff da implementação
-                 + saída real dos testes + nó e2e do verify (stack no ar? em qual URL?)
-                 + 3-implement/evidencias/*.md (quando existir)
-                 + 1-design/mockups.md (quando existir — o checklist de tela a conferir)
-       instrução: |
-         Você NÃO participou da implementação — avalie o que está no diff,
-         contra o mandate. NÃO leia `4-review/evaluator-report.md` neste
-         caminho antes de escrever o seu: se esse arquivo já existir quando
-         você começar, é resíduo de uma tentativa anterior — NÃO é insumo,
-         é o SEU caminho de escrita, não de leitura. Sua nota nasce do
-         mandate + spec + diff + testes, nunca do veredito de outro
-         avaliador; ler o relatório de um antecessor antes de pontuar é
-         ancoragem — exatamente o que "contexto fresco" existe para evitar.
-         Você tem Bash: use `morph-spec verify`, testes/build
-         do stack e `git log/diff/show` para conferir por conta própria o que
-         foi reportado, em vez de confiar cegamente. Aplique as rubricas em
-         .morph/framework/evals/rubrics/ (architecture 30%, contracts 25%,
-         code-quality 25%, test-coverage 20%) seguindo as bandas 0-10 de cada uma.
-         Se o nó e2e subiu o stack, NAVEGUE a aplicação com Playwright e
-         percorra os fluxos desta feature como um usuário faria — ler o diff
-         prova que o código existe, usar a aplicação prova que ela funciona.
-         Confira console e network atrás de erro que teste nenhum cobriu.
-         Registre no relatório o que você navegou e o que viu. Se um fluxo que
-         você exercitou merece virar regressão, RECOMENDE a spec Playwright —
-         recomendar é seu papel, escrever a spec não é.
-         NÃO suba nem derrube o stack por conta própria (`morph-spec e2e` e o
-         nó de verify fazem isso): stack que não sobe é achado de INFRA a
-         reportar, não defeito de implementação a pontuar.
-         NÃO reescreva código. NÃO toque em tasks.json, feature.json nem no board
-         de sessão — Bash é só para verificação, nunca para mudar estado.
-         Se o que você avalia é uma CORREÇÃO (rodada do loop, fix de achado
-         anterior), responda no relatório: O QUE ESTA CORREÇÃO ABRIU? Que
-         comportamento antes correto pode ter regredido, e há teste que
-         pegaria? Um fix que fecha um defeito e abre outro pontua alto em toda
-         dimensão e ainda assim piorou o produto — e essa pergunta é a única
-         que o score não faz sozinho. Não aceite "agora tem teste" como
-         fechamento: RE-EXECUTE os probes da rodada anterior.
-         PROCURE O QUE ESTÁ ERRADO — não confirme o que já foi dito.
-         Um relatório que só concorda com o recap não avaliou nada. A
-         pergunta que orienta a sua sessão inteira é: O QUE O IMPLEMENTADOR
-         NÃO VIU? O que ele não podia ver do lugar onde estava, o que ele
-         viu e não mediu, e o que ele mediu com a régua errada.
-         PROVE, não confie: um teste verde prova que o código RODA, nunca
-         que o teste MORDE. Aplique as cinco rubricas de PROVA e pontue-as
-         0-10 (elas NÃO são dimensões do composto; impõem teto em
-         test-coverage):
-           .morph/framework/evals/proof-rubrics/mutation-proof.md
-           .morph/framework/evals/proof-rubrics/verde-nao-e-coberto.md
-           .morph/framework/evals/proof-rubrics/fiacao.md
-           .morph/framework/evals/proof-rubrics/guard-cego.md
-           .morph/framework/evals/proof-rubrics/eval-de-modelo.md
-         Para a eval-de-modelo: se existir
-         `.morph/features/{feature}/3-implement/evidencias/`, LEIA antes de pontuar `eval`:
-         confronte o veredito com a saída registrada, e degrade o cenário que a
-         evidência aponta. Evidência é insumo, não veredito.
-         E, SÓ quando a feature chama LLM, mais uma — que impõe teto em
-         code-quality, não em test-coverage:
-           .morph/framework/evals/proof-rubrics/observabilidade-genai.md
-         A aplicabilidade dela NÃO é determinística, e isso é deliberado:
-         nenhuma leitura de tasks.json ou do mandate mede "esta feature
-         chama um modelo". São DUAS etapas. (1) FILTRO mecânico, de alta
-         recall: o mandate.md cita ao menos um standard ai-agents — falso
-         ⇒ `not_evaluated`, sem mais discussão. (2) DETERMINAÇÃO sua, por
-         escrito: a feature entrega código que CHAMA um modelo? Registre a
-         resposta COM O MOTIVO (o símbolo/arquivo que chama, ou por que o
-         diff não chama nada). Task com group em {docs, tests} é INDÍCIO
-         contra, nunca veredito — um harness de agente vive inteiro em
-         `tests`. `not_evaluated` NÃO aplica teto, e um not_evaluated MUDO
-         não é dispensa: é o escape que o standard ai-agents-guardrails
-         proíbe (standard, não rubrica — não existe rubrica de guardrails).
-         Ela pergunta a PROPRIEDADE ("dá para reconstruir o que foi
-         ao provedor, e o que ele respondeu, neste turno?"), nunca "tem span
-         OpenTelemetry?": telemetria própria COM teste de fidelidade alcança
-         9-10 igual, e wiring sem evidência capturada não passa de 8.
-         MUTAÇÃO — o método, e a ordem dele importa:
-           - COMMITE O FIX ANTES DE MUTAR. Se a sessão morrer no meio, o
-             que sobrevive é a mutação, não a correção.
-           - VOCÊ ESCOLHE os mutantes: ancore no CALL SITE que carrega a
-             decisão, não no `if` refatorado. Uma rodada POR CLÁUSULA de um
-             predicado composto — cada cláusula é um mutante próprio.
-           - ESCREVA `.morph/features/{feature}/4-review/mutants.json`:
-             {"mutants":[{"id":"M1","file":"src/x.cs","line":42,
-             "find":"a && b","replace":"a"}]}. `find` começa na `line` e é
-             único nela; arquivo:linha, diff e md5 saem da ferramenta.
-             Com a ferramenta Write, se você a tem; só com Bash, heredoc
-             de delimitador entre aspas simples. O transporte do Bash
-             reduz `\\` a `\` e decodifica escapes unicode, então escreva
-             cada barra invertida do código como `{{BS}}` (a ferramenta a
-             expande): atravessa qualquer transporte. `find` que deixa de
-             bater com o arquivo é recusado com o erro, nunca aplicado.
-           - RODE `morph-spec mutate {feature}` UMA vez, com o Bash. Ela
-             faz o lote inteiro: um build só (chaves por variável de
-             ambiente; o que a chave não compila cai para rebuild real),
-             subconjunto de testes primeiro — escolhido por ela, não por
-             você — e, para CADA sobrevivente, o mutante compilado de
-             verdade contra a suíte INTEIRA. Só esse caminho produz
-             "sobreviveu"; "derruba K de M" sempre diz o escopo do K
-             (≥K no subconjunto, K na suíte inteira); na suíte inteira a
-             falha tem de se repetir, senão é instabilidade e o mutante
-             sobrevive. Sem a ferramenta,
-             mute e rode a suíte INTEIRA à mão, um mutante por vez.
-           - LEIA O MOTIVO da falha, não só o md5: md5 prova que ALGO
-             mudou, jamais O QUÊ. Falha de build não é morte, e
-             `inconclusive` não conta como nada.
-           - A REVERSÃO é da ferramenta: bytes do snapshot com md5
-             conferido, por escrita NOVA, rebuild forçado e a DLL final
-             igual (md5) à construída antes do 1º mutante. NUNCA `os.utime`
-             para devolver o mtime: o MSBuild acha o binário do último
-             mutante em dia e a rodada-base roda sobre ele. NUNCA
-             `git checkout --`: ele descarta trabalho não commitado de
-             outra pessoa — aconteceu de verdade num Gate 3 desta epic.
-             Rodada que morreu no meio: `morph-spec mutate --restore`.
-           - TERMINE com `git status --porcelain src/` VAZIO e exit 0. Exit
-             4 é inseguro (arquivo não restaurado, árvore ou binário
-             diferentes): resolva antes de pontuar.
-         Cole no relatório a seção `## Mutações` que a ferramenta imprime
-         (ela também a grava em `4-review/mutation-section.md`), uma linha
-         por mutação, com os CINCO campos: arquivo:linha | diff | md5
-         antes/depois | quantos testes derrubou (com o escopo) | o MOTIVO
-         literal da falha. Feature sem código de produção declara a seção
-         com a linha `não aplicável — feature sem código de produção`. A
-         seção é OBRIGATÓRIA: sem ela o `morph-spec gate-check` PAUSA o
-         Gate 3 sozinho, e nenhum score alto compra a passagem.
-         MÍDIA GERADA — rubrica CONDICIONAL, aplique SÓ se a feature gera
-         mídia (alguma task de tasks.json cita, em standards[], um destes:
-         standards/ai-agents/modalities-image-gen.md,
-         standards/ai-agents/media-video.md,
-         standards/ai-agents/media-pipeline.md). Nesse caso aplique também
-         e pontue 0-10:
-           .morph/framework/evals/proof-rubrics/media-claims.md
-         Ela cobra QUATRO afirmações — custo, revisão humana, marcação e
-         hot path não bloqueado — cada uma com o código que a prende e o
-         teste que a prova. Grave a seção `## Mídia gerada` com uma linha
-         por afirmação. A seção é OBRIGATÓRIA nessa condição: sem ela o
-         `morph-spec gate-check` PAUSA o Gate 3. Feature que NÃO gera mídia
-         não declara a seção nem a chave — a isenção é automática, e
-         escrever a seção "por precaução" é cerimônia vazia.
-         CHECKLIST DE TELA — CONDICIONAL, aplique SÓ se
-         `.morph/features/{feature}/1-design/mockups.md` existe com telas
-         `## Tela:`. Para cada tela, confira cada item decidido do seu
-         `### Checklist de tela` (volume, paginação, ordenação, filtro, os
-         três estados, mobile, abas) contra a tela ENTREGUE — navegando
-         quando o stack subiu, lendo o código quando não (a query pagina e
-         ordena no servidor? o estado vazio existe?). Grave a seção
-         `## Checklist de tela`, uma linha por item decidido de cada tela:
-           | Tela | Item | Mockup (planejado) | Entregue (observado) | Veredito |
-         com o nome da tela como está no mockup e veredito cumpre / diverge
-         / não verificável (com o motivo). Itens "não se aplica" e a
-         Superfície não precisam de linha. Divergência pesa em CONTRATOS
-         (.morph/framework/evals/rubrics/contracts.md, "Contrato de tela").
-         Sem a seção, ou com item decidido sem linha, o `morph-spec
-         gate-check` PAUSA o Gate 3.
-         Grave também a linha literal, machine-readable:
-         `**Proof-Scores:** mutation={n} verde={n} fiacao={n} guard={n} eval={n}`
-         — os cinco 0-10, na ordem das rubricas acima. O MENOR deles
-         impõe o teto em test-coverage (tabela em
-         .morph/framework/evals/rubrics/test-coverage.md).
-         Se a feature gera mídia, acrescente ` media={n}` à MESMA linha.
-         Se a rubrica de observabilidade GenAI se aplicar, acrescente
-         ` obs={n}` (ou ` obs=not_evaluated`) à MESMA linha.
-         As duas são lidas À PARTE: NÃO entram no mínimo acima (um media ou
-         um obs baixo não pode derrubar o teto de teste por um motivo que
-         não é de teste). `media` impõe teto em ARQUITETURA (tabela em
-         .morph/framework/evals/rubrics/architecture.md) e `obs` impõe teto
-         em CODE-QUALITY (tabela em
-         .morph/framework/evals/rubrics/code-quality.md).
-         Contrato do relatório final: GRAVE seu relatório em
-         `.morph/features/{feature}/4-review/evaluator-report.md` ANTES de
-         encerrar — esse arquivo é o valor de retorno autoritativo desta
-         sessão. A sua última mensagem de texto é cortesia best-effort: pode
-         não chegar inteira ao orquestrador (o evento recebido às vezes é só
-         um idle_notification, sem texto). Ainda assim NÃO chame SendMessage:
-         ele gera um evento a mais além da notificação de término, custando
-         um turno inútil ao orquestrador.
-         Limite de turnos: se chegar a ~70% dele sem terminar, grave o
-         relatório com `PARCIAL` na 1ª linha e SEM `**Composite-Score:**`
-         (o que já provou, o que falta) — o gate-check leria o token como
-         final. Ao concluir, o relatório final substitui o parcial.
-         Seu relatório (no arquivo, e na mensagem final quando ela chega)
-         deve conter: score 0-10 por dimensão, score composto (arch×0.30 +
-         contracts×0.25 + quality×0.25 + tests×0.20) gravado TAMBÉM como a
-         linha literal `**Composite-Score:** {n.n}` (machine-readable — o
-         `morph-spec gate-check` lê o score real daí em vez do proxy de
-         taskScores), feedback priorizado (bloqueantes primeiro) para
-         qualquer dimensão < 9, e — quando o stack estava no ar — o que você
-         navegou e o que observou. Relatório ausente, oco, ou sem esses itens,
-         é falha de protocolo.
-     ```
-   - **Fallback (tipo não registrado):** se `morph-evaluator` não estiver na sua lista de subagent types, despache `general-purpose` colando o campo `persona` do agente `evaluator` (Read em `.morph/framework/agents.json`) no topo do prompt — e **registre o fallback no review-report** (seção de método).
-   - **Ao retomar o controle, HIGIENE DA ÁRVORE antes de qualquer leitura de score.** ANTES de
-     abrir o relatório, rode `morph-spec report-check {feature} --json`. A foto que o
-     `--before-eval` gravou antes do dispatch fica em `4-review/`, e é contra ela que o bloco `tree`
-     compara, em qualquer sessão — inclusive a que retoma depois de o avaliador morrer no meio:
-     - `tree.sinceBeforeEval.changed` vazio = o conteúdo de todo arquivo fora de `.morph/` é o de
-       antes do dispatch, e o avaliador reverteu o que mutou. Com arquivos listados, a mutação
-       ficou no disco (ou foi commitada) nesses arquivos;
-     - `tree.markers` vazio = nenhum marcador `MUTACAO` esquecido;
-     - `tree.sinceBeforeEval` `null` = não há foto (dispatch anterior a ela): confira cada arquivo
-       da seção `## Mutações` contra o md5 "antes" registrado; `tree` `null` = o git não respondeu,
-       e nada foi conferido.
-
-     Não tire a foto de novo antes desta higiene passar: a foto nova apagaria a prova da anterior.
-
-     **Por que antes:** o avaliador
-     muta código de produção de propósito, e um avaliador que morreu no meio da rodada deixa a
-     mutação NO DISCO. Ler o score primeiro e só depois descobrir a árvore suja significa ter
-     avaliado — e possivelmente aprovado — um estado que ninguém quis. E **não rode build/teste
-     enquanto o agente ainda está `running`**: ele muta o disco a meio, e o vermelho que você veria
-     seria da mutação dele, não do produto.
-
-     Árvore suja aqui é **falha de protocolo**. Reverta **pela mesma disciplina que o prompt exige
-     do avaliador** — nunca por git: peça o snapshot que ele diz ter feito (`cp` ANTES de mutar) e
-     restaure por cópia, conferindo `md5sum` de cada arquivo. Sem snapshot recuperável, o caminho é
-     desfazer a edição **linha a linha**, a partir do `diff` que a seção `## Mutações` obriga a
-     registrar. Registre o que fez na seção de método do review-report.
-
-     > **NUNCA `git checkout -- src/` aqui**, nem com ressalva. Na árvore típica de uma feature em
-     > review **não existe nenhum commit da feature** — o trabalho inteiro está não commitado, e o
-     > `checkout` o apaga junto com a mutação. Numa árvore desta epic havia 23 arquivos modificados
-     > e zero commits próprios; nesta mesma epic um avaliador rodou esse comando e destruiu
-     > alterações não commitadas de outro agente (só não houve perda porque ele tinha capturado o
-     > diff antes). É a mesma proibição que o prompt do passo 4 já dá ao avaliador: aqui ela vale
-     > para VOCÊ.
-   - **Leia primeiro** `.morph/features/{feature}/4-review/evaluator-report.md` — é o valor de retorno autoritativo, não a mensagem de texto do dispatch (que é cortesia, útil só quando chega inteira). Os scores por dimensão e o composto do review-report vêm **desse arquivo**, não da sua auto-avaliação. Se o arquivo vier ausente, oco, ou sem os scores por dimensão, registre a falha de protocolo na seção de método do review-report e re-despache.
-   - Com o relatório lido, rode `morph-spec worktree reap --json`: a árvore do avaliador que parou limpa sai sozinha; a que ficou com trabalho vem listada com a razão.
-   - **`PARCIAL` na 1ª linha = o avaliador parou antes do fim** (limite de turnos; o `report-check` devolve `evaluator.partial: true`). Não leia score dele — o parcial não tem `**Composite-Score:**`, e o `gate-check` pausaria de qualquer jeito — e não re-despache frio: um avaliador novo refaz a rodada inteira (probes, mutações, navegação). Retome o MESMO avaliador por `SendMessage`, como no passo 6, colando `tree.dirty` e `tree.commits` do `report-check` no recado; ele completa o relatório, e o final substitui o parcial. Só se o id não retomar, despache um novo pelo caminho normal — o parcial no disco é resíduo, não insumo, como o prompt já diz. Antes de qualquer das duas, a higiene da árvore acima continua valendo: um avaliador cortado no meio pode ter deixado mutação no disco.
-
-5. Produza `review-report.md` em `.morph/features/{feature}/4-review/` com:
-   - **`**Reviewed-SHA:** {git rev-parse HEAD}`** — o commit que você revisou, **obrigatório**.
-     Um review revisa uma ÁRVORE, e a árvore anda: sem esse carimbo, um relatório escrito antes
-     da última task fica no repo afirmando números e cobertura que já não valem. O
-     `morph-spec approve {feature} review` compara o carimbo com o HEAD e **recusa** se divergirem
-     (aconteceu de verdade: relatório de `b30ac6e` sobrevivendo à T3, que inverteu o default de
-     uma regra de negócio, e ainda dizendo `976/976` quando eram 982).
-   - Scores por dimensão (arquitetura, contratos, qualidade, cobertura)
-   - Score composto final
-   - **Verificação de runtime** — o resultado do nó `e2e` (`pass`/`fail`/`skip` + razão), e o que o
-     avaliador navegou. Dispensa (`skip`) entra aqui **por extenso**: o valor de um gate está tanto
-     no que ele provou quanto no que ele deixou de provar, e uma dispensa silenciosa se lê como
-     aprovação. Se houver spec Playwright recomendada pelo avaliador, liste-a como melhoria.
-   - **Prova de mutação** — a seção `## Mutações` do `evaluator-report.md`, repassada aqui em
-     resumo (quantas mutações, quantas derrubaram teste, e a linha `**Proof-Scores:**`). O formato
-     que o avaliador grava, e que o `morph-spec gate-check` cobra:
-
-     ```markdown
-     ## Mutações
-
-     | # | Arquivo:linha | Mutação (diff) | md5 antes | md5 depois | Testes derrubados | Motivo da falha |
-     |---|---|---|---|---|---|---|
-     | M1 | src/lib/x.js:42 | `- if (a && b)` / `+ if (a)` | abc… | def… | ≥3 de 212 (subconjunto) | `expected 3 got 0` em x.test.js:88 |
-     | M2 | src/lib/y.js:7 | `- return ok` / `+ return true` | 123… | 456… | 0 de 2684 (SOBREVIVEU, suíte inteira) | nenhum teste falhou na suíte inteira |
-
-     **Reversão:** snapshot/restore de bytes por escrita nova; DLL final igual (md5); `git status --porcelain src/` vazio.
-     **Proof-Scores:** mutation=9 verde=8 fiacao=9 guard=7
-     ```
-
-     Feature sem código de produção declara a seção com `não aplicável — feature sem código de
-     produção`. **Sem a seção, o `gate-check review` PAUSA** — a regra vive em código
-     (`risk-detector.js`), não na boa vontade do prompt.
-   - **Checklist de tela** (feature com `1-design/mockups.md`) — a seção `## Checklist de tela` do
-     `evaluator-report.md` em resumo: quantas telas e itens conferidos, e cada `diverge` por extenso
-     (tela, item, planejado × entregue). Sem ela, havendo item decidido a conferir, o `gate-check review` **pausa** — o design decidiu
-     como a tela pagina, ordena e falha, e o Gate 3 registra se a tela entregue cumpre.
-   - Lista de itens bloqueantes (se houver) — com descrição e critério de resolução
-   - Lista de melhorias recomendadas (não bloqueantes)
-   - Recomendação final: Aprovado / Rejeitar com condições / Reprovar
+## Ritmo
+- Comando em **primeiro plano**, com timeout. O único que pode passar do teto de 10 min do Bash é o
+  `verify {feature}` de um projeto grande: aí rode-o com `run_in_background` e espere a notificação
+  de término. Nunca `sleep`/`until` consultando um processo: a espera custa a máquina e não produz prova.
+- **Bloqueio de ambiente não é laço.** Memória baixa, slot pesado ocupado (`verify` exit 3 /
+  `status: "busy"`), Docker fora: tente **uma** vez mais. Persistiu, siga com o que tem — o
+  `gate-check` pausa com a razão e o humano decide. Nunca agende retentativas.
 
-6. Se houver itens bloqueantes (score < 8 em qualquer dimensão bloqueante), corrija antes
-   de apresentar o review-report.md ao usuário. Não abra o Gate 3 com bloqueantes em aberto.
-   (A barra de avanço por task é 9; uma dimensão individual abaixo de 8 no review da feature
-   inteira é um bloqueante crítico que o loop de correção deveria ter pego.)
-
-   **Para CONFIRMAR uma correção, retome o MESMO avaliador — não despache um frio.** Use
-   `SendMessage` com o id do agente que já avaliou, colando no recado `tree.dirty` e `tree.commits`
-   do `report-check {feature} --json` — o que mudou desde o relatório dele. Antes do recado, tire a foto de novo (`--before-eval`): suas correções mudaram a árvore, e a próxima higiene compara com a árvore que ele vai receber. Ele já tem em contexto o que apontou e
-   os probes que rodou; um avaliador novo re-descobre o produto inteiro para checar um item, e
-   re-executa do zero os probes da rodada anterior.
-
-   > Isto **não** contradiz a cláusula que proíbe o **sub-agent** de chamar `SendMessage`. As
-   > direções são opostas: o sub-agent não chama `SendMessage` porque o retorno dele é o ARQUIVO, e
-   > uma mensagem a mais custa um turno inútil ao orquestrador. Aqui quem fala é o ORQUESTRADOR,
-   > para dentro de uma sessão que ele mesmo abriu — a única forma de continuar uma avaliação em vez
-   > de recomeçá-la. Se o agente já encerrou e o id não retoma, aí sim despache um novo, e diga a
-   > ele no prompt que é uma REAVALIAÇÃO (o relatório é append-only: ele acrescenta ao fim, e o
-   > `gate-check` lê o token do FIM, o vigente).
-
-7. **NÃO finalize o trace manualmente.** O hook `trace-autogen` gera e finaliza `.morph/traces/YYYY-MM-DD-{feature}-implement.json` automaticamente (incl. `phase_summary` e `completed_at`) no último write de `tasks.json` — quando a última task sai de `pending`/`in_progress`. Se o trace parecer desatualizado, a causa é um `morph-spec score` faltante ou um recap sem o bloco da task — corrija a fonte, não o trace.
-
-8. Apresente o Gate 3 segundo trust mode — **única apresentação do gate**: `morph-apply` §5 aponta
-   para cá em vez de duplicar; ao devolver o controle a ela, o gate já está decidido.
-
-   Rode `morph-spec gate-check {feature} review [--json]` — lê `trust` de `.morph/config/config.json`, decide via `shouldPauseGate` e persiste `gateDecisions.review` com timestamp server-side, imprimindo `pause`/`reason`/`signals`. É o default — não recompute a tabela do MORPH.md §5 em linguagem natural.
-
-   **NÃO passe `evalScore` por `--signals` aqui.** O composto do avaliador é lido do disco sozinho: o `gate-check` procura o token `**Composite-Score:**` em `4-review/evaluator-report.md` (passo 4) e carimba `evalScoreSource: evaluator-report` — a **única** procedência que o Gate 3 aceita. Um `evalScore` vindo por override troca o valor mas rebaixa a procedência para `signals-override`, e o Gate 3 **pausa** por "sem score do avaliador independente" sem sequer olhar o número — inclusive quando é o mesmo número do relatório. Sem o token (relatório ausente ou oco), o `evalScore` cai na **PROXY** das `taskScores` — auto-avaliação de quem implementou — e o gate pausa igual. A correção, nos dois casos, é produzir o relatório íntegro do passo 4; nunca o override.
+## O que fazer
 
-   Os itens bloqueantes das **verificações mecânicas sempre-rodar** do passo 3 continuam entrando por `--signals` — é para isso que a flag serve aqui:
+1. **Contexto.** Tenha em contexto `2-plan/spec.md`, os use cases (`2-plan/usecases/UC-*.md`),
+   `2-plan/decisions.md` (se existir) e `3-implement/recap.md`. Numa sessão quente eles já estão
+   lá; numa fria, Read.
+
+2. **Relatório já íntegro?** Rode `morph-spec report-check {feature} --json` (sem task) e leia o
+   campo `evaluator` — também em sessão retomada: retomar não reseta este passo.
+   - `evaluator.complete` (tem `**Verdict:**` válido e não é parcial): **não re-despache** — vá ao
+     passo 5.
+   - `evaluator.partial: true` (`PARCIAL` na 1ª linha): ver "PARCIAL" no passo 4.
+   - Ausente ou sem veredito: siga para o passo 3.
+
+3. **Prova da suíte — uma rodada, sua.** Rode `morph-spec verify {feature} --json` **depois da
+   última task** (o `gate-check` pausa o ship se o último stamp é de escopo `task:{id}`).
+   **Sem `--filter`, sempre**: `verify {feature}` **nunca recorta**, e um verify filtrado não persiste o
+   stamp. Se o JSON vier com `repeatOf`, nada mudou desde a rodada anterior — use aquela. Esta é a
+   única execução de testes do Gate 3: o avaliador não roda a suíte de novo.
+   - Nó `e2e`: `pass` → passe a URL ao avaliador (`morph-spec e2e status {feature} --json` →
+     `baseUrl`). `fail` → volte à correção. `skip` → quem classifica é o `gate-check`
+     (`classifyE2eSkip`, em `risk-detector.js`): dispensa de projeto/escopo passa; ambiente,
+     `--skip-e2e` ou razão desconhecida pausam sozinhos. Diga ao avaliador que a app não foi exercida.
+   - `traceability.warnings`: repasse ao avaliador como sinal, não bloqueio.
+
+4. **Despache o avaliador independente** (`morph-evaluator`, contexto fresco, sem Write/Edit).
+   - Tire a foto da árvore e escolha o modelo: `morph-spec report-check {feature} --before-eval --json`.
+     O campo `evaluatorModel.model` é `sonnet` por padrão e `opus` quando o diff toca auth, segredo,
+     pagamento, migração, prompt/modelo ou mídia gerada (`evaluatorModel.reasons` diz por quê).
+   - Blast radius: para cada símbolo público do diff, `morph-spec graph affected <símbolo> --prod --json`.
+     Sem grafo (`no-graph`/`not-found`/`ambiguous`), siga sem o blast radius e registre a ausência no
+     review-report. Numa worktree com grafo stale, `morph-spec graph refresh` antes.
    ```
-   morph-spec gate-check {feature} review --signals '{"standardsViolations":[]}'
+   dispatch Agent (subagent_type: "morph-evaluator", model: {evaluatorModel.model}) with prompt:
+     contexto: use cases + spec.md + diff da feature + JSON do verify (nós, e2e, URL)
+               + blast radius + 1-design/mockups.md (se existir) + 3-implement/evidencias/*.md (se existir)
+     instrução: |
+       Siga .morph/framework/evals/review-checklist.md e grave
+       .morph/features/{feature}/4-review/evaluator-report.md ANTES de encerrar — o arquivo é o
+       retorno; não chame SendMessage. Se o arquivo já existir quando você começar, é resíduo de
+       outra tentativa: não o leia antes de escrever o seu (ancoragem no veredito alheio).
+       A suíte já rodou (JSON acima): você NÃO roda verify, build nem testes. Bash é para ler
+       (git diff/log/show, grep, morph-spec graph) e para no máximo UMA rodada de
+       `morph-spec mutate {feature}` (até 3 mutantes com `expect`), só quando o checklist pede.
+       Nada em segundo plano, nada de laço de espera. NUNCA `git checkout --`: descarta trabalho
+       não commitado.
+       Com stack no ar, navegue os fluxos da feature e confira console/network.
+       Limite de turnos: a ~70% sem terminar, grave o relatório com `PARCIAL` na 1ª linha e SEM
+       `**Verdict:**`; o relatório final substitui o parcial.
    ```
-
-   Julgamento do revisor que nenhuma dessas chaves representa — e forçar a passagem apesar da pausa: use `gate-decision` direto em vez de `gate-check` (`morph-spec gate-decision {feature} review --pause false --reason "..."`), que é explícito e fica registrado.
-
-   **Nunca edite `feature.json` à mão** (colide com o hook state-sync — erro "file modified since read"). Os caminhos acima gravam no mesmo lugar; o hook `gate-guard.js` confere depois se a ação bateu com a decisão persistida.
-
-   **Se `pause === true`**, use `AskUserQuestion`:
-
+   Tipo `morph-evaluator` não registrado: `general-purpose` com o campo `persona` do `evaluator`
+   (`.morph/framework/agents.json`) no topo do prompt, e registre o fallback no review-report.
+
+   **Ao retomar o controle — higiene antes de ler o veredito.** Rode `morph-spec report-check {feature} --json`:
+   - `tree.sinceBeforeEval.changed` vazio e `tree.markers` vazio = árvore como antes do dispatch.
+     Arquivo listado = mutação que ficou no disco: `morph-spec mutate --restore` devolve os bytes do
+     snapshot conferindo md5; fora de uma rodada de mutação, desfaça linha a linha pelo diff.
+     **NUNCA `git checkout -- src/` aqui**: na árvore de
+     uma feature em review não existe nenhum commit da feature, e o checkout apaga o trabalho junto.
+   - `tree.sinceBeforeEval` `null` = sem foto; `tree` `null` = git não respondeu, nada foi conferido.
+   - Não rode build/teste enquanto o agente está `running`.
+
+   Depois leia `4-review/evaluator-report.md` e rode `morph-spec worktree reap --json`.
+
+   **PARCIAL** (`evaluator.partial: true`): não leia veredito dele e não re-despache frio — retome o
+   MESMO avaliador por `SendMessage`, colando `tree.dirty` e `tree.commits` no recado. Só se o id não
+   retomar, despache um novo.
+
+5. **Bloqueadores.** `**Verdict:** FIX` ou bloqueador aberto: corrija (loop da `morph-apply`), rode o
+   verify de novo e **confirme só os bloqueadores** retomando o MESMO avaliador por `SendMessage`
+   (com `tree.dirty`/`tree.commits` e uma foto `--before-eval` nova). Ele não reavalia a feature
+   inteira, e **nota nunca motiva nova rodada**. Avaliador encerrado: despache um novo dizendo que
+   é uma confirmação dos bloqueadores Bn — o relatório é append-only e vale o último `**Verdict:**`.
+
+6. **`4-review/review-report.md`**, curto:
+   - **`**Reviewed-SHA:** {git rev-parse HEAD}`** — obrigatório. O `approve` recusa se o HEAD andou
+     depois do review.
+   - `**Veredito:** SHIP|FIX` e a tabela de bloqueadores do evaluator-report (vazia = `Nenhum.`).
+   - Runtime: nó `e2e` (`pass`/`fail`/`skip` + razão por extenso) e o que foi navegado.
+   - Notas não bloqueantes, numa lista.
+
+7. **Gate 3.** Rode `morph-spec gate-check {feature} review [--json]` — ele lê o veredito do
+   evaluator-report e os demais sinais do disco e decide. Violação das verificações mecânicas entra
+   por `--signals '{"standardsViolations":[...]}'`. Forçar a passagem apesar de uma pausa:
+   `morph-spec gate-decision {feature} review --pause false --reason "..."` (explícito e registrado).
+   Nunca edite `feature.json` à mão.
+
+   **`pause === true`** → `AskUserQuestion`:
    ```
    question: "Gate 3 — Review de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
    header: "Gate 3"
    options:
-     - { label: "aprovado, fechar feature", description: "Marcar review aprovado; próximo passo é fechar com morph-spec finish --pr|--merge (ver morph-apply §6)" }
-     - { label: "preciso ajustar", description: "Apontar correções necessárias antes de fechar" }
-     - { label: "rollback", description: "Desfazer e voltar para implement" }
-   ```
-
-   **Se `pause === false`**, exibir summary curto e prosseguir:
-
-   ```
-   ## Gate 3 (auto-aprovado)
-
-   **Composite score:** {score}/10
-   **Dimensões:** arquitetura={X} contratos={Y} qualidade={Z} cobertura={W}
-   **Runtime:** e2e={pass|skip} {razão, quando skip}
-   **Bloqueantes:** {N (zero esperado em auto-aprovação)}
-   **Recomendação:** Aprovado
+     - { label: "aprovado, fechar feature", description: "Próximo passo: morph-spec finish --pr|--merge (morph-apply §6)" }
+     - { label: "preciso ajustar", description: "Apontar correções antes de fechar" }
+     - { label: "rollback", description: "Voltar para implement" }
    ```
+   **`pause === false`** → resumo de 3 linhas (veredito, runtime, bloqueadores: 0) e
+   `morph-spec approve {feature} review --mode auto`. A pergunta nomeia a feature: é por ela que o
+   hook `state-sync` grava a aprovação.
 
-   No caminho manual, o hook state-sync detecta a aprovação em answers de AskUserQuestion e grava `approvalGates.review = { approved: true, timestamp, approvedBy: "manual" }` no `feature.json` autoritativo da feature — **a atribuição vem do nome da feature na pergunta** (o template acima o carrega). Pergunta sem nome, com mais de uma feature na árvore: o hook recusa a gravar e avisa; aprove então por `morph-spec approve {feature} review`. Em auto sem AskUserQuestion, aprove via `morph-spec approve {feature} review --mode auto` — nunca via Edit à mão de state.json.
-
-   **Próximo passo (não é desta skill):** com o Gate 3 aprovado, a feature fecha por `morph-spec finish {feature} --pr|--merge` — a `morph-apply` §6 conduz a escolha PR vs merge. Não arquive nem integre aqui. **`--pr` não encerra a feature** — arquiva e termina, mas só integra no merge (`integrated: false`, `awaiting: "merge"` no payload); até lá a feature fica `aguardando-merge` em `morph-spec list`/`fleet`. `finished: true` não é sinônimo de entregue.
+   Fechar não é desta skill: `finish {feature} --pr|--merge` (`morph-apply` §6). `--pr` deixa a
+   feature `aguardando-merge` até o merge.
 
 ## Output esperado
-- `.morph/features/{feature}/4-review/evaluator-report.md` — relatório bruto e autoritativo do
-  `morph-evaluator` despachado no passo 4 (canal durável, ver MORPH.md §6)
-- `.morph/features/{feature}/4-review/review-report.md` — síntese do orquestrador a partir do
-  evaluator-report, com scores e recomendação
-- Trace da fase com `phase_summary` preenchido
-- Gate 3 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo), na forma canônica `{ approved, timestamp, approvedBy }` — via `morph-spec approve` em auto, ou pelo hook state-sync no caminho manual
+- `4-review/evaluator-report.md` — veredito e bloqueadores do avaliador independente (retorno autoritativo)
+- `4-review/review-report.md` — síntese com `Reviewed-SHA`
+- Gate 3 registrado em `feature.json` via `approve` ou pelo hook `state-sync`
 
 ## Referências
-- `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores+e2e anexada ao prompt do avaliador (passo 4)
-- `.morph/features/{feature}/2-plan/reuse-map.md` — veredito de reuso por conceito; insumo do avaliador para julgar `code-quality` contra o codebase
-- `.morph/framework/MORPH.md` — seção 5 (Gate 3 + regras de pausa), seção 1 (papel Evaluator), Trust Mode
-- `.claude/agents/morph-evaluator.md` — subagent do avaliador (gerado de `.morph/framework/agents.json`), despachado no passo 4
-- `.claude/skills/morph-eval/SKILL.md` — rubricas e bandas que o avaliador aplica
-- `.morph/framework/evals/proof-rubrics/` — as sete rubricas de PROVA citadas no prompt do passo 4
-  (`mutation-proof.md`, `verde-nao-e-coberto.md`, `fiacao.md`, `guard-cego.md`, `eval-de-modelo.md`, `media-claims.md`, `observabilidade-genai.md`):
-  não são dimensões do composto. **Cinco** impõem teto em `test-coverage` pelo MENOR delas — as quatro
-  universais mais `eval-de-modelo`, que perguntam a mesma coisa: *a evidência é real?*. As outras
-  duas são condicionais e entram FORA do menor-das-cinco: `media-claims.md`, em feature que gera
-  mídia, impõe teto em `architecture`; `observabilidade-genai.md`, em feature que chama LLM, impõe
-  teto em `code-quality`. Somá-las faria um `media=4` ou um `obs=4` derrubar o teto de TESTE por um
-  motivo que não tem nada a ver com teste.
-- `.morph/framework/evals/trace-schema.md` — formato canônico do trace
-- `.morph/features/{feature}/2-plan/mandate.md` — critérios de done da feature
-- `.morph/features/{feature}/2-plan/spec.md` — arquitetura e contratos
-- `.morph/features/{feature}/2-plan/decisions.md` — ADRs registrados (se existir)
-- `.morph/features/{feature}/3-implement/recap.md` — registro de execução
-- `.morph/features/{feature}/1-design/mockups.md` — o checklist de tela que o avaliador confere no passo 4 (quando a feature tomou o ramo uiux)
+- `.morph/framework/evals/review-checklist.md` — o que o avaliador procura e o formato do relatório
+- `morph-spec verify|mutate|report-check|gate-check` — `.morph/framework/CLI.md`
+- `.morph/framework/MORPH.md` §5 — sinais do Gate 3

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-stack-scan