@polymorphism-tech/morph-spec 8.44.0 → 8.45.0

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

@@ -4,180 +4,130 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-apply
 
 ## Objetivo
 
-Executar todas as tasks pendentes de uma feature até `done`, aplicando `morph-eval` após cada uma, e finalizar com `morph-review` + Gate 3.
+Levar toda task pendente a `done` — `verify` da task verde e `doneCriteria` atendido — e fechar
+com `morph-review` + Gate 3.
 
 ## Quando invocar
 
-- Após Gate 2 aprovado (verificar `.morph/features/{feature}/feature.json → approvalGates.plan.approved === true`).
-- Usuário pede "use /morph-apply {feature}" ou "implementar {feature}".
+Gate 2 aprovado (`feature.json → approvalGates.plan.approved`), ou o usuário pede "use /morph-apply
+{feature}". Sem argumento: a feature `in_progress` mais recente.
 
-## Argumentos
+## Ritmo
 
-- `{feature-name}` — nome da feature. Se ausente, usar a feature `in_progress` mais recente em `state.json`.
-
-## Pré-condições
-
-- `.morph/features/{feature}/2-plan/tasks.json` existe e é válido (schema check).
-- `.morph/features/{feature}/2-plan/spec.md` e `mandate.md` existem.
-- Gate 2 está marcado aprovado no `feature.json` da feature (ou trust:auto está ativo).
+Comando em primeiro plano; o `verify {feature}` que passa do teto de 10 min do Bash vai com
+`run_in_background` e espera a notificação de término. `verify` com exit 3 (`status: "busy"`) já esperou a fila pesada
+pelo timeout dela: no máximo uma chamada nova; persistiu, pare e avise o usuário — a máquina está
+saturada (skill `morph-machine`). Nunca `sleep`/`until` nem retentativa agendada.
 
 ## Fluxo
 
 ### 1. Carregar contexto
 
-- Ler `.morph/config/config.json → trust`.
-- **Use a tool Read** em `.morph/features/{feature}/2-plan/tasks.json` para carregar as tasks (ids, `dependencies`, `effort`, `group`, `status`, `doneCriteria`). Não escreva scripts para isso — o parse e a validação de schema acontecem no comando CLI do passo 2.
-
-### 2. Análise de DAG — decisão sequencial vs paralelo
+`.morph/config/config.json → trust` e Read em `2-plan/tasks.json` (ids, `dependencies`, `effort`,
+`group`, `status`, `doneCriteria`).
 
-Rode o comando CLI (ele parseia o tasks.json, valida o schema e pondera o esforço):
+### 2. Análise de DAG — sequencial vs paralelo
 
 ```
 morph-spec dag {feature}
 ```
 
-O comando analisa `dependencies`, `group` e `effort` das tasks pendentes e imprime a decisão pronta com justificativa. As regras que ele aplica (e que você segue):
-
-1. Se `tasks.length <= 3`: **sequencial** (overhead de Agent dispatch não compensa).
-2. **Fluxos de domínio independentes (o caso comum — backend ‖ frontend).** Grupos cujas tasks não dependem de tasks de outro grupo formam fluxos paralelos (as cadeias só convergem, se convergirem, numa task final de integração). **≥ 2 fluxos independentes com peso de esforço suficiente** → dispache **um sub-agent por fluxo, em paralelo**, cada um com a persona e o standard do seu domínio (ver passo 3b).
-3. **Raízes independentes (fan-out na largura).** Tasks 100% independentes (`dependencies: []`). **≥ 3 raízes com effort M ou maior** → dispachar essas raízes em **paralelo**, depois cair em sequencial para o resto.
-4. Caso contrário: **sequencial puro** com auto-advance.
-
-> O `dag` também imprime uma recomendação de **isolamento**: se dois fluxos paralelos planejam escrever no mesmo path (colisão de `outputs`), ele reporta `isolation.recommended: "worktree"` — nesse caso siga a §3b-w em vez da §3b.
-
-> **Peso de esforço:** a decisão é ponderada por `effort` (S=1, M=2, L=4, XL=8). **Raízes e fluxos compostos só de tasks S não ganham dispatch próprio** — overhead > trabalho. O comando os lista como `inline` (você os executa no modo sequencial) ou os agrupa num **único** agente quando são muitos. O cap de **4 agentes simultâneos** (anti-padrão abaixo) vale para ambas as formas. Se um fluxo de domínio é uma cadeia longa, despache o **fluxo inteiro** a um sub-agent (que executa a cadeia em ordem internamente) — um agente por fluxo, não um agente por task.
+Ele lê `dependencies`, `group` e `effort` (S=1, M=2, L=4, XL=8) e imprime a decisão:
+- ≤ 3 tasks → **sequencial**.
+- ≥ 2 fluxos de domínio independentes com peso (backend ‖ frontend) → **um sub-agent por fluxo, em
+  paralelo** (§3b); cadeia longa vai inteira ao agente do fluxo.
+- ≥ 3 raízes independentes de effort ≥ M → raízes em **paralelo**, o resto sequencial.
+- Senão, sequencial com auto-advance. Raiz S roda `inline`.
 
-> **DAG × gatilho de effort — decisões ortogonais que coexistem:** a decisão deste comando governa o **paralelismo ENTRE tasks** (quantos sub-agents ao mesmo tempo: fluxos/raízes independentes em batch). O gatilho de effort/domínio de `morph-implement` §4 governa o **dispatch INDIVIDUAL** de cada task quando ela chega ao topo do loop sequencial. `DAG: sequencial` significa "uma task por vez, na ordem" — **NÃO significa "tudo inline"**. Exemplo: cadeia única backend de 12 tasks → o DAG decide sequencial; T7 tem effort L → ao chegar em T7, o orquestrador a despacha **sozinha** para `morph-dotnet-senior` e aguarda o retorno (um agente por vez); T8 (S, mesmo domínio já carregado) roda inline. As duas regras nunca conflitam: o DAG decide *quantos ao mesmo tempo*, o gatilho de effort decide *quem executa cada task*.
-
-Registre a linha de decisão que o comando imprimiu, por exemplo:
-```
-DAG: 14 tasks, fluxos {backend:9, frontend:2} independentes (peso 18‖4) → 2 fluxos paralelos + T14 (integração) sequencial no fim
-DAG: 12 tasks, 4 raízes independentes (3 com peso ≥ M) → parallel batch (T1, T3, T7) + T9 (S) inline + restante sequencial
-```
+`isolation.recommended: "worktree"` (dois fluxos escrevem o mesmo path) → §3b-w. O DAG decide
+quantas tasks ao mesmo tempo; o `morph-implement` §4 decide quem executa cada uma —
+`DAG: sequencial` não significa "tudo inline". Registre a linha de decisão que o comando imprimiu.
 
 ### 3a. Modo Sequencial (auto-advance)
 
