@polymorphism-tech/morph-spec 8.46.0 → 9.0.0

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

@@ -1,150 +1,125 @@
 ---
 name: morph-review
-description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
+description: Conduz o Gate 3 — despacha verificador ∥ revisor (∥ segurança, quando exigida) em contexto fresco sobre um SHA fixo e decide pelo gate-check
 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.46.0"
+when_to_use: Use quando a fase review começar, com todas as fatias com relatório final e o verify da feature verde
+user-invocable: true
+cliVersion: "9.0.0"
 ---
 
 # morph-review
 
 ## Objetivo
-Responder, com evidência, uma pergunta: **a entrega faz o que os use cases dizem, sem quebrar o que
-já funcionava?** O Gate 3 decide por veredito (`SHIP`/`FIX`) e bloqueadores tipados — não por nota.
-
-## Quando invocar
-Fase review, com todas as tasks `done` e o `recap.md` em dia. Normalmente chamada pela `morph-apply`.
+Responder, com evidência: **cada cenário do plano está provado, sem quebrar o que já funcionava?**
+Três agentes independentes, cada um com o seu relatório em `4-review/`: `verifier.md` (prova cada
+`Cn`), `reviewer.md` (escopo, arquitetura, regressão) e `security.md` (só com caminho sensível). O
+Gate 3 decide por `**Verdict:** SHIP|FIX`, bloqueadores tipados e a cobertura dos `Cn` — não por
+nota. Você não escreve relatório de review: os três arquivos são o retorno.
 
 ## Ritmo
-- Comando em **primeiro plano**, com timeout. O único que pode passar do teto de 10 min do Bash é o
-  `verify {feature}` de um projeto grande: aí rode-o com `run_in_background` e espere a notificação
-  de término. Nunca `sleep`/`until` consultando um processo: a espera custa a máquina e não produz prova.
-- **Bloqueio de ambiente não é laço.** Memória baixa, slot pesado ocupado (`verify` exit 3 /
-  `status: "busy"`), Docker fora: tente **uma** vez mais. Persistiu, siga com o que tem — o
-  `gate-check` pausa com a razão e o humano decide. Nunca agende retentativas.
-
-## O que fazer
-
-1. **Contexto.** Tenha em contexto `2-plan/spec.md`, os use cases (`2-plan/usecases/UC-*.md`),
-   `2-plan/decisions.md` (se existir) e `3-implement/recap.md`. Numa sessão quente eles já estão
-   lá; numa fria, Read.
-
-2. **Relatório já íntegro?** Rode `morph-spec report-check {feature} --json` (sem task) e leia o
-   campo `evaluator` — também em sessão retomada: retomar não reseta este passo.
-   - `evaluator.complete` (tem `**Verdict:**` válido e não é parcial): **não re-despache** — vá ao
-     passo 5.
-   - `evaluator.partial: true` (`PARCIAL` na 1ª linha): ver "PARCIAL" no passo 4.
-   - Ausente ou sem veredito: siga para o passo 3.
-
-3. **Prova da suíte — uma rodada, no CI.** Depois da última task, commite o trabalho da feature na
-   branch (`git add <paths>` + `git commit`: o CI só vê commits) e rode
-   `morph-spec verify {feature} --ci --json` com `run_in_background`. Ele empurra `morph/{feature}`,
-   cria o workflow `morph-verify.yml` se o projeto não tem um, espera o run e grava o stamp do JSON que
-   o run publicou. Sem CI (sem GitHub, sem `gh`, `project.ci: false`) ele mesmo roda o verify local e
-   diz por quê. **Quando a saída mostrar `CI rodando`, despache o avaliador (passo 4) sem esperar o
-   fim**: o workflow e o push já estão commitados, então a foto `--before-eval` não os acusa como
-   mutação, e a suíte corre no CI em paralelo. Saiu `verify local`: espere o fim antes do passo 4 —
-   suíte local e `mutate` disputam a máquina. Exit 2 = trabalho fora de commit; exit 3 (`pending`/`busy`)
-   não é vermelho (ver Ritmo). Rode-a só depois da última task: o `gate-check` pausa o ship se o
-   último stamp é de escopo `task:{id}`. **Sem `--filter`, sempre**: `verify {feature}` **nunca recorta**, e um verify filtrado não persiste o
-   stamp. Se o JSON vier com `repeatOf`, nada mudou desde a rodada anterior — use aquela. Esta é a
-   única execução de testes do Gate 3: o avaliador não roda a suíte de novo.
-   - Nó `e2e`: `pass` local → passe a URL ao avaliador (`morph-spec e2e status {feature} --json` →
-     `baseUrl`); `pass` no CI → a app foi exercida lá, não há stack local para navegar. `fail` →
-     correção (vermelho no CI: `gh run view <id> --log-failed`, impresso pelo verify). Vermelho por
-     config que só existe na máquina (`.env`, appsettings, connection string, secret) não é defeito do
-     código: pergunte ao usuário entre declarar o secret + `env:` no `morph-verify.yml` ou `project.ci: false`. `skip` → quem
-     classifica é o `gate-check` (`classifyE2eSkip`, em `risk-detector.js`): dispensa de projeto/escopo
-     passa; ambiente, `--skip-e2e` ou razão desconhecida pausam sozinhos.
-   - Vermelho com o avaliador ainda rodando: não mexa na árvore até ele voltar (passo 4); corrija junto
-     com os bloqueadores dele. `traceability.warnings` entram no review-report como sinal, não bloqueio.
-
-4. **Despache o avaliador independente** (`morph-evaluator`, contexto fresco, sem Write/Edit).
-   - Tire a foto da árvore e escolha o modelo: `morph-spec report-check {feature} --before-eval --json`.
-     O campo `evaluatorModel.model` é `sonnet` por padrão e `opus` quando o diff toca auth, segredo,
-     pagamento, migração, prompt/modelo ou mídia gerada (`evaluatorModel.reasons` diz por quê).
-   - Blast radius: para cada símbolo público do diff, `morph-spec graph affected <símbolo> --prod --json`.
-     Sem grafo (`no-graph`/`not-found`/`ambiguous`), siga sem o blast radius e registre a ausência no
-     review-report. Numa worktree com grafo stale, `morph-spec graph refresh` antes.
-   ```
-   dispatch Agent (subagent_type: "morph-evaluator", model: {evaluatorModel.model}) with prompt:
-     contexto: use cases + spec.md + diff da feature + JSON do verify se já terminou (nós, e2e, URL)
-               + blast radius + 1-design/mockups.md (se existir) + 3-implement/evidencias/*.md (se existir)
-     instrução: |
-       Siga .morph/framework/evals/review-checklist.md e grave
-       .morph/features/{feature}/4-review/evaluator-report.md ANTES de encerrar — o arquivo é o
-       retorno; não chame SendMessage. Se o arquivo já existir quando você começar, é resíduo de
-       outra tentativa: não o leia antes de escrever o seu (ancoragem no veredito alheio).
-       A suíte roda fora de você (JSON acima, ou o CI em curso): você NÃO roda verify, build nem testes. Bash é para ler
-       (git diff/log/show, grep, morph-spec graph) e para no máximo UMA rodada de
-       `morph-spec mutate {feature}` (até 3 mutantes com `expect`), só quando o checklist pede.
-       Nada em segundo plano, nada de laço de espera. NUNCA `git checkout --`: descarta trabalho
-       não commitado.
-       Com stack no ar, navegue os fluxos da feature e confira console/network.
-       Limite de turnos: a ~70% sem terminar, grave o relatório com `PARCIAL` na 1ª linha e SEM
-       `**Verdict:**`; o relatório final substitui o parcial.
-   ```
-   Tipo `morph-evaluator` não registrado: `general-purpose` com o campo `persona` do `evaluator`
-   (`.morph/framework/agents.json`) no topo do prompt, e registre o fallback no review-report.
-
-   **Ao retomar o controle — higiene antes de ler o veredito.** Rode `morph-spec report-check {feature} --json`:
-   - `tree.sinceBeforeEval.changed` vazio e `tree.markers` vazio = árvore como antes do dispatch.
-     Arquivo listado = mutação que ficou no disco: `morph-spec mutate --restore` devolve os bytes do
-     snapshot conferindo md5; fora de uma rodada de mutação, desfaça linha a linha pelo diff.
-     **NUNCA `git checkout -- src/` aqui**: o checkout apaga junto tudo o que não foi commitado depois
-     da prova (correção de bloqueador, trabalho de outra sessão), e no verify local a feature pode nem
-     ter commit.
-   - `tree.sinceBeforeEval` `null` = sem foto; `tree` `null` = git não respondeu, nada foi conferido.
-   - Não rode build/teste enquanto o agente está `running`.
-
-   Depois leia `4-review/evaluator-report.md` e rode `morph-spec worktree reap --json`.
-
-   **PARCIAL** (`evaluator.partial: true`): não leia veredito dele e não re-despache frio — retome o
-   MESMO avaliador por `SendMessage`, colando `tree.dirty` e `tree.commits` no recado. Só se o id não
-   retomar, despache um novo.
-
-5. **Bloqueadores.** `**Verdict:** FIX` ou bloqueador aberto: corrija (loop da `morph-apply`), commite, rode o
-   `verify {feature} --ci` de novo e **confirme só os bloqueadores** retomando o MESMO avaliador por `SendMessage`
-   (com `tree.dirty`/`tree.commits` e uma foto `--before-eval` nova). Ele não reavalia a feature
-   inteira, e **nota nunca motiva nova rodada**. Avaliador encerrado: despache um novo dizendo que
-   é uma confirmação dos bloqueadores Bn — o relatório é append-only e vale o último `**Verdict:**`.
-
-6. **`4-review/review-report.md`**, curto:
-   - **`**Reviewed-SHA:** {git rev-parse HEAD}`** — obrigatório. O `approve` recusa se o HEAD andou
-     depois do review.
-   - `**Veredito:** SHIP|FIX` e a tabela de bloqueadores do evaluator-report (vazia = `Nenhum.`).
-   - Runtime: nó `e2e` (`pass`/`fail`/`skip` + razão por extenso) e o que foi navegado.
-   - Notas não bloqueantes, numa lista.
-
-7. **Gate 3.** Rode `morph-spec gate-check {feature} review [--json]` — ele lê o veredito do
-   evaluator-report e os demais sinais do disco e decide. Violação das verificações mecânicas entra
-   por `--signals '{"standardsViolations":[...]}'`. Forçar a passagem apesar de uma pausa:
-   `morph-spec gate-decision {feature} review --pause false --reason "..."` (explícito e registrado).
-   Nunca edite `feature.json` à mão.
-
-   **`pause === true`** → `AskUserQuestion`:
-   ```
-   question: "Gate 3 — Review de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
-   header: "Gate 3"
-   options:
-     - { label: "aprovado, fechar feature", description: "Próximo passo: morph-spec finish --pr|--merge (morph-apply §6)" }
-     - { label: "preciso ajustar", description: "Apontar correções antes de fechar" }
-     - { label: "rollback", description: "Voltar para implement" }
-   ```
-   **`pause === false`** → resumo de 3 linhas (veredito, runtime, bloqueadores: 0) e
-   `morph-spec approve {feature} review --mode auto`. A pergunta nomeia a feature: é por ela que o
-   hook `state-sync` grava a aprovação.
-
-   Fechar não é desta skill: `finish {feature} --pr|--merge` (`morph-apply` §6). `--pr` deixa a
-   feature `aguardando-merge` até o merge.
-
-## Output esperado
-- `4-review/evaluator-report.md` — veredito e bloqueadores do avaliador independente (retorno autoritativo)
-- `4-review/review-report.md` — síntese com `Reviewed-SHA`
-- Gate 3 registrado em `feature.json` via `approve` ou pelo hook `state-sync`
+- Comando em **primeiro plano**, com timeout. Só o `verify {feature}` de projeto grande passa do teto
+  de 10 min do Bash: aí `run_in_background` e espere a notificação. Nunca `sleep`/`until`.
+- **Bloqueio de ambiente não é laço.** Slot pesado ocupado (exit 3 / `busy`), Docker fora: tente
+  **uma** vez mais; persistiu, siga — o `gate-check` pausa com a razão. Nunca agende retentativas.
+
+## 1. Relatórios já íntegros?
+`morph-spec report-check {feature} --json` (sem fatia) — também em sessão retomada: retomar não
+reseta este passo. Leia `reviews.verifier|reviewer|security`: `complete` → **não re-despache** esse
+papel; `partial: true` → passo 4 (PARCIAL); ausente → despache no passo 3.
+
+## 2. Prova da suíte — uma rodada
+Commite o trabalho da feature (`git add <paths>` + `git commit`) e rode
+`morph-spec verify {feature} --ci --json` com `run_in_background`. Ele empurra a branch, espera o run
+e grava o stamp do artefato que o run publicou; sem CI, roda local e diz por quê.
+**Sem `--filter`, sempre**: o Gate 3 roda a suíte inteira. Esta é a única execução de testes do Gate 3 — nenhum agente
+roda a suíte de novo. `repeatOf` no JSON = nada mudou, use aquela rodada; `reason: "stamp-reused"` = sem CI e
+nada fora de `.morph/` andou desde o último verify verde: ele vale, não rode de novo.
+- **Quando a saída mostrar `CI rodando`, despache (passo 3) sem esperar o fim**: o push e o
+  workflow já estão commitados e a foto da árvore não os acusa. Saiu `verify local`: espere o fim
+  antes do passo 3 — suíte local e `mutate` disputam a máquina. Exit 2 = trabalho fora de commit.
+- Nó `e2e`: `pass` local → `morph-spec e2e status {feature} --json` → `baseUrl` vai ao verificador.
+  `fail` → correção (CI: `gh run view <id> --log-failed`). `skip` → quem classifica é o `gate-check`
+  (`classifyE2eSkip`): dispensa de projeto passa; ambiente, `--skip-e2e` ou razão desconhecida pausam.
+- `traceability.warnings` do verify vão ao revisor como sinal.
+
+## 3. Dispatch — verificador ∥ revisor (∥ segurança)
+`morph-spec report-check {feature} --before-eval --json` tira a foto da árvore e diz quem despachar:
+`reviewModels.verifier.model` (opus com prompt/modelo ou mídia), `reviewModels.security.required`.
+Anote `base` (merge-base com a default) e `sha` (`git rev-parse HEAD`). Blast radius: para cada
+símbolo público do diff, `morph-spec graph affected <símbolo> --prod --json`; sem grafo
+(`no-graph`/`not-found`/`ambiguous`), siga sem o blast radius — o revisor cai para `git grep` — e
+registre a ausência no recado a ele. Cada agente nasce com contexto fresco e **nunca recebe relatório anterior** (ancoragem).
+Despache todos na mesma resposta:
+```
+dispatch Agent (subagent_type: "morph-verifier", model: {reviewModels.verifier.model}) with prompt:
+  feature, base, sha, JSON do verify (nós, e2e, URL) se já terminou, 1-design/mockups.md e
+  3-implement/evidencias/*.md se existirem. Grave .morph/features/{feature}/4-review/verifier.md.
+  Não rode `morph-spec mutate` até eu avisar que revisor e segurança terminaram.
+  NUNCA `git checkout --`: descarta trabalho não commitado.
+dispatch Agent (subagent_type: "morph-reviewer") with prompt:
+  feature, base, sha, blast radius (ou a ausência dele), traceability.warnings.
+  Grave .morph/features/{feature}/4-review/reviewer.md.
+dispatch Agent (subagent_type: "morph-security") with prompt:      ← só com security.required
+  feature, base, sha, reviewModels.security.reasons. Grave .morph/features/{feature}/4-review/security.md.
+```
+O prompt leva só os campos acima. O que você notou no loop chega ao revisor como
+`traceability.warnings` ou como item da `## Errata` do plano, nunca como lista solta de "fatos do
+loop": é histórico da conversa (MORPH §6) e ancora quem nasceu para olhar sem ele.
+O contrato fixo (o que provar, `**Reviewed-SHA:**` obrigatório, formato, PARCIAL, read-only) mora no
+corpo de cada persona e em `.morph/framework/evals/review-checklist.md`. Tipo não registrado:
+`general-purpose` com o campo `persona` de `.morph/framework/agents.json` no topo do prompt.
+
+Revisor e segurança voltaram: diga ao verificador, por `SendMessage`, que a mutação está liberada —
+opcional, no máximo 3 mutantes com `expect`, só para guarda sem teste que a morda (review-checklist).
+Achou o teste por leitura: não rode.
+
+## 4. Ao retomar — higiene antes de ler o veredito
+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 e `tree.markers` vazio = árvore como antes do dispatch.
+  Arquivo listado = mutação que ficou no disco: `morph-spec mutate --restore` devolve os bytes do
+  snapshot; fora de uma rodada de mutação, desfaça linha a linha pelo diff.
+  **NUNCA `git checkout -- src/` aqui**: o checkout apaga junto tudo o que não foi commitado depois
+  da prova (correção de bloqueador, trabalho de outra sessão).
+- `tree.sinceBeforeEval` `null` = sem foto; `tree` `null` = git não respondeu.
+
+Depois leia os relatórios e rode `morph-spec worktree reap --json`.
+
+**PARCIAL** (`reviews.<papel>.partial: true`): não leia veredito dele e não re-despache frio —
+retome o MESMO agente por `SendMessage`, colando `tree.dirty` e `tree.commits`. Só se o id não
+retomar, despache um novo.
+
+## 5. Bloqueadores
+O avaliador também erra: **antes de editar, reverifique cada bloqueador no código** — evidência que
+não se reproduz vira pergunta ao mesmo agente, não correção. Confirmado: corrija (loop da
+`morph-apply`), commite, rode o `verify {feature} --ci` de novo e uma foto `--before-eval` nova.
+Retome por `SendMessage` TODO agente exigido, com o `sha` novo e `tree.dirty`/`tree.commits`: quem
+abriu bloqueadores **confirme só os bloqueadores** (retomando o MESMO agente que os abriu); os outros
+julgam só o delta `{sha anterior}..{sha novo}` — o que a correção abriu. `reviewModels.security.required`
+virou `true` agora: despache a segurança. Ninguém reavalia a feature inteira, e **nota nunca motiva
+nova rodada**. Agente encerrado: despache um novo dizendo que é uma confirmação — o relatório é
+append-only e vale o último `**Verdict:**`. Cada relatório carrega o `**Reviewed-SHA:**` —
+obrigatório: o `approve` recusa quando o código andou depois de QUALQUER um deles.
+
+## 6. Gate 3
+`morph-spec gate-check {feature} review [--json]` lê os relatórios exigidos, a cobertura dos `Cn` e
+os demais sinais do disco. Violação das verificações mecânicas entra por
+`--signals '{"standardsViolations":[...]}'`. Forçar a passagem apesar de uma pausa:
+`morph-spec gate-decision {feature} review --pause false --reason "..."`. Nunca edite `feature.json`.
+
+**`pause === true`** → `AskUserQuestion`:
+```
+question: "Gate 3 — Review de {feature} aprovado?{ reason ? ' Sinal: ' + reason : '' }"
+header: "Gate 3"
+options:
+  - { label: "aprovado, fechar feature", description: "Próximo passo: morph-spec finish --pr|--merge (morph-apply §8)" }
+  - { label: "preciso ajustar", description: "Apontar correções antes de fechar" }
+  - { label: "rollback", description: "Voltar para implement" }
+```
+**`pause === false`** → resumo de 3 linhas (vereditos, cenários provados, bloqueadores: 0) e
+`morph-spec approve {feature} review --mode auto`. A pergunta nomeia a feature: é por ela que o hook
+`state-sync` grava a aprovação. Fechar é da `morph-apply` §8.
 
 ## Referências
