@polymorphism-tech/morph-spec 8.46.0 → 9.0.0

package/framework/MORPH.md

@@ -1,359 +1,202 @@
 # MORPH.md — Natural Language Harness
 
-> Leia este documento uma vez no início de cada sessão.
-> Ele define papéis, fases, outputs, standards, gates e skills do morph-spec.
-> Não procure instruções em hooks — o harness vive aqui.
+> Leia uma vez por sessão (e de novo após `/compact`). Os comandos imprimem a própria mecânica (sinais, vereditos, próximo passo); referência completa em `.morph/framework/CLI.md`.
 >
-> **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.
+> **Depois de ler:** `.morph/state.json` é um índice fino e gitignored, reconstruído a cada load — use-o só para achar a feature ativa e nunca o edite (a edição se perde no próximo load). O estado autoritativo e commitado é `.morph/features/{feature}/feature.json`. Feature `in_progress` → assuma o papel da fase e continue; sem feature ativa → pergunte qual trabalhar.
 
 ---
 
 ## 0. Contrato de Autonomia
 
-Entre gates, você opera com autonomia total. O dev valida. Você executa.
+Entre gates, você opera sozinho: o dev valida, você executa.
 
 | Situação | O que você faz |
-| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
-| Gate 1 / 2 / 3 aprovado | Avançar para próxima fase imediatamente |
-| Tarefa completada na fase implement | Iniciar a próxima task do tasks.json sem aguardar instrução |
-| Ambiguidade de escopo coberta pelo plano | Resolver conservadoramente e registrar em decisions.md |
-| Ambiguidade bloqueante (requisito ausente ou contraditório) | UMA pergunta via AskUserQuestion |
-| Task implementada (código escrito) | `morph-spec verify <feature> <task>` e cada `doneCriteria` com a evidência que o prova |
-| Verify verde e critérios atendidos | Task `done`, próxima tarefa, sem anúncio |
-| Verify vermelho ou critério sem evidência | Loop de correção autônomo com o feedback, até 3 tentativas, sem pausa humana |
-| 3 tentativas sem fechar | Escalar ao usuário (aceitar/continuar/pular) — único ponto de pausa do loop |
-| `verify` exit 3 (fila pesada cheia) | A fila já esperou: no máximo uma chamada nova, depois avise — nunca laço de espera |
+| --- | --- |
+| Gate aprovado (plano / uiux / review) | Avança para a próxima fase na hora |
+| Fatia relatada na fase implement | Despacha a próxima fatia pronta sem esperar instrução |
+| Ambiguidade de escopo coberta pelo plano | Resolve pelo lado conservador e registra no relatório |
+| Ambiguidade bloqueante (requisito ausente ou contraditório) | Uma pergunta via `AskUserQuestion` |
+| Todas as fatias relatadas | `morph-spec verify <feature>` uma vez, sem filtro, e cada cenário `Cn` com a evidência que o prova |
+| Verify verde e cenários provados | Segue para a review, sem anúncio |
+| Verify vermelho ou cenário sem evidência | Loop de correção autônomo com o feedback, até 3 tentativas, sem pausa humana |
+| 3 tentativas sem fechar | `AskUserQuestion` (aceitar/continuar/pular) — o único ponto de pausa do loop. Nunca uma 4ª tentativa por conta própria nem re-dispatch: sem informação nova, ela repete o erro |
+| `verify` exit 3 (fila pesada cheia) | A fila já esperou: no máximo uma chamada nova, depois avise. Nunca laço de espera |
 
-**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.
+**Regra de ouro:** dúvida que não bloqueia → resolva e registre; dúvida que bloqueia → uma pergunta, no máximo. Vale **depois** do gate do plano: na abertura, o **modo entrevista** (`morph-plan` §3) pergunta até fechar o entendimento, e esse é o comportamento desejado.
 
-**A prova é o código:** `morph-spec verify` (build+testes+validadores) prova o que é determinístico; o `doneCriteria` prova o comportamento. A suíte do Gate 3 roda no CI do projeto (`verify {f} --ci`: mesmo stamp, a máquina fica livre; sem CI, local). Não há nota por task — estilo e estrutura são nota do avaliador do Gate 3, nunca bloqueio.
+**A prova é o código:** `morph-spec verify` prova o determinístico; o cenário `Cn` do `checks.json` prova o comportamento (no CI: `verify {f} --ci`, mesmo stamp). Estilo é nota do revisor, nunca bloqueio.
 
 ---
 
 ## Stack baked-in
 
-O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos que haja ambiguidade real.
+O harness conhece o stack. Só pergunte sobre tecnologia com ambiguidade real.
 
 | Camada | Stack |
-| ------------ | -------------------------------------------------------------------------------------------------- |
+| --- | --- |
 | Backend | .NET 10 + VSA (feature-folder: handler + validator + endpoint + errors + tests) |
 | ORM/DB | EF Core + Neon (Postgres) |
-| IDs | `Guid.CreateVersion7()` (nunca `Guid.NewGuid()`) |
-| Classes | `sealed` por padrão |
-| Erros | Result pattern com `result.Match()` (nunca exceptions como fluxo) |
-| IA | Microsoft Agent Framework (MAF) — quando houver agentes |
+| Erros | Result pattern com `result.Match()` |
+| IA | Microsoft Agent Framework (MAF), quando houver agentes |
 | Frontend | Next.js App Router + Tailwind + Framer Motion + Shadcn |
-| Jobs async | Hangfire — apenas quando há razão real |
+| Jobs async | Hangfire, só com razão real |
 
 Padrões proibidos (valem em todo código; os standards detalham):