-Loop:
 ```
 while (true):
-  ready = tasks 'pending' cujas dependencies estão todas 'done' (releia tasks.json)
-  if ready.length === 0:
-    break
-
+  ready = tasks 'pending' com todas as dependencies 'done' (releia tasks.json)
+  if ready vazio: break
   task = ready[0]
-  marcar task.status = 'in_progress' em tasks.json (tool Edit — só campos mutáveis)
+  marcar task.status = 'in_progress' (Edit, só campos mutáveis)
 
-  // Loop de correção autônomo — a barra de qualidade é >= 9 (ver MORPH.md §0).
-  // Entre tasks NÃO há pausa humana: score < 9 dispara re-implementação, não AskUserQuestion.
-  attempt = 0
-  best = { score: 0, output: null }
-  skillLoaded = false   // true assim que Skill(morph-implement) foi invocada nesta sessão
+  attempt = 0; feedback = null; pronto = false
   while attempt < 3:
     attempt += 1
+    // attempt 1: invoke Skill(morph-implement) with task. Nas seguintes, aplique o
+    // feedback direto ao código — reinvoque a skill só depois de /compact ou numa
+    // sessão nova, que descartam o conteúdo dela.
+    implementar (ou corrigir com feedback)
+
+    // OUTPUTS ANTES DO VERIFY: o recorte por task lê `outputs`.
+    atualizar task.outputs em tasks.json (divergiu do plano → `notes` na mesma edição)
 
-    if attempt == 1 or not skillLoaded:
-      // attempt 1 sempre invoca — é o que carrega mandate/spec/standard/persona
-      // pela primeira vez. Reinvoca também se skillLoaded caiu para false (ver nota).
-      invoke Skill(morph-implement) with task
-        (no attempt > 1: passar o feedback priorizado da tentativa anterior como input)
-      skillLoaded = true
-    else:
-      // attempt > 1, skill já em contexto desde attempt 1: NÃO reinvoque a Skill —
-      // aplique o feedback priorizado direto ao código já implementado (mesma
-      // lógica do passo 1 do morph-implement, "isto NÃO é implementação do zero",
-      // só que sem reler o documento inteiro da skill de novo).
-      aplicar feedback priorizado da tentativa anterior ao código já implementado
-
-    // OUTPUTS ANTES DO VERIFY — o recorte por task lê `outputs` de tasks.json.
-    // Grave neles (campo mutável, tool Edit) os arquivos REAIS desta tentativa: do
-    // relatório `3-implement/reports/{task.id}.md` quando despachada, do que você
-    // escreveu quando inline. Divergiu do plano → `notes` na mesma edição.
-    atualizar task.outputs em tasks.json
-
-    // CÓDIGO ANTES DO JUIZ — barreira determinística e barata (build+testes+validadores).
-    // Loop por task: o recorte é AUTOMÁTICO — o `group` da task escolhe os nós e os
-    // arquivos de teste de `outputs` estreitam o comando dentro de cada nó (o relógio
-    // de uma task não paga a suíte inteira). `--filter {ids}` só para FORÇAR a
-    // escolha de nós; `--full` desliga o recorte.
     run: morph-spec verify {feature} {task.id} --json
-    // exit 3 / status == 'busy': fila de slot pesado cheia, NÃO vermelho — nada foi verificado nem gravado.
-    // Repita a mesma chamada; não conta como tentativa e não dispara o loop de correção.
     if verify.status == 'fail':
-      // vermelho: feedback determinístico direto ao loop, SEM gastar o juiz LLM.
-      feedback = verify.feedback   // usado como input do próximo attempt
-      continue   // conta como tentativa; não invoca morph-eval sobre código que não builda/não passa
-
-    // verde: o juiz avalia só o que o código não pega (arquitetura, contratos, qualidade).
-    result = invoke Skill(morph-eval) with implementation output
-    if result.score > best.score: best = result
-    // Persista o score no feature.json autoritativo — torna o evalScore um signal
-    // de disco no MOMENTO da implementação (não no fim). O hook gate-guard.js e o
-    // Gate 3 leem dali. O timestamp é carimbado server-side pelo CLI — NUNCA edite
-    // feature.json à mão para isso:
-    run: morph-spec score {feature} {task.id} {result.score} --dims {arch},{contracts},{quality},{tests}
-
-    if result.score >= 9:
-      break
-
-  if best.score >= 9:
+      feedback = verify.feedback; continue        // conta como tentativa
+    // 'busy': ver "Ritmo"
+
+    // cada doneCriteria com a evidência que o prova (teste, arquivo:linha) — do
+    // relatório `reports/{task.id}.md` quando despachada, do seu código quando inline
+    faltando = critérios sem evidência
+    if faltando: feedback = faltando; continue
+    pronto = true; break
+
+  if pronto:
     // task com `3-implement/evidencias/{id}.md` em `outputs`: confira o arquivo antes do `done`
     // (morph-implement §5). Em batch paralelo sem isolamento o sub-agente não roda eval — o
     // ORQUESTRADOR roda, após o batch, `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist`
-    marcar task.status = 'done' em tasks.json (tool Edit — confirme os outputs
-    reais, já gravados antes do verify, e, se divergirem do planejado, o porquê em notes)
+    marcar task.status = 'done' (Edit; confirme os outputs reais)
   else:
-    // 3 tentativas sem atingir 9 — AQUI sim escala ao humano (escape definido).
-    // Esta é a única pausa do loop de implement, e só após esgotar o loop de correção.
-    registrar em recap.md: as 3 tentativas e o melhor score (best.score) com o feedback
-    AskUserQuestion: "Task {id} não atingiu score 9 após 3 tentativas (melhor: {best.score}) — aceitar mesmo assim, continuar tentando, ou pular?"
-    options: [aceitar (marca done com ressalva no recap), continuar tentando (+3 tentativas), pular task (marca blocked)]
+    // 3 tentativas sem verify verde + critérios: a única pausa do loop
+    registrar no recap as tentativas e o que faltou
+    AskUserQuestion: "Task {id} sem verify verde e critérios atendidos após 3 tentativas — aceitar, continuar tentando, ou pular?"
+    options: [aceitar (done com ressalva no recap), continuar (+3 tentativas), pular (blocked)]
 ```
 
