@polymorphism-tech/morph-spec 8.37.1 → 8.38.0

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

@@ -4,7 +4,7 @@ description: Guia a produção dos artefatos de planejamento de uma feature (use
 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.37.1"
+cliVersion: "8.38.0"
 ---
 
 # morph-plan
@@ -46,26 +46,42 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 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:**
-   1. **O grafo** — para cada conceito central (entidade, DTO, componente, hook, serviço, helper) que a feature vai introduzir: `morph-spec graph explain <nome-candidato>` (existe? onde?) e `morph-spec graph affected <conceito> --uses-only` (quem usa de verdade, sem contar quem só implementa).
+   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) — **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`.
+   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:
+   **Produza `.morph/features/{feature}/2-plan/reuse-map.md`** — artefato, não prosa solta, com a saída do grafo **citada**:
 
    ```markdown
-   | Conceito | Já existe? | Onde | Decisão |
-   |---|---|---|---|
-   | SimpleBuilding | SIM (5×) | features/roulette/types/roulette.types.ts | REUSAR |
-   | FilterValues | SIM (ambíguo) | dashboard + leads + store | ESTENDER o de dashboard |
-   | RouletteScore | NÃO | — | CRIAR — nenhum tipo cobre pontuação por sorteio |
+   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 |
    ```
 
+   **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):
+
+   ```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`:
@@ -130,11 +146,11 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    | 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. |
+   | `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.
+   **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.
 
@@ -144,6 +160,18 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    - 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):
+
+     ```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 | — | — |
+     ```
+
+     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.
 
@@ -188,6 +216,13 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
        `.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 só com o porquê que o código não
+     mostra, nunca 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
@@ -243,7 +278,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
    **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).
+   - `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.
 
@@ -255,8 +290,21 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
    **`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).
 
    **Critério sobre saída de LLM vira eval de runtime — nunca "suíte estrutural".** Duas etapas,
@@ -288,6 +336,13 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    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.
 
+   **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.
+
    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.
 
 6. Apresente o Gate 2 segundo trust mode.
@@ -333,13 +388,13 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 ## 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
+- `.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`. O status é **descritivo** — quem trava fase é o gate, não este campo.
+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.
 
 ## Referências
 
@@ -349,7 +404,9 @@ Ao registrar a aprovação do Gate 2, atualize o frontmatter de cada use case de
 - `.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)