-- `Guid.NewGuid()` → `Guid.CreateVersion7()`
-- Classes não-sealed sem justificativa
-- Exceptions como fluxo de controle
-- Camada de Service/Manager entre handler e dados — o handler fala com o `ApplicationDbContext` direto, nunca com um service
-- 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
-- Redeclarar tipo/componente que já existe na mesma feature — `morph-spec graph explain <nome>` antes de criar (sem grafo: `grep -rn`); criar exige veredito `CRIAR` com `why` em `tasks[].reuse`
-
-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`.
+- `Guid.NewGuid()` → `Guid.CreateVersion7()`: o v7 é ordenado no tempo e não fragmenta o índice do Postgres.
+- Classe não-`sealed` sem justificativa: herança aberta por acidente vira contrato que ninguém desenhou.
+- Exception como fluxo de controle: o Result deixa o erro esperado no tipo, e a exception fica para o inesperado.
+- Camada de Service/Manager entre handler e dados: no VSA o handler fala com o `ApplicationDbContext` direto; a camada só repassa chamada.
+- Repository genérico (`IRepository<T>`/`IUnitOfWork`): `DbSet<T>` já é repository e `DbContext` já é unit of work.
+- SQL cru (`FromSqlRaw`, `ExecuteQuery(string)`) sem ADR no `plan.md`: o LINQ é tipado e parametrizado; SQL específico ou concorrência vão para um store dedicado com o porquê no ADR.
+- Redeclarar tipo/componente que já existe: duas definições divergem em silêncio. Antes de criar, `morph-spec graph explain <nome>` (sem grafo: `grep -rn`); criar exige `CRIAR` com `why` em `## Reuso` do `plan.md`.
 
 ---
 
 ## 1. Papéis
 
-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. 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.
+A transição entre papéis é explícita: conclua ou registre no relatório antes de mudar.
 
-**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.
+**Orchestrator** — abertura e transições de fase: escopo, plano, gates. Não escreve código: se começou a implementar, trocou de papel sem querer.
 
-**Evaluator** — ativo no Gate 3, sempre um sub-agent independente com contexto fresco (`morph-evaluator`), nunca quem implementou (enforcement: relatório obrigatório, `--self-assessed`, exceção `hotfix` — **§5**). Segue `.morph/framework/evals/review-checklist.md`: veredito `SHIP`/`FIX` e bloqueador só com evidência (uc, teste, regressão, segurança); o resto é nota. Não roda a suíte (a prova é o verify do orquestrador) e não reescreve código.
+**Specialist** — implementação: executa as fatias do plano, consulta os standards da fatia, grava `3-implement/reports/F{n}.md`. Não cria fatia nova: acréscimo pequeno vai no relatório; fato errado do plano vai em `## Errata` (§3); escopo mudou → `morph-spec unapprove {f} plan`, porque o plano aprovado está congelado.
 
-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.
+**Evaluator** — o Gate 3 são sub-agents com contexto fresco, nunca quem implementou: `morph-verifier` prova cada `Cn` (default NÃO PROVADO), `morph-reviewer` julga o diff (escopo, arquitetura, regressão) e `morph-security` (opus, só com caminho sensível) procura o caminho de exploração. Revisor e segurança leem só o SHA revisado; a mutação do verificador espera os dois. Seguem `.morph/framework/evals/review-checklist.md`: `SHIP`/`FIX`, bloqueador só com evidência tipada. Não rodam a suíte nem reescrevem código.
 
 ---
 
 ## 2. Fases
 
-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, archivedAt); `.morph/state.json` na raiz é só índice fino gitignored derivado dele; identidade do projeto em `.morph/config/config.json` (commitado).
+Cada fase tem pasta em `.morph/features/{feature}/`. Identidade do projeto: `.morph/config/config.json` (commitado).
 
 | Fase | Pasta | Gate | O que termina a fase |
-| ------------- | ---------------- | ----------------------- | ------------------------------------------------- |
-| proposal | `0-proposal/` | Gate 1 (trust-aware) | `proposal.md` aprovado e commitado |
-| plan | `2-plan/` | Gate 2 (trust-aware) | use cases, `spec.md`, `tasks.json` aprovados |
-| 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`/`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`.
+| --- | --- | --- | --- |
+| plan | `2-plan/` | plano (trust-aware) | `plan.md` + `checks.json` (`plan-check`) aprovados |
+| uiux (opcional) | `1-design/` | uiux (trust-aware) | design e checklist de tela aprovados |
+| implement | `3-implement/` | nenhum | toda fatia com relatório final em `reports/F{n}.md` |
+| review | `4-review/` | Gate 3 (trust-aware) | `verifier.md` + `reviewer.md` (+ `security.md`) e o gate aprovado |
 
-A fase `1-design/` é opcional — critério objetivo de entrada em §2.1.
+Sequência: `plan → [uiux] → implement → review`. Não avance sem o gate da fase.
 
-Não avance de fase sem o gate correspondente ter sido confirmado.
+A fase `plan` abre com a escolha do **modo de descoberta** (só `feature`/`bug`): **entrevista** (uma pergunta por vez até a árvore de decisões zerar; o gate do plano pausa sempre, porque confirmar o entendimento compartilhado é o gate) ou **automático** (até 4 perguntas, só sobre nós abertos; gate trust-aware). Nos dois, a varredura roda antes de qualquer pergunta: fato que `morph-spec stack-scan`, o contexto ou os ADRs respondem não vira pergunta. Detalhes em `morph-plan`.
 
 ### 2.1 Roteamento por tipo de trabalho
 
-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:
+Toda feature nasce com `description` obrigatória e um `workType`: `morph-spec create <f> --description "<o quê/porquê>" --type <tipo>` (ou `--request "<pedido>"`, que classifica e semeia a descrição).
 
 | Tipo | Pipeline | Gates |
-| ------ | ---------- | ------- |
-| `feature` | proposal → [uiux] → plan → implement → review (completo) | 1, 2, 3 |
-| `bug` | repro+diagnóstico enxuto (proposal lean) → plan enxuto → implement → review | 1, 2, 3 |
-| `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) |
-
-**Ramo uiux (critério objetivo):** feature/bug que cria ou altera superfície de UI (componente, página, tela, estilo, fluxo de navegação) toma o ramo `1-design/` via `morph-spec advance {feature} --design`; sem superfície de UI, direto para plan. Skill: `morph-uiux`. Avaliado por `morph-proposal`/`morph-brainstorming` no fecho do Gate 1 — não redecida em nenhum outro ponto do pipeline.
+| --- | --- | --- |
+| `feature` | plan → [uiux] → implement → review | plano, [uiux], review |
+| `bug` | plano enxuto (repro + diagnóstico) → implement → review | plano, review |
+| `chore` | `plan.md` curto, gate do plano carimbado por política → implement → review leve | só review |
+| `hotfix` | scout (diagnóstico read-only) → fix cirúrgico → aprovação humana obrigatória → test loop → ship | 3, sempre humano |
 
