@polymorphism-tech/morph-spec 9.7.0 → 10.0.0

package/framework/MORPH.md

@@ -1,189 +1,113 @@
 # MORPH.md — Natural Language Harness
 
-> 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:** `morph-spec next <f>` decide o passo do disco (fase, gates, relatórios, verify).
+> Leia uma vez por sessão (e de novo após `/compact`). `morph-spec next <f>` decide o passo a partir do disco; a mecânica de cada comando está na saída dele e em `.morph/framework/CLI.md`.
 
 ---
 
 ## 0. Contrato de Autonomia
 
-Entre gates, você opera sozinho: o dev valida, você executa.
+Entre gates, você opera sozinho: faz o que `next` mandar (`implement`, `verify`, `fix`, `review`, `finish`) sem esperar instrução nem anunciar.
 
 | Situação | O que você faz |
 | --- | --- |
-| Entre gates (gate aprovado, fatia relatada, verify verde ou vermelho) | Faz o que `morph-spec next <f>` mandar — `dispatch`, `verify` (uma vez, sem filtro), `fix`, `review`, `finish` — sem esperar instrução nem anunciar |
-| 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` |
-| Cenário `Cn` sem evidência | Loop de correção com o feedback, como o verify vermelho, antes da review |
-| `next` devolve `escalate` | `AskUserQuestion` (aceitar/continuar/parar), o único ponto de pausa do loop; nunca uma 4ª tentativa por conta própria |
-| `verify` exit 3 | fila cheia, não vermelho: no máximo uma chamada nova, nunca laço de espera |
+| Ambiguidade que o plano cobre | resolve pelo lado conservador e anota em `## Notas` do `report.md` |
+| Ambiguidade bloqueante (requisito ausente ou contraditório) | uma pergunta via `AskUserQuestion` |
+| `next` devolve `escalate` (3 verify vermelhos seguidos) | `AskUserQuestion`: aceitar, continuar ou parar. Nunca uma 4ª tentativa por conta própria |
+| `verify` exit 3 | fila cheia, não vermelho: no máximo uma chamada nova |
 
-**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` 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. 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) |
-| 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, só com razão real |
-
-Padrões proibidos (os standards detalham; o mecânico, o build e o lint cobram): exception como fluxo de controle (o Result põe o erro esperado no tipo); Service/Manager entre handler e dados; `IRepository<T>`/`IUnitOfWork` (`DbSet<T>` já é repository); SQL cru sem ADR; redeclarar tipo que já existe (antes, `morph-spec graph explain <nome>`, sem grafo `grep -rn`; criar exige `CRIAR` com `why` em `## Reuso`).
+Na abertura do plano vale o contrário: o modo entrevista pergunta até fechar o entendimento. **A prova é o código:** `verify` prova o determinístico, o Gate 3 prova cada cenário `Cn`. Estilo é nota, nunca bloqueio.
 
 ---
 
 ## 1. Papéis
 
-A transição entre papéis é explícita: conclua ou registre no relatório antes de 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.
+**Você** planeja, implementa o plano inteiro nesta janela, corrige e fecha. O que aprendeu implementando vale para o resto da feature: não existe handoff.
 
-**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.
-
-**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.
+**Gate 3** são sub-agents em contexto fresco, porque o que você sabe é exatamente o ponto cego que eles existem para não herdar: `morph-verifier` executa cada `Cn` contra a app, `morph-reviewer` julga o diff contra o plano, `morph-security` (só com caminho sensível) procura o caminho de exploração. Nenhum deles reescreve código.
 
 ---
 
 ## 2. Fases
 
-Cada fase tem pasta em `.morph/features/{feature}/`. Identidade do projeto: `.morph/config/config.json` (commitado).
-
-| Fase | Pasta | Gate | O que termina a fase |
+| Fase | Pasta | Gate | Termina com |
 | --- | --- | --- | --- |
-| 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`; chore: só `reviewer.md`) e o gate aprovado |
+| plan | `2-plan/` | plano | `plan.md` + `checks.json` (`plan-check`) aprovados |
+| uiux (opcional) | `1-design/` | uiux | protótipos escolhidos e checklist de tela |
+| implement | `3-implement/` | — | todo `Cn` `feito` no `report.md` e `verify` verde |
+| review | `4-review/` | Gate 3 | `verifier.md` + `reviewer.md` (+ `security.md`) e o gate aprovado |
 
-Sequência: `plan → [uiux] → implement → review`. Não avance sem o gate da fase.
-
-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`.
+`plan → [uiux] → implement → review`. Feature/bug com superfície de UI toma o ramo uiux (`advance --design`), decidido uma vez na `morph-plan`.
 
 ### 2.1 Roteamento por tipo de trabalho
 
-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).
+`morph-spec create <f> --request "<pedido>"` (ou `--type <t> --description "…"`).
 
 | Tipo | Pipeline | Gates |
 | --- | --- | --- |
