@polymorphism-tech/morph-spec 4.8.7 → 4.8.9

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

@@ -3,7 +3,7 @@ name: phase-codebase-analysis
 description: MORPH-SPEC Design sub-phase that analyzes existing codebase and database schema, producing schema-analysis.md with real column names, types, relationships, and field mismatches. Use at the start of Design phase before generating contracts.cs to prevent incorrect field names or types.
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.7"
+cliVersion: "4.8.9"
 ---
 
 # MORPH Codebase Analysis - Sub-fase de DESIGN
@@ -44,15 +44,33 @@ Automatiza a análise de código existente para gerar `schema-analysis.md` com d
 
 ### Passo 1: Detectar Método de Análise
 
+**IMPORTANTE (Problem 8 fix):** Não assuma que o MCP está disponível e acessível.
+Verifique primeiro com uma chamada de teste antes de tentar usá-lo.
+
 ```
-SE MCP Supabase disponível:
-  → Usar Método A (MCP direto)
-SE MCP Database disponível:
-  → Usar Método A adaptado
-SENÃO:
-  → Usar Método B (análise estática de código)
+1. SE MCP Supabase configurado no settings.json:
+   → Tentar mcp__supabase__list_tables() com timeout implícito
+   → SE retornar dados válidos (array de tabelas com conteúdo):
+      → Usar Método A (MCP direto)
+   → SE retornar erro, timeout, array vazio, ou dados inacessíveis:
+      → Logar: "MCP Supabase configurado mas inacessível (CloudSQL? Auth? Permissões?)"
+      → Usar Método B (análise estática de código)
+
+2. SE MCP Database (outro) configurado:
+   → Testar conectividade com query trivial antes de usar
+   → SE OK: Usar Método A adaptado
+   → SE falhar: Usar Método B
+
+3. SE nenhum MCP disponível:
+   → Usar Método B (análise estática de código)
 ```
 
+**Sinais de MCP inacessível:**
+- Resposta vazia ou `[]` em `list_tables()`
+- Erro de autenticação / permissão negada
+- Schema retornado não bate com o código (ex: tabelas existem no código mas não no MCP)
+- Projeto usa banco diferente do Supabase (CloudSQL, RDS, Azure SQL, etc.)
+
 ### Passo 2A: Método MCP (Preferencial)
 
 **Ferramentas:** Supabase MCP
@@ -128,6 +146,58 @@ Não use Task subagent quando:
 - Projeto tem < 10 arquivos de query (Read direto é mais rápido)
 - Padrão de acesso a dados é uniforme (só Supabase OU só EF Core)
 
+### Passo 2B-Formato: Formato Padronizado para Análise Estática
+
+**IMPORTANTE (Problem 10 fix):** Quando usar Método B (análise estática), **sempre use o template oficial**.
+Isso garante que `contracts.cs` pode ser gerado mecanicamente, sem interpretação manual.
+
+O template está em `framework/templates/docs/schema-analysis.md`. Use-o via:
+
+```bash
+npx morph-spec template render docs/schema-analysis \
+  .morph/features/{feature}/1-design/schema-analysis.md \
+  '{
+    "FEATURE_NAME": "{feature}",
+    "FEATURE_NAME_TITLE": "{Feature Display Name}",
+    "DATE": "YYYY-MM-DD",
+    "AUTHOR": "Claude Code (Sonnet 4.6)",
+    "method": "Static Code Analysis",
+    "mcpUsed": "No",
+    "tableCount": N,
+    "fileCount": N,
+    "tables": [
+      {
+        "name": "table_name",
+        "codeSource": "path/to/file.ts",
+        "columns": [
+          { "name": "column_name", "type": "string", "nullable": false, "notes": "from SELECT query" }
+        ],
+        "relationships": [{ "description": "belongs to users via user_id" }],
+        "indexes": [{ "description": "idx_leads_created_at (created_at DESC)" }]
+      }
+    ],
+    "fieldMismatches": [
+      { "description": "Code uses user.name but DB column is users.fullname" }
+    ],
+    "typeMismatches": [],
+    "relationshipIssues": [],
+    "dtoRecommendations": [
+      {
+        "tableName": "leads",
+        "dtoName": "LeadDto",
+        "fields": [
+          { "type": "Guid", "name": "Id", "nullable": false, "comment": "PK" },
+          { "type": "string", "name": "FullName", "nullable": false, "comment": "leads.fullname" }
+        ]
+      }
+    ]
+  }'
+```
+
+**Se o template render não estiver disponível**, use **Write** tool para criar o arquivo diretamente
+seguindo a estrutura acima. O formato das tabelas e mismatches é OBRIGATÓRIO — sem formato padrão
+não é possível gerar contracts.cs mecanicamente.
+
 ### Passo 3: Mapear Inconsistências
 
 Crie um mapa de:

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

