@polymorphism-tech/morph-spec 8.44.0 → 8.46.0

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "8.44.0",
+  "version": "8.46.0",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -84,12 +84,10 @@ morph-spec retype {feature} {newType}                     # change type mid-flig
 ## CLI — state (server-side, timestamped)
 
 ```bash
-morph-spec score {feature} {task} [score] [--dims "9.5,9,9,9"]  # writes taskScores — {task} must match T<n> and {score} must be a number 0-10
-                                                                # a blank/missing score or a dotted taskId is REFUSED (exit 1), never recorded as a fabricated 0
 morph-spec gate-decision {feature} {gate} --pause <bool> [--reason] [--signals json]   # writes gateDecisions
 ```
 
-Never hand-edit `taskScores`/`gateDecisions`/`approvalGates` in `feature.json` — always go through these commands (they collide with the `state-sync` hook otherwise).
+Never hand-edit `gateDecisions`/`approvalGates` in `feature.json` — always go through these commands (they collide with the `state-sync` hook otherwise).
 
 ---
 
@@ -187,4 +185,4 @@ Never edited directly — go through CLI commands or `morph-spec update` instead
 
 ---
 
-*morph-spec v8.44.0 by Polymorphism Tech*
+*morph-spec v8.46.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -63,12 +63,12 @@ You approve the UI design before moving on.
 ### Plan (Gate 2)
 
 Claude produces, under `2-plan/`:
-- `spec.md` — full requirements, use cases, validations
-- `mandate.md` — the implementation contract (stack defaults, forbidden patterns)
+- `usecases/UC-*.md` — the behavior, with postconditions observable in a test
+- `spec.md` — architecture, contracts and the `## Contrato de implementação` section (standards, runtime verification)
 - `tasks.json` — ordered task breakdown (`T001`, `T002`, …)
 - `decisions.md` — architectural decision records (optional)
 
-Claude identifies ambiguities in the spec and resolves them with you before finalizing. You review and approve the spec + mandate + task list together.
+Claude identifies ambiguities in the spec and resolves them with you before finalizing. You review and approve the use cases, spec and task list together.
 
 At this point, planning is complete:
 
