@polymorphism-tech/morph-spec 4.11.1 → 4.13.0

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

@@ -4,7 +4,7 @@ description: MORPH-SPEC Phase 4 (Tasks). Breaks approved spec into bottom-up ord
 argument-hint: "[feature-name]"
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
-cliVersion: "4.11.1"
+cliVersion: "4.13.0"
 ---
 
 # MORPH Tasks — Phase 4
@@ -15,9 +15,9 @@ Break the approved specification into executable tasks, define execution order,
 
 ## Prerequisites
 
-- [ ] Phase 3 (Clarify) completed
-- [ ] `spec.md` updated with clarifications
-- [ ] All edge cases documented
+- [ ] Design phase completed and approved
+- [ ] `spec.md` exists and approved
+- [ ] Plan phase completed
 
 ## Recommended Tools
 
@@ -42,7 +42,7 @@ Break the approved specification into executable tasks, define execution order,
 - Task agent to break down a simple single-domain spec (do it directly)
 - Creating tasks without reading all design outputs first
 - **(VSA)** Creating separate tasks for Handler, Validator, and Endpoint — one slice = one task
-- **(VSA)** Using DDD categories (`domain`, `application`, `infrastructure`) in VSA projects — use VSA categories: `entity`, `errors`, `tags`, `migration`, `slice`, `frontend`, `tests`
+- **(VSA)** Using generic layer categories (`domain`, `application`, `infrastructure`) in VSA projects — use VSA categories: `entity`, `errors`, `tags`, `migration`, `slice`, `frontend`, `tests`
 - **(VSA)** Creating a "Implement Service layer" task — there is no Service layer in VSA
 - Using vague effort labels ("Low", "Medium", "S/M") — always use specific minute estimates
 - Using non-standard task IDs (TASK-001, T01) — always use **T001** format (T + 3 digits)
@@ -61,9 +61,8 @@ Check the `"phase"` field:
 
 **If `"phase": "tasks"`** → correct phase, proceed.
 
-**If `"phase": "clarify"`** → run in sequence:
-1. `morph-spec state mark-output $ARGUMENTS clarifications`
-2. `morph-spec phase advance $ARGUMENTS` (→ tasks)
+**If `"phase": "plan"`** → run:
+1. `morph-spec phase advance $ARGUMENTS` (→ tasks)
 
 **Any other value** → STOP — inconsistent state, report to user.
 
@@ -83,10 +82,10 @@ Check the `"phase"` field:
 
 ```
 # Single parallel call, not sequential:
-Read: .morph/features/{feature}/1-design/spec.md
-    + Read: .morph/features/{feature}/1-design/contracts.cs  (or contracts.ts for TypeScript projects)
-    + Read: .morph/features/{feature}/1-design/decisions.md
-    + Read: .morph/features/{feature}/1-design/schema-analysis.md  (if exists)
+Read: .morph/features/{feature}/2-design/spec.md
+    + Read: .morph/features/{feature}/2-design/contracts.cs  (or contracts.ts for TypeScript projects)
+    + Read: .morph/features/{feature}/2-design/decisions.md
+    + Read: .morph/features/{feature}/2-design/schema-analysis.md  (if exists)
     + Read: .morph/config/config.json                               (→ architecture.style)
 ```
 
@@ -116,25 +115,25 @@ morph-spec approval-status $ARGUMENTS
 
 ### Step 0: Detect Architecture Style
 
-Before anything else, determine if the project is VSA or DDD:
+Before anything else, determine the architecture style:
 
 ```bash
 cat .morph/config/config.json | grep -A3 '"architecture"'
 ```
 
-**If `config.architecture.style === "vertical-slice"`** → follow **Step 0.5 (VSA)** and skip DDD path.
-**Otherwise** → follow **Step 0.6 (DDD)** below.
+**If `config.architecture.style === "vertical-slice"`** → follow **Step 0.5 (VSA)**.
+**Otherwise** → proceed to **Step 1 (Analyze Spec)** with standard layer-based task breakdown.
 
 ---
 
 ### Step 0.5: VSA Task Plan
 
-> For VSA task patterns and DDD-level mappings, see `references/task-planning-patterns.md`
+> For VSA task patterns, see `references/task-planning-patterns.md`
 
 Read the `## Architecture Style: Vertical Slice` section from spec.md for the **VSA Blueprint**:
 
 ```bash
-grep -A30 "## Architecture Style" ".morph/features/$ARGUMENTS/1-design/spec.md"
+grep -A30 "## Architecture Style" ".morph/features/$ARGUMENTS/2-design/spec.md"
 ```
 
 Create one task per slice following this order: entity → errors → tags → migration → CRUD slices → custom slices → frontend → tests. Each slice = Handler + Validator + Endpoint in a **single task**. `GetAll` operations do NOT have a Validator (no input parameters to validate).
@@ -145,30 +144,13 @@ Use VSA-specific categories: `entity`, `errors`, `tags`, `migration`, `slice`, `
 
 ---
 
-### Step 0.6: Read Domain Level — DDD
-
-Read the `## Domain Complexity` section from spec.md:
-
-```bash
-grep -A15 "## Domain Complexity" ".morph/features/$ARGUMENTS/1-design/spec.md"
-```
-
-> If the section doesn't exist, assume **Level 1 (CRUD)**.
-
-Use the level to constrain categories:
-- **Level 1**: domain → infrastructure → application → presentation → tests
-- **Level 2**: adds AggregateRoot, ValueObjects, DomainEvents, CQRS handlers
-- **Level 3**: adds BC setup, Integration Events
-
-See `references/task-planning-patterns.md` for the complete table.
-
 ---
 
 ### Step 1: Analyze Spec
 
 > **VSA:** If coming from Step 0.5, the task breakdown was already defined — use the generated examples as a base and skip to Step 3 (Dependencies).
 
-Read `.morph/features/$ARGUMENTS/1-design/spec.md` and identify:
+Read `.morph/features/$ARGUMENTS/2-design/spec.md` and identify:
 
 1. **Functional requirements** (FR001, FR002, ...)
 2. **Technical components** (Entities, Services/Slices, Controllers/Endpoints, Pages)
@@ -274,7 +256,7 @@ Use `AskUserQuestion` to capture explicit approval before advancing. This gate p
 
 - [x] `tasks.md` created with all tasks
 - [x] Tasks use T### format (T001, T002, ...) consistently
-- [x] Tasks categorized correctly (DDD layers or VSA categories)
+- [x] Tasks categorized correctly (VSA categories or standard layers)
 - [x] Dependencies mapped
 - [x] Checkpoints defined (every 3 tasks)
 - [x] Effort estimated in minutes per task
@@ -298,10 +280,10 @@ Use `AskUserQuestion` to capture explicit approval before advancing. This gate p
 
 ## Phase Outputs
 
-<!-- morph-outputs:tasks -->
-| Output | Caminho |
-|--------|---------|
-| `tasks` | `.morph/features/{feature}/4-tasks/tasks.md` |
+<!-- morph-outputs:tasks -->
+| Output | Caminho |
+|--------|---------|
+| `tasks` | `.morph/features/{feature}/4-tasks/tasks.md` |
 <!-- /morph-outputs -->
 
 ---

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

@@ -93,8 +93,6 @@ T0NN: Tests
 
 ## 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 |

package/framework/skills/level-1-workflows/morph-phase-tasks/references/tasks-example.md

@@ -81,7 +81,7 @@ Add `ProcessingJob` to `AppDbContext`, configure via Fluent API (column lengths,
 - **Type:** Infrastructure
 - **Priority:** 1
 - **Estimate:** 45min
-- **Assigned:** azure-architect
+- **Assigned:** infra-architect
 - **Dependencies:** None
 
 **Description:**
@@ -154,11 +154,11 @@ Create two endpoints per spec.md:
 - **Type:** UI
 - **Priority:** 2
 - **Estimate:** 1h
-- **Assigned:** blazor-builder
+- **Assigned:** nextjs-expert
 - **Dependencies:** T007
 
 **Description:**
-Blazor Server page at `/upload`. File input with client-side validation (type + size before submit). Loading state during upload. Redirect to `/processing/{jobId}` on success. Error message display per spec wireframe.
+Frontend page at `/upload`. File input with client-side validation (type + size before submit). Loading state during upload. Redirect to `/processing/{jobId}` on success. Error message display per spec wireframe.
 
 **Deliverables:**
 - [ ] Create: `src/Web/Pages/Upload.razor`
@@ -170,11 +170,11 @@ Blazor Server page at `/upload`. File input with client-side validation (type +
 - **Type:** UI
 - **Priority:** 3
 - **Estimate:** 1h
-- **Assigned:** blazor-builder
+- **Assigned:** nextjs-expert
 - **Dependencies:** T007
 
 **Description:**
-Blazor Server page at `/processing/{jobId}`. Polls `GET /api/status/{jobId}` every 5 seconds using `PeriodicTimer`. Shows status label + progress indicator. "Download" button when Completed. "Retry" suggestion when Failed. Stops polling on terminal state.
+Frontend page at `/processing/{jobId}`. Polls `GET /api/status/{jobId}` every 5 seconds using `PeriodicTimer`. Shows status label + progress indicator. "Download" button when Completed. "Retry" suggestion when Failed. Stops polling on terminal state.
 
 **Deliverables:**
 - [ ] Create: `src/Web/Pages/ProcessingStatus.razor`