@polymorphism-tech/morph-spec 8.47.0 → 9.0.0

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

@@ -1,260 +1,187 @@
 ---
 name: morph-apply
-description: Orquestra a execução autônoma de tasks de uma feature morph-spec. Analisa DAG de dependências em tasks.json e decide adaptativamente entre execução sequencial (auto-advance) ou paralela (Agent dispatch). Termina com morph-review e Gate 3.
+description: Executa as fatias do plano de uma feature morph-spec — dispatch por persona, em ondas paralelas do plan-check, com relatório por fatia — prova a feature com um verify sem filtro e entrega à morph-review (Gate 3).
 version: core
-when_to_use: Use quando chegar a instrução "use /morph-apply" ou "implementar feature" com o Gate 2 aprovado
+when_to_use: Use com o gate do plano aprovado, em "use /morph-apply {feature}" ou "implementar feature"
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.0.0"
 ---
 
 # morph-apply
 
 ## Objetivo
 
-Levar toda task pendente a `done` — `verify` da task verde e `doneCriteria` atendido — e fechar
-com `morph-review` + Gate 3.
-
-## Quando invocar
-
-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.
+Toda fatia de `2-plan/checks.json` com relatório final em `3-implement/reports/F{n}.md`, o
+`verify` da feature verde, e a entrega à `morph-review`. O progresso **é** o conjunto de
+relatórios (ausente = pendente, `PARCIAL` na 1ª linha = parcial, senão feito): não há arquivo de
+status para editar.
 
 ## Ritmo
 
 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
+`run_in_background` e espera a notificação de término **no mesmo turno**: nunca encerre o turno
+com o verify da feature rodando — o stamp que o Gate 3 lê é o dele. `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. Contexto, uma vez
 
-### 1. Carregar contexto
+Read em `2-plan/plan.md` e `2-plan/checks.json` uma vez por sessão (ou depois de um `/compact`):
+o plano está congelado desde o gate, então não releia por padrão — só o trecho que falta.
+Antes do primeiro dispatch: `.morph/config/config.json` sem `project.stack` ou `project.tests` →
+declare-os a partir dos comandos de baseline do `## Contrato de implementação` e commite junto com o
+`.gitignore` que o `plan-check` semeou (`bin/`/`obj/` num projeto .NET) — antes de qualquer código. Não há comando de
+CLI para isso: uma edição no `config.json` na forma de `.morph/framework/schemas/config.schema.json`
+(`project.tests[]` com `id` e `command`; `project.stack` com as tags unidas por `+`, ex. `dotnet+nextjs`;
+mais de uma solução .NET no repositório → `project.backendPath` com a pasta da que o build compila), conferida
+por `morph-spec doctor --full`.
+`morph-spec plan-check {feature}` imprime as **ondas**: fatias de uma onda não dependem uma da
+outra nem tocam o mesmo arquivo, até 4 por onda.
 
-`.morph/config/config.json → trust` e Read em `2-plan/tasks.json` (ids, `dependencies`, `effort`,
-`group`, `status`, `doneCriteria`).
+## 2. Fatiar
 
-### 2. Análise de DAG — sequencial vs paralelo
+- Uma onda por vez, até **4 agentes ao mesmo tempo**, um por fatia, `subagent_type: "morph-{id}"` (o `persona:` da fatia).
+- Duas fatias em voo que escrevem o mesmo arquivo: a segunda vai em worktree (§4), rolling.
+- Fatias em paralelo na mesma árvore commitam pela lista explícita de arquivos (`git add <paths>`), nunca um diretório: `git add api` leva o arquivo que a fatia vizinha acabou de escrever.
+- **Inline** só para fatia pequena no domínio já carregado, com **uma linha de porquê** no relatório.
+  Antes de codar, leia os standards que a fatia fixa. Inline também grava `3-implement/reports/F{n}.md`,
+  no formato abaixo — é ele que conta o progresso.
 
-```
-morph-spec dag {feature}
-```
+O hook `validate-completion` (no Stop) e o `report-check` cobram o relatório pela mesma régua
+(`inspectReport`); conhecer o formato antes evita reescrever o relatório depois de dar a fatia por feita:
 
-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`.
+```markdown
+# F{n} — {título}
 