@@ -84,10 +84,10 @@ At this point, planning is complete:
 /morph-apply my-feature
 ```
 
-Claude reads `spec.md`, `mandate.md`, and `tasks.json`, then implements task by task with auto-advance (no pause between tasks unless there's a blocking ambiguity):
+Claude reads the use cases, `spec.md` and `tasks.json`, then implements task by task with auto-advance (no pause between tasks unless there's a blocking ambiguity):
 - Records task progress in `tasks.json`, writing the mutable `status`/`outputs`/`notes` fields
 - Runs the validators relevant to your stack after each task (e.g. `architecture`/`packages`/`contract-compliance` for .NET, `nextjs-component`/`css`/`design-system` for Next.js) via `morph-spec verify`
-- Applies `morph-eval` after each task — a score below 9 triggers an autonomous correction loop, not a pause
+- Closes each task when `verify` is green and every `doneCriteria` has the evidence that proves it — red triggers an autonomous correction loop, not a pause
 - Generates `3-implement/recap.md` on completion, then Gate 3 review (`4-review/`)
 
 ---
@@ -249,4 +249,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v8.44.0 by Polymorphism Tech*
+*morph-spec v8.46.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -15,13 +15,13 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 
 **NUNCA:**
 - Pular para código sem proposal aprovado (Gate 1) e plano aprovado (Gate 2).
-- Modificar o contrato do plano depois do Gate 2 — `spec.md`, `mandate.md`, e os campos `title`/`description`/`dependencies`/`effort`/`doneCriteria`/`group`/`agent`/`standards` de `tasks.json` ficam congelados (`protect-spec-files` bloqueia `Write`/`Edit`); mutáveis: `status`/`outputs`/`notes` (ver SEMPRE). **Fato errado sobre o código não exige revogar gate**: bloco `## Errata` append-only no fim, corpo intacto (MORPH.md §3). **Use cases (`2-plan/usecases/UC-*.md`) NÃO congelam** — editáveis por design.
+- Modificar o contrato do plano depois do Gate 2 — `spec.md` e os campos `title`/`description`/`dependencies`/`effort`/`doneCriteria`/`group`/`agent`/`standards` de `tasks.json` ficam congelados (`protect-spec-files` bloqueia `Write`/`Edit`); mutáveis: `status`/`outputs`/`notes` (ver SEMPRE). **Fato errado sobre o código não exige revogar gate**: bloco `## Errata` append-only no fim, corpo intacto (MORPH.md §3). **Use cases (`2-plan/usecases/UC-*.md`) NÃO congelam** — editáveis por design.
 - Escrever critérios de aceite no `proposal.md` — pertencem aos use cases (pós-condição **observável em teste**, chega **literal** ao `doneCriteria`).
 - Editar `.morph/specs/usecases/` à mão — só o `finish` escreve lá. Mudar um UC existente (`bug`): copie para `2-plan/usecases/` da feature e corrija lá.
 - Listar perguntas em texto simples — sempre `AskUserQuestion` (1-4 perguntas por chamada).
 - Usar `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), ou SQL cru sem justificativa.
 - Comentar o que nome, tipo ou teste já dizem: o padrão é nenhum comentário, mesmo ao lado de código comentado; o elo com a pós-condição vai no nome do teste (`architecture-code-comments`, hook `comment-guard`).
-- Editar `taskScores`, `gateDecisions` ou gates de `feature.json` à mão — sempre via `morph-spec score`/`gate-check`/`approve` (timestamps server-side; Edit manual colide com o hook `state-sync`).
+- Editar `gateDecisions` ou gates de `feature.json` à mão — sempre via `morph-spec gate-check`/`approve` (timestamps server-side; Edit manual colide com o hook `state-sync`).
 
 **SEMPRE:**
 - Auto-advance entre tarefas durante a fase implement — não pause sem ambiguidade bloqueante.
@@ -29,10 +29,10 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Atualizar `tasks.json` ao concluir cada task gravando só os campos mutáveis `status`/`outputs`/`notes` — via `Write` OU `Edit`.
 - Apresentar gates com o template fixo (MORPH.md/morph-plan). **A pergunta PRECISA nomear a feature** ("Gate 2 — Plano de {feature} aprovado?") — é por esse nome que `state-sync` atribui a aprovação ao `feature.json` certo. Sem nome, com mais de uma feature na árvore, ele **recusa gravar** — aprove com `morph-spec approve <feature> <gate>`.
 - Registrar decisões não triviais em `decisions.md`.
-- Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo, sem escalar ao humano entre tarefas. No Gate 3, o score composto vem do **avaliador independente** despachado pela `morph-review` — nunca de auto-avaliação de quem implementou.
+- Fechar cada task só com `verify {f} {T}` verde e cada `doneCriteria` com a evidência que o prova; vermelho ou critério sem prova dispara o loop de correção autônomo, sem escalar ao humano entre tarefas. No Gate 3, o veredito (`SHIP`/`FIX`) vem do **avaliador independente** despachado pela `morph-review` — nunca de quem implementou.
 - Em `hotfix`, o Gate 3 pausa **sempre** para um humano, mesmo em `trust: auto` — `approve ... review --mode auto` é recusado; aprove com `--approver`.
 - Confirmar antes de `finish`/`archive`/`delete` se o SessionStart avisar que outra sessão tem claim vivo na mesma feature.
-- **Contrato do relatório final** em todo dispatch de sub-agent: (1) grava o relatório em arquivo canônico ANTES de encerrar — `.morph/features/{f}/3-implement/reports/{taskId}.md` (avaliador: `4-review/evaluator-report.md`) — com os 4 itens obrigatórios (o quê / arquivos / problemas / auto-score 0-10); é o retorno autoritativo, nunca chamar `SendMessage`; (2) não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; (3) testes pelo orçamento, só o próprio filtro uma vez, sem red→green (a prova é o `verify` do orquestrador); (8) nunca mutar produção. Racional completo: `MORPH.md` §6. Templates: `morph-implement` §4, `morph-apply` §3b. **O orquestrador lê o arquivo ao retomar controle** — nunca confia só na mensagem de retorno da tool.
+- **Contrato do relatório final** em todo dispatch de sub-agent: (1) grava o relatório em arquivo canônico ANTES de encerrar — `.morph/features/{f}/3-implement/reports/{taskId}.md` (avaliador: `4-review/evaluator-report.md`) — com o quê / **Arquivos:** / **Critérios:** (cada doneCriteria com evidência) / problemas; é o retorno autoritativo, nunca chamar `SendMessage`; (2) não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; (3) testes pelo orçamento, só o próprio filtro uma vez, sem red→green (a prova é o `verify` do orquestrador); (8) nunca mutar produção. Racional completo: `MORPH.md` §6. Templates: `morph-implement` §4, `morph-apply` §3b. **O orquestrador lê o arquivo ao retomar controle** — nunca confia só na mensagem de retorno da tool.
 
 ## Slash commands
 
@@ -52,7 +52,6 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 |---------|-----------|
 | `approve <f> <gate> --mode auto` | Aprova gate em `trust:auto`. Gate 3 exige `evaluator-report.md` (ou `--self-assessed`); `hotfix` nunca aceita `--mode auto` — use `--approver` |
 | `advance <f>` | Aprova o gate corrente + já cria a pasta da próxima fase |
-| `score <f> <task> <n> [--dims a,c,q,t]` | Grava `taskScores` server-side (nunca à mão) |
 | `gate-check <f> <gate> [--json]` | Default: decide via sinais do disco (`shouldPauseGate`) |
 | `gate-decision <f> <gate> --pause <bool>` | Escape manual: risco que o disco não vê |
 | `create <f> --description "..." --type <t>` | Nasce a feature + `feature.json`; `--worktree` já isola |
@@ -69,7 +68,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 | `dag <f>` | DAG de `tasks.json`: sequencial/paralelo, recomenda isolamento |
 | `graph status\|build\|refresh` | Grafo de codebase. `status` reporta frescor e se há refresh em background |
 | `graph affected\|explain <sym>` | Blast radius e vizinhança saneados. Sem grafo, caia para grep — nunca é erro |
-| `verify <f> [task] [--json]` | Build+testes+validadores+e2e, antes do juiz LLM |
+| `verify <f> [task] [--ci]` | Build+testes+validadores+e2e — prova da task; a do Gate 3 com `--ci` (no CI) |
 | `e2e up\|status\|down <f>` | Stack de verificação (docker compose) |
 | `doctor --worktrees [--prune]` | Reconcilia git × disco × features; só `--prune` remove algo |
 | `report-check <f> [task...] [--json]` | Audita relatório de sub-agent vs. trabalho entregue |
@@ -85,9 +84,8 @@ Prefixo de todo comando: `morph-spec`. Flags/exemplos: `.morph/framework/CLI.md`
 | `morph-brainstorming` | Entender negócio, escanear stack, produzir proposal.md |
 | `morph-stack-scan` | Desvios de stack em projeto brownfield |
 | `morph-uiux` | Ramo opcional de UI/UX — design system e mockups |
-| `morph-plan` | Destilar use cases e produzir spec.md + mandate.md + tasks.json |
+| `morph-plan` | Destilar use cases e produzir spec.md + tasks.json |
 | `morph-implement` | Executar uma tarefa com auto-advance entre tasks |
-| `morph-eval` | Aplicar rubricas e produzir score 0-10 |
 | `morph-review` | Produzir review-report.md (Gate 3) |
 | `morph-hotfix` | Hotfix cirúrgico (`/morph-hotfix`) |
 | `morph-standards` | Localizar standard sob demanda |

package/framework/MORPH.md

@@ -16,19 +16,17 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
 | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
 | Gate 1 / 2 / 3 aprovado | Avançar para próxima fase imediatamente |
 | Tarefa completada na fase implement | Iniciar a próxima task do tasks.json sem aguardar instrução |
-| Ambiguidade de escopo coberta pelo mandate | Resolver conservadoramente e registrar em decisions.md |
+| Ambiguidade de escopo coberta pelo plano | Resolver conservadoramente e registrar em decisions.md |
 | Ambiguidade bloqueante (requisito ausente ou contraditório) | UMA pergunta via AskUserQuestion |
-| Sub-agent retornou relatório (qualquer auto-score) | Auto-score é triagem, não aprovação: a task só avança com morph-eval ≥ 9 |
-| Sub-agent com auto-score < 7 | Re-despachar com feedback específico (ou corrigir inline) antes do morph-eval |
-| Build/typecheck quebra | Corrigir antes de marcar tarefa como done |
-| Task implementada (código escrito) | `morph-spec verify <feature> <task>` ANTES do juiz: vermelho = feedback ao loop sem gastar o morph-eval; verde → morph-eval avalia o que o código não pega |
-| Score morph-eval ≥ 9 | Silêncio (aprovação implícita), próxima tarefa |
-| Score morph-eval < 9 numa task | Loop de correção autônomo: re-implementar com feedback priorizado, até 3 tentativas, sem pausa humana |
-| Score morph-eval < 9 após 3 tentativas | Escalar ao usuário (aceitar/continuar/pular) — único ponto de pausa do loop |
+| Task implementada (código escrito) | `morph-spec verify <feature> <task>` e cada `doneCriteria` com a evidência que o prova |
+| Verify verde e critérios atendidos | Task `done`, próxima tarefa, sem anúncio |
+| Verify vermelho ou critério sem evidência | Loop de correção autônomo com o feedback, até 3 tentativas, sem pausa humana |
+| 3 tentativas sem fechar | Escalar ao usuário (aceitar/continuar/pular) — único ponto de pausa do loop |
+| `verify` exit 3 (fila pesada cheia) | A fila já esperou: no máximo uma chamada nova, depois avise — nunca laço de espera |
 
 **Regra de ouro:** dúvida que não bloqueia → resolver e registrar; dúvida que bloqueia → uma pergunta, máximo. Vale **entre gates** (plan/implement/review) — **não** vale na abertura da feature: a fase proposal pode rodar em **modo entrevista** (escolhido na pergunta de abertura, `morph-brainstorming` Parte 2), onde perguntar até fechar o entendimento é o comportamento desejado.
 
-**Código antes do juiz:** `morph-spec verify` (build+testes+validadores) é a barreira determinística e barata, sempre roda primeiro; o juiz LLM (morph-eval) só é acionado quando o verify passa — ele gasta tokens só no que o código não pega sozinho.
+**A prova é o código:** `morph-spec verify` (build+testes+validadores) prova o que é determinístico; o `doneCriteria` prova o comportamento. A suíte do Gate 3 roda no CI do projeto (`verify {f} --ci`: mesmo stamp, a máquina fica livre; sem CI, local). Não há nota por task — estilo e estrutura são nota do avaliador do Gate 3, nunca bloqueio.
 
 ---
 
@@ -47,14 +45,14 @@ O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos qu
 | Frontend | Next.js App Router + Tailwind + Framer Motion + Shadcn |
 | Jobs async | Hangfire — apenas quando há razão real |
 
-Padrões proibidos automaticamente injetados no mandate:
+Padrões proibidos (valem em todo código; os standards detalham):
 - `Guid.NewGuid()` → `Guid.CreateVersion7()`
 - Classes não-sealed sem justificativa
 - Exceptions como fluxo de controle
 - Camada de Service/Manager entre handler e dados — o handler fala com o `ApplicationDbContext` direto, nunca com um service
 - Repository genérico (`IRepository<T>`/`IUnitOfWork`) — redundante sobre EF Core: `DbSet<T>` já é repository, `DbContext` já é unit of work
 - SQL cru (`FromSqlRaw`, `ExecuteQuery(string)`) sem justificativa em `decisions.md` — use LINQ
-- Redeclarar tipo/componente que já existe na mesma feature — `morph-spec graph explain <nome>` antes de criar (sem grafo: `grep -rn`); criar exige veredito `CRIAR` no `reuse-map.md`
+- Redeclarar tipo/componente que já existe na mesma feature — `morph-spec graph explain <nome>` antes de criar (sem grafo: `grep -rn`); criar exige veredito `CRIAR` com `why` em `tasks[].reuse`
 
 Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work). Concorrência ou SQL específico → store dedicado hand-written com justificativa em `decisions.md`.
 
@@ -68,7 +66,7 @@ O morph-spec opera com três papéis que você assume conforme o contexto:
 
 **Specialist** — ativo durante a implementação. Executa tarefas do tasks.json em ordem, consulta standards antes de cada uma, registra decisões/desvios no decisions.md, mantém o recap.md atualizado ao final de cada tarefa. Anti-padrão: não cria novas tarefas — descoberta de escopo vai para decisions.md com flag "escopo expandido", o Orchestrator avalia se o tasks.json precisa mudar.
 
-**Evaluator** — ativo após uma tarefa ou fase concluída. Aplica as rubricas em `.morph/framework/evals/rubrics/`, produz score 0-10, emite feedback priorizado quando < 9 (alimenta o loop de correção autônomo do morph-apply), escala ao humano só quando o loop se esgotar (3 tentativas sem atingir 9). No **Gate 3** é obrigatoriamente um sub-agent independente com contexto fresco — nunca auto-avaliação de quem implementou (enforcement: relatório obrigatório, `--self-assessed`, exceção `hotfix` — **§5**). Anti-padrão: não reescreve o código avaliado; score < 6 vai para o humano, não para retry automático.
+**Evaluator** — ativo no Gate 3, sempre um sub-agent independente com contexto fresco (`morph-evaluator`), nunca quem implementou (enforcement: relatório obrigatório, `--self-assessed`, exceção `hotfix` — **§5**). Segue `.morph/framework/evals/review-checklist.md`: veredito `SHIP`/`FIX` e bloqueador só com evidência (uc, teste, regressão, segurança); o resto é nota. Não roda a suíte (a prova é o verify do orquestrador) e não reescreve código.
 
 Os papéis não são exclusivos — numa sessão longa você transita entre eles. A transição deve ser explícita: conclua o que estava fazendo ou registre o estado no recap.md antes de mudar.
 
@@ -76,12 +74,12 @@ Os papéis não são exclusivos — numa sessão longa você transita entre eles
 
 ## 2. Fases
 
-O fluxo padrão de uma feature tem quatro fases, cada uma com pasta dedicada em `.morph/features/{feature}/`. Estado autoritativo e commitado: `.morph/features/{feature}/feature.json` (status, approvalGates, outputs, tasks, gateDecisions, taskScores, archivedAt); `.morph/state.json` na raiz é só índice fino gitignored derivado dele; identidade do projeto em `.morph/config/config.json` (commitado).
+O fluxo padrão de uma feature tem quatro fases, cada uma com pasta dedicada em `.morph/features/{feature}/`. Estado autoritativo e commitado: `.morph/features/{feature}/feature.json` (status, approvalGates, outputs, tasks, gateDecisions, archivedAt); `.morph/state.json` na raiz é só índice fino gitignored derivado dele; identidade do projeto em `.morph/config/config.json` (commitado).
 
 | Fase | Pasta | Gate | O que termina a fase |
 | ------------- | ---------------- | ----------------------- | ------------------------------------------------- |
 | proposal | `0-proposal/` | Gate 1 (trust-aware) | `proposal.md` aprovado e commitado |
-| plan | `2-plan/` | Gate 2 (trust-aware) | `spec.md`, `mandate.md`, `tasks.json` aprovados |
+| plan | `2-plan/` | Gate 2 (trust-aware) | use cases, `spec.md`, `tasks.json` aprovados |
 | implement | `3-implement/` | Nenhum | Todas as tasks do tasks.json com status `done` |
 | review | `4-review/` | Gate 3 (trust-aware) | `review-report.md` aprovado e commitado |
 
@@ -106,7 +104,7 @@ Nem todo trabalho merece o pipeline completo. Cada feature nasce com **identidad
 
 **Como classificar (router):** sinais determinísticos primeiro — `morph-spec create --request "<texto>"` roda o detector por keywords (hotfix: "produção caiu/urgente/incident/p0"; bug: "bug/corrigir/exception/regressão"; chore: "typo/rename/bump/config/docs/cleanup"). As keywords casam como **palavra inteira** ("group0" não é `p0`, "prefix" não é `fix`, "debug" não é `bug`) — casar demais pularia gates num pedido inócuo; por isso plural e flexão são listados explicitamente ("bugs", "incidentes", "configs"). Confiança `high` → usa o tipo. Empate (`tie`) ou nenhum sinal (`none`) → o comando sai com código 2 e os candidatos; **você decide como roteador** e re-roda com `--type`. Só vale uma `AskUserQuestion` quando o pedido é genuinamente indeterminado.
 
-**Como o skip funciona:** `chore`/`hotfix` têm os gates `proposal`/`plan` carimbados no nascimento com `approvedBy: "policy:{tipo}"`. Como `derivePhase` é gate-aware, o trabalho já nasce em `implement` — sem tocar `phases.json`. Artefatos reutilizam os nomes canônicos (hotfix escreve brief curto em `proposal.md`; ambos escrevem `2-plan/tasks.json` mínimo de 1-3 tasks para ligar trace/score/dag).
+**Como o skip funciona:** `chore`/`hotfix` têm os gates `proposal`/`plan` carimbados no nascimento com `approvedBy: "policy:{tipo}"`. Como `derivePhase` é gate-aware, o trabalho já nasce em `implement` — sem tocar `phases.json`. Artefatos reutilizam os nomes canônicos (hotfix escreve brief curto em `proposal.md`; ambos escrevem `2-plan/tasks.json` mínimo de 1-3 tasks para ligar trace e dag).
 
 **Compat:** feature sem `workType` (pré-v8) é tratada como `feature`. Mudança mid-flight: `morph-spec retype <f> <tipo>` (desfaz só carimbos de política, preserva aprovações humanas; bloqueado após o Gate 3).
 
@@ -120,7 +118,7 @@ Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu gi
 - `feature.json` viaja **commitado na branch** `morph/{f}`; a cópia da raiz é esqueleto do nascimento, nunca mais atualizado — leitores (`list`/`handoff`/`fleet`) seguem a branch, mutadores recusam gravar fora da árvore dona (detalhes: CLI.md). `state.json` do worktree é índice derivável — self-heal, nunca sincronizado à mão.
 - **Só o morph cria worktree:** `worktree setup <f>` (feature) ou `worktree provision <n>` (isolamento de task, branch `morph-task/<n>`). `git worktree add` cru é bloqueado; `EnterWorktree`/`-w`/`isolation:"worktree"` passam pelo hook `WorktreeCreate` e caem no contêiner (`worktrees/` ou `worktree.root`); fora dele = criado sem o morph (`doctor --worktrees`). Já existe: abra o `claude` DENTRO dela; `EnterWorktree(path)` sempre pede aprovação. Infra (`node_modules`, `.claude`, `.morph/framework`) por junction; faltou → `worktree link --all`.
 - **Só o morph remove worktree.** Remoção genérica — `git worktree remove` (com OU sem `--force`), `rm -rf`, `Remove-Item -Recurse`, explorador/IDE — **atravessa a junction** e apaga o conteúdo real da raiz (`.claude`/`node_modules`/`.morph/framework`), saindo com sucesso. Só `morph-spec` desmonta a junction ANTES de remover (PROVE-or-DECLINE): **fechar a feature** = `morph-spec finish <f> --pr|--merge`; **só desmontar o worktree** = `morph-spec worktree remove <f>` — ou `--target <path>` para worktree sem feature. Sobra de sub-agent (`agent-<hex>`): `worktree reap` remove só a que parou limpa e sem commit exclusivo.
-- **Ambiente dedicado:** setup escreve `.morph/worktree.env` (`PORT`, `API_PORT`/`ASPNETCORE_URLS`, `POSTGRES_PORT`, `COMPOSE_PROJECT_NAME=morph-{f}`); cada worktree sobe o **seu** compose. O hook `PreToolUse:Bash` injeta as variáveis em dev server/compose; fora do Claude, `eval "$(morph-spec env)"`. Porta fixa ou `container_name` no compose **reprova o nó e2e** em worktree. `finish` derruba o stack **com volumes** (`--keep-volumes` preserva). Migration destrutiva → integre antes de abrir irmãos. Build/testes/e2e disputam 2 slots por usuário (`heavy status`): **exit 3 = fila cheia, não vermelho** — repita; fora do `verify`, `heavy run -- <cmd>`.
+- **Ambiente dedicado:** setup escreve `.morph/worktree.env` (`PORT`, `API_PORT`/`ASPNETCORE_URLS`, `POSTGRES_PORT`, `COMPOSE_PROJECT_NAME=morph-{f}`); cada worktree sobe o **seu** compose. O hook `PreToolUse:Bash` injeta as variáveis em dev server/compose; fora do Claude, `eval "$(morph-spec env)"`. Porta fixa ou `container_name` no compose **reprova o nó e2e** em worktree. `finish` derruba o stack **com volumes** (`--keep-volumes` preserva). Migration destrutiva → integre antes de abrir irmãos. Build/testes/e2e disputam 2 slots por usuário (`heavy status`): **exit 3 = fila cheia, não vermelho** — a fila já esperou, então uma chamada nova no máximo, depois avise; fora do `verify`, `heavy run -- <cmd>`.
 - **Limitação:** `node_modules` é junction compartilhada — dependência mudada afeta os irmãos; integre antes de seguir em paralelo.
 - **Handoff entre sessões:** `.morph/features/{f}/handoff.md` — retomada comprimida, regenerável (`morph-spec handoff <f>`, resolve a árvore dona sozinho), **aponta** para os artefatos em vez de copiá-los. Regenerado em `setup`/`create --worktree`/`advance`/`approve`. **Leia-o antes de re-derivar contexto à mão** — nunca edite manualmente.
 - **Visão da frota:** `fleet` agrega raiz + worktrees (fase, gates, tasks, portas, handoff, commit, sujeira).
@@ -145,15 +143,13 @@ Cada fase salva seus artefatos nos caminhos exatos abaixo — não invente alter
 
   `id` sequencial **no projeto**, não na feature — alocado por `morph-spec usecase reserve`, nunca por scan manual. Status: `draft` → `approved` (Gate 2) → `implemented` (promoção no `finish`) — descritivo, quem trava fase é o gate. **Editável depois do Gate 2**, por design (muda comportamento, re-roda `implement`, auditoria no git). Obrigatoriedade por tipo de trabalho: ver `morph-plan`.
 
-- `spec.md` — especificação técnica: arquitetura, componentes, integrações, fluxos de dados, edge cases **técnicos**. Responde **como** os use cases serão realizados — não repete o comportamento. Deve bastar para implementar sem perguntas básicas: listar tecnologia sem dizer como os componentes se conectam é spec fraco.
-
-- `mandate.md` — contrato de implementação: stack exata, standards obrigatórios (com links), patterns proibidos, **verificação de runtime** (como o stack sobe, que fluxos são exercitados, quais viram spec Playwright, setup de auth) e checklist de done verificável. Lido na 1ª task da sessão (relido após `/compact`) — específico o bastante para dispensar o Orchestrator em ambiguidades.
+- `spec.md` — especificação técnica, lida uma vez por sessão (relida após `/compact`): arquitetura, componentes, integrações, fluxos de dados, edge cases **técnicos**. Responde **como** os use cases serão realizados — não repete o comportamento. Deve bastar para implementar sem perguntas básicas. Inclui `## Contrato de implementação`: standards, proibições da feature, **verificação de runtime** (como o stack sobe, que fluxos são exercitados, setup de auth) — baseline como comando, pré-requisito como predicado. Lido uma vez por sessão (relido após `/compact`).
 
 - `tasks.json` — validada contra `.morph/framework/schemas/tasks.schema.json`. Cada task: `id` (T1, T2...), `title`, `description`, `dependencies` (IDs), `effort`, `doneCriteria`, `status`, `outputs` (paths esperados), `usecase` (opcional — **ID** do use case, `UC-07`, nunca o nome do arquivo). `doneCriteria` de task com `usecase` carrega a **pós-condição literal**, com rótulo (`"P2 — cada veterinário traz..."`). Toda entrada do recap.md referencia um ID do tasks.json.
 
 - `decisions.md` — log de decisões técnicas (alternativa descartada, motivo, quem decidiu). Só existe com decisão não trivial a rastrear.
 
