@polymorphism-tech/morph-spec 8.17.0 → 8.19.0

package/framework/commands/morph-hotfix.md

@@ -21,7 +21,7 @@ Resolve uma queda ou bug crítico de produção com prioridade máxima em veloci
 3. **Hotfix brief:** escreve `0-proposal/proposal.md` curto (sintoma/root cause/blast radius/plano do fix) e `2-plan/tasks.json` mínimo (T1 fix, T2 verify/regressão).
 4. **Fix cirúrgico:** implementa a mudança mínima que resolve o sintoma — sem refatoração, sem hardening fora de escopo.
 5. **Test loop:** `morph-spec verify {feature-name} {task} --json` focado no blast radius até verde; evidência real capturada no `recap.md`.
-6. **Gate 3 sempre humano:** `morph-spec gate-decision {feature-name} review --pause true ...` → `4-review/review-report.md` → `AskUserQuestion` sempre. **Nunca** `morph-spec approve {feature-name} review --mode auto` — o CLI recusa essa combinação num hotfix.
+6. **Gate 3 sempre humano:** `morph-spec gate-check {feature-name} review` (força a pausa via `workType: hotfix`, lido do disco) → `4-review/review-report.md` → `AskUserQuestion` sempre. **Nunca** `morph-spec approve {feature-name} review --mode auto` — o CLI recusa essa combinação num hotfix.
 7. **Pós-gate:** `morph-spec verify {feature-name}` (suíte completa da feature) e sinaliza commit/archive — não arquiva automaticamente.
 
 ## Anti-padrões

package/framework/docs/CLI.md

