@polymorphism-tech/morph-spec 7.9.3 → 8.0.0

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.9.3",
+  "version": "8.0.0",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -44,6 +44,7 @@ Phases in brackets are optional.
 |---------|-------------|
 | `/morph-proposal {feature}` | Full spec pipeline — phases 0–4 with approval gates |
 | `/morph-apply {feature}` | Implement approved feature — phase 5 |
+| `/morph-hotfix {feature}` | Surgical hotfix ADW — scout → fix → human Gate 3 → ship |
 | `/morph-status` | Project-wide feature status dashboard |
 | `/morph-preflight` | Pre-implementation validation (7 checks) |
 
@@ -81,6 +82,42 @@ morph-spec validate architecture
 morph-spec validate packages
 morph-spec validate contrast [--wcag-aaa]
 morph-spec validate-feature {feature} [--phase {phase}] [--json]
+morph-spec verify {feature} [task] [--json]    # deterministic build+tests+validators chain, before the LLM judge
+```
+
+---
+
+## CLI — work-type routing
+
+Every feature is born with a **work type** that dimensions its pipeline: `feature` (full proposal → [uiux] → plan → implement → review), `bug` (lean), `chore` (fast-track straight to implement), `hotfix` (scout → surgical fix → human Gate 3 always, even under `trust: auto`).
+
+```bash
+morph-spec create {feature} --type feature|bug|chore|hotfix
+morph-spec create {feature} --request "<free text>"     # deterministic detector classifies the type
+morph-spec retype {feature} {newType}                    # change type mid-flight (blocked after Gate 3)
+```
+
+---
+
+## CLI — worktrees (parallel development)
+
+One feature = one git worktree = one Claude Code instance. Independent features run side by side without stepping on each other's state; a SessionStart hook injects each worktree's feature identity into context.
+
+```bash
+morph-spec create {feature} --worktree     # birth the feature already isolated in its own worktree
+morph-spec worktree setup {feature}        # create .worktrees/{feature}/ on branch morph/{feature}
+morph-spec worktree link [--all]           # relink shared infra (node_modules, .claude, .morph/framework)
+morph-spec worktree finish {feature}       # merge --no-ff back to the primary root, clean up (requires Gate 3)
+morph-spec worktree list [--json]          # active feature worktrees with phase/gate status
+```
+
+---
+
+## CLI — DAG
+
+```bash
+morph-spec dag {feature} [--json]          # sequential vs parallel dispatch decision (effort-weighted)
+morph-spec dag {feature} --mermaid         # emit the tasks.json DAG as a Mermaid flowchart
 ```
 
 ---
@@ -200,4 +237,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.9.3 by Polymorphism Tech*
+*morph-spec v8.0.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -132,6 +132,65 @@ morph-spec validate architecture       # specific validator
 morph-spec validate packages
 ```
 
+Run the deterministic verification chain (build + tests + validators) before trusting an LLM judge score:
+
+```bash
+morph-spec verify my-feature           # whole feature
+morph-spec verify my-feature T001      # scoped to one task
+```
+
+---
+
+## Work-type routing
+
+Not every change needs the full pipeline walked above. Every feature is born with a **work type** that dimensions its pipeline:
+
+```bash
+morph-spec create my-feature --type feature   # default: full proposal → [uiux] → plan → implement → review
+morph-spec create my-fix --type bug           # lean proposal/plan
+morph-spec create my-chore --type chore       # skips straight to implement (Gates 1/2 stamped by policy)
+morph-spec create my-hotfix --type hotfix     # scout → surgical fix → test loop; Gate 3 always pauses for a human
+```
+
+You can also let the deterministic detector classify a free-text request instead of picking a type by hand:
+
+```bash
+morph-spec create my-feature --request "produção caiu, corrigir urgente"
+```
+
+Change the type later if it turns out to be wrong (blocked after Gate 3):
+
+```bash
+morph-spec retype my-feature hotfix --reason "escalated to production incident"
+```
+
+Production incidents run through the dedicated `/morph-hotfix my-feature` slash command instead of `/morph-proposal`.
+
+---
+
+## Parallel development with worktrees
+
+Independent features can be developed in parallel, each isolated in its own git worktree — one feature, one worktree, one Claude Code instance:
+
+```bash
+morph-spec create my-feature --worktree      # birth the feature already isolated
+# or, for an existing feature:
+morph-spec worktree setup my-feature         # creates .worktrees/my-feature/ on branch morph/my-feature
+```
+
+Open the new worktree directory in its own Claude Code instance and work normally — a SessionStart hook injects the worktree's feature identity into context automatically. When the feature is done:
+
+```bash
+morph-spec worktree finish my-feature        # merges --no-ff back into the primary root, then cleans up
+morph-spec archive my-feature                # run at the primary root afterward
+```
+
+List every active worktree with its phase and gate status:
+
+```bash
+morph-spec worktree list
+```
+
 ---
 
 ## Multiple features