@@ -1,10 +1,10 @@
 ---
 name: phase-design
-description: MORPH-SPEC Phase 2 (Design). Analyzes codebase/schema, then produces spec.md, contracts-level{N}.cs, 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.
+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.7"
+cliVersion: "4.8.9"
 ---
 
 # MORPH Design - FASE 2
@@ -28,6 +28,9 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 | 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 |
@@ -36,7 +39,8 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 | 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 (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 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 | — |
@@ -49,66 +53,112 @@ Expanda a proposta em especificação técnica completa, contracts, decisões ar
 - ❌ 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)
 
 ---
 
 ## Workflow
 
-### Passo 1: Carregar Contexto e Standards
+### Passo 1: Carregar Contexto, Agentes e Dispatch Config
 
-**Obtenha feature state e standards context:**
+**Obtenha feature state e dispatch config:**
 
 ```bash
 npx morph-spec state get $ARGUMENTS
+npx morph-spec dispatch-agents $ARGUMENTS design
 ```
 
-Parse o JSON para obter `activeAgents`, então carregue os standards context da FASE 1:
-- Standards relevantes estão em `.morph/framework/standards/` por agente ativo (paths em `agents.json`)
-- Prioridade: `.morph/context/*.md` > `.morph/framework/standards/` > `framework/standards/`
+O primeiro comando retorna `activeAgents`. O segundo retorna os agentes a disparar e seus prompts de task.
 
-**Leia outputs existentes:**
+**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)
 
-**Use standards context ao gerar spec.md:**
+**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
-- Azure standards → determinam Infrastructure Requirements
 
-### Passo 1.5: Detectar Nível de Domínio (domain-architect)
+### 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.
+
+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), pois ambos são independentes. Use dois Task calls em paralelo quando o schema analysis também for necessário.
 
-**⚠️ OBRIGATÓRIO:** Execute antes de gerar qualquer contrato.
+#### Caminho A: `domain-architect` ativo (config sem `architecture.style: "vertical-slice"`)
 
 **Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
 
-O `domain-architect` analisa a `proposal.md` e responde às seguintes perguntas:
+**Obtenha o taskPrompt do dispatch config** e use o Task tool:
 
 ```
-1. A entidade principal tem estados com transições? (Draft → Confirmed → Shipped)
-2. Existem invariants de negócio? ("só cancela se estiver Ativo")
-3. Cálculos derivados existem? (Total, Saldo, Desconto)
-4. Outros módulos precisam reagir a mudanças? (Domain Events com consumidores)
-5. O usuário declarou explicitamente Bounded Context na proposta?
-
-→ Nenhuma acima: Nível 1 (CRUD)
-→ 1-4 verdadeiros: Nível 2 (Business Logic)
-→ 5 verdadeiro OU múltiplos domínios com modelos conflitantes: Nível 3 (BC)
-```
+[Task tool — domain-architect]
+Prompt (do dispatch config, enriquecido com conteúdo da proposta):
+
+Você é o Domain Architect da feature '$ARGUMENTS'.
 
-**Documente no spec.md** (seção `## Domain Complexity`) antes de continuar para o Passo 3.
+Proposta da feature:
+[conteúdo de .morph/features/$ARGUMENTS/0-proposal/proposal.md]
 
-**Template a usar no Passo 4 (contracts-level{N}.cs):**
+Standards de referência:
+[.morph/framework/standards/architecture/ddd/complexity-levels.md]
 
-| Nível | Template |
-|-------|----------|
-| 1 | `code/dotnet/contracts/contracts-level1.cs` |
-| 2 | `code/dotnet/contracts/contracts-level2.cs` |
-| 3 | `code/dotnet/contracts/contracts-level3.cs` |
+Sua tarefa — responda cada ponto com "SIM" ou "NÃO" e cite trecho da proposta:
+1. A entidade principal tem estados com transições? (ex: Draft → Confirmed → Shipped)
+2. Existem invariants de negócio que impedem operações? (ex: "só cancela se Ativo")
+3. Há cálculos derivados sobre a entidade? (ex: Total, Saldo, Desconto)
+4. Outros módulos precisam reagir a mudanças? (Domain Events com consumidores reais)
+5. A proposta declara explicitamente Bounded Context ou múltiplos domínios conflitantes?
 