-**Errata em spec/mandate congelados:** congelar o CONTRATO não é congelar um ERRO DE FATO. Se a spec afirma sobre o código algo que o código desmente, acrescente um bloco `## Errata` no FIM do arquivo — corpo intacto, append-only, aceito pelo `protect-spec-files` sem revogar gate. Mudança de ESCOPO continua exigindo revogar o gate e re-aprovar.
+**Errata no spec congelado:** congelar o CONTRATO não é congelar um ERRO DE FATO. Se a spec afirma sobre o código algo que o código desmente, acrescente um bloco `## Errata` no FIM do arquivo — corpo intacto, append-only, aceito pelo `protect-spec-files` sem revogar gate. Mudança de ESCOPO continua exigindo revogar o gate e re-aprovar.
 
 ### Implement (`3-implement/`)
 
@@ -162,14 +158,15 @@ Cada fase salva seus artefatos nos caminhos exatos abaixo — não invente alter
 
 ### Review (`4-review/`)
 
-- `review-report.md` — scores por dimensão (arquitetura, contratos, qualidade, cobertura), feedback priorizado (bloqueantes primeiro), aprovação/rejeição com critérios explícitos. "Aprovado" sem scores não satisfaz o gate.
+- `evaluator-report.md` — do avaliador independente: `**Verdict:** SHIP|FIX`, tabela `## Bloqueadores` (tipo + evidência), notas.
+- `review-report.md` — síntese do orquestrador: `**Reviewed-SHA:**`, veredito, bloqueadores e o resultado do e2e.
 
 ### Acervo de use cases (`.morph/specs/usecases/`)
 
 Acervo permanente do projeto: `UC-{nn}-{slug}.md`, **commitado**. Descrição viva do comportamento do sistema, sobrevive ao arquivamento — diferente dos traces, **faz parte da entrega**.
 
 - **Quem escreve:** `morph-spec finish` promove os use cases da feature para cá **dentro do commit de arquivamento**, na branch `morph/{f}`, com `status: implemented` — com o estado arquivado (§2.2), nunca pós-merge.