-**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.
+**Ramo uiux (critério objetivo):** feature/bug que cria ou altera superfície de UI (componente, página, tela, estilo, navegação) toma o ramo `1-design/` depois do gate do plano (`morph-spec advance {feature} --design`, também com o gate já aprovado pelo humano; nunca `1-design/` à mão); sem superfície de UI, direto para implement. Skill: `morph-uiux`. A `morph-plan` §6 decide uma vez; nenhum outro ponto redecide.
 
-**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 e dag).
+**Router:** `create --request` classifica por palavra-chave. Exit 2 (empate ou nenhum sinal) imprime os candidatos: você decide como roteador e re-roda com `--type`. `AskUserQuestion` só quando o pedido é genuinamente indeterminado.
 
-**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).
+**Skip:** `chore`/`hotfix` nascem com o gate `plan` carimbado por política e começam em `implement`; escrevem um `2-plan/plan.md` curto (uma fatia; no hotfix, C1 = sintoma ausente, C2 = regressão) e rodam `plan-check`. Mudança: `morph-spec retype <f> <tipo>` (só antes do Gate 3; o esqueleto intocado do plano sai junto).
 
-**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}`). Fecha-se igual nos dois com `morph-spec finish <f> --pr|--merge` (§2.2). Features pré-modelo (sem branch `morph/{f}`) fecham por `morph-spec archive <f>`, não por `finish`.
+**Branch:** toda feature nasce em `morph/{f}`, ramificada da default, com ou sem `--worktree`, e fecha igual nos dois com `morph-spec finish <f> --pr|--merge` (§2.2).
 
 ### 2.2 Desenvolvimento paralelo por worktree (frota)
 
-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 `worktree setup <f>`) cria `worktrees/{f}/` na branch `morph/{f}`. Contrato:
+Features independentes rodam em paralelo, uma por worktree e uma instância de Claude Code por worktree: `create <f> --worktree` (ou `worktree setup <f>`) na branch `morph/{f}`.
 
-- **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}`; a cópia da raiz é esqueleto do nascimento, nunca mais atualizado — leitores (`list`/`handoff`/`fleet`) seguem a branch, mutadores recusam gravar fora da árvore dona (detalhes: CLI.md). `state.json` do worktree é índice derivável — self-heal, nunca sincronizado à mão.
-- **Só o morph cria worktree:** `worktree setup <f>` (feature) ou `worktree provision <n>` (isolamento de task, branch `morph-task/<n>`). `git worktree add` cru é bloqueado; `EnterWorktree`/`-w`/`isolation:"worktree"` passam pelo hook `WorktreeCreate` e caem no contêiner (`worktrees/` ou `worktree.root`); fora dele = criado sem o morph (`doctor --worktrees`). Já existe: abra o `claude` DENTRO dela; `EnterWorktree(path)` sempre pede aprovação. Infra (`node_modules`, `.claude`, `.morph/framework`) por junction; faltou → `worktree link --all`.
-- **Só o morph remove worktree.** Remoção genérica — `git worktree remove` (com OU sem `--force`), `rm -rf`, `Remove-Item -Recurse`, explorador/IDE — **atravessa a junction** e apaga o conteúdo real da raiz (`.claude`/`node_modules`/`.morph/framework`), saindo com sucesso. Só `morph-spec` desmonta a junction ANTES de remover (PROVE-or-DECLINE): **fechar a feature** = `morph-spec finish <f> --pr|--merge`; **só desmontar o worktree** = `morph-spec worktree remove <f>` — ou `--target <path>` para worktree sem feature. Sobra de sub-agent (`agent-<hex>`): `worktree reap` remove só a que parou limpa e sem commit exclusivo.
-- **Ambiente dedicado:** setup escreve `.morph/worktree.env` (`PORT`, `API_PORT`/`ASPNETCORE_URLS`, `POSTGRES_PORT`, `COMPOSE_PROJECT_NAME=morph-{f}`); cada worktree sobe o **seu** compose. O hook `PreToolUse:Bash` injeta as variáveis em dev server/compose; fora do Claude, `eval "$(morph-spec env)"`. Porta fixa ou `container_name` no compose **reprova o nó e2e** em worktree. `finish` derruba o stack **com volumes** (`--keep-volumes` preserva). Migration destrutiva → integre antes de abrir irmãos. Build/testes/e2e disputam 2 slots por usuário (`heavy status`): **exit 3 = fila cheia, não vermelho** — a fila já esperou, então uma chamada nova no máximo, depois avise; fora do `verify`, `heavy run -- <cmd>`.
-- **Limitação:** `node_modules` é junction compartilhada — dependência mudada afeta os irmãos; integre antes de seguir em paralelo.
-- **Handoff entre sessões:** `.morph/features/{f}/handoff.md` — retomada comprimida, regenerável (`morph-spec handoff <f>`, resolve a árvore dona sozinho), **aponta** para os artefatos em vez de copiá-los. Regenerado em `setup`/`create --worktree`/`advance`/`approve`. **Leia-o antes de re-derivar contexto à mão** — nunca edite manualmente.
-- **Visão da frota:** `fleet` agrega raiz + worktrees (fase, gates, tasks, portas, handoff, commit, sujeira).
-- **Ownership de arquivos:** sem lock runtime — colisão resolve **em plan-time** (`dag` detecta overlap de `outputs`, recomenda `isolation: "worktree"`) e **por construção** (uma feature = um worktree = um escritor).
-- **Fechamento:** aprove o Gate 3, depois **`morph-spec finish <f> --pr|--merge`** — encerramento único; `--merge` integra na hora, **`--pr` não** — só abre o PR. **Arquiva** commitando `features/{f} → archive/{f}` **dentro de `morph/{f}`**: `--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) — fica `aguardando-merge` até o merge, **nunca "entregue" só por `finished: true`**. Worktree desmontado (PROVE-or-DECLINE), portas liberadas; no `--pr` a branch é **preservada**.
+- **Uma feature = um worktree = uma instância.** Duas instâncias na mesma feature: o setup recusa (exit 3).
+- `feature.json` viaja commitado em `morph/{f}`; a cópia da raiz é esqueleto. Mutadores recusam gravar fora da árvore dona.
+- **Só o morph cria worktree:** `worktree setup <f>` (feature) ou `worktree provision <n>` (isolamento de fatia, branch `morph-task/<n>`). `git worktree add` cru é bloqueado; `EnterWorktree`/`-w`/`isolation:"worktree"` passam pelo hook `WorktreeCreate` e caem no contêiner (`worktrees/` ou `worktree.root`); fora dele = criado sem o morph (`doctor --worktrees`). Já existe: abra o `claude` DENTRO dela; `EnterWorktree(path)` sempre pede aprovação. Infra (`node_modules`, `.claude`, `.morph/framework`) entra por junction; faltou → `worktree link --all`.
+- **Só o morph remove worktree.** `git worktree remove` (com ou sem `--force`), `rm -rf`, `Remove-Item -Recurse` e o explorador **atravessam a junction** e apagam o conteúdo real da raiz (`.claude`, `node_modules`, `.morph/framework`), saindo com sucesso. Só o morph desmonta a junction antes de remover: fechar a feature = `morph-spec finish <f> --pr|--merge`; só desmontar = `morph-spec worktree remove <f>` (ou `--target <path>`). Sobra de sub-agent (`agent-<hex>`): `worktree reap` remove só a que parou limpa e sem commit exclusivo.
+- **Ambiente dedicado:** o setup escreve `.morph/worktree.env` (`PORT`, `API_PORT`, `POSTGRES_PORT`, `COMPOSE_PROJECT_NAME=morph-{f}`) e cada worktree sobe o seu compose; o hook de Bash injeta as variáveis (fora do Claude, `eval "$(morph-spec env)"`). Porta fixa ou `container_name` no compose reprova o nó e2e. `finish` derruba o stack com volumes (`--keep-volumes` preserva). Build/testes/e2e disputam 2 slots por usuário (`heavy status`): exit 3 é fila cheia, não vermelho; fora do `verify`, `heavy run -- <cmd>`.
+- **Migração destrutiva → integre antes de abrir irmãos:** os irmãos ramificam do schema velho e quebram no merge.
+- **`node_modules` é junction compartilhada:** dependência mudada afeta todos os irmãos; integre antes de seguir em paralelo.
+- **Handoff:** `.morph/features/{f}/handoff.md` (regenerável por `morph-spec handoff <f>`): leia antes de re-derivar contexto; nunca edite.
+- **Ownership:** sem lock; colisão se resolve no plano (ondas do `plan-check`) e por construção (uma feature = um escritor). Visão agregada: `fleet`.
+- **Fechamento:** aprove o Gate 3 e rode `morph-spec finish <f> --pr|--merge`. `--merge` integra na hora (`--no-ff` local, sem push). **`--pr` não integra:** só abre o PR, e a feature fica `aguardando-merge` até alguém mergear — nunca "entregue" só por `finished: true`. Nos dois, o worktree é desmontado e as portas liberadas.
 
 ---
 
 ## 3. Contratos de Output
 
-Cada fase salva seus artefatos nos caminhos exatos abaixo — não invente 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. Máximo ~2 páginas; além disso, o escopo pede corte 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 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 exigir (detalhe: `morph-plan`).
-
-  **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. Arquivo, `grep` ou texto de prompt não é comportamento: reescreva, ou justifique com `> [!note] Por que artefato:` na linha abaixo. Chega **literal** ao `doneCriteria` da task que a realiza — traduzir ali perde o requisito.
-
-  `id` sequencial **no projeto**, não na feature — alocado por `morph-spec usecase reserve`, nunca por scan manual. 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, lida uma vez por sessão (relida após `/compact`): 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. Inclui `## Contrato de implementação`: standards, proibições da feature, **verificação de runtime** (como o stack sobe, que fluxos são exercitados, setup de auth) — baseline como comando, pré-requisito como predicado. Lido uma vez por sessão (relido após `/compact`).
-
-- `tasks.json` — validada contra `.morph/framework/schemas/tasks.schema.json`. Cada task: `id` (T1, T2...), `title`, `description`, `dependencies` (IDs), `effort`, `doneCriteria`, `status`, `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.
+- `plan.md` — fonte única da feature, esqueleto escrito pelo `create` (chore/hotfix: você o cria), gramática em `morph-spec plan-check --help`: problema, fora de escopo, suposições, cenários `C1..Cn` (observáveis em teste, com `prova:`), decisões em ADR (`**Alcance:** feature|projeto`; conflitos sempre presentes), arquitetura, reuso, fatias `F1..Fn` (persona, standards, ≤ 8 arquivos, `cobre:`) e contrato de implementação (baseline como comando, pré-requisito como predicado). Lido uma vez por sessão e pós-`/compact`.
+- `checks.json` — extraído do `plan.md` por `morph-spec plan-check`, o único escritor; é a régua que o verificador prova item a item.
+- `stack-scan.md` e `scout-map.md` (§6) — insumos do plano.
 
-- `decisions.md` — log de decisões técnicas (alternativa descartada, motivo, quem decidiu). Só existe com decisão não trivial a rastrear.
-
-**Errata no spec congelado:** congelar o CONTRATO não é congelar um ERRO DE FATO. Se a spec afirma sobre o código algo que o código desmente, acrescente um bloco `## Errata` no FIM do arquivo — corpo intacto, append-only, aceito pelo `protect-spec-files` sem revogar gate. Mudança de ESCOPO continua exigindo revogar o gate e re-aprovar.
+**Congelamento:** aprovado o gate do plano, o corpo do `plan.md` trava: quem implementa não afrouxa o critério que prova o trabalho. Congelar o contrato não é congelar um erro de fato: o que o código desmente vai num bloco `## Errata` no fim do arquivo, append-only e fora do `planHash`. Mudança de escopo exige `morph-spec unapprove {f} plan`, `plan-check` e re-aprovar.
 
 ### Implement (`3-implement/`)
 
