@polymorphism-tech/morph-spec 4.8.19 → 4.10.0

package/framework/hooks/dev/validate-skill-format.js

@@ -1,70 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * Dev PreToolUse Hook: Validate Skill Frontmatter Format
- *
- * Event: PreToolUse | Matcher: Write|Edit
- * Scope: Framework codebase only (dev hook)
- *
- * Validates that SKILL.md files written to framework/skills/ have valid
- * YAML frontmatter with required `name:` and `description:` fields.
- *
- * Only validates on Write (full content). Edit operations pass through.
- * Simple regex parsing (no YAML library dependency).
- *
- * Fail-open: exits 0 on any error.
- */
-
-import { readStdin } from '../shared/stdin-reader.js';
-import { getFilePath, getContentToValidate, isWriteOperation } from '../shared/payload-utils.js';
-import { block, pass } from '../shared/hook-response.js';
-
-try {
-  const payload = await readStdin();
-  if (!payload) pass();
-
-  const filePath = getFilePath(payload);
-  if (!filePath) pass();
-
-  // Only check framework/skills/**/SKILL.md
-  if (!filePath.includes('framework/skills/')) pass();
-  if (!filePath.endsWith('SKILL.md')) pass();
-
-  // Only validate full Write operations (not Edit patches)
-  if (!isWriteOperation(payload)) pass();
-
-  const content = getContentToValidate(payload);
-  if (!content) pass();
-
-  // Check for YAML frontmatter delimiters
-  const frontmatterMatch = content.match(/^---\r?\n([\s\S]*?)\r?\n---/);
-  if (!frontmatterMatch) {
-    block(
-      `MORPH-SPEC: SKILL.md at '${filePath}' is missing YAML frontmatter.\n` +
-      'All skill files must start with --- delimited YAML frontmatter containing name: and description: fields.'
-    );
-  }
-
-  const frontmatter = frontmatterMatch[1];
-  const missing = [];
-
-  if (!/^name:/m.test(frontmatter)) {
-    missing.push('name:');
-  }
-  if (!/^description:/m.test(frontmatter)) {
-    missing.push('description:');
-  }
-
-  if (missing.length > 0) {
-    block(
-      `MORPH-SPEC: SKILL.md at '${filePath}' is missing required frontmatter fields:\n` +
-      missing.map(m => `  - ${m}`).join('\n') + '\n\n' +
-      'All skill files must have name: and description: in their YAML frontmatter.'
-    );
-  }
-
-  pass();
-} catch {
-  // Fail-open
-  process.exit(0);
-}

package/framework/hooks/dev/validate-standard-format.js

@@ -1,73 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * Dev PreToolUse Hook: Validate Standard Format
- *
- * Event: PreToolUse | Matcher: Write|Edit
- * Scope: Framework codebase only (dev hook)
- *
- * Validates that files written to framework/standards/ follow the required format:
- *   - `> **Scope:**` metadata header
- *   - `> **Layer:**` metadata header
- *   - `> **Keywords:**` metadata header
- *   - Footer: `*MORPH-SPEC by Polymorphism Tech*`
- *
- * Only validates on Write (full content). Edit operations pass through.
- *
- * Fail-open: exits 0 on any error.
- */
-
-import { readStdin } from '../shared/stdin-reader.js';
-import { getFilePath, getContentToValidate, isWriteOperation } from '../shared/payload-utils.js';
-import { block, pass } from '../shared/hook-response.js';
-
-try {
-  const payload = await readStdin();
-  if (!payload) pass();
-
-  const filePath = getFilePath(payload);
-  if (!filePath) pass();
-
-  // Only check framework/standards/**/*.md
-  if (!filePath.includes('framework/standards/')) pass();
-  if (!filePath.endsWith('.md')) pass();
-
-  // Skip non-standard files
-  const basename = filePath.split('/').pop();
-  if (basename === 'README.md') pass();
-  if (basename === 'STANDARDS.json') pass();
-
-  // Only validate full Write operations (not Edit patches)
-  if (!isWriteOperation(payload)) pass();
-
-  const content = getContentToValidate(payload);
-  if (!content) pass();
-
-  const missing = [];
-
-  if (!/>\s*\*\*Scope:\*\*/.test(content)) {
-    missing.push('> **Scope:** metadata header');
-  }
-  if (!/>\s*\*\*Layer:\*\*/.test(content)) {
-    missing.push('> **Layer:** metadata header');
-  }
-  if (!/>\s*\*\*Keywords:\*\*/.test(content)) {
-    missing.push('> **Keywords:** metadata header');
-  }
-  if (!/\*MORPH-SPEC by Polymorphism Tech\*/.test(content)) {
-    missing.push('Footer: *MORPH-SPEC by Polymorphism Tech*');
-  }
-
-  if (missing.length > 0) {
-    block(
-      `MORPH-SPEC: Standard file '${basename}' is missing required format elements:\n` +
-      missing.map(m => `  - ${m}`).join('\n') + '\n\n' +
-      'All framework standards must include Scope/Layer/Keywords metadata headers and the standard footer.'
-    );
-  }
-
-  pass();
-} catch {
-  // Fail-open
-  process.exit(0);
-}

