@polymorphism-tech/morph-spec 4.8.12 → 4.8.15

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

@@ -5,7 +5,7 @@ argument-hint: "[feature-name]"
 disable-model-invocation: true
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.12"
+cliVersion: "4.8.15"
 ---
 
 # MORPH Tasks - FASE 4
@@ -50,6 +50,31 @@ Quebre a especificação em tasks executáveis, defina ordem de execução e est
 
 ---
 
+## ✅ PRÉ-VOO OBRIGATÓRIO (antes de iniciar breakdown de tasks)
+
+### 1. Ler todos os prerequisitos em PARALELO
+
+```
+# Uma única chamada, não sequencial:
+Read: .morph/features/{feature}/1-design/spec.md
+    + Read: .morph/features/{feature}/1-design/contracts.cs
+    + Read: .morph/features/{feature}/1-design/decisions.md
+    + Read: .morph/features/{feature}/1-design/schema-analysis.md  (se existir)
+    + Read: .morph/config/config.json                               (→ architecture.style)
+```
+
+### 2. Criar tasks de sessão para visibilidade
+
+```
+TaskCreate: "Analisar spec e definir tasks"   → activeForm: "Analisando spec"
+TaskCreate: "Gerar tasks.md"                  → activeForm: "Gerando tasks.md"
+TaskCreate: "Avanço de fase"                  → activeForm: "Avançando fase"
+```
+
+> **Nota:** As tasks individuais T001-T00N serão criadas como native tasks durante a fase de implementação (`phase-implement`). Aqui mantemos apenas as 3 tasks de alto nível desta sessão de planejamento.
+
+---
+
 ## Workflow
 
 ### CHECKPOINT DE ENTRADA: Verificar Pré-requisitos
@@ -93,90 +118,15 @@ cat .morph/config/config.json | grep -A3 '"architecture"'
 
 ### Passo 0.5: Plano de Tasks — VSA
 
-**Ref:** `framework/standards/architecture/vertical-slice/vertical-slice.md`
+> Para padrões de tarefas VSA e mapeamento DDD por nível, veja `references/task-planning-patterns.md`
 
-Leia a seção `## Architecture Style: Vertical Slice` do spec.md para o **VSA Blueprint** (entity fields, operações, rotas, validações):
+Leia a seção `## Architecture Style: Vertical Slice` do spec.md para o **VSA Blueprint**:
 
 ```bash
 grep -A30 "## Architecture Style" ".morph/features/$ARGUMENTS/1-design/spec.md"
 ```
 
-**Categorias de tasks VSA** (uma task por slice — Handler + Validator + Endpoint juntos):
-
-| Categoria | Descrição | Arquivo(s) |
-|-----------|-----------|------------|
-| **entity** | Entity class + DbSet no ApplicationDbContext | `Entities/{Entity}.cs`, `Database/ApplicationDbContext.cs` |
-| **errors** | `{Entity}Errors` static class com factory methods | `Features/{Entity}Feature/{Entity}Errors.cs` |
-| **tags** | Constante em ApiTags (se tag nova) | `Constants/ApiTags.cs` |
-| **migration** | `dotnet ef migrations add` + `database update` | `Migrations/...` |
-| **slice** | Slice completo: Handler (+ Request + Response records) + Validator + Endpoint | `Features/{Entity}Feature/{Op}/{Op}Handler.cs`, `...Validator.cs`, `...Endpoint.cs` |
-| **tests** | Unit tests dos handlers | `Tests/Features/{Entity}Feature/...` |
-| **docs** | README, Swagger, comentários | — |
-
-**Ordem obrigatória (bottom-up VSA):**
-
-```
-T001: Entity + DbContext DbSet
-   ↓
-T002: {Entity}Errors (factory methods)
-   ↓
-T003: ApiTags constant (se tag ainda não existe)
-   ↓
-T004: Migration (Add{Entity} + database update)
-   ↓
-T005: Slice Create{Entity}     ← Handler+Validator+Endpoint = 1 task
-T006: Slice GetAll{Entity}s    ← Handler+Endpoint = 1 task (sem Validator)
-T007: Slice Get{Entity}ById    ← Handler+Validator+Endpoint = 1 task
-T008: Slice Update{Entity}     ← Handler+Validator+Endpoint = 1 task
-T009: Slice Delete{Entity}     ← Handler+Validator+Endpoint = 1 task
-   ↓
-T010+: Slices customizados (operações extra do VSA Blueprint)
-   ↓
-T0NN: Tests
-```
-
-**Regras VSA para tasks:**
-- 1 task = 1 slice completo (Handler + Validator + Endpoint num único task)
-- `GetAll` NÃO tem Validator — mencionar explicitamente no task
-- Cada task de slice lista os 3 arquivos que devem ser criados no campo `files`
-- Entity task deve incluir a linha `DbSet<{Entity}>` no `ApplicationDbContext`
-- Migration task é separada da entity task (pode rodar em paralelo com errors + tags)
-
-**Exemplo de tasks VSA geradas:**
-
-```json
-{ "id": "T001", "title": "Criar Entity Book + registrar DbSet no ApplicationDbContext",
-  "category": "entity", "dependencies": [],  "estimatedMinutes": 20,
-  "files": ["Entities/Book.cs", "Database/ApplicationDbContext.cs"] }
-
-{ "id": "T002", "title": "Criar BookErrors (NotFound + outros factory methods)",
-  "category": "errors", "dependencies": ["T001"], "estimatedMinutes": 10,
-  "files": ["Features/BookFeature/BookErrors.cs"] }
-
-{ "id": "T003", "title": "Adicionar ApiTags.Books em Constants/ApiTags.cs",
-  "category": "tags", "dependencies": [], "estimatedMinutes": 5,
-  "files": ["Constants/ApiTags.cs"] }
-
-{ "id": "T004", "title": "Criar migration AddBook + aplicar ao banco",
-  "category": "migration", "dependencies": ["T001"], "estimatedMinutes": 10,
-  "files": ["Migrations/...AddBook.cs"] }
-
-{ "id": "T005", "title": "Implementar slice CreateBook (Handler + Validator + Endpoint)",
-  "category": "slice", "dependencies": ["T001", "T002", "T003", "T004"],
-  "estimatedMinutes": 45,
-  "files": [
-    "Features/BookFeature/CreateBook/CreateBookHandler.cs",
-    "Features/BookFeature/CreateBook/CreateBookValidator.cs",
-    "Features/BookFeature/CreateBook/CreateBookEndpoint.cs"
-  ] }
-
-{ "id": "T006", "title": "Implementar slice GetAllBooks (Handler + Endpoint, sem Validator)",
-  "category": "slice", "dependencies": ["T001", "T004"], "estimatedMinutes": 25,
-  "files": [
-    "Features/BookFeature/GetAllBooks/GetAllBooksHandler.cs",
-    "Features/BookFeature/GetAllBooks/GetAllBooksEndpoint.cs"
-  ] }
-```
+Crie uma task por slice (entity → errors → tags → migration → slices CRUD → slices custom → tests). Cada slice = Handler + Validator + Endpoint numa única task. `GetAll` não tem Validator.
 
 **Após definir tasks VSA, pule direto para o Passo 3 (Dependências).**
 
@@ -184,39 +134,15 @@ T0NN: Tests
 
 ### Passo 0.6: Ler Nível de Domínio — DDD
 
-**Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
-
-Antes de quebrar tasks, leia a seção `## Domain Complexity` do spec.md:
+Leia a seção `## Domain Complexity` do spec.md:
 
 ```bash
 grep -A15 "## Domain Complexity" ".morph/features/$ARGUMENTS/1-design/spec.md"
 ```
 
-> Se a seção não existir no spec.md, assuma **Nível 1 (CRUD)** e documente nos pre-requisitos da task.
-
-Use o nível para **restringir** as categorias de tasks às listadas para o nível detectado:
-
-| Nível | Categorias de Tasks |
-|-------|---------------------|
-| **1 — CRUD** | `domain` (Entity simples) → `infrastructure` (Repository, EF Config) → `application` (Service CRUD) → `presentation` (API/Page) → `tests` |
-| **2 — Business Logic** | `domain` (AggregateRoot, ValueObjects, DomainEvents) → `infrastructure` (Repository, EF Config) → `application` (Commands, Queries, Handlers) → `presentation` (API/Page) → `tests` |
-| **3 — Bounded Context** | `domain-bc` (BC setup, Aggregates, Events) → `infrastructure` (BC repositories, EF) → `application` (Commands, Queries, Integration handlers) → `presentation` → `tests` |
+> Se a seção não existir, assuma **Nível 1 (CRUD)**.
 