-**Para Nível 2+:** Preencha o `## Aggregate Blueprint` no spec.md antes de gerar contracts-level{N}.cs.
+Regra de decisão:
+→ Todas "NÃO": Nível 1 (CRUD simples)
+→ Alguma de 1-4 "SIM": Nível 2 (Business Logic com AggregateRoot)
+→ 5 "SIM" OU múltiplos domínios com modelos conflitantes: Nível 3 (Bounded Context)
+
+Retorne:
+- Nível detectado (1, 2 ou 3)
+- Justificativa com citações da proposta
+- Para Nível 2+: Aggregate Blueprint inicial (entidade principal, value objects, invariants)
+```
 
+**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 (config com `architecture.style: "vertical-slice"`)
+
+**Ref:** `framework/standards/architecture/vertical-slice/vertical-slice.md`
+
+**Obtenha o taskPrompt do dispatch config** e use o Task tool:
+
+```
+[Task tool — vsa-architect]
+Prompt (do dispatch config, enriquecido com conteúdo da proposta):
+
+Você é o VSA Specialist da feature '$ARGUMENTS'.
+
+Proposta da feature:
+[conteúdo de .morph/features/$ARGUMENTS/0-proposal/proposal.md]
+
+Standards de referência:
+[.morph/framework/standards/architecture/vertical-slice/vertical-slice.md]
+
+Produza um VSA Blueprint:
+1. ENTITY FIELDS: todos os campos com tipos C# corretos (sem AggregateRoot, sem Value Objects)
+2. OPERATIONS: slices necessários (Create, GetAll, GetById, Update, Delete + operações customizadas)
+3. ROUTES: HTTP method + rota por operação (ex: POST /api/products, GET /api/products/{id:guid})
+4. ERROR TYPES: Error factory methods para {Entity}Errors
+5. VALIDATION RULES: regras FluentValidation por campo por operação
+
+Não use AggregateRoot, DomainEvent, CQRS formal, MediatR, Application Service layer.
+```
+
+**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!)
@@ -176,43 +226,50 @@ Se houver recursos Azure:
 
 **SEMPRE usar Bicep para infra!**
 
-### Passo 4: Gerar `contracts-level{N}.cs` (BASEADO NO SCHEMA REAL!)
+### Passo 4: Gerar `contracts.cs` (BASEADO NO SCHEMA REAL!)
+
+**⚠️ IMPORTANTE:** Use `schema-analysis.md` (do Passo 2) para gerar DTOs/campos corretos!
 
-**⚠️ IMPORTANTE:** Use `schema-analysis.md` (do Passo 2) para gerar DTOs 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
-# Use o template de contracts com dados do schema-analysis.md:
+# 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": [...], # Extrair de schema-analysis.md
+    "dtos": [...],
     "interfaces": [...],
     "enums": [...],
     "valueObjects": [...]
   }'
 ```
 
-**OU use Read tool para ler template:**
+**Após renderizar (VSA):** Preencha os campos `TODO` no template gerado com os campos reais da entidade, validators e mapeamentos do VSA Blueprint (Passo 1.5 Caminho B).
 
-```bash
-# Leia o template base:
-Read: .morph/framework/templates/code/dotnet/contracts/contracts-level{N}.cs.hbs
-
-# Preencha manualmente usando dados de schema-analysis.md
-# Template contém placeholders para:
-# - {{FEATURE_NAME_PASCAL}}
-# - {{NAMESPACE}}
-# - {{#each dtos}}...{{/each}}
-# - {{#each interfaces}}...{{/each}}
-# - {{#each enums}}...{{/each}}
-```
-
-**Padrões obrigatórios (já incluídos no template):**
+**Padrões obrigatórios (DDD — já incluídos no template):**
 - Records para DTOs (immutable)
 - Interfaces para serviços
 - CancellationToken em métodos async
@@ -221,6 +278,13 @@ Read: .morph/framework/templates/code/dotnet/contracts/contracts-level{N}.cs.hbs
 - 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)?

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

