@polymorphism-tech/morph-spec 8.46.0 → 9.0.0

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

@@ -2,9 +2,9 @@
 name: morph-media
 description: Conduz a AUTORIA de mídia gerada por IA — escolher o modelo pelo trabalho, montar o prompt como spec versionada, encadear derivadas a partir de um herói aprovado, subir a escada de custo e conduzir o gate humano de escolha entre N candidatas. É o lado processo; o conhecimento de API, custo e conformidade vive nos standards de mídia.
 version: core
-when-to-invoke: quando a tarefa é PRODUZIR imagem ou vídeo por IA (catálogo, marketing, asset de LP) e alguém precisa decidir modelo, prompt e aprovação
-user-invokable: true
-cliVersion: "8.46.0"
+when_to_use: Use quando a tarefa for PRODUZIR imagem ou vídeo por IA (catálogo, marketing, asset de LP) e alguém precisar decidir modelo, prompt e aprovação
+user-invocable: true
+cliVersion: "9.0.0"
 stacks:
   - dotnet
   - nextjs

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

@@ -1,307 +1,145 @@
 ---
 name: morph-plan
-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.
+description: Leva uma feature do pedido ao plano aprovado — roteia o tipo de trabalho, varre o ambiente, conduz a entrevista pela árvore de decisões, escreve 2-plan/plan.md, extrai checks.json com plan-check e apresenta o gate do plano.
 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.46.0"
+when_to_use: Use quando uma feature, bug ou chore começar ("/morph-proposal {feature}", "vamos planejar X"), ou ao retomar uma feature cujo gate plan ainda não foi aprovado
+user-invocable: true
+cliVersion: "9.0.0"
 ---
 
 # morph-plan
 