@@ -197,4 +256,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.9.3 by Polymorphism Tech*
+*morph-spec v8.0.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -31,7 +31,8 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 
 | Comando | Propósito |
 |---------|-----------|
-| `/morph-proposal {feature}` | Entendimento de negócio + plano (Gates 1 e 2) |
+| `/morph-proposal {feature}` | Entendimento de negócio + plano (Gates 1 e 2). Passo 0 roteia por tipo de trabalho (`feature`/`bug`/`chore`/`hotfix`) |
+| `/morph-hotfix {feature}` | ADW cirúrgico de hotfix (scout → fix → gate humano → ship) |
 | `/morph-apply {feature}` | Execução autônoma + review (Gate 3) |
 | `/morph-status [feature]` | Status da feature ativa (ou a especificada) |
 | `/morph-archive {feature}` | Arquiva feature concluída (após Gate 3) — wrapper de `morph-spec archive` (atômico, git-aware) |
@@ -45,7 +46,10 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - `morph-spec dag <feature>` — análise do DAG de tasks.json com decisão sequencial vs paralelo **ponderada por effort** (raízes S vão inline, nunca ganham agente próprio).
 - `morph-spec score <feature> <task> <score> [--dims a,c,q,t]` — grava `taskScores` no feature.json com timestamp server-side; **nunca edite taskScores à mão**.
 - `morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]` — grava `gateDecisions` no feature.json com timestamp server-side (shape em `framework/schemas/feature.schema.json`); **nunca edite gateDecisions à mão** — o Edit manual colide com o hook state-sync.
-- `morph-spec create <feature>` — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback).
+- `morph-spec create <feature> --type <feature|bug|chore|hotfix> [--request "<txt>"] [--worktree]` — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback). `--type` classifica direto; `--request "<pedido>"` roda o detector determinístico (empate/sem sinal sai com exit 2 e candidatos — a LLM decide e re-roda com `--type`); `--worktree` já nasce a feature no seu worktree próprio.
+- `morph-spec retype <feature> <newType>` — muda o tipo de trabalho mid-flight; desfaz só os gates carimbados por política, preserva aprovações humanas; bloqueado após o Gate 3.
+- `morph-spec verify <feature> [task] [--json]` — cadeia determinística build+testes+validadores (código antes do juiz LLM); escopo de task quando informado, senão a feature inteira.
+- `morph-spec worktree setup|link|finish|list` — gerencia o ciclo do worktree por feature (`setup` cria `.worktrees/{f}/` na branch `morph/{f}`; `link` religa infra compartilhada; `finish` faz merge `--no-ff` e limpa; `list` mostra fase/gate de cada worktree ativo).
 
 ## Skills core (em `.claude/skills/`)
 
@@ -57,8 +61,15 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 | `morph-implement` | Executar uma tarefa com auto-advance entre tasks |
 | `morph-eval` | Aplicar rubricas e produzir score 0-10 |
 | `morph-review` | Produzir review-report.md (Gate 3) |
+| `morph-hotfix` | ADW cirúrgico de hotfix — scout → fix → gate humano → ship |
 | `morph-standards` | Localizar standard sob demanda |
 
