@polymorphism-tech/morph-spec 9.7.0 → 10.0.0

package/framework/skills/core/morph-apply/references/review.md

@@ -0,0 +1,65 @@
+# Gate 3 — verificador ∥ revisor (∥ segurança)
+
+Pergunta: **cada cenário do plano funciona de verdade, sem quebrar o que já funcionava?** Três agentes em contexto fresco, cada um com o seu arquivo em `4-review/`. Você não escreve relatório de review (exceção: hotfix, `references/hotfix.md`).
+
+Por que fresco: o que você sabe da implementação é o ponto cego que eles existem para não herdar. Por isso cada um recebe **só** o que o papel precisa — nada do histórico desta conversa, nenhum relatório anterior.
+
+## 1. Relatórios já íntegros?
+
+`morph-spec report-check {feature} --json` (também ao retomar). `reviews.<papel>`: `complete` → não despache esse papel de novo; `partial` ou ausente → despache no passo 3.
+
+## 2. Prova da suíte — uma rodada
+
+Commite e rode `morph-spec verify {feature} --ci --json` em `run_in_background` (sem CI, roda local e diz por quê). Sem `--filter`, sempre: verde filtrado é verde sobre código não testado. `reason: "stamp-reused"` = nada andou desde o último verde: vale. Saída `CI rodando` → despache (passo 3) sem esperar o fim; `verify local` → espere, a máquina é uma só.
+
+Nó `e2e` `pass` → `morph-spec e2e status {feature} --json` → `baseUrl` vai ao verificador. `fail` → correção (CI: `gh run view <id> --log-failed`). `skip` → o `gate-check` decide se dispensa (`classifyE2eSkip`, em `risk-detector.js`: docker indisponível pausa sozinho, sem `gate-decision` à mão).
+
+## 3. Dispatch — os três na mesma resposta
+
+`morph-spec report-check {feature} --before-eval --json` tira a foto da árvore e diz `reviewModels.verifier.model` (opus com prompt/modelo ou mídia) e `reviewModels.security.required`. Anote `base` (merge-base com a default) e `sha` (`git rev-parse HEAD`). O revisor abre pela árvore do que mudou (`morph-spec graph diff --base {base} --json`, que ele mesmo roda). Blast radius para o revisor: por símbolo público do diff, `morph-spec graph affected <símbolo> --prod --json`; sem grafo (`no-graph`/`not-found`/`ambiguous`), diga isso a ele — ele cai para `git grep`.
+
+Despache **sem nome** no dispatch (com nome, o `agent_type` que o hook `test-budget` lê vira o nome e o guard não reconhece o papel). `chore`: só o revisor (∥ segurança).
+
+```
+Agent (subagent_type: "morph-verifier", model: {reviewModels.verifier.model}):
+  feature; o conteúdo de 2-plan/checks.json; baseUrl (ou "stack fora do ar: <motivo>");
+  reset entre fluxos: `morph-spec e2e reset {feature}`; 1-design/mockups.md se existir;
+  grave .morph/features/{feature}/4-review/verifier.md
+Agent (subagent_type: "morph-reviewer"):
+  feature, base, sha, blast radius (ou a ausência);
+  grave .morph/features/{feature}/4-review/reviewer.md
+Agent (subagent_type: "morph-security"):          ← só com security.required
+  feature, base, sha, reviewModels.security.reasons;
+  grave .morph/features/{feature}/4-review/security.md
+```
+
+O verificador **não** recebe plano, diff, `report.md` nem evidências: ele prova o comportamento executando, não lendo a sua versão dele. O contrato fixo de cada papel (formato, `**Reviewed-SHA:**`, read-only) está no corpo da persona e em `.morph/framework/evals/review-checklist.md`.
+
+## 4. Ao voltar
+
+Não rode build nem teste enquanto um agente está `running`. Com todos de volta, `morph-spec report-check {feature} --json`: `tree.sinceBeforeEval.changed` vazio = árvore como antes. Arquivo listado = alguém mexeu: desfaça pelo diff, **nunca `git checkout --`** (apaga o que não foi commitado).
+
+`partial` = o agente bateu no teto de turnos: despache o mesmo papel de novo dizendo o que já está no relatório (append-only).
+
+## 5. Bloqueadores
+
+O avaliador também erra: **reproduza cada bloqueador antes de editar**. Não se reproduz → é nota sua no `report.md`, e o próximo dispatch de confirmação recebe a contra-evidência. Confirmado → corrija, commite, `verify {feature}` local, foto `--before-eval` nova.
+
+Confirmação = **dispatch novo** de cada papel exigido, com o `sha` novo e o escopo da rodada: quem abriu bloqueadores confirma só esses (verificador: "confirme só C2, C5"); os outros julgam só o delta `{sha anterior}..{sha novo}`. `security.required` virou `true` agora → despache a segurança. Ninguém reavalia a feature inteira. O relatório é append-only e vale o último `**Verdict:**`; o `approve` recusa quando o código andou depois de qualquer `**Reviewed-SHA:**`.
+
+## 6. Gate 3
+
+`morph-spec gate-check {feature} review [--json]` lê os relatórios, a cobertura dos `Cn` e os demais sinais. Forçar passagem apesar da pausa: `morph-spec gate-decision {feature} review --pause false --reason "…"`.
+
+Pausa com `resolver: "session"` não é pergunta: faça o que a `reason` diz e rode o `gate-check` de novo. Verify vermelho ou velho → corrija e `verify {feature}`; e2e pulado a pedido → `verify {feature}` sem `--skip-e2e`; bloqueador ou `Cn` não provado → §5; relatório ausente ou sem seção → dispatch. Vira `human` sozinho depois de `FIX_ATTEMPTS` verify vermelhos seguidos ou rodadas de review: a disputa é do usuário.
+
+`resolver === "human"` → `AskUserQuestion`, header "Gate 3":
+
+```
+question: "Gate 3 — Review de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
+options: "aprovado, fechar feature" | "preciso ajustar" | "rollback"
+```
+
+Bloqueador `irreversivel` ou degrau (`rung`, `rung-undeclared`): a pergunta cita o trecho e o que fica depois do revert. "aprovado" é a aceitação do usuário e fecha pelo `approve` com o nome dele, com o bloqueador aberto; "preciso ajustar" → tire o efeito irreversível do diff e despache o revisor para confirmar.
+
+`pause === false` → uma linha (vereditos, cenários provados) e `morph-spec approve {feature} review --mode auto`. Fechar: `SKILL.md` §6.

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