-> **Loop por task filtra; Gate 3 e CI não.** O sub-agent despachado não roda `verify`: só o filtro dos próprios testes, uma vez (cláusula 3). No loop o filtro é **automático**: `verify {feature} {task.id}` deixa o `group` da task escolher os nós e os arquivos de teste de `outputs` estreitarem o comando — cada nó **aparece** em `nodes.tests.runs[]` com `selection` (`narrowed`/`whole`/`out-of-scope`/`full` e o motivo), nenhum some. `--filter {ids}` só força a escolha de nós (os não casados aparecem como `skip` nomeando o filtro, e um `--filter` que não casa nada é erro de uso, exit 2, nunca um verde); `--full` desliga o recorte. A verificação pós-batch e a do Gate 3 (`morph-spec verify {feature} --json`) rodam **sem filtro**, e `verify {feature}` **nunca recorta**: a prova que o avaliador lê tem de cobrir todos os nós, e o CI idem. Forma de `project.tests[]`, regras e limites do recorte, e a tabela da divisão: `.morph/framework/CLI.md`, seção "Suítes de teste".
->
-> **Verify vermelho consome uma tentativa** do loop (≤3) e devolve `feedback[]` acionável (erros de build, falhas de teste — linhas prefixadas por `[tests/{id}]`, que nomeiam a suíte —, issues de validador). O `morph-eval` NUNCA é invocado sobre código que não passou no verify — o juiz julga arquitetura/contratos/qualidade, o que o código determinístico não pega sozinho. Código roda antes, grátis; o juiz gasta tokens só no que sobra.
-
-> **Retry sem re-invoke — e a exceção que evita rodar sem a skill.** `skillLoaded` cai de volta para `false` (forçando reinvocação no próximo attempt) se houver `/compact` OU troca de sessão (nova sessão retomando via `handoff.md`) entre a última invocação e o attempt corrente — os dois eventos podem descartar o conteúdo da skill do seu contexto sem avisar. Sem essa exceção, um retry pós-compact aplicaria feedback sem o mandate/standard/persona carregados. Fora desses dois casos, reinvocar a Skill só para aplicar um feedback pontual é exatamente o custo repetido (~13KB por tentativa) que este corte existe para eliminar.
->
-> **Isto vale para a LEITURA da skill pelo orquestrador — não para o conteúdo de um dispatch.** Se o attempt 1 foi despachado a um sub-agent (§3b) e o attempt 2 também dispara os gatilhos de dispatch do `morph-implement` §4, o prompt de dispatch completo é reenviado normalmente: o sub-agent de um novo dispatch não tem o contexto do attempt anterior, então o corte de reinvoke não se aplica a ele. O que muda aqui é só a leitura da skill pelo ORQUESTRADOR no loop sequencial inline.
+> **O recorte é do loop por task.** `verify {feature} {task.id}` deixa o `group` escolher os nós e
+> os arquivos de teste de `outputs` estreitarem o comando; cada nó aparece em
+> `nodes.tests.runs[]` com `selection` e o motivo. `--filter {ids}` só força a escolha de nós (um
+> filtro que não casa nada é erro de uso, exit 2); `--full` desliga o recorte. A verificação
+> pós-batch e a do Gate 3 rodam **sem filtro**, e `verify {feature}` **nunca recorta**. Detalhe:
+> `.morph/framework/CLI.md`, seção "Suítes de teste".
 
-> **Por que loop e não pausa:** MORPH.md §0 manda auto-avançar entre tasks. Score baixo numa task individual é um problema de qualidade que o modelo deve **corrigir sozinho**, não delegar ao humano no meio da implementação. A pausa só existe quando o loop de correção se esgota (3 tentativas) — o "escape" do modelo autônomo. O trust mode não muda esse loop: ele governa os **gates** (proposal/plan/review), não o ciclo de correção intra-task.
+> **Não há juiz LLM por task.** O que o código determinístico prova (build, testes, validadores)
+> está no verify; o que ele não prova — o critério do use case — se confere contra o `doneCriteria`,
+> com evidência. Estilo e estrutura são assunto do avaliador do Gate 3, e mesmo lá só como nota.
 
 ### 3b. Modo Paralelo (para o subset independente)
 