package/framework/skills/level-1-workflows/phase-clarify/SKILL.md

@@ -1,190 +0,0 @@
----
-name: phase-clarify
-description: MORPH-SPEC Phase 3 (Clarify). Reviews spec.md for ambiguities, generates 3-7 targeted clarification questions, waits for user answers, then updates spec with edge cases and clarification sections. Use after design approval to eliminate spec ambiguities before task breakdown begins.
-argument-hint: "[feature-name]"
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.19"
----
-
-# MORPH Clarify - FASE 3
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Identifique ambiguidades na especificação e faça perguntas de clarificação para garantir que todos os edge cases estão cobertos.
-
-## Pré-requisitos
-
-- [ ] FASE 2 (Design) concluída
-- [ ] `spec.md` aprovado pelo usuário
-- [ ] `contracts.cs` definidos
-
-## Ferramentas Recomendadas
-
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
-> **Example:** `references/clarifications-example.md` — filled-in clarifications.md showing expected Q&A format.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Ler spec.md completo | **Read** spec.md | — |
-| Ler contracts.cs | **Read** contracts.cs | — |
-| Ler schema-analysis.md | **Read** schema-analysis.md | — |
-| Verificar viabilidade de requisito | **Context7 MCP** `query_docs()` | **WebSearch** + **WebFetch** |
-| Verificar issues/limitações conhecidas | **GitHub MCP** `search_issues()` | **Bash** `gh issue list --search "..."` |
-| Pesquisar edge cases externos | **WebSearch** | — |
-| Verificar comportamento UI existente | **Playwright MCP** `browser_navigate()` + `browser_snapshot()` | **WebFetch** URL |
-| Atualizar spec com clarificações | **Edit** spec.md | — |
-| Criar clarifications.md | **Bash** `npx morph-spec template render docs/clarifications .morph/features/$ARGUMENTS/2-clarify/clarifications.md` | — |
-| Atualizar state | **Bash** `npx morph-spec state mark-output $ARGUMENTS clarifications` | — |
-
-**MCPs desta fase:** Context7 (validar viabilidade), GitHub (issues conhecidas), Playwright (verificar UI existente).
-
-**Anti-padrões:**
-- ❌ Task agent para ler spec (use Read direto)
-- ❌ Reescrever spec do zero (use Edit para atualizar seções)
-- ❌ Pular cross-reference com schema-analysis.md (crítico para precisão)
-
----
-
-## Workflow
-
-### Passo 1: Analisar Spec
-
-Leia `.morph/features/$ARGUMENTS/1-design/spec.md` em detalhes e identifique:
-
-#### 1.1. Ambiguidades
-- Requisitos vagos ou genéricos
-- Termos sem definição clara
-- Comportamentos não especificados
-
-#### 1.2. Edge Cases Não Documentados
-- O que acontece se...?
-- Como lidar com entradas inválidas?
-- Comportamento em caso de erro?
-- Estados intermediários (loading, empty)
-
-#### 1.3. Requisitos Conflitantes
-- Duas funcionalidades que parecem incompatíveis
-- Prioridades não claras (o que vem primeiro?)
-
-#### 1.4. Dados Faltantes
-- Validações de negócio não especificadas
-- Limites e constraints (tamanhos, quantidades)
-- Formatos de dados (datas, moedas, etc.)
-
-### Passo 2: Gerar Perguntas de Clarificação
-
-Com base na análise, gere **3-7 perguntas** focadas e específicas:
-
-**Formato de pergunta:**
-```markdown
-### Q{N}: {Categoria} - {Título}
-
-**Context:** {Por que esta pergunta é importante}
-
-**Question:** {Pergunta clara e objetiva}
-
-**Options (if applicable):**
-- A) {Opção 1}
-- B) {Opção 2}
-- C) {Deixar em aberto/usuário decidir}
-
-**Impact:** {Como a resposta afeta a implementação}
-```
-
-### Passo 3: Categorizar Perguntas
-
-Organize perguntas por categoria:
-
-| Categoria | Descrição | Exemplos |
-|-----------|-----------|----------|
-| **Validação** | Regras de negócio, constraints | Limites de tamanho, formatos aceitos |
-| **Comportamento** | O que acontece quando... | Error handling, estados vazios |
-| **Prioridade** | O que é must-have vs nice-to-have | MVP vs futuras iterações |
-| **Integração** | Como interage com sistemas externos | APIs, webhooks, formato de dados |
-| **Performance** | Requisitos de velocidade/volume | Quantos registros? Tempo de resposta? |
-| **UX** | Experiência do usuário | Feedback visual, mensagens de erro |
-
-### Passo 4: Apresentar Perguntas ao Usuário
-
-Liste todas as perguntas de forma clara e estruturada.
-
-**IMPORTANTE:** Não prossiga para próxima fase até ter respostas!
-
-### Passo 5: Atualizar `spec.md` com Respostas
-
-Após receber respostas do usuário, atualize o spec com:
-
-1. **Seção de Clarificações** no início do spec:
-```markdown
-## Clarifications (FASE 3)
-
-### Q1: {Título}
-**Answer:** {Resposta do usuário}
-**Date:** {YYYY-MM-DD}
-```
-
-2. **Atualizar seções relevantes** com detalhes adicionados
-
-### CHECKPOINT: Validar Respostas Completas
-
-**⏸️ PAUSE - Antes de atualizar spec:**
-
-- [ ] Todas as perguntas foram respondidas pelo usuário?
-- [ ] Nenhuma resposta é ambígua ou contraditória?
-- [ ] Respostas são consistentes com `contracts.cs` existente?
-- [ ] Respostas são consistentes com `schema-analysis.md`?
-
-**❌ Se alguma checkbox NÃO estiver marcada:**
-→ Voltar e pedir esclarecimento adicional ao usuário
-
-**✅ Se TODAS as checkboxes estiverem marcadas:**
-→ Prosseguir para atualizar spec.md
-
-### Passo 6: Validar Edge Cases
-
-Documente no spec como lidar com cada edge case identificado:
-
-```markdown
-## Edge Cases
-
-### EC001: {Nome do Edge Case}
-**Scenario:** {Quando acontece}
-**Expected Behavior:** {Como o sistema deve reagir}
-**Implementation Notes:** {Dicas para implementação}
-```
-
-### Passo 7: Atualizar State
-
-## Outputs Gerados/Atualizados
-
-- `.morph/features/$ARGUMENTS/1-design/spec.md` - Atualizado com:
-  - Seção "Clarifications" com perguntas e respostas
-  - Edge cases documentados
-  - Requisitos mais específicos
-- `.morph/features/$ARGUMENTS/2-clarify/clarifications.md` - Novo arquivo com Q&A estruturado
-
-## Critérios de Avanço
-
-- [x] Perguntas de clarificação identificadas (3-7)
-- [x] Perguntas apresentadas ao usuário
-- [x] Respostas do usuário recebidas
-- [x] `spec.md` atualizado com clarificações
-- [x] Edge cases documentados
-- [x] State atualizado
-- [x] Nenhuma ambiguidade crítica remanescente
-
----
-
-## Integração com Superpowers
-
-> Disponível quando o plugin `superpowers` está instalado.
-
-| Skill | Quando Usar | Invocação |
-|-------|-------------|-----------|
-| `systematic-debugging` | Para investigar ambiguidades técnicas complexas | `Skill(superpowers:systematic-debugging)` |
-
----
-
-Continuar automaticamente para FASE 4 (Tasks) após clarificações resolvidas.