-**Nível 1:** Nenhuma task adicional obrigatória — apenas o padrão CRUD nas categorias listadas.
-
-**Tasks adicionais obrigatórias por nível:**
-
-**Nível 2 apenas:**
-- `T{N}: Implementar AggregateRoot {EntityName} com factory method e invariants` (domain)
-- `T{N}: Implementar ValueObjects: {lista do Aggregate Blueprint}` (domain)
-- `T{N}: Implementar DomainEvents: {lista do Aggregate Blueprint}` (domain)
-- `T{N}: Implementar Command Handlers com MediatR` (application)
-- `T{N}: Implementar Query Handlers com read models` (application)
-
-**Nível 3 apenas (além do Nível 2):**
-- `T{N}: Configurar namespace/pasta do Bounded Context {BoundedContext}` (infrastructure)
-- `T{N}: Implementar Integration Events para comunicação cross-BC` (domain-bc)
-- `T{N}: Implementar handlers de Integration Events` (application)
+Use o nível para restringir categorias (Nível 1: domain→infra→application→presentation→tests; Nível 2: adiciona AggregateRoot, ValueObjects, DomainEvents, CQRS handlers; Nível 3: adiciona BC setup, Integration Events). Ver `references/task-planning-patterns.md` para tabela completa.
 
 ---
 
@@ -233,58 +159,9 @@ Leia `.morph/features/$ARGUMENTS/1-design/spec.md` e identifique:
 
 ### Passo 2: Quebrar em Tasks
 
-Crie tasks no formato **T{NNN}** seguindo ordem lógica de implementação.
-
-#### 2.1. Estrutura de Task
-
-```json
-{
-  "id": "T001",
-  "title": "Criar Entity {Nome}",
-  "description": "Implementar entity {Nome} com propriedades X, Y, Z seguindo padrões EF Core",
-  "category": "domain",
-  "dependencies": [],
-  "estimatedMinutes": 30,
-  "status": "pending",
-  "specSections": ["## Domain Model", "## Business Rules"],
-  "contractInterfaces": ["I{Nome}Repository"],
-  "files": [
-    "Domain/Entities/{Nome}.cs",
-    "Infrastructure/Data/Configurations/{Nome}Configuration.cs"
-  ]
-}
-```
+> Para estrutura JSON, categorias e ordem de implementação, veja `references/task-planning-patterns.md`
 
-#### 2.2. Categorias de Tasks
-
-| Categoria | Descrição | Exemplos |
-|-----------|-----------|----------|
-| **domain** | Entities, Value Objects, Enums | Entity, DomainException |
-| **application** | Services, DTOs, Interfaces | Service, Validator, Mapper |
-| **infrastructure** | DbContext, Repositories, External APIs | EF Config, Repository impl |
-| **presentation** | Controllers, Pages, Components | API endpoint, Blazor page |
-| **tests** | Unit tests, Integration tests | Service tests, API tests |
-| **infra** | Bicep, Migrations, Scripts | Azure resources, DB migration |
-| **docs** | README, API docs, Swagger | OpenAPI spec, README update |
-
-#### 2.3. Ordem de Implementação
-
-**Bottom-up approach:**
-```
-1. Domain (Entities, Enums, Value Objects)
-   ↓
-2. Infrastructure (Repositories, DbContext configs)
-   ↓
-3. Application (Services, DTOs, Business logic)
-   ↓
-4. Presentation (Controllers, Pages, Components)
-   ↓
-5. Tests (Unit → Integration)
-   ↓
-6. Infra (Bicep, Migrations, Deploy scripts)
-   ↓
-7. Docs (README, Swagger, Comments)
-```
+Crie tasks no formato **T{NNN}** seguindo bottom-up: domain → infrastructure → application → presentation → tests → infra → docs.
 
 ### Passo 3: Definir Dependências
 
@@ -329,7 +206,7 @@ Para cada task, estime tempo em minutos:
 | Média (Business logic, validações) | 60-120 min |
 | Complexa (Integrações, AI) | 120-240 min |
 
-### Passo 6: Gerar `tasks.json`
+### Passo 6: Gerar `tasks.md`
 
 Crie `.morph/features/$ARGUMENTS/3-tasks/tasks.md` com a estrutura completa de tasks, checkpoints e estimativas.
 
@@ -340,7 +217,6 @@ Se houver recursos Azure, adicionar tasks de Bicep e migrations.
 ### Passo 8: Atualizar State
 
 ```bash
-npx morph-spec state set $ARGUMENTS phase tasks
 npx morph-spec state set $ARGUMENTS tasks.total {N}
 npx morph-spec state mark-output $ARGUMENTS tasks
 ```

package/framework/skills/level-1-workflows/phase-tasks/references/task-planning-patterns.md

@@ -0,0 +1,172 @@
+# Task Planning Patterns — VSA e DDD
+
+> Padrões detalhados de task planning para VSA e DDD.
+> Referenciado pelos Passos 0.5 e 0.6 de `phase-tasks/SKILL.md`.
+
+---
+
+## Padrão VSA (Vertical Slice Architecture)
+
+**Ref:** `framework/standards/architecture/vertical-slice/vertical-slice.md`
+
+### Categorias de tasks VSA
+
+Uma task por slice — Handler + Validator + Endpoint juntos:
+
+| Categoria | Descrição | Arquivo(s) |
+|-----------|-----------|------------|
+| **entity** | Entity class + DbSet no ApplicationDbContext | `Entities/{Entity}.cs`, `Database/ApplicationDbContext.cs` |
+| **errors** | `{Entity}Errors` static class com factory methods | `Features/{Entity}Feature/{Entity}Errors.cs` |
+| **tags** | Constante em ApiTags (se tag nova) | `Constants/ApiTags.cs` |
+| **migration** | `dotnet ef migrations add` + `database update` | `Migrations/...` |
+| **slice** | Slice completo: Handler (+ Request + Response records) + Validator + Endpoint | `Features/{Entity}Feature/{Op}/{Op}Handler.cs`, `...Validator.cs`, `...Endpoint.cs` |
+| **tests** | Unit tests dos handlers | `Tests/Features/{Entity}Feature/...` |
+| **docs** | README, Swagger, comentários | — |
+
+### Ordem obrigatória (bottom-up VSA)
+
+```
+T001: Entity + DbContext DbSet
+   ↓
+T002: {Entity}Errors (factory methods)
+   ↓
+T003: ApiTags constant (se tag ainda não existe)
+   ↓
+T004: Migration (Add{Entity} + database update)
+   ↓
+T005: Slice Create{Entity}     ← Handler+Validator+Endpoint = 1 task
+T006: Slice GetAll{Entity}s    ← Handler+Endpoint = 1 task (sem Validator)
+T007: Slice Get{Entity}ById    ← Handler+Validator+Endpoint = 1 task
+T008: Slice Update{Entity}     ← Handler+Validator+Endpoint = 1 task
+T009: Slice Delete{Entity}     ← Handler+Validator+Endpoint = 1 task
+   ↓
+T010+: Slices customizados (operações extra do VSA Blueprint)
+   ↓
+T0NN: Tests
+```
+
+### Regras VSA para tasks
+
+- 1 task = 1 slice completo (Handler + Validator + Endpoint num único task)
+- `GetAll` NÃO tem Validator — mencionar explicitamente no task
+- Cada task de slice lista os 3 arquivos que devem ser criados no campo `files`
+- Entity task deve incluir a linha `DbSet<{Entity}>` no `ApplicationDbContext`
+- Migration task é separada da entity task (pode rodar em paralelo com errors + tags)
+
+### Exemplos de tasks VSA
+
+```json
+{ "id": "T001", "title": "Criar Entity Book + registrar DbSet no ApplicationDbContext",
+  "category": "entity", "dependencies": [],  "estimatedMinutes": 20,
+  "files": ["Entities/Book.cs", "Database/ApplicationDbContext.cs"] }
+
+{ "id": "T002", "title": "Criar BookErrors (NotFound + outros factory methods)",
+  "category": "errors", "dependencies": ["T001"], "estimatedMinutes": 10,
+  "files": ["Features/BookFeature/BookErrors.cs"] }
+
+{ "id": "T003", "title": "Adicionar ApiTags.Books em Constants/ApiTags.cs",
+  "category": "tags", "dependencies": [], "estimatedMinutes": 5,
+  "files": ["Constants/ApiTags.cs"] }
+
+{ "id": "T004", "title": "Criar migration AddBook + aplicar ao banco",
+  "category": "migration", "dependencies": ["T001"], "estimatedMinutes": 10,
+  "files": ["Migrations/...AddBook.cs"] }
+
+{ "id": "T005", "title": "Implementar slice CreateBook (Handler + Validator + Endpoint)",
+  "category": "slice", "dependencies": ["T001", "T002", "T003", "T004"],
+  "estimatedMinutes": 45,
+  "files": [
+    "Features/BookFeature/CreateBook/CreateBookHandler.cs",
+    "Features/BookFeature/CreateBook/CreateBookValidator.cs",
+    "Features/BookFeature/CreateBook/CreateBookEndpoint.cs"
+  ] }
+
+{ "id": "T006", "title": "Implementar slice GetAllBooks (Handler + Endpoint, sem Validator)",
+  "category": "slice", "dependencies": ["T001", "T004"], "estimatedMinutes": 25,
+  "files": [
+    "Features/BookFeature/GetAllBooks/GetAllBooksHandler.cs",
+    "Features/BookFeature/GetAllBooks/GetAllBooksEndpoint.cs"
+  ] }
+```
+
+---
+
+## Padrão DDD — Mapeamento de Níveis para Categorias
+
+**Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
+
+### Categorias por nível de complexidade
+
+| Nível | Categorias de Tasks |
+|-------|---------------------|
+| **1 — CRUD** | `domain` (Entity simples) → `infrastructure` (Repository, EF Config) → `application` (Service CRUD) → `presentation` (API/Page) → `tests` |
+| **2 — Business Logic** | `domain` (AggregateRoot, ValueObjects, DomainEvents) → `infrastructure` (Repository, EF Config) → `application` (Commands, Queries, Handlers) → `presentation` (API/Page) → `tests` |
+| **3 — Bounded Context** | `domain-bc` (BC setup, Aggregates, Events) → `infrastructure` (BC repositories, EF) → `application` (Commands, Queries, Integration handlers) → `presentation` → `tests` |
+
+**Nível 1:** Nenhuma task adicional obrigatória — apenas o padrão CRUD nas categorias listadas.
+
+### Tasks adicionais obrigatórias por nível
+
+**Nível 2 apenas:**
+- `T{N}: Implementar AggregateRoot {EntityName} com factory method e invariants` (domain)
+- `T{N}: Implementar ValueObjects: {lista do Aggregate Blueprint}` (domain)
+- `T{N}: Implementar DomainEvents: {lista do Aggregate Blueprint}` (domain)
+- `T{N}: Implementar Command Handlers com MediatR` (application)
+- `T{N}: Implementar Query Handlers com read models` (application)
+
+**Nível 3 apenas (além do Nível 2):**
+- `T{N}: Configurar namespace/pasta do Bounded Context {BoundedContext}` (infrastructure)
+- `T{N}: Implementar Integration Events para comunicação cross-BC` (domain-bc)
+- `T{N}: Implementar handlers de Integration Events` (application)
+
+---
+
+## Estrutura de Task (formato JSON)
+
+```json
+{
+  "id": "T001",
+  "title": "Criar Entity {Nome}",
+  "description": "Implementar entity {Nome} com propriedades X, Y, Z seguindo padrões EF Core",
+  "category": "domain",
+  "dependencies": [],
+  "estimatedMinutes": 30,
+  "status": "pending",
+  "specSections": ["## Domain Model", "## Business Rules"],
+  "contractInterfaces": ["I{Nome}Repository"],
+  "files": [
+    "Domain/Entities/{Nome}.cs",
+    "Infrastructure/Data/Configurations/{Nome}Configuration.cs"
+  ]
+}
+```
+
+## Categorias de Tasks (DDD)
+
+| Categoria | Descrição | Exemplos |
+|-----------|-----------|----------|
+| **domain** | Entities, Value Objects, Enums | Entity, DomainException |
+| **application** | Services, DTOs, Interfaces | Service, Validator, Mapper |
+| **infrastructure** | DbContext, Repositories, External APIs | EF Config, Repository impl |
+| **presentation** | Controllers, Pages, Components | API endpoint, Blazor page |
+| **tests** | Unit tests, Integration tests | Service tests, API tests |
+| **infra** | Bicep, Migrations, Scripts | Azure resources, DB migration |
+| **docs** | README, API docs, Swagger | OpenAPI spec, README update |
+
+## Ordem de Implementação Bottom-Up
+
+```
+1. Domain (Entities, Enums, Value Objects)
+   ↓
+2. Infrastructure (Repositories, DbContext configs)
+   ↓
+3. Application (Services, DTOs, Business logic)
+   ↓
+4. Presentation (Controllers, Pages, Components)
+   ↓
+5. Tests (Unit → Integration)
+   ↓
+6. Infra (Bicep, Migrations, Deploy scripts)
+   ↓
+7. Docs (README, Swagger, Comments)
+```

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