-- `.morph/framework/evals/review-checklist.md` — o que o avaliador procura e o formato do relatório
+- `.morph/framework/evals/review-checklist.md` — o que cada papel procura e o formato dos relatórios
 - `morph-spec verify|mutate|report-check|gate-check` — `.morph/framework/CLI.md`
-- `.morph/framework/MORPH.md` §5 — sinais do Gate 3

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

@@ -1,64 +1,52 @@
 ---
 name: morph-standards
-description: Localiza um standard específico via busca server-side (morph-spec standards --find) e carrega só o necessário
+description: Localiza um standard específico via busca server-side (morph-spec standards --find) e carrega só a seção necessária (--show id#âncora)
 version: core
-when-to-invoke: quando precisar consultar um standard específico durante a implementação
-user-invokable: true
-cliVersion: "8.46.0"
+when_to_use: Use quando precisar consultar um standard específico durante a implementação
+user-invocable: true
+cliVersion: "9.0.0"
 ---
 
 # morph-standards
 
 ## Objetivo
-Encontrar o standard certo para a situação atual e carregar apenas o necessário no contexto.
-Nunca abra o `STANDARDS.json` inteiro (65 KB) — a busca server-side já devolve o suficiente
-para aplicar o standard na maioria dos casos.
+Achar o standard certo para a fatia e pôr no contexto só o trecho que ela precisa. Nunca abra o
+`STANDARDS.json` inteiro.
 
 ## Quando invocar
-Quando durante a implementação surgir uma dúvida de padrão arquitetural, de contrato, de qualidade
-ou de teste — e o `spec.md` e os standards da task não bastarem para resolver.
+Durante a implementação, quando surgir dúvida de padrão (arquitetura, contrato, qualidade, teste)
+que o `plan.md` e os standards da fatia não resolvem.
 
 ## O que fazer
 
-1. Rode a busca server-side — é O caminho, não uma opção entre várias:
+1. **Digest.** Busque no servidor:
    ```
-   morph-spec standards --find "<domínio/tecnologia da task>" [--category <cat>] [--tags <a,b>] [--json]
+   morph-spec standards --find "<domínio/tecnologia da fatia>" [--category <cat>] [--tags <a,b>] [--json]
    ```
-   Devolve o **top 3** como `id · path · digest` — o `digest` é o texto completo do standard;
-   na maioria dos casos ele já basta para aplicar o padrão, sem abrir o `.md`.
+   Devolve o top 3 com `id`, `path`, `digest` e as chaves de âncora. O digest é um resumo, não o
+   texto do standard: serve para decidir se o standard se aplica e muitas vezes basta para aplicá-lo.
 
-2. Se dois resultados parecerem relevantes e houver conflito, adote o mais específico ao stack
-   do projeto. Registre o conflito no `decisions.md` da feature.
-
-3. Abra o arquivo `.md` do standard (campo `path`) só quando o `digest` não bastar para resolver
-   a dúvida — ex.: precisa de um exemplo de código completo ou de uma seção que o resumo não cobre.
-
-4. Aplique o standard na tarefa atual.
-
-5. Registre no `recap.md`: qual standard foi consultado (via `--find`, ou navegação — item abaixo)
-   e como foi aplicado.
+2. **Seção.** O digest não bastou → leia só a seção que importa:
+   ```
+   morph-spec standards --show <id>#<âncora>
+   ```
+   A âncora é uma das chaves que o `--find` listou, ou o slug de qualquer heading do `.md`.
+   `morph-spec standards --show <id>` mostra o digest e a tabela de âncoras.
 
-## Fallback — navegação exploratória
+3. **Arquivo inteiro** (campo `path`, sob `.morph/framework/standards/`) só quando a fatia toca o
+   standard todo ou precisa de um exemplo que nenhuma seção isolada traz.
 
-`--find` exige uma query. Quando a necessidade é genuinamente exploratória (ex.: "o que existe
-pra categoria X?", sem um termo de busca claro), nesta ordem:
+4. Dois standards em conflito → adote o mais específico ao stack do projeto.
 
-1. `morph-spec standards` sem `--find` — lista categorias + contagem, custo mínimo, o suficiente
-   pra decidir qual `--category` usar num `--find` em seguida.
-2. Só se isso não bastar, abra `.morph/framework/standards/STANDARDS.json` inteiro — último recurso,
-   nunca o primeiro passo.
+5. Registre no `**Standards:**` do relatório da fatia (`3-implement/reports/F{n}.md`) qual standard (e qual âncora) aplicou e, havendo, o conflito.
 
-## Quando não há standard adequado
-Registre no `decisions.md` que nenhum standard cobre o caso.
-Descreva o critério adotado e sinalize para revisão futura.
-Não invente um standard — padrões não documentados são dívida técnica.
+## Sem query clara
+`morph-spec standards` sem flag lista categorias e contagens; use para escolher o `--category` de
+um `--find` em seguida.
 
-## Output esperado
-- Standard identificado (via `--find`/digest, ou `.md` completo quando necessário) no contexto
-- Critério de implementação claro para a tarefa atual
-- Entrada no recap.md registrando o standard consultado
+## Quando nenhum standard cobre o caso
+Registre no relatório da fatia o critério adotado. Não invente standard: padrão não documentado é dívida.
 
 ## Referências
-- `morph-spec standards --find "<query>" [--category] [--tags] [--json]` — busca server-side, top 3 `id · path · digest`
-- `.morph/framework/standards/STANDARDS.json` — índice completo; abrir só como fallback exploratório (ver acima)
-- `.morph/framework/MORPH.md` — seção 4 (Como consultar Standards)
+- `.morph/framework/CLI.md` — seção `standards` (flags, `--json`, falhas)
+- `.morph/framework/MORPH.md` — §4 (Como consultar Standards)