-**Antes de despachar, escope cada agente ao seu domínio.** Um agente genérico sem persona nem standard não "conhece" as convenções daquele domínio — produz código fora do padrão. Para cada fluxo/task a despachar, resolva:
-
-- **Subagent:** use `task.agent` (id da persona, sem prefixo `morph-`) já carimbado em `tasks.json` pelo `morph-plan` §5a — o `subagent_type` do dispatch é **`morph-{task.agent}`** (ex.: `morph-dotnet-senior`). **Fallback (plano legado, task sem `agent`):** em `.morph/framework/agents.json`, encontre o agente cujo `domains` cobre o `group`/domínio da task (ex: `backend` → `dotnet-senior`, `frontend` → `nextjs-expert`/`ui-designer`, `database` → `ef-modeler`).
-- **Standard(s):** use `task.standards` quando presente; senão, do array `standards` do agente resolvido acima em `agents.json` (e/ou do `mandate.md`), selecione o(s) path(s) `.md` relevante(s) à task.
-- **Fallback (tipo não registrado):** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado neste projeto), use `subagent_type: "general-purpose"` colando o campo `persona` no prompt — e **registre nas `notes` da task**: `dispatch-fallback: general-purpose ({id} não registrado)`. O recap deve refletir o mecanismo real.
-
-**Cole o template literal**: só os campos entre `<>` mudam; não parafraseie cláusula nem omita os parágrafos de leitura, ferramentas e comentário.
+Escope cada agente ao domínio: `subagent_type: "morph-{task.agent}"` e `task.standards` (carimbados
+pelo `morph-plan`). Plano legado sem `agent`: escolha em `.morph/framework/agents.json` por
+`domains`. Tipo não registrado: `general-purpose` com o campo `persona` colado, e
+`dispatch-fallback: general-purpose ({id} não registrado)` nas `notes`. Cap de 4 agentes ao mesmo
+tempo. **Cole o template literal** — só os campos entre `<>` mudam:
 
 ```
 dispatch Agent (subagent_type: "morph-{id}") with prompt:
-  contexto: spec.md, mandate.md, task description completa, doneCriteria,
-            task.reuse (veredito REUSAR/ESTENDER/CRIAR por conceito), os paths
-            dos alvos de reuso e o que você já leu para a task (`arquivo:linhas`
-            + o trecho)
+  contexto: spec.md, use cases da task, description completa, doneCriteria,
+            task.reuse (REUSAR/ESTENDER/CRIAR por conceito), os paths dos alvos
+            de reuso e o que você já leu (`arquivo:linhas` + o trecho)
   standards: <por standard: id + digest do `standards --find` + as 3-8 regras do
              .md que ESTA task aplica, coladas; o path só para consulta pontual>
   instrução: |
-    Siga as regras dos standards acima; abra o .md só para uma dúvida pontual.
     Implemente esta task (ou cadeia de tasks do fluxo) sem depender do trabalho
-    dos outros agentes deste batch: seu ISOLAMENTO é de ESTADO e de ÁRVORE DE
-    TRABALHO — nunca de conhecimento do codebase. Antes de criar tipo,
+    dos outros agentes deste batch: seu isolamento é de estado e de árvore de
+    trabalho, nunca de conhecimento do codebase. Antes de criar tipo,
     componente, hook ou serviço NOVO, verifique se já existe: `morph-spec graph
     explain <nome>` e `graph affected <conceito> --uses-only`; sem grafo
     (`no-graph`), caia para `grep -rn "<nome>"` e siga — a ausência de grafo
-    nunca bloqueia. Se algo cobre o caso, reuse ou estenda; se criar mesmo
-    assim, diga por que em uma linha no relatório.
+    nunca bloqueia. Se criar mesmo assim, diga por que em uma linha no relatório.
+
     Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
     turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
     turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
@@ -189,173 +139,122 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
     shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
     `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
-    (`morph-spec graph`), não de varredura por grep. Tool `mcp__…` que não esteja
-    carregada se carrega com `ToolSearch` (`select:<nome>`); MCP ausente nunca
-    bloqueia — siga com o fallback.
+    (`morph-spec graph`). Tool `mcp__…` não carregada se carrega com `ToolSearch`
+    (`select:<nome>`); MCP ausente nunca bloqueia — siga com o fallback.
+
     Comentário: o padrão é nenhum. Nome, tipo e teste explicam o código; sem
     `///`/JSDoc em membro de aplicação, cabeçalho, banner de seção ou história
     da task. Só o porquê que o código não mostra, em uma linha
     (`architecture-code-comments`). O elo com a pós-condição vai no nome do
-    teste; a densidade do arquivo vizinho não é modelo. O hook `comment-guard`
-    bloqueia a edição que adiciona história, banner ou bloco longo.
-    Não modifique spec.md, mandate.md.
+    teste. O hook `comment-guard` bloqueia a edição que adiciona história,
+    banner ou bloco longo. Não modifique spec.md.
 
     Contrato do relatório final:
-    1. GRAVE um relatório por task concluída em
+    1. GRAVE um relatório por task em
        `.morph/features/{feature}/3-implement/reports/{taskId}.md` ANTES de
-       encerrar (um arquivo por task, mesmo cobrindo várias tasks do fluxo
-       numa sessão só) — é o retorno autoritativo, não a sua mensagem final
-       (que é cortesia best-effort e pode não chegar inteira). NÃO chame
-       SendMessage.
+       encerrar — é o retorno autoritativo. NÃO chame SendMessage.
     2. NÃO toque em tasks.json, feature.json, state.json nem no board de
-       sessão — todo estado (status de task, scores, gates) é gravado
-       exclusivamente pelo orquestrador.
+       sessão — todo estado é gravado exclusivamente pelo orquestrador.
     3. TESTE — a prova é do orquestrador (`morph-spec verify`), não sua.
-       Escreva os testes pelo orçamento: um por pós-condição, um de regressão
-       por bug, variantes numa tabela (`[Theory]`/`it.each`). NÃO rode teste a
-       cada marco nem faça ciclo red→green: escreva código e testes, compile, e
-       rode SÓ o filtro dos seus testes UMA vez, antes do relatório; se falhar,
-       corrija e rode só os que falharam. Não rode `morph-spec verify`.
-       - Batch SEM isolamento (working tree compartilhada): só compile —
-         edições concorrentes quebram o build umas das outras; o teste roda no
-         verify do orquestrador, pós-batch.
-       - Batch COM isolamento (você recebeu `isolation: "worktree"`): a regra
-         acima vale DENTRO do seu worktree; commite seu trabalho na branch do
-         worktree como último ato antes do relatório; reporte a branch — nunca
-         faça merge nem toque na árvore principal.
-       - Ao rodar: compile uma vez e rode sem recompilar (`dotnet test
-         --no-build`), com `--filter`. Grave a saída em arquivo uma vez
-         (`… > .morph/logs/test-last.log 2>&1`, sem nada depois) e leia o arquivo:
-         rodar de novo com outro `| tail`/`| grep` repete o teste para ver outras
-         linhas, e com pipe ou `; echo` o exit é o do último comando, não o do teste.
-
+       Testes pelo orçamento: um por pós-condição, um de regressão por bug,
+       variantes numa tabela. NÃO rode teste a cada marco nem faça ciclo
+       red→green: compile e rode SÓ o filtro dos seus testes UMA vez, em
+       primeiro plano, saída em arquivo
+       (`… > .morph/logs/test-last.log 2>&1`). Não rode `morph-spec verify`.
+       Batch SEM isolamento: só compile. Com `isolation: "worktree"`: o mesmo
+       dentro do seu worktree, e o último ato é o commit na branch dele —
+       nunca faça merge.
     4. ESCOPO: no máximo 3 tasks e ~4 arquivos por dispatch. Escopo maior falha e
        volta — fatie antes, não depois.
     5. SOBREVIVÊNCIA: o limite de turnos (`maxTurns`, no seu system prompt)
        corta sem aviso: commite `wip({taskId})` a cada marco (um arquivo ou
-       uma fatia coerente escrita — sem rodar teste para isso), não só ao fim da task — e só os seus arquivos
+       uma fatia coerente escrita), não só ao fim da task — e só os seus arquivos
        (`git add <paths>`, nunca `-A`). Sem commit, a retomada recomeça do zero.
        A ~70% do limite, grave o relatório parcial no arquivo canônico: `PARCIAL`
