@polymorphism-tech/morph-spec 4.7.2 → 4.8.1

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

@@ -1,284 +1,285 @@
----
-name: phase-tasks
-description: MORPH-SPEC Phase 4 (Tasks). Breaks approved spec into bottom-up ordered implementation tasks (T001...TXXX) with dependencies, checkpoints every 3 tasks, and effort estimates, producing tasks.md. Use after design and clarification phases to create a structured implementation plan before coding starts.
-argument-hint: "[feature-name]"
-disable-model-invocation: true
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
----
-
-# MORPH Tasks - FASE 4
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Quebre a especificação em tasks executáveis, defina ordem de execução e estabeleça checkpoints.
-
-## Pré-requisitos
-
-- [ ] FASE 3 (Clarify) concluída
-- [ ] `spec.md` atualizado com clarificações
-- [ ] Todos os edge cases documentados
-
-## 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/tasks-example.md` — filled-in tasks.md showing expected granularity and format.
-> **Script:** `scripts/validate-tasks.mjs` — validates tasks.md structure, T### IDs, and required fields.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Ler spec + contracts + decisions | **Read** todos os outputs | — |
-| Analisar complexidade de implementação | **Grep** padrões no código existente | — |
-| Contar padrões similares existentes | **Glob** `**/Services/**/*.cs` | — |
-| Consultar padrões de implementação | **Context7 MCP** `query_docs()` | **WebSearch** |
-| Criar issues no GitHub a partir das tasks | **GitHub MCP** `create_issue()` | **Bash** `gh issue create ...` |
-| Renderizar template de tasks | **Bash** `npx morph-spec template render docs/tasks ...` | — |
-| Atualizar state com total de tasks | **Bash** `npx morph-spec state set ... tasks.total N` | — |
-
-**MCPs desta fase:** Context7 (estimar complexidade), GitHub (criar issues).
-
-**Anti-padrões:**
-- ❌ Task agent para quebrar spec simples (faça diretamente)
-- ✅ Task agent para specs complexos com 50+ requisitos (análise legítima multi-step)
-- ❌ Criar tasks.json sem ler todos os outputs primeiro
-
----
-
-## Workflow
-
-### CHECKPOINT DE ENTRADA: Verificar Pré-requisitos
-
-**⏸️ PAUSE - Antes de iniciar o breakdown de tasks:**
-
-- [ ] `spec.md` existe e foi aprovado pelo usuário?
-- [ ] `contracts.cs` existe e corresponde ao schema real?
-- [ ] `schema-analysis.md` foi validado (se aplicável)?
-- [ ] `decisions.md` contém ADRs para todas as escolhas críticas?
-- [ ] Design gate (`morph-spec approve $ARGUMENTS design`) foi aprovado?
-- [ ] Clarificações (FASE 3) foram resolvidas e spec atualizado?
-
-**❌ Se alguma checkbox NÃO estiver marcada:**
-→ Voltar para a fase correspondente e resolver
-
-**✅ Se TODAS as checkboxes estiverem marcadas:**
-→ Prosseguir para análise e breakdown
-
-```bash
-# Verificar estado atual:
-npx morph-spec state get $ARGUMENTS
-# Verificar se design foi aprovado:
-npx morph-spec approval get $ARGUMENTS design
-```
-
----
-
-### Passo 0: Ler Nível de Domínio
-
-**Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
-
-Antes de quebrar tasks, 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` |
-
-**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)
-
----
-
-### Passo 1: Analisar Spec
-
-Leia `.morph/features/$ARGUMENTS/1-design/spec.md` e identifique:
-
-1. **Requisitos funcionais** (FR001, FR002, ...)
-2. **Componentes técnicos** (Entities, Services, Controllers, Pages)
-3. **Infraestrutura** (Bicep, migrations, configs)
-4. **Testes** (Unit tests, integration tests)
-
-### 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"
-  ]
-}
-```
-
-#### 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)
-```
-
-### Passo 3: Definir Dependências
-
-Para cada task, especifique dependências:
-
-```json
-{
-  "id": "T005",
-  "title": "Criar {Nome}Service",
-  "dependencies": ["T001", "T002"],
-  "status": "pending"
-}
-```
-
-**Regra:** Task só pode ser executada quando todas as dependências estão `completed`.
-
-### Passo 4: Estabelecer Checkpoints
-
-Defina checkpoints a cada **3 tasks** ou **marcos significativos**:
-
-```json
-{
-  "id": "CHECKPOINT_001",
-  "title": "Domain Layer Completo",
-  "afterTasks": ["T001", "T002", "T003"],
-  "validations": [
-    "Todas as entities criadas",
-    "Migrations aplicadas",
-    "Testes de domain passando"
-  ]
-}
-```
-
-### Passo 5: Estimar Esforço
-
-Para cada task, estime tempo em minutos:
-
-| Complexidade | Tempo Estimado |
-|--------------|----------------|
-| Trivial (CRUD básico) | 15-30 min |
-| Simples (Service, Controller) | 30-60 min |
-| Média (Business logic, validações) | 60-120 min |
-| Complexa (Integrações, AI) | 120-240 min |
-
-### Passo 6: Gerar `tasks.json`
-
-Crie `.morph/features/$ARGUMENTS/3-tasks/tasks.md` com a estrutura completa de tasks, checkpoints e estimativas.
-
-### Passo 7: Incluir Tasks de IaC (se necessário)
-
-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
-```
-
-## Outputs Gerados
-
-- `.morph/features/$ARGUMENTS/3-tasks/tasks.md` - Breakdown completo de tasks
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar breakdown e iniciar implementação**
-2. **Repriorizar tasks** - Mudar ordem de execução
-3. **Adicionar/remover tasks** - Ajustar escopo
-
-## Critérios de Avanço
-
-- [x] `tasks.json` criado com todas as tasks
-- [x] Tasks categorizadas corretamente
-- [x] Dependências mapeadas
-- [x] Checkpoints definidos (a cada 3 tasks)
-- [x] Esforço estimado por task
-- [x] Ordem de execução clara
-- [x] Tasks de IaC incluídas (se aplicável)
-- [x] State atualizado com total de tasks
-- [x] Usuário aprovou breakdown
-
----
-
-## Integração com Superpowers
-
-> Disponível quando o plugin `superpowers` está instalado.
-
-| Skill | Quando Usar | Invocação |
-|-------|-------------|-----------|
-| `writing-plans` | Após breakdown de tasks, para planejar sequência de implementação | `Skill(superpowers:writing-plans)` |
-| `executing-plans` | Para executar o plano de tasks em sessão separada | `Skill(superpowers:executing-plans)` |
-
----
-
-## Outputs desta Fase
-
-<!-- morph:outputs:tasks -->
-| Output | Caminho |
-|--------|---------|
-| `tasks` | `.morph/features/{feature}/3-tasks/tasks.md` |
-<!-- /morph:outputs -->
-
----
-
+---
+name: phase-tasks
+description: MORPH-SPEC Phase 4 (Tasks). Breaks approved spec into bottom-up ordered implementation tasks (T001...TXXX) with dependencies, checkpoints every 3 tasks, and effort estimates, producing tasks.md. Use after design and clarification phases to create a structured implementation plan before coding starts.
+argument-hint: "[feature-name]"
+disable-model-invocation: true
+user-invocable: false
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep
+cliVersion: "4.8.1"
+---
+
+# MORPH Tasks - FASE 4
+
+> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
+
+Quebre a especificação em tasks executáveis, defina ordem de execução e estabeleça checkpoints.
+
+## Pré-requisitos
+
+- [ ] FASE 3 (Clarify) concluída
+- [ ] `spec.md` atualizado com clarificações
+- [ ] Todos os edge cases documentados
+
+## 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/tasks-example.md` — filled-in tasks.md showing expected granularity and format.
+> **Script:** `scripts/validate-tasks.mjs` — validates tasks.md structure, T### IDs, and required fields.
+
+| Ação | Ferramenta | Alternativa |
+|------|------------|-------------|
+| Ler spec + contracts + decisions | **Read** todos os outputs | — |
+| Analisar complexidade de implementação | **Grep** padrões no código existente | — |
+| Contar padrões similares existentes | **Glob** `**/Services/**/*.cs` | — |
+| Consultar padrões de implementação | **Context7 MCP** `query_docs()` | **WebSearch** |
+| Criar issues no GitHub a partir das tasks | **GitHub MCP** `create_issue()` | **Bash** `gh issue create ...` |
+| Renderizar template de tasks | **Bash** `npx morph-spec template render docs/tasks ...` | — |
+| Atualizar state com total de tasks | **Bash** `npx morph-spec state set ... tasks.total N` | — |
+
+**MCPs desta fase:** Context7 (estimar complexidade), GitHub (criar issues).
+
+**Anti-padrões:**
+- ❌ Task agent para quebrar spec simples (faça diretamente)
+- ✅ Task agent para specs complexos com 50+ requisitos (análise legítima multi-step)
+- ❌ Criar tasks.json sem ler todos os outputs primeiro
+
+---
+
+## Workflow
+
+### CHECKPOINT DE ENTRADA: Verificar Pré-requisitos
+
+**⏸️ PAUSE - Antes de iniciar o breakdown de tasks:**
+
+- [ ] `spec.md` existe e foi aprovado pelo usuário?
+- [ ] `contracts.cs` existe e corresponde ao schema real?
+- [ ] `schema-analysis.md` foi validado (se aplicável)?
+- [ ] `decisions.md` contém ADRs para todas as escolhas críticas?
+- [ ] Design gate (`morph-spec approve $ARGUMENTS design`) foi aprovado?
+- [ ] Clarificações (FASE 3) foram resolvidas e spec atualizado?
+
+**❌ Se alguma checkbox NÃO estiver marcada:**
+→ Voltar para a fase correspondente e resolver
+
+**✅ Se TODAS as checkboxes estiverem marcadas:**
+→ Prosseguir para análise e breakdown
+
+```bash
+# Verificar estado atual:
+npx morph-spec state get $ARGUMENTS
+# Verificar se design foi aprovado:
+npx morph-spec approval get $ARGUMENTS design
+```
+
+---
+
+### Passo 0: Ler Nível de Domínio
+
+**Ref:** `framework/standards/architecture/ddd/complexity-levels.md`
+
+Antes de quebrar tasks, 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` |
+
+**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)
+
+---
+
+### Passo 1: Analisar Spec
+
+Leia `.morph/features/$ARGUMENTS/1-design/spec.md` e identifique:
+
+1. **Requisitos funcionais** (FR001, FR002, ...)
+2. **Componentes técnicos** (Entities, Services, Controllers, Pages)
+3. **Infraestrutura** (Bicep, migrations, configs)
+4. **Testes** (Unit tests, integration tests)
+
+### 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"
+  ]
+}
+```
+
+#### 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)
+```
+
+### Passo 3: Definir Dependências
+
+Para cada task, especifique dependências:
+
+```json
+{
+  "id": "T005",
+  "title": "Criar {Nome}Service",
+  "dependencies": ["T001", "T002"],
+  "status": "pending"
+}
+```
+
+**Regra:** Task só pode ser executada quando todas as dependências estão `completed`.
+
+### Passo 4: Estabelecer Checkpoints
+
+Defina checkpoints a cada **3 tasks** ou **marcos significativos**:
+
+```json
+{
+  "id": "CHECKPOINT_001",
+  "title": "Domain Layer Completo",
+  "afterTasks": ["T001", "T002", "T003"],
+  "validations": [
+    "Todas as entities criadas",
+    "Migrations aplicadas",
+    "Testes de domain passando"
+  ]
+}
+```
+
+### Passo 5: Estimar Esforço
+
+Para cada task, estime tempo em minutos:
+
+| Complexidade | Tempo Estimado |
+|--------------|----------------|
+| Trivial (CRUD básico) | 15-30 min |
+| Simples (Service, Controller) | 30-60 min |
+| Média (Business logic, validações) | 60-120 min |
+| Complexa (Integrações, AI) | 120-240 min |
+
+### Passo 6: Gerar `tasks.json`
+
+Crie `.morph/features/$ARGUMENTS/3-tasks/tasks.md` com a estrutura completa de tasks, checkpoints e estimativas.
+
+### Passo 7: Incluir Tasks de IaC (se necessário)
+
+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
+```
+
+## Outputs Gerados
+
+- `.morph/features/$ARGUMENTS/3-tasks/tasks.md` - Breakdown completo de tasks
+
+## PAUSA OBRIGATÓRIA
+
+Apresente ao usuário 3 ações sugeridas:
+
+1. **Aprovar breakdown e iniciar implementação**
+2. **Repriorizar tasks** - Mudar ordem de execução
+3. **Adicionar/remover tasks** - Ajustar escopo
+
+## Critérios de Avanço
+
+- [x] `tasks.json` criado com todas as tasks
+- [x] Tasks categorizadas corretamente
+- [x] Dependências mapeadas
+- [x] Checkpoints definidos (a cada 3 tasks)
+- [x] Esforço estimado por task
+- [x] Ordem de execução clara
+- [x] Tasks de IaC incluídas (se aplicável)
+- [x] State atualizado com total de tasks
+- [x] Usuário aprovou breakdown
+
+---
+
+## Integração com Superpowers
+
+> Disponível quando o plugin `superpowers` está instalado.
+
+| Skill | Quando Usar | Invocação |
+|-------|-------------|-----------|
+| `writing-plans` | Após breakdown de tasks, para planejar sequência de implementação | `Skill(superpowers:writing-plans)` |
+| `executing-plans` | Para executar o plano de tasks em sessão separada | `Skill(superpowers:executing-plans)` |
+
+---
+
+## Outputs desta Fase
+
+<!-- morph:outputs:tasks -->
+| Output | Caminho |
+|--------|---------|
+| `tasks` | `.morph/features/{feature}/3-tasks/tasks.md` |
+<!-- /morph:outputs -->
+
+---
+
 Após aprovação: "Planejamento completo! Execute `/morph-apply $ARGUMENTS` para iniciar implementação."