+## Roteamento por tipo de trabalho
+
+Toda feature nasce com um `workType` (`morph-spec create <f> --type <tipo>` ou classificado de `--request "<pedido>"`) que dimensiona o pipeline: `feature` roda o fluxo completo (proposal → [uiux] → plan → implement → review); `bug` roda uma versão enxuta (proposal/plan lean); `chore` pula direto para implement (Gates 1/2 carimbados por política no nascimento); `hotfix` roda scout → fix cirúrgico → test loop → ship. O Gate 3 do `hotfix` **pausa sempre para um humano**, mesmo em `trust: auto` — o CLI recusa `morph-spec approve <f> review --mode auto` nesse tipo. Detalhes em `.morph/framework/MORPH.md` §2.1 e §5.
+
+Features independentes podem rodar em paralelo, cada uma isolada num git worktree (`morph-spec create <f> --worktree` ou `morph-spec worktree setup <f>`) — uma feature por worktree, uma instância de Claude Code por worktree. `feature.json` viaja commitado na branch `morph/{f}`; ao fechar, aprove o Gate 3 dentro do worktree e rode `morph-spec worktree finish <f>` seguido de `morph-spec archive <f>` na raiz. Detalhes em `.morph/framework/MORPH.md` §2.2.
+
 ## Personas (em `.claude/agents/`)
 
 Despache tasks de domínio com `subagent_type: "morph-{id}"` — a persona é o **system prompt** do subagent registrado (gerado de `agents.json`, a fonte única). Se o tipo não estiver na sua lista de subagents (stack não instalado neste projeto), use o fallback documentado em `morph-apply` §3b: `general-purpose` + campo `persona` de `agents.json` colado no prompt, **registrando o fallback nas `notes` da task**.

package/framework/MORPH.md

@@ -21,12 +21,15 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
 | Sub-agent retornou relatório (qualquer auto-score)                    | Auto-score é triagem, não aprovação: a task só avança com morph-eval ≥ 9      |
 | Sub-agent com auto-score < 7                                          | Re-despachar com feedback específico (ou corrigir inline) antes do morph-eval |
 | Build/typecheck quebra                                                | Corrigir antes de marcar tarefa como done                                     |
+| Task implementada (código escrito) na fase implement                  | Rodar `morph-spec verify <feature> <task>` (build+testes+validadores determinísticos) ANTES do juiz: verify vermelho = feedback direto ao loop de correção, sem gastar o morph-eval; verify verde → morph-eval avalia o que o código não pega (arquitetura, contratos, qualidade) |
 | Score morph-eval ≥ 9                                                  | Silêncio (aprovação implícita), próxima tarefa                                |
 | Score morph-eval < 9 numa task                                        | Loop de correção autônomo: re-implementar com o feedback priorizado, até 3 tentativas, sem pausa humana |
 | Score morph-eval < 9 após 3 tentativas                                | Escalar ao usuário (aceitar / continuar tentando / pular) — único ponto de pausa do loop de implement |
 
 **Regra de ouro:** Dúvida que não bloqueia o progresso → resolver e registrar. Dúvida que bloqueia → uma pergunta, máximo.
 
+**Código antes do juiz:** o `morph-spec verify` é a barreira determinística e barata — build, testes e validadores estáticos rodam primeiro, sempre igual, sem custo de tokens. O juiz LLM (morph-eval) só é acionado quando o verify passa. Código é o herói não-celebrado do loop: ele pega o que pega de graça; o juiz gasta tokens só no que o código não consegue ver.
+
 ---
 
 ## Stack baked-in
@@ -92,6 +95,32 @@ A fase `1-design/` (design system, mockups, flows) é opcional — aplica-se ape
 
 Não avance de fase sem o gate correspondente ter sido confirmado.
 