package/framework/skills/level-1-workflows/phase-design/SKILL.md

@@ -1,366 +0,0 @@
----
-name: phase-design
-description: MORPH-SPEC Phase 2 (Design). Analyzes codebase/schema, then produces spec.md, contracts.cs (contracts-vsa.cs for VSA or contracts-level{N}.cs for DDD), schema-analysis.md, and decisions.md for the feature. Use after setup phase to create a full technical specification with C# contracts based on the real database schema and architecture decision records.
-argument-hint: "[feature-name]"
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.19"
----
-
-# MORPH Design - FASE 2
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Expanda a proposta em especificação técnica completa, contracts, decisões arquiteturais e estimativa de custos.
-
-## Pré-requisitos
-
-- [ ] FASE 1 (Setup) concluída
-- [ ] FASE 1.5 (UI/UX) concluída OU pulada (se não houver front-end)
-- [ ] Proposta aprovada pelo usuário
-
-## Ferramentas Recomendadas
-
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
-> **Example:** `references/spec-example.md` — filled-in spec.md showing expected output quality.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Ler proposal + UI specs | **Read** output files | — |
-| Obter dispatch config | **Bash** `npx morph-spec dispatch-agents $ARGUMENTS design` | Agentes a disparar + prompts de task |
-| **Dispatch domain-architect** (paralelo) | **Task** subagent com prompt do dispatch config | Análise de complexidade independente |
-| **Dispatch tech leads ativos** (paralelo) | **Task** subagents (dotnet-senior, nextjs-expert…) | Validação de arquitetura independente |
-| Obter schema do banco | **Supabase MCP** `list_tables()`, `get_table_schema()` | **Grep** queries + **Read** types |
-| Obter relacionamentos de FK | **Supabase MCP** `get_relationships()` | **Grep** JOIN/FK no código |
-| Obter políticas RLS | **Supabase MCP** `query()` com pg_policies | **Read** arquivos de políticas |
-| Encontrar arquivos de query (fallback) | **Grep** `\.from\(` em `*.ts,*.tsx,*.js,*.cs` | — |
-| Encontrar definições de tipo (fallback) | **Glob** `src/**/types/**/*.ts` ou `**/Entities/**/*.cs` | — |
-| Ler arquivos de query/tipos (fallback) | **Read** cada arquivo encontrado | — |
-| Pesquisar biblioteca para ADR | **Context7 MCP** `query_docs()` | **WebSearch** + **WebFetch** |
-| Buscar padrões no código | **GitHub MCP** `search_code()` | **Grep** padrões no projeto |
-| Renderizar template contracts (VSA) | **Bash** `npx morph-spec template render code/dotnet/contracts/contracts-vsa.cs ...` | — |
-| Renderizar template contracts (DDD nível detectado) | **Bash** `npx morph-spec template render code/dotnet/contracts/contracts-level{N}.cs ...` onde N = nível detectado no Passo 1.5 | — |
-| Renderizar template spec.md | **Bash** `npx morph-spec template render docs/spec ...` | — |
-| Renderizar template decisions.md | **Bash** `npx morph-spec template render docs/decisions ...` | — |
-| Criar schema-analysis.md | **Write** no diretório de outputs | — |
-| Atualizar state | **Bash** `npx morph-spec state mark-output ...` | — |
-
-**MCPs desta fase:** Supabase (schema analysis — **PRIORITÁRIO**), Context7 (research), GitHub (code search).
-
-**Anti-padrões:**
-- ❌ Adivinhar nomes de campos sem verificar schema (use MCP ou Grep primeiro!)
-- ❌ Task agent para ler um único arquivo spec (use Read direto)
-- ❌ WebSearch para schema do banco (use Supabase MCP ou análise de código)
-- ❌ Escrever contracts-level{N}.cs do zero (use template render)
-- ❌ Executar análise de domínio e análise de schema sequencialmente (são independentes — paralelize!)
-- ❌ Fazer análise de domínio inline no contexto principal quando 2+ agentes estão ativos (use Task dispatch)
-
----
-
-## ✅ PRÉ-VOO OBRIGATÓRIO (antes de gerar qualquer artefato)
-
-### 1. Verificar contexto injetado pelo SessionStart
-
-O hook já injetou o estado atual. Confirme que você leu:
-- Feature ativa, fase, status de approvals
-- Task progress e pending gates
-- Spec snippet (se disponível)
-
-### 2. Ler todos os prerequisitos em PARALELO
-
-```
-# Uma única chamada, não sequencial:
-Read: .morph/features/{feature}/0-proposal/proposal.md
-    + Read: .morph/config/config.json   (→ architecture.style)
-    + Read: .morph/context/README.md    (→ project context)
-    + Read: framework/agents.json       (→ activeAgents do feature)
-```
-
-### 3. Avaliar escopo → EnterPlanMode se necessário
-
-Se QUALQUER uma das condições abaixo for verdadeira:
-- [ ] Refactor toca ≥5 arquivos existentes de domínio
-- [ ] Estimativa de tasks ≥20
-- [ ] Mudança de arquitetura (ex: migrar de DDD Level 1 → Level 2)
-
-→ **USE EnterPlanMode** antes de gerar contratos. Explore o codebase, apresente opções, aguarde aprovação.
-
-### 4. Dispatch paralelo de subagents para artefatos independentes
-
-Os 4 artefatos de design são **independentes entre si**. Dispatch em paralelo:
-
-```
-# Executar todos ao mesmo tempo (uma mensagem, múltiplos Task tool calls):
-Task(subagent=general): gerar spec.md (endpoints, regras de negócio)
-Task(subagent=general): gerar contracts-vsa.cs ou contracts-levelN.cs
-Task(subagent=general): gerar decisions.md (ADRs)
-Task(subagent=general): gerar tasks.md skeleton
-```
-
-Ou obter config de dispatch:
-```bash
-npx morph-spec dispatch-agents {feature} design --table
-```
-
-### 5. Criar tasks de sessão para visibilidade
-
-```
-TaskCreate: "Gerar spec.md"          → activeForm: "Gerando spec.md"
-TaskCreate: "Gerar contracts.cs"     → activeForm: "Gerando contracts.cs"
-TaskCreate: "Gerar decisions.md"     → activeForm: "Gerando decisions.md"
-TaskCreate: "Avanço de fase"         → activeForm: "Avançando fase"
-```
-
----
-
-## Workflow
-
-### Passo 1: Carregar Contexto, Agentes e Dispatch Config
-
-**Obtenha feature state e dispatch config:**
-
-```bash
-npx morph-spec state get $ARGUMENTS
-npx morph-spec dispatch-agents $ARGUMENTS design
-```
-
-O primeiro comando retorna `activeAgents`. O segundo retorna os agentes a disparar e seus prompts de task.
-
-**Leia outputs existentes em paralelo (Read direto):**
-1. `.morph/features/$ARGUMENTS/0-proposal/proposal.md` - Proposta inicial
-2. `.morph/features/$ARGUMENTS/2-ui/*.md` - UI/UX specs (se existirem)
-
-**Standards context** (carregue para o contexto principal os standards dos agentes ativos):
-- Paths dos standards em `agents.json[activeAgent].standards[]`
-- Prioridade: `.morph/context/*.md` > `.morph/framework/standards/` > `framework/standards/`
-- Architecture standards → guiam Technical Architecture section
-- Coding standards → definem contracts-level{N}.cs patterns
-
-### Passo 1.5: Análise de Domínio via Task Dispatch
-
-**⚠️ OBRIGATÓRIO:** Execute antes de gerar qualquer contrato. Use **Task tool** para isolar esta análise do contexto principal.
-
-> Para os prompts completos de análise de arquitetura, veja `references/architecture-analysis-guide.md`
-
-O arquiteto ativo (lido do dispatch config no Passo 1) pode ser `domain-architect` (DDD) ou `vsa-architect` (VSA) — o prompt vem do dispatch config retornado por `dispatch-agents`.
-
-**Paralelização:** Este Task dispatch pode iniciar SIMULTANEAMENTE com o Passo 2 (schema analysis).
-
-#### Caminho A: `domain-architect` ativo (DDD)
-
-Use o `taskPrompt` do dispatch config (enriquecido com o conteúdo da proposta). O agente responde às 5 perguntas de complexidade DDD e retorna o nível (1, 2 ou 3) com justificativa.
-
-**Após receber o resultado:**
-- Documente no spec.md (seção `## Domain Complexity`)
-- **Para Nível 2+:** Preencha o `## Aggregate Blueprint` no spec.md
-- **Para Nível 3:** Adicione `BOUNDED_CONTEXT` como variável ao renderizar o template
-
-#### Caminho B: `vsa-architect` ativo (VSA)
-
-Use o `taskPrompt` do dispatch config (enriquecido com o conteúdo da proposta). O agente produz um VSA Blueprint com entity fields, operations, routes, error types e validation rules.
-
-**Após receber o resultado:** Documente no spec.md (seção `## Architecture Style: Vertical Slice`).
-
----
-
-### Passo 2: Analisar Código Existente (CRÍTICO - FAZER ANTES DE CONTRACTS!)
-
-**⚠️ ATENÇÃO:** Este passo é OBRIGATÓRIO antes de gerar `contracts-level{N}.cs`. Previne geração de DTOs com nomes de campos errados.
-
-**Delegate para skill dedicada:**
-
-> **Ref:** `framework/skills/level-1-workflows/phase-codebase-analysis/SKILL.md` — workflow completo de análise de schema (MCP Supabase → fallback análise estática → SCHEMA-ANALYSIS.md → checkpoint de aprovação)
-
-Execute o workflow de `phase-codebase-analysis.md` para:
-1. Detectar se análise é necessária
-2. Tentar MCP Supabase (preferencial) ou análise estática (fallback)
-3. Mapear field name mismatches e type mismatches
-4. Gerar `schema-analysis.md` com findings reais
-5. Apresentar checkpoint ao usuário e aguardar aprovação
-
-**Pule se:**
-- Feature é 100% nova (sem dependências em código existente)
-- Não há banco de dados ou APIs envolvidas
-
-### Passo 3: Gerar `spec.md`
-
-> Para estrutura detalhada de cada seção, veja `references/spec-authoring-guide.md`
-
-Crie `.morph/features/$ARGUMENTS/1-design/spec.md` com as seções: Overview, Functional Requirements (FR001...), Non-Functional Requirements, Technical Architecture, Data Model, e Infrastructure Requirements (se aplicável).
-
-### Passo 4: Gerar `contracts.cs` (BASEADO NO SCHEMA REAL!)
-
-**⚠️ IMPORTANTE:** Use `schema-analysis.md` (do Passo 2) para gerar DTOs/campos corretos!
-
-**Selecione o template baseado no arquiteto ativo:**
-
-| Arquiteto ativo | Template |
-|-----------------|---------|
-| `vsa-architect` | `code/dotnet/contracts/contracts-vsa.cs` |
-| `domain-architect` (Nível 1) | `code/dotnet/contracts/contracts-level1.cs` |
-| `domain-architect` (Nível 2) | `code/dotnet/contracts/contracts-level2.cs` |
-| `domain-architect` (Nível 3) | `code/dotnet/contracts/contracts-level3.cs` |
-
-**Renderizar template:**
-
-```bash
-# Para projetos VSA:
-npx morph-spec template render \
-  dotnet-contracts-vsa \
-  .morph/features/$ARGUMENTS/1-design/contracts.cs \
-  '{
-    "FEATURE_NAME": "$ARGUMENTS",
-    "NAMESPACE": "{ProjectNamespace}",
-    "ROUTE": "/api/{kebabCase FEATURE_NAME}s",
-    "DATE": "{{DATE}}"
-  }'
-
-# Para projetos DDD (substituir N pelo nível detectado):
-npx morph-spec template render \
-  code/dotnet/contracts/contracts-level{N}.cs \
-  .morph/features/$ARGUMENTS/1-design/contracts.cs \
-  '{
-    "FEATURE_NAME": "$ARGUMENTS",
-    "NAMESPACE": "{ProjectNamespace}",
-    "dtos": [...],
-    "interfaces": [...],
-    "enums": [...],
-    "valueObjects": [...]
-  }'
-```
-
-**Após renderizar (VSA):** Preencha os campos marcados com `// placeholder:` no template gerado com os campos reais da entidade, validators e mapeamentos do VSA Blueprint (Passo 1.5 Caminho B).
-
-**Padrões obrigatórios (DDD — já incluídos no template):**
-- Records para DTOs (immutable)
-- Interfaces para serviços
-- CancellationToken em métodos async
-- Nullable reference types habilitados
-- **USAR NOMES DE CAMPOS REAIS DO SCHEMA** (NÃO assumir!)
-- XML documentation comments
-- Value objects para complex types
-
-**Padrões obrigatórios (VSA — já incluídos no template):**
-- Request + Response records no mesmo arquivo do Handler
-- `sealed` em handlers, endpoints, validators, records
-- `Guid.CreateVersion7()` para IDs
-- `result.Match()` nos endpoints
-- `{Entity}Errors` estático compartilhado por todos os slices da feature
-
-**⚠️ CHECKPOINT: Verificar contra schema-analysis.md**
-- [ ] Todos os field names correspondem ao schema real?
-- [ ] Tipos de dados corretos (JSONB → JsonObject, não string)?
-- [ ] Nullability correta (campo opcional no banco → nullable no DTO)?
-- [ ] Relacionamentos mapeados corretamente?
-- [ ] Template foi renderizado corretamente?
-
-### Passo 5: Iniciar `decisions.md`
-
-**Renderizar template:**
-
-```bash
-# Use o template de decisions:
-Read: .morph/framework/templates/feature/decisions.md
-
-# OU renderize via CLI:
-npx morph-spec template render \
-  feature/decisions \
-  .morph/features/$ARGUMENTS/1-design/decisions.md \
-  '{
-    "FEATURE_NAME": "$ARGUMENTS",
-    "DATE": "{{DATE}}",
-    "decisions": []
-  }'
-```
-
-**Template contém estrutura para ADRs (Architecture Decision Records):**
-- Status, Context, Decision, Consequences
-- Pros/Cons analysis
-- Alternatives Considered section
-- Date tracking
-
-**ADRs obrigatórios:**
-- Escolha de biblioteca UI (se FASE 1.5 executou)
-- Padrões arquiteturais (CQRS, Repository, etc.)
-- Recursos Azure (se houver infra)
-- Integrações externas (APIs, webhooks, etc.)
-- Análise de custos (se houver recursos pagos)
-
-### Passo 6: Estimar Custos
-
-Se houver recursos Azure na spec:
-
-**Limites configuráveis** (em config.json):
-- `costs.limits.freeTierOnly`: $0 (apenas free tier)
-- `costs.limits.withApproval`: $10 (requer confirmação do usuário)
-- `costs.limits.requiresADR`: $10 (requer ADR documentado)
-
-Documente custos em `decisions.md` e atualize state:
-
-```bash
-npx morph-spec state set $ARGUMENTS costs.estimated {X.XX}
-npx morph-spec state set $ARGUMENTS costs.approved {true/false}
-```
-
-### Passo 7: Atualizar State
-
-```bash
-npx morph-spec state mark-output $ARGUMENTS schema-analysis
-npx morph-spec state mark-output $ARGUMENTS spec
-npx morph-spec state mark-output $ARGUMENTS contracts
-npx morph-spec state mark-output $ARGUMENTS decisions
-```
-
-## Outputs Gerados
-
-- `.morph/features/$ARGUMENTS/1-design/schema-analysis.md` - **NOVO!** Análise do schema real
-- `.morph/features/$ARGUMENTS/1-design/spec.md` - Especificação técnica completa
-- `.morph/features/$ARGUMENTS/1-design/contracts.cs` - Interfaces, DTOs, Enums (baseados no schema real!)
-- `.morph/features/$ARGUMENTS/1-design/decisions.md` - ADRs (novo ou atualizado)
-- State atualizado com custos estimados
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar design e continuar para clarificação**
-2. **Ajustar escopo/complexidade** - Revisar spec.md
-3. **Modificar contracts** - Ajustar interfaces/DTOs
-
-## Critérios de Avanço
-
-- [x] `spec.md` completo com todos os requisitos
-- [x] `contracts-level{N}.cs` com interfaces e DTOs
-- [x] `decisions.md` com ADRs relevantes
-- [x] Custos estimados e documentados (se houver infra)
-- [x] State atualizado
-- [x] Usuário aprovou design
-
----
-
-## Integração com Superpowers
-
-> Disponível quando o plugin `superpowers` está instalado.
-
-| Skill | Quando Usar | Invocação |
-|-------|-------------|-----------|
-| `writing-plans` | Após spec aprovado, para estruturar abordagem de implementação | `Skill(superpowers:writing-plans)` |
-| `brainstorming` | Para explorar alternativas de arquitetura (use morph-spec version) | Use `brainstorming` (morph-spec version) |
-
----
-
-## Outputs desta Fase
-
-<!-- morph:outputs:design -->
-| Output | Caminho |
-|--------|---------|
-| `schemaAnalysis` | `.morph/features/{feature}/1-design/schema-analysis.md` |
-| `spec` | `.morph/features/{feature}/1-design/spec.md` |
-| `contracts` | `.morph/features/{feature}/1-design/contracts.cs` |
-| `decisions` | `.morph/features/{feature}/1-design/decisions.md` |
-<!-- /morph:outputs -->
-
----
-
-Continuar automaticamente para FASE 3 (Clarify) após aprovação.