@polymorphism-tech/morph-spec 8.17.0 → 8.19.0

package/framework/MORPH.md

@@ -4,7 +4,7 @@
 > Ele define papéis, fases, outputs, standards, gates e skills do morph-spec.
 > Não procure instruções em hooks — o harness vive aqui.
 >
-> **Depois de ler:** leia `.morph/state.json` para identificar a feature ativa e a fase atual. `state.json` é um **índice fino e gitignored** (só status + updatedAt por feature, reconstruído a partir dos `feature.json` a cada load) — use-o apenas para descobrir a feature ativa, **nunca o edite à mão** (a edição é perdida no próximo load). O estado autoritativo e commitado de cada feature vive em `.morph/features/{feature}/feature.json`. Se houver uma feature `in_progress`, assuma o papel correspondente à fase e continue o trabalho sem esperar instrução. Se não houver feature ativa, pergunte ao usuário qual feature trabalhar ou se é uma feature nova.
+> **Depois de ler:** leia `.morph/state.json` — **índice fino e gitignored** (status + updatedAt por feature, reconstruído dos `feature.json` a cada load) — só para descobrir a feature ativa; **nunca o edite à mão** (perdido no próximo load). O estado autoritativo e commitado vive em `.morph/features/{feature}/feature.json`. Feature `in_progress` → assuma o papel da fase e continue sem esperar instrução. Sem feature ativa → pergunte qual trabalhar.
 
 ---
 
@@ -21,16 +21,14 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
 | Sub-agent retornou relatório (qualquer auto-score)                    | Auto-score é triagem, não aprovação: a task só avança com morph-eval ≥ 9      |
 | Sub-agent com auto-score < 7                                          | Re-despachar com feedback específico (ou corrigir inline) antes do morph-eval |
 | Build/typecheck quebra                                                | Corrigir antes de marcar tarefa como done                                     |
-| Task implementada (código escrito) na fase implement                  | Rodar `morph-spec verify <feature> <task>` (build+testes+validadores determinísticos) ANTES do juiz: verify vermelho = feedback direto ao loop de correção, sem gastar o morph-eval; verify verde → morph-eval avalia o que o código não pega (arquitetura, contratos, qualidade) |
+| Task implementada (código escrito)                                    | `morph-spec verify <feature> <task>` ANTES do juiz: vermelho = feedback ao loop sem gastar o morph-eval; verde → morph-eval avalia o que o código não pega |
 | Score morph-eval ≥ 9                                                  | Silêncio (aprovação implícita), próxima tarefa                                |
-| Score morph-eval < 9 numa task                                        | Loop de correção autônomo: re-implementar com o feedback priorizado, até 3 tentativas, sem pausa humana |
-| Score morph-eval < 9 após 3 tentativas                                | Escalar ao usuário (aceitar / continuar tentando / pular) — único ponto de pausa do loop de implement |
+| Score morph-eval < 9 numa task                                        | Loop de correção autônomo: re-implementar com feedback priorizado, até 3 tentativas, sem pausa humana |
+| Score morph-eval < 9 após 3 tentativas                                | Escalar ao usuário (aceitar/continuar/pular) — único ponto de pausa do loop  |
 
-**Regra de ouro:** Dúvida que não bloqueia o progresso → resolver e registrar. Dúvida que bloqueia → uma pergunta, máximo.
+**Regra de ouro:** dúvida que não bloqueia → resolver e registrar; dúvida que bloqueia → uma pergunta, máximo. Vale **entre gates** (plan/implement/review) — **não** vale na abertura da feature: a fase proposal pode rodar em **modo entrevista** (escolhido na pergunta de abertura, `morph-brainstorming` Parte 2), onde perguntar até fechar o entendimento é o comportamento desejado.
 
-**Escopo da regra de ouro:** ela vale **entre gates** — durante plan, implement e review. Ela **não** vale na abertura de uma feature: a fase proposal pode rodar em **modo entrevista**, em que perguntar até fechar o entendimento é o comportamento desejado, escolhido pelo usuário na pergunta de abertura (`morph-brainstorming` Parte 2). Entrevistar antes de especificar é barato; descobrir o mal-entendido depois do Gate 2 não é.
-
-**Código antes do juiz:** o `morph-spec verify` é a barreira determinística e barata — build, testes e validadores estáticos rodam primeiro, sempre igual, sem custo de tokens. O juiz LLM (morph-eval) só é acionado quando o verify passa. Código é o herói não-celebrado do loop: ele pega o que pega de graça; o juiz gasta tokens só no que o código não consegue ver.
+**Código antes do juiz:** `morph-spec verify` (build+testes+validadores) é a barreira determinística e barata, sempre roda primeiro; o juiz LLM (morph-eval) só é acionado quando o verify passa — ele gasta tokens só no que o código não pega sozinho.
 
 ---
 