@@ -1,147 +1,81 @@
 ---
 name: morph-plan
-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.
+description: Leva um pedido ao plano aprovado — roteia o tipo de trabalho, varre o ambiente, entrevista pela árvore de decisões, escreve 2-plan/plan.md com os cenários que definem "pronto", extrai checks.json com plan-check e apresenta o gate do plano.
 version: core
 when_to_use: Use quando uma feature, bug ou chore começar ("/morph-plan {feature}", "vamos planejar X"), ou ao retomar uma feature cujo gate plan ainda não foi aprovado
 user-invocable: true
-cliVersion: "9.7.0"
+cliVersion: "10.0.0"
 ---
 
 # morph-plan
 
-## 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).
+Saída: `2-plan/plan.md` (fonte única) e `2-plan/checks.json` (só o `plan-check` grava). Nada de código nesta fase. Retomada: com `checks.json` no disco, ou o `plan.md` já sem os `<…>` do esqueleto, vá ao §5 (corrigir) ou ao §6 (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.
+Sem nome, pergunte (`AskUserQuestion`, header "Feature"). Feature nova: `morph-spec create {feature} --request "<pedido>"` (tipo óbvio: `--type <t> --description "<o quê/porquê>"`). Exit 2 = você escolhe entre os `candidates` e re-roda com `--type`.
 
 | 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) |
+| `hotfix` | `Skill(morph-apply)` › `references/hotfix.md`; encerre esta skill |
+| `chore` | plano curto (§7), `plan-check`, `Skill(morph-apply)` direto |
+| `bug` | fluxo inteiro, bug-lean (§7) |
+| `feature` | fluxo inteiro |
+
+**Stack primeiro, completa.** `config.json` sem `project.stack` (ou `unknown`): antes de qualquer outra pergunta, `AskUserQuestion` header "Stack" com a recomendada sempre a **stack completa do Morph**, `dotnet+nextjs --with neon` (`morph-spec standards --show architecture-stack-baseline#a-stack`), mesmo que o pedido pareça caber em menos; recorte (`dotnet`, `nextjs`) ou outra tecnologia só como escolha explícita do usuário. Escolhida: `morph-spec stack-set <stack> --with <integrações>`, que grava o `config.json` e instala tudo o que a stack carrega (rules, commands, skills). Fora da stack do Morph: ADR `**Alcance:** projeto` em `## Decisões`.
 
 ## 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.
+1. `morph-spec stack-scan {feature}` — desvio Bloqueante/Alto contra `project.stack` vira nó da árvore.
+2. `.morph/config/config.json`, `.morph/context/` (o `README.md` inventaria componentes e endpoints), features ativas e o índice `.morph/specs/adrs/` (decisão vigente; `.morph/archive/` é história).
+3. **O código que a feature toca**: `morph-spec graph affected|explain <símbolo>` (stale numa worktree → `graph refresh`; sem grafo, `grep -rn`). Você vai implementar o que planejar: o que ler agora fica na sua janela.
+4. Pedido que contradiz ADR ou contexto: uma linha de aviso (fonte, o que diz, o que muda); pedido explícito sobre o ponto → vale o mais novo. Só o conflito ambíguo entra na árvore. Todos vão para `### Conflitos com o acervo`.
+5. Design system (`.morph/context/design-system.md`) divergente do código ou de mocks recentes → nó da árvore e sinal `designSystemDivergence`.
 
 ## 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:
+Entra na árvore só o que muda escopo, comportamento ou arquitetura e a varredura não respondeu, ordenado pelo que poda. Nó de baixo risco com resposta óbvia não vira pergunta: vira item de `## Padrões assumidos`. Publique a árvore antes de perguntar. Abertura (`feature`/`bug`): uma `AskUserQuestion`, header "Descoberta", modo recomendado primeiro — **entrevista** (uma pergunta por chamada até a árvore zerar; as respostas aprovam o plano) ou **automático** (até 4 perguntas, só nós abertos). Detalhe e headless: `references/interview.md`.
 
-```
-morph-spec scout-check .morph/features/{feature}/2-plan/scout-map.md --json
-```
+## 4. Reuso
 
-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.
+Por conceito central (entidade, DTO, componente, hook, helper): `morph-spec graph explain <nome> --json` e `graph affected <nome> --uses-only --json` (`--uses-only`: o grep conta herança como uso). Sem grafo, `grep -rn` e anote que a contagem veio do grep. O veredito vai na tabela `## Reuso`.
 
 ## 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` | `leitura`) **na linha seguinte, sem linha em branco** — linha vazia encerra o cenário.
-- **Teste é por risco, não por código novo.** `prova: teste` exige `risco:` (`regra` | `dinheiro` | `contrato` | `concorrência` | `dado` | `regressão`) na linha abaixo: ramo de regra de negócio, valor, contrato externo, corrida, integridade de dado ou o bug real. Sem risco (CRUD, DTO, mapping, wiring, constante, texto, layout) a prova é `leitura` — o verificador fecha citando `arquivo:linha` — ou `e2e` quando o fluxo é o que importa. O `plan-check` recusa `teste` sem `risco:`.
-- **Observável**: que asserção (ou que linha de código) prova? 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} --with-secrets)" && 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 de risco — o cenário é a unidade, nunca a pós-condição nem o componente; variantes são linhas de tabela (`[Theory]`/`it.each`); acima disso, o porquê na linha do cenário. Nenhum teste que só fixa texto, prompt ou constante, nenhum de DTO/mapping, e o mesmo comportamento numa camada só (handler **ou** endpoint). Teste além do orçamento é escopo para o revisor. O `verify` avisa quando o teste passa da 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
-  risco: contrato
-- **C2** — Nenhum arquivo em `tenants/**` contém a chave `criterion_overrides`.
-  prova: leitura
-  > 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`). Abstração nova (interface, base, factory, camada) soma ao `why` o segundo uso ou a próxima adição que ela barateia; sem isso é excesso (`architecture-engineering-lens#excess`). 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`, `architecture-engineering-lens` 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 cujo build é caro dentro do Docker sobe como processo do host por `e2e.hostServices` (compose só com as dependências; campos em `morph-spec e2e --help`). 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.
+O `create` escreveu o esqueleto; a gramática completa chega pela rule `plan-grammar` quando você abre o `plan.md`; o resto em `morph-spec plan-check --help`. O que importa:
 
-## 6. Ramo de design
+- **`## Cenários` é a definição de pronto.** Cada `Cn` é um comportamento observável que o verificador do Gate 3 vai **executar** contra a app — escreva-o como um fluxo de usuário ou uma regra que dá para disparar. `prova:` `teste` (com `risco:`) | `e2e` | `eval` | `manual` | `leitura`. Sem risco, `leitura`.
+- **`degrau:`** quando o `Cn` não se desfaz com revert: `migrar` (toda migration, aditiva ou não: drop, rename, backfill, coluna nova) ou `irreversível` (apaga dado que alguém lê, quebra contrato externo). Sem a linha, `refazer`. Esses dois degraus pausam o gate do plano para o usuário, e o Gate 3 pausa em migration sem degrau, em arquivo de contrato (`openapi`, `.proto`) sem `irreversível`, e no bloqueador `irreversivel` do revisor.
+- **`## Padrões assumidos`**: todo valor de baixo risco que você decidiu sem perguntar, numerado `1.`…`N.`, com o valor. É o que tira a pergunta trivial da entrevista: o usuário veta por número. Auth, credencial, permissão, pagamento e apagar dado nunca entram: são pergunta.
+- **`## Estados`** (opcional): algo muda de estado (pedido, aprovação) → `- origem → destino: gatilho`, uma por linha; o `plan-check` desenha a máquina no `2-plan/plan.html`.
+- **`## Reuso`**: `REUSAR` | `ESTENDER` | `CRIAR`; `CRIAR` exige `why` (a consulta que respondeu "não existe").
+- **`## Decisões`**: ADR por decisão não trivial, `**Alcance:** feature|projeto`; `### Conflitos com o acervo` sempre.
+- **`## Arquitetura`**: onde entra, o que conversa com o quê, edge cases técnicos. Gera imagem ou vídeo por IA → cite aqui o standard (`ai-agents-modalities-image-gen`, `ai-agents-media-video`, `ai-agents-media-pipeline`): é a citação que arma as provas de mídia do Gate 3, e o `plan-check` recusa o plano que fala em mídia gerada sem ela (falso positivo: a linha `Mídia gerada: não`).
 
-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.
+**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}`: app sem dependência (dados no `localStorage`, só APIs externas) sobe só por `e2e.hostServices` (build + start + health, sem compose); com dependência (banco, fila) o compose do projeto sobe ela, e criá-lo entra no plano; 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 de build caro no Docker também sobe como processo do host por `e2e.hostServices`, ao lado do compose das dependências. Login: `e2e.auth` (`mode: seed|storageState|bypass|none`, `seedCommand`, credenciais num `.env.e2e` gitignored) — **`mode` é obrigatório sempre que houver `seedCommand`**, sem ele o seed fica inerte. Estado limpo entre fluxos: o `e2e reset` recria os volumes de dados do stack da feature (`morph-{f}_*`); volume com `name:` fixo é compartilhado com o stack de desenvolvimento, e aí o reset recusa até existir `e2e.resetCommand`. Biblioteca pura: registre a dispensa e o porquê.
+- **Baseline é um COMANDO, nunca um número** (`npm test`, `dotnet test`): número cravado está errado na primeira mudança. `expectedCount` (só `node-test`/`evals`) 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.
+- **Pré-requisito é um PREDICADO, nunca um SHA literal:** "`git merge-base --is-ancestor origin/main HEAD` sai 0".
 
-**`pause === true`**: apresente o entendimento compartilhado (problema, fora de escopo, cenários, fatias, riscos) e uma `AskUserQuestion`, header "Gate plano":
+Plano bom cabe em duas páginas. `morph-spec plan-check {feature}` até zero erro.
 
-```
-question: "Gate do plano — Plano de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
-options: "aprovado, prosseguir" | "preciso ajustar" | "cancelar feature"
-```
+## 6. Ramo de design e gate
 
-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.
+Cria ou altera UI → `morph-spec advance {feature} --design` (sempre por ele, nunca criando `1-design/` à mão: o `--design` semeia o `mockups.md`) e `Skill(morph-uiux)` depois do gate; senão `advance {feature}` leva a implement. Decidido uma vez, aqui.
 
-**`pause === false`**: resumo de 3 linhas (problema → solução; fatias e ondas; risco principal) e `morph-spec advance {feature}` (ou `--design`, §6).
+Antes do gate, em `feature` e `bug`: a crítica em contexto fresco de `references/critique.md` (o `gate-check` cobra o `2-plan/critica.md` do plano atual).
 
-**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.
+`morph-spec gate-check {feature} plan [--json]`. Entrevista que zerou a árvore já é a aprovação do usuário: não repause, salvo a pausa de `signal: "rung"`, que vence e pergunta nomeando cada `Cn` e o seu degrau. Encerrada antes, com nós em `## Fora de escopo`: `morph-spec gate-decision {feature} plan --pause true --reason "entrevista encerrada com nós abertos" --signals '{"discoveryMode":"interview"}'`, e a pergunta do gate lista esses nós.
 
-## 8. Deltas por tipo
+- `resolver === "session"` (`plan-check` com erro, crítica ausente ou de outra versão) → corrija o plano ou despache a crítica, e rode `plan-check` e `gate-check` de novo, sem perguntar.
+- `resolver === "human"` → abra `2-plan/plan.html` no navegador do usuário (`start`/`open`/`xdg-open`; o `plan-check` o gera), o entendimento (problema, fora de escopo, cenários, riscos) e `AskUserQuestion`, header "Gate plano": `"Gate do plano — Plano de {feature} aprovado?"` com `"aprovado, prosseguir" | "preciso ajustar" | "cancelar feature"`; a pergunta lista `## Padrões assumidos` para veto por número; só a decisão sensível que você tomou sozinho vira pergunta antes, na forma de `references/interview.md` (`## Forma da pergunta`). Headless: `morph-spec approve {feature} plan --approver <quem>`.
+- `pause === false` → uma linha e `morph-spec advance {feature}` (ou `--design`).
 
-- **`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; um cenário é o sintoma ausente com `prova: teste` e `risco: regressão` (o `plan-check` recusa bug sem ele) — esse é o teste que fica; `### 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`.
+Aprovado: "Plano aprovado. Rode `/morph-apply {feature}`.", seguido de `## Padrões assumidos` numerado e "veta N antes do /morph-apply". Veto → `## Errata` com "Padrão N vetado: <valor novo>"; a implementação segue a errata. Não comece a implementar (exceção: `chore`). Rodou `stack-set` nesta sessão: "…numa sessão nova", porque as rules de domínio só carregam no início de uma sessão.
 
-## 9. Encerramento
+## 7. Deltas por tipo
 
-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`).
+- **bug:** árvore de repro e diagnóstico; `## Problema` com repro e causa provável; um `Cn` é o sintoma ausente com `prova: teste` e `risco: regressão`.
+- **chore:** nasce com o gate carimbado — `plan.md` numa única escrita (o arquivo congela ao nascer): `## Problema`, um ou dois cenários, `### Conflitos com o acervo`.

package/framework/skills/core/morph-plan/references/critique.md

@@ -0,0 +1,40 @@
+# Crítica do plano em contexto fresco
+
+Depois do `plan-check` verde e antes do `gate-check {feature} plan`, em `feature` e `bug` (chore e hotfix pulam). Quem planejou não enxerga a premissa que ele mesmo assumiu: um leitor que nunca viu a conversa enxerga. Gaste esse agente antes de gastar a atenção do usuário.
+
+## Dispatch
+
+`Agent`, `subagent_type: "Plan"` (nativo, sem Edit/Write), em contexto fresco. O prompt leva só:
+
+- o caminho do `2-plan/plan.md` e o `planHash` de `2-plan/checks.json`;
+- a missão e o formato abaixo, literais.
+
+Nunca a conversa, as respostas da entrevista nem o seu resumo do plano: o crítico lê o plano como o verificador vai ler.
+
+> Leia `{plano}` e o código do repositório. Procure só o que um `grep` ou uma leitura confirma, com `arquivo:linha`:
+> `premissa` (o plano afirma algo do código que o código desmente: arquivo, símbolo, contagem, flag);
+> `contradicao` (duas partes do plano se negam);
+> `decisao` (o plano escolhe um valor ou um caminho sem dizer, e o usuário pode querer outro);
+> `cenario` (um `Cn` que nenhuma asserção ou passo no navegador consegue provar).
+> Estilo, nome e "eu faria diferente" não entram. Sem achado, escreva "Nenhum achado.".
+> Grave, pelo Bash, só `{feature}/2-plan/critica.md`, nesta forma, e não toque em mais nada:
+>
+> ```markdown
+> # Crítica — {feature}
+>
+> **Plan-Hash:** {planHash}
+>
+> | id | tipo | onde no plano | evidência |
+> |----|------|---------------|-----------|
+> | K1 | premissa | F1 lista 4 arquivos | `grep -rl X tests/` → 57 arquivos |
+> ```
+
+Leia o `critica.md`, não a mensagem final do agente.
+
+## O que fazer com cada achado
+
+- `premissa`, `contradicao`, `cenario` → corrija o plano você mesmo.
+- `decisao` de baixo risco → novo item de `## Padrões assumidos`.
+- `decisao` sensível (auth, credencial, permissão, pagamento, apagar dado) → pergunta ao usuário na forma de `references/interview.md` (`## Forma da pergunta`).
+
+Mudou o plano: `plan-check` de novo e acrescente ao fim do `critica.md` `**Aplicado-em:** <planHash novo do checks.json>`. A crítica vale para o plano que leu e para o plano onde foi aplicada; uma mudança depois disso pede outro `**Aplicado-em:**`, nunca outra crítica.