@@ -0,0 +1,41 @@
+# morph-spec CLI — Referência Completa
+
+> Referência completa (flags, semântica, exemplos) dos comandos `morph-spec` usados pela LLM em vez de editar o estado à mão. Resumo rápido em `.morph/framework/CLAUDE.md`; racional dos gates em `.morph/framework/MORPH.md` §5, dispatch de sub-agents em §6, worktree/fleet em §2.2.
+
+---
+
+## Gates e estado
+
+- **`morph-spec approve <feature> <gate> --mode auto`** — aprova um gate (`proposal`/`plan`/`review`) em `trust: auto`. **O Gate 3 exige `4-review/evaluator-report.md`**: sem o relatório do avaliador independente o comando recusa (exit 1). Se o dispatch do avaliador for impossível nesta sessão, aprove com `--self-assessed` — a degradação é gravada em `approvalGates.review.selfAssessed` e aparece marcada no `morph-spec list`. `--force` **não** dispensa esta regra (é só para ordem de gate). **Exceção `hotfix`:** esse tipo nunca despacha o avaliador (`morph-hotfix` §7); o Gate 3 exige `4-review/review-report.md` no lugar do `evaluator-report.md`, e a assinatura humana continua obrigatória via `--approver` (o backstop de `--mode auto` acima permanece recusando).
+- **`morph-spec advance <feature>`** — aprova o gate da fase corrente **e** cria a pasta da próxima fase num passo só (`--design` toma o ramo opcional de uiux a partir da proposta).
+- **`morph-spec score <feature> <task> <score> [--dims a,c,q,t]`** — grava `taskScores` no feature.json com timestamp server-side; **nunca edite taskScores à mão**. Em PowerShell, cite o valor de `--dims` entre aspas (`--dims "9.5,9,9,9"`) — sem aspas, a lista pode chegar como tokens separados; o parser aceita ambas as formas, mas citar evita qualquer ambiguidade.
+- **`morph-spec gate-check <feature> <gate> [--signals <json>] [--trust <mode>] [--json]`** — o caminho **default**: coleta do disco os sinais que `shouldPauseGate` (risk-detector.js) já sabe avaliar (`workType`, `taskCount`, verificação, sha/diffstat), decide a pausa e persiste `gateDecisions.{gate}`. `--signals` aceita só as chaves que o disco genuinamente não expõe sozinho — `designSystemDivergence`, `standardsViolations`, `evalScore` — qualquer outra chave é ignorada com aviso. No **review**, o `evalScore` real vem do token `**Composite-Score:** {n.n}` do `evaluator-report.md` (o avaliador o grava por contrato); sem o token, cai no proxy (média das `taskScores`); `--signals` vence ambos. Um stamp de `verification` com status `fail` (último `morph-spec verify` vermelho) **força pausa** em qualquer gate.
+- **`morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`** — o **escape manual**: registra uma decisão já tomada pela sessão (ex.: `discoveryMode: "interview"`, sinal que `shouldPauseGate` nem representa). Mesmo write path do `gate-check` — grava `gateDecisions` no feature.json com timestamp server-side (shape em `framework/schemas/feature.schema.json`); **nunca edite gateDecisions à mão** — o Edit manual colide com o hook state-sync.
+
+## Features
+
+- **`morph-spec create <feature> --description "<o quê/porquê>" --type <feature|bug|chore|hotfix> [--request "<txt>"] [--name "<nome>"] [--worktree]`** — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback). **Identidade no nascimento:** `name` (default = slug) e `description` são carimbados; a `--description` é **obrigatória** numa feature nova (ou `--request`, que a semeia) — sem nenhuma das duas o `create` recusa (fim dos scaffolds anônimos). `--type` classifica direto; `--request "<pedido>"` roda o detector determinístico (empate/sem sinal sai com exit 2 e candidatos — a LLM decide e re-roda com `--type` + `--request`/`--description`); `--worktree` já nasce a feature no seu worktree próprio. **Toda feature nasce numa branch `morph/{f}`** (ramificada da default) mesmo sem `--worktree` — por isso o fechamento por `morph-spec finish` é idêntico nos dois fluxos.
+- **`morph-spec list [--all] [--json]`** — o quadro de auditoria: uma linha por feature × workType × status × fase × gates G1/G2/G3 × descrição, com `⚠` para inconsistências (sem descrição, ordem de gate). `--all` inclui as arquivadas; `--json` para scripting. É o complemento do `delete` (enxergar o que está morto antes de remover).
+- **`morph-spec delete <feature> [--archive] [--force]`** — remove uma feature. Hard por padrão (pasta apagada, git-aware, + entrada podada do índice raiz para não ressuscitar); `--archive` move para `.morph/archive` com status `abandoned` em vez de apagar. Recusa se algum gate estiver aprovado, a menos que `--force`. Use para faxina de scaffolds mortos e drafts abandonados (`archive` é para trabalho concluído; `delete` é para trabalho morto).
+- **`morph-spec retype <feature> <newType>`** — muda o tipo de trabalho mid-flight; desfaz só os gates carimbados por política, preserva aprovações humanas; bloqueado após o Gate 3.
+
+## Worktree / Fleet
+
+- **`morph-spec finish <feature> --pr|--merge`** — o **encerramento único** da feature (worktree ou comum): **arquiva** commitando `features/{f} → archive/{f}` dentro de `morph/{f}` — promovendo junto, no mesmo commit, os use cases da feature para o acervo permanente `.morph/specs/usecases/` com `status: implemented` (fail-open: sem `2-plan/usecases/`, no-op silencioso) — depois integra. `--merge` faz merge `--no-ff` **local** na default (sem push); `--pr` faz `push` + `gh pr create` (exige `origin` + `gh`, checados **antes** de arquivar — um `--pr` recusado não deixa meio-estado). Desmonta o worktree (PROVE-or-DECLINE) e libera o bloco de portas; no `--pr` **preserva** a branch (o PR precisa dela) e fica em `morph/{f}`. Flags: `--keep` mantém o worktree, `--force` dispensa o Gate 3, `--discard-ignored` consente descartar gitignored no teardown. Substitui o antigo `worktree finish` + `archive` separados.
+- **`morph-spec archive <feature>`** — arquiva-**sem-integrar** (atômico, git-aware, commita o move escopado por pathspec): reservado a features legadas (sem branch `morph/{f}`) e faxina. O fechamento normal (arquiva **e** integra num passo) é `morph-spec finish`. É o que `/morph-archive` chama.
+- **`morph-spec worktree setup|link|list`** — gerencia o ciclo do worktree por feature (`setup` cria `worktrees/{f}/` na branch `morph/{f}`, aloca o bloco de portas e escreve `.morph/worktree.env`; `link` religa infra compartilhada; `list` mostra fase/gate de cada worktree ativo). O fechamento saiu daqui — use `morph-spec finish` (acima).
+- **`morph-spec handoff <feature>`** — regenera o documento de retomada (`.morph/features/{f}/handoff.md`): comprimido, derivado, aponta para os artefatos em vez de copiá-los. Gerado automaticamente em `setup`/`create --worktree`/`advance`.
+- **`morph-spec fleet`** — visão da frota: toda feature ativa (raiz + worktrees) com fase, gates pendentes, tasks, **remoto** (`local`/`pushed`/`PR #N`), **claim** (que sessão está na feature), portas, handoff e atividade. Use entre sessões para decidir onde atuar.
+- **`morph-spec claim [feature] [--release] [--list] [--json]`** — posse **advisory** de feature. Cada sessão reclama sua feature ativa automaticamente (hook SessionStart) e renova o heartbeat a cada tool call; o registro vive em `<git-common-dir>/morph-spec/claims.json`, compartilhado por todos os worktrees. **`morph-spec claim <feature>` (sem flags) ADQUIRE** — se esta árvore já tinha claim vivo em outra feature, ele é liberado no mesmo passo (o CLI reporta "movido de X para Y"); é o jeito de trocar de feature no meio da tarefa sem a dança de dois passos `--release` + reclamar. `--list` força a leitura sem adquirir mesmo passando uma feature. **Claims avisam, nunca bloqueiam** — mas se o SessionStart avisar que outra sessão tem claim vivo, **confirme antes de `finish`/`archive`/`delete`**: duas sessões na mesma feature já custaram um recap.md inteiro e um sub-agent (o worktree sumiu debaixo dele). Claim órfão de sessão morta: `morph-spec claim <f> --release`.
+
+## Validação
+
+- **`morph-spec dag <feature>`** — análise do DAG de tasks.json com decisão sequencial vs paralelo **ponderada por effort** (raízes S vão inline, nunca ganham agente próprio). Também cruza `tasks.json` com os use cases: `usecase` apontando para um `UC-{nn}` inexistente é **erro** (exit 1, não despacha); pós-condição órfã e `doneCriteria` que parafraseou em vez de copiar são avisos. `--mermaid` nunca é bloqueado.
+- **`morph-spec verify <feature> [task] [--json]`** — cadeia determinística build+testes+validadores (código antes do juiz LLM); escopo de task quando informado, senão a feature inteira.
+- **`morph-spec doctor --worktrees [--prune] [--json]`** — reconcilia o registro do git × as pastas em disco × as features conhecidas. Worktrees órfãos acumulavam **invisíveis**: o `fleet` só reporta worktrees em branch `morph/*`, então um worktree em outra branch (resíduo de finish anterior) não aparecia em lugar nenhum. `--prune` roda o único reparo seguro (`git worktree prune` — registros de pastas que já sumiram); apagar pasta que ainda existe é reportado com o comando exato, nunca executado.
+- **`morph-spec report-check <feature> [task] [--json]`** — audita os relatórios de sub-agent contra o trabalho que realmente entrou. **Relatório ausente NÃO quer dizer que o agente falhou** — ele pode ter feito tudo e perdido o meio de gravar. O comando responde a pergunta certa (`work-landed-report-missing` → aceite degradado, NÃO re-despache; `no-work-no-report` → re-despache uma vez). Protocolo completo em MORPH.md §6.
+
+## Observabilidade
+
+- **`morph-spec telemetry [--json] [--feature <f>] [--limit <n>]`** — reconstrói o caminho de execução da sessão a partir de `.morph/logs/events.jsonl` (skills invocadas, personas despachadas + prompts, standards/base de conhecimento lidos, mix de tools, prompts do usuário). Capturado silenciosamente pelo hook `telemetry-log` em todo tool call e todo UserPromptSubmit.
+- **`morph-spec cost [feature] [--by task|phase] [--json]`** — custo da execução a partir do mesmo `events.jsonl`: duração por task (TaskStart→TaskEnd), bytes de contexto re-ingerido por tipo (`rubric`/`standard`/`skill`/`agents`/`plan-artifact`/`code`), dispatches + tamanho de prompt e mix de tools. Bytes re-ingeridos são **proxy determinística** de custo de token (tokens reais não são observáveis por hook). Use antes/depois de mudar skill ou fluxo para medir o efeito.