@@ -4,7 +4,7 @@ description: MORPH-SPEC Phase 1.5 (UI/UX). Creates design-system.md, mockups.md,
 argument-hint: "[feature-name]"
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.8.12"
+cliVersion: "4.8.15"
 ---
 
 # MORPH UI/UX Design - FASE 1.5
@@ -87,6 +87,26 @@ npx morph-spec state get $ARGUMENTS
 
 Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e continue para FASE 2 (Design).
 
+### Passo 1.5: Design Thinking — Direção Estética
+
+> **Ref:** `framework/standards/frontend/design-system/aesthetic-direction.md`
+
+**ANTES de coletar requisitos técnicos**, definir a direção visual com 4 perguntas:
+
+1. **Purpose**: Que problema resolve? Quem usa? Qual o contexto profissional?
+2. **Tone**: Qual direção? (Minimal Refined / Editorial / Soft Professional / Industrial / Modern Luxury)
+3. **Differentiation**: Qual o 1 elemento memorável desta interface?
+4. **Constraints**: Framework, performance budget, brand guidelines existentes
+
+**CRITICAL:** Commitar à direção ANTES das specs técnicas. Documentar em `ui-design-system.md`
+na seção `## Aesthetic Direction` (template disponível no standard acima).
+
+**Anti-padrões a evitar:**
+- ❌ Gradiente roxo em fundo branco (AI cliché)
+- ❌ Inter/Roboto como fonte de display
+- ❌ Grid 3-colunas de cards sem diferencial visual
+- ❌ Paleta de 5 cores de peso igual (sem dominant + accent)
+
 ### Passo 2: Coletar Input do Usuário
 
 **SEMPRE perguntar ao usuário PRIMEIRO:**
@@ -128,6 +148,8 @@ Crie os seguintes arquivos em `.morph/features/$ARGUMENTS/`:
 
 **Se não existe:**
 - Crie design system feature-level completo com:
+  - **Seção `## Aesthetic Direction`** (usar template de `aesthetic-direction.md`):
+    direção, font pair, color philosophy, motion intent, composition approach
   - Paleta de cores (primary, secondary, accent, semantic)
   - Tipografia (heading scales, body text, code)
   - Spacing e layout (grid, margins, paddings)
@@ -161,8 +183,11 @@ Fluxos de usuário completos:
 
 **⏸️ PAUSE - Antes de prosseguir para acessibilidade:**
 
+- [ ] Direção estética definida e documentada em `ui-design-system.md`?
+- [ ] Font pair especificado (não apenas Inter/Roboto para display)?
+- [ ] Color philosophy: dominant + accent + rationale documentados?
 - [ ] Design system definido (project-level ou feature-level)?
-- [ ] Wireframes cobrem TODOS os estados (loading, error, empty, success)?
+- [ ] Wireframes cobrem todos os estados (loading, error, empty, success)?
 - [ ] Componentes especificados com props reais da biblioteca UI escolhida?
 - [ ] Fluxos de usuário completos com edge cases?
 - [ ] Biblioteca UI escolhida documentada como ADR em `decisions.md`?