package/framework/skills/core/morph-plan/references/interview.md

@@ -0,0 +1,25 @@
+# Entrevista e modos de descoberta
+
+## Árvore
+
+Só entra o que (a) muda escopo, comportamento ou arquitetura e (b) a varredura não respondeu. Ordene pelo que **poda**: "síncrono ou assíncrono?" antes de "qual política de retry". Publique a árvore ao usuário antes de perguntar, e de novo quando ela mudar de forma.
+
+## Pergunta de abertura (só feature e bug)
+
+Uma `AskUserQuestion`, header "Descoberta", com a árvore resumida e o modo recomendado primeiro (`(Recomendado)` no label). Muitas decisões ou decisões acopladas → entrevista; árvore rasa → automático.
+
+- **Entrevista:** uma pergunta por chamada — lote impede que uma resposta pode os ramos seguintes. Cada pergunta traz a resposta recomendada primeiro. Termina quando a árvore zera; o usuário pode encerrar antes, e o que ficou aberto vira `## Fora de escopo`. Árvore zerada: as respostas aprovam o plano e o gate não repausa. Encerrada antes: o gate pausa e mostra o que foi cortado.
+- **Automático:** até 4 perguntas, só sobre nós abertos. Árvore vazia → nenhuma pergunta.
+
+## Forma da pergunta
+
+Vale para a entrevista, o automático e o gate do plano.
+
+- **Negócio, não código:** a pergunta fala de pessoas, telas e números do usuário ("quem vira dono do card?"), nunca de arquivo ou função. `Cn`, ADR e fatia ficam no `plan.md`.
+- **Efeito à vista:** opção que muda algo visível ou um dado leva `preview` (ASCII, até ~12 linhas) com o efeito num exemplo concreto: nomes, contagem antes → depois, o card duplicado marcado `✖`. Opção sem efeito visível dispensa.
+- **Recomendada primeiro**, com `(Recomendado)` no label; a description diz o custo da alternativa em uma frase.
+- Comentário do usuário chega pelas notas da opção: leia-as antes de seguir.
+
+## Headless
+
+`AskUserQuestion` indisponível ou negada (`claude -p`): nunca decida você os nós abertos. Escreva-os em texto, numerados, cada um com a resposta recomendada; `morph-spec gate-decision {feature} plan --pause true --reason "entrevista headless"` e encerre o turno. Retome quando o usuário responder.

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

@@ -1,103 +1,86 @@
 ---
 name: morph-uiux
-description: Conduz a fase opcional de UI/UX de uma feature com plano aprovado — design system, mockups com checklist de tela, componentes e fluxos — despachando a persona ui-designer, e apresenta o Gate uiux antes da implementação.
+description: Conduz a fase de UI/UX de uma feature com plano aprovado — renderiza 2-3 opções navegáveis por tela, abre no navegador para o usuário escolher, refina a escolhida em protótipo com prints 1280/390, preenche o checklist de tela e apresenta o Gate uiux.
 version: core
-when_to_use: Use quando o ramo de design for tomado (morph-spec advance {feature} --design, depois do gate do plano) e antes de /morph-apply
+when_to_use: Use quando o ramo de design for tomado (morph-spec advance {feature} --design), antes de /morph-apply
 user-invocable: true
-cliVersion: "9.7.0"
+cliVersion: "10.0.0"
 ---
 
 # morph-uiux
 
-Entra depois do gate do plano, quando a `morph-plan` §6 decidiu que a feature cria ou altera superfície de UI (componente, página, tela, estilo, fluxo de navegação). Sai com `1-design/` aprovado; o próximo passo é `/morph-apply {feature}`.
+Entra depois do gate do plano, quando a feature cria ou altera UI. Sai com `1-design/` aprovado; próximo passo `/morph-apply {feature}`. Você desenha nesta sessão — o que decidir aqui é o que vai implementar depois.
+
+A régua de sistema e de estética chega sozinha: a rule `ui-design` carrega quando você abre um arquivo de `1-design/` ou de UI. Carregue `frontend-design:frontend-design` se a sessão a tiver.
 
 ## 1. Insumos
 
-- `2-plan/plan.md` — problema, cenários e as fatias de UI (`persona: ui-designer`, com `superfície:`). O plano está congelado: esta fase **nunca** edita `plan.md` nem `checks.json`; refere as fatias pelo id (`F2`).
-- `.morph/context/design-system.md` — o design system **vivo**: toda decisão de token ou componente parte dele. Ausente, o `advance --design` já o escreveu a partir do template do pacote como forma de partida.
-- `.morph/config/config.json` → `project.stack` decide a tecnologia (`nextjs` → Tailwind + shadcn + Framer Motion; outro stack, o equivalente idiomático). Nunca suponha Next.js.
-- `2-plan/stack-scan.md`, se existir.
+- `2-plan/plan.md` — problema e cenários de tela, referidos pelo id (`C3`). Esta fase **nunca** edita `plan.md` nem `checks.json`.
+- `.morph/context/design-system.md` — o design system vivo; toda decisão de token ou componente parte dele e dos tokens reais do CSS do projeto.
+- `config.json` → `project.stack` decide a tecnologia (`nextjs` → Tailwind + shadcn + Motion). Nunca suponha Next.js.
+- A superfície de cada tela (`marketing-site` | `admin-app` | `brand-moment`, em `surfaces.json`) diz quais standards abrir.
 
-## 2. Princípios (não são opcionais)
+## 2. Opções — o usuário escolhe vendo, não lendo
 
-- WCAG AA e todos os estados de componente interativo (default/hover/focus/disabled/loading/error), não só o caminho feliz.
-- Reusa token e componente existentes antes de criar; token novo precisa de justificativa. Sistemas, não telas isoladas.
-- Tarefa principal da tela em até 3 interações, uma ação primária por tela, voltar/cancelar sempre à vista. Erro diz o que fazer a seguir; conteúdo gerado por IA aparece marcado como tal.
-- **Toda tela sai com o checklist de tela preenchido.** O `advance --design` já escreveu `1-design/mockups.md` a partir do template do pacote, a fonte única dos dez itens (tabela `### Checklist de tela` dentro de cada `## Tela:`). "Não se aplica" vale se escrito; `…`, vazio ou "a definir" reprovam. Design sem tela nova ou alterada (só componente ou estilo): apague o `1-design/mockups.md` semeado. É o checklist que faz a lista de 2 000 linhas paginar: o verificador do Gate 3 cobra cada item decidido em `## Checklist de tela`. Tela de dados segue os standards de `admin-app` (lista/tabela, formulário, feedback, estrutura de página); login, onboarding, primeira tela, estado vazio de destaque e sucesso são `brand-moment`.
-- **Conformidade não basta: a régua estética vale junto.** Direção escrita antes de componente (`1-design/direcao.md`: conceito, metáfora, o que torna a tela memorável, o que ela não pode parecer; 2 ou 3 direções para tela nova ou momento de marca), celular desenhado e não derivado, movimento com versão estática digna. A régua é o standard `frontend-design-system-art-direction`.
-- **Toda tela nova ou alterada tem protótipo renderizado e conferido por print.** `1-design/prototipos/{tela}.html` autossuficiente, com os tokens reais do projeto (lidos do CSS de tokens), desktop e celular lado a lado, controles animado/estático/pausar; prints `{tela}-1280.png` e `{tela}-390.png` ao lado, saídos do laço de autocrítica. A `## Tela:` aponta o protótipo na linha `**Protótipo:**`.
+Para cada tela nova ou alterada, `1-design/opcoes/{tela}.html`: **uma página com 2 ou 3 direções distintas**, alternáveis por abas, cada uma com:
 
-## 3. Dispatch
+- o conceito em uma frase e o que a torna memorável, no topo da aba;
+- desktop (1280) e celular (390) lado a lado em moldura de aparelho, com conteúdo realista (nunca lorem ipsum nem métrica inventada);
+- controles animado/estático; `prefers-reduced-motion` respeitado;
+- os tokens reais do projeto; uma direção pode propor tokens novos, marcados como tal.
 
