@polymorphism-tech/morph-spec 2.2.0 → 2.4.0

package/content/.claude/skills/workflows/phase-tasks.md

@@ -0,0 +1,164 @@
+# 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
+
+## Workflow
+
+### Passo 1: Analisar Spec
+
+Leia `.morph/project/outputs/{feature}/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/project/outputs/{feature}/tasks.json` 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 {feature-name} phase tasks
+npx morph-spec state set {feature-name} tasks.total {N}
+npx morph-spec state mark-output {feature-name} tasks
+```
+
+## Outputs Gerados
+
+- `.morph/project/outputs/{feature}/tasks.json` - 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
+
+---
+
+Após aprovação: "Planejamento completo! Execute `/morph-apply {feature}` para iniciar implementação."

package/content/.claude/{commands/morph-uiux.md → skills/workflows/phase-uiux.md}

@@ -1,12 +1,8 @@
 # MORPH UI/UX Design - FASE 1.5
 
-Fase obrigatória para features com front-end. Coleta requisitos de UI/UX, gera wireframes, specs de componentes e fluxos de usuário.
+> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
 
-## Uso
-
-```
-/morph-uiux {feature-name}
-```
+Fase condicional para features com front-end. Coleta requisitos de UI/UX, gera wireframes, specs de componentes e fluxos de usuário.
 
 ## Pré-requisitos
 
@@ -21,10 +17,10 @@ Fase obrigatória para features com front-end. Coleta requisitos de UI/UX, gera
 Verifique se agentes ativos incluem `uiux-designer`:
 
 ```bash
-node bin/state-manager.js get {feature-name}
+npx morph-spec state get {feature-name}
 ```
 
-Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e vá para `/morph-design`.
+Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e continue para FASE 2 (Design).
 
 ### Passo 2: Coletar Input do Usuário
 
@@ -51,18 +47,7 @@ Escolha entre **Fluent UI Blazor** (recomendado para AI-first) ou **MudBlazor**
 - Fluent UI: Para dashboards, forms simples, AI components, Microsoft design language
 - MudBlazor: Para data grids avançadas, charts complexos, material design
 
-**Documente a decisão:**
-```bash
-# Adicionar ADR em decisions.md
-echo "## ADR: UI Library Choice
-
-Decision: [Fluent UI / MudBlazor]
-
-Rationale:
-- {Justificativa baseada nos requisitos}
-
-Date: $(date +%Y-%m-%d)" >> .morph/project/outputs/{feature}/decisions.md
-```
+**Documente a decisão em `decisions.md`.**
 
 ### Passo 4: Gerar Deliverables
 
@@ -84,21 +69,6 @@ Wireframes ASCII + descrições:
 - Responsividade (desktop, tablet, mobile)
 - Estados (loading, error, empty, success)
 
-Exemplo:
-```
-┌─────────────────────────────────────────┐
-│  Header                   [🔔] [👤]     │
-├─────────────────────────────────────────┤
-│ ┌─────────┐                             │
-│ │ Sidebar │  Main Content Area          │
-│ │  Menu   │  ┌─────────────────────┐   │
-│ │         │  │ Dashboard Card      │   │
-│ │ • Home  │  │ - Chart            │   │
-│ │ • Data  │  │ - Metrics          │   │
-│ └─────────┘  └─────────────────────┘   │
-└─────────────────────────────────────────┘
-```
-
 #### 4.3. `ui-components.md`
 
 Specs técnicas de componentes Fluent UI/MudBlazor:
@@ -107,25 +77,6 @@ Specs técnicas de componentes Fluent UI/MudBlazor:
 - Eventos e bindings
 - Validações e estados
 
-Exemplo:
-```markdown
-### DashboardCard Component
-
-**Library:** FluentCard
-**Props:**
-- Title: string
-- Subtitle: string (optional)
-- Loading: bool
-
-**Events:**
-- OnRefresh: EventCallback
-
-**Variants:**
-- Default (outline)
-- Filled (accent color)
-- Error (danger color)
-```
-
 #### 4.4. `ui-flows.md`
 
 Fluxos de usuário completos:
@@ -134,22 +85,6 @@ Fluxos de usuário completos:
 - Edge cases (o que acontece se...?)
 - Validações e feedback
 
-Exemplo:
-```
-## Fluxo: Adicionar Item
-
-1. User clica "Adicionar Item"
-2. Modal abre com form
-   - Loading: Skeleton placeholders
-   - Error: Toast notification
-3. User preenche campos
-   - Validação em tempo real
-   - Campos required marcados com *
-4. User clica "Salvar"
-   - Success: Modal fecha + toast "Item adicionado"
-   - Error: Modal permanece + mensagem de erro destacada
-```
-
 ### Passo 5: Validar Acessibilidade e Responsividade
 
 Documente nos arquivos UI:
@@ -165,14 +100,11 @@ Documente nos arquivos UI:
 ### Passo 6: Atualizar State
 
 ```bash