-| `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 |
-
-**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.
+| `feature` | plan → [uiux] → implement → review | plano, [uiux], Gate 3 |
+| `bug` | plano enxuto (repro + causa) → implement → review | plano, Gate 3 |
+| `chore` | plano curto carimbado → implement → só revisor | Gate 3 |
+| `hotfix` | plano curto carimbado → fix → `verifier.md` seu → humano | Gate 3, sempre humano |
 
-**Skip:** `chore`/`hotfix` começam em `implement` com um `plan.md` curto de uma fatia (hotfix: C1 = sintoma ausente, C2 = regressão) e `plan-check`; trocar o tipo: `morph-spec retype`.
-
-**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).
+Toda feature nasce em `morph/{f}` e fecha com `morph-spec finish <f> --pr|--merge`.
 
 ### 2.2 Desenvolvimento paralelo por worktree (frota)
 
-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}`.
+Features independentes rodam em paralelo, **uma feature = um worktree = uma sessão**: `create <f> --worktree`. Dentro de uma feature, nunca paralelo.
 
-- **Uma feature = um worktree = uma instância.** `feature.json` viaja commitado em `morph/{f}`; a cópia da raiz é esqueleto.
-- **Só o morph cria worktree:** `worktree setup <f>` (feature) ou `worktree provision <n>` (isolamento de fatia, branch `morph-task/<n>`). `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.** Qualquer outra remoção atravessa a junction e apaga o conteúdo real da raiz (os hooks barram as formas conhecidas; o explorador, não). Fechar = `morph-spec finish <f> --pr|--merge`; só desmontar = `morph-spec worktree remove <f>`. 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)"`). `finish` derruba o stack com volumes (`--keep-volumes` preserva). Fora do `verify`, build e teste pesados vão por `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`. **`--pr` não integra:** a feature fica `aguardando-merge` até alguém mergear, nunca "entregue" só por `finished: true`.
+- **Só o morph cria worktree:** `worktree setup <f>` (feature) ou `worktree provision <n>` (árvore avulsa); `EnterWorktree`/`claude -w` passam pelo hook `WorktreeCreate`. Já existe: abra o `claude` dentro dela.
+- **Só o morph remove worktree.** `finish` ou `worktree remove`; qualquer outra remoção atravessa a junction e apaga a raiz.
+- **Ambiente dedicado:** `.morph/worktree.env` (`PORT`, `API_PORT`, `POSTGRES_PORT`, `COMPOSE_PROJECT_NAME`) e compose próprio; `finish` derruba com volumes (`--keep-volumes` preserva). Build e teste pesados fora do `verify` vão por `heavy run -- <cmd>`.
+- Migração destrutiva ou dependência nova: integre antes de abrir irmãos. Visão agregada: `fleet`.
+- **`--pr` não integra:** a feature fica `aguardando-merge` até o merge.
 
 ---
 
 ## 3. Contratos de Output
 
-### Plan (`2-plan/`)
-
-- `plan.md` — fonte única da feature (esqueleto do `create`; chore/hotfix: você o cria), gramática em `morph-spec plan-check --help`. Lido uma vez por sessão e pós-`/compact`.
-- `checks.json` — escrito só pelo `plan-check`; é a régua que o verificador prova item a item.
-- `stack-scan.md` e `scout-map.md` (§6) — insumos do plano.
-
-**Congelamento:** aprovado o gate do plano, o corpo do `plan.md` trava: quem implementa não afrouxa o critério que prova o trabalho. Fato que o código desmente vai em `## Errata` no fim (append-only); escopo mudou → `morph-spec unapprove {f} plan`.
-
-### Implement (`3-implement/`)
-
-- `3-implement/reports/F{n}.md` — um por fatia (sub-agent, ou você se inline); 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/`)
-
-- `verifier.md`, `reviewer.md`, `security.md` (só com caminho sensível) — formato em `.morph/framework/evals/review-checklist.md`; vale o último veredito.
+- `plan.md` (`2-plan/`) — fonte única, lida uma vez por sessão e de novo após `/compact` (gramática: `plan-check --help`). Aprovado, o corpo congela: fato que o código desmente vai em `## Errata` no fim; escopo mudou → `unapprove {f} plan`.
+- `2-plan/checks.json` — escrito só pelo `plan-check`; a régua do Gate 3.
+- `3-implement/report.md` — tabela `| Cn | status | evidência |` (`pendente`/`feito`/`bloqueado`) e `## Notas` append-only. É a sua memória depois de um `/compact`: atualize ao fechar cada `Cn`.
+- `3-implement/evidencias/{Cn}.md` — só para `prova: eval` ou `manual`.
+- `4-review/{verifier,reviewer,security}.md` — formato em `.morph/framework/evals/review-checklist.md`; vale o último veredito.
 
 ---
 
 ## 4. Como consultar Standards
 
-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:
-
-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.
-
-Inline, o campo `persona` do domínio em `.morph/framework/agents.json` dá o ponto de vista e o rigor.
+Nunca carregue todos. `morph-spec standards --find "<tema>"` dá o top 3 com digest (costuma bastar) → `--show <id>#<âncora>` só a seção → o arquivo inteiro só pelo exemplo completo. As regras de cada domínio chegam pela rule do stack (`.claude/rules/`, por `paths:`) quando você toca o arquivo. Nenhum standard cobre: anote o critério nas `## Notas`; não invente standard.
 
 ---
 
 ## 5. Gates de Aprovação (Trust Mode)
 
-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).
-
-**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`:
-
-| 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) |
-
-Risco que nenhum sinal representa: `morph-spec gate-decision <feature> <gate> --pause <bool> --reason <txt>`. Sinais completos: CLI.md (`gate-check`).
-
-**Gates por tipo:** o Gate 3 vale para todos; em `hotfix` é sempre humano (o `approve` recusa `--mode auto`) e exige só `4-review/verifier.md`, escrito pelo orquestrador.
+**Quem decide é o código:** `gate-check <f> <gate>` decide pelo disco a pausa e quem a resolve. O que o disco não mostra vai por `--signals` (lista no `CLI.md`); outro risco, `gate-decision <f> <gate> --pause <bool> --reason <txt>`.
 
-**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 "aprovado, prosseguir" da pergunta que nomeia a feature; outra resposta → `morph-spec approve`.
+- `pause: false` → uma linha e `approve <f> <gate> --mode auto` (ou `advance`).
+- `resolver: session` → faça o que a `reason` diz e rode `gate-check` de novo, sem perguntar.
+- `resolver: human` → `AskUserQuestion` que **nomeia a feature** ("Gate do plano — Plano de {f} aprovado?"): o `state-sync` grava a aprovação por ela.
+- Hotfix: `approve` recusa `--mode auto`. Estado só pela CLI, nunca no `feature.json`.
 
 ---
 
-## 6. Sub-agents
-
-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:
-
-- **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.
+## 6. Contexto
 
-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.
+Uma pergunta decide se algo sai da sua janela: **o que você já sabe ajuda, atrapalha ou não importa?**
 
-**Mecanismo:** `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`); a persona é o system prompt, gerada de `agents.json` em `.claude/agents/`. Tipo não registrado: `general-purpose` com o `persona` colado no prompt, registrado no relatório da fatia.
+- **Ajuda** → faça aqui. Domínio diferente, arquivo grande ou tarefa longa não são motivo para despachar: o plano inteiro se implementa nesta sessão, em sequência. Se a janela encher, `/compact` — o `report.md` e o plano guardam o estado.
+- **Atrapalha** → Gate 3, em contexto fresco (`morph-apply` › `references/review.md`).
+- **Não importa** → pesquisa externa sem nada do projeto pode ir a um sub-agent descartável.
 
-**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 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.
-
-**O arquivo é o retorno; a última mensagem é cortesia** (pode não chegar): leia o relatório no caminho canônico.
+Rode build e teste quando quiser enquanto implementa; a prova do gate é um `verify <f>` sem filtro.
 
 ### Protocolo de auditoria do relatório
 
-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.
-
-**Teto de turnos:** o corte é cego; relatório `PARCIAL` vira `report-incomplete` com ação `resume`: retome o mesmo agente, não carimbe DEGRADADO.
-
-**Paralelo:** fluxos genuinamente independentes (backend ‖ frontend) vão ao mesmo tempo, um agente por fatia, até 4. As ondas saem do `plan-check`. 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).
+O arquivo é o retorno; a mensagem final do sub-agent é cortesia. `morph-spec report-check <f> --json` diz o estado de cada relatório do Gate 3: `complete` não se despacha de novo; `partial` (`PARCIAL` na 1ª linha) ou ausente → despache. Rodada de confirmação depois de uma correção é um dispatch **novo** com o `sha` novo, nunca uma conversa com o agente anterior.
 
 ---
 
 ## 7. Skills disponíveis
 
-**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`.
+**Skills core** (`.claude/skills/{nome}/SKILL.md`): `morph-plan` (pedido → plano aprovado) · `morph-apply` (plano → código → verify → Gate 3 → finish; hotfix e chore são deltas dela) · `morph-uiux` (opções renderizadas → protótipo → gate uiux).
 
-`/morph-plan` invoca a skill direto; `/morph-apply` e `/morph-hotfix` são atalhos da skill homônima. Desvio do passo a passo vai justificado no relatório.
+`/morph-plan`, `/morph-apply`, `/morph-hotfix` e `/morph-review` invocam a skill no passo certo. Detalhe sob demanda em `references/` de cada skill.