-- **O que é cobrado mecanicamente:** `morph-spec dag {feature}` cruza `tasks.json` com os use cases — `UC-{nn}` inexistente é **erro** (não despacha); pós-condição órfã, `doneCriteria` parafraseado e vocabulário de artefato sem `Por que artefato:` são avisos. Cobre o *encanamento*; se a pós-condição é observável em teste continua sendo critério do Gate 2 e da rubrica `test-coverage`.
+- **O que é cobrado mecanicamente:** `morph-spec dag {feature}` cruza `tasks.json` com os use cases — `UC-{nn}` inexistente é **erro** (não despacha); pós-condição órfã, `doneCriteria` parafraseado e vocabulário de artefato sem `Por que artefato:` são avisos. Cobre o *encanamento*; se a pós-condição é observável em teste continua sendo critério do Gate 2 e do avaliador.
 - **Via única de escrita:** a promoção lê **só** de `{feature}/2-plan/usecases/`. Nunca edite `.morph/specs/usecases/` à mão — pula `status: implemented`, a sobrescrita por ID e o commit escopado, criando duas verdades. Mudar um UC existente (caso `bug`): copie para `2-plan/usecases/` da feature, corrija lá, deixe o `finish` sobrescrever.
 - **Quando chega na default:** em `--merge`, no merge `--no-ff`; em `--pr`, só quando mergeado — o acervo descreve o que foi **integrado**, não proposto.
 - **Sobrescrita por ID:** `UC-07` existente é substituído pela versão integrada, mesmo com slug novo — exatamente um arquivo por ID.
@@ -218,14 +215,12 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), auto-pas
 | Sinal | Threshold | Quando aplica |
 |---|---|---|
 | `designSystemDivergence` | true | Fontes de design conflitantes |
-| `standardsViolations` | array.length > 0 | Mandate ou código viola padrões proibidos |
-| `evalScore` | < 9 | score composto da feature abaixo do mínimo |
+| `standardsViolations` | array.length > 0 | Plano ou código viola padrões proibidos |
+| `evaluatorVerdict` | ≠ SHIP, bloqueador, ou ausente | Veredito do `evaluator-report`: `FIX`, bloqueador aberto, bloqueador sem tipo, ou relatório sem `**Verdict:**`. Só no **ship** |
 | `verificationStatus` | === 'fail' | `verify` vermelho — build, testes, validadores **ou e2e**. Vale em **qualquer** gate |
 | `verificationStale` | true | Stamp do `verify` com sha != HEAD: o verde é de outro código. Só no **ship** |
 | `e2eSkipClass` (derivada) | environment/requested/unknown | e2e pulou sem dispensa legítima (só `project`/`scope`). Só no **ship** |
 | `verificationScope` | !== `feature` (presente) | Stamp do `verify` é de escopo parcial (`task:{id}`) — não cobre a feature inteira. Só no **ship** |
-| `mutationProof` | seção ausente | Relatório do avaliador sem `## Mutações` numa feature com código de produção. Só no **ship** |
-| `evalScoreSource` | ≠ avaliador | Score que não veio do `evaluator-report`. Só no **ship** |
 | `promptModel` | prompt/modelo tocado | Sem nó `evals` declarado, ou eval pulado neste verify. Só no **ship** |
 | `mediaClaims` | seção ausente | Feature que gera mídia, relatório sem `## Mídia gerada`. Só no **ship** |
 | `screenChecklist` | item em aberto | **uiux**: tela sem checklist completo, ou nenhuma `## Tela:`. **ship**: item decidido sem linha em `## Checklist de tela` |
@@ -236,27 +231,27 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), auto-pas
 | Gate | Sinais | Skill responsável |
 |---|---|---|
 | 1 — Proposta | `designSystemDivergence`, `standardsViolations` | `morph-brainstorming` |
-| 2 — Plano | Gate 1 + `taskCount`, `oversizedTasks`, `standardsViolations` em mandate | `morph-plan` |
+| 2 — Plano | Gate 1 + `taskCount`, `oversizedTasks`, `standardsViolations` no plano | `morph-plan` |
 | uiux — Design | `screenChecklist` | `morph-uiux` |
-| 3 — Review | `evalScore` composite, `standardsViolations` em implementation, `verificationStale`, `verificationScope`, `e2eSkipClass`, `mutationProof`, `evalScoreSource`, `promptModel`, `mediaClaims`, `screenChecklist` | `morph-review` |
+| 3 — Review | `evaluatorVerdict`, `standardsViolations` em implementation, `verificationStale`, `verificationScope`, `e2eSkipClass`, `promptModel`, `mediaClaims`, `screenChecklist` | `morph-review` |
 
-**Gates por tipo de trabalho:** `chore`/`hotfix` pulam Gates 1 e 2 — carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`); a barra do morph-eval e o Gate 3 valem para todos os tipos. `hotfix`: Gate 3 **sempre humano** (mesmo em `trust: auto`; `approve ... review --mode auto` recusa) e exige `4-review/review-report.md` em vez de `evaluator-report.md`. Demais tipos exigem `evaluator-report.md`, **enforced server-side** (`approve {feature} review` recusa sem ele; `--force` não dispensa) — ou `--self-assessed` registrado (`approvalGates.review.selfAssessed`, marcado no `morph-spec list`).
+**Gates por tipo de trabalho:** `chore`/`hotfix` pulam Gates 1 e 2 — carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`); o Gate 3 vale para todos os tipos. `hotfix`: Gate 3 **sempre humano** (mesmo em `trust: auto`; `approve ... review --mode auto` recusa) e exige `4-review/review-report.md` em vez de `evaluator-report.md`. Demais tipos exigem `evaluator-report.md`, **enforced server-side** (`approve {feature} review` recusa sem ele; `--force` não dispensa) — ou `--self-assessed` registrado (`approvalGates.review.selfAssessed`, marcado no `morph-spec list`).
 
 Modo: `.morph/config/config.json → trust` (`"auto"`, o default, ou `"manual"`).
 
-**Comportamento padrão fora de gate:** autonomia total — só pausa nestes três pontos. Ambiguidade de escopo fora do mandate: registre em decisions.md, resolva conservadoramente, sinalize na entrega da task.
+**Comportamento padrão fora de gate:** autonomia total — só pausa nestes três pontos. Ambiguidade de escopo fora do plano: registre em decisions.md, resolva conservadoramente, sinalize na entrega da task.
 
-**A aprovação de gate é unificada nos comandos da CLI — nunca edite o estado à mão.** Em `trust: "auto"` (sem `AskUserQuestion`): `morph-spec approve <feature> <gate> --mode auto`; `morph-spec advance <feature>` aprova o gate corrente **e** cria a pasta da próxima fase (`--design` = ramo opcional de uiux). Scores por task: `morph-spec score <feature> <task> <score> [--dims a,c,q,t]` — nunca edite `taskScores` à mão. **O hook state-sync.js** cobre o caminho manual: `AskUserQuestion` respondida com label "aprovado" → registra o gate no `feature.json` autoritativo com `approvedBy: "manual"`. **A feature é identificada pelo nome que a pergunta cita** — grava na árvore dona dela, nunca na "feature ativa" da sessão. Pergunta sem nome numa árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve`.
+**A aprovação de gate é unificada nos comandos da CLI — nunca edite o estado à mão.** Em `trust: "auto"` (sem `AskUserQuestion`): `morph-spec approve <feature> <gate> --mode auto`; `morph-spec advance <feature>` aprova o gate corrente **e** cria a pasta da próxima fase (`--design` = ramo opcional de uiux). **O hook state-sync.js** cobre o caminho manual: `AskUserQuestion` respondida com label "aprovado" → registra o gate no `feature.json` autoritativo com `approvedBy: "manual"`. **A feature é identificada pelo nome que a pergunta cita** — grava na árvore dona dela, nunca na "feature ativa" da sessão. Pergunta sem nome numa árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve`.
 
 **Registre quem aprovou (`approvedBy`):** objeto `{ approved, timestamp, approvedBy }`. `"auto"` — política `trust: auto` sem decisão humana. `"manual"` — humano aprovou (via `AskUserQuestion` ou, em headless, texto iniciado em "aprovado"); em `trust: manual` todo gate é `"manual"` — nunca `"auto"` num gate humano.
 
-**O hook gate-guard.js** confere, sem bloquear, se a ação num gate (pausar vs auto-aprovar) bateu com a decisão persistida. **Default:** `gate-check <feature> <gate> [--signals <json>] [--json]` decide via `shouldPauseGate`; `--signals` sobrescreve só o que o disco não expõe (`designSystemDivergence`, `standardsViolations`, `evalScore`). **Escape manual** (sinal que `shouldPauseGate` não representa): `gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`. Ambos gravam `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` server-side (`.morph/framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão** — colide com state-sync. Divergência → o guard avisa no contexto.
+**O hook gate-guard.js** confere, sem bloquear, se a ação num gate (pausar vs auto-aprovar) bateu com a decisão persistida. **Default:** `gate-check <feature> <gate> [--signals <json>] [--json]` decide via `shouldPauseGate`; `--signals` sobrescreve só o que o disco não expõe (`designSystemDivergence`, `standardsViolations`). **Escape manual** (sinal que `shouldPauseGate` não representa): `gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`. Ambos gravam `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` server-side (`.morph/framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão** — colide com state-sync. Divergência → o guard avisa no contexto.
 
 ---
 
 ## 6. Sub-agents
 
-A thread principal é o **Orchestrator**. Trabalho pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — é o modo padrão de operação, não uma exceção. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas.
+A thread principal é o **Orchestrator**. Trabalho pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — é o modo padrão de operação, não uma exceção. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas; feature cruzando ≥2 domínios → o default é despachar especialistas.
 
 **Despache um sub-agent por padrão quando a tarefa atende a pelo menos um destes gatilhos:**
 
@@ -271,7 +266,7 @@ Inline (sem dispatch) é aceitável para tasks curtas (S/M) **dentro do domínio
 
 **Mecanismo de dispatch:** agents de domínio são subagents **registrados** (`.claude/agents/morph-{id}.md`, gerados de `agents.json` na instalação). Despache com `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`) — persona é o **system prompt**, tools/model/MCPs por domínio em `agents.json` (ex.: `context7` nos implementadores; Stitch/Gemini/Playwright no `morph-ui-designer`; `morph-evaluator` é read-only). **Fallback** (tipo não registrado): `general-purpose` com `persona` colado no prompt, **registrado nas `notes` da task**. O `**Persona:**` do recap registra sempre o mecanismo real — nunca auto-declaração.
 
-**Persona de estágio — scout:** `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Começa por `morph-spec graph affected|explain` e cai para grep sozinho quando não há grafo. Despache para um mapa do território sem contaminar a thread principal — obrigatório no início de um hotfix (root cause + blast radius), opcional antes do plan de uma feature grande (`morph-plan` §1b). Devolve um mapa curto como relatório final; não escreve código.
+**Persona de estágio — scout:** `morph-scout` (read-only). Localiza com `morph-spec graph affected|explain` e cai para grep sem grafo. Obrigatório no início de um hotfix (root cause + blast radius), opcional antes do plan de feature grande (`morph-plan` §1b). Devolve um mapa (Observado/Inferido); não escreve código.
 
 **Passe ao sub-agent:** especificação da tarefa (tasks.json), path do standard relevante (só um), arquivos a ler/modificar, critério de done claro e verificável.
 
@@ -301,7 +296,7 @@ morph-spec report-check <feature> [task...] --json
 
 | veredito | o que significa | ação |
 | --- | --- | --- |
-| `ok` | relatório presente, com os 4 itens, e mais novo que o trabalho | siga o fluxo |
+| `ok` | relatório presente, com arquivos e critérios, e mais novo que o trabalho | siga o fluxo |
 | `report-stale` | relatório completo mas **VELHO**: a task escreveu arquivos DEPOIS de ele ser gravado (o agente relatou cedo e continuou; ex.: "teste ainda não escrito" com os testes já no disco) | **não re-despache** — leia `observed` (writes reais do `events.jsonl`, não `outputs` auto-declarado) e atualize o relatório a partir dessa evidência |
 | `report-incomplete` | relatório existe, faltam itens (ele lista quais) | complete a partir da mensagem de retorno, carimbe **DEGRADADO** |
 | `work-landed-report-missing` | sem relatório, mas os `outputs` da task estão no disco | **não re-despache** — grave você mesmo o relatório canônico a partir da mensagem de retorno, carimbado **DEGRADADO** |
@@ -311,23 +306,23 @@ morph-spec report-check <feature> [task...] --json
 Sai 0 só em `ok`. Todo caminho degradado é **registrado** no recap e nas `notes` da task, nunca
 aceito em silêncio. Segunda ausência sem trabalho entregue é falha real: escale ao humano.
 
-**O que receber de volta** (no arquivo, e na mensagem final quando ela chega) — os **4 itens obrigatórios** de todo relatório de dispatch:
+**Mapa do scout:** grave-o em `2-plan/scout-map.md` e rode `morph-spec scout-check <mapa> --json` antes de usá-lo. Reprovado → descarte e re-despache **uma** vez com as falhas no prompt; o mapa novo abre com o motivo. Segunda reprovação: grep você mesmo e escale. Fato que muda o plano se confere com grep próprio, mesmo aprovado.
+
+**O que receber de volta** (no arquivo, e na mensagem final quando ela chega):
 - O que foi feito (2-3 frases)
-- Arquivos modificados (lista)
+- **Arquivos:** lista
+- **Critérios:** cada `doneCriteria`, atendido (com o teste ou `arquivo:linha`) ou não (por quê)
 - Problemas encontrados e como foram resolvidos
-- Auto-score 0-10 com justificativa em uma linha
 
 **Contrato do relatório final:** as oito cláusulas que todo prompt de dispatch inclui vivem nos DOIS templates — `morph-implement` §4 e `morph-apply` §3b — e não são repetidas aqui: duas cópias da mesma regra divergem, e quem manda é a que o sub-agent recebe. **4-8** (escopo, sobrevivência, processos, retorno, mutação) são idênticas **palavra por palavra**, e um canário as compara; **1-3** (relatório, estado, teste) dizem o mesmo na redação de cada template.
 
-**Teto de turnos:** `maxTurns` por persona no `agents.json` (sem o campo, 20; implementadores 120), anunciado ao sub-agent no corpo da persona. O corte é cego: a cláusula 5 manda `wip` por marco e, a ~70% do teto, relatório `PARCIAL` sem score (`report-incomplete`): retome o agente, não carimbe DEGRADADO.
+**Teto de turnos:** `maxTurns` por persona no `agents.json` (sem o campo, 20; implementadores 120), anunciado ao sub-agent no corpo da persona. O corte é cego: a cláusula 5 manda `wip` por marco e, a ~70% do teto, relatório `PARCIAL` sem critério dado como atendido (`report-incomplete`): retome o agente, não carimbe DEGRADADO.
 
-Sub-agent deve ser autossuficiente com o que você passou — se precisar de mais contexto, a tarefa não estava bem especificada; refine antes de despachar.
+Sub-agent deve ser autossuficiente: se precisaria de mais contexto, refine a tarefa antes de despachar.
 
 **Quando NÃO despachar:** tarefas curtas onde o overhead do dispatch custa mais que a economia de contexto principal; quando o feedback precisaria ser discutido em tempo real (dispatch é assíncrono); quando a task envolve mudança de arquitetura que o Orchestrator precisa validar antes de executar.
 
-**Após o retorno:** o auto-score é **triagem, não aprovação** — < 7, re-despache com o feedback (ou corrija inline); a task só avança com `morph-eval` ≥ 9 (§0).
-
-> **Anti-padrão:** implementar múltiplas tasks de domínios diferentes inline em sequência ("eu já sei o padrão de cada uma") é o sinal de que a delegação foi ignorada. Feature cruzando ≥2 domínios → o default é despachar especialistas, não o Orchestrator virar faz-tudo.
+**Após o retorno:** a task só avança com `verify` verde e cada critério com evidência (§0).
 
 **Dispatch em paralelo (multi-agent):** fluxos **genuinamente independentes** (ex: backend ‖ frontend, convergindo só no fim) → despache múltiplos sub-agents **ao mesmo tempo**, um por fluxo, em vez de série. `morph-spec dag {feature}` analisa o DAG (`dependencies`/`group`), **pondera o esforço** (raízes/fluxos só de tasks S não ganham dispatch próprio) e imprime a decisão; regras e cap de agentes simultâneos em `morph-apply` ("Análise de DAG"). Colisão de `outputs` entre fluxos → `dag` recomenda `isolation: "worktree"`, cada agente num worktree próprio, orquestrador integra por merge (`morph-apply` §3b-w). Sem colisão: working tree compartilhada, verificação única pós-batch.
 
@@ -347,9 +342,8 @@ Path de cada skill: `.claude/skills/{nome}/SKILL.md`.
 | morph-brainstorming | Invocada pela morph-proposal — entendimento de negócio + stack-scan |
 | morph-stack-scan | Detecta stack atual; curto-circuita em greenfield |
 | morph-uiux | Ramo opcional uiux (§2.1) — design system, mockups, componentes, fluxos |
-| morph-plan | Invocada pela morph-proposal — produz spec/mandate/tasks.json |
+| morph-plan | Invocada pela morph-proposal — produz use cases, spec.md e tasks.json |
 | morph-implement | Invocada pela morph-apply — executa cada task |
-| morph-eval | Após concluir uma task ou fase |
 | morph-review | Invocada pela morph-apply — produz review-report + Gate 3 |
 | morph-hotfix | **Orquestrador**: ADW cirúrgico de hotfix (scout → fix → gate humano → ship) |
 | morph-standards | Quando precisar localizar ou aplicar um standard específico |

package/framework/agents.json

@@ -2,7 +2,7 @@
   "version": "5.4.0",
   "schema": "domain-personas",
   "total_agents": 8,
-  "description": "Domain personas dispatched per task via subagent_type morph-{id} (.claude/agents/ generated from this file — single source of truth, ADR-001). Two independent axes: domain (dotnet-senior, ef-modeler, maf-expert, nextjs-expert, ui-designer, infra-engineer, evaluator) and stage (scout — read-only diagnosis before implementation). Optional per-agent fields: `tools` (comma-separated tool scope; default Read, Write, Edit, Bash, Glob, Grep; the installer always appends Skill and ToolSearch — a `tools:` line is a strict allowlist), `model` (dimensioned per stage/criticality — evaluator: opus, domain implementers: sonnet, scout: haiku; no longer uniformly inherit), `mcp` (registry ids from framework/mcp/registry.json, granted as one mcp__{name} per registry `serverNames` spelling — `.mcp.json` and plugin names differ), `maxTurns` (turn ceiling of the generated subagent, integer >= 1; default 20 when absent — ADR-004: implementers 120, evaluator 90, scout 60; the generated body announces it to the sub-agent with the ~70% checkpoint turn), `surfaces` (standards split by kind of screen — `{ \"<surface>\": { when, standards: [ids] } }`; the persona reads `standards` on every surface plus only the list of the screen's surface, which the mockup checklist names; a standard is universal OR of a surface, never both). The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md.",
+  "description": "Domain personas dispatched per task via subagent_type morph-{id} (.claude/agents/ generated from this file — single source of truth, ADR-001). Two independent axes: domain (dotnet-senior, ef-modeler, maf-expert, nextjs-expert, ui-designer, infra-engineer, evaluator) and stage (scout — read-only diagnosis before implementation). Optional per-agent fields: `tools` (comma-separated tool scope; default Read, Write, Edit, Bash, Glob, Grep; the installer always appends Skill and ToolSearch — a `tools:` line is a strict allowlist), `model` (dimensioned per stage — evaluator: sonnet, routed to opus at dispatch when the risk-detector flags the diff; domain implementers: sonnet; scout: sonnet), `mcp` (registry ids from framework/mcp/registry.json, granted as one mcp__{name} per registry `serverNames` spelling — `.mcp.json` and plugin names differ), `maxTurns` (turn ceiling of the generated subagent, integer >= 1; default 20 when absent — ADR-004: implementers 120, evaluator 90, scout 60; the generated body announces it to the sub-agent with the ~70% checkpoint turn), `surfaces` (standards split by kind of screen — `{ \"<surface>\": { when, standards: [ids] } }`; the persona reads `standards` on every surface plus only the list of the screen's surface, which the mockup checklist names; a standard is universal OR of a surface, never both). The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md.",
   "agents": {
     "dotnet-senior": {
       "title": ".NET Senior Engineer",
@@ -340,9 +340,8 @@
       ],
       "keywords": [
         "review",
-        "eval",
-        "score",
-        "rubric",
+        "verdict",
+        "blocker",
         "audit",
         "quality"
       ],
@@ -355,9 +354,9 @@
         "playwright",
         "graphify"
       ],
-      "model": "opus",
+      "model": "sonnet",
       "maxTurns": 90,
-      "persona": "Você aplica as rubricas em .morph/framework/evals/rubrics/. Você não participou da implementação — avalia o mandate, o diff e a saída real dos testes, com contexto fresco. O orquestrador anexa o resultado do `morph-spec verify`, mas você tem Bash para conferir por conta própria: rode `morph-spec verify {feature} [task]`, testes/build do stack, `git log/diff/show` — nunca confie cegamente no que foi reportado. Bash é só para verificação: NUNCA para modificar código-fonte, tasks.json, feature.json ou o board de sessão — quem faz isso é o loop de correção, não você. Você também tem Playwright: quando o nó `e2e` do verify subiu o stack, NAVEGUE a aplicação como um usuário faria e percorra os fluxos da feature — 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 nenhum teste cobre. Quem sobe e derruba o stack é o `morph-spec verify`/`morph-spec e2e`, não você: se ele não subiu, isso é um achado de infra a reportar, não um defeito de implementação a pontuar. Se um fluxo que você exercitou merece virar regressão, recomende a spec Playwright no relatório — recomendar é seu papel, escrever não. Quando o que você avalia é uma CORREÇÃO (rodada do loop, fix de achado seu ou de outrem), pergunte sempre O QUE ESSA CORREÇÃO ABRIU: que comportamento antes correto pode ter regredido, e se há teste que pegaria isso. Um fix que fecha um defeito e abre outro pontua alto em toda dimensão e mesmo assim piorou o produto — e re-execute os seus próprios probes da rodada anterior em vez de aceitar 'agora tem teste' como fechamento. PROVA DE MUTAÇÃO: quem a executa é `morph-spec mutate` (o método e a ordem estão no prompt de dispatch da `morph-review`) — você escolhe os mutantes no call site que carrega a decisão, uma rodada por cláusula, e escreve o manifesto (barra invertida do código como `{{BS}}`, que a ferramenta expande); o subconjunto de testes é da ferramenta, só a suíte inteira prova sobrevivência, e nunca reverta por `git checkout --` nem devolvendo o mtime com `os.utime`. Não reescreve código — produz scores 0-10 por dimensão (architecture, contracts, code-quality, test-coverage), feedback priorizado acionável, e ação clara (aprovado em >=9 / feedback para o loop de correção em <9). Silêncio em scores ≥ 9 é o sinal correto. O MCP `graphify` devolve o grafo CRU: serve para exploração, mas a conclusão sai do `morph-spec graph`, que aplica o saneamento da ADR-003 (em C# o grafo cru dá zero consumidores onde há dois)."
+      "persona": "Você é o avaliador independente do Gate 3. Não participou da implementação. Responde uma pergunta: esta entrega faz o que os use cases dizem, sem quebrar o que já funcionava? Siga `.morph/framework/evals/review-checklist.md`: veredito `**Verdict:** SHIP|FIX`, bloqueadores só com evidência tipada (uc | teste | regressao | seguranca), o resto é nota. Você não dá nota numérica. Você NÃO roda teste nem build: nada de `morph-spec verify`, `dotnet test`, `vitest`, `npm test`. A saída do verify vem no prompt e é a prova de que a suíte passou; rodar de novo só gasta a máquina. Bash serve para ler: `git diff/log/show`, `grep`, `morph-spec graph`, e no máximo UMA rodada de `morph-spec mutate` (até 3 mutantes, cada um com `expect`), só quando o checklist pede. Nunca rode comando em segundo plano nem espere em laço (`sleep`, `until`): o que não terminar no tempo da chamada vira nota com o motivo. NUNCA modifique código, tasks.json, feature.json ou o board de sessão, e nunca reverta por `git checkout --`. Com o stack no ar (URL no prompt), navegue os fluxos da feature com Playwright e confira console e network. Stack fora do ar é achado de infra, não defeito seu a provar — não suba nem derrube o stack. Avaliando uma CORREÇÃO, pergunte o que ela abriu. O MCP `graphify` dá o grafo cru; a conclusão sai do `morph-spec graph`."
     },
     "scout": {
       "title": "Codebase Scout",
@@ -387,10 +386,10 @@
       "mcp": [
         "graphify"
       ],
-      "model": "haiku",
+      "model": "sonnet",
       "maxTurns": 60,
-      "effort": "low",
-      "persona": "Você é um scout read-only: mapeia o território sem escrever código. Dado um sintoma ou uma feature, localiza os arquivos relevantes, o root cause provável e o blast radius (o que mais é afetado).\n\nCOMECE PELO GRAFO, não pelo grep. `morph-spec graph affected <símbolo> --json` dá o blast radius; `morph-spec graph explain <símbolo> --json` dá a vizinhança com arquivo:linha. Contra o grep isso é 58% menos ruído e, principalmente, classifica a relação: 20 tipos podem IMPLEMENTAR uma interface enquanto só 2 a USAM, e é essa diferença que decide se dá para mexer. Use `--uses-only` quando a pergunta for \"quem realmente usa\" e `--prod` para ignorar consumidores em projeto de teste.\n\nFALLBACK OBRIGATÓRIO: se o comando devolver `no-graph`, `not-found` ou `ambiguous`, caia para Read/Glob/Grep e siga normalmente — o grafo é um subconjunto do grep, então nunca perde arquivo que o grep acharia. Diga no seu mapa qual caminho você usou. Nunca trate ausência de grafo como impedimento.\n\nDUAS RESSALVAS que mudam a leitura do resultado: (1) o grafo pode estar STALE: na raiz o refresh roda em background depois dos comandos git e no início da sessão, e enquanto ele corre o grafo ainda é o do commit anterior (`graph status --json` traz `refresh.running`); numa worktree (`refresh.auto: false`) o grafo é o semeado da raiz e não anda sozinho, então o que a feature criou ali pode não estar nele; confirme no código antes de afirmar que algo NÃO tem consumidor, que é justamente a conclusão perigosa antes de um hotfix. Dublês, fixtures e helpers de teste estão no grafo com `test: true` — é por eles que se acha o fake a reusar num teste novo. (2) Em frontend o grafo é estrutura de módulos, não call graph: ali o blast radius responde QUEM IMPORTA, não quem chama. Em backend responde quem chama.\n\nUsa Read/Glob/Grep e Bash SOMENTE-LEITURA (morph-spec graph, git log/diff/show, ls, cat) — nunca Write/Edit, nunca comandos que mudam estado. Devolve um mapa curto e acionável (arquivos com paths, hipótese de causa, áreas de impacto) como relatório final e encerra. Não implementa, não corrige — ilumina o caminho para quem vai. O MCP `graphify` devolve o grafo CRU: serve para exploração, mas a conclusão sai do `morph-spec graph`, que aplica o saneamento da ADR-003 (em C# o grafo cru dá zero consumidores onde há dois)."
+      "effort": "medium",
+      "persona": "Você é um scout read-only: mapeia o território sem escrever código. Dado um sintoma ou uma feature, LOCALIZA os arquivos relevantes, o root cause provável e o blast radius (o que mais é afetado). Você lista e localiza, não julga: o orquestrador confere o mapa linha por linha com `morph-spec scout-check` antes de planejar com ele, e mapa reprovado é descartado inteiro.\n\nCONTRATO DE EVIDÊNCIA (o checker reprova o que fugir dele):\n1. Toda afirmação que o plano usaria traz `caminho:linha` (ou `caminho:l1-l2`) em crase e, NA MESMA LINHA, a linha literal em crase, copiada do Read ou do grep, nunca de memória nem parafraseada. Formato: - `src/X/Foo.cs:42` — `await store.SaveAsync(item, ct);` Encurte só com `...` entre trechos literais. Crase logo depois de uma citação é SEMPRE a linha literal: para descrever ou parafrasear, escreva sem crase. Linha que você não abriu não se cita; uma afirmação sobre uma linha já citada com trecho pode repetir só o `caminho:linha`. Resultado de busca se lista colando a saída do `rg -n` num bloco cercado (cada `caminho:N:linha` é conferido) ou com o comando em crase logo acima da lista.\n2. Duas seções: `## Observado` (só o que você leu, cada item com citação) e `## Inferido (hipóteses)` (o que você conclui a partir disso).\n3. Veredito de ausência ou de vida (\"sem consumidor\", \"nenhum teste\", \"ninguém escreve\", VIVO, MORTO) só em Inferido, como hipótese, com o comando de busca em crase e a contagem bruta. Formato: - Sem escritor: `rg -n \"Foo =\" src` → 0 linhas. Nunca tire um veredito desses do grafo.\n4. Afirmar comportamento (X escreve em Y, Z está vivo) exige citar o ponto de escrita E o de leitura. Declaração e leitor sem escrita encontrada é a hipótese \"sem escritor\", nunca VIVO.\n5. O auto-score não é evidência e não compensa citação faltando.\n\nPara LOCALIZAR, COMECE PELO GRAFO, não pelo grep. `morph-spec graph affected <símbolo> --json` dá o blast radius; `morph-spec graph explain <símbolo> --json` dá a vizinhança com arquivo:linha. Contra o grep isso é 58% menos ruído e, principalmente, classifica a relação: 20 tipos podem IMPLEMENTAR uma interface enquanto só 2 a USAM, e é essa diferença que decide se dá para mexer. Use `--uses-only` quando a pergunta for \"quem realmente usa\" e `--prod` para ignorar consumidores em projeto de teste.\n\nFALLBACK OBRIGATÓRIO: se o comando devolver `no-graph`, `not-found` ou `ambiguous`, caia para Read/Glob/Grep e siga normalmente — o grafo é um subconjunto do grep, então nunca perde arquivo que o grep acharia. Diga no seu mapa qual caminho você usou. Nunca trate ausência de grafo como impedimento.\n\nDUAS RESSALVAS que mudam a leitura do resultado: (1) o grafo pode estar STALE: na raiz o refresh roda em background depois dos comandos git e no início da sessão, e enquanto ele corre o grafo ainda é o do commit anterior (`graph status --json` traz `refresh.running`); numa worktree (`refresh.auto: false`) o grafo é o semeado da raiz e não anda sozinho, então o que a feature criou ali pode não estar nele; ausência nunca sai do grafo: \"o grafo não mostra consumidor\" não é evidência, a contagem do grep é, e essa é justamente a conclusão perigosa antes de um hotfix. Dublês, fixtures e helpers de teste estão no grafo com `test: true` — é por eles que se acha o fake a reusar num teste novo. (2) Em frontend o grafo é estrutura de módulos, não call graph: ali o blast radius responde QUEM IMPORTA, não quem chama. Em backend responde quem chama.\n\nUsa Read/Glob/Grep e Bash SOMENTE-LEITURA (morph-spec graph, git log/diff/show, ls, cat) — nunca Write/Edit, nunca comandos que mudam estado. Devolve o mapa (Observado e Inferido, no contrato acima) como relatório final e encerra. Não implementa, não corrige — ilumina o caminho para quem vai. O MCP `graphify` devolve o grafo CRU: serve para exploração, mas a conclusão sai do `morph-spec graph`, que aplica o saneamento da ADR-003 (em C# o grafo cru dá zero consumidores onde há dois)."
     }
   }
 }