-Despache `subagent_type: "morph-ui-designer"` — persona universal, registrada em todo projeto. Não registrado (instalação antiga): `general-purpose` com o campo `persona` de `.morph/framework/agents.json` colado no prompt, registrando o fallback; resolve com `morph-spec setup-infra --reinstall`. O corpo da persona já carrega o contrato fixo (teto de turnos, relatório `PARCIAL`); o prompt leva só o que varia:
+Direções genuinamente diferentes (layout, hierarquia, densidade, tom), não três variações de cor. Sirva a pasta por HTTP (`npx http-server 1-design -p <porta>` em background), **abra no navegador do usuário** (`start` no Windows, `open` no macOS, `xdg-open` no Linux) e pergunte:
 
 ```
-Feature [feature]: artefatos de UI/UX em `.morph/features/[feature]/1-design/`.
-Plano: `2-plan/plan.md` — fatias de UI [F2 (admin-app), F3 …]. Stack: [project.stack].
-Design system: `.morph/context/design-system.md` (tokens e componentes a reusar).
-
-Nesta ordem, só o aplicável ao escopo:
-1. `1-design/direcao.md` — antes de qualquer componente: conceito em uma frase, metáfora visual,
-   o que torna a tela memorável, o que ela NÃO pode parecer. Tela nova ou momento de marca:
-   2 ou 3 direções distintas, uma recomendada com o porquê (standard `frontend-design-system-art-direction`).
-2. `1-design/design-system.md` (obrigatório: sem ele o `advance` recusa) — tokens (cor, tipografia, espaço, motion) que a feature usa ou acrescenta, lidos do CSS de tokens real do projeto; token novo também reescreve `.morph/context/design-system.md` (§4).
-3. `1-design/prototipos/{tela}.html` por tela nova ou alterada — autossuficiente, tokens reais,
-   desktop e celular (folha inferior, zona do polegar, 44px) lado a lado em moldura de aparelho,
-   controles animado/estático/pausar e `prefers-reduced-motion`. Laço de autocrítica: sirva a pasta
-   por HTTP local (o Playwright MCP recusa `file:`), print em 1280 e em 390 (`{tela}-1280.png`,
-   `{tela}-390.png` ao lado do HTML), avalie (hierarquia, contraste, ritmo, celular, "parece template?"),
-   corrija e repita até passar.
-4. `mockups.md` — um `## Tela: <nome>` por tela nova ou alterada, com a fatia que a entrega, a linha
-   `**Protótipo:** 1-design/prototipos/{tela}.html` e a tabela `### Checklist de tela` que o
-   `advance --design` já escreveu em `1-design/mockups.md`, cada item decidido.
-5. `components.md` — componentes novos e reusados, com props e estados.
-6. `flows.md` — navegação entre as telas.
-
-Relatório por artefato em `1-design/reports/[artefato]-report.md`: o que foi feito (2-3 frases),
-o artefato, as decisões de design e por quê, o que ficou aberto; o do protótipo lista as rodadas
-do laço e o que cada uma corrigiu. É o retorno; a mensagem final é cortesia.
-Bash só para consulta (`morph-spec standards --find`, `npx`, screenshot, `git log/diff`) e para o
-servidor estático do protótipo (`npx http-server <pasta> -p <porta>` em background; ao fim, encerre
-esse processo pelo id do background ou pelo PID dono da porta, nunca por nome de executável):
-sem build, teste, `verify`, `approve` ou `advance`.
-Não toque `feature.json`, `state.json`, `plan.md` nem `checks.json`.
+AskUserQuestion — header "Direção", question: "Qual direção para {tela}?"
+options: uma por direção (nome curto + o conceito) — a sua recomendação primeiro, com "(Recomendado)"
 ```
 
-Ao retomar, **leia primeiro** `1-design/reports/*-report.md`. `design-system.md` é o único output obrigatório: sem ele, o `advance` recusa.
+"Outra" com comentário → ajuste a página e pergunte de novo. Componente ou estilo sem tela nova: pule para o §3 com uma opção só.
 
-## 4. Design system vivo
+## 3. Protótipo da escolhida
 
-Tokens ou componentes novos: aplique o protocolo da `morph-plan` §2 — **reescreva o corpo** de `.morph/context/design-system.md` (o valor que mudou substitui o antigo na própria seção) e registre no changelog só data e motivo. `1-design/design-system.md` é da feature; `.morph/context/design-system.md` é do projeto.
+`1-design/prototipos/{tela}.html` refina a direção escolhida até o nível de entrega: todos os estados (vazio, carregando, erro, sucesso), foco visível, alvos de 44px no celular. **Seletor de estado** no topo do protótipo: um botão por estado com `data-estado="vazio|carregando|erro"`, e o mesmo estado abre por `?estado=<nome>` na URL — o usuário vê cada estado num clique, sem ler. **Laço de autocrítica:** print em 1280 e em 390 pelo Playwright MCP (ele recusa `file:` — use a URL HTTP), salvos como `{tela}-1280.png` e `{tela}-390.png` ao lado do HTML, mais `{tela}-{estado}-390.png` de cada estado que o checklist diz que se aplica (vazio e carregando pelo item "Estados", erro pelo item "Erro"; "não se aplica" dispensa) — o gate uiux confere o `data-estado` e os prints; avalie (hierarquia, contraste AA, ritmo, celular, "parece template?"), corrija, repita até passar. Ao terminar, encerre o servidor pelo id do background ou pelo PID da porta, nunca por nome de executável.
 
-## 5. Todo aviso de capacidade tem destino
+## 4. mockups.md
 
-Antes do gate:
+O `advance --design` já escreveu `1-design/mockups.md` a partir do template — a tabela do checklist mora lá, não copie. Por tela, um `## Tela: <nome>` com:
 
-```bash
-grep -riE "capacidade nova|precisa de backend|dimensionar junto" .morph/features/{feature}/1-design/
-```
+- `**Protótipo:** 1-design/prototipos/{tela}.html` e `**Direção escolhida:**` (qual opção e por quê, numa frase);
+- o `### Checklist de tela` com cada item decidido (`não se aplica` vale se escrito; vazio ou "a definir" reprova);
+- `### Componentes` (novos e reusados, com props e estados) e `### Fluxo` (de onde vem, para onde vai).
+
+Sem tela nova ou alterada: apague o `mockups.md` semeado.
+
+## 5. Design system vivo
+
+Token ou componente novo aprovado: **reescreva o corpo** de `.morph/context/design-system.md` (o valor novo substitui o antigo na própria seção); o changelog guarda só data e motivo.
 
-Cada ocorrência **nunca fica sem destino**: a fatia do plano que já a cobre (cite o id no mockup), uma exclusão registrada no `mockups.md` com o motivo, ou — se é escopo novo — `morph-spec unapprove {feature} plan`, ajuste do plan.md, `morph-spec plan-check {feature}` e o gate do plano de novo. Sem hits, o passo é um no-op.
+## 6. Destino de toda capacidade nova
 
-## 6. Gate uiux
+Uma tela que pede algo que o plano não tem (endpoint, campo, permissão) **nunca fica sem destino**. Antes do gate, varra o que você escreveu:
 
 ```
-morph-spec gate-check {feature} uiux [--json]
+grep -riE "capacidade nova|precisa de backend|dimensionar junto" .morph/features/{feature}/1-design/
 ```
 
-O checklist é cobrado por código: tela sem a tabela, item ausente ou não decidido, ou nenhuma `## Tela:` **pausa** o gate nomeando tela e item, e `approve`/`advance` com assinatura `auto` recusam pela mesma regra (só o mockup antigo, telas `## S001:`, é isento). Com o checklist completo, cada tela ainda deve o protótipo: sem a linha `**Protótipo:**`, o HTML ou um dos prints de 1280/390, o gate **pausa** nomeando a tela e o arquivo. Complete o mockup antes de apresentar: não peça aprovação de um design que ainda não decidiu se a lista pagina, nem de um que ninguém renderizou.
+Cada ocorrência vai para o `Cn` do plano que já a cobre, para uma exclusão registrada no `mockups.md`, ou — escopo novo — `morph-spec unapprove {feature} plan`, ajuste, `plan-check` e o gate de novo.
+
+## 7. Gate uiux
+
+`morph-spec gate-check {feature} uiux [--json]` cobra por código: tela sem checklist completo, sem `**Protótipo:**`, sem o HTML ou sem os dois prints pausa nomeando o que falta. Complete antes de pedir aprovação.
 
-**Apresente o design aberto, não descrito.** Antes da pergunta do gate, abra cada protótipo no navegador do usuário (sirva `1-design/prototipos/` por HTTP local e abra a URL: `start` no Windows, `open` no macOS, `xdg-open` no Linux) e cite a direção escolhida de `direcao.md` em uma frase. Divergência de design system vista aqui: `--signals '{"designSystemDivergence":true}'`.
+Apresente aberto, não descrito: abra cada protótipo no navegador e cite a direção de cada tela em uma frase. Divergência de design system vista aqui: `--signals '{"designSystemDivergence":true}'`.
 
-**`pause === true`**: `AskUserQuestion`, header "Gate uiux":
+Pausa com `resolver: "session"` não é pergunta: faça o que a `reason` diz e rode o `gate-check` de novo. Checklist ou protótipo incompleto → complete-o. Sem como completar (sem navegador para os prints): `morph-spec gate-decision {feature} uiux --pause true --reason "<o que falta>"`, pausa manual, que é do usuário.
+
+`resolver === "human"` → `AskUserQuestion`, header "Gate uiux":
 
 ```
 question: "Gate uiux — Design de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
 options: "aprovado, prosseguir" | "preciso ajustar" | "cancelar feature"
 ```
 
-O hook `state-sync` reconhece "Gate uiux" e grava a aprovação pela feature nomeada. Sem `AskUserQuestion` (headless): `morph-spec advance {feature} --approver <quem>` — sem `--approver`, um terminal não interativo grava `approvedBy: "auto"` num gate que um humano aprovou.
-
-**`pause === false`**: resumo (tokens novos, N telas, componentes novos/reusados, fluxos) e `morph-spec advance {feature}`.
+O hook `state-sync` grava a aprovação pela feature nomeada. Headless: `morph-spec advance {feature} --approver <quem>` — sem `--approver`, um terminal não interativo grava `approvedBy: "auto"` num gate que um humano devia assinar. `pause === false` → uma linha e `morph-spec advance {feature}`.
 
-Aprovado o gate, os quatro artefatos de `1-design/` travam: retrabalho de design passa pelo gate de novo, nunca por Edit no arquivo travado. Diga ao usuário que `/morph-apply {feature}` está pronto; não despache a apply.
+Aprovado, `1-design/` trava: retrabalho passa pelo gate de novo. Diga que `/morph-apply {feature}` está pronto.

package/framework/skills/core/morph-uiux/surfaces.json

@@ -0,0 +1,32 @@
+{
+  "marketing-site": {
+    "when": "site de marketing: landing page, institucional, campanha — narrativa, conversão, movimento e SEO",
+    "standards": [
+      "frontend-design-system-ai-image-generation",
+      "frontend-design-system-ai-video-generation",
+      "frontend-scroll-driven-frame-scrub",
+      "frontend-scroll-driven-smooth-scroll",
+      "frontend-scroll-driven-scroll-components",
+      "frontend-seo-meta-schema-audit",
+      "frontend-gsap-core",
+      "frontend-gsap-scrolltrigger",
+      "frontend-gsap-plugins"
+    ]
+  },
+  "admin-app": {
+    "when": "app de dados: painel administrativo, CRUD, back office, dashboard — lista, tabela, formulário e densidade",
+    "standards": [
+      "frontend-admin-app-data-table",
+      "frontend-admin-app-forms",
+      "frontend-admin-app-feedback",
+      "frontend-admin-app-page-structure"
+    ]
+  },
+  "brand-moment": {
+    "when": "momento de marca dentro do produto: login e auth, onboarding, primeira tela, estado vazio de destaque, sucesso, vitrine — direção, cena e movimento",
+    "standards": [
+      "frontend-gsap-core",
+      "frontend-gsap-scrolltrigger"
+    ]
+  }
+}