+- `.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

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

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.37.1"
+cliVersion: "8.38.0"
 ---
 
 # morph-proposal

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

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.37.1"
+cliVersion: "8.38.0"
 ---
 
 # morph-review
@@ -57,9 +57,13 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
      review-report a partir dele). Re-despachar aqui joga fora um veredito de Gate 3 já válido.
    - **Se ausente, oco, ou sem scores por dimensão:** este é exatamente o caso de falha de protocolo
      que este passo trata — prossiga com o dispatch abaixo.
+   - **Se `PARCIAL` na 1ª linha** (`evaluator.partial: true` no `report-check`): o avaliador anterior
+     parou no limite de turnos — não é ausente nem oco. Antes de um dispatch frio, siga o bullet
+     `PARCIAL` do "Leia primeiro" abaixo: continuar quem já provou metade custa menos que refazer a
+     rodada.
 
    **Despache o avaliador independente** — o score do Gate 3 nunca é auto-atribuído por quem implementou:
-   - Rode `morph-spec verify {feature} --json` (escopo feature) e capture o JSON — é a saída real de build+testes+validadores+e2e que você anexa ao prompt do avaliador independente (`morph-evaluator`). **Sem `--filter`, sempre:** o `--filter` é do loop por task, onde o relógio de uma task não paga a suíte inteira; a prova que o avaliador lê tem de cobrir **todos** os nós de `nodes.tests.runs[]` (uma suíte filtrada aparece como `skip` nomeando o filtro — Gate 3 aberto sobre isso é verde sobre código não testado). Se a suíte inteira não couber numa chamada, rode-a em background; não a encolha com `--filter`. `verify {feature}` (sem task) **nunca recorta** — o recorte automático é só do escopo de task —, e um `verify {feature} --filter …` nem persiste o stamp (`persisted: false`, `reason: 'filtered'`) — o mesmo vale para `--skip-tests`/`--skip-build` no escopo de feature. Rode-o **depois** da última task: o `gate-check {feature} review` pausa quando o último stamp `verification` é de escopo `task:{id}`, porque aquela rodada cobriu só a task.
+   - Rode `morph-spec verify {feature} --json` (escopo feature) e capture o JSON — é a saída real de build+testes+validadores+e2e que você anexa ao prompt do avaliador independente (`morph-evaluator`). **Sem `--filter`, sempre:** o `--filter` é do loop por task, onde o relógio de uma task não paga a suíte inteira; a prova que o avaliador lê tem de cobrir **todos** os nós de `nodes.tests.runs[]` (uma suíte filtrada aparece como `skip` nomeando o filtro — Gate 3 aberto sobre isso é verde sobre código não testado). Se a suíte inteira não couber numa chamada, rode-a em background; não a encolha com `--filter`. `verify {feature}` (sem task) **nunca recorta** — o recorte automático é só do escopo de task —, e um `verify {feature} --filter …` nem persiste o stamp (`persisted: false`, `reason: 'filtered'`) — o mesmo vale para `--skip-tests`/`--skip-build` no escopo de feature. Rode-o **depois** da última task: o `gate-check {feature} review` pausa quando o último stamp `verification` é de escopo `task:{id}`, porque aquela rodada cobriu só a task. Uma rodada por árvore: se o JSON vier com `repeatOf`, nada mudou fora de `.morph/` desde o verify de feature anterior — use aquele resultado em vez de rodar de novo; depois de uma correção a árvore mudou, e a nova rodada é a prova.
    - **Confira o nó `e2e` do verify antes de despachar.** Ele carrega o estado do stack:
      - `pass` → a aplicação subiu e está saudável; o avaliador pode navegá-la. **Passe a URL no prompt**
        — cada feature roda no seu bloco de portas, não em `localhost:3000`; pegue de
@@ -88,13 +92,15 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
      gravaram rodando o eval (`morph-plan` §5); não confunda com `3-implement/reports/`, que diz o
      que o sub-agente fez.
    - Gere o **diff da implementação** (`git diff` do range da feature, ou a lista de arquivos do recap.md com seus conteúdos atuais).
-   - **Blast radius dos símbolos do diff (se houver grafo).** Para cada símbolo público que o diff tocou, rode `morph-spec graph affected <símbolo> --prod --json` e inclua o resultado no contexto do avaliador. É o que permite perguntar *"o que esta mudança pode ter quebrado FORA do diff"* sem que o avaliador leia o repositório inteiro. **Fallback:** `no-graph`, `not-found` ou `ambiguous` — siga sem o blast radius e **registre a ausência na seção de método do review-report**; o gate não depende disso. **Trate o resultado como possivelmente stale:** o rebuild do hook é assíncrono, então logo depois de um commit o grafo ainda é o anterior. E lembre que em frontend ele responde "quem importa", não "quem chama".
+   - **Blast radius dos símbolos do diff (se houver grafo).** Para cada símbolo público que o diff tocou, rode `morph-spec graph affected <símbolo> --prod --json` e inclua o resultado no contexto do avaliador. É o que permite perguntar *"o que esta mudança pode ter quebrado FORA do diff"* sem que o avaliador leia o repositório inteiro. **Fallback:** `no-graph`, `not-found` ou `ambiguous` — siga sem o blast radius e **registre a ausência na seção de método do review-report**; o gate não depende disso. **Trate o resultado como possivelmente stale:** o refresh automático só cobre a raiz. Numa worktree o grafo é o semeado da raiz e não vê o que o diff trouxe — com `graph status --json` stale e `refresh.auto: false`, rode `morph-spec graph refresh` antes do blast radius; na raiz, enquanto o refresh em background corre (`refresh.running`), o grafo ainda é o anterior. E lembre que em frontend ele responde "quem importa", não "quem chama".
+   - **Tire a foto da árvore imediatamente antes do dispatch:** `morph-spec report-check {feature} --before-eval --json`, depois do verify e de qualquer correção sua. É contra ela que a higiene abaixo prova que o avaliador reverteu o que mutou.
    - Despache o subagent registrado `morph-evaluator` (gerado de `agents.json` — a persona do avaliador é o system prompt dele, com Read/Glob/Grep + Bash somente para verificação + Playwright para navegar, sem Write/Edit), com contexto fresco:
      ```
      dispatch Agent (subagent_type: "morph-evaluator") with prompt:
        contexto: mandate.md + spec.md + reuse-map.md + diff da implementação
                  + saída real dos testes + nó e2e do verify (stack no ar? em qual URL?)
                  + 3-implement/evidencias/*.md (quando existir)
+                 + 1-design/mockups.md (quando existir — o checklist de tela a conferir)
        instrução: |
          Você NÃO participou da implementação — avalie o que está no diff,
          contra o mandate. NÃO leia `4-review/evaluator-report.md` neste
@@ -201,6 +207,21 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          `morph-spec gate-check` PAUSA o Gate 3. Feature que NÃO gera mídia
          não declara a seção nem a chave — a isenção é automática, e
          escrever a seção "por precaução" é cerimônia vazia.
+         CHECKLIST DE TELA — CONDICIONAL, aplique SÓ se
+         `.morph/features/{feature}/1-design/mockups.md` existe com telas
+         `## Tela:`. Para cada tela, confira cada item decidido do seu
+         `### Checklist de tela` (volume, paginação, ordenação, filtro, os
+         três estados, mobile, abas) contra a tela ENTREGUE — navegando
+         quando o stack subiu, lendo o código quando não (a query pagina e
+         ordena no servidor? o estado vazio existe?). Grave a seção
+         `## Checklist de tela`, uma linha por item decidido de cada tela:
+           | Tela | Item | Mockup (planejado) | Entregue (observado) | Veredito |
+         com o nome da tela como está no mockup e veredito cumpre / diverge
+         / não verificável (com o motivo). Itens "não se aplica" e a
+         Superfície não precisam de linha. Divergência pesa em CONTRATOS
+         (.morph/framework/evals/rubrics/contracts.md, "Contrato de tela").
+         Sem a seção, ou com item decidido sem linha, o `morph-spec
+         gate-check` PAUSA o Gate 3.
          Grave também a linha literal, machine-readable:
          `**Proof-Scores:** mutation={n} verde={n} fiacao={n} guard={n} eval={n}`
          — os cinco 0-10, na ordem das rubricas acima. O MENOR deles
@@ -223,6 +244,10 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          um idle_notification, sem texto). Ainda assim NÃO chame SendMessage:
          ele gera um evento a mais além da notificação de término, custando
          um turno inútil ao orquestrador.
+         Limite de turnos: se chegar a ~70% dele sem terminar, grave o
+         relatório com `PARCIAL` na 1ª linha e SEM `**Composite-Score:**`
+         (o que já provou, o que falta) — o gate-check leria o token como
+         final. Ao concluir, o relatório final substitui o parcial.
          Seu relatório (no arquivo, e na mensagem final quando ela chega)
          deve conter: score 0-10 por dimensão, score composto (arch×0.30 +
          contracts×0.25 + quality×0.25 + tests×0.20) gravado TAMBÉM como a
@@ -234,14 +259,21 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          é falha de protocolo.
      ```
    - **Fallback (tipo não registrado):** se `morph-evaluator` não estiver na sua lista de subagent types, despache `general-purpose` colando o campo `persona` do agente `evaluator` (Read em `.morph/framework/agents.json`) no topo do prompt — e **registre o fallback no review-report** (seção de método).
-   - **Ao retomar o controle, HIGIENE DA ÁRVORE antes de qualquer leitura de score.** Rode, nesta
-     ordem e ANTES de abrir o relatório:
-     ```bash
-     git status --porcelain src/      # vazio = o avaliador reverteu o que mutou
-     grep -rn "MUTACAO" src/          # nenhum hit = nenhum marcador esquecido
-     ```
-     (No PowerShell, `Select-String -Path src -Pattern MUTACAO -Recurse` faz o mesmo; o shell do
-     harness é Git Bash, então a forma POSIX acima é a canônica.) **Por que antes:** o avaliador
+   - **Ao retomar o controle, HIGIENE DA ÁRVORE antes de qualquer leitura de score.** ANTES de
+     abrir o relatório, rode `morph-spec report-check {feature} --json`. A foto que o
+     `--before-eval` gravou antes do dispatch fica em `4-review/`, e é contra ela que o bloco `tree`
+     compara, em qualquer sessão — inclusive a que retoma depois de o avaliador morrer no meio:
+     - `tree.sinceBeforeEval.changed` vazio = o conteúdo de todo arquivo fora de `.morph/` é o de
+       antes do dispatch, e o avaliador reverteu o que mutou. Com arquivos listados, a mutação
+       ficou no disco (ou foi commitada) nesses arquivos;
+     - `tree.markers` vazio = nenhum marcador `MUTACAO` esquecido;
+     - `tree.sinceBeforeEval` `null` = não há foto (dispatch anterior a ela): confira cada arquivo
+       da seção `## Mutações` contra o md5 "antes" registrado; `tree` `null` = o git não respondeu,
+       e nada foi conferido.
+
+     Não tire a foto de novo antes desta higiene passar: a foto nova apagaria a prova da anterior.
+
+     **Por que antes:** o avaliador
      muta código de produção de propósito, e um avaliador que morreu no meio da rodada deixa a
      mutação NO DISCO. Ler o score primeiro e só depois descobrir a árvore suja significa ter
      avaliado — e possivelmente aprovado — um estado que ninguém quis. E **não rode build/teste
@@ -262,6 +294,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
      > diff antes). É a mesma proibição que o prompt do passo 4 já dá ao avaliador: aqui ela vale
      > para VOCÊ.
    - **Leia primeiro** `.morph/features/{feature}/4-review/evaluator-report.md` — é o valor de retorno autoritativo, não a mensagem de texto do dispatch (que é cortesia, útil só quando chega inteira). Os scores por dimensão e o composto do review-report vêm **desse arquivo**, não da sua auto-avaliação. Se o arquivo vier ausente, oco, ou sem os scores por dimensão, registre a falha de protocolo na seção de método do review-report e re-despache.
+   - **`PARCIAL` na 1ª linha = o avaliador parou antes do fim** (limite de turnos; o `report-check` devolve `evaluator.partial: true`). Não leia score dele — o parcial não tem `**Composite-Score:**`, e o `gate-check` pausaria de qualquer jeito — e não re-despache frio: um avaliador novo refaz a rodada inteira (probes, mutações, navegação). Retome o MESMO avaliador por `SendMessage`, como no passo 6, colando `tree.dirty` e `tree.commits` do `report-check` no recado; ele completa o relatório, e o final substitui o parcial. Só se o id não retomar, despache um novo pelo caminho normal — o parcial no disco é resíduo, não insumo, como o prompt já diz. Antes de qualquer das duas, a higiene da árvore acima continua valendo: um avaliador cortado no meio pode ter deixado mutação no disco.
 
 5. Produza `review-report.md` em `.morph/features/{feature}/4-review/` com:
    - **`**Reviewed-SHA:** {git rev-parse HEAD}`** — o commit que você revisou, **obrigatório**.
@@ -294,6 +327,10 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
      Feature sem código de produção declara a seção com `não aplicável — feature sem código de
      produção`. **Sem a seção, o `gate-check review` PAUSA** — a regra vive em código
      (`risk-detector.js`), não na boa vontade do prompt.
+   - **Checklist de tela** (feature com `1-design/mockups.md`) — a seção `## Checklist de tela` do
+     `evaluator-report.md` em resumo: quantas telas e itens conferidos, e cada `diverge` por extenso
+     (tela, item, planejado × entregue). Sem ela, havendo item decidido a conferir, o `gate-check review` **pausa** — o design decidiu
+     como a tela pagina, ordena e falha, e o Gate 3 registra se a tela entregue cumpre.
    - Lista de itens bloqueantes (se houver) — com descrição e critério de resolução
    - Lista de melhorias recomendadas (não bloqueantes)
    - Recomendação final: Aprovado / Rejeitar com condições / Reprovar
@@ -304,8 +341,8 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
    inteira é um bloqueante crítico que o loop de correção deveria ter pego.)
 
    **Para CONFIRMAR uma correção, retome o MESMO avaliador — não despache um frio.** Use
-   `SendMessage` com o id do agente que já avaliou, colando no recado o `git status --porcelain` e o
-   `git log --oneline` do que mudou desde o relatório dele. Ele já tem em contexto o que apontou e
+   `SendMessage` com o id do agente que já avaliou, colando no recado `tree.dirty` e `tree.commits`
+   do `report-check {feature} --json` — o que mudou desde o relatório dele. Antes do recado, tire a foto de novo (`--before-eval`): suas correções mudaram a árvore, e a próxima higiene compara com a árvore que ele vai receber. Ele já tem em contexto o que apontou e
    os probes que rodou; um avaliador novo re-descobre o produto inteiro para checar um item, e
    re-executa do zero os probes da rodada anterior.
 
@@ -389,3 +426,4 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 - `.morph/features/{feature}/2-plan/spec.md` — arquitetura e contratos
 - `.morph/features/{feature}/2-plan/decisions.md` — ADRs registrados (se existir)
 - `.morph/features/{feature}/3-implement/recap.md` — registro de execução
+- `.morph/features/{feature}/1-design/mockups.md` — o checklist de tela que o avaliador confere no passo 4 (quando a feature tomou o ramo uiux)

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

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

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

@@ -4,7 +4,7 @@ description: Localiza um standard específico via busca server-side (morph-spec
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.37.1"
+cliVersion: "8.38.0"
 ---
 
 # morph-standards

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

@@ -4,7 +4,7 @@ description: Conduz a fase opcional de UI/UX — design system, mockups, compone
 version: core
 when-to-invoke: ao tomar o ramo uiux (morph-spec advance --design), depois do Gate 1 e antes do morph-plan
 user-invokable: true
-cliVersion: "8.37.1"
+cliVersion: "8.38.0"
 ---
 
 # morph-uiux
@@ -30,6 +30,7 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
    - **Consistência:** reusa tokens/componentes existentes de `.morph/context/design-system.md` antes de criar novos; um token novo precisa de justificativa (o existente não cobre o caso).
    - **Tecnologia de ponta condicionada ao stack real** (passo 1) — nunca a suposição de que o projeto é Next.js.
    - **Sistemas, não telas isoladas** — mesmo critério da persona `ui-designer`: componentes reutilizáveis antes de composições de uso único.
+   - **Toda tela sai com o checklist de tela preenchido** (template no passo 3) — a superfície, o volume esperado de dados, paginação, ordenação, filtro, os três estados (vazio, carregando, erro), o comportamento no mobile e abas × página longa. "Não se aplica" vale, **desde que escrito**. É o checklist que faz a lista de 2 000 linhas paginar: o que o design não decide não vira `doneCriteria` (`morph-plan` §5d), e o que não é critério ninguém entrega. Tela de dados segue os standards de `admin-app` (lista/tabela, formulário, feedback, estrutura de página), que a persona cita na superfície `admin-app`.
 
 3. **Despache `morph-ui-designer`** para o trabalho visual — dispatch é o default aqui (domínio diferente do Orchestrator, MORPH.md §6). `morph-ui-designer` tem `Read/Write/Edit/Glob/Grep` + MCPs `stitch`/`gemini-image`/`playwright`/`context7`, mas **não tem Bash** — não peça build, testes nem `morph-spec` a ele; isso é do orquestrador.
 
@@ -45,13 +46,36 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
    Produza, NESTA ORDEM — design-system.md primeiro, os demais só como aplicável ao escopo:
    1. `design-system.md` — tokens (cor, tipografia, espaço, motion) consistentes com o projeto
    2. `mockups.md` — descrição estruturada de cada tela nova/alterada (+ imagem via MCP
-      gemini-image/stitch quando disponível; fallback: descrição textual detalhada)
+      gemini-image/stitch quando disponível; fallback: descrição textual detalhada).
+      Cada tela é um `## Tela: <nome>` e traz, dentro dela, o checklist abaixo, com cada `…`
+      trocado pela decisão — "não se aplica" vale se escrito; `…`, vazio ou "a definir" não.
+      O que cada item decide: Superfície (admin-app | marketing-site — ela escolhe que
+      standards você lê para ESSA tela, seção "Standards by surface" da sua persona),
+      Volume esperado (registros hoje e em 1 ano), Paginação (servidor, N por página — ou
+      por que não pagina), Ordenação (colunas + padrão, no servidor), Filtro (filtros e
+      busca, no servidor), Estado vazio (sem registros × sem resultado para o filtro),
+      Estado carregando, Estado de erro (mensagem + como tentar de novo), Mobile (o que a
+      tela vira abaixo de md), Abas (abas × página longa × wizard, e por quê).
+      ### Checklist de tela
+      | Item | Decisão |
+      |---|---|
+      | Superfície | … |
+      | Volume esperado | … |
+      | Paginação | … |
+      | Ordenação | … |
+      | Filtro | … |
+      | Estado vazio | … |
+      | Estado carregando | … |
+      | Estado de erro | … |
+      | Mobile | … |
+      | Abas | … |
    3. `components.md` — inventário de componentes novos/reusados, com props e os estados do
       princípio 2 acima
    4. `flows.md` — fluxos de navegação/interação entre as telas
 
-   Done quando: os artefatos aplicáveis existem e cada um cita os tokens/componentes do
-   design-system.md em vez de reinventar valores soltos.
+   Done quando: os artefatos aplicáveis existem, cada um cita os tokens/componentes do
+   design-system.md em vez de reinventar valores soltos, e toda `## Tela:` do mockups.md
+   tem o checklist completo.
 
    Contrato do relatório final:
    1. GRAVE um relatório por artefato produzido em
@@ -70,13 +94,13 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
 
    Após o retorno: **leia primeiro** `1-design/reports/*-report.md` — valor de retorno autoritativo, a mensagem de texto é atalho best-effort quando chega inteira. `design-system.md` é o único output obrigatório (`phases.json → uiux.requiredOutputs`); sem ele em disco, `morph-spec advance` recusa avançar — confirme que existe antes de rodar `advance` no passo 6.
 
-4. **Atualize o design system vivo do projeto** — se a Parte 3 introduziu tokens/componentes novos, aplique o mesmo protocolo do `morph-brainstorming` (Parte 0): atualize `.morph/context/design-system.md` com a adição e uma entrada de changelog (data, motivo). `1-design/design-system.md` é o artefato **da feature** (o que ela usa/introduz); `.morph/context/design-system.md` é o acervo vivo do **projeto** — não confunda os dois.
+4. **Atualize o design system vivo do projeto** — se a Parte 3 introduziu tokens/componentes novos, aplique o mesmo protocolo do `morph-brainstorming` (Parte 0): **reescreva o corpo** de `.morph/context/design-system.md` com a adição — o token ou a regra que mudou é substituído na própria seção, nunca empilhado ao lado do antigo — e registre no changelog só data e motivo. `1-design/design-system.md` é o artefato **da feature** (o que ela usa/introduz); `.morph/context/design-system.md` é o acervo vivo do **projeto** — não confunda os dois.
 
 5. **Os artefatos alimentam o `morph-plan` seguinte.** Use cases e tasks de UI referenciam `1-design/mockups.md`/`components.md` **por path** (ex.: doneCriteria citando a seção do mockup) — não redigite conteúdo visual em `spec.md`.
 
 6. Apresente o Gate uiux.
 
-   Rode `morph-spec gate-check {feature} uiux [--json]` — mesma mecânica de `morph-plan`/`morph-review`: lê `trust`, decide via `shouldPauseGate` e persiste `gateDecisions.uiux` com timestamp server-side. Divergência de design-system detectada aqui (fonte do projeto vs. o que a feature precisa) é uma das poucas chaves que `--signals` aceita sobrescrever:
+   Rode `morph-spec gate-check {feature} uiux [--json]` — mesma mecânica de `morph-plan`/`morph-review`: lê `trust`, decide via `shouldPauseGate` e persiste `gateDecisions.uiux` com timestamp server-side. **O checklist de tela é cobrado aqui, por código:** com `1-design/mockups.md` presente, tela sem o bloco, item ausente, resposta vazia ou "a definir" — ou nenhuma `## Tela:` — **pausa** o gate nomeando tela e item (`signals.screenChecklist`), e o `approve`/`advance` com assinatura `auto` recusam encerrar a fase pela mesma regra (só o mockup no formato antigo, telas `## S001:`, é isento — e o sinal diz isso). Complete o mockup antes de apresentar o gate: não peça ao humano que aprove um design que ainda não decidiu se a lista pagina. Divergência de design-system detectada aqui (fonte do projeto vs. o que a feature precisa) é uma das poucas chaves que `--signals` aceita sobrescrever:
    ```
    morph-spec gate-check {feature} uiux --signals '{"designSystemDivergence":true}'
    ```
@@ -119,9 +143,9 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
 ## Output esperado
 
 - `.morph/features/{feature}/1-design/design-system.md` — obrigatório
-- `.morph/features/{feature}/1-design/mockups.md`, `components.md`, `flows.md` — conforme o escopo exigir
+- `.morph/features/{feature}/1-design/mockups.md`, `components.md`, `flows.md` — conforme o escopo exigir; no `mockups.md`, toda `## Tela:` com o `### Checklist de tela` completo (cobrado pelo `gate-check uiux` e pelo `approve`/`advance` com assinatura `auto`)
 - `.morph/features/{feature}/1-design/reports/*-report.md` — relatório(s) bruto(s) do `morph-ui-designer` despachado no passo 3
-- `.morph/context/design-system.md` atualizado (se tokens/componentes novos entraram) com entrada de changelog
+- `.morph/context/design-system.md` com o corpo reescrito (se tokens/componentes novos entraram) e uma entrada de changelog (data, motivo)
 - Gate uiux registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo)
 
 ## Referências
@@ -129,7 +153,8 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
 - `.morph/framework/MORPH.md` §2.1 — critério objetivo de entrada no ramo uiux
 - `.morph/framework/MORPH.md` §6 — protocolo de dispatch e contrato do relatório final
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)
-- `.morph/framework/agents.json` — persona `ui-designer` (tools, MCPs, standards)
+- `.morph/framework/agents.json` — persona `ui-designer` (tools, MCPs, standards; `surfaces` separa os de `marketing-site` e os de `admin-app`)
+- `.morph/framework/standards/frontend/admin-app/` — lista e tabela, formulário, confirmação e toast, abas × página longa × wizard: o que o checklist de tela decide numa tela de dados
 - `.morph/framework/templates/context/design-system.md` — forma de partida quando o projeto não tem design system vivo
 - `.claude/skills/morph-brainstorming/SKILL.md` — protocolo de reconciliação/changelog do design-system vivo (Parte 0), reaplicado no passo 4
 - `.claude/skills/morph-plan/SKILL.md` — consome os artefatos desta fase por path