package/framework/hooks/shared/phase-utils.js

@@ -24,7 +24,6 @@ export const PHASE_DIRS = {
 export const OUTPUT_PHASE_MAP = {
   proposal: 'proposal',
   stackScan: 'proposal',
-  migrationPlan: 'proposal',
   uiDesignSystem: 'uiux',
   uiMockups: 'uiux',
   uiComponents: 'uiux',
@@ -43,7 +42,6 @@ export const OUTPUT_PHASE_MAP = {
 export const FILENAME_TO_OUTPUT = {
   'proposal.md': 'proposal',
   'stack-scan.md': 'stackScan',
-  'migration-plan.md': 'migrationPlan',
   'design-system.md': 'uiDesignSystem',
   'mockups.md': 'uiMockups',
   'components.md': 'uiComponents',

package/framework/phases.json

@@ -12,7 +12,7 @@
         "Produce proposal.md and reach Gate 1"
       ],
       "requiredOutputs": ["proposal"],
-      "optionalOutputs": ["migrationPlan", "stackScan"],
+      "optionalOutputs": ["stackScan"],
       "pausePoints": [
         { "id": "proposal", "label": "Gate 1 — Approve proposal" }
       ],

package/framework/rules/morph-workflow.md

@@ -64,7 +64,7 @@ All outputs go in `.morph/features/{feature}/`:
 
 | Phase | Path |
 |-------|------|
-| Proposal | `0-proposal/proposal.md`, `stack-scan.md`, `migration-plan.md` (optional) |
+| Proposal | `0-proposal/proposal.md`, `stack-scan.md` |
 | Design (optional) | `1-design/design-system.md`, `mockups.md`, `components.md`, `flows.md` |
 | Plan | `2-plan/spec.md`, `mandate.md`, `tasks.json`, `decisions.md` |
 | Implement | `3-implement/recap.md` + source code |

package/framework/schemas/feature.schema.json

@@ -145,6 +145,18 @@
       },
       "additionalProperties": false
     },
+    "verification": {
+      "type": "object",
+      "description": "The single latest deterministic verify stamp (any scope), written ONLY by `morph-spec verify`. Distinct from `verifications`/`taskVerifications` above (per-scope history with attempts/nodes): this is overwritten by every verify call regardless of scope, carrying just enough to correlate a pass/fail with the exact commit it covers. Primary consumer: `morph-spec gate-check`, which surfaces it as a signal (informational — no shouldPauseGate rule keys on it directly).",
+      "required": ["status", "sha", "ts", "scope"],
+      "properties": {
+        "status": { "type": "string", "enum": ["pass", "fail"] },
+        "sha": { "type": ["string", "null"], "description": "HEAD commit SHA at verify time (git rev-parse HEAD); null when not in a git repo or no commits yet." },
+        "ts": { "type": "string", "format": "date-time", "description": "Server-side timestamp, same instant as the corresponding verifications/taskVerifications entry's updatedAt." },
+        "scope": { "type": "string", "description": "'feature', or 'task:<id>' for a task-scoped verify." }
+      },
+      "additionalProperties": false
+    },
     "tasks": {
       "type": "object",
       "description": "Aggregate task counters (informational — the source of truth is 2-plan/tasks.json).",

package/framework/skills/README.md

@@ -13,7 +13,7 @@ These are the only skills the harness needs. MORPH.md references them by path.
 | Skill                | Purpose                                                              | User-invocable |
 |----------------------|----------------------------------------------------------------------|----------------|
 | `morph-brainstorming` | Business understanding + brownfield scan → proposal.md (Gate 1)     | yes            |
-| `morph-stack-scan`    | Detect stack drift in existing projects, generate migration-plan.md  | yes            |
+| `morph-stack-scan`    | Detect stack drift in existing projects, report in stack-scan.md     | yes            |
 | `morph-plan`          | Produce spec.md + mandate.md + tasks.json (Gate 2)                   | yes            |
 | `morph-implement`     | Execute each task with standard + persona, auto-advance between tasks| no             |
 | `morph-eval`          | Score work 0-10 across 4 dimensions, silence on score >= 9           | no             |

package/framework/skills/core/create-umbraco-lp/SKILL.md

@@ -4,7 +4,9 @@ description: Guia a criação de uma landing page nova ponta-a-ponta a partir do
 version: core
 when-to-invoke: ao iniciar um novo projeto de LP com o template Umbraco genérico
 user-invokable: true
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
+stacks:
+  - umbraco
 ---
 
 # create-umbraco-lp

package/framework/skills/core/migrate-lp-to-umbraco/SKILL.md

@@ -4,7 +4,9 @@ description: Migra uma landing page existente (React/Vite, Next.js estático ou
 version: core
 when-to-invoke: ao receber instrução "use /migrate-lp-to-umbraco {projeto}" do usuário, ou quando o usuário descrever necessidade de migrar uma LP para Umbraco
 user-invokable: true
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
+stacks:
+  - umbraco
 ---
 
 # migrate-lp-to-umbraco

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

@@ -4,7 +4,7 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-apply
@@ -210,33 +210,24 @@ Quando `getPendingTasks(data).length === 0`:
 
 ### 5. Gate 3 (trust-aware)
 
-Sinais de risco para Gate 3:
-
-- Score médio < 9 no review-report.
-- Presença de erros não resolvidos.
-- Mudanças incidentais em standards/.morph/framework/.
-
-Mesma lógica do Gate 1/Gate 2 (regras da tabela do MORPH.md §5, aplicadas em linguagem natural — sem scripts): `trust: manual` → pausa sempre; `standardsViolations` não-vazio → pausa; `evalScore < 9` → pausa; caso contrário → auto-passa.
-
-**Persista a decisão ANTES de apresentar ou auto-aprovar — via CLI, nunca editando feature.json à mão** (o Edit manual colide com o hook state-sync — erro "file modified since read"):
+Rode `morph-spec gate-check {feature} review [--json]` — lê `trust`, decide via `shouldPauseGate` e persiste `gateDecisions.review` com timestamp server-side (shape canônico em `.morph/framework/schemas/feature.schema.json`), imprimindo `pause`/`reason`/`signals`. É o default — não recompute a tabela do MORPH.md §5 em linguagem natural.
 
+**`evalScore` sem override é uma PROXY** (média das `taskScores`, não o score composto real). Passe o composto do `review-report.md` (avaliador independente) e qualquer violação que ele tenha encontrado via `--signals` — as únicas chaves que este comando aceita sobrescrever:
 ```
-morph-spec gate-decision {feature} review --pause false --reason "score 9.2, sem violações" --signals '{"evalScore":9.2,"standardsViolations":[]}'
+morph-spec gate-check {feature} review --signals '{"evalScore":9.2,"standardsViolations":[]}'
 ```
 
-O comando grava `gateDecisions.review = { pause, reason, signals, trust, decidedAt }` no `feature.json` autoritativo com timestamp server-side (o `signals.evalScore` aqui é o score composto do review-report; shape canônico em `.morph/framework/schemas/feature.schema.json`). O hook `gate-guard.js` confere depois se a ação bateu. Sem o registro o guard não verifica.
+Risco que nenhuma dessas chaves representa (julgamento do avaliador que não vira `standardsViolations`): use `gate-decision` direto em vez de `gate-check`.
+
+**Nunca edite `feature.json` à mão** (colide com o hook state-sync — erro "file modified since read"). Os caminhos acima gravam no mesmo lugar; o hook `gate-guard.js` confere depois se a ação bateu com a decisão persistida.
 
 - Pause: `AskUserQuestion` com options `["aprovado, fechar feature", "preciso ajustar", "rollback"]`.
 - Auto: exibir summary do review-report, aprovar via `morph-spec approve {feature} review --mode auto`, e prosseguir.
 
 ### 6. Pós Gate 3 — encerramento
 
-- Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em AskUserQuestion — **desde que a pergunta nomeie a feature** (o template acima nomeia; se você improvisar sem o nome e houver mais de uma feature na árvore, o hook recusa a gravar e avisa, e você aprova por `morph-spec approve`). O gate fica gravado no `feature.json` autoritativo da feature — nunca via Edit à mão de `state.json`.
-- **Fechar a feature** com `morph-spec finish {feature} --pr|--merge` — um passo só: arquiva commitando `features/{f} → archive/{f}` dentro de `morph/{f}`, integra e desmonta o worktree (se houver). Escolha o modo com `AskUserQuestion` (header `"Integração"`):
-  - **Abrir PR** (`--pr`): faz `push` de `morph/{f}` + `gh pr create` com base na default — para review por outro humano/CI antes do merge. Exige `origin` + `gh` autenticado (checados **antes** de arquivar; se faltarem, `finish` recusa sem efeito colateral — caia para `--merge`). A branch é preservada e a sessão fica em `morph/{f}`.
-  - **Merge local** (`--merge`): merge `--no-ff` na default **localmente**, sem push — para o fluxo single-user direto. Remove a branch e o worktree.
-- Não integre automaticamente sem a escolha do modo: `finish` toca o remoto (`--pr`) ou a branch default (`--merge`) — é uma ação de saída que pede confirmação.
-- Feature **legada** (criada antes do modelo "nasce numa branch", sem `morph/{f}`): `finish` recusa e roteia para `morph-spec archive {feature}` (arquivar-sem-integrar); nesse caso, arquive.
+- Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em `AskUserQuestion` — **desde que a pergunta nomeie a feature** (senão aprove via `morph-spec approve`).
+- **Fechar a feature** com `morph-spec finish {feature} --pr|--merge`, modo escolhido via `AskUserQuestion` (header `"Integração"`): `--pr` (push + PR, review antes do merge) vs `--merge` (integra local, single-user direto). Não integre automaticamente sem essa escolha. Mecânica completa (o que cada modo faz, feature legada sem `morph/{f}`): `MORPH.md` §2.1/§2.2.
 
 ## Anti-padrões
 
@@ -246,7 +237,7 @@ O comando grava `gateDecisions.review = { pause, reason, signals, trust, decided
 - Não dispachar mais que 4 agentes em paralelo (sobrecarga de contexto + custo).
 - Não dispachar um agente inteiro para uma raiz de effort S — overhead > trabalho; o `morph-spec dag` já as marca como `inline`.
 - Não deixar sub-agent tocar `tasks.json`, `feature.json` ou o board de sessão — estado é do orquestrador (cláusula 2 do protocolo).
-- Não editar `feature.json` à mão para gravar scores ou decisões de gate — use `morph-spec score` e `morph-spec gate-decision` (timestamps server-side; o Edit manual colide com o hook state-sync — "file modified since read").
+- Não editar `feature.json` à mão para gravar scores ou decisões de gate — use `morph-spec score` e `morph-spec gate-check`/`gate-decision` (timestamps server-side; o Edit manual colide com o hook state-sync — "file modified since read").
 
 ## Output esperado
 
@@ -266,5 +257,6 @@ O comando grava `gateDecisions.review = { pause, reason, signals, trust, decided
 - `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort), incluindo recomendação de isolamento (`isolation.recommended: "worktree"`)
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores (código antes do juiz)
 - `morph-spec score {feature} {task} {score} [--dims a,c,q,t]` — grava taskScores no feature.json com timestamp server-side
-- `morph-spec gate-decision {feature} {gate} --pause {bool} [--reason ...] [--signals ...]` — grava gateDecisions no feature.json com timestamp server-side (shape em `.morph/framework/schemas/feature.schema.json`)
+- `morph-spec gate-check {feature} {gate} [--json]` — default: coleta sinais do disco, decide via `shouldPauseGate`, persiste `gateDecisions`
+- `morph-spec gate-decision {feature} {gate} --pause {bool} [--reason ...] [--signals ...]` — escape manual: risco que o `gate-check` não vê no disco (shape em `.morph/framework/schemas/feature.schema.json`)
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-brainstorming
@@ -17,17 +17,7 @@ Ao iniciar uma nova feature — antes de qualquer especificação técnica ou pl
 
 ## Stack padrão (baked in)
 
-O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos que haja ambiguidade real.
-
-| Camada | Stack |
-|--------|-------|
-| Backend | .NET 10, VSA (feature-folder: handler + validator + endpoint + errors + tests) |
-| ORM | EF Core + Neon (Postgres), `Guid.CreateVersion7()`, `sealed` classes, `result.Match()` |
-| IA | Microsoft Agent Framework (MAF) — quando a feature envolve agentes |
-| Frontend | Next.js App Router + Tailwind + Framer Motion + Shadcn |
-| Jobs async | Hangfire — apenas se a feature requer processamento em background |
-
-**Padrões proibidos:** `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions sem result pattern, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), SQL cru sem justificativa. Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
+O harness conhece o stack por padrão (backend .NET 10 + VSA + EF Core/Neon, IA via MAF, frontend Next.js/Tailwind/Shadcn) e a lista de padrões proibidos (`Guid.NewGuid()`, classes não-sealed, Service/Manager layer, repository genérico, SQL cru). **Não pergunte sobre tecnologia a menos que haja ambiguidade real** — stack nunca entra na árvore de decisões. Regra canônica: `MORPH.md` § "Stack baked-in".
 
 ## Modo bug-lean (`workType: bug`)
 
@@ -50,7 +40,7 @@ Fato não se pergunta. Antes de levar a primeira pergunta ao usuário, levante o
 
 3. Reconciliação de design-system (se aplicável): comparar `.morph/context/design-system.md` (se existir) com o que foi detectado no stack-scan e com bundles/mocks recentes do usuário. Se houver **divergência** (tokens diferentes, framework version mismatch, fonte aprovada distinta), marque `signals.designSystemDivergence = true` — a escolha da fonte vira uma **decisão da árvore** (Parte 1), não uma pergunta solta. Resolvida, atualize `.morph/context/design-system.md` com a fonte escolhida + entrada de changelog (data, motivo).
 
-4. Desvio de stack detectado: gere `migration-plan.md` em `.morph/features/{feature}/0-proposal/`. "A migração entra nesta feature ou vira feature separada?" também é decisão da árvore.
+4. Desvio de stack detectado (`stack-scan.md`, seção Desvios): "a migração entra nesta feature ou vira feature separada?" — pergunta feita pelo `morph-stack-scan` ao fim da varredura — também é decisão da árvore; a resposta vai para a seção "Compliance de stack" do `proposal.md` (Parte 4).
 
 ### Parte 1 — Árvore de decisões abertas
 
@@ -112,27 +102,17 @@ options:
 
 2. Apresente o Gate 1 segundo o modo de descoberta e o trust mode.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
-
-   - `discoveryMode` = `"interview"` ou `"auto"`, conforme a resposta da Parte 2.
-   - `designSystemDivergence` = detectado na Parte 0 (fontes de design conflitantes).
-   - `standardsViolations` = lista de violações detectadas.
-
-   **Decisão de pausa** (regras da tabela do MORPH.md §5): **modo entrevista → pausa sempre** ("não aja até eu confirmar" é literalmente o Gate 1: a confirmação do entendimento compartilhado é o gate); `trust: manual` → pausa sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; caso contrário → auto-passa (`pause: false`). Monte `reason` com o sinal que disparou.
-
-   **Persista a decisão ANTES de apresentar ou auto-aprovar — via CLI, nunca editando feature.json à mão** (o Edit manual colide com o hook state-sync, que reescreve o arquivo entre o seu Read e o Edit — erro "file modified since read"):
-
+   **Modo entrevista** (Parte 2) é a única exceção genuína: pausa sempre, e `shouldPauseGate` não tem esse conceito — `discoveryMode` não está entre as chaves que `gate-check --signals` aceita sobrescrever. Registre direto, sem `gate-check`:
    ```
-   # modo entrevista — o gate pausa sempre
-   morph-spec gate-decision {feature} proposal --pause true --reason "modo entrevista — entendimento compartilhado confirmado pelo usuário" --signals '{"discoveryMode":"interview","designSystemDivergence":false,"standardsViolations":[]}'
-
-   # modo automático, sem sinais de risco
-   morph-spec gate-decision {feature} proposal --pause false --reason "nenhum sinal de risco" --signals '{"discoveryMode":"auto","designSystemDivergence":false,"standardsViolations":[]}'
+   morph-spec gate-decision {feature} proposal --pause true --reason "modo entrevista — entendimento compartilhado confirmado pelo usuário" --signals '{"discoveryMode":"interview"}'
    ```
 
-   `signals` é free-form no `feature.schema.json` — `discoveryMode` não exige mudança de schema, e deixa o modo escolhido auditável no `feature.json` commitado.
+   **Fora do modo entrevista** (o caminho comum), rode `morph-spec gate-check {feature} proposal [--json]` — lê `trust` de `.morph/config/config.json`, decide via `shouldPauseGate` e persiste `gateDecisions.proposal` com timestamp server-side, imprimindo `pause`/`reason`/`signals`. Se a Parte 0 detectou divergência de design-system (leitura semântica — o `gate-check` não a vê sozinho no disco), repasse-a: `designSystemDivergence` é uma das poucas chaves que `--signals` aceita sobrescrever aqui:
+   ```
+   morph-spec gate-check {feature} proposal --signals '{"designSystemDivergence":true}'
+   ```
 
-   O comando grava `gateDecisions.proposal = { pause, reason, signals, trust, decidedAt }` no `feature.json` autoritativo com timestamp server-side (shape canônico em `.morph/framework/schemas/feature.schema.json`). O hook `gate-guard.js` confere depois se a ação (pausar vs auto-aprovar) bateu com esta decisão e avisa em divergência. Sem o registro o guard não verifica — não pule.
+   **Nunca edite `feature.json` à mão** (o Edit manual colide com o hook state-sync — erro "file modified since read"). Os dois comandos gravam `gateDecisions.proposal = { pause, reason, signals, trust, decidedAt }` no mesmo lugar (shape canônico em `.morph/framework/schemas/feature.schema.json`); o hook `gate-guard.js` confere depois se a ação (pausar vs auto-aprovar) bateu com a decisão persistida.
 
    **Se `pause === true`** (manual mode OU risco detectado em auto), use `AskUserQuestion`:
 
@@ -162,8 +142,7 @@ options:
    No caminho manual, o hook state-sync.js detecta a aprovação automaticamente (grava o gate no `feature.json` autoritativo, `approvedBy: "manual"`) — **atribuindo pela feature nomeada na pergunta**; sem o nome, e com mais de uma feature na árvore, ele recusa a gravar e avisa (aprove então por `morph-spec approve {feature} proposal`). Em modo auto sem AskUserQuestion, aprove via `morph-spec approve {feature} proposal --mode auto` (ou `morph-spec advance {feature}` para já criar a pasta 2-plan/) — nunca via Edit à mão de state.json.
 
 ## Output esperado
-- `.morph/features/{feature}/0-proposal/proposal.md` — proposta aprovada
-- `.morph/features/{feature}/0-proposal/migration-plan.md` — apenas se houver desvio de stack
+- `.morph/features/{feature}/0-proposal/proposal.md` — proposta aprovada, com desvios de stack (se houver) resolvidos na seção "Compliance de stack"
 - Gate 1 apresentado e aprovado
 
 ## Referências

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

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-eval

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

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-hotfix
@@ -81,10 +81,10 @@ Use `--skip-tests`/`--skip-build` quando fizer sentido para velocidade (ex.: ite
 
 ### 7. Gate 3 — SEMPRE humano
 
-O hotfix tem `forcedPauseGates: ['review']` (`src/core/work-types.js`) — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. Persista a decisão antes de apresentar:
+O hotfix tem `forcedPauseGates: ['review']` (`src/core/work-types.js`) — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. `gate-check` já sabe disso: lê `workType` do disco e `shouldPauseGate` força a pausa antes de checar qualquer outro sinal — rode direto, sem `--signals`:
 
 ```
-morph-spec gate-decision {feature} review --pause true --reason "hotfix: aprovação humana obrigatória" --signals '{"workType":"hotfix","evalScore":X}'
+morph-spec gate-check {feature} review [--json]
 ```
 
 Escreva `4-review/review-report.md` curto: diff do fix + evidência real de teste (saída do `verify` do passo 6). Depois, **`AskUserQuestion` SEMPRE**:
@@ -137,4 +137,4 @@ morph-spec approve {feature} review --approver "<nome de quem aprovou>"
 - `src/core/work-types.js` — `scaffold`/`skippedGates`/`forcedPauseGates` do tipo `hotfix`
 - `morph-spec create {feature} --type hotfix` — nascimento com política de gates
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores
-- `morph-spec gate-decision {feature} review --pause true [--reason ...] [--signals ...]` — persiste a decisão de pausa antes do Gate 3
+- `morph-spec gate-check {feature} review [--json]` — persiste a decisão de pausa (forçada por `workType: hotfix`) antes do Gate 3

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

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-implement

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.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-plan
@@ -45,25 +45,22 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    2. Sistema retorna os veterinários ordenados por sobrenome
    3. Sistema exibe, para cada um, nome e especialidades
 
-   ## Fluxos alternativos
-   - **A1** — Nenhum veterinário cadastrado → sistema exibe estado vazio
-   - **A2** — Veterinário sem especialidade → sistema exibe "sem especialidade"
-
    ## Pós-condições
    - **P1** — A resposta contém todos os veterinários não arquivados
    - **P2** — Cada veterinário traz suas especialidades em lista, nunca string concatenada
    - **P3** — A ordenação por sobrenome é estável para nomes repetidos
 
-   ## Delta de domínio
-   - `Vet.archivedAt` (novo, nullable) — habilita P1
-   - Nenhuma relação nova
+   ## Fluxos alternativos (opcional)
+   - **A1** — Nenhum veterinário cadastrado → sistema exibe estado vazio
    ```
 
    **A regra que sustenta a camada inteira: pós-condição precisa ser observável em teste.** "O sistema fica consistente" não passa. "A resposta contém todos os veterinários não arquivados" passa. Antes de escrever cada pós-condição, pergunte: *que asserção eu escreveria para verificar isto?* Se não há resposta, a pós-condição está mal formulada — reescreva ou descarte. Sem esse filtro a camada vira prosa e não chega ao `doneCriteria`.
 
    **Identificador sequencial no projeto, não na feature.** Antes de numerar, leia o acervo `.morph/specs/usecases/` (se existir) mais os use cases das features ativas em `.morph/features/*/2-plan/usecases/`; tome o maior `UC-{nn}` e some um. Numerar por feature garante colisão no momento da promoção.
 
-   **Seções:** `Pré-condições` (o que já é verdade antes), `Cenário principal` (o caminho feliz, numerado), `Fluxos alternativos` (**A1**, **A2**… — cada alternativa aproxima uma user story; edge case de *comportamento* mora aqui, edge case *técnico* fica no `spec.md`), `Pós-condições` (**P1**, **P2**… — o que passa a ser verdade, cada uma testável) e `Delta de domínio` (**só o que muda**: campo novo, relação nova, invariante nova — o modelo completo continua sendo o código EF Core mais as migrations; se a feature não altera o domínio, escreva "nenhum").
+   **Seções obrigatórias:** `Pré-condições` (o que já é verdade antes), `Cenário principal` (o caminho feliz, numerado, **curto** — não é o lugar para exaustão de casos) e `Pós-condições` (**P1**, **P2**… — o que passa a ser verdade, cada uma testável; é a seção que viaja **literal** ao `doneCriteria`, ver abaixo).
+
+   **Seções opcionais** — inclua só quando o comportamento não-trivial exigir, não por padrão: `Fluxos alternativos` (**A1**, **A2**… — um desvio do caminho feliz que precisa de pós-condição própria; edge case de *comportamento* mora aqui, edge case *técnico* fica no `spec.md`) e `Delta de domínio` (**só quando a feature muda o modelo**: campo novo, relação nova, invariante nova — sem delta, omita a seção em vez de escrever "nenhum"). Nenhuma das duas é consumida por `dag`/`finish` — existem para o leitor humano quando o caso pede, não para preencher o template.
 
    **Quando é obrigatório** (ver MORPH.md §2.1 para o roteamento por tipo):
 
@@ -88,13 +85,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 4. Produza `mandate.md` em `.morph/features/{feature}/2-plan/`:
    - Stack exata do projeto (leia de `.morph/config/config.json` → `project.stack` ou do CLAUDE.md).
    - Standards obrigatórios: liste os IDs relevantes de `.morph/framework/standards/STANDARDS.json`.
-   - Patterns proibidos — inclua sempre os defaults abaixo mais qualquer específico da feature:
-     - `Guid.NewGuid()` → usar `Guid.CreateVersion7()`
-     - Classes não-sealed sem justificativa documentada
-     - Exceptions como fluxo de controle → usar result pattern com `result.Match()`
-     - Camada de Service/Manager entre handler e dados → handler usa `ApplicationDbContext` direto no slice
-     - Repository genérico (`IRepository<T>`/`IUnitOfWork`) → redundante sobre EF Core: `DbSet<T>` já é repository, `DbContext` já é unit of work
-     - SQL cru (`FromSqlRaw`, `ExecuteQuery(string)`) sem justificativa em `decisions.md` → usar LINQ
+   - Patterns proibidos — **copie por extenso no mandate.md** a lista canônica de `MORPH.md` § "Stack baked-in" (`Guid.NewGuid()`→`Guid.CreateVersion7()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, repository genérico `IRepository<T>`/`IUnitOfWork`, SQL cru sem justificativa) mais qualquer proibição específica da feature. Copie o texto completo — o mandate.md é lido por implementadores em contexto fresco, sem `MORPH.md` carregado, então um ponteiro sozinho não basta aqui.
    - Política de acesso a dados (registre no mandate): `ApplicationDbContext` injetado direto no slice — para CRUD e para queries específicas (joins, projeção, paginação). Para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
    - **Features com agentes de IA (MAF):** se a feature envolve um agente (Microsoft Agent Framework), **use a tool Read** nos standards relevantes de `framework/standards/ai-agents/*.md` (ex.: `setup`, `agent-session`, `middleware-patterns`, `mcp-server`, `mcp-tools`, `multi-agent-patterns`, `production`) — filtre pelo que a feature exige via STANDARDS.json. Esses standards carregam as **convenções de projeto** (single-agent por padrão — Workflows só para fan-in/out real; provider, caching, observability, A2A) que uma fonte externa de docs (ex.: context7) não conhece. Padrão de divisão: **superfície da API** pode vir de docs ao vivo/context7 (mais frescas para um SDK em evolução), mas **as convenções vêm dos standards** — registre ambas no mandate. Não pule os `ai-agents/*.md` só porque o STANDARDS.json index lista que eles existem.
    - Checklist de done com critérios verificáveis por tarefa.
@@ -157,21 +148,16 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
    Você pode embutir o diagrama do DAG do plano via `morph-spec dag {feature} --mermaid` (flowchart Mermaid) para visualização no gate.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
-
-   - `taskCount` = número de tasks do tasks.json.
-   - `designSystemDivergence` = herdado do brainstorming.
-   - `standardsViolations` = violações detectadas no mandate.
-
-   **Decisão de pausa** (regras da tabela do MORPH.md §5): `trust: manual` → pausa sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; `taskCount > 20` → pausa; caso contrário → auto-passa (`pause: false`).
-
-   **Persista a decisão ANTES de apresentar ou auto-aprovar — via CLI, nunca editando feature.json à mão** (o Edit manual colide com o hook state-sync, que reescreve o arquivo entre o seu Read e o Edit — erro "file modified since read"):
+   Rode `morph-spec gate-check {feature} plan [--json]` — lê `trust` de `.morph/config/config.json`, conta `taskCount` do `tasks.json` (disco), decide via `shouldPauseGate` e persiste `gateDecisions.plan` com timestamp server-side (shape canônico em `.morph/framework/schemas/feature.schema.json`), imprimindo `pause`/`reason`/`signals`. É o default — não recompute a tabela do MORPH.md §5 em linguagem natural.
 
+   `gate-check` **não herda** `designSystemDivergence` do Gate 1 automaticamente — é recomputado a cada chamada. Se a divergência do Gate 1 segue sem resolução, ou o mandate introduziu uma violação de standard, repasse via `--signals` (as únicas chaves que este comando aceita sobrescrever):
    ```
-   morph-spec gate-decision {feature} plan --pause false --reason "nenhum sinal de risco" --signals '{"taskCount":12,"standardsViolations":[]}'
+   morph-spec gate-check {feature} plan --signals '{"designSystemDivergence":true,"standardsViolations":["<id>"]}'
    ```
 
-   O comando grava `gateDecisions.plan = { pause, reason, signals, trust, decidedAt }` no `feature.json` autoritativo com timestamp server-side (shape canônico em `.morph/framework/schemas/feature.schema.json`). Isso deixa o raciocínio de trust auditável no disco: o hook `gate-guard.js` confere depois se a ação tomada (pausar vs auto-aprovar) bateu com esta decisão e avisa em caso de divergência. Sem este registro o guard não tem como verificar — não pule.
+   Risco que nenhuma dessas chaves representa (julgamento desta sessão, não fato de disco): use `gate-decision` direto em vez de `gate-check`.
+
+   **Nunca edite `feature.json` à mão** (colide com o hook state-sync — erro "file modified since read"). Os caminhos acima gravam no mesmo lugar; o hook `gate-guard.js` confere depois se a ação tomada (pausar vs auto-aprovar) bateu com a decisão persistida.
 
    **Se `pause === true`**, use `AskUserQuestion`:
 

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.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-proposal
@@ -65,13 +65,7 @@ No **modo entrevista** o Gate 1 pausa sempre — a confirmação do entendimento
 
 ### 3. Gate 1 (trust-aware)
 
-Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular sinais de risco:
-
-- `discoveryMode` — `"interview"` ou `"auto"`, decidido na pergunta de abertura da morph-brainstorming.
-- `designSystemDivergence` — detectado pela morph-brainstorming.
-- `standardsViolations` — violações de mandate listadas na proposal (não deveria, mas verifica).
-
-**Decisão de pausa** (regras da tabela do MORPH.md §5, aplicadas em linguagem natural — sem scripts): `discoveryMode: "interview"` → `pause: true` sempre; `trust: manual` → `pause: true` sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; caso contrário → `pause: false` (auto-passa). Monte `reason` com o sinal que disparou.
+A decisão de pausa já foi tomada e persistida pela `morph-brainstorming` (Parte 4): `morph-spec gate-check {feature} proposal` no caminho comum (`shouldPauseGate`; divergência de design-system detectada entra via `--signals`), ou `gate-decision` manual quando `discoveryMode: "interview"` — o único sinal que `shouldPauseGate` não representa. Leia `gateDecisions.proposal` em `feature.json` (ou o output do comando) para `pause`/`reason`.
 
 **Se `pause === true`**, apresentar via `AskUserQuestion`:
 
@@ -118,13 +112,7 @@ A skill lê `proposal.md` e produz:
 
 ### 6. Gate 2 (trust-aware)
 
-Sinais de risco para Gate 2 incluem **mais** do que Gate 1:
-
-- Todos os do Gate 1.
-- `taskCount` — count(tasks.json.tasks). Threshold: 20.
-- `standardsViolations` detectadas no mandate (improvável, mas verificar).
-
-Lógica idêntica ao passo 3 (`shouldPauseGate` + AskUserQuestion ou auto-aprovação).
+Mesma mecânica do passo 3: a decisão já foi tomada e persistida pela `morph-plan` (passo 6) — `morph-spec gate-check {feature} plan` no caminho comum (`shouldPauseGate` sobre `taskCount` do disco; `designSystemDivergence`/`standardsViolations` via `--signals` quando aplicável — não são herdados automaticamente entre gates), ou `gate-decision` manual para risco que nenhuma dessas chaves representa. Leia `gateDecisions.plan` para `pause`/`reason` e apresente com o mesmo template (AskUserQuestion ou auto-aprovação) do passo 3.
 
 ### 7. Conclusão
 

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.17.0"
+cliVersion: "8.19.0"
 ---
 
 # morph-review
@@ -68,9 +68,12 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          um turno inútil ao orquestrador.
          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), e feedback priorizado
-         (bloqueantes primeiro) para qualquer dimensão < 9. Relatório
-         ausente, oco, ou sem esses itens, é falha de protocolo.
+         contracts×0.25 + quality×0.25 + tests×0.20) gravado TAMBÉM como a
+         linha literal `**Composite-Score:** {n.n}` (machine-readable — o
+         `morph-spec gate-check` lê o score real daí em vez do proxy de
+         taskScores), e feedback priorizado (bloqueantes primeiro) para
+         qualquer dimensão < 9. Relatório ausente, oco, ou sem esses itens,
+         é 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).
    - **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.
@@ -97,12 +100,16 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 
 8. Apresente o Gate 3 segundo trust mode.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
+   Rode `morph-spec gate-check {feature} review [--json]` — lê `trust` de `.morph/config/config.json`, decide via `shouldPauseGate` e persiste `gateDecisions.review` com timestamp server-side, imprimindo `pause`/`reason`/`signals`. É o default — não recompute a tabela do MORPH.md §5 em linguagem natural.
 
-   - `evalScore` = score composto retornado pelo **avaliador independente** (passo 4).
-   - `standardsViolations` = ids dos itens bloqueantes de standard encontrados no passo 3.
+   **`evalScore` sem override é uma PROXY** (média das `taskScores`, não o composto real). Passe o composto retornado pelo **avaliador independente** (passo 4) e qualquer item bloqueante encontrado nas **verificações mecânicas sempre-rodar** do passo 3 via `--signals` — as únicas chaves que este comando aceita sobrescrever:
+   ```
+   morph-spec gate-check {feature} review --signals '{"evalScore":9.2,"standardsViolations":[]}'
+   ```
+
+   Julgamento do revisor que nenhuma dessas chaves representa: use `gate-decision` direto em vez de `gate-check`.
 
-   **Decisão de pausa** (mesmas regras da tabela do MORPH.md §5): `trust: manual` → `pause: true` sempre; `standardsViolations` não-vazio → `pause: true`; `evalScore < 9` → `pause: true`; caso contrário → `pause: false` (auto-passa).
+   **Nunca edite `feature.json` à mão** (colide com o hook state-sync). Os caminhos acima gravam no mesmo lugar; o hook `gate-guard.js` confere depois se a ação bateu com a decisão persistida.
 
    **Se `pause === true`**, use `AskUserQuestion`: