@polymorphism-tech/morph-spec 7.3.0 → 7.5.0

package/CLAUDE.md

@@ -52,7 +52,7 @@ No build step — pure ESM JavaScript, runs directly via Node.js 18+.
   - `agents.json` (v5.0.0) — 7 domain personas, no tiers
   - `phases.json` — 5 phases (proposal, uiux, plan, implement, review)
   - `standards/STANDARDS.json` — index of available standards
-  - `hooks/claude-code/core/` — 6 fail-open guardrail hooks
+  - `hooks/claude-code/core/` — 7 fail-open guardrail hooks
   - `skills/core/` — 7 core NLH skills (single source of truth)
   - `templates/` — Handlebars templates for code generation
   - `mcp/registry.json` — MCP server registry

package/README.md

@@ -3,7 +3,7 @@
 > Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
 
 **Package:** `@polymorphism-tech/morph-spec`
-**Version:** 7.3.0  
+**Version:** 7.5.0  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v7.3.0 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v7.5.0 by [Polymorphism Tech](https://polymorphism.tech)*

package/bin/morph-spec.js

@@ -26,6 +26,8 @@ import { worktreeSetupCommand } from '../src/commands/project/worktree.js';
 
 // === Approval gates (human-only) ===
 import { approveCommand, approvalStatusCommand, unapproveCommand } from '../src/commands/state/approve.js';
+import { advanceCommand } from '../src/commands/state/advance.js';
+import { archiveCommand } from '../src/commands/state/archive.js';
 
 // === Validation ===
 import { validateCommand } from './validate.js';
@@ -112,10 +114,27 @@ program
 program
   .command('approve <feature> <gate>')
   .description('Approve a phase gate (proposal, plan, review)')
-  .option('--approver <name>', 'Name of approver (default: current user)')
+  .option('--approver <name>', 'Name of approver (default: current user when interactive, "auto" otherwise)')
+  .option('--mode <mode>', 'Approval mode: "user" or "auto" (default: detected from TTY)')
   .option('--notes <notes>', 'Approval notes')
   .action((feature, gate, options) => approveCommand(feature, gate, options));
 
+program
+  .command('advance <feature>')
+  .description('Approve the current phase gate and scaffold the next phase folder (one step)')
+  .option('--approver <name>', 'Name of approver (default: current user when interactive, "auto" otherwise)')
+  .option('--mode <mode>', 'Approval mode: "user" or "auto" (default: detected from TTY)')
+  .option('--design', 'From proposal, advance into the optional design (uiux) phase instead of plan')
+  .option('--notes <notes>', 'Approval notes')
+  .action((feature, options) => advanceCommand(feature, options));
+
+program
+  .command('archive <feature>')
+  .description('Archive a completed feature (atomic, git-aware): move folder + update state')
+  .option('--no-git', 'Skip git staging of the move')
+  .option('--force', 'Archive even if Gate 3 (review) is not approved')
+  .action((feature, options) => archiveCommand(feature, options));
+
 program
   .command('approval-status <feature>')
   .description('Show approval status for all gates')
@@ -125,7 +144,8 @@ program
 program
   .command('unapprove <feature> <gate>')
   .description('Revoke a phase gate approval (recovery only)')
-  .option('--revoker <name>', 'Name of person revoking')
+  .option('--revoker <name>', 'Name of person revoking (default: current user when interactive, "auto" otherwise)')
+  .option('--mode <mode>', 'Revocation mode: "user" or "auto" (default: detected from TTY)')
   .option('--reason <reason>', 'Reason for revocation')
   .action((feature, gate, options) => unapproveCommand(feature, gate, options));
 

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.3.0",
+  "version": "7.5.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

@@ -196,4 +196,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.3.0 by Polymorphism Tech*
+*morph-spec v7.5.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.3.0 by Polymorphism Tech*
+*morph-spec v7.5.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -5,7 +5,7 @@
 ## Como começar cada sessão
 
 1. Leia `.morph/framework/MORPH.md` — o charter NLH com papéis, fases, gates e skills.
-2. Leia `.morph/state.json` — identifique a feature `in_progress` e a fase atual.
+2. Leia `.morph/state.json` — índice fino e gitignored (só status + updatedAt por feature) — para identificar a feature `in_progress` e a fase atual. **Não o edite à mão:** é reconstruído a partir dos `feature.json` a cada load. O estado autoritativo e commitado de cada feature vive em `.morph/features/{feature}/feature.json`.
 3. Assuma o papel correspondente (Orchestrator/Specialist/Evaluator) e continue o trabalho. Não aguarde instrução do usuário se há trabalho pendente entre gates.
 
 Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
@@ -15,16 +15,16 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 **NUNCA:**
 - Pular para código sem proposal aprovado (Gate 1) e plano aprovado (Gate 2).
 - Modificar o contrato do plano depois do Gate 2: `spec.md`, `mandate.md`, e os campos de plano de `tasks.json` (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) estão congelados.
-- Usar `Edit` em `tasks.json` após o Gate 2 — o arquivo é gravado inteiro via `writeTasksJson` (Write). O hook `protect-spec-files` bloqueia `Edit`.
+- Tocar os campos de contrato do plano em `tasks.json` após o Gate 2 (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) — o hook `protect-spec-files` faz diff semântico e bloqueia mudanças neles, seja via `Write` ou `Edit`. (Os campos mutáveis `status`/`outputs`/`notes` continuam graváveis por `Write` ou `Edit` — ver SEMPRE.)
 - Listar perguntas em texto simples — sempre use a tool `AskUserQuestion` (1-4 perguntas por chamada).
 - Usar `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, ou SQL cru sem justificativa.
 
 **SEMPRE:**
 - Auto-advance entre tarefas durante a fase implement — não pause sem ambiguidade bloqueante.
-- Atualizar o progresso em `tasks.json` via `writeTasksJson` ao concluir cada task — apenas os campos `status`, `outputs` e `notes` mudam; o contrato do plano permanece congelado.
+- Atualizar o progresso em `tasks.json` ao concluir cada task gravando apenas os campos mutáveis `status`, `outputs` e `notes` — via `Write` OU `Edit` (o hook `protect-spec-files` faz diff semântico e permite qualquer um dos dois desde que o contrato do plano permaneça congelado).
 - Apresentar gates com o template fixo definido em MORPH.md / morph-plan.
 - Registrar decisões não triviais em `decisions.md`.
-- Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 8 é o sinal correto.
+- Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas.
 
 ## Slash commands
 
@@ -33,10 +33,15 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 | `/morph-proposal {feature}` | Entendimento de negócio + plano (Gates 1 e 2) |
 | `/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) |
+| `/morph-archive {feature}` | Arquiva feature concluída (após Gate 3) — wrapper de `morph-spec archive` (atômico, git-aware) |
 | `/morph-preflight` | Validação pré-deploy (specs, contratos, testes, infra) |
 | `/morph-troubleshoot [erro]` | Diagnóstico de erros .NET/Next.js com root-cause analysis |
 
+**Comandos CLI de gate** (a LLM os usa em vez de editar o estado à mão para aprovar/avançar):
+- `morph-spec approve <feature> <gate> --mode auto` — aprova um gate (`proposal`/`plan`/`review`) em `trust: auto`.
+- `morph-spec advance <feature>` — aprova o gate da fase corrente **e** cria a pasta da próxima fase num passo só (`--design` toma o ramo opcional de uiux a partir da proposta).
+- `morph-spec archive <feature>` — arquiva a feature (atômico, git-aware); é o que `/morph-archive` chama.
+
 ## Skills core (em `.claude/skills/`)
 
 | Skill | Quando usar |

package/framework/MORPH.md

@@ -4,7 +4,7 @@
 > Ele define papéis, fases, outputs, standards, gates e skills do morph-spec.
 > Não procure instruções em hooks — o harness vive aqui.
 >
-> **Depois de ler:** leia `.morph/state.json` para identificar a feature ativa e a fase atual. Se o arquivo existir e houver uma feature `in_progress`, assuma o papel correspondente à fase e continue o trabalho sem esperar instrução. Se não houver feature ativa, pergunte ao usuário qual feature trabalhar ou se é uma feature nova.
+> **Depois de ler:** leia `.morph/state.json` para identificar a feature ativa e a fase atual. `state.json` é um **índice fino e gitignored** (só status + updatedAt por feature, reconstruído a partir dos `feature.json` a cada load) — use-o apenas para descobrir a feature ativa, **nunca o edite à mão** (a edição é perdida no próximo load). O estado autoritativo e commitado de cada feature vive em `.morph/features/{feature}/feature.json`. Se houver uma feature `in_progress`, assuma o papel correspondente à fase e continue o trabalho sem esperar instrução. Se não houver feature ativa, pergunte ao usuário qual feature trabalhar ou se é uma feature nova.
 
 ---
 
@@ -21,9 +21,9 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
 | Sub-agent com auto-score ≥ 7                                          | Integrar ao recap.md e continuar                                              |
 | Sub-agent com auto-score < 7                                          | Aplicar morph-eval antes de aceitar                                           |
 | Build/typecheck quebra                                                | Corrigir antes de marcar tarefa como done                                     |
-| Score morph-eval ≥ 8                                                  | Silêncio (aprovação implícita), próxima tarefa                                |
-| Score morph-eval entre 6 e 7.9                                        | Feedback priorizado, continuar                                                |
-| Score morph-eval < 6                                                  | Escalar ao usuário via review-report                                          |
+| 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.
 
@@ -68,7 +68,7 @@ Responsabilidades: executar tarefas do tasks.json em ordem, consultar standards
 Anti-padrão: o Specialist não cria novas tarefas. Descobertas de escopo durante a implementação vão para o decisions.md com flag "escopo expandido" — o Orchestrator avalia se o tasks.json precisa ser atualizado.
 
 **Evaluator** — ativo após uma tarefa ou fase ser concluída.
-Responsabilidades: aplicar as rubricas em `framework/evals/rubrics/`, produzir score 0-10, emitir feedback priorizado quando score < 8, escalar para revisão humana quando score < 6.
+Responsabilidades: aplicar as rubricas em `framework/evals/rubrics/`, produzir score 0-10, emitir feedback priorizado quando score < 9 (que alimenta o loop de correção autônomo do morph-apply), escalar para revisão humana apenas quando o loop de correção se esgotar (3 tentativas sem atingir 9).
 Anti-padrão: o Evaluator não reescreve o código que avaliou. Se o score está abaixo de 6, o relatório vai para o humano — não para uma segunda rodada de tentativa automática.
 
 Os papéis não são exclusivos — numa sessão longa você transita entre Orchestrator e Specialist conforme as tarefas avançam. A transição deve ser explícita: antes de mudar de papel, conclua o que estava fazendo ou registre o estado corrente no recap.md.
@@ -77,7 +77,7 @@ Os papéis não são exclusivos — numa sessão longa você transita entre Orch
 
 ## 2. Fases
 
-O fluxo padrão de uma feature tem quatro fases. Cada fase tem uma pasta dedicada em `.morph/features/{feature}/`.
+O fluxo padrão de uma feature tem quatro fases. Cada fase tem uma pasta dedicada em `.morph/features/{feature}/`. O estado autoritativo e commitado da feature mora em `.morph/features/{feature}/feature.json` (status, approvalGates, outputs, tasks, gateDecisions, taskScores, archivedAt); a raiz `.morph/state.json` é só um índice fino e gitignored derivado dele, e a identidade do projeto fica no `.morph/config/config.json` (commitado).
 
 | Fase        | Pasta          | Gate                  | O que termina a fase                            |
 |-------------|----------------|-----------------------|-------------------------------------------------|
@@ -167,7 +167,7 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **
 |-------|-----------|---------------|
 | `designSystemDivergence` | true | Brainstorming detecta fontes conflitantes (spec antigo vs bundle local) |
 | `standardsViolations` | array.length > 0 | Mandate ou implementation viola padrões proibidos |
-| `evalScore` | < 8 | morph-eval/morph-review produz score abaixo do mínimo |
+| `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 |
 
 **Gate 1 — Proposta**
@@ -186,19 +186,32 @@ Para alterar o modo: editar `.morph/config/config.json → trust` (`"auto"` ou `
 
 **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.
 
-**O hook state-sync.js** detecta as respostas dos Gates automaticamente: quando uma `AskUserQuestion` é respondida com label começando em "aprovado", marca o gate correspondente em `.morph/state.json`. Em modo auto sem AskUserQuestion, a skill atualiza state.json diretamente (allowlist permite Edit em `.morph/state.json`).
+**A aprovação de gate é unificada nos comandos da CLI — a LLM nunca edita o estado à mão para aprovar um gate.** Em `trust: "auto"` (sem `AskUserQuestion`), a skill aprova o gate via `morph-spec approve <feature> <gate> --mode auto`; para aprovar o gate da fase corrente **e** já criar a pasta da próxima fase num passo só, use `morph-spec advance <feature>` (adicione `--design` para tomar o ramo opcional de uiux a partir da proposta) — isso substitui o Edit manual de state.json + `mkdir` da pasta de fase. **O hook state-sync.js** cobre o caminho manual: quando uma `AskUserQuestion` é respondida com label começando em "aprovado", ele registra o gate correspondente no `feature.json` autoritativo da feature com `approvedBy: "manual"` (um humano aprovou no loop), na forma canônica. Nos dois caminhos o gate acaba gravado em `.morph/features/{feature}/feature.json` — nunca via Edit à mão de `state.json`.
+
+**Registre quem aprovou cada gate (`approvedBy`):** o gate é um objeto `{ approved, timestamp, approvedBy }`.
+- `approvedBy: "auto"` — gate avançado por política `trust: auto` sem decisão humana.
+- `approvedBy: "manual"` — um humano aprovou explicitamente (via `AskUserQuestion`, ou, quando `AskUserQuestion` está indisponível em contexto headless, via mensagem em texto do usuário começando em "aprovado"). Em `trust: manual`, todo gate é `"manual"` — nunca grave `"auto"` num gate que um humano aprovou em conversa.
+
+Isso mantém o audit trail honesto justamente nos contextos headless (CI, `claude -p`) onde ele mais importa.
+
+**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar via `AskUserQuestion` vs auto-aprovar) bateu com a decisão de trust que a skill computou via `shouldPauseGate`. Para isso, a skill **persiste** a decisão no `feature.json` autoritativo da feature antes de agir: `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` (escrito com a tool `Edit` — a allowlist permite `Edit(.morph/features/**)`). Se a ação observada divergir do registro (pausou um gate auto-aprovável, ou auto-aprovou um gate que exigia pausa), o guard injeta um aviso no contexto — a LLM corrige. É um guardrail silencioso, nunca um orquestrador: coerente, sem registro, ou erro → silêncio.
 
 ---
 
 ## 6. Sub-agents
 
-Despache um sub-agent quando a tarefa atende a pelo menos um dos critérios abaixo:
+A thread principal é o **Orchestrator**. Trabalho de implementação pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — não absorvido inline na thread principal. Delegar não é uma permissão excepcional; é o modo padrão de operação para o caso pesado/multi-domínio. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas — é exatamente o anti-padrão que esta seção existe para evitar.
+
+**Despache um sub-agent por padrão quando a tarefa atende a pelo menos um destes gatilhos:**
 
-- Duração estimada > 5 minutos
-- Mais de 3 tentativas de correção falharam no mesmo problema
-- Análise de arquivo com mais de 500 linhas
-- Tarefa repetitiva com mais de 3 instâncias do mesmo padrão
-- Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes para o fluxo
+- **Domínio diferente do contexto corrente** — a task pertence a um domínio (ver `agents.json → domains`) distinto do que você está trabalhando agora (ex: você está no backend e a próxima task é frontend/UI/dados). Cruzar de domínio é o gatilho mais importante: cada domínio tem sua persona e seus standards, e o sub-agent escopado os carrega sem inchar seu contexto.
+- **Esforço L ou XL** (duração estimada > 5 minutos).
+- Mais de 3 tentativas de correção falharam no mesmo problema.
+- Análise de arquivo com mais de 500 linhas.
+- Tarefa repetitiva com mais de 3 instâncias do mesmo padrão.
+- Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes para o fluxo.
+
+Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do domínio que você já tem carregado em contexto**. Se optar por inline numa task que dispara um gatilho acima, **registre a justificativa em uma linha no decisions.md** ("inline porque o contexto X já está carregado e o overhead de dispatch não compensa") — uma escolha de inline silenciosa numa task pesada/multi-domínio é o anti-padrão.
 
 **O que passar ao sub-agent:**
 - Especificação da tarefa (do tasks.json)
@@ -226,6 +239,10 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
 
 **Após receber o retorno do sub-agent:** leia o auto-score. Se for < 7, aplique a skill morph-eval no resultado antes de aceitar. Se for >= 7 e sem itens bloqueantes, integre o resultado ao recap.md e siga para a próxima tarefa.
 
+> **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 analisa o DAG de `tasks.json`, identifica os fluxos independentes (por `dependencies` e por `group`), e dispara o batch paralelo. As regras concretas de decisão sequencial vs. paralelo 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 padrão de dispatch e o template de prompt para sub-agents estão detalhados em `framework/skills/core/morph-implement/SKILL.md`.
 
 ---

package/framework/agents.json

@@ -1,132 +1,132 @@
-{
-  "version": "5.0.0",
-  "schema": "domain-personas",
-  "total_agents": 7,
-  "description": "Domain personas dispatched per task by the morph-implement skill. The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md — these are domain personas the Specialist consults when working in a specific area.",
-  "agents": {
-    "dotnet-senior": {
-      "title": ".NET Senior Engineer",
-      "icon": "🔷",
-      "color": "blue",
-      "domains": ["backend", "backend-api", "architecture"],
-      "keywords": [
-        "backend", "api", "dotnet", ".net", "csharp", "c#",
-        "minimal api", "vertical slice", "vsa", "result pattern",
-        "feature slice", "endpoint", "handler", "validator"
-      ],
-      "stack": ["dotnet"],
-      "standards": [
-        "architecture-vertical-slice-vertical-slice",
-        "backend-dotnet-result-pattern",
-        "backend-dotnet-vsa-handler-patterns",
-        "backend-dotnet-fluent-validation-vsa"
-      ],
-      "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados híbrido: IRepository<T> + IUnitOfWork para CRUD, DbContext direto no slice para queries específicas; nunca uma camada de Service/Manager. 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": {
-      "title": "EF Core / Database Modeler",
-      "icon": "🗄️",
-      "color": "cyan",
-      "domains": ["database", "data-modeling", "migrations"],
-      "keywords": [
-        "ef core", "entity framework", "neon", "postgres", "postgresql",
-        "migration", "dbcontext", "navigation property", "configuration"
-      ],
-      "stack": ["dotnet"],
-      "standards": [
-        "backend-database-postgresql-database",
-        "infrastructure-neon-setup",
-        "infrastructure-neon-pgvector"
-      ],
-      "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": {
-      "title": "Microsoft Agent Framework Expert",
-      "icon": "🤖",
-      "color": "purple",
-      "domains": ["ai-agents", "ai-orchestration"],
-      "keywords": [
-        "agent", "ai agent", "maf", "microsoft agent framework",
-        "tool", "tool calling", "rag", "vector search", "llm",
-        "orchestration", "multi-agent"
-      ],
-      "stack": ["dotnet"],
-      "standards": [
-        "ai-agents-setup",
-        "ai-agents-sweet-spot",
-        "ai-agents-providers-model-registry",
-        "ai-agents-structured-output",
-        "ai-agents-prompts-in-db",
-        "ai-agents-rag-custom-pgvector",
-        "ai-agents-middleware-patterns",
-        "ai-agents-multi-agent-patterns"
-      ],
-      "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": {
-      "title": "Next.js / React Expert",
-      "icon": "⚛️",
-      "color": "green",
-      "domains": ["frontend", "ui", "react", "nextjs"],
-      "keywords": [
-        "nextjs", "next.js", "react", "app router", "server component",
-        "client component", "tailwind", "framer motion", "shadcn"
-      ],
-      "stack": ["nextjs"],
-      "standards": [
-        "frontend-nextjs-app-router",
-        "frontend-nextjs-components",
-        "frontend-nextjs-data-fetching",
-        "frontend-nextjs-naming-conventions",
-        "frontend-nextjs-state-management"
-      ],
-      "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": {
-      "title": "UI/UX Designer",
-      "icon": "🎨",
-      "color": "magenta",
-      "domains": ["ui", "ux", "design-system", "accessibility"],
-      "keywords": [
-        "design", "ui", "ux", "design system", "tokens", "wcag",
-        "accessibility", "mockup", "flow", "shadcn", "tailwind"
-      ],
-      "stack": ["nextjs"],
-      "standards": [
-        "frontend-design-system-naming",
-        "frontend-design-system-animations",
-        "frontend-nextjs-motion-patterns"
-      ],
-      "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": {
-      "title": "Infrastructure / Jobs Engineer",
-      "icon": "⚙️",
-      "color": "yellow",
-      "domains": ["infrastructure", "jobs", "deployment", "observability"],
-      "keywords": [
-        "hangfire", "background job", "queue", "deployment",
-        "docker", "ci/cd", "telemetry", "logging", "monitoring"
-      ],
-      "stack": ["dotnet"],
-      "standards": [
-        "backend-integrations-hangfire-hangfire-jobs",
-        "infrastructure-docker-easypanel-deploy",
-        "backend-dotnet-scrutor"
-      ],
-      "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."
-    },
-    "evaluator": {
-      "title": "Code & Architecture Evaluator",
-      "icon": "🔍",
-      "color": "red",
-      "domains": ["evaluation", "review", "quality"],
-      "keywords": [
-        "review", "eval", "score", "rubric", "audit", "quality"
-      ],
-      "stack": ["*"],
-      "standards": [],
-      "persona": "Você aplica as rubricas em framework/evals/rubrics/. Não reescreve código — produz scores 0-10 por dimensão (architecture, contracts, code-quality, test-coverage), feedback priorizado, e ação clara (aprovado/feedback/escalar). Silêncio em scores ≥ 8 é o sinal correto."
-    }
-  }
-}
+{
+  "version": "5.0.0",
+  "schema": "domain-personas",
+  "total_agents": 7,
+  "description": "Domain personas dispatched per task by the morph-implement skill. The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md — these are domain personas the Specialist consults when working in a specific area.",
+  "agents": {
+    "dotnet-senior": {
+      "title": ".NET Senior Engineer",
+      "icon": "🔷",
+      "color": "blue",
+      "domains": ["backend", "backend-api", "architecture"],
+      "keywords": [
+        "backend", "api", "dotnet", ".net", "csharp", "c#",
+        "minimal api", "vertical slice", "vsa", "result pattern",
+        "feature slice", "endpoint", "handler", "validator"
+      ],
+      "stack": ["dotnet"],
+      "standards": [
+        "architecture-vertical-slice-vertical-slice",
+        "backend-dotnet-result-pattern",
+        "backend-dotnet-vsa-handler-patterns",
+        "backend-dotnet-fluent-validation-vsa"
+      ],
+      "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados híbrido: IRepository<T> + IUnitOfWork para CRUD, DbContext direto no slice para queries específicas; nunca uma camada de Service/Manager. 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": {
+      "title": "EF Core / Database Modeler",
+      "icon": "🗄️",
+      "color": "cyan",
+      "domains": ["database", "data-modeling", "migrations"],
+      "keywords": [
+        "ef core", "entity framework", "neon", "postgres", "postgresql",
+        "migration", "dbcontext", "navigation property", "configuration"
+      ],
+      "stack": ["dotnet"],
+      "standards": [
+        "backend-database-postgresql-database",
+        "infrastructure-neon-setup",
+        "infrastructure-neon-pgvector"
+      ],
+      "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": {
+      "title": "Microsoft Agent Framework Expert",
+      "icon": "🤖",
+      "color": "purple",
+      "domains": ["ai-agents", "ai-orchestration"],
+      "keywords": [
+        "agent", "ai agent", "maf", "microsoft agent framework",
+        "tool", "tool calling", "rag", "vector search", "llm",
+        "orchestration", "multi-agent"
+      ],
+      "stack": ["dotnet"],
+      "standards": [
+        "ai-agents-setup",
+        "ai-agents-sweet-spot",
+        "ai-agents-providers-model-registry",
+        "ai-agents-structured-output",
+        "ai-agents-prompts-in-db",
+        "ai-agents-rag-custom-pgvector",
+        "ai-agents-middleware-patterns",
+        "ai-agents-multi-agent-patterns"
+      ],
+      "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": {
+      "title": "Next.js / React Expert",
+      "icon": "⚛️",
+      "color": "green",
+      "domains": ["frontend", "ui", "react", "nextjs"],
+      "keywords": [
+        "nextjs", "next.js", "react", "app router", "server component",
+        "client component", "tailwind", "framer motion", "shadcn"
+      ],
+      "stack": ["nextjs"],
+      "standards": [
+        "frontend-nextjs-app-router",
+        "frontend-nextjs-components",
+        "frontend-nextjs-data-fetching",
+        "frontend-nextjs-naming-conventions",
+        "frontend-nextjs-state-management"
+      ],
+      "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": {
+      "title": "UI/UX Designer",
+      "icon": "🎨",
+      "color": "magenta",
+      "domains": ["ui", "ux", "design-system", "accessibility"],
+      "keywords": [
+        "design", "ui", "ux", "design system", "tokens", "wcag",
+        "accessibility", "mockup", "flow", "shadcn", "tailwind"
+      ],
+      "stack": ["nextjs"],
+      "standards": [
+        "frontend-design-system-naming",
+        "frontend-design-system-animations",
+        "frontend-nextjs-motion-patterns"
+      ],
+      "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": {
+      "title": "Infrastructure / Jobs Engineer",
+      "icon": "⚙️",
+      "color": "yellow",
+      "domains": ["infrastructure", "jobs", "deployment", "observability"],
+      "keywords": [
+        "hangfire", "background job", "queue", "deployment",
+        "docker", "ci/cd", "telemetry", "logging", "monitoring"
+      ],
+      "stack": ["dotnet"],
+      "standards": [
+        "backend-integrations-hangfire-hangfire-jobs",
+        "infrastructure-docker-easypanel-deploy",
+        "backend-dotnet-scrutor"
+      ],
+      "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."
+    },
+    "evaluator": {
+      "title": "Code & Architecture Evaluator",
+      "icon": "🔍",
+      "color": "red",
+      "domains": ["evaluation", "review", "quality"],
+      "keywords": [
+        "review", "eval", "score", "rubric", "audit", "quality"
+      ],
+      "stack": ["*"],
+      "standards": [],
+      "persona": "Você aplica as rubricas em framework/evals/rubrics/. 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."
+    }
+  }
+}

package/framework/commands/create-umbraco-lp.md

@@ -0,0 +1,35 @@
+---
+description: Cria uma nova landing page ponta-a-ponta a partir do template MORPH Umbraco genérico: coleta decisões, scaffolda com new-lp, sobe e valida, customiza branding e módulos.
+argument-hint: [nome-do-projeto]
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill
+---
+
+# /create-umbraco-lp — Nova LP Umbraco
+
+Cria um projeto de landing page novo a partir do template canônico `MORPH_Umbraco_LP_Template`.
+
+**Implementação:** este slash command é um atalho. O agente deve invocar `Skill(create-umbraco-lp)` com o nome do projeto (se fornecido). A skill coleta decisões do usuário uma pergunta por vez, scaffolda via `new-lp.ps1` / `new-lp.sh`, valida o boot (Delivery API + Ping de leads) e apresenta o checklist de entrega.
+
+## Argumentos
+
+`[nome-do-projeto]` — nome do projeto/LP (opcional; se não fornecido, a skill pergunta).
+
+## Pré-requisitos
+
+- `gh` autenticado (ou credencial git) com acesso ao repositório **privado** `polymorphism-tech/MORPH_Umbraco_LP_Template` (branch `master`).
+- .NET 10 SDK instalado (`dotnet --version` deve retornar `10.x`).
+- Node.js 20+ e npm instalados.
+- PowerShell 7+ (Windows) ou bash (Linux/macOS) para os scripts.
+
+## Anti-padrões
+
+- Não editar `backend/uSync/v17/` manualmente durante o setup — deixar o uSync importar no primeiro boot.
+- Não commitar `.env` ou `frontend/.env.local` — contêm credenciais e secrets.
+- Não reutilizar `UMBRACO_GLOBAL_ID` de outro projeto — o script gera um UUID único por execução.
+
+## Referências
+
+- `framework/skills/core/create-umbraco-lp/SKILL.md`
+- `docs/umbraco-lp-patterns.md` (em `main`)
+
+**Projeto:** $ARGUMENTS

package/framework/commands/migrate-lp-to-umbraco.md

@@ -0,0 +1,33 @@
+---
+description: Migra uma LP existente (React/Vite, Next.js estático ou HTML) para o template Umbraco-headless MORPH entregando a LP EXATAMENTE igual à origem (mesmo CSS, imagens, fontes e comportamento) + Umbraco — obtenção automática do template, lift-and-rewire verbatim de cada seção para módulo editável, conexão do formulário ao backend de leads e gate de paridade determinístico. Repo-agnóstica.
+argument-hint: <projeto>
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, Skill
+---
+
+# /migrate-lp-to-umbraco — Migração de LP para Umbraco Headless
+
+Migra a LP de origem para o template `MORPH_Umbraco_LP_Template` de forma reproduzível, entregando a LP **exatamente igual** à origem com o Umbraco por cima.
+
+**Implementação:** este slash command é um atalho. O agente deve invocar `Skill(migrate-lp-to-umbraco)` com o nome do projeto como argumento. A skill é **repo-agnóstica** — obtém o template sozinha e funciona mesmo sem template ou origem pré-baixados.
+
+## Argumentos
+
+`{projeto}` — nome do projeto em kebab-case (ex.: `reserva-das-flores`, `lp-imobiliaria`).
+
+## Fluxo resumido
+
+0. **Obter o template** — clone/cache de `polymorphism-tech/MORPH_Umbraco_LP_Template` (privado, branch `master`) via `gh repo clone` (fallback git HTTPS/SSH). Sempre garantido antes de qualquer passo.
+1. **Analisar a origem (capturar para um lift)** — inventariar seções, markup/classes exatos, CSS/tema verbatim, assets byte-a-byte (com `sha256`), fontes e comportamentos. Origem por código-fonte local ou só URL (scrape). Produzir `docs/origem-inventario.md`.
+2. **Mapear para módulos** — cada seção vira um módulo via **lift verbatim** (default) — reuso direto do template só quando o render já bate com a origem. Produzir `docs/mapeamento-modulos.md`.
+3. **Scaffold via new-lp** — cópia fresca do template para o diretório do projeto, `git init`, `scripts/new-lp.sh`/`.ps1` com `--lead-integration`, smoke-boot com `docker compose up --build`.
+4. **Lift verbatim** — copiar markup/CSS/classes/assets de cada seção verbatim para o componente do módulo, trocando só os literais por leitura do backoffice; uSync `.config`, `SeedContentHandler` idempotente, `globals.css` com o tema portado, registro em `moduleRegistry.ts`.
+5. **Conectar formulário** — selecionar sink (`ghl`/`prospectpro`/`webhook`) no backoffice via nó `leadsConfig`; nunca colocar token em código ou env.
+6. **Gate de paridade** — checks determinísticos (DOM+classes, estilo computado, checksum de assets, comportamento) como bloqueio + screenshot diff como corroboração secundária. A skill scaffolda `parity.spec.ts` e `compare-sections.mjs`.
+
+## Referências
+
+- `framework/skills/core/migrate-lp-to-umbraco/SKILL.md` — playbook completo (passos 0-6, gate de paridade)
+- `polymorphism-tech/MORPH_Umbraco_LP_Template` — template canônico (privado, branch `master`), obtido no passo 0
+- `MORPH_Umbraco_LP_Template/scripts/new-lp.sh` / `new-lp.ps1` — scaffold
+
+**Projeto:** $ARGUMENTS