@@ -6,7 +6,7 @@ disable-model-invocation: true
 context: fork
 agent: general-purpose
 user-invocable: false
-cliVersion: "4.8.7"
+cliVersion: "4.8.9"
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
 ---
 
@@ -31,6 +31,8 @@ Implemente as tasks definidas na FASE 4, com checkpoints a cada 3 tasks e recap
 
 | Ação | Ferramenta | Alternativa |
 |------|------------|-------------|
+| Verificar viabilidade de paralelização | **Bash** `npx morph-spec dispatch-agents $ARGUMENTS implement` | Grupos de tasks + prompts de subagents |
+| **Dispatch implementadores por domínio** (quando viável) | **Task** subagents — um por grupo | Backend + frontend + infra em paralelo |
 | Ler task details | **Read** tasks.json, spec.md, contracts.cs | — |
 | Criar novos arquivos | **Write** source files | — |
 | Modificar arquivos existentes | **Edit** source files | — |
@@ -51,14 +53,70 @@ Implemente as tasks definidas na FASE 4, com checkpoints a cada 3 tasks e recap
 **Anti-padrões:**
 - ❌ Task agent para editar um único arquivo (use Edit direto)
 - ✅ Task agent para implementar service layer em 5+ arquivos (multi-file legítimo)
+- ✅ Task agents paralelos quando `tasks.total ≥ 6` e feature tem 2+ domínios ativos
 - ❌ Bash `cat` para criar arquivos (use Write tool)
 - ❌ Bash `sed` para modificar código (use Edit tool)
 - ❌ Implementar sem ler contracts.cs primeiro (contracts são a fonte de verdade!)
+- ❌ Implementar tasks de backend e frontend sequencialmente quando são independentes
+- ❌ **(VSA)** Criar Application Service layer — handler acessa IRepository diretamente
+- ❌ **(VSA)** Registrar handlers/endpoints manualmente no Program.cs — auto-discovery via reflection
+- ❌ **(VSA)** Colocar Request/Response em arquivos separados do Handler
+- ❌ **(VSA)** Usar `Guid.NewGuid()` — use `Guid.CreateVersion7()`
 
 ---
 
 ## Workflow
 
+### Passo 0.5: Planejar Paralelização
+
+**Execute antes de qualquer implementação:**
+
+```bash
+npx morph-spec dispatch-agents $ARGUMENTS implement
+```
+
+**Se `shouldDispatch: true` no output:**
+
+1. Leia os `taskGroups` retornados (ex: `backend`, `frontend`, `infra`)
+2. Para cada grupo com ≥ 3 tasks e sem dependências cruzadas, use **Task tool** com o `taskPrompt` do dispatch config:
+
+```
+[Task tool — grupo backend, por exemplo]
+Prompt do dispatch config enriquecido:
+
+Você é o implementador do grupo BACKEND da feature '$ARGUMENTS'.
+
+Contexto completo:
+- Spec: [conteúdo de .morph/features/$ARGUMENTS/1-design/spec.md]
+- Contracts: [conteúdo de .morph/features/$ARGUMENTS/1-design/contracts.cs]
+- Tasks do grupo: [lista de TXXX do grupo backend]
+
+Para cada task do grupo, em ordem:
+1. Execute: npx morph-spec task start $ARGUMENTS TXXX
+2. Leia a descrição completa da task
+3. Implemente os arquivos — use Write (novo) ou Edit (existente)
+4. Verifique build: [dotnet build / npm run build]
+5. Execute: npx morph-spec task done $ARGUMENTS TXXX
+
+A cada 3 tasks:
+- Execute: npx morph-spec checkpoint-save $ARGUMENTS
+- Execute: npx morph-spec validate-feature $ARGUMENTS --phase implement
+- Reporte qualquer falha de validação antes de continuar
+
+Restrições OBRIGATÓRIAS:
+- Modifique APENAS os arquivos listados nas tasks do grupo BACKEND
+- NÃO toque em arquivos de frontend, UI ou infra
+- Se encontrar dependência em outro grupo, pause e reporte
+```
+
+3. Dispare os Task subagents dos grupos em **paralelo** (quando sem dependências entre si)
+4. Após todos completarem, valide integração: `npx morph-spec validate-feature $ARGUMENTS --phase implement`
+
+**Se `shouldDispatch: false`** (feature pequena ou single-domain):
+→ Continue para o workflow sequencial normal abaixo.
+
+---
+
 ### CHECKPOINT DE ENTRADA: Verificar Pré-requisitos
 
 **⏸️ Antes de iniciar implementação:**