-# Marcar fase como uiux-design
-node bin/state-manager.js set {feature-name} phase uiux-design
-
-# Marcar outputs criados
-node bin/state-manager.js mark-output {feature-name} ui-design-system
-node bin/state-manager.js mark-output {feature-name} ui-mockups
-node bin/state-manager.js mark-output {feature-name} ui-components
-node bin/state-manager.js mark-output {feature-name} ui-flows
+npx morph-spec state set {feature-name} phase uiux-design
+npx morph-spec state mark-output {feature-name} ui-design-system
+npx morph-spec state mark-output {feature-name} ui-mockups
+npx morph-spec state mark-output {feature-name} ui-components
+npx morph-spec state mark-output {feature-name} ui-flows
 ```
 
 ## Outputs Gerados
@@ -183,18 +115,13 @@ node bin/state-manager.js mark-output {feature-name} ui-flows
 - `.morph/project/outputs/{feature}/ui-flows.md`
 - `.morph/project/outputs/{feature}/decisions.md` (atualizado com ADR UI library)
 
-## ⛔ PAUSA OBRIGATÓRIA
+## PAUSA OBRIGATÓRIA
 
 Apresente ao usuário 3 ações sugeridas:
 
-1. ✅ **Aprovar UI/UX e prosseguir para design técnico**
-   Continuar para `/morph-design` (FASE 2)
-
-2. 🎨 **Ajustar wireframes/componentes de telas específicas**
-   Revisar mockups ou adicionar mais detalhes
-
-3. 🔄 **Revisar biblioteca UI escolhida (Fluent UI ↔ MudBlazor)**
-   Mudar decisão se justificado
+1. **Aprovar UI/UX e prosseguir para design técnico**
+2. **Ajustar wireframes/componentes de telas específicas**
+3. **Revisar biblioteca UI escolhida (Fluent UI / MudBlazor)**
 
 ## Critérios de Avanço
 
@@ -208,4 +135,4 @@ Apresente ao usuário 3 ações sugeridas:
 
 ---
 
-**Feature:** $ARGUMENTS
+Continuar automaticamente para FASE 2 (Design) após aprovação.

package/content/.morph/.morphversion

@@ -1,5 +1,5 @@
-{
-  "morphVersion": "1.0.4",
-  "installedAt": "2025-11-28T00:00:00.000Z",
-  "cliVersion": "1.0.4"
-}
+{
+  "morphVersion": "1.0.4",
+  "installedAt": "2025-11-28T00:00:00.000Z",
+  "cliVersion": "1.0.4"
+}

package/content/.morph/archive/.gitkeep

@@ -1,25 +1,25 @@
-# Features Arquivadas
-
-Esta pasta contém o histórico de features CONCLUÍDAS.
-
-## Estrutura
-
-```
-archive/
-└── {feature-name}/
-    ├── proposal.md    # Proposta original
-    ├── spec.md        # Especificação final
-    ├── tasks.md       # Tasks completadas
-    ├── contracts.cs   # Contracts finais
-    ├── decisions.md   # ADRs
-    └── recap.md       # Resumo e métricas
-```
-
-## Por que arquivar?
-
-1. Manter histórico de decisões
-2. Referência para features similares
-3. Métricas de produtividade
-4. Lições aprendidas
-
-*Gerado pelo MORPH Framework*
+# Features Arquivadas
+
+Esta pasta contém o histórico de features CONCLUÍDAS.
+
+## Estrutura
+
+```
+archive/
+└── {feature-name}/
+    ├── proposal.md    # Proposta original
+    ├── spec.md        # Especificação final
+    ├── tasks.md       # Tasks completadas
+    ├── contracts.cs   # Contracts finais
+    ├── decisions.md   # ADRs
+    └── recap.md       # Resumo e métricas
+```
+
+## Por que arquivar?
+
+1. Manter histórico de decisões
+2. Referência para features similares
+3. Métricas de produtividade
+4. Lições aprendidas
+
+*Gerado pelo MORPH Framework*