+### 2.1 Roteamento por tipo de trabalho
+
+Nem todo trabalho merece o pipeline completo. Cada feature nasce com um **workType** (`morph-spec create <f> --type <tipo>` ou classificado de `--request "<pedido>"`), e o tipo dimensiona o pipeline:
+
+| Tipo | Pipeline | Gates |
+|------|----------|-------|
+| `feature` | proposal → [uiux] → plan → implement → review (completo) | 1, 2, 3 |
+| `bug` | repro+diagnóstico enxuto (proposal lean) → plan enxuto → implement → review | 1, 2, 3 |
+| `chore` | fast-track: direto para implement (Gates 1/2 carimbados por política no nascimento) → review leve | só 3 |
+| `hotfix` | scout (diagnóstico read-only) → fix cirúrgico → **aprovação humana obrigatória** → test loop → ship | 3 (humano sempre) |
+
+**Como classificar (router):** sinais determinísticos primeiro — o `morph-spec create --request "<texto>"` roda o detector por keywords (hotfix: "produção caiu/urgente/incident/p0"; bug: "bug/corrigir/exception/regressão"; chore: "typo/rename/bump/config/docs/cleanup"). As keywords casam como **palavra inteira**, nunca como pedaço de outra palavra ("group0" não é `p0`, "prefix" não é `fix`, "debug" não é `bug`) — casar demais faria um pedido inócuo pular gates sem humano nem router. Por isso plural e flexão são listados explicitamente ("bugs", "erros", "incidentes", "configs"): o recall mora no vocabulário, não num matcher que dispara em fragmento. Confiança `high` → usa o tipo. Empate (`tie`) ou nenhum sinal (`none`) → o comando sai com código 2 e os candidatos; **você decide como roteador** e re-roda com `--type`. Só há ambiguidade real que valha uma `AskUserQuestion` quando o pedido do usuário é genuinamente indeterminado.
+
+**Como o skip funciona (sem variantes de pipeline):** `chore`/`hotfix` têm os gates `proposal` e `plan` carimbados no nascimento com `approvedBy: "policy:{tipo}"`. Como a fase derivada avança com gate aprovado (`derivePhase` é gate-aware), o trabalho já nasce em `implement` — sem tocar `phases.json`. Os artefatos de fase reutilizam os nomes canônicos (o hotfix escreve um brief curto no `proposal.md`; ambos escrevem um `2-plan/tasks.json` mínimo de 1-3 tasks para ligar trace/score/dag).
+
+**Compat:** uma feature sem `workType` (criada antes do v8) é tratada como `feature`. Mudança de tipo mid-flight: `morph-spec retype <f> <tipo>` (desfaz só carimbos de política, preserva aprovações humanas; bloqueado após o Gate 3).
+
+### 2.2 Desenvolvimento paralelo por worktree
+
+Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu git worktree**, com uma instância de Claude Code por worktree. `morph-spec create <f> --worktree` (ou `morph-spec worktree setup <f>`) cria `.worktrees/{f}/` na branch `morph/{f}`. Contrato:
+
+- **Uma feature = um worktree = uma instância.** Nunca abra duas instâncias na mesma feature (o setup recusa com exit 3).
+- O estado autoritativo (`feature.json`) viaja **commitado na branch** `morph/{f}`. O `state.json` local do worktree é um índice derivável — materializado por self-heal, nunca sincronizado à mão.
+- Infra compartilhada (`node_modules`, `.claude`, `.morph/framework`) é linkada por junction; `memory/` e `logs/` são locais de cada worktree (isolamento correto). Se faltar infra num worktree (aberto com `git worktree add` puro), rode `morph-spec worktree link --all`.
+- **Fechamento:** aprove o Gate 3 dentro do worktree, depois `morph-spec worktree finish <f>` (merge `--no-ff` da branch na raiz primária limpa; recusa se worktree ou raiz estiverem sujos; aborta em conflito) e por fim `morph-spec archive <f>` na raiz. `morph-spec worktree list` mostra os worktrees ativos com fase e gate.
+
 ---
 
 ## 3. Contratos de Output
@@ -172,6 +201,7 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **
 | `standardsViolations` | array.length > 0 | Mandate ou implementation viola padrões proibidos |
 | `evalScore` | < 9 | morph-review produz score composto da feature abaixo do mínimo (o loop de correção intra-task já buscou 9 por task antes daqui) |
 | `taskCount` | > 20 | Escopo grande — provavelmente vale revisar antes de implementar |
+| `workType` | === 'hotfix' | Gate 3 pausa SEMPRE para aprovação humana, mesmo em `trust: auto` — o CLI recusa `morph-spec approve <f> review --mode auto` num hotfix |
 
 **Gate 1 — Proposta**
 - Sinais: `designSystemDivergence`, `standardsViolations` (improvável).
@@ -185,6 +215,8 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **
 - Sinais: `evalScore` composite, `standardsViolations` detectadas em implementation.
 - Skill responsável: `morph-review`.
 
+**Gates por tipo de trabalho:** `chore` e `hotfix` não passam pelos Gates 1 e 2 — eles são carimbados por política no nascimento (`approvedBy: "policy:{tipo}"`, nunca `"auto"`, para não colidir com o gate-guard). A barra de qualidade do morph-eval e o Gate 3 continuam valendo para todos os tipos. Para `hotfix`, o Gate 3 é **sempre humano**: mesmo em `trust: auto` a `morph-hotfix` apresenta o review via `AskUserQuestion` e o `risk-detector` força a pausa; o backstop server-side (`morph-spec approve ... review --mode auto` recusa) garante que nenhum caminho auto passe por cima.
+
 Para alterar o modo: editar `.morph/config/config.json → trust` (`"auto"` ou `"manual"`). Configs sem o campo `trust` defaultam para `"auto"`.
 
 **Comportamento padrão fora de gate:** trabalhe com autonomia total. Gates só existem nestes três pontos. Não pause para confirmação no meio de implementação a menos que encontre uma ambiguidade de escopo que o mandate não cobre — nesse caso, registre a ambiguidade no decisions.md, resolva da forma mais conservadora possível, e sinalize na entrega da task.
@@ -218,6 +250,8 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 
 **Mecanismo de dispatch:** os agents de domínio são subagents **registrados** (`.claude/agents/morph-{id}.md`, gerados de `agents.json` — a fonte única — na instalação). Despache com `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`): a persona é o **system prompt** do subagent, com tools, model e MCPs definidos por domínio no próprio `agents.json` (ex.: `context7` para docs vivas nos implementadores; Stitch/Gemini/Playwright no `morph-ui-designer`; o `morph-evaluator` é read-only). **Fallback** quando o tipo não está registrado (stack não instalado neste projeto): `general-purpose` com o campo `persona` de `agents.json` colado no prompt, **registrado nas `notes` da task**. O `**Persona:**` do recap registra sempre o mecanismo real usado — nunca uma auto-declaração.
 
+**Persona de estágio — scout:** além das personas de domínio, existe o `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Despache-o quando precisar de um mapa do território sem contaminar a thread principal — obrigatoriamente no início de um hotfix (localizar root cause + blast radius) e opcionalmente antes do plan de uma feature grande (buscar código, docs e specs anteriores relevantes). Ele devolve um mapa curto via SendMessage e encerra; não escreve código.
+
 **O que passar ao sub-agent:**
 - Especificação da tarefa (do tasks.json)
 - Path do standard relevante (apenas um)
@@ -238,7 +272,7 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 **Protocolo obrigatório do sub-agent** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
 1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` como a ÚLTIMA tool call do turno, e encerrar IMEDIATAMENTE depois** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Zero texto adicional, zero nova tool call, zero "aguardando confirmação" depois do SendMessage: é o encerramento, não um passo intermediário. Terminar idle sem SendMessage, ou continuar agindo depois dele, é **falha de protocolo**: o hook `subagent-report-guard` bloqueia o encerramento uma vez com a instrução, e a cobrança do orquestrador via SendMessage é apenas o fallback (registrada como falha no recap). Os templates trazem o exemplo literal da chamada.
 2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo orquestrador.
-3. Em batch paralelo, não rodar build/test da suíte compartilhada — a verificação é do orquestrador, uma vez, pós-batch (alternativa: dispatch com `isolation: "worktree"`, e aí o build roda dentro do worktree).
+3. **Verificação em batch paralelo — condicional ao isolamento:** em batch **sem isolamento** (agentes na mesma working tree), 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"`** (quando o `morph-spec dag` recomenda, por colisão de `outputs` entre fluxos), a regra se inverte: rode build/test **dentro do seu worktree**, commite o trabalho na branch do worktree como penúltimo ato (antes do SendMessage), reporte a branch + status de build, e **nunca** faça merge nem toque na árvore principal — a integração é do orquestrador.
 
 O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais contexto para começar, a tarefa não estava bem especificada — refine antes de despachar.
 
@@ -251,7 +285,7 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
 
 > **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
 
-**Dispatch em paralelo (multi-agent):** quando há fluxos de trabalho **genuinamente independentes** (ex: a cadeia de backend e a cadeia de frontend de uma mesma feature, que só convergem no fim), despache múltiplos sub-agents **ao mesmo tempo** — um por fluxo — em vez de processá-los em série. O orquestrador roda `morph-spec dag {feature}` — o comando analisa o DAG de `tasks.json` (por `dependencies` e por `group`), **pondera o esforço** (raízes e fluxos só de tasks S não ganham dispatch próprio: vão inline ou agrupados num único agente) e imprime a decisão pronta. As regras concretas e o cap de agentes simultâneos vivem na skill `morph-apply` (seção "Análise de DAG"). A thread principal coordena; os especialistas executam — inclusive em paralelo.
+**Dispatch em paralelo (multi-agent):** quando há fluxos de trabalho **genuinamente independentes** (ex: a cadeia de backend e a cadeia de frontend de uma mesma feature, que só convergem no fim), despache múltiplos sub-agents **ao mesmo tempo** — um por fluxo — em vez de processá-los em série. O orquestrador roda `morph-spec dag {feature}` — o comando analisa o DAG de `tasks.json` (por `dependencies` e por `group`), **pondera o esforço** (raízes e fluxos só de tasks S não ganham dispatch próprio: vão inline ou agrupados num único agente) e imprime a decisão pronta. As regras concretas e o cap de agentes simultâneos vivem na skill `morph-apply` (seção "Análise de DAG"). A thread principal coordena; os especialistas executam — inclusive em paralelo. O `morph-spec dag` também detecta colisão de arquivos entre os fluxos paralelos (via os `outputs` planejados no tasks.json) e, quando dois fluxos escreveriam no mesmo path, recomenda `isolation: "worktree"` — nesse caso cada agente trabalha num worktree próprio e o orquestrador integra por merge ao final (protocolo detalhado na `morph-apply` §3b-w). Sem colisão, o batch roda na working tree compartilhada com verificação única pós-batch.
 
 O padrão de dispatch e o template de prompt para sub-agents estão detalhados em `framework/skills/core/morph-implement/SKILL.md`.
 
@@ -272,11 +306,13 @@ Não invoque uma skill fora do momento indicado.
 | morph-implement       | `framework/skills/core/morph-implement/SKILL.md`   | Invocada pela morph-apply — executa cada task                           |
 | morph-eval            | `framework/skills/core/morph-eval/SKILL.md`        | Após concluir uma task ou fase                                          |
 | morph-review          | `framework/skills/core/morph-review/SKILL.md`      | Invocada pela morph-apply — produz review-report + Gate 3               |
+| morph-hotfix          | `framework/skills/core/morph-hotfix/SKILL.md`      | **Orquestrador**: ADW cirúrgico de hotfix (scout → fix → gate humano → ship) |
 | morph-standards       | `framework/skills/core/morph-standards/SKILL.md`   | Quando precisar localizar ou aplicar um standard específico             |
 
 **Entry points** para o usuário:
 - `/morph-proposal {feature}` → invoca `Skill(morph-proposal)`, que orquestra brainstorming + plan
 - `/morph-apply {feature}` → invoca `Skill(morph-apply)`, que orquestra implement + review
+- `/morph-hotfix {feature}` → invoca `Skill(morph-hotfix)`, o pipeline cirúrgico de correção em produção
 
 Os slash commands são atalhos: o agente pode chamar `Skill(morph-proposal)` diretamente quando o usuário pede "use /morph-proposal".
 

package/framework/agents.json

@@ -1,8 +1,8 @@
 {
-  "version": "5.1.0",
+  "version": "5.2.0",
   "schema": "domain-personas",
-  "total_agents": 7,
-  "description": "Domain personas dispatched per task via subagent_type morph-{id} (.claude/agents/ generated from this file — single source of truth, ADR-001). Optional per-agent fields: `tools` (comma-separated tool scope; default Read, Write, Edit, Bash, Glob, Grep), `model` (default inherit), `mcp` (registry ids from framework/mcp/registry.json, granted as mcp__{id}). The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md.",
+  "total_agents": 8,
+  "description": "Domain personas dispatched per task via subagent_type morph-{id} (.claude/agents/ generated from this file — single source of truth, ADR-001). Two independent axes: domain (dotnet-senior, ef-modeler, maf-expert, nextjs-expert, ui-designer, infra-engineer, evaluator) and stage (scout — read-only diagnosis before implementation). Optional per-agent fields: `tools` (comma-separated tool scope; default Read, Write, Edit, Bash, Glob, Grep), `model` (dimensioned per stage/criticality — evaluator: opus, domain implementers: sonnet, scout: haiku; no longer uniformly inherit), `mcp` (registry ids from framework/mcp/registry.json, granted as mcp__{id}). The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md.",
   "agents": {
     "dotnet-senior": {
       "title": ".NET Senior Engineer",
@@ -23,6 +23,7 @@
         "backend-integrations-neon-auth-neon-auth"
       ],
       "mcp": ["context7"],
+      "model": "sonnet",
       "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados: ApplicationDbContext injetado 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; nunca uma camada de Service/Manager; nunca repository genérico (IRepository<T>/IUnitOfWork). Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
     },
     "ef-modeler": {
@@ -41,6 +42,7 @@
         "infrastructure-neon-pgvector"
       ],
       "mcp": ["context7"],
+      "model": "sonnet",
       "persona": "Você é um especialista em EF Core sobre Neon (Postgres). Pensa em migrations explícitas, configurações fluentes, navigation properties bem nomeadas, índices intencionais. Sempre Guid.CreateVersion7() para PKs. Sealed entities. Nunca leak de DbContext fora do handler."
     },
     "maf-expert": {
@@ -65,6 +67,7 @@
         "ai-agents-multi-agent-patterns"
       ],
       "mcp": ["context7"],
+      "model": "sonnet",
       "persona": "Você é especialista no Microsoft Agent Framework (MAF 1.0 GA). Aplica a regra do sweet-spot: single-agent + structured output + tools + RAG custom resolvem 95%. Refere alias do Model Registry, nunca model hardcoded. Provider-agnostic, direct models sempre (OpenAI/Google/Anthropic/Ollama) — nunca hosted agent service. Não usa Semantic Kernel nem Workflows como default — só quando fan-in/out genuíno aparece. Telemetria via AgentOpenTelemetryConsts.DefaultSourceName."
     },
     "nextjs-expert": {
@@ -86,6 +89,7 @@
         "backend-integrations-neon-auth-neon-auth"
       ],
       "mcp": ["context7"],
+      "model": "sonnet",
       "persona": "Você escreve Next.js App Router idiomático. Server Components por padrão, Client Components apenas quando há interatividade real. Tailwind + Shadcn + Framer Motion. Tipos via Zod. Nada de getServerSideProps. RSC streaming quando faz sentido."
     },
     "ui-designer": {
@@ -105,6 +109,7 @@
       ],
       "tools": "Read, Write, Edit, Glob, Grep",
       "mcp": ["context7", "stitch", "gemini-image", "playwright"],
+      "model": "sonnet",
       "persona": "Você desenha sistemas, não telas isoladas. Pensa em tokens (cor, espaço, tipografia), componentes reutilizáveis, estados (default/hover/focus/disabled/loading/error), acessibilidade WCAG AA. Mockups em Tailwind direto, sem Figma intermediário."
     },
     "infra-engineer": {
@@ -123,6 +128,7 @@
         "backend-dotnet-scrutor"
       ],
       "mcp": ["context7"],
+      "model": "sonnet",
       "persona": "Você cuida de infra: jobs assíncronos com Hangfire (apenas quando há razão real), deployment, observabilidade. Pensa em retry, idempotência, dead-letter, métricas. Não inventa infra — usa o que o stack já oferece. Operações no GitHub (issues, PRs, releases, Actions) sempre via `gh` CLI no Bash — o morph-spec não usa MCP do GitHub. Coolify sempre via SSH + curl na API local — não há MCP nem CLI."
     },
     "evaluator": {
@@ -136,7 +142,20 @@
       "stack": ["*"],
       "standards": [],
       "tools": "Read, Glob, Grep",
+      "model": "opus",
       "persona": "Você aplica as rubricas em .morph/framework/evals/rubrics/. Você não participou da implementação — avalia apenas o mandate, o diff e a saída real dos testes que o orquestrador fornece, com contexto fresco. Não reescreve código — produz scores 0-10 por dimensão (architecture, contracts, code-quality, test-coverage), feedback priorizado acionável, e ação clara (aprovado em >=9 / feedback para o loop de correção em <9). Silêncio em scores ≥ 9 é o sinal correto."
+    },
+    "scout": {
+      "title": "Codebase Scout",
+      "icon": "🔦",
+      "color": "gray",
+      "domains": ["scouting", "diagnosis", "code-search"],
+      "keywords": ["scout", "diagnose", "root cause", "blast radius", "search", "map", "investigate", "locate", "trace"],
+      "stack": ["*"],
+      "standards": [],
+      "tools": "Read, Glob, Grep, Bash",
+      "model": "haiku",
+      "persona": "Você é um scout read-only: mapeia o território sem escrever código. Dado um sintoma ou uma feature, localiza os arquivos relevantes, o root cause provável e o blast radius (o que mais é afetado). Usa Read/Glob/Grep e Bash SOMENTE-LEITURA (git log/diff/show, ls, cat) — nunca Write/Edit, nunca comandos que mudam estado. Devolve um mapa curto e acionável (arquivos com paths, hipótese de causa, áreas de impacto) via SendMessage e encerra. Não implementa, não corrige — ilumina o caminho para quem vai."
     }
   }
 }