@@ -90,6 +148,86 @@ Leia TODOS os outputs antes de implementar:
 5. `.morph/features/$ARGUMENTS/1-design/schema-analysis.md` — Schema real (se existir)
 6. `.morph/features/$ARGUMENTS/2-ui/design-system.md` — Design tokens (se existir)
 
+**Detectar estilo de arquitetura:**
+```bash
+# Leia config para saber se é VSA ou DDD:
+cat .morph/config/config.json | grep architecture
+```
+
+Se `config.architecture.style === "vertical-slice"` → siga o **Passo 1.5** antes de implementar.
+Caso contrário → vá direto para o Passo 2.
+
+### Passo 1.5: Guia de Implementação VSA (somente se `style: "vertical-slice"`)
+
+> **Ref:** `framework/standards/architecture/vertical-slice/vertical-slice.md`
+
+**Estrutura de arquivos obrigatória por slice:**
+
+```
+Features/
+└── {Entity}Feature/
+    ├── {Entity}Errors.cs                        ← 1 arquivo por feature (compartilhado)
+    ├── Create{Entity}/
+    │   ├── Create{Entity}Handler.cs             ← Request + Response records + Handler
+    │   ├── Create{Entity}Validator.cs           ← AbstractValidator<Request>
+    │   └── Create{Entity}Endpoint.cs           ← IApiEndpoint (internal sealed)
+    ├── GetAll{Entity}s/
+    │   ├── GetAll{Entity}sHandler.cs           ← sem Validator (sem parâmetros)
+    │   └── GetAll{Entity}sEndpoint.cs
+    ├── Get{Entity}ById/
+    │   ├── Get{Entity}ByIdHandler.cs
+    │   ├── Get{Entity}ByIdValidator.cs
+    │   └── Get{Entity}ByIdEndpoint.cs
+    ├── Update{Entity}/
+    │   ├── Update{Entity}Handler.cs
+    │   ├── Update{Entity}Validator.cs
+    │   └── Update{Entity}Endpoint.cs
+    └── Delete{Entity}/
+        ├── Delete{Entity}Handler.cs
+        ├── Delete{Entity}Validator.cs
+        └── Delete{Entity}Endpoint.cs
+```
+
+**Regras obrigatórias ao implementar cada slice:**
+1. `Request` e `Response` records ficam no **mesmo arquivo** que o `Handler`
+2. Tudo `sealed` — handlers, endpoints, validators, records
+3. `Guid.CreateVersion7()` para gerar IDs (não `Guid.NewGuid()`)
+4. Endpoints usam `result.Match(onSuccess, onFailure)` — nunca acesse `result.Value` sem checar `IsSuccess`
+5. Endpoints são `internal sealed` (não public)
+6. `{Entity}Errors` é static e compartilhado entre todos os slices da feature
+7. Handlers de escrita (Create/Update/Delete) injetam `IRepository<T>` + `IUnitOfWork`
+8. Handlers de leitura (GetAll/GetById) injetam apenas `IRepository<T>`
+9. GetAll não tem Validator
+
+**Registrar entidade no DbContext:**
+```csharp
+// Database/ApplicationDbContext.cs — adicionar:
+public DbSet<{Entity}> {Entities} { get; set; } = null!;
+```
+
+**Criar migration após DbContext atualizado:**
+```bash
+dotnet ef migrations add Add{Entity}
+dotnet ef database update
+```
+
+**Registrar tag em ApiTags (se necessário):**
+```csharp
+// Constants/ApiTags.cs — adicionar:
+public const string {Entities} = "{entities}";
+```
+
+**O que NÃO precisa fazer (auto-discovery via reflection):**
+- ❌ Registrar handler manualmente no Program.cs — `AddHandlersFromAssembly()` faz isso
+- ❌ Registrar endpoint manualmente — `RegisterApiEndpointsFromAssembly()` faz isso
+- ❌ Registrar validator manualmente — `AddValidatorsFromAssembly()` faz isso
+- ❌ Criar Application Service layer — handler acessa IRepository diretamente
+
+**Verificar build após cada slice completo:**
+```bash
+dotnet build
+```
+
 ### Passo 2: Iniciar Primeira Task
 
 ```bash

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

@@ -4,7 +4,7 @@ description: MORPH-SPEC Phase 1 (Setup). Reads project context, detects tech sta
 argument-hint: "[feature-name]"
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.7"
+cliVersion: "4.8.9"
 ---
 
 # MORPH Setup - FASE 1
@@ -29,7 +29,8 @@ Inicialize o contexto e prepare o ambiente para uma feature aprovada.
 | Verificar state | **Bash** `npx morph-spec state get` | — |
 | Detectar agentes + standards | **Read** `.morph/framework/agents.json` → match keywords → **Bash** `npx morph-spec state add-agent` | — |
 | Ler contexto do projeto | **Read** `.morph/context/README.md` | — |
-| Ler config | **Read** `.morph/config.json` | — |
+| Ler config | **Read** `.morph/config/config.json` | — |
+| Detectar arquitetura VSA | **Read** `.morph/config/config.json` → verificar `config.architecture.style` | — |
 | Escanear estrutura do projeto | **Glob** `src/**/*.{ts,tsx,cs}` | — |
 | Metadata do repositório | **GitHub MCP** `get_repo()` | **Bash** `gh repo view --json` |
 | Atualizar state | **Bash** `npx morph-spec state set` | — |
@@ -38,7 +39,7 @@ Inicialize o contexto e prepare o ambiente para uma feature aprovada.
 
 **Anti-padrões:**
 - ❌ Chamar `detect-agents` CLI (não existe — leia `.morph/framework/agents.json` diretamente)
-- ❌ Task agent para detectar stack (leia agents.json e faça o match de keywords inline)
+- ❌ Task agent para o keyword matching inline de stack detection (rápido o suficiente direto)
 - ❌ WebSearch para info local do projeto (use Read/Glob)
 
 ---
@@ -70,11 +71,25 @@ Se não existir, volte para FASE 0 (proposal).
 
 ### Passo 2: Detectar Agentes e Carregar Standards
 
-**Leia agents.json diretamente e faça o match de keywords:**
+#### Passo 2.0: Detectar Estilo de Arquitetura e Ativar Arquiteto
+
+**Leia `.morph/config/config.json` e verifique `config.architecture.style`:**
+
+| Valor | Ação |
+|-------|------|
+| `"vertical-slice"` | `npx morph-spec state add-agent $ARGUMENTS vsa-architect` |
+| ausente / qualquer outro | `npx morph-spec state add-agent $ARGUMENTS domain-architect` |
+
+**Prossiga com keyword detection normal para os demais agentes** (ef-modeler, api-designer, etc.).
+O arquiteto já foi adicionado acima — **ignore-o no keyword matching** para evitar duplicação.
+
+#### Passo 2.1: Keyword Detection
+
+**Leia agents.json diretamente e faça o match de keywords** (exceto `domain-architect` e `vsa-architect` que já foram tratados no Passo 2.0):
 
 1. Leia `.morph/framework/agents.json`
 2. Extraia título e descrição da feature de `0-proposal/proposal.md`
-3. Para cada agente no JSON, verifique se alguma keyword do campo `keywords[]` aparece no texto da proposta
+3. Para cada agente no JSON (exceto arquitetos), verifique se alguma keyword do campo `keywords[]` aparece no texto da proposta
 4. Adicione os agentes correspondentes ao state:
 
 ```bash
@@ -104,7 +119,7 @@ Baseado no proposal e contexto, confirme:
 - Padrões arquiteturais aplicáveis
 - Componentes reutilizáveis existentes
 
-### Passo 4: Listar Agentes Ativos
+### Passo 4: Listar Agentes Ativos e Preview de Dispatch
 
 Mostre os agentes detectados no proposal:
 
@@ -114,6 +129,14 @@ npx morph-spec state get $ARGUMENTS
 
 Parse o JSON e liste os `activeAgents` com seus emojis e responsabilidades (consulte `.morph/framework/agents.json`).
 
+**Se houver 2+ agentes especialistas ativos**, mostre o plano de dispatch para as próximas fases:
+
+```bash
+npx morph-spec dispatch-agents $ARGUMENTS design
+```
+
+Isso informa quais agentes serão disparados em paralelo na fase de design e quais tasks eles executarão.
+
 ### Passo 5: Atualizar State
 
 Marque a feature como na fase SETUP: