@polymorphism-tech/morph-spec 8.44.0 → 8.45.0

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

@@ -1,80 +1,67 @@
 ---
 name: morph-plan
-description: Guia a produção dos artefatos de planejamento de uma feature (use cases, spec.md, mandate.md, tasks.json) e apresenta o Gate 2 trust-aware.
+description: Guia a produção dos artefatos de planejamento de uma feature (use cases, spec.md, tasks.json) e apresenta o Gate 2 trust-aware.
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-plan
 
 ## Objetivo
 
-Produzir os **use cases**, `spec.md`, `mandate.md` e `tasks.json` com qualidade suficiente para abrir o Gate 2.
-Os use cases definem o **comportamento**; os três artefatos seguintes definem o como e o quanto da feature.
-
-A ordem importa e não é negociável: **comportamento antes de solução técnica**. Um `spec.md` escrito antes dos use cases resolve um problema que ainda não foi enunciado.
+Produzir os **use cases**, o `spec.md` e o `tasks.json` com qualidade para abrir o Gate 2. Os use
+cases definem o **comportamento**; o spec diz **como**; as tasks dizem **em que ordem** e **quando
+cada uma está pronta**. Comportamento antes de solução técnica — sempre nessa ordem.
 
 ## Quando invocar
 
-Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualquer implementação. Normalmente invocada pela skill orquestradora `morph-proposal`.
+Fase plan, depois do Gate 1. Normalmente chamada pela `morph-proposal`.
 
 ## O que fazer
 
-1. **Garanta que `proposal.md` e `stack-scan.md` estão no seu contexto antes de planejar.** Se 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. Na dúvida, Read. `.morph/features/{feature}/0-proposal/proposal.md` (problema, escopo, riscos — o comportamento é destilado aqui no passo 2, não vem pronto do proposal) e `.morph/features/{feature}/0-proposal/stack-scan.md` (contexto técnico detectado: greenfield vs brownfield, stack atual, drift). Em brownfield, o stack-scan informa decisões de spec/mandate — não invente padrões que conflitam com o detectado.
-
-   **E `.morph/features/{feature}/1-design/*.md`, quando o diretório existe** — os artefatos da fase
-   uiux (wireframes, decisões de layout, componentes propostos). Leia TODOS os `.md` de lá: eles
-   descrevem comportamento de interface que o `proposal.md` não carrega, e um plano que os ignora
-   dimensiona a feature pela metade. **Diretório ausente NÃO é erro** — a fase uiux é opcional
-   (MORPH.md §2.1) e a maioria das features não a toma; nesse caso não há passo nenhum a rodar e o
-   plano segue idêntico ao de hoje.
+1. **Garanta que `proposal.md` e `stack-scan.md` estão no seu contexto antes de planejar** (Read se
+   a sessão é fresca). Em brownfield, o stack-scan manda: não invente padrão que conflita com o
+   detectado.
 
-1b. **Scout — mapa do território antes de planejar (opcional, mas o default em feature grande ou brownfield).** É o call-site do "scout opcional antes do plan" que a MORPH.md promete. Dispare quando a feature toca área que você não tem em contexto, ou quando o `stack-scan.md` acusou brownfield com desvios.
+   **E `.morph/features/{feature}/1-design/*.md`, quando o diretório existe** — leia todos os `.md`:
+   descrevem comportamento de interface que o proposal não carrega. **Diretório ausente NÃO é erro**
+   — a fase uiux é opcional (MORPH.md §2.1) e o plano segue igual.
 
+1b. **Scout — mapa do território (default em feature grande ou brownfield).**
+   Despache `subagent_type: "morph-scout"`: os arquivos que a feature vai tocar, o blast radius dos símbolos centrais e o que
+   quebra junto. O scout começa por `morph-spec graph affected|explain` e **cai para grep sozinho
+   quando não há grafo**. Não registrado: `general-purpose` com o campo `persona` do `scout`.
+   Grave a resposta em `2-plan/scout-map.md` e audite:
    ```
-   subagent_type: "morph-scout"
-   ```
-
-   Peça: os arquivos que a feature vai tocar, o blast radius dos símbolos centrais dessa área e o que quebra junto. O scout começa por `morph-spec graph affected|explain` e **cai para grep sozinho quando não há grafo** — nunca trate a ausência de grafo como impedimento para planejar.
-
-   **Fallback** (se `morph-scout` não estiver registrado nos subagent types deste projeto): `general-purpose` com o campo `persona` do agente `scout` colado no prompt (Read em `.morph/framework/agents.json`), registrando o fallback no `decisions.md`.
-
-   Pular o scout é aceitável em feature pequena dentro de domínio já carregado — nesse caso **registre a decisão em uma linha no `decisions.md`**.
-
-1c. **Mapa de reuso — o que desta feature JÁ EXISTE no codebase.** Antes de destilar os use cases, responda por conceito: *isto já está implementado?* É o passo que falta hoje e cujo efeito é medido — 17 duplicações intra-feature no ProspectPRO, `SimpleBuilding` redefinido em cinco arquivos da MESMA pasta, um deles já sem um campo. Sem este passo, quem implementa não tem como saber, e o framework nunca pergunta.
-
-   **Insumos, nesta ordem:**
-   0. **O estado do grafo** — `morph-spec graph status --json`. Stale com `refresh.running: true`: espere o refresh terminar (ele roda em background, só na raiz) ou trate cada "não existe" como possivelmente velho; stale sem refresh em andamento — e sempre numa worktree (`refresh.auto: false`), cujo grafo é o semeado da raiz e não anda sozinho: `morph-spec graph refresh`. O resultado vai para a linha de método do mapa.
-   1. **O grafo** — para cada conceito central (entidade, DTO, componente, hook, serviço, helper — e o dublê ou a fixture de teste, que também estão no grafo, com `test: true`) que a feature vai introduzir: `morph-spec graph explain <nome-candidato> --json` (existe? onde?) e `morph-spec graph affected <conceito> --uses-only --json` (quem usa de verdade, sem contar quem só implementa). **O mapa nasce dessa saída**, não de memória nem de grep por conta própria.
-   2. **O inventário do projeto** — `.morph/context/README.md` (gerado por `morph-spec context refresh`): entidades, endpoints com método e rota, páginas e **componentes com path**. É a granularidade de *conceito* que o grafo, que casa por símbolo, não dá. **Este passo é o consumidor declarado desse arquivo** — se ele não existir, rode `morph-spec context refresh` ou siga sem ele.
-   3. **Sem grafo** (`no-graph`, projeto sem Python), ou o grafo não respondeu (`not-found` num grafo stale, `ambiguous` sem opção que sirva) — **caia para `grep -rn "<nome-candidato>"` no diretório de código e siga**; a ausência de grafo nunca bloqueia o plano (ADR-002). Registre a queda no `decisions.md`.
-
-   **Produza `.morph/features/{feature}/2-plan/reuse-map.md`** — artefato, não prosa solta, com a saída do grafo **citada**:
-
-   ```markdown
-   Método: `morph-spec graph status --json` → fresh, built_at_commit 1a2b3c4d = HEAD
-
-   | Conceito | Já existe? | Onde | Fonte | Decisão |
-   |---|---|---|---|---|
-   | SimpleBuilding | SIM (5×) | features/roulette/types/roulette.types.ts:L12 | `graph explain SimpleBuilding` → ambiguous, 5 opções | REUSAR |
-   | FilterValues | SIM (ambíguo) | dashboard + leads + store | `graph affected FilterValues --uses-only` → 7 consumidores | ESTENDER o de dashboard |
-   | RouletteScore | NÃO | — | `graph explain RouletteScore` → not-found; `grep -rn RouletteScore` → 0 | CRIAR — nenhum tipo cobre pontuação por sorteio |
+   morph-spec scout-check .morph/features/{feature}/2-plan/scout-map.md --json
    ```
-
-   **A coluna Fonte cita o comando e o que ele devolveu** (`ok` com `arquivo:linha`, `not-found`, `ambiguous` com as opções) — ou o `grep` da queda, com a contagem. Sem grafo, a linha de método diz isso (`sem grafo — grep`). Uma linha sem Fonte não vale, pela mesma razão que um CRIAR sem justificativa: quem lê o mapa no Gate 2 precisa saber se o "não existe" veio de uma consulta ou de uma suposição.
-
-   **`CRIAR` exige justificativa em uma linha, na própria célula** — a mesma forma que `morph-uiux` §"Consistência" já impõe para token de design (*"um token novo precisa de justificativa: o existente não cobre o caso"*). Sem a justificativa, o veredito não vale.
-
-   **Distinga "extrair para shared" de "importar de outra feature".** Reuso não é desculpa para acoplar slices: se o conceito é de duas features, o alvo é um módulo comum, não um import cruzado — a rubrica `architecture` penaliza dependência cross-feature e continua valendo.
-
-   O veredito viaja para o implementador pelo campo `reuse` de cada task (passo 5). Quem cobra o resultado é o `morph-spec verify`: o validador `reuse` acusa símbolo novo cujo nome já existe no grafo, na mesma linguagem — **intra-feature reprova**, cross-feature avisa, e um `CRIAR` declarado no plano rebaixa o achado a aviso.
-
-1d. **O que esta feature supera no acervo.** Insumos: a seção `Conflitos com o acervo` do `proposal.md`, o acervo `.morph/specs/usecases/` e o índice de ADRs ativos `.morph/specs/adrs/` (um arquivo por ADR). UC com `status: superseded` não é o comportamento vigente — o `superseded_by` é, e `scope` diz onde o antigo ainda vale; decisão vigente é a do índice, e os `decisions.md` arquivados são história, não instrução.
-
-   Cada conflito com UC ou ADR decidido pelo pedido novo vira duas coisas: uma linha na seção de revogação do `spec.md` (passo 3) e um ADR no `decisions.md` (conflito com `.morph/context/*.md` vira a reescrita do corpo daquele documento no encerramento — `morph-apply` §6). ADR cuja regra vale **além desta feature** leva `**Alcance:** projeto` — é por essa linha que o `finish` o copia para o índice (o resto fica só no `decisions.md` da feature):
-
+   Exit ≠ 0 → o mapa é descartado; re-despache **uma** vez com as `failures` coladas. Segunda
+   reprovação: faça você o grep dos fatos que o plano precisa. Mapa aprovado prova que as citações
+   existem, não que a conclusão está certa — confira com grep próprio o Inferido que muda o plano.
+   Pular o scout em feature pequena no domínio carregado: uma linha em `decisions.md`.
+
+1c. **Reuso — o que desta feature JÁ EXISTE.** Para cada conceito central que a feature introduz
+   (entidade, DTO, componente, hook, serviço, helper, dublê de teste): `morph-spec graph explain
+   <nome> --json` (existe? onde?) e `morph-spec graph affected <conceito> --uses-only --json` (quem
+   usa de verdade). Antes, `morph-spec graph status --json`: stale numa worktree, ou sem refresh em
+   andamento, `morph-spec graph refresh`. O inventário `.morph/context/README.md` (`morph-spec context
+   refresh`) dá componentes e endpoints por path. **Sem grafo** (`no-graph`, `not-found` num grafo
+   stale), caia para `grep -rn "<nome>"` e siga — a ausência de grafo nunca bloqueia.
+
+   O veredito vai direto para a task que realiza o conceito (passo 5b): `REUSAR`, `ESTENDER` ou
+   `CRIAR`. **`CRIAR` exige `why`** — uma linha com a consulta que respondeu "não existe" (`graph
+   explain X → not-found; grep -rn X → 0`). Conceito de duas features vai para um módulo comum, nunca
+   import cruzado entre slices. O validador `reuse` do `verify` cobra o resultado: símbolo novo
+   homônimo de um existente reprova na mesma feature e avisa entre features; `CRIAR` declarado no
+   plano rebaixa o achado a aviso.
+
+1d. **O que esta feature supera no acervo.** Insumos: `Conflitos com o acervo` do `proposal.md`,
+   `.morph/specs/usecases/` e o índice `.morph/specs/adrs/`. UC `status: superseded` não é o
+   comportamento vigente — o `superseded_by` é. Cada conflito decidido vira uma linha na seção de
+   revogação do `spec.md` (passo 3) e um ADR em `decisions.md`; ADR que vale além desta feature leva
+   `**Alcance:** projeto` (é por ela que o `finish` o copia para o índice):
    ```markdown
    ## ADR-{nnn}: {a regra que vale no projeto}
 
@@ -101,66 +88,53 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    ## Cenário principal
    1. Visitante acessa a listagem de veterinários
    2. Sistema retorna os veterinários ordenados por sobrenome
-   3. Sistema exibe, para cada um, nome e especialidades
 
    ## Pós-condições
    - **P1** — A resposta contém todos os veterinários não arquivados
    - **P2** — Cada veterinário traz suas especialidades em lista, nunca string concatenada
-   - **P3** — A ordenação por sobrenome é estável para nomes repetidos
 
    ## Fluxos alternativos (opcional)
    - **A1** — Nenhum veterinário cadastrado → sistema exibe estado vazio
    ```
 
-   **A regra que sustenta a camada inteira: pós-condição precisa ser observável em teste.** "O sistema fica consistente" não passa. "A resposta contém todos os veterinários não arquivados" passa. Antes de escrever cada pós-condição, pergunte: *que asserção eu escreveria para verificar isto?* Se não há resposta, a pós-condição está mal formulada — reescreva ou descarte. Sem esse filtro a camada vira prosa e não chega ao `doneCriteria`.
+   **A regra que sustenta a camada inteira: pós-condição precisa ser observável em teste.** Pergunte:
+   *que asserção eu escreveria para verificar isto?* Sem resposta, reescreva ou descarte.
 
    **Artefato não é comportamento.** Pós-condição que cita arquivo, pasta, `grep`, "contém a