@@ -57,34 +55,27 @@ Padrões proibidos automaticamente injetados no mandate:
 - 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` — use LINQ
 
-Acesso a dados em VSA: o handler injeta `ApplicationDbContext` direto no slice — `DbSet<T>` já é repository, `DbContext` já é unit of work. Para concorrência ou SQL específico, crie um store dedicado hand-written com justificativa em `decisions.md`. NUNCA camada de Service/Manager; NUNCA repository genérico.
+Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work). Concorrência ou SQL específico → store dedicado hand-written com justificativa em `decisions.md`.
 
 ---
 
 ## 1. Papéis
 
-O morph-spec opera com três papéis que você assume conforme o contexto da tarefa:
+O morph-spec opera com três papéis que você assume conforme o contexto:
 
-**Orchestrator** — ativo na abertura de uma feature e nas transições de fase.
-Responsabilidades: ler o mandato, entender o escopo, propor o plano de ataque, identificar dependências entre tarefas, garantir que gates sejam respeitados antes de avançar.
-Anti-padrão: o Orchestrator não escreve código. Se você está no papel de Orchestrator e percebe que começou a implementar algo, pare — você transitou de papel sem intenção, e o plano provavelmente ainda não está fechado.
+**Orchestrator** — ativo na abertura de uma feature e nas transições de fase. Lê o mandato, entende o escopo, propõe o plano de ataque, identifica dependências entre tarefas, garante que gates sejam respeitados antes de avançar. Anti-padrão: não escreve código — se percebe que começou a implementar, pare, você transitou de papel sem intenção.
 
-**Specialist** — ativo durante a fase de implementação.
-Responsabilidades: executar tarefas do tasks.json em ordem, consultar standards relevantes antes de cada tarefa, registrar decisões e desvios no decisions.md, manter o recap.md atualizado ao final de cada tarefa.
-Anti-padrão: o Specialist não cria novas tarefas. Descobertas de escopo durante a implementação vão para o decisions.md com flag "escopo expandido" — o Orchestrator avalia se o tasks.json precisa ser atualizado.
+**Specialist** — ativo durante a implementação. Executa tarefas do tasks.json em ordem, consulta standards antes de cada uma, registra decisões/desvios no decisions.md, mantém o recap.md atualizado ao final de cada tarefa. Anti-padrão: não cria novas tarefas — descoberta de escopo vai para decisions.md com flag "escopo expandido", o Orchestrator avalia se o tasks.json precisa mudar.
 
-**Evaluator** — ativo após uma tarefa ou fase ser concluída.
-Responsabilidades: aplicar as rubricas em `.morph/framework/evals/rubrics/`, produzir score 0-10, emitir feedback priorizado quando score < 9 (que alimenta o loop de correção autônomo do morph-apply), escalar para revisão humana apenas quando o loop de correção se esgotar (3 tentativas sem atingir 9).
-No **Gate 3** o Evaluator é obrigatoriamente um sub-agent independente: a `morph-review` despacha o subagent registrado `morph-evaluator` (gerado de `agents.json`, tools read-only) com contexto fresco — mandate + diff da implementação + saída real dos testes — e o score composto da feature vem desse retorno, nunca de auto-avaliação de quem implementou. **A regra é enforced server-side:** `morph-spec approve {feature} review` recusa (exit 1) enquanto `4-review/evaluator-report.md` não existir. Se o dispatch for genuinamente 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 a regra (é só para ordem de gate). **Exceção `hotfix`:** o tipo nunca despacha o avaliador (velocidade é o ponto do hotfix); o Gate 3 exige `4-review/review-report.md` — o artefato que a `morph-hotfix` de fato produz — e a assinatura humana continua obrigatória (§2.1/§5), sem afrouxar nada para os demais tipos.
-Anti-padrão: o Evaluator não reescreve o código que avaliou. Se o score está abaixo de 6, o relatório vai para o humano — não para uma segunda rodada de tentativa automática.
+**Evaluator** — ativo após uma tarefa ou fase concluída. Aplica as rubricas em `.morph/framework/evals/rubrics/`, produz score 0-10, emite feedback priorizado quando < 9 (alimenta o loop de correção autônomo do morph-apply), escala ao humano só quando o loop se esgotar (3 tentativas sem atingir 9). No **Gate 3** é obrigatoriamente um sub-agent independente com contexto fresco — nunca auto-avaliação de quem implementou (enforcement: relatório obrigatório, `--self-assessed`, exceção `hotfix` — **§5**). Anti-padrão: não reescreve o código avaliado; score < 6 vai para o humano, não para retry automático.
 
-Os papéis não são exclusivos — numa sessão longa você transita entre Orchestrator e Specialist conforme as tarefas avançam. A transição deve ser explícita: antes de mudar de papel, conclua o que estava fazendo ou registre o estado corrente no recap.md.
+Os papéis não são exclusivos — numa sessão longa você transita entre eles. A transição deve ser explícita: conclua o que estava fazendo ou registre o estado no recap.md antes de mudar.
 
 ---
 
 ## 2. Fases
 
-O fluxo padrão de uma feature tem quatro fases. Cada fase tem uma pasta dedicada em `.morph/features/{feature}/`. O estado autoritativo e commitado da feature mora em `.morph/features/{feature}/feature.json` (status, approvalGates, outputs, tasks, gateDecisions, taskScores, archivedAt); a raiz `.morph/state.json` é só um índice fino e gitignored derivado dele, e a identidade do projeto fica no `.morph/config/config.json` (commitado).
+O fluxo padrão de uma feature tem quatro fases, cada uma com pasta dedicada em `.morph/features/{feature}/`. Estado autoritativo e commitado: `.morph/features/{feature}/feature.json` (status, approvalGates, outputs, tasks, gateDecisions, taskScores, archivedAt); `.morph/state.json` na raiz é só índice fino gitignored derivado dele; identidade do projeto em `.morph/config/config.json` (commitado).
 
 | Fase        | Pasta          | Gate                  | O que termina a fase                            |
 |-------------|----------------|-----------------------|-------------------------------------------------|
@@ -93,15 +84,15 @@ O fluxo padrão de uma feature tem quatro fases. Cada fase tem uma pasta dedicad
 | implement   | `3-implement/` | Nenhum                | Todas as tasks do tasks.json com status `done`  |
 | review      | `4-review/`    | Gate 3 (trust-aware)  | `review-report.md` aprovado e commitado         |
 
-A fase `proposal` tem dois **modos de descoberta**, escolhidos pelo usuário na abertura (só `workType: feature` e `bug` — `chore`/`hotfix` nascem em `implement`): **entrevista** (uma pergunta por vez até a árvore de decisões abertas zerar; Gate 1 pausa sempre, porque a confirmação do entendimento compartilhado é o gate) e **automático** (até 4 perguntas em lote; Gate 1 trust-aware). Nos dois modos a varredura do ambiente roda **antes** de qualquer pergunta — fato que o `morph-stack-scan` ou o acervo de use cases responde não vira pergunta ao usuário. Detalhes em `morph-brainstorming`.
+A fase `proposal` tem dois **modos de descoberta**, escolhidos pelo usuário na abertura (só `workType: feature`/`bug` — `chore`/`hotfix` nascem em `implement`): **entrevista** (uma pergunta por vez até a árvore de decisões abertas zerar; Gate 1 pausa sempre) e **automático** (até 4 perguntas em lote; Gate 1 trust-aware). Nos dois modos a varredura do ambiente roda **antes** de qualquer pergunta — fato que `morph-stack-scan` ou o acervo de use cases responde não vira pergunta. Detalhes em `morph-brainstorming`.
 
-A fase `1-design/` (design system, mockups, flows) é opcional — aplica-se apenas a features com componentes de UI novos e deve ser explicitamente requisitada pelo usuário.
+A fase `1-design/` (design system, mockups, flows) é opcional — só para features com UI nova, requisitada explicitamente pelo usuário.
 
 Não avance de fase sem o gate correspondente ter sido confirmado.
 
 ### 2.1 Roteamento por tipo de trabalho
 
-Nem todo trabalho merece o pipeline completo. Cada feature nasce com **identidade** (`name` = slug por padrão + `description` obrigatória) e um **workType** (`morph-spec create <f> --description "<o quê/porquê>" --type <tipo>`, ou classificado de `--request "<pedido>"` — que também semeia a descrição), e o tipo dimensiona o pipeline:
+Nem todo trabalho merece o pipeline completo. Cada feature nasce com **identidade** (`name` = slug + `description` obrigatória) e um **workType** (`morph-spec create <f> --description "<o quê/porquê>" --type <tipo>`, ou classificado de `--request "<pedido>"`, que também semeia a descrição) que dimensiona o pipeline:
 
 | Tipo | Pipeline | Gates |
 |------|----------|-------|
@@ -110,29 +101,29 @@ Nem todo trabalho merece o pipeline completo. Cada feature nasce com **identidad
 | `chore` | fast-track: direto para implement (Gates 1/2 carimbados por política no nascimento) → review leve | só 3 |
 | `hotfix` | scout (diagnóstico read-only) → fix cirúrgico → **aprovação humana obrigatória** → test loop → ship | 3 (humano sempre) |
 
-**Como classificar (router):** sinais determinísticos primeiro — o `morph-spec create --request "<texto>"` roda o detector por keywords (hotfix: "produção caiu/urgente/incident/p0"; bug: "bug/corrigir/exception/regressão"; chore: "typo/rename/bump/config/docs/cleanup"). As keywords casam como **palavra inteira**, nunca como pedaço de outra palavra ("group0" não é `p0`, "prefix" não é `fix`, "debug" não é `bug`) — casar demais faria um pedido inócuo pular gates sem humano nem router. Por isso plural e flexão são listados explicitamente ("bugs", "erros", "incidentes", "configs"): o recall mora no vocabulário, não num matcher que dispara em fragmento. Confiança `high` → usa o tipo. Empate (`tie`) ou nenhum sinal (`none`) → o comando sai com código 2 e os candidatos; **você decide como roteador** e re-roda com `--type`. Só há ambiguidade real que valha uma `AskUserQuestion` quando o pedido do usuário é genuinamente indeterminado.
+**Como classificar (router):** sinais determinísticos primeiro — `morph-spec create --request "<texto>"` roda o detector por keywords (hotfix: "produção caiu/urgente/incident/p0"; bug: "bug/corrigir/exception/regressão"; chore: "typo/rename/bump/config/docs/cleanup"). As keywords casam como **palavra inteira** ("group0" não é `p0`, "prefix" não é `fix`, "debug" não é `bug`) — casar demais pularia gates num pedido inócuo; por isso plural e flexão são listados explicitamente ("bugs", "incidentes", "configs"). Confiança `high` → usa o tipo. Empate (`tie`) ou nenhum sinal (`none`) → o comando sai com código 2 e os candidatos; **você decide como roteador** e re-roda com `--type`. Só vale uma `AskUserQuestion` quando o pedido é genuinamente indeterminado.
 
-**Como o skip funciona (sem variantes de pipeline):** `chore`/`hotfix` têm os gates `proposal` e `plan` carimbados no nascimento com `approvedBy: "policy:{tipo}"`. Como a fase derivada avança com gate aprovado (`derivePhase` é gate-aware), o trabalho já nasce em `implement` — sem tocar `phases.json`. Os artefatos de fase reutilizam os nomes canônicos (o hotfix escreve um brief curto no `proposal.md`; ambos escrevem um `2-plan/tasks.json` mínimo de 1-3 tasks para ligar trace/score/dag).
+**Como o skip funciona:** `chore`/`hotfix` têm os gates `proposal`/`plan` carimbados no nascimento com `approvedBy: "policy:{tipo}"`. Como `derivePhase` é gate-aware, o trabalho já nasce em `implement` — sem tocar `phases.json`. Artefatos reutilizam os nomes canônicos (hotfix escreve brief curto em `proposal.md`; ambos escrevem `2-plan/tasks.json` mínimo de 1-3 tasks para ligar trace/score/dag).
 
-**Compat:** uma feature sem `workType` (criada antes do v8) é tratada como `feature`. Mudança de tipo mid-flight: `morph-spec retype <f> <tipo>` (desfaz só carimbos de política, preserva aprovações humanas; bloqueado após o Gate 3).
+**Compat:** feature sem `workType` (pré-v8) é tratada como `feature`. Mudança mid-flight: `morph-spec retype <f> <tipo>` (desfaz só carimbos de política, preserva aprovações humanas; bloqueado após o Gate 3).
 
-**Nascimento numa branch:** toda feature — **com ou sem `--worktree`** — nasce numa branch `morph/{f}` ramificada da default. O fluxo comum (sem worktree) desenvolve direto em `morph/{f}` na raiz; o fluxo worktree isola em `worktrees/{f}`. Por construção o fechamento é simétrico: `morph-spec finish <f> --pr|--merge` (§2.2) fecha os dois do mesmo jeito. Features criadas **antes** deste modelo (sem branch `morph/{f}`) fecham por `morph-spec archive <f>` (arquivar-sem-integrar), não por `finish`.
+**Nascimento numa branch:** toda feature — com ou sem `--worktree` — nasce em `morph/{f}` ramificada da default (comum: desenvolve direto na raiz; worktree: isola em `worktrees/{f}`). Fechamento simétrico: `morph-spec finish <f> --pr|--merge` (§2.2) fecha os dois igual. Features pré-modelo (sem branch `morph/{f}`) fecham por `morph-spec archive <f>`, não por `finish`.
 
 ### 2.2 Desenvolvimento paralelo por worktree (frota)
 
-Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu git worktree**, com uma instância de Claude Code por worktree. `morph-spec create <f> --description "<o quê/porquê>" --worktree` (ou `morph-spec worktree setup <f>`) cria `worktrees/{f}/` na branch `morph/{f}`. Contrato:
+Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu git worktree**, uma instância de Claude Code por worktree. `morph-spec create <f> --description "<o quê/porquê>" --worktree` (ou `morph-spec worktree setup <f>`) cria `worktrees/{f}/` na branch `morph/{f}`. Contrato:
 
-- **Uma feature = um worktree = uma instância.** Nunca abra duas instâncias na mesma feature (o setup recusa com exit 3).
-- O estado autoritativo (`feature.json`) viaja **commitado na branch** `morph/{f}`. O `state.json` local do worktree é um índice derivável — materializado por self-heal, nunca sincronizado à mão.
-- Infra compartilhada (`node_modules`, `.claude`, `.morph/framework`) é linkada por junction; `memory/` e `logs/` são locais de cada worktree (isolamento correto). Se faltar infra num worktree (aberto com `git worktree add` puro), rode `morph-spec worktree link --all`.
-- **Nunca apague um worktree à mão** (`rm -rf`, `Remove-Item -Recurse -Force`, deletar a pasta pelo explorador/IDE). O `morph-spec finish`/`worktree remove` desmonta a junction ANTES de remover (PROVE-or-DECLINE — nunca segue o link para fora); um `rm -rf`/`Remove-Item -Recurse` genérico não sabe disso e, em muitas implementações (inclusive o `Remove-Item -Recurse` do PowerShell no Windows), atravessa a junction e apaga o conteúdo real da raiz que ela aponta — o `.claude`/`node_modules`/`.morph/framework` compartilhados, não só o link. Se um worktree precisa sumir, use sempre `morph-spec finish <f> --pr|--merge` (ou, sem fechar a feature, `git worktree remove`, nunca uma remoção de diretório genérica).
-- **Ambiente separado (portas):** o setup aloca um **bloco de portas determinístico** por feature e escreve `.morph/worktree.env` no worktree (`PORT`, `MORPH_PORT_RANGE`; `ASPNETCORE_URLS` quando o stack tem dotnet). **Suba dev servers SEMPRE nas portas do bloco** — as portas padrão (3000/5000) pertencem à raiz; duas instâncias no default se matam. O arquivo é local e git-invisível; o hook de SessionStart injeta as portas. Overrides em `config.json → fleet.basePort/blockSize`.
-- **Banco de dados:** worktrees compartilham o mesmo banco por padrão. Para isolamento real com o MCP do Neon disponível, crie um branch de DB `morph/{f}` e anote a connection string no `.morph/worktree.env` (a CLI nunca toca em credenciais); sem Neon, prefixe schema/DB local com o nome da feature. Migration destrutiva num worktree compartilhando banco → integre antes de abrir worktrees irmãos.
-- **Limitação conhecida:** `node_modules` é compartilhado (junction) — mudança de dependência feita num worktree afeta os irmãos. Mudou dependência: conclua e integre (`finish`) antes de seguir com worktrees paralelos.
-- **Handoff entre sessões:** `.morph/features/{f}/handoff.md` é o documento de retomada — comprimido, derivado e regenerável (`morph-spec handoff <f>`), ele **aponta** para os artefatos em vez de copiá-los. É regenerado automaticamente no `worktree setup`, `create --worktree` e `advance`; o hook de SessionStart aponta para ele. **Ao abrir uma sessão numa feature em andamento, leia o handoff antes de re-derivar contexto à mão.** Nunca o edite manualmente (é git-invisível e sobrescrito na próxima regeneração).
-- **Visão da frota:** `morph-spec fleet` agrega raiz + worktrees (fase, gates pendentes, tasks, portas, handoff, último commit, sujeira) — use entre sessões para decidir onde atuar. `morph-spec worktree list` continua sendo a visão enxuta por worktree.
-- **Ownership de arquivos:** não há lock em runtime, por design — a colisão de escrita se resolve **em plan-time** (`morph-spec dag` detecta overlap de `outputs` e recomenda `isolation: "worktree"`) e **por construção** (uma feature = um worktree = um escritor). Entre features, arquivos compartilhados convergem no merge do `finish` — conflito ali é o sinal honesto de escopo sobreposto, não um bug.
-- **Fechamento:** aprove o Gate 3, depois **`morph-spec finish <f> --pr|--merge`** — o encerramento único e simétrico (mesmo comando nos dois fluxos, worktree e comum). Ele **arquiva** a feature commitando o move `features/{f} → archive/{f}` **dentro da branch `morph/{f}`** (o estado arquivado viaja na própria integração, não num commit à parte) e então integra: `--merge` faz o merge `--no-ff` **local** na branch default (sem push; recusa se worktree/raiz estiverem sujos; aborta em conflito) e `--pr` faz `push` de `morph/{f}` + `gh pr create` (sem merge local; exige `origin` + `gh` autenticado — as pré-condições rodam **antes** de arquivar, então um `--pr` recusado não deixa meio-estado). Em ambos o worktree é desmontado (PROVE-or-DECLINE) e o bloco de portas liberado; no `--pr` a branch é **preservada** (o PR aberto precisa dela) e a sessão permanece em `morph/{f}`. Não há mais `worktree finish` nem `archive` separado no caminho feliz — `morph-spec archive` fica reservado a arquivar-sem-integrar (features legadas, faxina).
+- **Uma feature = um worktree = uma instância.** Nunca abra duas instâncias na mesma feature (setup recusa, exit 3).
+- `feature.json` viaja **commitado na branch** `morph/{f}`. `state.json` local do worktree é índice derivável — materializado por self-heal, nunca sincronizado à mão.
+- Infra compartilhada (`node_modules`, `.claude`, `.morph/framework`) linkada por junction; `memory/`/`logs/` são locais de cada worktree. Faltou infra (worktree aberto com `git worktree add` puro) → `morph-spec worktree link --all`.
+- **Nunca apague um worktree à mão** (`rm -rf`, `Remove-Item -Recurse -Force`, explorador/IDE). `morph-spec finish`/`worktree remove` desmonta a junction ANTES de remover (PROVE-or-DECLINE); uma remoção genérica não sabe disso e, em várias implementações (inclusive `Remove-Item -Recurse` no Windows), **atravessa a junction** e apaga o conteúdo real compartilhado (`.claude`/`node_modules`/`.morph/framework`), não só o link. Use sempre `morph-spec finish <f> --pr|--merge` (ou `git worktree remove`, sem fechar a feature).
+- **Ambiente separado (portas):** o setup aloca um **bloco de portas determinístico** por feature em `.morph/worktree.env` (`PORT`, `MORPH_PORT_RANGE`; `ASPNETCORE_URLS` se dotnet). **Suba dev servers SEMPRE nas portas do bloco** — as portas padrão (3000/5000) pertencem à raiz. Arquivo local, git-invisível; SessionStart injeta as portas. Overrides em `config.json → fleet.basePort/blockSize`.
+- **Banco de dados:** compartilhado por padrão. Isolamento real (Neon MCP): branch de DB `morph/{f}` + connection string no `.morph/worktree.env`; sem Neon, prefixe schema/DB local pelo nome da feature. Migration destrutiva compartilhando banco → integre antes de abrir worktrees irmãos.
+- **Limitação conhecida:** `node_modules` compartilhado (junction) — mudança de dependência afeta os irmãos. Mudou dependência: conclua e integre (`finish`) antes de seguir em paralelo.
+- **Handoff entre sessões:** `.morph/features/{f}/handoff.md` — documento de retomada comprimido, regenerável (`morph-spec handoff <f>`), **aponta** para os artefatos em vez de copiá-los. Regenerado em `worktree setup`/`create --worktree`/`advance`. **Leia-o antes de re-derivar contexto à mão.** Nunca edite manualmente.
+- **Visão da frota:** `morph-spec fleet` agrega raiz + worktrees (fase, gates, tasks, portas, handoff, último commit, sujeira). `morph-spec worktree list` é a visão enxuta por worktree.
+- **Ownership de arquivos:** sem lock em runtime — colisão se resolve **em plan-time** (`morph-spec dag` detecta overlap de `outputs`, recomenda `isolation: "worktree"`) e **por construção** (uma feature = um worktree = um escritor). Arquivos compartilhados convergem no merge do `finish`; conflito ali é escopo sobreposto, não bug.
+- **Fechamento:** aprove o Gate 3, depois **`morph-spec finish <f> --pr|--merge`** — encerramento único e simétrico. **Arquiva** commitando `features/{f} → archive/{f}` **dentro de `morph/{f}`** e integra: `--merge` faz `--no-ff` **local** (sem push; recusa se sujo; aborta em conflito); `--pr` faz `push` + `gh pr create` (exige `origin`+`gh`, checados **antes** de arquivar). Worktree desmontado (PROVE-or-DECLINE), portas liberadas; no `--pr` a branch é **preservada**. `morph-spec archive` fica para arquivar-sem-integrar (features legadas, faxina).
 
 ---
 
@@ -143,80 +134,74 @@ Não invente caminhos alternativos.
 
 ### Proposal (`0-proposal/`)
 
-- `proposal.md` — descrição da feature, problema que resolve, escopo, riscos. **Sem critérios de aceite:** o comportamento verificável mora nos use cases (`2-plan/usecases/`), destilados na fase plan. Duplicar aqui produz duas fontes que divergem no primeiro ajuste. Um bom proposal.md tem no máximo 2 páginas: se está crescendo além disso, o escopo provavelmente precisa ser cortado antes de avançar.
+- `proposal.md` — descrição da feature, problema que resolve, escopo, riscos. **Sem critérios de aceite:** o comportamento verificável mora nos use cases (`2-plan/usecases/`), destilados na fase plan — duplicar aqui produz duas fontes que divergem no primeiro ajuste. Máximo ~2 páginas; além disso, o escopo provavelmente precisa ser cortado antes de avançar.
 
 ### Plan (`2-plan/`)
 
-- `usecases/UC-{nn}-{slug}.md` — **um arquivo por use case**, o artefato de comportamento da feature. Frontmatter (`id`, `title`, `actor`, `status`, `entities`) mais as seções `Pré-condições`, `Cenário principal`, `Fluxos alternativos` (A1, A2… — cada alternativa aproxima uma user story), `Pós-condições` (P1, P2…) e `Delta de domínio` (**só o que muda** no modelo; o domínio completo continua sendo o código EF Core mais as migrations).
+- `usecases/UC-{nn}-{slug}.md` — **um arquivo por use case**, o artefato de comportamento da feature. Frontmatter (`id`, `title`, `actor`, `status`, `entities`) mais as seções obrigatórias `Pré-condições`, `Cenário principal` (curto) e `Pós-condições` (P1, P2…). `Fluxos alternativos` (A1, A2…) e `Delta de domínio` são **opcionais** — só quando o comportamento não-trivial exigir (detalhe: `morph-plan`).
 
-  **Pós-condição precisa ser observável em teste** — esta é a regra que sustenta a camada. "O sistema fica consistente" não passa; "a resposta contém todos os veterinários não arquivados" passa. A pós-condição chega **literal** ao `doneCriteria` da task que a realiza: é a tradução manual nesse ponto que hoje perde o requisito.
+  **Pós-condição precisa ser observável em teste** — a regra que sustenta a camada. "O sistema fica consistente" não passa; "a resposta contém todos os veterinários não arquivados" passa. Chega **literal** ao `doneCriteria` da task que a realiza — tradução manual nesse ponto é o que hoje perde o requisito.
 
-  O `id` é sequencial **no projeto**, não na feature — atribuído lendo o acervo `.morph/specs/usecases/` mais os use cases das features ativas, tomando o maior mais um. Ciclo de status: `draft` (nasce) → `approved` (Gate 2) → `implemented` (promoção no `finish`); é descritivo, quem trava fase é o gate. O use case fica **editável depois do Gate 2**, por design — é o que permite mudar o comportamento e re-rodar `implement`, com a auditoria no git. Obrigatoriedade por tipo de trabalho: ver `morph-plan`.
+  `id` sequencial **no projeto**, não na feature — leia o acervo `.morph/specs/usecases/` mais os use cases das features ativas, tome o maior mais um. Status: `draft` → `approved` (Gate 2) → `implemented` (promoção no `finish`) — descritivo, quem trava fase é o gate. **Editável depois do Gate 2**, por design (muda comportamento, re-roda `implement`, auditoria no git). Obrigatoriedade por tipo de trabalho: ver `morph-plan`.
 
-- `spec.md` — especificação técnica detalhada: arquitetura, componentes, integrações, fluxos de dados, edge cases **técnicos**. Responde **como** os use cases serão realizados — não repete o comportamento. Um bom spec.md permite que qualquer desenvolvedor comece a implementar sem fazer perguntas básicas. Um spec.md fraco lista tecnologias mas não explica como os componentes se conectam.
+- `spec.md` — especificação técnica: arquitetura, componentes, integrações, fluxos de dados, edge cases **técnicos**. Responde **como** os use cases serão realizados — não repete o comportamento. Deve bastar para implementar sem perguntas básicas: tecnologia listada sem explicar como os componentes se conectam é um spec.md fraco.
 
-- `mandate.md` — contrato de implementação: stack exata, standards obrigatórios (com links), patterns explicitamente proibidos, checklist de done com critérios verificáveis. O mandate.md é lido no início de cada tarefa de implementação — deve ser específico o suficiente para resolver ambiguidades sem consultar o Orchestrator.
+- `mandate.md` — contrato de implementação: stack exata, standards obrigatórios (com links), patterns proibidos, checklist de done verificável. Lido no início de cada task — específico o bastante para resolver ambiguidades sem consultar o Orchestrator.
 
-- `tasks.json` — task list estruturada validada contra `framework/schemas/tasks.schema.json`. Cada task tem `id` (T1, T2...), `title`, `description`, `dependencies` (array de IDs), `effort` (S/M/L/XL), `doneCriteria`, `status` (pending/in_progress/done/skipped/blocked), `outputs` (paths esperados) e `usecase` (opcional — o **ID** do use case que a task realiza, `UC-07`, nunca o nome do arquivo). O `doneCriteria` de uma task com `usecase` carrega a **pós-condição literal**, com o rótulo (`"P2 — cada veterinário traz..."`). Cada entrada no recap.md deve referenciar um ID do tasks.json.
+- `tasks.json` — validada contra `framework/schemas/tasks.schema.json`. Cada task: `id` (T1, T2...), `title`, `description`, `dependencies` (IDs), `effort` (S/M/L/XL), `doneCriteria`, `status` (pending/in_progress/done/skipped/blocked), `outputs` (paths esperados), `usecase` (opcional — **ID** do use case, `UC-07`, nunca o nome do arquivo). `doneCriteria` de task com `usecase` carrega a **pós-condição literal**, com rótulo (`"P2 — cada veterinário traz..."`). Toda entrada do recap.md referencia um ID do tasks.json.
 
-- `decisions.md` — log de decisões técnicas: qual era a alternativa, por que foi descartada, quem decidiu. Criado quando surgir a primeira decisão não trivial. Não é obrigatório — só existe se houver decisões que precisam de rastreabilidade.
+- `decisions.md` — log de decisões técnicas (alternativa descartada, motivo, quem decidiu). Só existe se houver decisão não trivial a rastrear.
 
 ### Implement (`3-implement/`)
 
-- `recap.md` — atualizado ao fim de cada tarefa: ID da tarefa, o que foi feito, arquivos modificados, problemas encontrados e como foram resolvidos, standard consultado. Se não há nada a registrar em alguma dessas categorias, escreva "nenhum" — um recap vazio é pior do que um recap mínimo.
+- `recap.md` — atualizado ao fim de cada task: ID, o que foi feito, arquivos modificados, problemas e resolução, standard consultado. Categoria sem nada a registrar → escreva "nenhum" (recap vazio é pior que mínimo).
 
 ### Review (`4-review/`)
 
-- `review-report.md` — relatório de revisão: scores por dimensão (arquitetura, contratos, qualidade, cobertura), feedback priorizado (bloqueantes primeiro, melhorias depois), aprovação ou rejeição com critérios explícitos. Um review-report.md que só diz "aprovado" sem scores não satisfaz o gate.
+- `review-report.md` — scores por dimensão (arquitetura, contratos, qualidade, cobertura), feedback priorizado (bloqueantes primeiro), aprovação/rejeição com critérios explícitos. "Aprovado" sem scores não satisfaz o gate.
 
 ### Acervo de use cases (`.morph/specs/usecases/`)
 
-O acervo permanente do projeto: `UC-{nn}-{slug}.md`, **commitado** (nenhuma regra do `.gitignore` o cobre). É a descrição viva do comportamento do sistema e sobrevive ao arquivamento das features — diferente dos traces, ele **faz parte da entrega**.
+O acervo permanente do projeto: `UC-{nn}-{slug}.md`, **commitado**. Descrição viva do comportamento do sistema, sobrevive ao arquivamento — diferente dos traces, **faz parte da entrega**.
 
-- **Quem escreve:** `morph-spec finish` promove os use cases da feature para cá **dentro do commit de arquivamento**, na branch `morph/{f}`, com `status: implemented`. O acervo viaja na própria integração, como o estado arquivado (§2.2) — não é um passo pós-merge.
-- **O que é cobrado mecanicamente:** `morph-spec dag {feature}` cruza `tasks.json` com os use cases — referência a um `UC-{nn}` inexistente é **erro** (não despacha), pós-condição órfã e `doneCriteria` parafraseado são avisos. Isso cobre o *encanamento*. Se a pós-condição é **observável em teste** nenhum checker decide: continua sendo critério do Gate 2 e da rubrica `test-coverage`.
-- **Via única de escrita:** a promoção lê **só** de `{feature}/2-plan/usecases/`. Nunca edite `.morph/specs/usecases/` à mão — a edição direta pula o `status: implemented`, a sobrescrita por ID e o commit escopado, e o acervo passa a ter duas verdades. Para mudar um UC existente (o caso `bug`), copie-o para o `2-plan/usecases/` da feature, corrija lá, e deixe o `finish` sobrescrever.
-- **Quando chega na default:** em `--merge`, no merge `--no-ff`; em `--pr`, só quando o PR for mergeado. Correto por construção: o acervo descreve o que foi **integrado**, não o que foi proposto.
-- **Sobrescrita por ID:** um `UC-07` que já existe é substituído pela versão que está sendo integrada, mesmo que o slug tenha mudado. Exatamente um arquivo por ID.
-- **Fail-open:** feature sem `2-plan/usecases/` promove nada, em silêncio. A promoção nunca pode impedir o fechamento de uma feature.
-- **Colisão entre features paralelas:** dois worktrees podem alocar `UC-08` sem se enxergar, porque cada `feature.json` viaja na sua branch. A colisão é **aceita e resolvida no merge**, como conflito de arquivo — coerente com o ownership de §2.2 ("conflito ali é o sinal honesto de escopo sobreposto"). Renumere o UC perdedor e atualize as referências `usecase` no `tasks.json` arquivado daquela feature. Não há alocador central, e não deve haver: um lock global de id reintroduziria entre worktrees a coordenação que a arquitetura evita de propósito.
+- **Quem escreve:** `morph-spec finish` promove os use cases da feature para cá **dentro do commit de arquivamento**, na branch `morph/{f}`, com `status: implemented` — junto com o estado arquivado (§2.2), não um passo pós-merge.
+- **O que é cobrado mecanicamente:** `morph-spec dag {feature}` cruza `tasks.json` com os use cases — `UC-{nn}` inexistente é **erro** (não despacha); pós-condição órfã e `doneCriteria` parafraseado são avisos. Cobre o *encanamento*; se a pós-condição é observável em teste continua sendo critério do Gate 2 e da rubrica `test-coverage`.
+- **Via única de escrita:** a promoção lê **só** de `{feature}/2-plan/usecases/`. Nunca edite `.morph/specs/usecases/` à mão — pula `status: implemented`, a sobrescrita por ID e o commit escopado, criando duas verdades. Mudar um UC existente (caso `bug`): copie para `2-plan/usecases/` da feature, corrija lá, deixe o `finish` sobrescrever.
+- **Quando chega na default:** em `--merge`, no merge `--no-ff`; em `--pr`, só quando mergeado — o acervo descreve o que foi **integrado**, não proposto.
+- **Sobrescrita por ID:** `UC-07` existente é substituído pela versão integrada, mesmo com slug novo — exatamente um arquivo por ID.
+- **Fail-open:** feature sem `2-plan/usecases/` promove nada, em silêncio — a promoção nunca impede o fechamento.
+- **Colisão entre features paralelas:** dois worktrees podem alocar `UC-08` sem se enxergar. Aceita e resolvida no merge, como conflito de arquivo (§2.2) — renumere o UC perdedor e atualize `usecase` no `tasks.json` arquivado. Sem alocador central por design.
 
 ### Traces (`.morph/traces/`)
 
-Cada fase de implementação produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json`.
-O trace registra tarefas, scores de eval, standards consultados e sub-agents despachados.
-O formato canônico está em `.morph/framework/evals/trace-schema.md` (criado na issue #17).
-**O trace é gerado automaticamente pelo hook `trace-autogen`** a cada write de `tasks.json`, a partir de tasks.json + recap.md + `taskScores` do feature.json — as skills não o escrevem à mão (a escrita manual foi removida da cerimônia por task).
-Traces são ignorados pelo git (`.gitignore`) e servem para análise do harness — não fazem parte da entrega da feature.
+Cada fase produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json` (tarefas, scores de eval, standards consultados, sub-agents despachados; formato em `.morph/framework/evals/trace-schema.md`). **Gerado automaticamente pelo hook `trace-autogen`** a cada write de `tasks.json` — as skills não o escrevem à mão. Ignorado pelo git; serve para análise do harness, não é entrega da feature.
 
 ---
 
 ## 4. Como consultar Standards
 
-Standards nunca devem ser carregados todos de uma vez. Consulte sob demanda, por tarefa.
+**Nunca carregue todos os standards de uma vez** — custa tokens sem benefício, você não sabe quais serão relevantes antes de começar. Consulte sob demanda, por tarefa.
 
-O índice de standards fica em `framework/standards/STANDARDS.json`. Cada entrada tem `id`, `name`, `path`, `category`, `tags`.
+Índice em `framework/standards/STANDARDS.json` (`id`, `name`, `path`, `category`, `tags`).
 
 **Fluxo de consulta:**
 
-1. Antes de iniciar uma tarefa, identifique de 1 a 3 standards relevantes — rode `morph-spec standards --find "<domínio/tecnologia da task>"` (o comando devolve o top 3 como `id · path · digest`, sem você abrir o índice inteiro) em vez de filtrar `id`/`tags` à mão no JSON.
-2. Leia apenas o arquivo `.md` daquele standard específico — o path está no campo `path` do JSON.
-3. Aplique o standard durante a implementação. Se precisar de contexto adicional, leia mais um standard.
+1. Antes de iniciar uma tarefa, identifique 1-3 standards relevantes — rode `morph-spec standards --find "<domínio/tecnologia da task>"` (devolve o top 3 como `id · path · digest`) em vez de filtrar `id`/`tags` à mão no JSON.
+2. Leia apenas o arquivo `.md` daquele standard (campo `path`).
+3. Aplique durante a implementação. Se precisar de mais contexto, leia mais um standard.
 4. Registre no recap.md qual standard foi consultado e como foi aplicado.
 
-**Nunca** carregue todos os standards no início da sessão. Isso custa tokens sem benefício — você não sabe quais serão relevantes antes de começar.
-
-**Como identificar o standard certo:** filtre por `category` primeiro (ex: "architecture", "contracts", "testing"), depois por `tags` (ex: "dotnet", "nextjs", "blazor"). Se dois standards parecem relevantes e há conflito, adote o mais específico ao stack do projeto — e registre o conflito no decisions.md.
+**Como identificar o standard certo:** filtre por `category` primeiro (ex: "architecture", "contracts", "testing"), depois por `tags` (ex: "dotnet", "nextjs", "blazor"). Dois standards relevantes em conflito → adote o mais específico ao stack do projeto e registre o conflito no decisions.md.
 
-O agente responsável por um domínio está listado em `.morph/framework/agents.json` (fonte única — os subagents `morph-{id}` em `.claude/agents/` são gerados dele). Consulte o campo `persona` do agente para entender o ponto de vista que você deve adotar ao aplicar os standards daquele domínio quando trabalhar inline. A persona define o nível de rigor esperado: um agente de arquitetura tem critérios mais rígidos do que um agente de suporte mensal.
+O agente responsável por um domínio está em `.morph/framework/agents.json` (fonte única — os subagents `morph-{id}` são gerados dele). O campo `persona` define o ponto de vista e o nível de rigor a adotar ao aplicar os standards daquele domínio trabalhando inline (um agente de arquitetura é mais rígido que um de suporte mensal).
 
-**Quando não há standard adequado:** registre no decisions.md que nenhum standard cobre o caso, descreva o critério que você adotou e sinalize para revisão futura. Não invente um standard — padrões não documentados são dívida técnica disfarçada.
+**Quando não há standard adequado:** registre no decisions.md que nenhum cobre o caso, descreva o critério adotado, sinalize para revisão futura. Não invente um standard — padrão não documentado é dívida técnica disfarçada.
 
 ---
 
 ## 5. Gates de Aprovação (Trust Mode)
 
-Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **auto-passam** se nenhum sinal de risco for detectado — apenas exibem um summary curto. Em `trust: "manual"` OU se um sinal de risco fizer fire, o gate pausa via `AskUserQuestion` com options padrão:
+Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), auto-passam sem sinal de risco — só exibem summary curto. Em `trust: "manual"` OU com sinal de risco, o gate pausa via `AskUserQuestion` com options padrão:
 
 ```
 - "aprovado, prosseguir"
@@ -224,102 +209,78 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **
 - "cancelar feature"   (Gate 3 usa "rollback" em vez de "cancelar")
 ```
 
-**Sinais de risco que forçam pausa em auto** (as skills aplicam estas regras em linguagem natural — a tabela abaixo é a fonte única):
+**Sinais de risco que forçam pausa em auto** (`gate-check` aplica esta tabela via `shouldPauseGate` — fonte única; sinal que só a sessão conhece escala via `gate-decision` manual):
 
 | Sinal | Threshold | Quando aplica |
 |-------|-----------|---------------|
 | `designSystemDivergence` | true | Brainstorming detecta fontes conflitantes (spec antigo vs bundle local) |
 | `standardsViolations` | array.length > 0 | Mandate ou implementation viola padrões proibidos |
-| `evalScore` | < 9 | morph-review produz score composto da feature abaixo do mínimo (o loop de correção intra-task já buscou 9 por task antes daqui) |
+| `evalScore` | < 9 | score composto da feature (via morph-review) abaixo do mínimo |
 | `taskCount` | > 20 | Escopo grande — provavelmente vale revisar antes de implementar |
-| `workType` | === 'hotfix' | Gate 3 pausa SEMPRE para aprovação humana, mesmo em `trust: auto` — o CLI recusa `morph-spec approve <f> review --mode auto` num hotfix |
-
-**Gate 1 — Proposta**
-- Sinais: `designSystemDivergence`, `standardsViolations` (improvável).
-- Skill responsável: `morph-brainstorming`.
-
-**Gate 2 — Plano**
-- Sinais: todos do Gate 1 + `taskCount`, `standardsViolations` em mandate.
-- Skill responsável: `morph-plan`.
+| `workType` | === 'hotfix' | Gate 3 pausa SEMPRE (detalhe abaixo, "Gates por tipo de trabalho") |
 
-**Gate 3 — Review**
-- Sinais: `evalScore` composite, `standardsViolations` detectadas em implementation.
-- Skill responsável: `morph-review`.
+| Gate | Sinais | Skill responsável |
+|------|--------|--------------------|
+| 1 — Proposta | `designSystemDivergence`, `standardsViolations` (improvável) | `morph-brainstorming` |
+| 2 — Plano | Gate 1 + `taskCount`, `standardsViolations` em mandate | `morph-plan` |
+| 3 — Review | `evalScore` composite, `standardsViolations` em implementation | `morph-review` |
 
-**Gates por tipo de trabalho:** `chore` e `hotfix` não passam pelos Gates 1 e 2 — eles são carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`, para não colidir com o gate-guard). A barra de qualidade do morph-eval e o Gate 3 continuam valendo para todos os tipos. Para `hotfix`, o Gate 3 é **sempre humano**: mesmo em `trust: auto` a `morph-hotfix` apresenta o review via `AskUserQuestion` e o `risk-detector` força a pausa; o backstop server-side (`morph-spec approve ... review --mode auto` recusa) garante que nenhum caminho auto passe por cima. O artefato exigido também difere: `hotfix` nunca despacha o avaliador independente, então o Gate 3 exige `4-review/review-report.md` em vez de `evaluator-report.md`; todos os outros tipos continuam exigindo o `evaluator-report.md` (ou `--self-assessed` registrado).
+**Gates por tipo de trabalho:** `chore`/`hotfix` pulam Gates 1 e 2 — carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`, para não colidir com o gate-guard); a barra do morph-eval e o Gate 3 valem para todos os tipos. `hotfix`: Gate 3 **sempre humano** (mesmo em `trust: auto` — `morph-hotfix` pausa via `AskUserQuestion`, o `risk-detector` força, o backstop server-side recusa `approve ... review --mode auto`) e exige `4-review/review-report.md` em vez de `evaluator-report.md`. Demais tipos exigem `evaluator-report.md`, **enforced server-side** (`morph-spec approve {feature} review` recusa exit 1 sem ele; `--force` não dispensa) — ou `--self-assessed` registrado (`approvalGates.review.selfAssessed`, marcado no `morph-spec list`).
 
 Para alterar o modo: editar `.morph/config/config.json → trust` (`"auto"` ou `"manual"`). Configs sem o campo `trust` defaultam para `"auto"`.
 
-**Comportamento padrão fora de gate:** trabalhe com autonomia total. Gates só existem nestes três pontos. Não pause para confirmação no meio de implementação a menos que encontre uma ambiguidade de escopo que o mandate não cobre — nesse caso, registre a ambiguidade no decisions.md, resolva da forma mais conservadora possível, e sinalize na entrega da task.
+**Comportamento padrão fora de gate:** autonomia total — gates só existem nestes três pontos. Não pause no meio de implementação a menos que encontre ambiguidade de escopo que o mandate não cobre — registre em decisions.md, resolva conservadoramente, sinalize na entrega da task.
 
-**A aprovação de gate é unificada nos comandos da CLI — a LLM nunca edita o estado à mão para aprovar um gate.** Em `trust: "auto"` (sem `AskUserQuestion`), a skill aprova o gate via `morph-spec approve <feature> <gate> --mode auto`; para aprovar o gate da fase corrente **e** já criar a pasta da próxima fase num passo só, use `morph-spec advance <feature>` (adicione `--design` para tomar o ramo opcional de uiux a partir da proposta) — isso substitui o Edit manual de state.json + `mkdir` da pasta de fase. Os scores por task também têm comando dedicado: `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. **O hook state-sync.js** cobre o caminho manual: quando uma `AskUserQuestion` é respondida com label começando em "aprovado", ele registra o gate correspondente no `feature.json` autoritativo da feature com `approvedBy: "manual"` (um humano aprovou no loop), na forma canônica. **A feature é identificada pelo nome que a pergunta cita** — e o `feature.json` gravado é o da árvore que possui essa feature (raiz ou worktree), nunca o da "feature ativa" de quem por acaso rodou a sessão. Por isso os templates de gate nomeiam a feature: uma pergunta sem nome, numa árvore com mais de uma feature, faz o hook **recusar a gravar** e avisar — aprove então por `morph-spec approve <feature> <gate>`. Nos dois caminhos o gate acaba gravado em `.morph/features/{feature}/feature.json` — nunca via Edit à mão de `state.json`.
+**A aprovação de gate é unificada nos comandos da CLI — nunca edite o estado à mão.** Em `trust: "auto"` (sem `AskUserQuestion`): `morph-spec approve <feature> <gate> --mode auto`; `morph-spec advance <feature>` aprova o gate corrente **e** já cria a pasta da próxima fase (`--design` para o ramo opcional de uiux). Scores por task: `morph-spec score <feature> <task> <score> [--dims a,c,q,t]` — nunca edite `taskScores` à mão. **O hook state-sync.js** cobre o caminho manual: `AskUserQuestion` respondida com label "aprovado" → registra o gate no `feature.json` autoritativo com `approvedBy: "manual"`. **A feature é identificada pelo nome que a pergunta cita** — grava na árvore que a possui (raiz ou worktree), nunca na "feature ativa" de quem rodou a sessão. Pergunta sem nome, árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve <feature> <gate>`. Gate sempre gravado em `.morph/features/{feature}/feature.json` — nunca via Edit de `state.json`.
 
-**Registre quem aprovou cada gate (`approvedBy`):** o gate é um objeto `{ approved, timestamp, approvedBy }`.
-- `approvedBy: "auto"` — gate avançado por política `trust: auto` sem decisão humana.
-- `approvedBy: "manual"` — um humano aprovou explicitamente (via `AskUserQuestion`, ou, quando `AskUserQuestion` está indisponível em contexto headless, via mensagem em texto do usuário começando em "aprovado"). Em `trust: manual`, todo gate é `"manual"` — nunca grave `"auto"` num gate que um humano aprovou em conversa.
+**Registre quem aprovou (`approvedBy`):** objeto `{ approved, timestamp, approvedBy }`. `"auto"` — política `trust: auto` sem decisão humana. `"manual"` — humano aprovou explicitamente (via `AskUserQuestion`, ou, sem ela em headless, via texto começando em "aprovado"); em `trust: manual` todo gate é `"manual"` — nunca grave `"auto"` num gate que um humano aprovou. Mantém o audit trail honesto nos contextos headless (CI, `claude -p`) onde mais importa.
 
-Isso mantém o audit trail honesto justamente nos contextos headless (CI, `claude -p`) onde ele mais importa.
-
-**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar via `AskUserQuestion` vs auto-aprovar) bateu com a decisão de trust que a skill computou via `shouldPauseGate`. Para isso, a skill **persiste** a decisão no `feature.json` autoritativo da feature antes de agir — via `morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`, que grava `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` com timestamp server-side (shape canônico em `framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão:** o Edit manual de feature.json colide com o hook state-sync, que reescreve o arquivo entre o Read e o Edit ("file modified since read"). Se a ação observada divergir do registro (pausou um gate auto-aprovável, ou auto-aprovou um gate que exigia pausa), o guard injeta um aviso no contexto — a LLM corrige. É um guardrail que nunca bloqueia: a cada conferência ele registra uma linha no activity log (`.morph/logs/activity.json`) com o resultado — `coherent` ou `divergent` — e só injeta aviso quando diverge; sem registro ou erro → silêncio.
+**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar vs auto-aprovar) bateu com a decisão persistida. **Default:** `gate-check <feature> <gate> [--signals <json>] [--json]` decide via `shouldPauseGate`; `--signals` sobrescreve só o que o disco não expõe sozinho (`designSystemDivergence`, `standardsViolations`, `evalScore`). **Escape manual** (sinal que `shouldPauseGate` nem representa, ex.: modo de descoberta): `gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`. Ambos gravam `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` server-side (shape em `framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão** — colide com state-sync. Divergência → o guard injeta aviso no contexto; cada conferência registra `coherent`/`divergent` em `.morph/logs/activity.json` — nunca bloqueia.
 
 ---
 
 ## 6. Sub-agents
 
-A thread principal é o **Orchestrator**. Trabalho de implementação pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — não absorvido inline na thread principal. Delegar não é uma permissão excepcional; é o modo padrão de operação para o caso pesado/multi-domínio. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas — é exatamente o anti-padrão que esta seção existe para evitar.
+A thread principal é o **Orchestrator**. Trabalho pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — é o modo padrão de operação, não uma exceção. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas.
 
 **Despache um sub-agent por padrão quando a tarefa atende a pelo menos um destes gatilhos:**
 
-- **Domínio diferente do contexto corrente** — a task pertence a um domínio (ver `agents.json → domains`) distinto do que você está trabalhando agora (ex: você está no backend e a próxima task é frontend/UI/dados). Cruzar de domínio é o gatilho mais importante: cada domínio tem sua persona e seus standards, e o sub-agent escopado os carrega sem inchar seu contexto.
-- **Esforço L ou XL** (duração estimada > 5 minutos).
+- **Domínio diferente do contexto corrente** (ver `agents.json → domains`) — ex: backend agora, próxima task é frontend/UI/dados. Gatilho mais importante: cada domínio tem sua persona e standards, e o sub-agent escopado os carrega sem inchar seu contexto.
+- **Esforço L ou XL** (> 5 minutos).
 - Mais de 3 tentativas de correção falharam no mesmo problema.
 - Análise de arquivo com mais de 500 linhas.
 - Tarefa repetitiva com mais de 3 instâncias do mesmo padrão.
-- Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes para o fluxo.
+- Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes.
 
-Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do domínio que você já tem carregado em contexto**. Se optar por inline numa task que dispara um gatilho acima, **registre a justificativa em uma linha no decisions.md** ("inline porque o contexto X já está carregado e o overhead de dispatch não compensa") — uma escolha de inline silenciosa numa task pesada/multi-domínio é o anti-padrão.
+Inline (sem dispatch) é aceitável para tasks curtas (S/M) **dentro do domínio já carregado em contexto**. Inline numa task que dispara um gatilho acima → **registre a justificativa em uma linha no decisions.md** — inline silencioso numa task pesada/multi-domínio é o anti-padrão.
 
-**Mecanismo de dispatch:** os agents de domínio são subagents **registrados** (`.claude/agents/morph-{id}.md`, gerados de `agents.json` — a fonte única — na instalação). Despache com `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`): a persona é o **system prompt** do subagent, com tools, model e MCPs definidos por domínio no próprio `agents.json` (ex.: `context7` para docs vivas nos implementadores; Stitch/Gemini/Playwright no `morph-ui-designer`; o `morph-evaluator` é read-only). **Fallback** quando o tipo não está registrado (stack não instalado neste projeto): `general-purpose` com o campo `persona` de `agents.json` colado no prompt, **registrado nas `notes` da task**. O `**Persona:**` do recap registra sempre o mecanismo real usado — nunca uma auto-declaração.
+**Mecanismo de dispatch:** agents de domínio são subagents **registrados** (`.claude/agents/morph-{id}.md`, gerados de `agents.json` na instalação). Despache com `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`) — persona é o **system prompt**, tools/model/MCPs por domínio em `agents.json` (ex.: `context7` nos implementadores; Stitch/Gemini/Playwright no `morph-ui-designer`; `morph-evaluator` é read-only). **Fallback** (tipo não registrado): `general-purpose` com `persona` colado no prompt, **registrado nas `notes` da task**. O `**Persona:**` do recap registra sempre o mecanismo real — nunca auto-declaração.
 
-**Persona de estágio — scout:** além das personas de domínio, existe o `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Despache-o quando precisar de um mapa do território sem contaminar a thread principal — obrigatoriamente no início de um hotfix (localizar root cause + blast radius) e opcionalmente antes do plan de uma feature grande (buscar código, docs e specs anteriores relevantes). Ele devolve um mapa curto como relatório final e encerra; não escreve código.
+**Persona de estágio — scout:** `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Despache para um mapa do território sem contaminar a thread principal — obrigatório no início de um hotfix (root cause + blast radius), opcional antes do plan de uma feature grande. Devolve um mapa curto como relatório final; não escreve código.
 
-**O que passar ao sub-agent:**
-- Especificação da tarefa (do tasks.json)
-- Path do standard relevante (apenas um)
-- Lista de arquivos que ele precisa ler ou modificar
-- Critério de done claro e verificável
+**Passe ao sub-agent:** especificação da tarefa (tasks.json), path do standard relevante (só um), arquivos a ler/modificar, critério de done claro e verificável.
 
-**O que NÃO passar ao sub-agent:**
-- Histórico da conversa principal
-- Contexto de outras tarefas não relacionadas
-- Outputs de ferramentas não pertinentes à tarefa
+**NÃO passe:** histórico da conversa principal, contexto de outras tarefas não relacionadas, outputs de ferramentas não pertinentes.
 
-**O ARQUIVO é o retorno, a última mensagem é cortesia.** Em uso real (feature `config-tenant-split`,
-MORPH_GHLBrain, 2026-07-22 — overnight com dispatch de sub-agents), o evento recebido de volta do
-sub-agent foi só um `idle_notification`, sem o texto — o orquestrador teve que reconstruir o
-relatório do disco e pedir via `SendMessage` que o avaliador o persistisse. A última mensagem de
-texto **pode não chegar** inteira ao orquestrador; por isso ela deixou de ser o canal
-autoritativo. O sub-agent **sempre** grava o relatório também em um arquivo canônico:
+**O ARQUIVO é o retorno, a última mensagem é cortesia.** Em uso real, o evento recebido de volta do
+sub-agent às vezes é só um `idle_notification` sem texto — a última mensagem **pode não chegar**
+inteira ao orquestrador, por isso ela deixou de ser o canal autoritativo. O sub-agent **sempre**
+grava o relatório também em um arquivo canônico:
 
-- Task de implementação: `.morph/features/{feature}/3-implement/reports/{taskId}.md` (um arquivo
-  por task concluída, mesmo quando uma única sessão de sub-agent cobre várias tasks de um fluxo).
-- Avaliador do Gate 3 (`morph-evaluator`): `.morph/features/{feature}/4-review/evaluator-report.md`
-  — o relatório BRUTO do avaliador; a `morph-review` o lê e sintetiza o `review-report.md`
-  apresentado no Gate 3 (os dois nunca colidem: um é saída crua do sub-agent, o outro é a curadoria
-  do orquestrador).
+- Task de implementação: `.morph/features/{feature}/3-implement/reports/{taskId}.md` (um arquivo por task concluída, mesmo quando uma sessão de sub-agent cobre várias tasks de um fluxo).
+- Avaliador do Gate 3 (`morph-evaluator`): `.morph/features/{feature}/4-review/evaluator-report.md` — relatório BRUTO; a `morph-review` o lê e sintetiza o `review-report.md` do Gate 3 (nunca colidem: um é saída crua do sub-agent, o outro é curadoria do orquestrador).
 
-O orquestrador **lê o arquivo** ao retomar controle após o dispatch — nunca confia apenas na
-mensagem de retorno da tool. Se a mensagem de texto final chegou inteira, ótimo (economiza uma
-leitura); se não chegou, o arquivo já está lá.
+O orquestrador **lê o arquivo** ao retomar controle após o dispatch — nunca confia só na mensagem
+de retorno da tool (que, se chegou inteira, só economiza a leitura).
 
 ### Protocolo de ausência de relatório
 
 **"Relatório ausente = o agente falhou" é a leitura errada.** O sub-agent pode ter feito todo o
-trabalho e perdido o meio de gravá-lo — foi o que aconteceu quando um worktree sumiu debaixo de um
-avaliador em execução. Tratar isso como falha joga fora trabalho real.
+trabalho e perdido o meio de gravá-lo (ex.: o worktree sumiu debaixo dele em execução). Tratar isso
+como falha joga fora trabalho real.
 
-A pergunta que decide não é "o relatório chegou?", é **"o TRABALHO entrou?"** — e ela se responde
-por evidência, não pela palavra do agente:
+A pergunta que decide não é "o relatório chegou?", é **"o TRABALHO entrou?"** — respondida por
+evidência, não pela palavra do agente:
 
 ```
 morph-spec report-check <feature> [task] --json
@@ -337,29 +298,26 @@ Sai 0 só em `ok`. Em qualquer caminho degradado a degradação é **registrada*
 `notes` da task —, nunca aceita em silêncio. Segunda ausência sem trabalho entregue é falha real:
 escale ao humano.
 
-**O que receber de volta (no arquivo, e na mensagem final quando ela chega):**
+**O que receber de volta** (no arquivo, e na mensagem final quando ela chega) — os **4 itens obrigatórios** de todo relatório de dispatch:
 - O que foi feito (2-3 frases)
 - Arquivos modificados (lista)
 - Problemas encontrados e como foram resolvidos
 - Auto-score 0-10 com justificativa em uma linha
 
 **Contrato do relatório final** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
-1. **GRAVE o relatório no arquivo canônico do seu dispatch ANTES de encerrar** — é o valor de retorno autoritativo desta sessão, não a sua última mensagem de texto (que é cortesia best-effort e pode não chegar inteira ao orquestrador). Conteúdo obrigatório, idêntico no arquivo: (1) o que foi feito em 2-3 frases, (2) arquivos modificados, (3) problemas encontrados e como foram resolvidos, (4) auto-score 0-10 com justificativa em uma linha. Relatório ausente, oco, ou sem os 4 itens é **falha de protocolo** — registrada no recap. Ainda assim **não chame `SendMessage`**: ele gera um evento a mais (o teammate-message) além da notificação de término, custando um turno inútil ao orquestrador — a mensagem de texto final (cortesia) já é entregue automaticamente.
-2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo orquestrador.
-3. **Verificação em batch paralelo — condicional ao isolamento:** em batch **sem isolamento** (agentes na mesma working tree), não rode build/test da suíte compartilhada — a verificação (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch **com `isolation: "worktree"`** (quando o `morph-spec dag` recomenda, por colisão de `outputs` entre fluxos), a regra se inverte: rode build/test **dentro do seu worktree**, commite o trabalho na branch do worktree como último ato antes do relatório, reporte a branch + status de build, e **nunca** faça merge nem toque na árvore principal — a integração é do orquestrador.
+1. **GRAVE o relatório no arquivo canônico ANTES de encerrar**, com os 4 itens acima — é o retorno autoritativo, não a sua última mensagem (cortesia best-effort, pode não chegar inteira). Ausente/oco/incompleto é **falha de protocolo** — registrada no recap. **Não chame `SendMessage`**: gera um evento a mais além da notificação de término.
+2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão — todo estado é do orquestrador.
+3. **Verificação condicional ao isolamento:** **sem isolamento** → não rode build/test compartilhado, verificação é do orquestrador pós-batch. **Com `isolation: "worktree"`** (`dag` recomenda por colisão de `outputs`) → build/test **dentro do worktree**, commite na branch como último ato, reporte a branch, **nunca** faça merge.
 
-O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais contexto para começar, a tarefa não estava bem especificada — refine antes de despachar.
+Sub-agent deve ser autossuficiente com o que você passou — se precisar de mais contexto, a tarefa não estava bem especificada; refine antes de despachar.
 
-**Quando NÃO despachar sub-agent:**
-- Tarefas curtas onde o overhead de contexto do dispatch custa mais do que a economia de contexto principal.
-- Quando o feedback do sub-agent precisaria ser discutido em tempo real — dispatch é assíncrono.
-- Quando a tarefa envolve mudanças de arquitetura que o Orchestrator precisa validar antes de executar.
+**Quando NÃO despachar:** tarefas curtas onde o overhead do dispatch custa mais que a economia de contexto principal; quando o feedback precisaria ser discutido em tempo real (dispatch é assíncrono); quando a task envolve mudança de arquitetura que o Orchestrator precisa validar antes de executar.
 
-**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa.
+**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. A task só avança quando `morph-eval` der score ≥ 9 (barra única do §0); integre ao recap.md e siga para a próxima tarefa.
 
-> **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
+> **Anti-padrão:** implementar múltiplas tasks de domínios diferentes inline em sequência ("eu já sei o padrão de cada uma") é o sinal de que a delegação foi ignorada. Feature cruzando ≥2 domínios → o default é despachar especialistas, não o Orchestrator virar faz-tudo.
 
-**Dispatch em paralelo (multi-agent):** quando há fluxos de trabalho **genuinamente independentes** (ex: a cadeia de backend e a cadeia de frontend de uma mesma feature, que só convergem no fim), despache múltiplos sub-agents **ao mesmo tempo** — um por fluxo — em vez de processá-los em série. O orquestrador roda `morph-spec dag {feature}` — o comando analisa o DAG de `tasks.json` (por `dependencies` e por `group`), **pondera o esforço** (raízes e fluxos só de tasks S não ganham dispatch próprio: vão inline ou agrupados num único agente) e imprime a decisão pronta. As regras concretas e o cap de agentes simultâneos vivem na skill `morph-apply` (seção "Análise de DAG"). A thread principal coordena; os especialistas executam — inclusive em paralelo. O `morph-spec dag` também detecta colisão de arquivos entre os fluxos paralelos (via os `outputs` planejados no tasks.json) e, quando dois fluxos escreveriam no mesmo path, recomenda `isolation: "worktree"` — nesse caso cada agente trabalha num worktree próprio e o orquestrador integra por merge ao final (protocolo detalhado na `morph-apply` §3b-w). Sem colisão, o batch roda na working tree compartilhada com verificação única pós-batch.
+**Dispatch em paralelo (multi-agent):** fluxos **genuinamente independentes** (ex: backend ‖ frontend, convergindo só no fim) → despache múltiplos sub-agents **ao mesmo tempo**, um por fluxo, em vez de série. `morph-spec dag {feature}` analisa o DAG (`dependencies`/`group`), **pondera o esforço** (raízes/fluxos só de tasks S não ganham dispatch próprio) e imprime a decisão; regras e cap de agentes simultâneos em `morph-apply` ("Análise de DAG"). Colisão de `outputs` entre fluxos → `dag` recomenda `isolation: "worktree"`, cada agente num worktree próprio, orquestrador integra por merge (`morph-apply` §3b-w). Sem colisão: working tree compartilhada, verificação única pós-batch.
 
 O padrão de dispatch e o template de prompt para sub-agents estão detalhados em `framework/skills/core/morph-implement/SKILL.md`.
 
@@ -370,36 +328,30 @@ O padrão de dispatch e o template de prompt para sub-agents estão detalhados e
 Skills são documentos de instrução que você invoca sob demanda. Eles ficam em `framework/skills/core/`.
 Não invoque uma skill fora do momento indicado.
 
-| Skill                 | Path                                               | Quando invocar                                                          |
-|-----------------------|----------------------------------------------------|-------------------------------------------------------------------------|
-| **morph-proposal**    | `framework/skills/core/morph-proposal/SKILL.md`    | **Orquestrador**: brainstorming → Gate 1 → plan → Gate 2 (entry point) |
-| **morph-apply**       | `framework/skills/core/morph-apply/SKILL.md`       | **Orquestrador**: DAG-adaptive implement loop → review → Gate 3        |
-| morph-brainstorming   | `framework/skills/core/morph-brainstorming/SKILL.md` | Invocada pela morph-proposal — entendimento de negócio + stack-scan    |
-| morph-stack-scan      | `framework/skills/core/morph-stack-scan/SKILL.md`  | Detecta stack atual; curto-circuita em greenfield                       |
-| morph-plan            | `framework/skills/core/morph-plan/SKILL.md`        | Invocada pela morph-proposal — produz spec/mandate/tasks.json           |
-| morph-implement       | `framework/skills/core/morph-implement/SKILL.md`   | Invocada pela morph-apply — executa cada task                           |
-| morph-eval            | `framework/skills/core/morph-eval/SKILL.md`        | Após concluir uma task ou fase                                          |
-| morph-review          | `framework/skills/core/morph-review/SKILL.md`      | Invocada pela morph-apply — produz review-report + Gate 3               |
-| morph-hotfix          | `framework/skills/core/morph-hotfix/SKILL.md`      | **Orquestrador**: ADW cirúrgico de hotfix (scout → fix → gate humano → ship) |
-| morph-standards       | `framework/skills/core/morph-standards/SKILL.md`   | Quando precisar localizar ou aplicar um standard específico             |
+Path de cada skill: `framework/skills/core/{nome}/SKILL.md`.
+
+| Skill                 | Quando invocar                                                          |
+|-----------------------|---------------------------------------------------------------------------|
+| **morph-proposal**    | **Orquestrador**: brainstorming → Gate 1 → plan → Gate 2 (entry point) |
+| **morph-apply**       | **Orquestrador**: DAG-adaptive implement loop → review → Gate 3        |
+| morph-brainstorming   | Invocada pela morph-proposal — entendimento de negócio + stack-scan    |
+| morph-stack-scan      | Detecta stack atual; curto-circuita em greenfield                       |
+| morph-plan            | Invocada pela morph-proposal — produz spec/mandate/tasks.json           |
+| morph-implement       | Invocada pela morph-apply — executa cada task                           |
+| morph-eval            | Após concluir uma task ou fase                                          |
+| morph-review          | Invocada pela morph-apply — produz review-report + Gate 3               |
+| morph-hotfix          | **Orquestrador**: ADW cirúrgico de hotfix (scout → fix → gate humano → ship) |
+| morph-standards       | Quando precisar localizar ou aplicar um standard específico             |
 
 **Entry points** para o usuário:
 - `/morph-proposal {feature}` → invoca `Skill(morph-proposal)`, que orquestra brainstorming + plan
 - `/morph-apply {feature}` → invoca `Skill(morph-apply)`, que orquestra implement + review
 - `/morph-hotfix {feature}` → invoca `Skill(morph-hotfix)`, o pipeline cirúrgico de correção em produção
 
-Os slash commands são atalhos: o agente pode chamar `Skill(morph-proposal)` diretamente quando o usuário pede "use /morph-proposal".
-
-Cada skill contém instruções de execução passo a passo. Leia, siga, não desvie sem justificativa registrada no recap.md.
+Slash commands são atalhos: o agente pode chamar `Skill(morph-proposal)` diretamente quando o usuário pede "use /morph-proposal".
 
-Apenas o conjunto `framework/skills/core/` é instalado. As legacy trees `level-0-meta/` e `level-1-workflows/` foram removidas em v5 — o conteúdo útil foi consolidado em core.
-
-Nenhuma skill deve ser invocada proativamente por um hook ou script automático. Skills são instrumentos do modelo — você decide quando a situação pede o nível de rigor que a skill fornece.
+Cada skill contém instruções passo a passo. Leia, siga, não desvie sem justificativa no recap.md. Apenas `framework/skills/core/` é instalado. Nenhuma skill deve ser invocada proativamente por um hook ou script — skills são instrumentos do modelo, você decide quando a situação pede o rigor que a skill fornece.
 
 ---
 
-> **Nota de autoria:** Este documento deve ser revisado e mantido pelo time de engenharia.
-> Alterações de comportamento do harness exigem atualização aqui, não em hooks ou scripts.
-> Versão inicial criada em 2026-04-24. Próxima revisão recomendada após o ciclo completo com NLH.
->
-> Para histórico de decisões sobre este documento, consulte os commits do arquivo.
+> **Nota de autoria:** este documento é mantido pelo time de engenharia. Alterações de comportamento do harness são feitas aqui, não em hooks ou scripts. Histórico de decisões: commits do arquivo.