@polymorphism-tech/morph-spec 7.9.3 → 8.0.0

package/framework/skills/core/create-umbraco-lp/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a criação de uma landing page nova ponta-a-ponta a partir do
 version: core
 when-to-invoke: ao iniciar um novo projeto de LP com o template Umbraco genérico
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # create-umbraco-lp

package/framework/skills/core/migrate-lp-to-umbraco/SKILL.md

@@ -4,7 +4,7 @@ description: Migra uma landing page existente (React/Vite, Next.js estático ou
 version: core
 when-to-invoke: ao receber instrução "use /migrate-lp-to-umbraco {projeto}" do usuário, ou quando o usuário descrever necessidade de migrar uma LP para Umbraco
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # migrate-lp-to-umbraco

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

@@ -4,7 +4,7 @@ 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: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-apply
@@ -50,6 +50,8 @@ O comando analisa `dependencies`, `group` e `effort` das tasks pendentes e impri
 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.
 
 > **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*.
@@ -79,7 +81,16 @@ while (true):
   while attempt < 3:
     attempt += 1
     invoke Skill(morph-implement) with task
-      (no attempt > 1: passar o feedback priorizado do morph-eval anterior como input)
+      (no attempt > 1: passar o feedback priorizado da tentativa anterior como input)
+
+    // CÓDIGO ANTES DO JUIZ — barreira determinística e barata (build+testes+validadores).
+    run: morph-spec verify {feature} {task.id} --json
+    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
@@ -102,6 +113,8 @@ while (true):
     options: [aceitar (marca done com ressalva no recap), continuar tentando (+3 tentativas), pular task (marca blocked)]
 ```
 
+> **Verify vermelho consome uma tentativa** do loop (≤3) e devolve `feedback[]` acionável (erros de build, falhas de teste, 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.
+
 > **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.
 
 ### 3b. Modo Paralelo (para o subset independente)
@@ -139,9 +152,14 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
        (TaskCreate/TaskUpdate) — todo estado (status de task, scores, gates) é
        gravado exclusivamente pelo orquestrador.
-    3. Você roda em batch paralelo: NÃO rode build/test da suíte compartilhada
-       (dotnet test / npm test do projeto inteiro) — edições concorrentes quebram
-       o build umas das outras; a verificação é do orquestrador, pós-batch.
+    3. Verificação condicional ao isolamento:
+       - Batch SEM isolamento (working tree compartilhada): NÃO rode build/test da
+         suíte compartilhada — edições concorrentes quebram o build umas das outras;
+         a verificação é do orquestrador, uma vez, pós-batch (`morph-spec verify`).
+       - Batch COM isolamento (você recebeu `isolation: "worktree"`): rode build/test
+         DENTRO do seu worktree; commite seu trabalho na branch do worktree como
+         penúltimo ato (antes do SendMessage); reporte a branch + status de build no
+         relatório; NUNCA faça merge nem toque na árvore principal.
 
     Retorne no content do SendMessage:
       - sumário das mudanças
@@ -152,10 +170,10 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 
 > 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 cláusulas de protocolo. 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): despache com `isolation: "worktree"` — cada agente trabalha numa working tree própria e o orquestrador integra ao final. Nesse caso a cláusula 3 vira "rode build/test apenas dentro do seu worktree".
+> **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.
 
 Aguardar todos os agentes terminarem. O hook `subagent-report-guard` (Stop/SubagentStop) bloqueia uma vez o encerramento de um subagent despachado que não chamou SendMessage, com a instrução da cláusula 1 — o ciclo cobrar-esperar deixa de ser o caminho normal. **Fallback: se mesmo assim um agente ficar idle sem entregar o relatório, cobre-o via SendMessage e registre a falha de protocolo no recap.** Assim que o relatório de um agente chegar (SendMessage como teammate-message), **libere a sessão imediatamente** — chame `TaskStop(task_id: <id/nome do agente retornado pelo dispatch>)` antes de seguir para o próximo agente. Não espere o idle-detector do harness: sem esse `TaskStop`, a sessão fica pendurada minutos até o harness marcá-la idle sozinho e injetar um `idle_notification` vazio de volta nesta sessão. Trate falha do TaskStop (agente já finalizado sozinho) como não-fatal. Depois, sequencialmente:
-- **Rodar a verificação compartilhada uma única vez** (build + suíte de testes do projeto) — os agentes não a rodaram (cláusula 3 do protocolo).
+- **Rodar `morph-spec verify {feature} --json` uma única vez, pós-batch** (escopo feature) — 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}`.
@@ -164,6 +182,18 @@ Aguardar todos os agentes terminarem. O hook `subagent-report-guard` (Stop/Subag
 
 Depois do batch paralelo, executar o restante em modo sequencial (passo 3a).
 
+### 3b-w. Batch isolado por worktree (quando o dag recomenda)
+
+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.
+
+1. **Dispatch:** mesmo `subagent_type: "morph-{id}"` e standards de §3b, mais `isolation: "worktree"`. Se a stack for Node e faltar `node_modules` no worktree, o agente roda `morph-spec worktree link` (fail-open) antes de testar; se ainda impossível, reporta "verificação: não executada" (o verify pós-merge cobre). O agente commita na branch do worktree e reporta a branch.
+2. **Integração (orquestrador, após todos os relatórios + `TaskStop`):** 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:** rode `morph-spec verify {feature} --json` UMA vez (o merge é o novo ponto de integração — verificação compartilhada obrigatória), depois `morph-eval` + `morph-spec score` por relatório, como em §3b.
+4. **Cleanup:** `git worktree remove` + `git branch -d` das branches integradas + `git worktree prune` (fail-open). 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.
+
+> 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).
+
 ### 4. Conclusão de tasks
 
 Quando `getPendingTasks(data).length === 0`:
@@ -222,7 +252,8 @@ O comando grava `gateDecisions.review = { pause, reason, signals, trust, decided
 - `framework/skills/core/morph-implement/SKILL.md`
 - `framework/skills/core/morph-eval/SKILL.md`
 - `framework/skills/core/morph-review/SKILL.md`
-- `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort)
+- `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 (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-decision {feature} {gate} --pause {bool} [--reason ...] [--signals ...]` — grava gateDecisions no feature.json com timestamp server-side (shape em `.morph/framework/schemas/feature.schema.json`)
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-brainstorming
@@ -29,6 +29,12 @@ O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos qu
 
 **Padrões proibidos:** `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions sem result pattern, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), SQL cru sem justificativa. Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
 
+## Modo bug-lean (`workType: bug`)
+
+Quando a feature tem `workType: bug` (roteada pela `morph-proposal` — ver MORPH.md §2.1 "Roteamento por tipo de trabalho"), o brainstorming é enxuto: pule as 4 perguntas de negócio da Parte 1 e faça **no máximo 1 pergunta de repro** via `AskUserQuestion` (como reproduzir, em qual ambiente) — só se isso não estiver claro no pedido original. O `stack-scan` (Parte 2) continua rodando normalmente, o diagnóstico precisa do contexto técnico. O `proposal.md` (Parte 3) foca em **Repro / Diagnóstico / Root cause provável / Escopo do fix / Critérios de aceite**, sem as perguntas de negócio completas.
+
+Para `workType: feature` (ou features sem `workType` — compat, ver MORPH.md §2.1), o fluxo completo abaixo permanece integral.
+
 ## O que fazer
 
 ### Parte 1 — Entendimento de negócio
@@ -71,6 +77,8 @@ O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos qu
    - **Riscos e dependências:** o que pode dar errado, o que esta feature depende
    - **Compliance de stack:** "Em compliance" ou lista de desvios detectados e plano de resolução
 
+   **Se `workType: bug`** (modo bug-lean, ver nota no início da skill), substitua a lista acima pela estrutura enxuta: **Repro** (passos para reproduzir), **Diagnóstico** (o que foi observado/investigado), **Root cause provável**, **Escopo do fix** (o que muda, o que fica de fora) e **Critérios de aceite** (condição verificável de que o bug foi corrigido) — sem as seções de negócio completas do fluxo `feature`.
+
    Um bom proposal.md tem no máximo 2 páginas. Se está crescendo além disso, o escopo precisa ser cortado.
 
 5. Apresente o Gate 1 segundo trust mode.

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

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-eval
@@ -17,10 +17,14 @@ O objetivo não é punir — é identificar o que melhorar antes de seguir adian
 Após concluir uma tarefa ou ao finalizar a fase de implementação.
 Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 
+**Somente após `morph-spec verify {feature} {task}` verde** (a `morph-apply` garante isso no loop §3a). O verify é a barreira determinística (build+testes+validadores); esta skill julga o que o código não pega: arquitetura, contratos, qualidade, cobertura qualitativa.
+
 > **Escopo de fase (Gate 3):** a avaliação da feature inteira NÃO é feita por quem implementou — a `morph-review` despacha a persona `evaluator` de `agents.json` (contexto fresco, sem autoria; recebe mandate + diff + saída real dos testes) usando esta skill como guia. O eval por task pode ser inline; o score composto do Gate 3 vem sempre do avaliador independente.
 
 ## O que fazer
 
+0. Confirme que o `morph-spec verify` da task está verde (a morph-apply passa o resultado; numa invocação manual, rode `morph-spec verify {feature} {task} --json`). Se estiver vermelho, NÃO avalie — devolva o `feedback[]` do verify ao loop de correção.
+
 1. Identifique o escopo da avaliação: tarefa única ou fase completa.
 
 2. Para cada dimensão, leia a rubrica correspondente em `.morph/framework/evals/rubrics/`:
@@ -48,6 +52,7 @@ Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 - Score persistido em `taskScores` via `morph-spec score` (o trace é gerado automaticamente pelo hook `trace-autogen`)
 
 ## Referências
+- `morph-spec verify {feature} [task] --json` — barreira determinística (build+testes+validadores) que precede esta skill
 - `.morph/framework/evals/rubrics/architecture.md` — rubrica de arquitetura (30%)
 - `.morph/framework/evals/rubrics/contracts.md` — rubrica de contratos (25%)
 - `.morph/framework/evals/rubrics/code-quality.md` — rubrica de qualidade (25%)

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

@@ -0,0 +1,136 @@
+---
+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-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.0.0"
+---
+
+# morph-hotfix
+
+## Objetivo
+
+Resolver uma queda ou bug crítico de produção o mais rápido possível — prioridade é velocidade, não elegância — mantendo aprovação humana obrigatória antes do ship. É o pipeline dimensionado por `workType: hotfix` (MORPH.md §2.1): scout → fix cirúrgico → aprovação humana → test loop → ship.
+
+## 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.
+- Usuário diz "produção caiu", "hotfix", "urgente", "incident", "P0" — sinais que o detector determinístico de `morph-spec create --request` já reconhece.
+
+## Argumentos
+
+- `{feature-name}` — nome em kebab-case da feature. Se ausente, perguntar via `AskUserQuestion`.
+
+## Fluxo
+
+### 1. Nascimento da feature
+
+```
+morph-spec create {feature} --type hotfix
+```
+
+Carimba os gates `proposal` e `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.
+
+### 2. Scout — mapa do território (obrigatório)
+
+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**.
+
+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 3 cláusulas de protocolo obrigatório no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): ato final = relatório via `SendMessage` para `main` como a ÚLTIMA tool call do turno, sem texto ou tool call depois; 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.
+
+Ao receber o mapa via `SendMessage`, **libere a sessão imediatamente**: `TaskStop(task_id: <id/nome retornado pelo dispatch>)` (trate falha como não-fatal).
+
+### 3. Hotfix brief (`0-proposal/proposal.md`)
+
+Escreva o brief curto (~20 linhas) reutilizando o nome canônico `proposal.md`:
+
+- **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.
+
+### 4. Plano mínimo (`2-plan/tasks.json`)
+
+Escreva um `tasks.json` mínimo validado contra `framework/schemas/tasks.schema.json`:
+
+- `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.
+
+### 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.
+
+### 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:
+
+```
+morph-spec verify {feature} {task} --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. Capture a saída real dos testes no `recap.md` — não descreva "testes passaram" sem colar a evidência.
+
+### 7. Gate 3 — SEMPRE humano
+
+O hotfix tem `forcedPauseGates: ['review']` (`src/core/work-types.js`) — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. Persista a decisão antes de apresentar:
+
+```
+morph-spec gate-decision {feature} review --pause true --reason "hotfix: aprovação humana obrigatória" --signals '{"workType":"hotfix","evalScore":X}'
+```
+
+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**:
+
+```
+question: "Gate 3 — Hotfix de {feature} pronto para ship?"
+header: "Gate 3"
+options:
+  - { label: "aprovado, ship", description: "Aceitar o fix e liberar para produção" }
+  - { label: "preciso ajustar", description: "Apontar correções antes de fechar" }
+  - { label: "rollback", description: "Desfazer o fix — voltar ao estado anterior" }
+```
+
+**NUNCA `morph-spec approve {feature} review --mode auto`** — o CLI recusa explicitamente essa combinação (`src/commands/state/approve.js`: `gateName === 'review' && feature.workType === 'hotfix' && approvedBy === 'auto'` é bloqueado) porque `forcedPauseGates` sobrepõe qualquer trust mode. Em contexto headless (sem `AskUserQuestion` disponível), a resposta textual "aprovado" do usuário é registrada pelo hook `state-sync` como `approvedBy: "manual"` — nunca `"auto"`.
+
+### 8. 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).
+- Sinalize ao usuário: commit do fix e `morph-spec archive {feature}` (ou `morph-spec worktree finish {feature}` se a feature nasceu em worktree — ver `MORPH.md` §2.2) estão prontos.
+- Não arquive automaticamente — usuário decide quando.
+
+## Anti-padrões
+
+- 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.
+
+## 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 `approvedBy: "manual"` em `feature.json` (autoritativo) — nunca `"auto"`
+
+## 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
+- `framework/skills/core/morph-proposal/SKILL.md` — Passo 0, roteamento que invoca esta skill
+- `framework/skills/core/morph-implement/SKILL.md` §4 — template de dispatch e protocolo
+- `src/core/work-types.js` — `scaffold`/`skippedGates`/`forcedPauseGates` do tipo `hotfix`
+- `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 gate-decision {feature} review --pause true [--reason ...] [--signals ...]` — persiste a decisão de pausa antes do Gate 3

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

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-implement
@@ -76,8 +76,12 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
       (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo
       orquestrador.
-   3. Se você faz parte de um batch paralelo, NÃO rode build/test da suíte
-      compartilhada — a verificação é do orquestrador, pós-batch.
+   3. Verificação condicional ao isolamento: em batch paralelo SEM isolamento,
+      NÃO rode build/test da suíte compartilhada — a verificação
+      (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch
+      COM `isolation: "worktree"`, rode build/test dentro do seu worktree,
+      commite na branch do worktree como penúltimo ato (antes do SendMessage)
+      e reporte a branch — nunca faça merge.
 
    Retorne no content do SendMessage APENAS: (1) o que foi feito em 2-3 frases,
    (2) arquivos modificados, (3) problemas encontrados e como foram resolvidos,
@@ -137,7 +141,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
    > manualmente** — a escrita manual foi removida da cerimônia por task.
 
-8. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
+8. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
 
 ## Output esperado
 - Código implementado conforme o standard consultado (direto ou via sub-agent)

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

@@ -4,7 +4,7 @@ description: Guia a produção dos três artefatos de planejamento de uma featur
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-plan
@@ -73,10 +73,14 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    - `group` (opcional): backend, frontend, tests, infra, docs. Default backend.
    - `outputs` (opcional): array de paths que serão criados/modificados.
 
+   **Preencha `outputs` (paths planejados) em cada task** — o `morph-spec dag` usa os outputs para detectar colisão de arquivos entre fluxos paralelos e recomendar `isolation: "worktree"`. Task sem `outputs` entra como footprint desconhecido (não força isolamento, mas o dag não consegue protegê-la de colisão).
+
    Antes de retornar, valide rodando `morph-spec dag {feature}` — o comando parseia e valida o schema do tasks.json (ids únicos `T\d+`, enums de `status`/`effort`, `dependencies` válidas) e já imprime a análise de DAG que a `/morph-apply` vai usar. Erros de schema abortam com a lista do que corrigir.
 
 5. Apresente o Gate 2 segundo trust mode.
 
+   Você pode embutir o diagrama do DAG do plano via `morph-spec dag {feature} --mermaid` (flowchart Mermaid) para visualização no gate.
+
    Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
 
    - `taskCount` = número de tasks do tasks.json.

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

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-proposal
@@ -30,6 +30,26 @@ Conduzir uma feature do request inicial até o plano aprovado (Gate 2), sem inte
 
 ## Fluxo
 
+### 0. Roteamento por tipo de trabalho
+
+Antes de qualquer trabalho de negócio, classifique o pedido. Se `{feature-name}` ainda não foi determinado, pergunte via `AskUserQuestion` antes desta chamada (ver Argumentos):
+
+```
+morph-spec create {feature-name} --request "<pedido do usuário>"
+```
+
+(ou `--type <tipo>` diretamente quando o tipo é óbvio pelo pedido — ex.: o usuário já diz "isso é um hotfix").
+
+- **Classificação `high` confidence** — a feature nasce com o `workType` decidido pelo detector determinístico (keywords: `hotfix` — "produção caiu/urgente/incident/p0"; `bug` — "bug/corrigir/exception/regressão"; `chore` — "typo/rename/bump/config/docs/cleanup"). Prossiga para o branch correspondente abaixo.
+- **Exit 2** (empate `tie` ou nenhum sinal `none`) — o comando sai sem criar a feature e imprime `{ needsDecision, candidates, matched }`. **Você é o roteador**: decida o tipo entre os candidatos e re-rode com `morph-spec create {feature-name} --type <tipo>`. Só use `AskUserQuestion` para o usuário quando o pedido for genuinamente indeterminado — a maioria dos empates o roteador resolve sozinho pelo contexto da conversa.
+
+**Branches por tipo** (dimensionamento completo em `MORPH.md` §2.1):
+
+- **`hotfix`** → invoque `Skill(morph-hotfix)` passando `{feature-name}` e **ENCERRE** — não siga o restante deste fluxo. A skill cuida de scout, brief, fix cirúrgico, test loop e Gate 3 (sempre humano).
+- **`chore`** → fast-track: os Gates 1 e 2 já nasceram carimbados `policy:chore` no `create`. Escreva um `2-plan/tasks.json` mínimo (1-3 tasks) e invoque `Skill(morph-apply)` diretamente — **exceção documentada** à regra do passo 7 ("não despachar `morph-apply` automaticamente"): não pausar numa mudança óbvia é exatamente o valor do fast-track.
+- **`bug`** → siga para `Skill(morph-brainstorming)` em modo **bug-lean**: produz um `proposal.md` enxuto (repro / diagnóstico / root cause / escopo / critério de aceite — não a proposta completa de uma feature nova) e depois um plano enxuto via `Skill(morph-plan)`. Gates 1 e 2 continuam trust-aware (passos 3 e 6) — só o conteúdo dos artefatos é mais curto.
+- **`feature`** (default — inclui features criadas antes do v8 sem `workType`) → siga o fluxo completo abaixo (passos 1-7): brainstorming → Gate 1 → plan → Gate 2.
+
 ### 1. Determinar feature name e estado
 
 - Se argumento ausente: perguntar via `AskUserQuestion` (1 pergunta, header "Feature").
@@ -117,6 +137,7 @@ Lógica idêntica ao passo 3 (`shouldPauseGate` + AskUserQuestion ou auto-aprova
 - Não pular o Gate 1 mesmo em trust:auto se houver divergência detectada.
 - Não escrever código nesta fase — apenas artefatos de planejamento.
 - Não perguntar sobre stack — o stack padrão está em MORPH.md / mandate.
+- Não rodar o pipeline completo de 5 fases num `chore` ou `bug` óbvio — o Passo 0 existe para dimensionar o trabalho pelo `workType`, não para ser pulado "para simplificar".
 
 ## Output esperado
 
@@ -129,6 +150,8 @@ Lógica idêntica ao passo 3 (`shouldPauseGate` + AskUserQuestion ou auto-aprova
 ## Referências
 
 - `.morph/framework/MORPH.md` — charter NLH completo
+- `.morph/framework/MORPH.md` §2.1 — roteamento por tipo de trabalho (Passo 0)
 - `framework/skills/core/morph-brainstorming/SKILL.md`
 - `framework/skills/core/morph-plan/SKILL.md`
+- `framework/skills/core/morph-hotfix/SKILL.md` — pipeline invocado pelo branch `hotfix` do Passo 0
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-review
@@ -43,7 +43,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
      outro propósito. Falha aqui é bloqueante — quebra silenciosa em runtime, não em build.
 
 4. **Despache o avaliador independente** — o score do Gate 3 nunca é auto-atribuído por quem implementou:
-   - Rode a suíte de testes do projeto e capture a **saída real** (não um resumo seu).
+   - Rode `morph-spec verify {feature} --json` (escopo feature) e capture o JSON — é a saída real de build+testes+validadores que você anexa ao prompt do avaliador independente (`morph-evaluator`).
    - Gere o **diff da implementação** (`git diff` do range da feature, ou a lista de arquivos do recap.md com seus conteúdos atuais).
    - Despache o subagent registrado `morph-evaluator` (gerado de `agents.json` — a persona do avaliador é o system prompt dele, com tools read-only), com contexto fresco:
      ```
@@ -126,6 +126,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 - Gate 3 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo), na forma canônica `{ approved, timestamp, approvedBy }` — via `morph-spec approve` em auto, ou pelo hook state-sync no caminho manual
 
 ## Referências
+- `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores anexada ao prompt do avaliador (passo 4)
 - `.morph/framework/MORPH.md` — seção 5 (Gate 3 + regras de pausa), seção 1 (papel Evaluator), Trust Mode
 - `.claude/agents/morph-evaluator.md` — subagent do avaliador (gerado de `.morph/framework/agents.json`), despachado no passo 4
 - `framework/skills/core/morph-eval/SKILL.md` — rubricas e bandas que o avaliador aplica

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-stack-scan

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

@@ -4,7 +4,7 @@ description: Localiza e carrega um standard específico do STANDARDS.json sob de
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "7.9.3"
+cliVersion: "8.0.0"
 ---
 
 # morph-standards

package/framework/standards/STANDARDS.json

@@ -941,10 +941,15 @@
         "signature validator",
         "jwks",
         "middleware runtime",
-        "api prefix"
+        "api prefix",
+        "data api",
+        "postgrest",
+        "bypass backend",
+        "direct database access"
       ],
       "anchors": {
         "setup": "#installation--setup",
+        "data-access-boundary": "#data-access-boundary--backend-first-by-default",
         "onboarding": "#onboarding-checklist--do-this-before-testing-login-mandatory",
         "middleware": "#route-protection-middleware",
         "api-prefix": "#api-prefix-convention--server-direct-vs-client-proxy",
@@ -952,7 +957,7 @@
         "rls": "#row-level-security-integration",
         "postmortem": "#known-failure-modes-postmortem"
       },
-      "digest": "Use @neondatabase/auth SDK for Next.js. Auth data lives in neon_auth schema — no external provider, no webhooks. Server: createNeonAuth() with NEON_AUTH_BASE_URL + NEON_AUTH_COOKIE_SECRET. Client: createAuthClient(). Pages: AuthView component. Protection: auth.middleware() with runtime='nodejs' (Edge times out minting the session cookie). Register every dev/preview origin in trusted_origins before testing login. Two named prefix constants (BACKEND_API_PREFIX / PROXY_API_PREFIX) — never share one between server-direct and client-proxy calls. .NET: tokens are EdDSA/Ed25519 (OKP) — Microsoft.IdentityModel.Tokens can't verify OKP keys and there's no OIDC discovery; fetch+cache the JWKS yourself and verify signatures manually via BouncyCastle.Cryptography + TokenValidationParameters.SignatureValidator (must return Microsoft.IdentityModel.JsonWebTokens.JsonWebToken, not JwtSecurityToken — else IDX10506). NeonAuth:BaseUrl is mandatory in appsettings.Development.json (public value). RLS: auth.user_id() via pg_session_jwt."
+      "digest": "Use @neondatabase/auth SDK for Next.js. Auth data lives in neon_auth schema — no external provider, no webhooks. Server: createNeonAuth() with NEON_AUTH_BASE_URL + NEON_AUTH_COOKIE_SECRET. Client: createAuthClient(). Pages: AuthView component. Protection: auth.middleware() with runtime='nodejs' (Edge times out minting the session cookie). Register every dev/preview origin in trusted_origins before testing login. Two named prefix constants (BACKEND_API_PREFIX / PROXY_API_PREFIX) — never share one between server-direct and client-proxy calls. Frontend never queries Neon directly for business data by default — only its own auth/session SDK; a Data API bypass requires a decisions.md ADR. .NET: tokens are EdDSA/Ed25519 (OKP) — Microsoft.IdentityModel.Tokens can't verify OKP keys and there's no OIDC discovery; fetch+cache the JWKS yourself and verify signatures manually via BouncyCastle.Cryptography + TokenValidationParameters.SignatureValidator (must return Microsoft.IdentityModel.JsonWebTokens.JsonWebToken, not JwtSecurityToken — else IDX10506). NeonAuth:BaseUrl is mandatory in appsettings.Development.json (public value). RLS: auth.user_id() via pg_session_jwt."
     },
     {
       "id": "backend-integrations-hangfire-hangfire-jobs",