-       na 1ª linha, o feito e o que falta, sem auto-score. Depois siga ou pare,
-       por decisão sua; ao concluir, o relatório final substitui o parcial, sem o
-       `PARCIAL`. Sem limite declarado, bastam os commits por marco.
+       na 1ª linha, o feito e o que falta, sem critério dado como atendido. Depois
+       siga ou pare, por decisão sua; o relatório final substitui o parcial.
     6. PROCESSOS: NUNCA `taskkill /IM node.exe` (derruba os MCPs de todas as
        sessões). Encerre dev server pelo PID que você mesmo subiu. Build e
-       suíte pesados (`dotnet build`, `dotnet test`, `docker compose up`) rodam
-       por `morph-spec heavy run -- <comando>`: exit 3 é fila cheia, não erro do
-       código — espere e repita.
+       suíte pesados rodam por `morph-spec heavy run -- <comando>`, em primeiro
+       plano. Exit 3 é fila cheia depois da espera da própria fila: não repita
+       nem espere em laço — diga no relatório o que não rodou.
     7. RETORNO: o relatório no arquivo canônico é o retorno. `SendMessage` não é
        substituto do relatório e não deve ser chamado.
     8. MUTAÇÃO: nunca altere, reverta, mova ou apague código de produção para ver
        um teste falhar (`sed`, `mv`, `git show HEAD:… >`, `git stash`, `git
        checkout --`). A prova de que o teste morde é do avaliador no Gate 3.
 