-- `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 → "nenhum" (recap vazio é pior que mínimo).
-- `evidencias/{taskId}.md` — só em task cujo `doneCriteria` julga saída de LLM (`morph-plan` §5): entrada, modelo, saída, veredito e o nó `evals`, se houver. Lida no Gate 3.
+- `3-implement/reports/F{n}.md` — um por fatia, do sub-agent ou do orquestrador quando inline; ausente = pendente, `PARCIAL` na 1ª linha = parcial. São o registro da implementação (`**Arquivos:**`, `**Standards:**`; não há recap). Formato em `morph-apply`.
+- `3-implement/evidencias/{Cn}.md` — no cenário `prova: eval` (entrada, modelo, saída, veredito) ou `prova: manual` (passo e resultado).
 
 ### Review (`4-review/`)
 
-- `evaluator-report.md` — do avaliador independente: `**Verdict:** SHIP|FIX`, tabela `## Bloqueadores` (tipo + evidência), notas.
-- `review-report.md` — síntese do orquestrador: `**Reviewed-SHA:**`, veredito, bloqueadores e o resultado do e2e.
-
-### Acervo de use cases (`.morph/specs/usecases/`)
-
-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` — com o estado arquivado (§2.2), nunca 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ã, `doneCriteria` parafraseado e vocabulário de artefato sem `Por que artefato:` são avisos. Cobre o *encanamento*; se a pós-condição é observável em teste continua sendo critério do Gate 2 e do avaliador.
-- **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:** `usecase reserve` aloca de um contador comum aos worktrees; colisão residual faz o `finish` recusar promover só aquele UC (recuperação que ele prescreve: renumere e promova à mão).
-
-### Traces (`.morph/traces/`)
-
-Cada fase produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json` (formato em `.morph/framework/evals/trace-schema.md`). **Gerado automaticamente pelo hook `trace-autogen`** a cada write de `tasks.json`, nunca à mão. Ignorado pelo git: análise do harness, não entrega da feature.
+- `verifier.md`, `reviewer.md`, `security.md` (só com caminho sensível) — `**Verdict:** SHIP|FIX`, `**Reviewed-SHA:**`, `## Bloqueadores` (tipo + evidência), notas. O do verificador traz `## Checks` (`| Cn | PROVADO|NÃO PROVADO|FALHA | evidência |`). Append-only: vale o último veredito.
 
 ---
 
 ## 4. Como consultar Standards
 