@@ -190,7 +215,6 @@ Documente nos arquivos UI:
 ### Passo 6: Atualizar State
 
 ```bash
-npx morph-spec state set $ARGUMENTS phase uiux-design
 npx morph-spec state mark-output $ARGUMENTS ui-design-system
 npx morph-spec state mark-output $ARGUMENTS ui-mockups
 npx morph-spec state mark-output $ARGUMENTS ui-components
@@ -211,6 +235,21 @@ npx morph-spec state mark-output $ARGUMENTS ui-flows
 - `.morph/features/$ARGUMENTS/2-ui/flows.md`
 - `.morph/features/$ARGUMENTS/1-design/decisions.md` (atualizado com ADR UI library)
 
+### Passo 7: Validar Design com Frontend Review
+
+Após gerar todos os 4 outputs de UI e atualizar o state (Passo 6):
+
+```bash
+/frontend-review $ARGUMENTS
+```
+
+O skill valida: contraste WCAG dos tokens, existência de todos os outputs, acessibilidade
+estática no design, e gera screenshots dos mockups se dev server disponível.
+
+**🚫 Se o frontend-review bloquear**, corrija os issues antes de apresentar ao usuário.
+
+---
+
 ## PAUSA OBRIGATÓRIA
 
 Apresente ao usuário 3 ações sugeridas:

package/framework/squad-templates/backend-only.json

@@ -30,5 +30,18 @@
     "ef-modeler": "Entity models, DbContext, migrations",
     "api-designer": "Controllers, DTOs, Swagger docs"
   },
-  "estimatedParallelGain": "2-3x throughput vs sequential"
+  "estimatedParallelGain": "2-3x throughput vs sequential",
+  "agent_team": {
+    "team_name_pattern": "{feature}-backend",
+    "lead": "standards-architect",
+    "teammates": [
+      {
+        "id": "dotnet-senior",
+        "spawn_context": "standards/coding.md, standards/architecture/, contracts.cs, spec.md",
+        "task_scope": "backend tasks (domain logic, application services, EF Core, API endpoints, DTOs)"
+      }
+    ],
+    "coordination_notes": "Single-domain squad — Agent Teams not required. Use subagents for parallelization.",
+    "quality_gate": "Require plan approval before implementation. Only approve plans that match contracts.cs."
+  }
 }

package/framework/squad-templates/frontend-only.json

@@ -30,5 +30,18 @@
     "blazor-builder": ".razor components, code-behind, state management",
     "css-specialist": "CSS modules, design system implementation, responsive layout"
   },
-  "estimatedParallelGain": "2x throughput vs sequential"
+  "estimatedParallelGain": "2x throughput vs sequential",
+  "agent_team": {
+    "team_name_pattern": "{feature}-frontend",
+    "lead": "standards-architect",
+    "teammates": [
+      {
+        "id": "ui-designer",
+        "spawn_context": "standards/css-architecture.md, standards/css-design-system.md, design-system.md, spec.md",
+        "task_scope": "frontend tasks (Blazor components, CSS, design system implementation, responsive layout)"
+      }
+    ],
+    "coordination_notes": "Single-domain squad — Agent Teams not required. Use subagents for parallelization.",
+    "quality_gate": "Require plan approval before implementation. Only approve plans that match spec.md and design-system.md."
+  }
 }

package/framework/squad-templates/full-stack.json

@@ -3,7 +3,7 @@
   "name": "Full Stack Squad",
   "description": "Full-stack feature squad: backend API + Blazor frontend + Azure infra",
   "parallel": true,
-  "coordination": "thread-orchestrator",
+  "coordination": "standards-architect",
   "waitForAll": true,
   "agents": [
     {
@@ -24,12 +24,6 @@
       "domain": "infrastructure",
       "standards": ["azure.md", "bicep.md"]
     },
-    {
-      "id": "thread-orchestrator",
-      "role": "Parallel Coordinator",
-      "domain": "developer-experience",
-      "standards": []
-    },
     {
       "id": "context-optimizer",
       "role": "Context Manager",
@@ -48,5 +42,28 @@
     "frontend": "Blazor components, pages, CSS",
     "infrastructure": "Bicep templates, deployment scripts"
   },
-  "estimatedParallelGain": "3-5x throughput vs sequential"
+  "estimatedParallelGain": "3-5x throughput vs sequential",
+  "agent_team": {
+    "team_name_pattern": "{feature}-full-stack",
+    "lead": "standards-architect",
+    "teammates": [
+      {
+        "id": "dotnet-senior",
+        "spawn_context": "standards/coding.md, standards/architecture/, contracts.cs, spec.md",
+        "task_scope": "backend tasks (domain logic, EF Core, API endpoints, DTOs)"
+      },
+      {
+        "id": "blazor-builder",
+        "spawn_context": "standards/coding.md, standards/blazor-components.md, design-system.md, spec.md",
+        "task_scope": "frontend tasks (Blazor pages, components, CSS, state management)"
+      },
+      {
+        "id": "bicep-architect",
+        "spawn_context": "standards/azure.md, standards/bicep.md, spec.md",
+        "task_scope": "infrastructure tasks (Bicep templates, App Service, Azure resources)"
+      }
+    ],
+    "coordination_notes": "Backend deve sinalizar quando contracts.cs/DTOs estiverem estáveis antes do frontend prosseguir com chamadas de API. Infrastructure pode executar em paralelo com backend/frontend.",
+    "quality_gate": "Require plan approval before each teammate implements. Only approve plans that match contracts.cs and spec.md."
+  }
 }