-    Seu relatório final deve conter APENAS: (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.
+    Formato do relatório: (1) o que foi feito, em 2-3 frases; **Arquivos:** um
+    item `- \`path\`` por arquivo; **Critérios:** cada doneCriteria — atendido (o
+    teste ou `arquivo:linha` que o prova) ou não (por quê); (4) problemas.
 ```
 
-> **Passo pós-dispatch (do orquestrador, antes de avaliar qualquer relatório):** ao retomar o
-> controle, a auditoria do batch abaixo (`report-check` com os ids do batch) traz, no bloco `tree`,
-> o que está não commitado fora de `.morph/` (`dirty`, `diffstat`), os commits sobre a default
-> (`commits`) e os marcadores `MUTACAO` esquecidos (`markers`) — sem `git status`, `git diff` e
-> `grep` à parte. Um sub-agent morto no meio deixa o disco a meio caminho — e um relatório lido
-> sobre uma árvore que ninguém conferiu avalia um estado que ninguém quis. Árvore inesperadamente
-> suja ou `markers` não vazio é falha de protocolo: registre no recap antes de pontuar.
-
-> **Relatório com `PARCIAL` na 1ª linha = a task não está pronta**: o sub-agent parou antes do fim
-> (limite de turnos, cláusula 5). O `report-check` o acusa como `report-incomplete`, e aqui a ação é
-> retomar, não completar DEGRADADO: retome o MESMO agente por `SendMessage`, colando no recado
-> `tree.dirty` e `tree.commits` do `report-check` e o que falta (ele guarda o contexto), ou
-> re-despache só o que falta a partir do último `wip`. Nunca pontue nem marque `done` sobre um
-> parcial.
-
-> Este template é deliberadamente paritário com o template sequencial em `morph-implement` §4: ambos despacham o **subagent registrado do domínio (`morph-{id}`)** com standard escopado e as **mesmas 8 cláusulas** do contrato do relatório final (relatório, estado, teste, escopo, sobrevivência, processos, retorno e mutação), os mesmos parágrafos de leitura/turnos e ferramentas e os mesmos 4 itens de relatório — racional completo em `MORPH.md` §6. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
-
-> **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): siga a §3b-w abaixo em vez desta seção — despache com `isolation: "worktree"`, cada agente trabalha numa working tree própria e o orquestrador integra ao final.
-
-**Batch SEM isolamento:** aguardar todos os agentes terminarem, depois **auditar os relatórios contra o trabalho** com `morph-spec report-check {feature} {T1} {T2} … --json` (os ids do batch: sem eles o modo feature só audita tasks já `done`, e as do batch ainda não estão) — determinístico e independente da palavra dos agentes; é o passo que pega tanto o relatório ausente quanto o `report-stale` (completo, porém gravado antes do fim do trabalho: o agente relatou cedo e continuou escrevendo). Em `report-stale`, **não re-despache** — leia o campo `observed` (writes reais do `events.jsonl`) e atualize o relatório a partir dele. Vereditos e ações: `MORPH.md` §6. Em seguida **ler** `.morph/features/{feature}/3-implement/reports/{taskId}.md` de cada task — é o valor de retorno autoritativo; a mensagem de texto do dispatch, se chegou inteira, é só um atalho que economiza essa leitura. Depois, sequencialmente:
-- **Rodar `morph-spec verify {feature} --json` uma única vez, pós-batch** (escopo feature, **sem `--filter`**) — os agentes não a rodaram (cláusula 3). Vermelho: use `verify.feedback` para corrigir/redespachar ANTES de qualquer morph-eval. (Com isolamento por worktree, cada agente já rodou o verify dentro do seu worktree; o orquestrador roda o verify compartilhado UMA vez após o merge — ver §3b-w.)
-- Para cada relatório retornado:
-  - Aplicar `Skill(morph-eval)`.
-  - Gravar o score: `morph-spec score {feature} {taskId} {score} --dims {a},{c},{q},{t}`.
-  - Se score >= 9 (e `3-implement/evidencias/{taskId}.md` gravada, se a task a deve — checagem do §3a): marcar `done` em tasks.json (tool Edit — só campos mutáveis).
-  - Se score < 9: marcar `pending` novamente com nota — volta ao modo sequencial, onde o loop de correção (até 3 tentativas) busca o score 9.
-
-Depois do batch paralelo, executar o restante em modo sequencial (passo 3a).
-
-**Batch COM isolamento (§3b-w): dispatch rolling, não por onda.** Nenhum agente escreve na
-árvore principal, então o orquestrador não espera o batch inteiro: a cada relatório que chega,
-audita (`report-check {feature} {taskId}`), integra aquela branch (§3b-w passo 2), roda
-`verify {feature} {taskId}` e `morph-eval` + `score` daquela task, e **despacha na hora** toda
-task que ficou `ready` (`getReadyTasks`) cujos `outputs` não colidem com os das tasks em voo —
-o worktree nasce da branch da feature, já com o merge que acabou de entrar. Cap de 4 em voo. O
-`verify {feature}` de escopo feature roda uma vez, quando nada mais está em voo. Medido: uma task
-esperou 43 min pela onda depois de a dependência dela já estar pronta.
+**Passo pós-dispatch (batch SEM isolamento):** espere todos e rode `morph-spec report-check {feature} {T1} {T2} … --json`
+com os ids do batch. O bloco `tree` (`dirty`, `diffstat`, `commits`, `markers`) mostra o disco que
+os agentes deixaram; árvore suja sem explicação ou `markers` não vazio vai ao recap. Em
+`report-stale`, **não re-despache** — leia `observed` e atualize o relatório. Leia cada
+`3-implement/reports/{taskId}.md` (a mensagem do agente é atalho). Depois:
+- **`morph-spec verify {feature} --json` uma vez, pós-batch, sem filtro** — os agentes não o rodaram.
+  Vermelho: corrija ou re-despache com `verify.feedback`.
+- Para cada task do batch:
+  - Se verify verde e critérios atendidos (e `3-implement/evidencias/{taskId}.md` gravada, se a task a deve — checagem do §3a): marcar `done` (Edit, só campos mutáveis).
+  - Senão: de volta a `pending` com nota — o loop sequencial (§3a) a retoma.
 
-### 3b-w. Batch isolado por worktree (quando o dag recomenda)
+**`PARCIAL` na 1ª linha = a task não está pronta** — o `report-check` o acusa como `report-incomplete`.
+Retome o MESMO agente por `SendMessage`, com
+`tree.dirty`, `tree.commits` e o que falta; ou re-despache só o que falta a partir do último `wip`.
 
-Quando o `morph-spec dag {feature}` reporta `isolation.recommended: "worktree"` (dois fluxos paralelos planejam escrever no mesmo path — colisão de `outputs`), despache cada fluxo com o parâmetro `isolation: "worktree"` do tool Agent. Cada agente trabalha numa working tree própria; build/test rodam lá dentro sem colidir.
+O template é paritário com o do `morph-implement` §4: mesmas 8 cláusulas e o mesmo formato de
+relatório (racional em `MORPH.md` §6).
 
-1. **Dispatch:** mesmo `subagent_type: "morph-{id}"` e standards de §3b, mais `isolation: "worktree"`. O worktree vem do hook `WorktreeCreate` do morph: nasce em `worktrees/<n>` na branch `morph-task/<n>`, com junctions (`node_modules`, `.claude`, `.morph/framework`) e `.morph/worktree.env` já prontos — se faltar infra mesmo assim, o agente roda `morph-spec worktree link --all` (fail-open); se ainda impossível, reporta "verificação: não executada" (o verify pós-merge cobre). Dev server/compose dentro do worktree já sai nas portas do bloco (o hook `worktree-env-inject` prefixa o comando; fora do Claude, `eval "$(morph-spec env)"`). O worktree nasce da branch `morph/<feature>` quando a sessão está nela (o trabalho já integrado da feature vem junto, sem `merge` manual) e com os `.env*` da raiz copiados — o prompt de dispatch não manda o agente preparar nada disso. Sessão fora de `morph/<feature>` (orquestrador na raiz) faz o worktree nascer da default: aí, e só aí, o prompt abre com `git merge --ff-only morph/<feature>`. O agente commita na branch do worktree como último ato e reporta a branch. Ele não roda `morph-spec verify` (cláusula 3): a prova é o verify do orquestrador depois do merge.
-2. **Integração (orquestrador, a cada relatório que chega):** faça o merge de cada branch reportada, uma por vez, na ordem de chegada — `git merge --no-ff <branch>`. Conflito → `git merge --abort`, marque a task de volta a `pending` com nota "merge conflict — reexecutar sequencial", siga para a próxima branch. Os paths em conflito são exatamente os de `isolation.collisions` do dag.
-3. **Pós-merge:** `verify {feature} {taskId}` no merge de cada task (dispatch rolling, §3b), depois `morph-eval` + `morph-spec score`; `morph-spec verify {feature} --json` de escopo feature UMA vez, quando nada mais está em voo (o merge é o novo ponto de integração — verificação compartilhada obrigatória).
-4. **Cleanup:** o hook `WorktreeRemove` remove o worktree **limpo** ao fim do subagent (branch sobrevive) — mas não conte com ele: rode `morph-spec worktree remove --target <path>` por worktree que sobrou (NUNCA `git worktree remove` cru — as junctions do passo 1 seriam atravessadas e o `node_modules`/`.claude` da raiz apagados) + `git branch -d morph-task/<n>` das branches integradas + `git worktree prune` (fail-open). Depois de cada retorno de agent com `isolation`, e ao fim do batch, rode `morph-spec worktree reap --json`: remove só o worktree de `agent-<hex>` que parou limpo e sem commit exclusivo, e lista o resto com a razão (`not-a-registered-worktree` no `remove --target` seguinte = o reaper já o levou). Worktree sujo (subagent não commitou) fica, vira `agent-worktree-leftover` no `doctor --worktrees`, e a task volta a `pending`. Branches não integradas ficam e são registradas no recap com o motivo.
-5. **Agente morto no meio:** se commitou, a branch sobrevive (retomável); senão, a task volta a `pending` na lane sequencial. Registre a falha de protocolo no recap.
+### 3b-w. Batch isolado por worktree (quando o dag recomenda)
 
-> Anti-padrões: não misture unidades isoladas e não-isoladas no mesmo batch; o subagent nunca faz merge (integração é exclusiva do orquestrador).
+1. **Dispatch:** o template de §3b com `isolation: "worktree"`. O hook `WorktreeCreate` cria
+   `worktrees/<n>` na branch `morph-task/<n>`, com junctions e `.morph/worktree.env` prontos, a partir
+   de `morph/<feature>` quando a sessão está nela (fora dela, o prompt abre com
+   `git merge --ff-only morph/<feature>`). Infra faltando: o agente roda `morph-spec worktree link --all`.
+2. **Rolling, não por onda:** a cada relatório, `report-check {feature} {taskId}`, `git merge --no-ff
+   <branch>` (conflito → `git merge --abort`, task volta a `pending` com nota), `verify {feature}
+   {taskId}`, critérios, e despache na hora a task que ficou ready sem colidir com as em voo. Cap
+   de 4. O `verify {feature}` sem filtro roda uma vez, quando nada mais está em voo.
+3. **Cleanup:** depois de cada retorno e ao fim, `morph-spec worktree reap --json` remove o worktree
+   `agent-<hex>` que parou limpo e sem commit exclusivo e lista o resto com a razão
+   (`not-a-registered-worktree` no `remove --target` seguinte = o reaper já o levou). O que sobrar:
+   `morph-spec worktree remove --target <path>` — NUNCA `git worktree remove` cru, que atravessa as
+   junctions. `git branch -d morph-task/<n>` das branches integradas.
+4. **Agente morto no meio:** com commit, a branch é retomável; sem, a task volta a `pending`.
+
+O subagent nunca faz merge, e unidades isoladas e não isoladas não se misturam no mesmo batch.
 
 ### 4. Conclusão de tasks
 
-Quando `getPendingTasks(data).length === 0`:
-
-- Invocar `Skill(morph-review)` para gerar `.morph/features/{feature}/4-review/review-report.md`.
-- A skill morph-review chama `morph-eval` em escopo de feature inteira.
+Sem tasks pendentes: invoke `Skill(morph-review)`.
 
 ### 5. Gate 3
 
-Apresentado e persistido por `morph-review` §8 (invocada no passo 4 acima) — gate-check, template
-fixo nomeando a feature, aprovação registrada pós-resposta. Ao retomar o controle dela, **NÃO
-re-apresente o gate**: siga direto para o encerramento (§6) conforme a decisão já persistida em
-`gateDecisions.review`.
+Apresentado, decidido e aprovado por `morph-review` §7. Ao retomar o controle, **não re-apresente
+o gate** nem aprove de novo: siga para o encerramento conforme `gateDecisions.review`.
 
-### 6. Pós Gate 3 — encerramento
+### 6. Encerramento
 
-- Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em `AskUserQuestion` — **desde que a pergunta nomeie a feature** (senão aprove via `morph-spec approve`).
-- **Antes do `finish`, reescreva o contexto que a feature mudou.** Todo `.morph/context/*.md` que descreve um fato que esta feature alterou (fonte, token, fluxo, integração) tem o **corpo** reescrito — a seção que descrevia o antigo passa a descrever o novo, e o que ainda vale num escopo diz o escopo. O changelog do documento guarda só data e motivo, nunca o valor novo: um agente que lê só o corpo precisa receber a resposta de hoje. Commite na branch da feature — o `finish` exige a árvore limpa. UCs e ADRs não entram aqui: o `finish` aplica ao acervo o que o `spec.md` declarou revogar (`morph-plan` §3) e reporta em `supersededUseCases`/`adrIndex`/`revocationProblems`.
-- **Fechar a feature** com `morph-spec finish {feature} --pr|--merge`, modo escolhido via `AskUserQuestion` (header `"Integração"`): `--pr` (push + PR, review antes do merge) vs `--merge` (integra local, single-user direto). Não integre automaticamente sem essa escolha. Mecânica completa (o que cada modo faz, feature legada sem `morph/{f}`): `MORPH.md` §2.1/§2.2.
-- **`--pr` não encerra a feature; quem encerra é o merge.** O comando arquiva e termina (`finished: true`) nos dois modos, mas só `--merge` integra na hora (`integrated: true`); `--pr` sai com `integrated: false`, `awaiting: "merge"` e `pr: {number, url}` — o archive viaja no diff do PR e só chega na branch default quando alguém mergeia. Até lá a feature aparece em `morph-spec list`/`fleet` como `aguardando-merge`, sem cópia local. Nunca registre a feature como entregue só porque `finish --pr` retornou `finished: true`.
+- **Contexto antes do `finish`.** Todo `.morph/context/*.md` que descreve um fato que esta feature
+  mudou tem o **corpo** reescrito para o estado novo; o changelog do documento guarda só data e
+  motivo. Commite na branch da feature — o `finish` exige a árvore limpa.
+- **Fechar:** `morph-spec finish {feature} --pr|--merge`, modo escolhido por `AskUserQuestion`
+  (header `"Integração"`). `--pr` arquiva e abre o PR, mas só o merge integra: a feature fica
+  `aguardando-merge` em `list`/`fleet`. Mecânica: `MORPH.md` §2.1/§2.2.
 
 ## Anti-padrões
 
-- Não dispachar paralelo se há deps cruzadas entre as tasks selecionadas (corrompe ordem).
-- Não pular `morph-eval` — uma task só avança com score >= 9; abaixo disso, o loop de correção roda (não pausa).
-- Não reescrever spec.md/mandate.md durante implement (são read-only após Gate 2 — `protect-spec-files.js` hook bloqueia).
-- Não dispachar mais que 4 agentes em paralelo (sobrecarga de contexto + custo).
-- Não dispachar um agente inteiro para uma raiz de effort S — overhead > trabalho; o `morph-spec dag` já as marca como `inline`.
-- Não deixar sub-agent tocar `tasks.json`, `feature.json` ou o board de sessão — estado é do orquestrador (cláusula 2 do protocolo).
-- Não editar `feature.json` à mão para gravar scores ou decisões de gate — use `morph-spec score` e `morph-spec gate-check`/`gate-decision` (timestamps server-side; o Edit manual colide com o hook state-sync — "file modified since read").
-
-## Output esperado
-
-- Todas as tasks em `tasks.json` com status `done` ou `skipped`.
-- `.morph/features/{feature}/3-implement/recap.md` produzido por morph-implement.
-- `.morph/features/{feature}/3-implement/evidencias/{taskId}.md` — só nas tasks que o listam em `outputs` (critério sobre saída de LLM, `morph-plan` §5): evidência de runtime gravada por morph-implement e lida pelo avaliador do Gate 3 — não é o `reports/{taskId}.md` do sub-agente.
-- `.morph/features/{feature}/4-review/review-report.md` produzido por morph-review.
-- Gate 3 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo) — via `morph-spec approve` em auto, ou pelo hook state-sync no caminho manual.
-- Feature com Gate 3 aprovado e **fechada** por `morph-spec finish --pr|--merge` (arquiva carimbando `status: "completed"` + `archivedAt` e desmonta num passo; `--merge` integra na hora, `--pr` só abre o PR — `aguardando-merge` até o merge) — ou, se legada, por `morph-spec archive`.
+- Paralelo com dependência cruzada entre as tasks do batch.
+- Mais de 4 agentes ao mesmo tempo; agente inteiro para raiz S.
+- Sub-agent tocando `tasks.json`, `feature.json` ou o board de sessão.
+- Editar `spec.md` depois do Gate 2, ou `feature.json` à mão.
+- Rodar teste fora do `verify` no loop do orquestrador: a prova é o verify.
 
 ## Referências
 
-- `.morph/framework/MORPH.md` — charter NLH; §6 tem o racional completo do contrato do relatório final (aqui e no `morph-implement` §4 estão só as versões curtas coladas no dispatch)
-- `.claude/skills/morph-implement/SKILL.md` — §4 tem o template sequencial paritário a este §3b
-- `.claude/skills/morph-eval/SKILL.md`
-- `.claude/skills/morph-review/SKILL.md`
-- `.claude/skills/morph-plan/SKILL.md` §5a — resolve e carimba `task.agent`/`task.standards` no plano; fonte primária deste §3b
-- `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort), incluindo recomendação de isolamento (`isolation.recommended: "worktree"`)
-- `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores+e2e (código antes do juiz)
-- `morph-spec score {feature} {task} {score} [--dims a,c,q,t]` — grava taskScores no feature.json com timestamp server-side
-- `morph-spec gate-check {feature} {gate} [--json]` — default: coleta sinais do disco, decide via `shouldPauseGate`, persiste `gateDecisions`
-- `morph-spec gate-decision {feature} {gate} --pause {bool} [--reason ...] [--signals ...]` — escape manual: risco que o `gate-check` não vê no disco (shape em `.morph/framework/schemas/feature.schema.json`)
-- `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)
+- `.morph/framework/MORPH.md` §6 — contrato do relatório final
+- `morph-spec dag|verify|report-check|worktree reap` — `.morph/framework/CLI.md`
+- `.claude/skills/morph-implement/SKILL.md` §4 — template sequencial paritário
+- `.claude/skills/morph-review/SKILL.md` — Gate 3

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

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-brainstorming

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

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-hotfix
@@ -45,6 +45,8 @@ subagent_type: "morph-scout"
 
 Peça ao scout: localizar o root cause provável, os arquivos afetados e o blast radius (o que mais pode quebrar). Ele é read-only (Read/Glob/Grep/Bash somente-leitura) — não escreve código. Inclua as 8 cláusulas do contrato do relatório final no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): relatório no arquivo canônico como retorno, sem `SendMessage`; não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; sem build/test da suíte compartilhada em batch paralelo; no máximo 3 tasks por dispatch; commit `wip({taskId})` ao fim de cada task; nunca `taskkill /IM node.exe`; nunca mutar código de produção para ver teste falhar.
 
+**Audite o mapa antes do brief.** Grave a resposta do scout em `.morph/features/{feature}/2-plan/scout-map.md` e rode `morph-spec scout-check .morph/features/{feature}/2-plan/scout-map.md --json`. Exit ≠ 0 → descarte o mapa e re-despache o scout **uma** vez com as `failures` no prompt (o mapa novo abre com o motivo); na segunda reprovação, faça você o grep do root cause e siga. Root cause e blast radius que entram no brief se conferem com grep próprio mesmo com o mapa aprovado: sob pressão de hotfix, citação inventada vira um segundo incidente.
+
 ### 3. Hotfix brief (`0-proposal/proposal.md`)
 
 Escreva o brief curto (~20 linhas) reutilizando o nome canônico `proposal.md`:
@@ -61,13 +63,13 @@ Escreva um `tasks.json` mínimo validado contra `.morph/framework/schemas/tasks.
 - `T1` — o fix.
 - `T2` — verify/regressão do blast radius.
 
-Isso liga trace/score/dag de graça (o hook `trace-autogen` gera o trace a partir do primeiro write de `tasks.json`) — não pule esta escrita mesmo sob pressão de tempo.
+Isso liga trace e dag de graça (o hook `trace-autogen` gera o trace a partir do primeiro write de `tasks.json`) — não pule esta escrita mesmo sob pressão de tempo.
 
 ### 5. Fix cirúrgico
 
 Implemente a mudança mínima — inline se estiver no domínio já carregado, ou despachando a persona de domínio via `subagent_type: "morph-{id}"` conforme `MORPH.md` §6 se a task cruzar domínio ou tiver esforço L/XL. Prioridade: tirar a falha do ar, não refatorar — melhorias de forma (não de correção) vão para o roadmap-fora-hotfix, não para este diff.
 
-Aplique `morph-eval` com foco em correção: pese `contracts.md` e `test-coverage.md` mais que `architecture.md` — o objetivo do hotfix é parar a sangria com o menor blast radius, não elegância de arquitetura.
+A task fecha com o `verify` verde e o sintoma reproduzido antes e ausente depois — o objetivo do hotfix é parar a sangria com o menor blast radius, não elegância de arquitetura.
 
 ### 6. Test loop no blast radius