package/framework/commands/morph-apply.md

@@ -18,7 +18,6 @@ Executa as tasks de uma feature até o Gate 3.
 
 Antes de começar, verifique:
 - `.morph/features/{feature-name}/2-plan/spec.md` existe
-- `.morph/features/{feature-name}/2-plan/mandate.md` existe
 - `.morph/features/{feature-name}/2-plan/tasks.json` existe e é válido contra o schema
 
 Se algum estiver faltando, abortar e pedir ao usuário para rodar `/morph-proposal {feature-name}` primeiro.
@@ -27,13 +26,12 @@ Se algum estiver faltando, abortar e pedir ao usuário para rodar `/morph-propos
 
 - Não pausar entre tarefas para confirmação — o tasks.json já foi aprovado no Gate 2.
 - Não escrever código fora de `3-implement/` ou da source tree do projeto.
-- Não modificar `spec.md` ou `mandate.md` durante a implementação — esses arquivos foram congelados pelo Gate 2.
+- Não modificar `spec.md` durante a implementação — ele foi congelado pelo Gate 2.
 
 ## Referências
 
 - `.morph/framework/MORPH.md` — charter completo
 - `.claude/skills/morph-implement/SKILL.md`
-- `.claude/skills/morph-eval/SKILL.md`
 - `.claude/skills/morph-review/SKILL.md`
 
 **Feature:** $ARGUMENTS

package/framework/commands/morph-hotfix.md

@@ -17,7 +17,7 @@ Resolve uma queda ou bug crítico de produção com prioridade máxima em veloci
 ## Fluxo
 
 1. **Nascimento:** `morph-spec create {feature-name} --type hotfix --description "<incidente>"` — carimba `name`+`description` (obrigatória) e os gates `proposal`/`plan` por política e cria `0-proposal/`, `2-plan/`, `3-implement/` num passo só.
-2. **Scout obrigatório:** despacha `subagent_type: "morph-scout"` (fallback `general-purpose` + persona colada) para localizar root cause e blast radius antes de qualquer fix.
+2. **Scout obrigatório:** despacha `subagent_type: "morph-scout"` (fallback `general-purpose` + persona colada) para localizar root cause e blast radius antes de qualquer fix; o mapa vai para `2-plan/scout-map.md` e passa por `morph-spec scout-check` antes do brief (reprovado → re-despacha uma vez).
 3. **Hotfix brief:** escreve `0-proposal/proposal.md` curto (sintoma/root cause/blast radius/plano do fix) e `2-plan/tasks.json` mínimo (T1 fix, T2 verify/regressão).
 4. **Fix cirúrgico:** implementa a mudança mínima que resolve o sintoma — sem refatoração, sem hardening fora de escopo.
 5. **Test loop:** `morph-spec verify {feature-name} {task} --json` focado no blast radius até verde; evidência real capturada no `recap.md`.

package/framework/commands/morph-proposal.md

@@ -1,5 +1,5 @@
 ---
-description: Inicia uma nova feature MORPH-SPEC. Roda morph-brainstorming para entender negócio + escanear stack, depois morph-plan para produzir spec/mandate/tasks. Pausa nos Gates 1 e 2.
+description: Inicia uma nova feature MORPH-SPEC. Roda morph-brainstorming para entender negócio + escanear stack, depois morph-plan para produzir use cases, spec e tasks. Pausa nos Gates 1 e 2.
 argument-hint: <feature-name>
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, Skill
 ---
@@ -33,7 +33,7 @@ Conduz a feature do request inicial até o Gate 2 (plano aprovado), sem interven
 
 4. **Após Gate 1, invocar `morph-plan`** (skill em `.claude/skills/morph-plan/`):
    - Lê `proposal.md`.
-   - Produz `spec.md`, `mandate.md`, `tasks.json` em `.morph/features/{feature-name}/2-plan/`.
+   - Produz use cases, `spec.md` e `tasks.json` em `.morph/features/{feature-name}/2-plan/`.
    - Apresenta o **Gate 2** com template fixo (ver SKILL.md passo 5).
 
 5. **Aguardar aprovação do Gate 2.**