-## Objetivo
-
-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
-
-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** (Read se
-   a sessão é fresca). Em brownfield, o stack-scan manda: não invente padrão que conflita com o
-   detectado.
-
-   **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:
-   ```
-   morph-spec scout-check .morph/features/{feature}/2-plan/scout-map.md --json
-   ```
-   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}
-
-   **Status:** Accepted
-   **Alcance:** projeto
-   ```
-
-2. **Destile os use cases — ANTES de escrever `spec.md` e `tasks.json`.**
-
-   Um arquivo por use case em `.morph/features/{feature}/2-plan/usecases/UC-{nn}-{slug}.md`:
-
-   ```markdown
-   ---
-   id: UC-07
-   title: Listar veterinários com suas especialidades
-   actor: Visitante
-   status: draft
-   entities: [Vet, Specialty]
-   ---
-
-   ## Pré-condições
-   - Existe ao menos um veterinário cadastrado
-
-   ## Cenário principal
-   1. Visitante acessa a listagem de veterinários
-   2. Sistema retorna os veterinários ordenados por sobrenome
-
-   ## 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
-
-   ## 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.** 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. 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: 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).
-
-   **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:** 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 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. |
-
-   **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 `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
-
-     | Id | Mudança | Substituto | Escopo em que o antigo ainda vale |
-     |---|---|---|---|
-     | UC-{nn} | parcial | UC-{nn} | {onde o antigo ainda vale} |
-     | {feature}/ADR-{nnn} | total | — | — |
-     ```
-
-     `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
-   {
-     "version": "1.0",
-     "feature": "{feature-name}",
-     "tasks": [
-       {
-         "id": "T1",
-         "title": "Título curto",
-         "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": ["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": "VetDto", "verdict": "CRIAR", "why": "graph explain VetDto → not-found; grep -rn VetDto → 0" }]
-       }
-     ]
-   }
-   ```
-
-   - `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ó;
-   - **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.
-
-   **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 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.** 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}` — 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.
-
-   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.
-
-   **Se `pause === true`**, `AskUserQuestion`:
-
-   ```
-   question: "Gate 2 — Plano de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
-   header: "Gate 2"
-   options:
-     - { 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" }
-   ```
-
-   **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.
-
-   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
-
-- `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` — §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`
+## 0. Contrato
+
+Saída: `.morph/features/{feature}/2-plan/plan.md` (fonte única da feature) e `2-plan/checks.json`, gravado só por `morph-spec plan-check`. O usuário só toca a entrevista e o gate; o resto você resolve. Nada de código nesta fase. O `create` escreve o esqueleto de `plan.md` no nascimento: só é retomada com `2-plan/checks.json` no disco ou com o `plan.md` já sem os `<…>` do esqueleto — aí vá ao §5 (corrigir) ou ao §7 (gate).
+
+## 1. Roteamento
+
+Sem nome de feature, pergunte (`AskUserQuestion`, header "Feature"). Feature que ainda não existe (sem `feature.json`), uma vez só:
+
+```
+morph-spec create {feature} --request "<pedido do usuário>"
+```
+
+Tipo óbvio pelo pedido: `--type <tipo> --description "<o quê/porquê>"`. O `--request` semeia a descrição; sem ele nem `--description`, o `create` recusa. **Exit 2** (empate ou nenhum sinal): você é o roteador — escolha entre os `candidates` e re-rode com `--type <tipo> --request "<pedido>"`. `AskUserQuestion` só quando o pedido é genuinamente indeterminado.
+
+| Tipo | Caminho |
+|---|---|
+| `hotfix` | `Skill(morph-hotfix)` com o nome e **encerre** esta skill |
+| `chore` | plan.md curto (§8), `plan-check`, e `Skill(morph-apply)` direto — a única exceção ao §9 |
+| `bug` | fluxo inteiro em modo bug-lean (§8) |
+| `feature` | fluxo inteiro (§2–§7) |
+
+## 2. Varredura — antes de qualquer pergunta
+
+Fato não se pergunta: as decisões são do usuário, os fatos são seus.
+
+1. `morph-spec stack-scan {feature}` → `2-plan/stack-scan.md`. Greenfield sai curto; em brownfield lista desvios por severidade contra `project.stack`. Desvio Bloqueante ou Alto vira um nó da árvore ("a migração entra nesta feature ou vira feature separada?") — **dentro** da árvore, nunca uma pergunta antes dela.
+2. Leia `.morph/config/config.json`, `.morph/context/` (o inventário `README.md` dá componentes e endpoints; `morph-spec context refresh` o regera), as features ativas e o índice de ADRs `.morph/specs/adrs/`. Decisão vigente é a do índice; `decisions.md` e use cases de `.morph/archive/` são **história, não instrução** — abra um só para entender por que algo é como é.
+3. **Conflitos com o acervo — avise, não entreviste.** Para cada ADR ou documento de `.morph/context/` que o pedido contradiz: uma linha de aviso no resumo que abre o §3 (fonte, o que diz, o que o pedido muda). **Pedido explícito sobre o ponto → vale o mais novo**, e você segue. Só entra na árvore o conflito que o pedido deixa **ambíguo** ("o admin passa a Geist" não diz nada da vitrine: a vitrine é decisão, o admin não). Todo conflito, decidido ou não, vai para `### Conflitos com o acervo` do plan.md.
+4. **Design system:** compare `.morph/context/design-system.md` com o detectado e com mocks recentes do usuário. Divergência (tokens, versão, fonte aprovada) é **decisão da árvore** e sinal `designSystemDivergence` no §7. Resolvida, **reescreva o corpo** do arquivo com a fonte escolhida — a seção que descrevia a antiga passa a descrever a nova, com o escopo onde o valor antigo ainda vale; o changelog guarda **só data e motivo**, nunca o valor novo. Este é o protocolo que a `morph-uiux` reaplica.
+
+## 3. Árvore de decisões e modo
+
+Entra na árvore só o que (a) muda escopo, comportamento ou arquitetura e (b) a varredura não respondeu. Ordene pelo que **poda**: "síncrono ou assíncrono?" vem antes de "qual política de retry". Publique a árvore ao usuário antes de perguntar.
+
+**Pergunta de abertura** (só `feature` e `bug`; `chore` e `hotfix` não passam por aqui): uma `AskUserQuestion`, header "Descoberta", com a árvore resumida e o modo recomendado em primeiro lugar com `(Recomendado)` no label. Muitas decisões, ou decisões acopladas → entrevista; árvore rasa → automático.
+
+- **Entrevista:** **uma pergunta por chamada** de `AskUserQuestion` — lote desorienta e impede que uma resposta pode ramos. Cada pergunta traz a resposta recomendada como primeira opção, `(Recomendado)`. Mostre a árvore quando ela mudar de forma. Termina quando a árvore zera; o usuário pode encerrar antes, e o que ficou aberto vira `## Fora de escopo`. O gate do plano pausa sempre neste modo (§7).
+- **Automático:** até 4 perguntas, **só sobre nós abertos** da árvore — nunca uma lista fixa. Árvore vazia → nenhuma pergunta.
+
+**Headless** (`AskUserQuestion` indisponível ou negada, como sob `claude -p`): nunca decida você os nós abertos. Escreva-os em texto, numerados, cada um com a resposta recomendada; rode `morph-spec gate-decision {feature} plan --pause true --reason "entrevista headless"` e **encerre o turno**. Retome quando o usuário responder.
+
+## 4. Território
+
+Feature grande ou brownfield: despache `subagent_type: "morph-scout"` (não registrado: `general-purpose` com o campo `persona` do `scout` de `.morph/framework/agents.json`) para os arquivos que a feature toca e o blast radius dos símbolos centrais. Grave em `2-plan/scout-map.md` e audite:
+
+```
+morph-spec scout-check .morph/features/{feature}/2-plan/scout-map.md --json
+```
+
+Exit ≠ 0 → descarte o mapa e re-despache **uma** vez com as `failures` coladas; segunda reprovação: grep você mesmo. 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 numa feature pequena no domínio carregado: uma linha em `## Arquitetura`.
+
+**Reuso — o que já existe.** Para cada conceito central (entidade, DTO, componente, hook, helper, dublê de teste): `morph-spec graph explain <nome> --json` e `morph-spec graph affected <nome> --uses-only --json`. Antes, `morph-spec graph status --json`; stale numa worktree → `morph-spec graph refresh`. `--uses-only` importa: o grep conta herança como uso — no ProspectPRO apontou 23 arquivos onde 20 eram interfaces filhas herdando o contrato e só 2 usavam de verdade. **Sem grafo** (`no-graph`, `not-found` num grafo stale), caia para `grep -rn "<nome>"` e registre que a contagem veio do grep, que superestima consumidores. A ausência de grafo nunca bloqueia.
+
+## 5. plan.md
+
+O `create` já escreveu o esqueleto em `2-plan/plan.md` (leia e preencha; `chore` e `hotfix` nascem com o gate carimbado e criam o arquivo numa única escrita); gramática completa: `morph-spec plan-check --help`. `plan-check` é o único leitor; o que ele não reconhece, ninguém lê.
+
+**Cenários** (`## Cenários`): `- **Cn** — Dado …, quando …, então …`, com `prova:` (`teste` | `e2e` | `eval` | `manual`) **na linha seguinte, sem linha em branco** — linha vazia encerra o cenário.
+- **Observável em teste**: que asserção eu escreveria? Sem resposta, reescreva ou descarte.
+- **Artefato não é comportamento.** Cenário que cita `grep`, "contém a string", "o binário", "nenhum arquivo", "arquivo/pasta/diretório em" ou glob `**/` descreve o repositório. Tente o efeito em runtime; se o artefato É o entregável, justifique em `> Por que artefato:` logo abaixo (nunca na mesma linha, nunca `> [!note]`).
+- **Saída de LLM** (o que o modelo responde) prova-se por `eval` de runtime, nunca pelo texto do prompt: evidência em `3-implement/evidencias/{Cn}.md`, path listado em `arquivos:` da fatia; com nó `runner: "evals"` (standard `ai-agents-evals-with-cache`) o cenário mora no dataset. No máximo 1 teste de estrutura da fonte do prompt.
+- **"O comando de teste da raiz roda de ponta a ponta"** prova-se pelo `verify {feature}` (o nó `e2e` e o nó de teste `e2e: true` já percorrem a cadeia): nomeie essa rodada como a prova, nunca uma execução avulsa. Precisando mesmo rodar fora dele, numa linha só (o Bash não guarda o env entre chamadas): `eval "$(morph-spec env {feature})" && morph-spec heavy run -- <comando>` — o `COMPOSE_PROJECT_NAME` da feature é o que o `finish` derruba com os volumes. `prova: manual` registra passo e resultado em `3-implement/evidencias/{Cn}.md`.
+- **Orçamento de teste**: um teste por cenário, um de regressão por bug; acima disso, uma linha de porquê. Cenários do mesmo comportamento são linhas de tabela (`[Theory]`/`it.each`); nenhum teste que só fixa texto. O `verify` avisa quando o teste passa de 1,5× a produção.
+
+```markdown
+## Cenários
+- **C1** — Dado um tenant com `criterion_overrides`, quando ele é publicado, então a publicação é recusada nomeando a chave.
+  prova: teste
+- **C2** — Nenhum arquivo em `tenants/**` contém a chave `criterion_overrides`.
+  prova: teste
+  > Por que artefato: a chave saiu do contrato; nenhum leitor de runtime a consulta.
+
+## Fatias
+### F1 — Recusar a chave na publicação
+- persona: dotnet-senior
+- standards: backend-dotnet-vsa-handler-patterns, backend-dotnet-testing, architecture-code-comments
+- arquivos: src/Tenants/Publish.cs, tests/Tenants/PublishTests.cs
+- cobre: C1, C2
+```
+
+**Decisões** (`## Decisões`): uma `### ADR-001 — título` por decisão não trivial (alternativa descartada, motivo, quem decidiu), com `**Alcance:** feature` ou `projeto` — `projeto` quando vale além desta feature. Em projeto greenfield, a decisão que fixa stack, layout, infraestrutura ou test runner é `projeto`: a próxima feature a herda, e só o índice de ADRs a mostra. `### Conflitos com o acervo` existe sempre; "nenhum" vale. Proibição além das de `MORPH.md` § "Stack baked-in" é ADR.
+
+**Arquitetura**: componentes, fluxo de dados, edge cases **técnicos** e integrações; não repita os cenários.
+
+**Reuso**: tabela `| conceito | veredito | alvo | why |`, veredito `REUSAR` | `ESTENDER` | `CRIAR`. **`CRIAR` exige `why`** — 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: símbolo novo homônimo de um existente reprova na mesma feature e avisa entre features; `CRIAR` declarado rebaixa a aviso. Conceito sem fatia que o escreva: falta fatia ou o conceito não é desta feature — resolva antes do gate.
+
+**Fatias** (`### Fn — título`): a unidade de entrega e de relatório (`3-implement/reports/Fn.md`).
+- `persona:` obrigatório — o id sem `morph-`, cujo `domains` cobre a fatia (uma leitura de `agents.json`). Fatia que cria ou altera UI é `ui-designer`, mesmo sem o ramo de design; com `superfície:`, os standards são os daquela chave de `surfaces`.
+- `standards:` — `morph-spec standards --find "<domínio>"` por domínio (o digest decide): os da persona mais o que a fatia exige, sempre `architecture-code-comments` e o de teste do stack; agente MAF soma `--category ai-agents`.
+- `arquivos:` — os paths planejados, testes incluídos, **no máximo 8**: acima disso o sub-agente bate no teto de turnos.
+- `depende:` opcional; `cobre:` lista os Cn — todo cenário é coberto por alguma fatia. Fatias sem `depende:` comum e sem arquivo em comum rodam em paralelo; o `plan-check` imprime as ondas.
+- Cenário que se observa por um artefato de outra fatia (rota, endpoint, componente que ela cria) faz da fatia que o cobre um `depende:` daquela — senão as duas caem na mesma onda e o teste do cenário não tem por onde provar. O `plan-check` não vê de quem é a rota: a regra é sua.
+
+**Contrato de implementação**: o que quem implementa precisa e o código não diz.
+- **Verificação de runtime:** o stack sobe por `morph-spec e2e up {feature}` (compose do projeto; sem compose, isso é uma fatia); os fluxos que o verificador navega, nos verbos dos cenários; base URL `process.env.PLAYWRIGHT_BASE_URL ?? \`http://localhost:${process.env.PORT ?? 3000}\``, compose com `"${PORT:-3000}:3000"` e sem `container_name` (standard `infrastructure/docker/local-compose-isolation`). 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. Biblioteca pura: registre a dispensa e o porquê.
+- **Baseline é um COMANDO, nunca um número.** O plano congela e é lido por dias: um número cravado está errado na primeira fatia, e quem confia nele "conserta" o que não quebrou. Registre como medir (`npm test`, `dotnet test`); o `expectedCount` sai de `morph-spec verify {feature} --record-baseline`, nunca digitado. Sem `project.stack`/`project.tests` no `config.json`, a `morph-apply` os declara a partir destes comandos antes do primeiro verify.
+- **Pré-requisito é um PREDICADO, nunca um SHA literal:** "`git merge-base --is-ancestor origin/main HEAD` sai 0" — o SHA muda no primeiro squash.
+
+Plano bom cabe em duas páginas; crescendo além, corte escopo. Feche com `morph-spec plan-check {feature}` até zero erro. Ele também recusa veredito de reuso fora do enum, id `C`/`F`/`ADR` duplicado, `## Errata` fora do fim, `## Cenários` vazio e fatia sem `persona:`; avisa chave de fatia desconhecida, superfície fora da `ui-designer`, ADR sem **Alcance**, fatia sem `cobre:` e mais de 12 fatias.
+
+## 6. Ramo de design
+
+Critério objetivo, decidido **uma vez**, aqui: a feature cria ou altera superfície de UI (componente, página, tela, estilo, fluxo de navegação)? Sim → `morph-spec advance {feature} --design`, sempre por ele e nunca criando `1-design/` à mão: no gate auto-aprovado ele aprova `plan`; com o gate já aprovado pelo humano, só abre o ramo. Nos dois casos escreve `1-design/mockups.md` do template e, se faltar, `.morph/context/design-system.md`. Depois, `Skill(morph-uiux)`. Não → `morph-spec advance {feature}` leva a implement. Ninguém redecide adiante.
+
+## 7. Gate do plano
+
+```
+morph-spec gate-check {feature} plan [--json]
+```
+
+Divergência de design system ou violação de standard que o disco não vê entram por `--signals '{"designSystemDivergence":true,"standardsViolations":["<id>"]}'` (as únicas chaves aceitas). **Modo entrevista** pausa sempre, e `shouldPauseGate` não conhece isso — registre direto: `morph-spec gate-decision {feature} plan --pause true --reason "modo entrevista — entendimento compartilhado" --signals '{"discoveryMode":"interview"}'`. Outro risco que nenhuma chave representa: `gate-decision` também. Nunca edite `feature.json` à mão.
+
+**`pause === true`**: apresente o entendimento compartilhado (problema, fora de escopo, cenários, fatias, riscos) e uma `AskUserQuestion`, header "Gate plano":
+
+```
+question: "Gate do plano — Plano de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
+options: "aprovado, prosseguir" | "preciso ajustar" | "cancelar feature"
+```
+
+A pergunta **nomeia a feature**: é por ela que o hook `state-sync` grava a aprovação; sem o nome, com mais de uma feature na árvore, ele recusa. O hook só aceita resposta que começa com "aprovado" ou contém "pode avançar", "pode implementar" ou "pode prosseguir" — "lgtm" não grava. Sem `AskUserQuestion` (headless): `morph-spec approve {feature} plan --approver <quem>`. "Preciso ajustar" → edite, `plan-check`, reapresente.
+
+**`pause === false`**: resumo de 3 linhas (problema → solução; fatias e ondas; risco principal) e `morph-spec advance {feature}` (ou `--design`, §6).
+
+**Congelamento:** aprovado o gate, o corpo do plan.md trava — fato errado sobre o código vai num bloco `## Errata` append-only no fim (não muda o `planHash`); `checks.json` só se regrava por `plan-check`. Mudança de escopo: `morph-spec unapprove {feature} plan`, editar, `plan-check`, reapresentar o gate.
+
+## 8. Deltas por tipo
+
+- **`bug` (bug-lean):** a varredura roda inteira; a árvore é de repro, diagnóstico e comportamento do sistema, não de negócio; no modo automático, no máximo 1 pergunta de repro, e só se o pedido não deixar claro. `## Problema` traz repro, diagnóstico e causa provável; os cenários são o sintoma ausente e a regressão; `### Conflitos com o acervo` continua presente.
+- **`chore`:** nasce com o gate `plan` carimbado por política. Escreva o plan.md curto numa única escrita (o gate já aprovado congela o arquivo depois de criado): `## Problema`, um ou dois cenários, `## Decisões` só com `### Conflitos com o acervo`, uma fatia. `plan-check` e `Skill(morph-apply)`.
+- **`hotfix`:** é da `morph-hotfix`.
+
+## 9. Encerramento
+
+Diga ao usuário: "Plano aprovado. Rode `/morph-apply {feature}` para implementar." Não despache a `morph-apply` — o usuário decide quando começar (exceção: `chore`).