-**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.
+Nunca carregue todos os standards: custa contexto em toda chamada e você não sabe quais importam antes de começar. Disclosure progressivo, por fatia:
 
-Índice em `.morph/framework/standards/STANDARDS.json` (`id`, `name`, `path`, `category`, `tags`).
+1. `morph-spec standards --find "<domínio/tecnologia da fatia>"` → top 3 como `id · path · digest`, com as âncoras de seção. O `digest` costuma bastar.
+2. Não bastou → `morph-spec standards --show <id>#<âncora>` imprime só aquela seção.
+3. Só então o arquivo inteiro (campo `path`), quando precisar do exemplo completo.
+4. Registre no `**Standards:**` do relatório qual standard aplicou. Dois em conflito → o mais específico ao stack, com o conflito no relatório. Nenhum cobre o caso → registre o critério adotado; não invente standard, porque padrão não documentado é dívida disfarçada.
 
-**Fluxo de consulta:**
-
-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.
-
-**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á 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 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.
+Inline, o campo `persona` do domínio em `.morph/framework/agents.json` dá o ponto de vista e o rigor.
 
 ---
 
 ## 5. Gates de Aprovação (Trust Mode)
 
-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, pausam via `AskUserQuestion` com options padrão:
-
-```
-- "aprovado, prosseguir"
-- "preciso ajustar"
-- "cancelar feature"   (Gate 3 usa "rollback" em vez de "cancelar")
-```
-
-**Sinais de risco que forçam pausa em auto** (`gate-check` decide via `shouldPauseGate` — fonte única; sinal que só a sessão conhece escala via `gate-decision` manual):
+Em `trust: "auto"` (default, `.morph/config/config.json → trust`), um gate sem sinal de risco passa com um resumo curto. Em `trust: "manual"` ou com sinal de risco, pausa via `AskUserQuestion` com as opções `"aprovado, prosseguir"` / `"preciso ajustar"` / `"cancelar feature"` (no Gate 3, `"rollback"` no lugar de cancelar).
 