-`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.
+{2-3 frases: o comportamento entregue, onde mora e como foi provado}
 
-### 3a. Modo Sequencial (auto-advance)
+**Arquivos:** `{path}`, `{path}`
 
-```
-while (true):
-  ready = tasks 'pending' com todas as dependencies 'done' (releia tasks.json)
-  if ready vazio: break
-  task = ready[0]
-  marcar task.status = 'in_progress' (Edit, só campos mutáveis)
-
-  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)
-
-    run: morph-spec verify {feature} {task.id} --json
-    if verify.status == 'fail':
-      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' (Edit; confirme os outputs reais)
-  else:
-    // 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)]
-```
+**Checks:** C{n} — {teste que prova, ou `arquivo:linha`}
 
-> **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".
+**Standards:** `{id}`, `{id}`
+```
 
-> **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.
+`**Arquivos:**` lista todo arquivo criado ou modificado; cada `C{n}` que a fatia `cobre` aparece pelo
+id; relatório que abre com `PARCIAL` não conta como feito. Os relatórios **são** o registro da
+implementação (não há `recap.md`): o `verify` confere a união dos `**Arquivos:**` contra os
+`arquivos:` das fatias (aviso, nunca reprova). `**Standards:**` nomeia os ids que o agente de fato
+consultou (o `report-check` não o exige).
+- Persona não registrada: `general-purpose` com o campo `persona` de `agents.json` colado, e
+  `dispatch-fallback: general-purpose ({id} não registrado)` no relatório.
 
-### 3b. Modo Paralelo (para o subset independente)
+## 3. Dispatch — só o que muda
 
-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:
+O contrato fixo (relatório, estado, teste, escopo, `wip`, processos, reuso, mutação e o formato do
+relatório) está no corpo da persona gerada e chega a todo dispatch sem ser colado. O prompt leva:
 
 ```
 dispatch Agent (subagent_type: "morph-{id}") with prompt:
-  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: |
-    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,
-    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 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
-    Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
-    `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
-    acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
-    se lê pelo `Grep` do erro, não inteiro.
-
-    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`). 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. 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 em
-       `.morph/features/{feature}/3-implement/reports/{taskId}.md` ANTES de
-       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 é gravado exclusivamente pelo orquestrador.
-    3. TESTE — a prova é do orquestrador (`morph-spec verify`), não sua.
-       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), 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 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 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.
-
-    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.
+Fatia F{n} — <título>
+cobre: <cada Cn com o texto literal do cenário e a `prova:`>
+arquivos: <os `arquivos:` da fatia>
+standards: <por id: o digest de `morph-spec standards --find` + as 3-8 regras que ESTA fatia aplica>
+reuso: <as linhas de `## Reuso` que tocam a fatia — conceito, veredito, alvo>
+contexto: <o que você já leu: `arquivo:linhas` + o trecho; nada que o agente tenha de reler>
+relatório: .morph/features/{feature}/3-implement/reports/F{n}.md (com `**Standards:**`: os ids consultados)
+worktree: <só com isolamento>
 ```
 
-**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.
-
-**`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`.
-
-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).
-
-### 3b-w. Batch isolado por worktree (quando o dag recomenda)
-
-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
-
-Sem tasks pendentes: invoke `Skill(morph-review)`.
-
-### 5. Gate 3
-
-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. Encerramento
-
-- **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.
+## 4. Worktree rolling
+
+Com `isolation: "worktree"` o hook `WorktreeCreate` cria `worktrees/<n>` na branch `morph-task/<n>`,
+com junctions e `.morph/worktree.env` prontos (infra faltando: `morph-spec worktree link --all`).
+**Rolling, não por onda:** a cada relatório, `report-check`, `git merge --no-ff <branch>` (conflito →
+`git merge --abort` e a fatia volta a pendente com nota no relatório) e despache na hora a próxima fatia
+que ficou pronta sem colidir com as em voo. Depois de cada retorno, `morph-spec worktree reap --json`
+(`not-a-registered-worktree` no `remove --target` seguinte = o reaper já o levou); o que sobrar sai por `morph-spec worktree remove --target <path> --delete-branch` (já mergeada; o
+`git branch -d` dele recusa trabalho não integrado) — NUNCA `git worktree remove` cru,
+que atravessa as junctions.
+
+## 5. Retomar o controle
+
+`morph-spec report-check {feature} F1 F2 … --json` com as fatias que voltaram. **Leia o arquivo de
+relatório, não a mensagem** — a mensagem final pode não chegar ou vir resumida.
+
+| Veredito | Ação |
+|---|---|
+| `ok` | siga |
+| `report-stale` | **não re-despache**: o agente escreveu depois de relatar; leia `observed` e atualize o relatório |
+| `report-incomplete` + `resume` | `PARCIAL` na 1ª linha = a fatia não está pronta — o `report-check` o acusa como `report-incomplete`. Retome o MESMO agente por `SendMessage`, colando `tree.dirty`, `tree.commits` e o que falta |
+| `report-incomplete` + `complete-degraded` | complete a partir da mensagem, carimbe DEGRADADO e registre a falha no relatório |
+| `work-landed-report-missing` | não re-despache; grave você o relatório, DEGRADADO |
+| `no-work-no-report` / `report-missing-evidence-unknown` | re-despache uma vez; segunda ausência sem trabalho = escale |
+
+Árvore suja sem explicação ou `tree.markers` não vazio vão ao relatório da fatia.
+
+## 6. Verify da feature, uma vez
+
+Sem fatia pendente nem em voo, **primeiro o contexto** — antes do verify, para que a prova e o Gate 3
+cubram a árvore que vai ao merge. Todo `.morph/context/*.md` que descreve um fato que esta feature
+mudou tem o **corpo** reescrito para o estado novo, nunca empilhado (valor que ainda vale em algum
+lugar diz onde); o changelog do documento guarda só data e motivo. Mudança estrutural
+(`package.json`, `.csproj`, `next.config.*`, `tsconfig.json`, `docker-compose.yml`) atualiza também
+`.morph/context/README.md` (stack, arquitetura, integrações) e `.morph/config/config.json` (stack,
+arquitetura, integrações, paths). **Commite** o trabalho das fatias e essa atualização de contexto e
+config **antes** do verify: o stamp grava o HEAD, e código ou `config.json` commitado depois dele é
+árvore nova — um terceiro verify.
+
+Depois `morph-spec verify {feature} --json`, **sem filtro** — nunca recorte o
+verify da feature. `--filter` é do loop do próprio sub-agente; o Gate 3 e o CI rodam a suíte
+inteira. Nó de teste sem `expectedCount`: acrescente `--record-baseline` a ESTA rodada — ela mede e
+prova de uma vez; nunca um segundo verify só para gravar a baseline. Vermelho: corrija com `verify.feedback` (direto no código, ou re-despachando a fatia dona)
+e rode de novo; **3 tentativas** sem verde → `AskUserQuestion` ("Verify de {feature} vermelho após 3
+tentativas — aceitar com ressalva, continuar tentando, ou parar?").
+
+**Cenário que julga saída de LLM** (`prova: eval`): a evidência é rodar, não ler código. Com nó
+`runner: "evals"`: `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist`
+(sonda, não prova de gate). Grave `3-implement/evidencias/{Cn}.md`: o cenário literal, o nó, o modelo
+efetivo, a versão ou o hash do prompt (nunca o prompt cru), entrada e saída sem dado pessoal, e o
+veredito com a razão. Não é o `reports/F{n}.md`: aquele diz o que o agente fez; este prova, rodando,
+que a saída atende ao cenário.
+
+## 7. Review
+
+Verify verde: `Skill(morph-review)`. O Gate 3 é apresentado, decidido e aprovado por ela; ao retomar o
+controle, **não re-apresente o gate** — siga para o encerramento conforme `gateDecisions.review`.
+
+## 8. Encerramento
+
+- **Contexto já foi no §6**, antes da prova. Depois do Gate 3 nada muda `config.json` nem código: a
+  árvore integrada é a revisada. Commite na branch da feature o que faltar (relatórios do review) —
+  o `finish` exige a árvore limpa.
+- **Fechar:** `morph-spec finish {feature} --pr|--merge`, modo por `AskUserQuestion` (header
+  `"Integração"`). `--pr` arquiva e abre o PR, mas só o merge integra: a feature fica
+  `aguardando-merge` em `list`/`fleet`.
+
+## Escalada de escopo
+
+| Situação | Caminho |
+|---|---|
+| Acréscimo pequeno dentro da fatia | registre no relatório da fatia — sem gate a revogar |
+| **Fato errado**: o plano afirma algo que o código desmente, sem mudar escopo | bloco `## Errata` no FIM do `plan.md`, corpo intacto, append-only |
+| **O escopo mudou** | `morph-spec unapprove {feature} plan --reason "..."`, emende, `plan-check`, re-aprove |
+
+Ambiguidade que o plano não cobre não é escalada: resolva pelo lado conservador, registre a decisão sob `## Errata` do `plan.md`
+e siga.
+
+## Arquivo de teste
+
+1. **Analise primeiro** — a IMPLEMENTAÇÃO está errada ou a ESPECIFICAÇÃO do teste está?
+2. **Corrija a implementação primeiro** — o teste é a especificação; confie nele por padrão.
+3. **Só mude um arquivo de teste se a própria expectativa estiver errada.**
+4. **Antes de mudar, explique POR QUE o teste está errado** — qual é o comportamento certo.
+
+## Debugging
+
+Causa raiz antes do conserto: reproduza e leia o erro inteiro; erro conhecido de .NET/Next.js →
+`/morph-troubleshoot <palavras>`; **uma hipótese por vez**, cada uma testada pela menor checagem que
+a refutaria; depois de três consertos falhos, nunca tente um quarto sozinho — `AskUserQuestion`
+com a pergunta de desenho que as falhas levantam; confirme com a mesma checagem que reproduziu.
 
 ## Anti-padrões
 
-- 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.
+- Mais de 4 agentes ao mesmo tempo, ou duas fatias em voo no mesmo arquivo sem worktree.
+- Sub-agente tocando `plan.md`, `checks.json` ou `feature.json`.
+- Re-despachar sobre `report-stale` ou sobre um `PARCIAL` (retome o MESMO agente).
 - Rodar teste fora do `verify` no loop do orquestrador: a prova é o verify.
-
-## Referências
-
-- `.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-hotfix/SKILL.md

@@ -2,9 +2,9 @@
 name: morph-hotfix
 description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de produção com prioridade máxima em velocidade, com aprovação humana obrigatória antes do ship.
 version: core
-when_to_use: Use quando chegar "/morph-hotfix {feature}", quando a morph-proposal classificar o pedido como workType hotfix (Passo 0), ou quando o usuário disser "produção caiu / hotfix / urgente" a respeito de um incidente
+when_to_use: Use quando chegar "/morph-hotfix {feature}", quando a morph-plan rotear o pedido como workType hotfix, ou quando o usuário disser "produção caiu / hotfix / urgente" a respeito de um incidente
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.0.0"
 ---
 
 # morph-hotfix
@@ -16,7 +16,7 @@ Resolver uma queda ou bug crítico de produção o mais rápido possível — pr
 ## Quando invocar
 
 - Usuário roda `/morph-hotfix {feature}` diretamente.
-- `Skill(morph-proposal)` classifica o pedido como `hotfix` no Passo 0 de roteamento e invoca esta skill.
+- `Skill(morph-plan)` roteia o pedido como `hotfix` e invoca esta skill.
 - Usuário diz "produção caiu", "hotfix", "urgente", "incident", "P0" — sinais que o detector determinístico de `morph-spec create --request` já reconhece.
 
 ## Argumentos
@@ -31,7 +31,7 @@ Resolver uma queda ou bug crítico de produção o mais rápido possível — pr
 morph-spec create {feature} --type hotfix --description "<o incidente: o que quebrou / sintoma>"
 ```
 
-Carimba `name` (o slug) + `description` (obrigatória no nascimento — descreva o incidente) e os gates `proposal`/`plan` como `approvedBy: "policy:hotfix"`, e cria as pastas `0-proposal/`, `2-plan/`, `3-implement/` num passo só — a feature já nasce em `implement` (fase derivada é gate-aware). Se a feature já existe, siga adiante sem recriar.
+Carimba `name` (o slug) + `description` (obrigatória no nascimento — descreva o incidente) e o gate `plan` como `approvedBy: "policy:hotfix"`, e cria as pastas `2-plan/` e `3-implement/` num passo só — a feature já nasce em `implement` (fase derivada é gate-aware). Se a feature já existe, siga adiante sem recriar.
 
 ### 2. Scout — mapa do território (obrigatório)
 
@@ -41,47 +41,39 @@ Despache o scout com o sintoma reportado, antes de qualquer fix:
 subagent_type: "morph-scout"
 ```
 
-**Fallback** (se `morph-scout` não estiver registrado nos subagent types deste projeto): `general-purpose` com o campo `persona` do agente `scout` colado no prompt, **registrando o fallback nas notes da task**.
+**Fallback** (se `morph-scout` não estiver registrado nos subagent types deste projeto): `general-purpose` com o campo `persona` do agente `scout` colado no prompt, **registrando o fallback no `reports/F1.md`**.
 
-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 cole as 8 cláusulas do contrato de implementador (`morph-implement` §4 / `morph-apply` §3b) — commit `wip`, orçamento de teste e limite de tasks não se aplicam a quem não escreve. O prompt dele diz só: não escreve nem reverte nada, e o mapa é a mensagem final (Observado/Inferido, no contrato de citação que a persona já carrega). Você grava o mapa.
+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) e o corpo da persona dele já carrega o contrato read-only: o contrato de dispatch dos implementadores — commit `wip`, orçamento de teste, escopo da fatia — não se aplica a quem não escreve. O prompt dele diz só o sintoma: ele não escreve nem reverte nada, e o mapa é a mensagem final (Observado/Inferido, no contrato de citação que a persona já carrega). Você grava o mapa.
 
 **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`)
+### 3. Plano curto (`2-plan/plan.md` → `checks.json`)
 
-Escreva o brief curto (~20 linhas) reutilizando o nome canônico `proposal.md`:
+Escreva o `plan.md` mínimo (~25 linhas) numa única escrita: o hotfix nasce com o gate `plan` carimbado, o `create` não escreve esqueleto e o arquivo congela assim que existe. Gramática completa: `morph-spec plan-check --help`.
 
-- **Sintoma** — o que está quebrado, em produção, agora.
-- **Root cause** — o que o scout localizou.
-- **Blast radius** — o que mais pode quebrar com o fix.
-- **Plano do fix** — a mudança mínima que resolve o sintoma.
+- `## Problema` — o sintoma em produção, o root cause que o scout localizou e o blast radius.
+- `## Cenários` — dois, sempre:
+  - **C1** — o sintoma ausente: dado o estado que quebrava, quando a ação que falhava, então o resultado certo. `prova: teste` (ou `e2e`).
+  - **C2** — a regressão do blast radius: o que o fix poderia quebrar continua funcionando. `prova: teste`.
+- `## Decisões` com `### Conflitos com o acervo` (`nenhum` vale).
+- `## Fatias` — uma, `### F1 — fix`, com `persona:`, `arquivos:` e `cobre: C1, C2`.
 
-### 4. Plano mínimo (`2-plan/tasks.json`)
+Rode `morph-spec plan-check {feature}` até zero erro: ele grava `2-plan/checks.json`, que o
+`report-check` e o Gate 3 leem. Não pule esta escrita mesmo sob pressão de tempo.
 
-Escreva um `tasks.json` mínimo validado contra `.morph/framework/schemas/tasks.schema.json`:
+### 4. Fix cirúrgico
 
-- `T1` — o fix.
-- `T2` — verify/regressão do blast radius.
+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}"` (a `morph-apply` §3 mostra o prompt: só os campos da fatia). Inline ou despachada, a fatia termina em `3-implement/reports/F1.md` com `**Arquivos:**` e `**Checks:**` (C1 e C2 com a evidência). 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.
 
-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.
-
-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
-
-Rode a cadeia determinística focada na(s) task(s) do fix, não uma suíte ad-hoc:
+### 5. Prova
 
 ```
-morph-spec verify {feature} {task} --json
+morph-spec verify {feature} --json
 ```
 
-Use `--skip-tests`/`--skip-build` quando fizer sentido para velocidade (ex.: iterar rápido no build antes de rodar a suíte completa), mas o `T2` de verify/regressão do passo 4 precisa fechar verde antes do Gate 3. No escopo de **feature**, `--skip-tests`/`--skip-build` não gravam o stamp `verification` (`reason: 'skip-tests'`/`'skip-build'`): o Gate 3 só lê uma execução completa. Capture a saída real dos testes no `recap.md` — não descreva "testes passaram" sem colar a evidência.
+Sem filtro: é a prova que o Gate 3 lê. Para iterar rápido antes, `--skip-tests`/`--skip-build` servem, mas não gravam o stamp `verification` (`reason: 'skip-tests'`/`'skip-build'`): o Gate 3 só lê uma execução completa. C1 se prova com o sintoma reproduzido antes e ausente depois; capture a saída real no `3-implement/reports/F1.md` — não descreva "testes passaram" sem colar a evidência.
 
-### 7. Gate 3 — SEMPRE humano
+### 6. Gate 3 — SEMPRE humano
 
 O hotfix nasce com o Gate 3 em `forcedPauseGates` — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. `gate-check` já sabe disso: lê `workType` do disco e `shouldPauseGate` força a pausa antes de checar qualquer outro sinal — rode direto, sem `--signals`:
 
@@ -89,7 +81,7 @@ O hotfix nasce com o Gate 3 em `forcedPauseGates` — o Gate 3 pausa **sempre**,
 morph-spec gate-check {feature} review [--json]
 ```
 
-Escreva `4-review/review-report.md` curto: diff do fix + evidência real de teste (saída do `verify` do passo 6). Depois, **`AskUserQuestion` SEMPRE**:
+Escreva você mesmo `4-review/verifier.md` — o hotfix não despacha verificador nem revisor: `**Verdict:** SHIP|FIX`, `**Reviewed-SHA:** {git rev-parse HEAD}`, `## Checks` com C1 e C2 (`| Cn | PROVADO|NÃO PROVADO|FALHA | evidência |`, a evidência é a saída real do `verify` do passo 5), o diff do fix e `## Bloqueadores` (`Nenhum.` quando não há). Depois, **`AskUserQuestion` SEMPRE**:
 
 ```
 question: "Gate 3 — Hotfix de {feature} pronto para ship?"
@@ -108,9 +100,9 @@ morph-spec approve {feature} review --approver "<nome de quem aprovou>"
 
 `--approver` é a única assinatura que passa pelo backstop em headless — as outras rotas de `resolveApprovedBy` (`--mode auto`, e "sem TTY") resolvem para `"auto"` e são recusadas. Ela é **auto-declarada**: o CLI não consegue verificar que houve um humano, só recusa as assinaturas definitivamente não-humanas. Por isso: **nunca invente o nome** — use `--approver` só quando o humano de fato aprovou, senão o backstop do hotfix vira teatro.
 
-### 8. Pós-gate (o "test loop → ship" de `MORPH.md` §2.1)
+### 7. Pós-gate (o "test loop → ship" de `MORPH.md` §2.1)
 
-- Rode a suíte completa uma vez: `morph-spec verify {feature}` (sem escopo de task — cobertura da feature inteira, agora que o Gate 3 está aprovado).
+- Se o código mudou depois do verify do passo 5 (ajuste pedido no Gate 3), rode `morph-spec verify {feature}` de novo.
 - Feche com `morph-spec finish {feature} --pr|--merge` — o mesmo encerramento único das demais features (arquiva commitando dentro de `morph/{f}`, desmonta). Num hotfix urgente o `--merge` (local, direto na default, integra na hora) costuma ser o caminho; use `--pr` quando o fix precisa passar por CI/review antes do merge — mas `--pr` **não integra**: sai com `finished: true` e `integrated: false`, `awaiting: "merge"`. Um hotfix "fechado" por `--pr` ainda não chegou na produção — não relate o incidente como resolvido até o merge. Ver `MORPH.md` §2.2.
 - Não integre automaticamente — o usuário decide quando e por qual modo (`finish` toca a default ou o remoto). Feature legada sem `morph/{f}`: `finish` roteia para `morph-spec archive {feature}`.
 
@@ -119,24 +111,23 @@ morph-spec approve {feature} review --approver "<nome de quem aprovou>"
 - Não pular o scout — mesmo sob pressão, o mapa de blast radius evita um segundo incidente causado pelo próprio fix.
 - Não auto-aprovar o Gate 3 — nunca tente `morph-spec approve {feature} review --mode auto` num hotfix; o backstop server-side existe exatamente para isso.
 - Não "fazer do jeito certo" às custas da velocidade — refatoração, cobertura extra, ou hardening que não bloqueia o sintoma atual vira item no roadmap-fora-hotfix, não neste diff.
-- Não rodar suíte ad-hoc fora do `morph-spec verify` — a cadeia determinística é a única fonte de evidência aceita no review-report.
+- Não rodar suíte ad-hoc fora do `morph-spec verify` — a cadeia determinística é a única fonte de evidência aceita no `verifier.md`.
 
 ## Output esperado
 
-- `.morph/features/{feature}/0-proposal/proposal.md` — hotfix brief (sintoma/root cause/blast radius/plano)
-- `.morph/features/{feature}/2-plan/tasks.json` — T1 (fix) + T2 (verify/regressão)
-- `.morph/features/{feature}/3-implement/recap.md` — evidência real de teste
-- `.morph/features/{feature}/4-review/review-report.md` — diff + evidência, Gate 3 sempre humano
-- Gates `proposal`/`plan` carimbados `approvedBy: "policy:hotfix"`; Gate 3 registrado em `feature.json` (autoritativo) com uma **assinatura humana** — `"manual"` pelo `state-sync` (resposta ao `AskUserQuestion`), o nome passado em `--approver`, ou `$USER` num terminal interativo. **Nunca `"auto"`** — é o que o backstop recusa.
+- `.morph/features/{feature}/2-plan/plan.md` + `checks.json` — C1 sintoma ausente, C2 regressão, F1 fix
+- `.morph/features/{feature}/3-implement/reports/F1.md` — o relatório da fatia, com a evidência real de teste
+- `.morph/features/{feature}/4-review/verifier.md` — escrito pelo orquestrador: C1/C2 com evidência + diff, Gate 3 sempre humano
+- Gate `plan` carimbado `approvedBy: "policy:hotfix"`; Gate 3 registrado em `feature.json` (autoritativo) com uma **assinatura humana** — `"manual"` pelo `state-sync` (resposta ao `AskUserQuestion`), o nome passado em `--approver`, ou `$USER` num terminal interativo. **Nunca `"auto"`** — é o que o backstop recusa.
 
 ## Referências
 
 - `.morph/framework/MORPH.md` §2.1 — roteamento por tipo de trabalho
 - `.morph/framework/MORPH.md` §5 — Gates de aprovação, gate humano forçado no hotfix
 - `.morph/framework/MORPH.md` §6 — Sub-agents, persona de estágio scout, protocolo obrigatório
-- `.claude/skills/morph-proposal/SKILL.md` — Passo 0, roteamento que invoca esta skill
-- `.claude/skills/morph-implement/SKILL.md` §4 — template de dispatch e protocolo
+- `.claude/skills/morph-plan/SKILL.md` — roteamento que invoca esta skill
+- `.claude/skills/morph-apply/SKILL.md` §3/§5 — prompt de dispatch e retomada por `report-check`
 - `morph-spec create {feature} --type hotfix --json` — mostra a política do tipo (`scaffold`, `skippedGates`, `forcedPauseGates`) como o CLI a aplicou
 - `morph-spec create {feature} --type hotfix` — nascimento com política de gates
-- `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores
+- `morph-spec verify {feature} --json` — cadeia determinística build+testes+validadores
 - `morph-spec gate-check {feature} review [--json]` — persiste a decisão de pausa (forçada por `workType: hotfix`) antes do Gate 3

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

@@ -4,7 +4,7 @@ description: Cuida da RAM e da CPU da máquina enquanto o morph-spec trabalha
 version: core
 when_to_use: Use quando a máquina estiver lenta ou sem RAM, um comando pesado esperou ou foi recusado pela fila, sobrou worktree de sub-agent, ou vários sub-agents pesados vão rodar em paralelo
 user-invocable: false
-cliVersion: "8.47.0"
+cliVersion: "9.0.0"
 ---
 
 # morph-machine
@@ -42,5 +42,5 @@ Limites: não cobre `run_in_background`, PowerShell nem comando fora da lista; u
 
 ## Referências
 
-- `.morph/framework/CLI.md` — seções `heavy`, `worktree reap`, `doctor --procs` e `worktree.root`.
+- `.morph/framework/CLI.md` — `### heavy`, `### worktree reap`, `### doctor --procs` e `### worktree.root`.
 - `MORPH.md` §2.2 (worktrees) e a cláusula 6 dos templates de dispatch (PROCESSOS).

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

@@ -4,7 +4,7 @@ description: Conduz a AUTORIA de mídia gerada por IA — escolher o modelo pelo
 version: core
 when_to_use: Use quando a tarefa for PRODUZIR imagem ou vídeo por IA (catálogo, marketing, asset de LP) e alguém precisar decidir modelo, prompt e aprovação
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.0.0"
 stacks:
   - dotnet
   - nextjs