@polymorphism-tech/morph-spec 8.47.0 → 9.1.0

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.1.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.1.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.1.0"
 stacks:
   - dotnet
   - nextjs