-   string" ou "o binário" descreve o TEXTO do repositório, não o que o sistema faz — e chega
-   literal ao `doneCriteria`, onde vira um teste que lê arquivo. Duas saídas, nesta ordem:
-   1. **Reescreva como efeito observável em runtime** — o que o sistema faz de diferente quando
-      o texto está errado ("publicar tenant com `criterion_overrides` é recusado, nomeando a
-      chave", não "nenhum arquivo em `tenants/**` contém a chave").
-   2. **Se o artefato É o entregável** (standard, faxina sem efeito de runtime), justifique
-      **na linha logo abaixo** da pós-condição:
+   string" ou "o binário" descreve o texto do repositório, não o que o sistema faz. Primeiro tente
+   o efeito observável em runtime ("publicar tenant com `criterion_overrides` é recusado, nomeando a
+   chave"). Se o artefato É o entregável, justifique **na linha logo abaixo**:
 
       ```markdown
       - **P4** — Nenhum arquivo em `tenants/**` contém a chave `criterion_overrides`
         > [!note] Por que artefato: a chave saiu do contrato; nenhum leitor de runtime a consulta.
       ```
 
-      Nunca na mesma linha: o texto da pós-condição viaja literal ao `doneCriteria` e a
-      justificativa iria junto. Task sem `usecase` justifica no próprio `doneCriteria`
-      (`… — Por que artefato: …`). O `morph-spec dag` aponta o vocabulário sem justificativa.
-
-   Pós-condição sobre o que um **modelo** responde ("o texto pode nomear a pior campanha") é
-   observável — em runtime, nunca no texto do prompt. O passo 5 diz que forma a task toma.
-
-   **Identificador sequencial, reservado — nunca leia o disco à mão.** Rode `morph-spec usecase reserve --count {n} --feature {feature}` (`n` = quantos UCs esta feature vai criar; pode reservar de novo se descobrir mais no meio do plano). Um scan manual do maior `UC-{nn}` só enxerga a ÁRVORE CORRENTE — cada worktree tem a própria cópia de `.morph/features/`, então dois worktrees planejando ao mesmo tempo calculam o mesmo maior número e mintam o MESMO `UC-{nn}` sem saber um do outro; na promoção do `finish`, o segundo a fechar sobrescreve por ID e **apaga o use case do primeiro** — já causou perda de dados em produção. `usecase reserve` aloca atomicamente a partir de um contador compartilhado em `<git-common-dir>/morph-spec/uc-registry.json` (visível a todo worktree do repo, mesmo mecanismo do `claim`/fleet), semeado do maior número já visto no acervo + nas features da árvore corrente + no próprio contador — nunca regride. Fora de um repositório git, cai para o scan local antigo e avisa que o paralelismo entre worktrees não está protegido.
+   Nunca na mesma linha: a pós-condição viaja literal ao `doneCriteria`. Task sem `usecase`
+   justifica no próprio `doneCriteria` (`… — Por que artefato: …`). Pós-condição sobre o que um
+   **modelo** responde é observável em runtime, nunca no texto do prompt (passo 5).
 
-   **Seções obrigatórias:** `Pré-condições` (o que já é verdade antes), `Cenário principal` (o caminho feliz, numerado, **curto** — não é o lugar para exaustão de casos) e `Pós-condições` (**P1**, **P2**… — o que passa a ser verdade, cada uma testável; é a seção que viaja **literal** ao `doneCriteria`, ver abaixo).
+   **Numeração:** `morph-spec usecase reserve --count {n} --feature {feature}` — nunca o maior
+   `UC-{nn}` do disco: cada worktree vê só a sua cópia, e dois planos paralelos mintariam o mesmo id.
 
-   **Seções opcionais** — inclua só quando o comportamento não-trivial exigir, não por padrão: `Fluxos alternativos` (**A1**, **A2**… — um desvio do caminho feliz que precisa de pós-condição própria; edge case de *comportamento* mora aqui, edge case *técnico* fica no `spec.md`) e `Delta de domínio` (**só quando a feature muda o modelo**: campo novo, relação nova, invariante nova — sem delta, omita a seção em vez de escrever "nenhum"). Nenhuma das duas é consumida por `dag`/`finish` — existem para o leitor humano quando o caso pede, não para preencher o template.
-
-   **Quando é obrigatório** (ver MORPH.md §2.1 para o roteamento por tipo):
+   **Seções:** obrigatórias `Pré-condições`, `Cenário principal` (curto) e `Pós-condições` (**P1**,
+   **P2**…). Opcionais, só quando pedem: `Fluxos alternativos` (**A1**…) e `Delta de domínio`.
 
    | Tipo | Use case |
    |---|---|
-   | `feature` | Obrigatório quando há comportamento observável. Feature puramente técnica (refactor, infra, migração) dispensa — **registre a dispensa em `decisions.md`**. |
-   | `bug` | Não cria novo, não reserva número novo: **copie** o `UC-{nn}-*.md` do acervo para `2-plan/usecases/` **mantendo o nome do arquivo publicado** (mesmo slug) e **corrija ou adicione a pós-condição** lá — o bug é a pós-condição que faltava, não a identidade do UC. É esse mesmo nome, inalterado, que faz o `finish` reconhecer a correção como o MESMO UC (abaixo) em vez de uma colisão. UC `superseded` com `scope`: a correção vale só para a parte que ainda vale, e a cópia leva `status`/`superseded_by`/`scope` como estão — a promoção os preserva. |
-   | `chore` | Nenhum (já pula a fase plan por política). |
-   | `hotfix` | Não bloqueia. Referencia se existir; o pós-mortem pode virar pós-condição numa feature posterior. |
-
-   **Nunca edite `.morph/specs/usecases/` à mão.** A única via de escrita no acervo é a promoção do `finish`, que lê **só** de `2-plan/usecases/`: é ela que carimba `status: implemented`, sobrescreve por ID (mesmo com slug novo) e leva o arquivo no commit de arquivamento. Editar o acervo direto pula os três e cria uma segunda verdade fora do mecanismo. Mudar um UC existente = copiar para o `2-plan/usecases/` da feature, corrigir lá, e deixar o `finish` sobrescrever. Aposentar um UC (todo ou em parte) também não é edição à mão: é a seção de revogação do `spec.md` (passo 3), que o `finish` aplica.
-
-   **Backstop de colisão na promoção.** Se, apesar da reserva, duas features chegarem à promoção com o MESMO `UC-{nn}` e slugs diferentes — registro de reserva aponta para uma feature diferente da que já está no acervo —, o `finish`/`archive` **recusa promover esse UC específico** (nunca recusa fechar a feature: fail-open, só aquele use case fica de fora) e imprime onde o arquivo ficou e como recuperar. Se acontecer: renumere com `usecase reserve` e promova manualmente, ou — se for mesmo o caso `bug` — confira se o slug bate com o publicado.
+   | `feature` | Obrigatório com comportamento observável; feature puramente técnica dispensa (registre em `decisions.md`). |
+   | `bug` | Copie o `UC-{nn}-*.md` do acervo para `2-plan/usecases/` **com o mesmo nome de arquivo** e corrija ou adicione a pós-condição — não reserve número novo. |
+   | `chore` | Nenhum. |
+   | `hotfix` | Referencia se existir. |
 
-   O use case fica **editável depois do Gate 2**, por design — é o que permite mudar o comportamento e re-rodar `implement`. A trilha de auditoria fica no git.
+   **Nunca edite `.morph/specs/usecases/` à mão** — a única escrita no acervo é a promoção do
+   `finish`, que lê de `2-plan/usecases/`. O use case segue editável depois do Gate 2.
 
-3. Produza `spec.md` em `.morph/features/{feature}/2-plan/`:
-   - Arquitetura da solução: quais componentes, como se conectam, fluxos de dados principais.
-   - Edge cases **técnicos** e como serão tratados (os de comportamento estão nos fluxos alternativos dos use cases).
-   - Integrações externas e contratos esperados.
-   - **UCs e ADRs que esta feature altera ou revoga** — seção obrigatória, com este título: `Nenhum.` quando nada muda; senão, a tabela (colunas posicionais — o cabeçalho é livre):
+3. Produza `spec.md` em `2-plan/`:
+   - Arquitetura: componentes, como se conectam, fluxos de dados. Edge cases **técnicos** (os de
+     comportamento estão nos use cases) e integrações externas. Não repita o comportamento.
+   - **UCs e ADRs que esta feature altera ou revoga** — seção obrigatória com este título; `Nenhum.`
+     quando nada muda, senão:
 
      ```markdown
      ## UCs e ADRs que esta feature altera ou revoga
@@ -171,75 +145,41 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
      | {feature}/ADR-{nnn} | total | — | — |
      ```
 
-     Troque os placeholders pelos ids reais (ex.: `UC-133` superado em parte por `UC-589`, ainda valendo na vitrine) — um placeholder esquecido não é id, e o `usecase check` o aponta. `Id` é `UC-{nn}` ou `{feature}/ADR-{nnn}` — o número de ADR recomeça em cada feature. UC revogado exige `Substituto` (`UC-{nn}`, que vira o `superseded_by`) que exista no acervo depois da promoção; `parcial` exige `Escopo`, e `total` não tem; id repetido em duas linhas não aplica nenhuma delas. No `finish`, dentro do commit de arquivamento, o UC ganha `status: superseded` + `superseded_by` (+ `scope`) e o ADR sai do índice (total) ou fica com o escopo (parcial); linha malformada, alvo fora do acervo ou substituto inexistente não é aplicada e volta em `revocationProblems`. **Rode `morph-spec usecase check {feature}` logo depois de escrever a seção**: o `spec.md` congela no Gate 2, e uma linha errada descoberta no `finish` já não tem conserto no plano.
-
-   O `spec.md` responde **como** os use cases do passo 2 serão realizados. Não repita o comportamento aqui.
-
-4. Produza `mandate.md` em `.morph/features/{feature}/2-plan/`:
-   - Stack exata do projeto (leia de `.morph/config/config.json` → `project.stack` ou do CLAUDE.md).
-   - Standards obrigatórios: descubra-os com `morph-spec standards --find "<domínio/tecnologia>"` (top 3 `id · path · digest` — o digest decide) por domínio tocado; liste os IDs escolhidos.
-   - Patterns proibidos — **copie por extenso no mandate.md** a lista canônica de `MORPH.md` § "Stack baked-in" (`Guid.NewGuid()`→`Guid.CreateVersion7()`, 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`, SQL cru sem justificativa, redeclarar tipo/componente que já existe na mesma feature) mais qualquer proibição específica da feature. Copie o texto completo — o mandate.md é lido por implementadores em contexto fresco, sem `MORPH.md` carregado, então um ponteiro sozinho não basta aqui.
-   - Política de acesso a dados (registre no mandate): `ApplicationDbContext` injetado direto no slice — para CRUD e para queries específicas (joins, projeção, paginação). Para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
-   - **Features com agentes de IA (MAF):** se a feature envolve um agente (Microsoft Agent Framework), **use a tool Read** nos standards relevantes de `.morph/framework/standards/ai-agents/*.md` (ex.: `setup`, `agent-session`, `middleware-patterns`, `mcp-server`, `mcp-tools`, `multi-agent-patterns`, `production`) — filtre pelo que a feature exige via `morph-spec standards --find "<tema>" --category ai-agents`. Esses standards carregam as **convenções de projeto** (single-agent por padrão — Workflows só para fan-in/out real; provider, caching, observability, A2A) que uma fonte externa de docs (ex.: context7) não conhece. Padrão de divisão: **superfície da API** pode vir de docs ao vivo/context7 (mais frescas para um SDK em evolução), mas **as convenções vêm dos standards** — registre ambas no mandate. Não pule os `ai-agents/*.md` só porque o STANDARDS.json index lista que eles existem.
-   - **Verificação de runtime** — como se PROVA que a feature funciona rodando, não só compilando.
-     Compilar não é subir: um serviço injetado sem registro em `Program.cs` passa no build e derruba
-     a aplicação no startup. Registre no mandate:
-     - **Como o stack sobe:** o `docker compose` do projeto (`morph-spec e2e up {feature}`). Se o
-       projeto containeriza mas não tem compose, **isso é uma task** — sem ele o nó `e2e` do verify
-       reprova (não dispensa).
-     - **O que precisa ser exercitado:** os fluxos desta feature que o avaliador vai navegar, em
-       linguagem de comportamento — os mesmos verbos das pós-condições dos use cases.
-     - **Quais viram spec Playwright versionada:** caminho crítico e bug corrigido merecem regressão;
-       exploração pontual não. O critério vai aqui; escrever a spec é tarefa da implementação.
-     - **Base URL vinda do ambiente:** o harness dá a cada feature um bloco de portas próprio (para
-       duas worktrees não brigarem pela porta 3000), então o `playwright.config.ts` **não pode**
-       cravar a URL — leia `process.env.PLAYWRIGHT_BASE_URL ?? \`http://localhost:${process.env.PORT ?? 3000}\``
-       e faça o compose publicar `"${PORT:-3000}:3000"` e `"${POSTGRES_PORT:-5432}:5432"`, sem
-       `container_name` (o projeto compose já namespaceia; nome explícito colide entre worktrees —
-       standard `infrastructure/docker/local-compose-isolation`). Config cravada = suíte batendo em
-       porta vazia e `ECONNREFUSED` com cara de app quebrada; compose cravado **reprova o nó e2e**
-       dentro de um worktree. Se estiver cravado, **isso é uma task**.
-     - **Setup de autenticação**, se a aplicação tem login: `e2e.auth` em `config.json`
-       (`mode: seed|storageState|bypass|none`, `seedCommand`, `storageStatePath`, `envFile`), com as
-       credenciais num `.env.e2e` **gitignored** — nunca no config commitado. **`mode` é obrigatório
-       sempre que houver `seedCommand`**: com `mode` ausente (ou `"none"`) o seed fica **inerte** — o
-       comando está configurado e nunca roda, e o autor acredita que a base é semeada. O `verify`
-       avisa (`[e2e] warning: …` nomeando `e2e.auth.seedCommand` e `e2e.auth.mode`), mas um aviso não
-       repara um plano: escreva o `mode` no config que a task de setup entrega. **Se a app tem login e
-       isso não existe, crie a task de setup**: sem ela a navegação para na tela de login e a
-       verificação de runtime vira teatro. É gap de Gate 2, não dispensa de Gate 3.
-     - **Baseline de contagem de testes é um COMANDO aqui também:** se o projeto declara
-       `project.tests[]`, o `expectedCount` de cada suíte é gravado por `morph-spec verify {feature}
-       --record-baseline` a partir de uma execução verde — **nunca digitado no config**. Um número
-       inventado **alto demais** deixa o verify vermelho por `count-drop` e trava o próprio comando que
-       o consertaria (só sai rebaixando/apagando o número à mão). Forma de `project.tests[]`:
-       `.morph/framework/CLI.md`, seção "Suítes de teste".
-     - **Quando não se aplica** (biblioteca pura, chore sem runtime), registre a dispensa e o porquê.
-   - Checklist de done com critérios verificáveis por tarefa.
-   - **Orçamento de teste e comentário — copie no mandate**, pelo mesmo motivo dos patterns
-     proibidos: o orçamento por task do passo 5 (um teste por pós-condição + um de regressão por
-     bug, justificativa acima disso, tabela antes de cópia, nenhum teste que só fixa texto);
-     fixture compartilhada antes de helper novo; TDD onde paga (bug: regressão primeiro; lógica
-     pura), teste depois aceito em UI e integração; comentário: o padrão é nenhum (nome, tipo e teste
-     explicam), só o porquê que o código não mostra, nunca `///`/JSDoc que repete a assinatura
-     nem história de task/UC/ADR. Nos standards obrigatórios, liste
-     `architecture-code-comments` e o standard de teste do stack (seção *Test budget*).
-   - **Baseline é um COMANDO, nunca um número.** O mandate congela no Gate 2 e é lido por
-     implementadores durante dias — todo número cravado nele (`Suíte: 2366 passando`, cobertura,
-     contagem de arquivos) está errado a partir da primeira task, e um agente que confia nele
-     "conserta" um baseline que nunca esteve quebrado. Registre **como medir** (`npm test`,
-     `dotnet test`) e mande comparar com o resultado do momento, não com um valor histórico.
-     Aconteceu de verdade: mandate afirmando 2366 quando já eram 2375, e um ADR escrito só para
-     desmentir o próprio mandate.
-   - **Pré-requisito é um PREDICADO, nunca um SHA literal.** "`git merge-base --is-ancestor
-     origin/main HEAD` sai 0" ou "a branch da feature X está integrada" — não "confirme que
-     origin/master contém `49dfba2`". SHA cravado envelhece na primeira rebase/squash: o merge sai
-     com outro hash e o sub-agent mandado verificá-lo ou queima turnos procurando o que não existe,
-     ou declara que verificou sem ter verificado.
-
-5. Produza `tasks.json` em `.morph/features/{feature}/2-plan/` seguindo o schema em `.morph/framework/schemas/tasks.schema.json`.
-
-   **Formato obrigatório** (schema em `.morph/framework/schemas/tasks.schema.json` — o hook `tasks-json-guard` valida cada write):
+     `Id` é `UC-{nn}` ou `{feature}/ADR-{nnn}`. UC revogado exige `Substituto`; `parcial` exige
+     `Escopo`. O `finish` aplica as linhas válidas e devolve as malformadas em `revocationProblems`.
+     **Rode `morph-spec usecase check {feature}` logo depois de escrever a seção** — o spec congela no
+     Gate 2.
+
+4. **Seção `## Contrato de implementação` do `spec.md`** — o que quem implementa precisa saber e o
+   código não diz. Curta; o resto já está nos standards que cada task carrega.
+   - **Standards:** `morph-spec standards --find "<domínio>"` por domínio tocado (o digest decide);
+     liste os ids. Inclua `architecture-code-comments` e o standard de teste do stack. Feature com
+     agente MAF: os `standards/ai-agents/*.md` que ela exige (`--category ai-agents`) — convenção de
+     projeto vem deles; superfície da API pode vir do context7.
+   - **Proibições desta feature** além das de `MORPH.md` § "Stack baked-in", quando houver.
+   - **Verificação de runtime** — como se prova que a feature funciona rodando:
+     - O stack sobe pelo `docker compose` do projeto (`morph-spec e2e up {feature}`). Projeto que
+       containeriza sem compose: **isso é uma task**.
+     - Os fluxos que o avaliador vai navegar, nos verbos das pós-condições; quais viram spec
+       Playwright (caminho crítico e bug corrigido).
+     - Base URL do ambiente: `process.env.PLAYWRIGHT_BASE_URL ?? \`http://localhost:${process.env.PORT ?? 3000}\``,
+       compose publicando `"${PORT:-3000}:3000"` e sem `container_name` (standard
+       `infrastructure/docker/local-compose-isolation`). Cravado: **isso é uma task**.
+     - App com login: `e2e.auth` em `config.json` (`mode: seed|storageState|bypass|none`,
+       `seedCommand`, `storageStatePath`, `envFile`), credenciais num `.env.e2e` gitignored.
+       **`mode` é obrigatório sempre que houver `seedCommand`** — sem ele o seed fica inerte. Sem setup de
+       login, crie a task.
+     - Não se aplica (biblioteca pura): registre a dispensa e o porquê.
+   - **Baseline é um COMANDO, nunca um número.** O spec congela no Gate 2 e é lido por dias: número
+     cravado (`2366 passando`) está errado na primeira task, e quem confia nele "conserta" o que não
+     quebrou. Registre como medir (`npm test`, `dotnet test`); o `expectedCount` de `project.tests[]`
+     é gravado por `morph-spec verify {feature} --record-baseline`, nunca digitado.
+   - **Pré-requisito é um PREDICADO, nunca um SHA literal**: "`git merge-base --is-ancestor
+     origin/main HEAD` sai 0", não "confirme que main contém `49dfba2`" — o SHA muda no primeiro
+     squash.
+
+5. Produza `tasks.json` em `.morph/features/{feature}/2-plan/` seguindo o schema
+   `.morph/framework/schemas/tasks.schema.json` (o hook `tasks-json-guard` valida cada write):
 
    ```json
    {
@@ -249,175 +189,119 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
        {
          "id": "T1",
          "title": "Título curto",
-         "description": "Detalhes — o que esta task realiza e por quê",
+         "description": "O que esta task realiza e por quê",
          "dependencies": [],
          "effort": "S",
          "doneCriteria": "P2 — Cada veterinário traz suas especialidades em lista, nunca string concatenada",
          "status": "pending",
-         "outputs": [],
+         "outputs": ["src/Vets/ListVets.cs", "tests/Vets/ListVetsTests.cs"],
          "group": "backend",
          "usecase": "UC-07",
          "agent": "dotnet-senior",
          "standards": ["standards/backend/dotnet/vsa-handler-patterns.md"],
-         "reuse": [{ "concept": "SimpleBuilding", "verdict": "REUSAR", "target": "features/roulette/types/roulette.types.ts" }]
+         "reuse": [{ "concept": "VetDto", "verdict": "CRIAR", "why": "graph explain VetDto → not-found; grep -rn VetDto → 0" }]
        }
      ]
    }
    ```
 
-   Regras:
-   - `id` segue padrão `T\d+` (T1, T2, T10...).
-   - `dependencies` lista outros IDs Tn. Tasks sem deps tem `[]`.
-   - `effort`: S (≤30min), M (≤1h), L (≤2h), XL (>2h).
-   - `status` inicia sempre como `pending`.
-   - `group` (opcional): backend, frontend, tests, infra, docs. Default backend.
-   - `outputs` (opcional): array de paths que serão criados/modificados.
-   - `usecase` (opcional): o **ID** do use case que a task realiza — `UC-07`, nunca o nome do arquivo. Task puramente técnica (build, config, migração) não tem.
-   - `agent` (opcional): o `id` da persona de `agents.json` responsável pelo domínio da task — **sem** o prefixo `morph-` (ex.: `"dotnet-senior"`, não `"morph-dotnet-senior"`). Carimbado no passo 5a abaixo; ausente numa task sem domínio de agente claro (config/docs) ou num plano legado.
-   - `reuse` (opcional): os vereditos do `reuse-map.md` (passo 1c) que ESTA task realiza — `[{concept, verdict: REUSAR|ESTENDER|CRIAR, target}]`. Só nas tasks que tocam o conceito; task que não introduz conceito nenhum não tem. **A justificativa do CRIAR fica no `reuse-map.md`, não aqui** — o mesmo fato escrito em dois lugares diverge. É este campo que o `morph-spec verify` lê para saber se a criação de um símbolo homônimo foi decidida no Gate 2 ou aconteceu por descuido.
-   - `standards` (opcional): array de paths relativos de `.morph/framework/standards/` (ex.: `["standards/backend/dotnet/vsa-handler-patterns.md"]`) — os standards da persona resolvida em `agent`, mais qualquer standard específico que a task exija.
-
-   **5a. Carimbe `agent` e `standards` — uma leitura de `agents.json`, N tasks.** Antes de fechar o array `tasks`, **use a tool Read UMA VEZ** em `.morph/framework/agents.json` (não releia por task — é essa releitura repetida por task, hoje feita em `morph-implement`/`morph-apply` a cada dispatch, que este passo existe para eliminar). Para cada task do plano, resolva:
-   - `agent`: o `id` da persona (chave do objeto `agents`, sem prefixo `morph-`) cujo `domains` cobre o `group`/domínio da task — o mesmo casamento que `morph-implement` §3 e `morph-apply` §3b fariam manualmente a cada dispatch; aqui você faz uma vez, no plano.
-   - `standards`: o array `standards` dessa persona, mais qualquer standard adicional que a task especificamente exija (some, não substitua). **Persona com `surfaces`** (a `ui-designer`): some também a lista da superfície da tela que a task entrega — a que o checklist de tela do `1-design/mockups.md` declara em `Superfície` —, nunca a de outra superfície; sem mockup, escolha pela tela e registre a escolha em `decisions.md`.
-
-   **5b. Carimbe `reuse` — do `reuse-map.md` para a task que realiza o conceito.** Para cada linha do mapa produzido no passo 1c, encontre a task que vai escrever aquele conceito e copie o veredito para `reuse` (`concept` + `verdict` + `target`). Um conceito sem task é sinal de plano incompleto — ou o mapa listou o que a feature não vai tocar, ou falta task. Resolva antes do Gate 2.
-
-   **Task que cria ou altera superfície de UI** (componente, página, estilo, fluxo de navegação) carimba `agent: "ui-designer"` — inclusive numa feature que não tomou o ramo uiux (MORPH.md §2.1): o critério de agente é por domínio da task, não por fase percorrida.
-
-   Uma task cujo domínio não bate com nenhuma persona registrada (ex.: task pura de config/docs) fica sem `agent` — `morph-implement` cai no fallback de Read de `agents.json` nesse caso.
-
-   **O `doneCriteria` carrega a pós-condição LITERAL.** Este é o elo que amarra a cadeia inteira: a pós-condição escrita em linguagem de negócio chega **sem tradução** ao critério que o `morph-spec verify` e o `morph-eval` cobram. Copie o texto da pós-condição, prefixado pelo seu rótulo (`"P2 — Cada veterinário traz..."`). Reescrever com outras palavras aqui é exatamente o ponto em que o requisito se perde hoje.
-
-   **`morph-spec dag {feature}` cobra o encanamento.** Ele lê os use cases junto com o `tasks.json` e reporta: referência a um `UC-{nn}` inexistente (**erro** — trava), pós-condição que nenhuma task cita (aviso) e task que referencia um UC mas parafraseou em vez de copiar (aviso). A comparação normaliza caixa e espaço, então prefixar o rótulo não quebra o casamento — mas a redação e os acentos precisam bater. E um quarto achado, léxico e também só aviso: `doneCriteria` com vocabulário de artefato (`grep`, "contém a string", "o binário", "nenhum arquivo", "arquivo/pasta/diretório em", glob `**/`) sem `Por que artefato:` (passo 2). O `dag` aponta o vocabulário; se a pós-condição é observável em teste continua sendo seu no Gate 2 e do evaluator.
-
-   **Ciclo de vida do acervo — também só aviso.** O `dag` (e o `morph-spec usecase check {feature}`, que roda sem `tasks.json`) aponta task cujo `usecase` está `superseded` — no acervo, na cópia da feature ou revogado pelo próprio `spec.md` —, frontmatter de supersessão malformado e linha de revogação que o `finish` não conseguiria aplicar. Task sobre UC superado em parte é legítima quando realiza a parte que ainda vale; senão, cite o substituto.
-
-   Cada pós-condição de cada use case deve estar coberta por **pelo menos uma** task. Antes de fechar o `tasks.json`, percorra os `UC-*.md` e confira: sobrou pós-condição sem task? Ou o plano está incompleto, ou a pós-condição não era necessária — resolva antes do Gate 2, não depois.
-
-   **Orçamento de teste por task.** Cada pós-condição que a task realiza compra **um** teste, e
-   cada bug corrigido compra **um** de regressão. Acima disso, a task justifica em uma linha da
-   `description` (é ela que chega ao sub-agente). O orçamento conta comportamentos, não cenários:
-   os cenários do mesmo comportamento são linhas de uma tabela (`[Theory]`/`it.each`), não N
-   testes. **Nenhum teste que só fixa texto** (copy de UI, config de tenant, prosa): a checagem
-   vira analyzer, lint ou validação no publish e fica fora da contagem da suíte. A regra de
-   critério sobre saída de LLM, abaixo, é o caso de prompt desta. A prova de mutação do Gate 3
-   continua no caminho crítico: mutante sobrevivente se mata apertando uma asserção ou somando uma
-   linha de tabela, nunca com um teste novo por mutante. O `morph-spec verify` avisa quando as
-   linhas de teste adicionadas passam de 1,5× as de produção (validador `code-budget`).
-
-   **Preencha `outputs` (paths planejados) em cada task** — o `morph-spec dag` usa os outputs para detectar colisão de arquivos entre fluxos paralelos e recomendar `isolation: "worktree"`. Task sem `outputs` entra como footprint desconhecido (não força isolamento, mas o dag não consegue protegê-la de colisão).
-
-   **Tamanho da task: no máximo 8 `outputs`** (testes incluídos). Uma task inteira cabe num
-   dispatch; acima disso o sub-agente bate no teto de turnos e a retomada recomeça fria. Fatie por
-   pós-condição (uma task por pós-condição ou par delas, com a dependência explícita). Antes do
-   Gate 2, o `morph-spec dag` recusa (exit 1) e o `gate-check plan` pausa com `oversizedTasks`;
-   depois do Gate 2 é só aviso.
-
-   **Critério sobre saída de LLM vira eval de runtime — nunca "suíte estrutural".** Duas etapas,
-   como na `morph-review`: (1) **filtro mecânico** — o `mandate.md` cita ao menos um standard
-   `ai-agents`; senão, a regra não se aplica. (2) **determinação sua, por task** — o
-   `doneCriteria` julga o que o modelo *responde* (conteúdo, tom, escolha)? Se sim:
-   - a prova é um **eval de runtime**; a evidência (entrada, modelo, saída, veredito) vai em
+   - `id` `T\d+`; `dependencies` com ids Tn; `effort` S (≤30min) | M (≤1h) | L (≤2h) | XL (>2h);
+     `status` nasce `pending`; `group` backend | frontend | tests | infra | docs.
+   - `usecase`: o **id** (`UC-07`), nunca o nome do arquivo.
+   - `outputs`: paths planejados — o `dag` detecta colisão entre fluxos paralelos por eles.
+     **No máximo 8 `outputs` por task** (testes incluídos): acima disso o sub-agente bate no teto de
+     turnos; o `dag` recusa antes do Gate 2.
+
+   **5a. Carimbe `agent` e `standards`** com UMA leitura de `.morph/framework/agents.json`: `agent` é
+   o id da persona (sem `morph-`) cujo `domains` cobre o domínio da task; `standards`, o array dela
+   mais o que a task exige. **Persona com `surfaces`** (a `ui-designer`): some a lista da superfície
+   que o checklist de tela do `1-design/mockups.md` declara em `Superfície`, nunca de outra; sem
+   mockup, escolha pela tela e registre em `decisions.md`. Task que cria ou altera UI carimba
+   `agent: "ui-designer"` mesmo sem o ramo uiux. Task sem persona clara (config, docs) fica sem `agent`.
+
+   **5b. Carimbe `reuse`** na task que escreve cada conceito do passo 1c: `concept`, `verdict`,
+   `target` (o que reusar ou estender) e, em `CRIAR`, `why`. Conceito sem task: falta task ou o
+   conceito não é desta feature — resolva antes do Gate 2.
+
+   **O `doneCriteria` carrega a pós-condição LITERAL**, prefixada pelo rótulo (`"P2 — Cada
+   veterinário traz..."`). Reescrever com outras palavras é onde o requisito se perde. Toda
+   pós-condição de todo UC tem ao menos uma task.
+
+   **`morph-spec dag {feature}` cobra o encanamento.** Ele reporta UC inexistente (erro), pós-condição sem task e `doneCriteria` parafraseado (avisos), e `doneCriteria` com vocabulário de artefato (`grep`, "contém a string", "o binário", "nenhum arquivo", "arquivo/pasta/diretório em", glob `**/`) sem `Por que artefato:` (aviso). Também aponta task sobre UC `superseded` e linha de revogação que o `finish` não aplicaria.
+
+   **Orçamento de teste por task.** Cada pós-condição compra **um** teste, cada bug corrigido **um** de
+   regressão; acima disso, uma linha de justificativa na `description`. Cenários do mesmo
+   comportamento são linhas de tabela (`[Theory]`/`it.each`). **Nenhum teste que só fixa texto**
+   (copy, config, prosa). O `verify` avisa quando o teste adicionado passa de 1,5× a produção.
+
+   **Critério sobre saída de LLM vira eval de runtime — nunca "suíte estrutural".** Vale quando a seção
+   de contrato cita um standard `ai-agents` e o `doneCriteria` julga o que o modelo *responde*:
+   - a prova é um **eval de runtime**; a evidência vai em
      `.morph/features/{feature}/3-implement/evidencias/{taskId}.md`, e esse path entra em
      `outputs` — é por ele que implementador e avaliador sabem que ela é devida. Com nó
-     `runner: "evals"` (standard `ai-agents-evals-with-cache`), o cenário mora no dataset do nó
-     e a evidência aponta para ele;
-   - **no máximo 1 teste de estrutura** da fonte do prompt (chaves que o consumidor lê, ausência
-     da instrução revogada) — nunca vocabulário do que o modelo deveria dizer;
-   - escreva as duas coisas na `description` da task: é ela que chega ao sub-agente.
+     `runner: "evals"` (standard `ai-agents-evals-with-cache`), o cenário mora no dataset do nó;
+   - **no máximo 1 teste de estrutura** da fonte do prompt — nunca vocabulário do que o modelo
+     deveria dizer;
+   - as duas coisas vão na `description` da task.
 
-   Medido no acervo: 12 suítes, 106 testes de `Contains` sobre migrations de prompt — todos sobre
-   versões já superadas, verdes com qualquer resposta do modelo.
-
-   **5c. Cross-check do `1-design/` — todo aviso de capacidade tem destino.** Se o diretório existe,
-   rode antes de fechar o array `tasks`:
+   **5c. Cross-check do `1-design/` — todo aviso de capacidade tem destino.** Com o diretório
+   presente, antes de fechar o array `tasks`:
 
    ```bash
    grep -riE "capacidade nova|precisa de backend|dimensionar junto" .morph/features/{feature}/1-design/
    ```
 
-   Cada ocorrência é o designer dizendo que a tela pede algo que ainda não existe. Ela vira **task
-   irmã** no `tasks.json` **ou** exclusão registrada em `decisions.md` com o motivo — **nunca fica
-   sem destino**. Medido em campo: duas ocorrências dessas passaram batidas em features reais e
-   viraram trabalho descoberto na fase implement, quando o escopo já estava aprovado no Gate 2.
-   Sem hits, ou sem `1-design/`, o passo é um no-op silencioso.
+   Cada ocorrência vira **task irmã** ou exclusão registrada em `decisions.md` com o motivo —
+   **nunca fica sem destino**. Sem hits, ou sem `1-design/`, o passo é um no-op.
 
-   **5d. O checklist de tela vira critério.** Cada `## Tela:` do `1-design/mockups.md` traz o
-   `### Checklist de tela` (volume, paginação, ordenação, filtro, os três estados, mobile, abas).
-   A task que entrega a tela carrega essas decisões no `doneCriteria`, citando a seção do mockup
-   por path (`1-design/mockups.md#tela-…`) — "lista pagina no servidor, 25 por página" é critério;
-   "conforme o mockup" sozinho não é. É o que o implementador entrega e o que o avaliador confere
-   no Gate 3 (`morph-review` §4). Item marcado "não se aplica" não vira critério.
+   **5d. O checklist de tela vira critério.** A task que entrega uma `## Tela:` do
+   `1-design/mockups.md` carrega no `doneCriteria` as decisões do `### Checklist de tela` (volume,
+   paginação, ordenação, filtro, os três estados, mobile, abas), citando a seção por path
+   (`1-design/mockups.md#tela-…`) — "lista pagina no servidor, 25 por página" é critério; "conforme
+   o mockup" não é. Item "não se aplica" não vira critério.
 
-   Antes de retornar, valide rodando `morph-spec dag {feature}` — o comando parseia e valida o schema do tasks.json (ids únicos `T\d+`, enums de `status`/`effort`, `dependencies` válidas) e já imprime a análise de DAG que a `/morph-apply` vai usar. Erros de schema abortam com a lista do que corrigir.
+   Antes de retornar, valide rodando `morph-spec dag {feature}` — schema do tasks.json (ids, enums,
+   dependências) e a análise de DAG que a `/morph-apply` vai usar.
 
 6. Apresente o Gate 2 segundo trust mode.
 
-   Você pode embutir o diagrama do DAG do plano via `morph-spec dag {feature} --mermaid` (flowchart Mermaid) para visualização no gate.
-
-   Rode `morph-spec gate-check {feature} plan [--json]` — lê `trust` de `.morph/config/config.json`, conta `taskCount` do `tasks.json` (disco), decide via `shouldPauseGate` e persiste `gateDecisions.plan` com timestamp server-side (shape canônico em `.morph/framework/schemas/feature.schema.json`), imprimindo `pause`/`reason`/`signals`. É o default — não recompute a tabela do MORPH.md §5 em linguagem natural.
-
-   `gate-check` **não herda** `designSystemDivergence` do Gate 1 automaticamente — é recomputado a cada chamada. Se a divergência do Gate 1 segue sem resolução, ou o mandate introduziu uma violação de standard, repasse via `--signals` (as únicas chaves que este comando aceita sobrescrever):
+   Rode `morph-spec gate-check {feature} plan [--json]` — decide pelos sinais do disco e persiste
+   `gateDecisions.plan`. Divergência de design system do Gate 1 sem resolução, ou violação de
+   standard, entram por `--signals` (as únicas chaves aceitas):
    ```
    morph-spec gate-check {feature} plan --signals '{"designSystemDivergence":true,"standardsViolations":["<id>"]}'
    ```
+   Risco que nenhuma chave representa: `gate-decision` direto. Nunca edite `feature.json` à mão.
+   `morph-spec dag {feature} --mermaid` dá o diagrama do plano para o gate.
 
-   Risco que nenhuma dessas chaves representa (julgamento desta sessão, não fato de disco): use `gate-decision` direto em vez de `gate-check`.
-
-   **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 tomada (pausar vs auto-aprovar) bateu com a decisão persistida.
-
-   **Se `pause === true`**, use `AskUserQuestion`:
+   **Se `pause === true`**, `AskUserQuestion`:
 
    ```
    question: "Gate 2 — Plano de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
    header: "Gate 2"
    options:
-     - { label: "aprovado, prosseguir", description: "Aceitar spec/mandate/tasks e habilitar /morph-apply" }
+     - { label: "aprovado, prosseguir", description: "Aceitar use cases, spec e tasks e habilitar /morph-apply" }
      - { label: "preciso ajustar", description: "Apontar mudanças no plano antes de prosseguir" }
      - { label: "cancelar feature", description: "Abortar" }
    ```
 
-   Aguardar resposta. Se "preciso ajustar", aplicar e reapresentar.
+   **Se `pause === false`**: resumo de 3 linhas (problema → solução; tasks e esforço; caminho
+   crítico) e `morph-spec approve {feature} plan --mode auto` (ou `advance {feature}`). A pergunta
+   nomeia a feature — é por ela que o hook `state-sync` grava a aprovação.
 
-   **Se `pause === false`** (auto-aprovação), exibir summary curto:
-
-   ```
-   ## Gate 2 (auto-aprovado)
-
-   **Spec:** {1 frase} → {1 frase da solução}
-   **Mandate:** Stack: {stack} | Standards: {N obrigatórios} | Proibido: {N padrões}
-   **Tasks:** {N} | Esforço total: {soma} | Caminho crítico: {IDs sem deps paralelas}
-   ```
-
-   No caminho manual, o hook state-sync registra a aprovação automaticamente em answers de AskUserQuestion (grava o gate no `feature.json` autoritativo, `approvedBy: "manual"`) — **atribuindo pela feature nomeada na pergunta**; sem o nome, e com mais de uma feature na árvore, ele recusa a gravar e avisa (aprove então por `morph-spec approve {feature} plan`). Em auto sem AskUserQuestion, aprove via `morph-spec approve {feature} plan --mode auto` (ou `morph-spec advance {feature}` para já criar a pasta da próxima fase) — nunca via Edit à mão de state.json.
+   Aprovado o Gate 2, o frontmatter de cada use case passa de `status: draft` a `status: approved`.
+   O `finish` os promove ao acervo com `status: implemented`.
 
 ## Output esperado
 
-- `.morph/features/{feature}/2-plan/usecases/UC-{nn}-{slug}.md` — um arquivo por use case, com pós-condições testáveis
-- `.morph/features/{feature}/2-plan/spec.md` — especificação técnica completa, com a seção `UCs e ADRs que esta feature altera ou revoga` (passo 3)
-- `.morph/features/{feature}/2-plan/mandate.md` — contrato de implementação
-- `.morph/features/{feature}/2-plan/reuse-map.md` — veredito REUSAR/ESTENDER/CRIAR por conceito, com justificativa de uma linha em cada CRIAR (passo 1c)
-- `.morph/features/{feature}/2-plan/tasks.json` — task list estruturada válida contra schema, com o `doneCriteria` carregando a pós-condição literal e, por task, `agent`/`standards` carimbados a partir de `agents.json` (passo 5a) e, nas tasks de critério sobre saída de LLM, o path de `3-implement/evidencias/{taskId}.md` em `outputs` (passo 5)
-- Gate 2 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo)
-
-Ao registrar a aprovação do Gate 2, atualize o frontmatter de cada use case de `status: draft` para `status: approved`. O ciclo fecha na integração: `morph-spec finish` promove os use cases para o acervo permanente `.morph/specs/usecases/` já com `status: implemented` — até que uma feature posterior o revogue (passo 3) e ele passe a `status: superseded`, com `superseded_by` e, se parcial, `scope`. O status é **descritivo** — quem trava fase é o gate, não este campo.
+- `2-plan/usecases/UC-{nn}-{slug}.md` — pós-condições testáveis
+- `2-plan/spec.md` — arquitetura, seção de revogação e `## Contrato de implementação`
+- `2-plan/tasks.json` — válido contra o schema, `doneCriteria` literal, `agent`/`standards`/`reuse`
+  carimbados, `3-implement/evidencias/{taskId}.md` em `outputs` nas tasks de critério sobre LLM
+- Gate 2 registrado em `feature.json`
 
 ## Referências
 
-- `.morph/framework/MORPH.md` — seções 2 (Fases), 3 (Contratos de Output), 5 (Gates), Trust Mode
-- `morph-spec standards --find "<query>"` — para identificar standards relevantes ao mandate (o índice inteiro só como navegação exploratória; ver `morph-standards`)
-- `.morph/framework/agents.json` — personas por domínio; lido UMA VEZ no passo 5a para carimbar `agent`/`standards` por task
-- `.morph/framework/schemas/tasks.schema.json` — schema obrigatório de tasks.json
-- `morph-spec graph explain|affected --uses-only` — "isto já existe?" e "quem usa de verdade" (passo 1c); **sem grafo, o fallback é `grep -rn`**
-- `.morph/context/README.md` — inventário do projeto (entidades, endpoints, componentes com path); insumo declarado do passo 1c, atualizado por `morph-spec context refresh`
-- `.morph/specs/usecases/` — acervo permanente de use cases do projeto (`usecase reserve` já lê antes de numerar; em `bug`, é onde mora o UC a corrigir; `status: superseded` não é comportamento vigente)
-- `.morph/specs/adrs/` — índice dos ADRs que valem no projeto, um arquivo por ADR, mantido pelo `finish` (passo 1d); os `decisions.md` arquivados são história
-- `morph-spec usecase check {feature}` — o ciclo de vida do acervo contra esta feature (revogações do `spec.md`, task sobre UC `superseded`), antes do Gate 2
-- `.morph/features/{feature}/1-design/` — artefatos da fase uiux, insumo do passo 1 e do cross-check do passo 5c (ausente não é erro)
-- `.morph/features/{feature}/0-proposal/proposal.md` — escopo da feature
-- `.morph/features/{feature}/0-proposal/stack-scan.md` — contexto técnico detectado
-- `.morph/framework/schemas/tasks.schema.json` — schema e enums de tasks.json
-- `.morph/framework/standards/ai-agents/evals-with-cache.md` e `.morph/framework/standards/ai-agents/testing-ai.md` — o nó `runner: "evals"` e a fronteira eval × unit; insumos da regra de critério sobre saída de LLM (passo 5)
-- `morph-spec dag {feature}` — valida o tasks.json e imprime a análise de DAG
-- `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)
+- `.morph/framework/MORPH.md` — §2 (fases), §3 (contratos de output), §5 (gates)
+- `morph-spec standards --find|graph explain|graph affected --uses-only|usecase reserve|usecase check|dag` — `.morph/framework/CLI.md`
+- `.morph/framework/schemas/tasks.schema.json`