-| Sinal | Threshold | Quando aplica |
-|---|---|---|
-| `designSystemDivergence` | true | Fontes de design conflitantes |
-| `standardsViolations` | array.length > 0 | Plano ou código viola padrões proibidos |
-| `evaluatorVerdict` | ≠ SHIP, bloqueador, ou ausente | Veredito do `evaluator-report`: `FIX`, bloqueador aberto, bloqueador sem tipo, ou relatório sem `**Verdict:**`. Só no **ship** |
-| `verificationStatus` | === 'fail' | `verify` vermelho — build, testes, validadores **ou e2e**. Vale em **qualquer** gate |
-| `verificationStale` | true | Stamp do `verify` com sha != HEAD: o verde é de outro código. Só no **ship** |
-| `e2eSkipClass` (derivada) | environment/requested/unknown | e2e pulou sem dispensa legítima (só `project`/`scope`). Só no **ship** |
-| `verificationScope` | !== `feature` (presente) | Stamp do `verify` é de escopo parcial (`task:{id}`) — não cobre a feature inteira. Só no **ship** |
-| `promptModel` | prompt/modelo tocado | Sem nó `evals` declarado, ou eval pulado neste verify. Só no **ship** |
-| `mediaClaims` | seção ausente | Feature que gera mídia, relatório sem `## Mídia gerada`. Só no **ship** |
-| `screenChecklist` | item em aberto | **uiux**: tela sem checklist completo, ou nenhuma `## Tela:`. **ship**: item decidido sem linha em `## Checklist de tela` |
-| `taskCount` | > 20 | Escopo grande — revise antes de implementar |
-| `oversizedTasks` | > 8 `outputs` | Task não cabe num dispatch. Só no **plano** |
-| `workType` | === 'hotfix' | Gate 3 pausa SEMPRE (ver "Gates por tipo de trabalho") |
+**Quem decide é o código:** `morph-spec gate-check <feature> <gate>` coleta os sinais do disco, decide a pausa (`shouldPauseGate`), grava `gateDecisions` e imprime o sinal que pausou. Só o que a sessão sabe e o disco não mostra entra por `--signals`:
 
-| Gate | Sinais | Skill responsável |
-|---|---|---|
-| 1 — Proposta | `designSystemDivergence`, `standardsViolations` | `morph-brainstorming` |
-| 2 — Plano | Gate 1 + `taskCount`, `oversizedTasks`, `standardsViolations` no plano | `morph-plan` |
-| uiux — Design | `screenChecklist` | `morph-uiux` |
-| 3 — Review | `evaluatorVerdict`, `standardsViolations` em implementation, `verificationStale`, `verificationScope`, `e2eSkipClass`, `promptModel`, `mediaClaims`, `screenChecklist` | `morph-review` |
+| Sinal | Quando você o passa |
+| --- | --- |
+| `designSystemDivergence` | fontes de design conflitantes (tokens, versão, fonte aprovada) |
+| `standardsViolations` | plano ou código viola um padrão proibido (lista não vazia) |
 
-**Gates por tipo de trabalho:** `chore`/`hotfix` pulam Gates 1 e 2 — carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`); o Gate 3 vale para todos os tipos. `hotfix`: Gate 3 **sempre humano** (mesmo em `trust: auto`; `approve ... review --mode auto` recusa) e exige `4-review/review-report.md` em vez de `evaluator-report.md`. Demais tipos exigem `evaluator-report.md`, **enforced server-side** (`approve {feature} review` recusa sem ele; `--force` não dispensa) — ou `--self-assessed` registrado (`approvalGates.review.selfAssessed`, marcado no `morph-spec list`).
+Risco que nenhum sinal representa: `morph-spec gate-decision <feature> <gate> --pause <bool> --reason <txt>`. Nunca edite `gateDecisions` à mão — colide com o hook `state-sync`. A tabela completa de sinais está em CLI.md (`gate-check`).
 
-Modo: `.morph/config/config.json → trust` (`"auto"`, o default, ou `"manual"`).
+**Gates por tipo:** `chore`/`hotfix` pulam o gate do plano (carimbado por política no nascimento); o Gate 3 vale para todos. Em `hotfix` o Gate 3 é sempre humano, mesmo em `trust: auto` (`approve … review --mode auto` recusa; use `--approver`), e exige só `4-review/verifier.md`, escrito pelo orquestrador. Os demais exigem `verifier.md` e `reviewer.md` (+ `security.md` com caminho sensível), cobrados pelo `approve` — ou `--self-assessed`, que fica registrado e marcado no `list`.
 
-**Comportamento padrão fora de gate:** autonomia total — só pausa nestes três pontos. Ambiguidade de escopo fora do plano: registre em decisions.md, resolva conservadoramente, sinalize na entrega da task.
-
-**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** cria a pasta da próxima fase (`--design` = ramo opcional de uiux). **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 dona dela, nunca na "feature ativa" da sessão. Pergunta sem nome numa árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve`.
-
-**Registre quem aprovou (`approvedBy`):** objeto `{ approved, timestamp, approvedBy }`. `"auto"` — política `trust: auto` sem decisão humana. `"manual"` — humano aprovou (via `AskUserQuestion` ou, em headless, texto iniciado em "aprovado"); em `trust: manual` todo gate é `"manual"` — nunca `"auto"` num gate humano.
-
-**O hook gate-guard.js** confere, sem bloquear, se a ação 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 (`designSystemDivergence`, `standardsViolations`). **Escape manual** (sinal que `shouldPauseGate` não representa): `gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`. Ambos gravam `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` server-side (`.morph/framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão** — colide com state-sync. Divergência → o guard avisa no contexto.
+**Aprovar é sempre pela CLI, nunca editando o estado:** em `trust: auto`, `morph-spec approve <feature> <gate> --mode auto`, ou `morph-spec advance <feature>` (aprova e cria a pasta da próxima fase; `--design` toma o ramo uiux). No caminho humano, o hook `state-sync` grava a resposta do `AskUserQuestion` que começa com "aprovado" ou contém "pode avançar", "pode implementar" ou "pode prosseguir"; outra frase não grava, e aí se aprova por `morph-spec approve`. **A pergunta nomeia a feature** ("Gate do plano — Plano de {feature} aprovado?"): é por esse nome que o hook acha o `feature.json` certo, e sem nome numa árvore com mais de uma feature ele recusa gravar.
 
 ---
 
 ## 6. Sub-agents
 
-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; feature cruzando ≥2 domínios → o default é despachar especialistas.
-
-**Despache um sub-agent por padrão quando a tarefa atende a pelo menos um destes gatilhos:**
-
-- **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.
-
-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.
+Trabalho pesado ou de outro domínio vai para um sub-agent com persona e standards escopados — o modo padrão, porque ele carrega o domínio sem inchar o contexto principal. Despache quando houver:
 
-**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.
+- **domínio diferente do corrente** (backend agora, a próxima fatia é frontend/UI/dados) — o gatilho mais importante;
+- esforço L/XL (> 5 min), arquivo com mais de 500 linhas, mais de 3 repetições do mesmo padrão, ou detalhe de baixo nível que contaminaria o contexto.
 
-**Persona de estágio — scout:** `morph-scout` (read-only). Localiza com `morph-spec graph affected|explain` e cai para grep sem grafo. Obrigatório no início de um hotfix (root cause + blast radius), opcional antes do plan de feature grande (`morph-plan` §1b). Devolve um mapa (Observado/Inferido); não escreve código.
+Inline vale para fatia pequena no domínio já carregado; inline numa fatia que dispara um gatilho exige uma linha de porquê no relatório. Não despache quando o overhead passa da economia ou a fatia muda arquitetura que você precisa validar antes.
 
-**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.
+**Mecanismo:** `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`); a persona é o system prompt, gerada de `agents.json` em `.claude/agents/`. `morph-verifier`, `morph-reviewer`, `morph-security` e `morph-scout` são read-only. Tipo não registrado: `general-purpose` com o `persona` colado no prompt, registrado no relatório da fatia.
 
-**NÃO passe:** histórico da conversa principal, contexto de outras tarefas não relacionadas, outputs de ferramentas não pertinentes.
+**Scout:** `morph-scout` localiza com `morph-spec graph affected|explain` e cai para grep sem grafo. Obrigatório no início de um hotfix, default no plano de feature grande ou brownfield (`morph-plan` §4). Devolve um mapa (Observado/Inferido) em `2-plan/scout-map.md`; rode `morph-spec scout-check <mapa> --json` antes de usá-lo. Reprovado → re-despache uma vez com as falhas; segunda reprovação → grep você mesmo e escale.
 
-**O ARQUIVO é o retorno, a última mensagem é cortesia.** O evento de volta do sub-agent às vezes é só
-um `idle_notification` sem texto — a última mensagem **pode não chegar** inteira, por isso não é o
-canal autoritativo. O sub-agent **sempre** grava o relatório num arquivo canônico:
+**O prompt leva só o que muda por fatia** (`morph-apply` §3): cenários que ela cobre, arquivos, standards, caminho do relatório. As cláusulas fixas de todo dispatch de implementador vivem no corpo gerado da persona (`## Contrato de dispatch`), o único texto que todo dispatch carrega. Não passe histórico da conversa nem saída de outras tarefas.
 
-- 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; a mensagem, se chegou inteira, só poupa a leitura.
+**O arquivo é o retorno; a última mensagem é cortesia.** O evento de volta às vezes é só um `idle_notification` sem texto, então a mensagem pode não chegar. O sub-agent sempre grava o relatório no caminho canônico — `3-implement/reports/F{n}.md` por fatia; `4-review/{verifier,reviewer,security}.md` no Gate 3 — e o orquestrador lê o arquivo ao retomar o controle.
 
 ### Protocolo de auditoria do relatório
 
-**"Relatório ausente = o agente falhou" é a leitura errada** — ele pode ter feito o trabalho e
-perdido o meio de gravá-lo (ex.: o worktree sumiu). E relatório PRESENTE também não
-basta: um gravado cedo demais fica completo e desatualizado.
-
-A pergunta que decide não é "o relatório chegou?", é **"o TRABALHO entrou, e é isto que ele diz?"** —
-respondida por evidência, não pela palavra do agente:
-
-```
-morph-spec report-check <feature> [task...] --json
-```
-
-| veredito | o que significa | ação |
-| --- | --- | --- |
-| `ok` | relatório presente, com arquivos e critérios, e mais novo que o trabalho | siga o fluxo |
-| `report-stale` | relatório completo mas **VELHO**: a task escreveu arquivos DEPOIS de ele ser gravado (o agente relatou cedo e continuou; ex.: "teste ainda não escrito" com os testes já no disco) | **não re-despache** — leia `observed` (writes reais do `events.jsonl`, não `outputs` auto-declarado) e atualize o relatório a partir dessa evidência |
-| `report-incomplete` | relatório existe, faltam itens (ele lista quais) | complete a partir da mensagem de retorno, carimbe **DEGRADADO** |
-| `work-landed-report-missing` | sem relatório, mas os `outputs` da task estão no disco | **não re-despache** — grave você mesmo o relatório canônico a partir da mensagem de retorno, carimbado **DEGRADADO** |
-| `no-work-no-report` | sem relatório e sem output | re-despache **uma** vez com o mesmo prompt |
-| `report-missing-evidence-unknown` | sem relatório e a task não declarou `outputs` | re-despache (sem evidência, o conservador é o certo) |
-
-Sai 0 só em `ok`. Todo caminho degradado é **registrado** no recap e nas `notes` da task, nunca
-aceito em silêncio. Segunda ausência sem trabalho entregue é falha real: escale ao humano.
+Relatório ausente não prova que o agente falhou, e relatório presente não prova que ele está certo (um gravado cedo fica completo e velho). A pergunta é "o trabalho entrou, e é isto que ele diz?", respondida por evidência: `morph-spec report-check <feature> [F1 F2 …] --json` dá o veredito e a ação (`hint`) de cada fatia, e a tabela de ação está em `morph-apply` §5. `report-stale` e `work-landed-report-missing` nunca se resolvem re-despachando: o trabalho já entrou. Caminho degradado fica no relatório (DEGRADADO); segunda ausência sem trabalho é falha real, escale.
 
-**Mapa do scout:** grave-o em `2-plan/scout-map.md` e rode `morph-spec scout-check <mapa> --json` antes de usá-lo. Reprovado → descarte e re-despache **uma** vez com as falhas no prompt; o mapa novo abre com o motivo. Segunda reprovação: grep você mesmo e escale. Fato que muda o plano se confere com grep próprio, mesmo aprovado.
+**Teto de turnos:** `maxTurns` por persona no `agents.json` (implementadores 120), anunciado no corpo da persona. O corte é cego: `wip` por marco e, a ~70% do teto, relatório `PARCIAL` — o `report-check` o lê como `report-incomplete` com ação `resume`: retome o mesmo agente, não carimbe DEGRADADO.
 
-**O que receber de volta** (no arquivo, e na mensagem final quando ela chega):
-- O que foi feito (2-3 frases)
-- **Arquivos:** lista
-- **Critérios:** cada `doneCriteria`, atendido (com o teste ou `arquivo:linha`) ou não (por quê)
-- Problemas encontrados e como foram resolvidos
-
-**Contrato do relatório final:** as oito cláusulas que todo prompt de dispatch inclui vivem nos DOIS templates — `morph-implement` §4 e `morph-apply` §3b — e não são repetidas aqui: duas cópias da mesma regra divergem, e quem manda é a que o sub-agent recebe. **4-8** (escopo, sobrevivência, processos, retorno, mutação) são idênticas **palavra por palavra**, e um canário as compara; **1-3** (relatório, estado, teste) dizem o mesmo na redação de cada template.
-
-**Teto de turnos:** `maxTurns` por persona no `agents.json` (sem o campo, 20; implementadores 120), anunciado ao sub-agent no corpo da persona. O corte é cego: a cláusula 5 manda `wip` por marco e, a ~70% do teto, relatório `PARCIAL` sem critério dado como atendido (`report-incomplete`): retome o agente, não carimbe DEGRADADO.
-
-Sub-agent deve ser autossuficiente: se precisaria de mais contexto, refine a tarefa antes de despachar.
-
-**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 o retorno:** a task só avança com `verify` verde e cada critério com evidência (§0).
-
-**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.
+**Paralelo:** fluxos genuinamente independentes (backend ‖ frontend) vão ao mesmo tempo, um agente por fatia, até 4. `morph-spec plan-check {feature}` imprime as ondas (fatias sem `depende:` comum e sem arquivo em comum). Colisão que escapou do plano → a segunda fatia vai num worktree próprio, em rolling: a cada relatório o orquestrador integra por merge e despacha a próxima pronta (`morph-apply` §4). A feature só segue para a review com `verify` verde e cada cenário com evidência (§0).
 
 ---
 
 ## 7. Skills disponíveis
 
-Skills são documentos de instrução que você invoca sob demanda.
-Não invoque uma skill fora do momento indicado.
-
-Path de cada skill: `.claude/skills/{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-uiux | Ramo opcional uiux (§2.1) — design system, mockups, componentes, fluxos |
-| morph-plan | Invocada pela morph-proposal — produz use cases, spec.md e tasks.json |
-| morph-implement | Invocada pela morph-apply — executa cada task |
-| 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 |
-| morph-media | Imagem/vídeo por IA — modelo, prompt versionado, custo, gate humano |
-| morph-machine | Máquina lenta/sem RAM, "⏳ não rodou" ou exit 3, sobra de worktree de sub-agent, sub-agents pesados em paralelo |
-
-Slash commands (`/morph-proposal`, `/morph-apply`, `/morph-hotfix`) são atalhos da `Skill()` correspondente; chame-a direto quando o usuário pedir "use /morph-proposal".
-
-Cada skill traz instruções passo a passo: siga, e justifique desvio no recap.md. Só as skills **core** são instaladas; nenhum hook as invoca — você decide quando a situação pede o rigor dela.
-
----
+**Skills core** (`.claude/skills/{nome}/SKILL.md`, invocadas no momento indicado na descrição de cada uma): `morph-plan` (entrada: roteia, varre, entrevista, `plan.md`, gate do plano) · `morph-apply` (fatias → verify → review) · `morph-uiux` · `morph-review` · `morph-hotfix` · `morph-standards` · `morph-media` · `morph-machine`.
 
-> **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.
+`/morph-proposal` → `morph-plan`, `/morph-apply` e `/morph-hotfix` são atalhos da skill. Desvio do passo a passo vai justificado no relatório.