@polymorphism-tech/morph-spec 4.12.0 → 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.12.0"
+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`

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

@@ -1,13 +1,13 @@
 ---
 name: morph-phase-uiux
-description: MORPH-SPEC Phase 1.5 (UI/UX). Creates design-system.md, mockups.md, components.md, and flows.md using Playwright/Context7 MCPs. Use after setup for features with frontend UI components, pages, dashboards, forms, wizards, or visual interactions requiring design documentation.
+description: MORPH-SPEC Phase 2 (UI/UX). Creates design-system.md, mockups.md, components.md, and flows.md using Playwright/Context7 MCPs. Use after setup for features with frontend UI components, pages, dashboards, forms, wizards, or visual interactions requiring design documentation.
 argument-hint: "[feature-name]"
 user-invocable: false
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
-cliVersion: "4.12.0"
+cliVersion: "4.13.0"
 ---
 
-# MORPH UI/UX Design - Phase 1.5
+# MORPH UI/UX Design - Phase 2
 
 > INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
 
@@ -15,8 +15,8 @@ Conditional phase for features with front-end. Collects UI/UX requirements, gene
 
 ## Prerequisites
 
-- [ ] Phase 1 (Setup) completed
-- [ ] Feature has detected UI keywords (blazor, ui, component, page, dashboard, wizard, form, chart)
+- [ ] Proposal approved by the user
+- [ ] Feature has detected UI keywords (ui, component, page, dashboard, wizard, form, chart)
 - [ ] `ui-designer` agent activated
 
 ## Recommended Tools
@@ -29,7 +29,7 @@ Conditional phase for features with front-end. Collects UI/UX requirements, gene
 | Check existing design system | **Read** `.morph/context/design-system.md` | — |
 | Read user screenshots | **Read** (image file) | — |
 | Search for existing CSS variables | **Grep** `--root:` in `*.css,*.scss` | — |
-| Find existing components | **Glob** `**/Components/**/*.razor` or `**/components/**/*.tsx` | — |
+| Find existing components | **Glob** `**/components/**/*.tsx` | — |
 | UI component documentation | **Context7 MCP** `query_docs({ libraryId, query })` | **WebSearch** + **WebFetch** |
 | Preview existing page | **Playwright MCP** `browser_navigate()` + `browser_take_screenshot()` | **WebFetch** URL |
 | Generate visual mockup | **Playwright MCP** `browser_navigate()` + `browser_resize()` + `browser_take_screenshot()` | HTML file + manual screenshot |
@@ -42,13 +42,11 @@ Conditional phase for features with front-end. Collects UI/UX requirements, gene
 | Auto-detect dev server | **Glob** `next.config.*`, `vite.config.*`, `*.csproj` | **Read** `package.json` scripts |
 | Capture existing app | **Playwright MCP** `browser_navigate()` + `browser_take_screenshot()` | — |
 | Read Tailwind config | **Read** `tailwind.config.{js,ts}` | **Grep** `colors:` |
-| Read MudBlazor theme | **Glob** `**/MudTheme*.cs` → **Read** | **Grep** `PaletteLight` |
-| Trend research | **Read** `design-trends.md` standard | **Context7 MCP** / **WebSearch** |
+| Trend research | **Context7 MCP** / **WebSearch** | — |
 
 **MCPs for this phase:** Playwright (preview, inspection, responsiveness), Context7 (component docs).
 
 **Anti-patterns:**
-- WebSearch for MudBlazor docs (use Context7 MCP — more precise)
 - Task agent to read a screenshot (use Read directly on image)
 - Guess component props (use Context7 for actual API)
 
@@ -66,12 +64,13 @@ Check the `"phase"` field in the output:
 
 **If `"phase": "uiux"`** → correct phase, proceed.
 
-**If `"phase": "setup"`** → execute:
-1. `morph-spec phase advance $ARGUMENTS` (→ uiux)
+**If `"phase": "proposal"`** → execute in sequence:
+1. `morph-spec state mark-output $ARGUMENTS proposal`
+2. `morph-spec phase advance $ARGUMENTS` (→ uiux)
 
 **Any other value** → do not proceed — inconsistent state, report to user.
 
-> **Rule:** Never write to `2-ui/` until the phase is `uiux`. The hook will block writes.
+> **Rule:** Never write to `1-ui/` until the phase is `uiux`. The hook will block writes.
 
 ---
 
@@ -88,8 +87,7 @@ Check in priority order:
 2. **`package.json` port flags**: Read `package.json` scripts → scan for `--port`, `-p` flags → extract port
 3. **Next.js**: Glob `next.config.*` → try `http://localhost:3000`
 4. **Vite**: Glob `vite.config.*` → try `http://localhost:5173`
-5. **.NET launchSettings**: Glob `**/Properties/launchSettings.json` → Read → extract `applicationUrl`
-6. **.NET fallback**: Glob `*.csproj` → try `https://localhost:5001`
+5. **.NET**: Glob `**/Properties/launchSettings.json` → Read → extract `applicationUrl`
 
 Track: `detectedUrl` (string or null).
 
@@ -147,11 +145,11 @@ Once connected, take screenshots of up to 5 pages:
    mcp__plugin_playwright_playwright__browser_resize({ width: 1440, height: 900 })
    mcp__plugin_playwright_playwright__browser_take_screenshot({})
    ```
-4. Save screenshots to `.morph/features/$ARGUMENTS/2-ui/existing-*.png`
+4. Save screenshots to `.morph/features/$ARGUMENTS/1-ui/existing-*.png`
 
 #### 0.2.4 — Visual analysis
 
-Analyze the captured screenshots and write `.morph/features/$ARGUMENTS/2-ui/existing-ui-analysis.md`:
+Analyze the captured screenshots and write `.morph/features/$ARGUMENTS/1-ui/existing-ui-analysis.md`:
 
 > **Note:** This is an intermediate artifact — NOT a tracked output in `output-schema.js`. It will not appear in `state mark-output`. Advisory warnings from `task-tracking-guard.js` are expected.
 
@@ -217,21 +215,12 @@ If found, Read the file and extract:
 Glob: `components.json`
 If found and contains `"style"` field, also scan `src/lib/utils.ts` or `lib/utils.ts` for CSS var references.
 
-**D. MudBlazor Theme (.NET):**
-Glob: `**/MudTheme*.cs`, `**/*Theme*.cs`, `**/CustomTheme*.cs`
-If found, Grep for `PaletteLight`, `PaletteDark`, `Typography` property assignments.
-Extract: Primary, Secondary, Tertiary, Background, Surface colors + font families.
-
-**E. Fluent UI Theme (.NET):**
-Glob: `**/FluentDesignTheme*.cs`, `**/DesignTheme*.cs`
-If found, Grep for `DesignThemePalette` properties.
-
-**F. Global theme files:**
+**D. Global theme files:**
 Glob: `**/theme.{ts,js}`, `**/tokens.{ts,js}`, `**/design-tokens.{ts,js}`
 If found, Read and extract exported color/spacing/font objects.
 
 Classify ALL found tokens into:
-- **Colors**: `--color-*`, hex values, rgb(), Palette assignments
+- **Colors**: `--color-*`, hex values, rgb()
 - **Fonts**: `--font-*`, `font-family:`, fontFamily config
 - **Spacing**: `--space-*`, `--gap-*`, spacing config
 - **Radius**: `--radius-*`, borderRadius config
@@ -253,7 +242,7 @@ Track: `dsExists` (bool).
 |------|-----------|--------|
 | **A** | `dsExists` AND `cssTokensFound` | Cross-check DS vs scanned tokens. If >2 colors diverge, flag misalignment and ask user if they want to update DS with `AskUserQuestion`. Proceed to Step 1. |
 | **B** | `dsExists` AND NOT `cssTokensFound` | Print: `✓ Design system found (no CSS tokens to cross-check)`. Proceed to Step 1. |
-| **C** | NOT `dsExists` AND tokens found | Auto-generate `.morph/context/design-system.md` from ALL scanned token sources (CSS vars, Tailwind config, MudBlazor theme, etc.). Merge tokens from multiple sources, preferring Tailwind/Theme config over raw CSS. If Step 0.2 produced `existing-ui-analysis.md`, cross-reference visual analysis with extracted tokens. Proceed to Step 1. |
+| **C** | NOT `dsExists` AND tokens found | Auto-generate `.morph/context/design-system.md` from ALL scanned token sources (CSS vars, Tailwind config, etc.). Merge tokens from multiple sources, preferring Tailwind/Theme config over raw CSS. If Step 0.2 produced `existing-ui-analysis.md`, cross-reference visual analysis with extracted tokens. Proceed to Step 1. |
 | **D** | NOT `dsExists` AND NOT `cssTokensFound` | Greenfield project. Ask user for aesthetic direction + brand color using `AskUserQuestion` (same options as morph-init). Scaffold from template. Proceed to Step 1. |
 
 **Case C — auto-generate from scanned tokens:**
@@ -267,7 +256,7 @@ Create `.morph/context/design-system.md` with these sections populated from scan
 
 Print: `✓ Design system generated from [N] tokens — .morph/context/design-system.md`
 
-> **Design system is mandatory** for UI features. The implementation gate (Phase 5) will block if no design system exists.
+> **Design system is mandatory** for UI features. The implementation gate (Phase 7) will block if no design system exists.
 
 ## MANDATORY: Session Tasks
 
@@ -285,16 +274,18 @@ Check if active agents include `ui-designer`:
 morph-spec state get $ARGUMENTS
 ```
 
-If `ui-designer` is NOT in `activeAgents`, skip this phase and continue to Phase 2 (Design).
+If `ui-designer` is NOT in `activeAgents`, skip this phase and continue to Phase 3 (Design).
 
 ### Step 1.3: Trend Research
 
 > **Purpose:** Before defining aesthetic direction, research current design trends relevant to this project's domain.
-> **Ref:** `framework/standards/frontend/design-system/design-trends.md`
+> Use Context7 MCP or web search for current design trends.
 
-#### 1.3.1 — Consult curated catalog
+#### 1.3.1 — Research current trends
 
-Read `framework/standards/frontend/design-system/design-trends.md` and identify techniques relevant to the project.
+> **MCP:** Use **WebSearch** to research current design trends for the detected domain (e.g., "{currentYear} UI design trends {detectedDomain}"). WebSearch provides real-time results that are more current than any static reference. If WebSearch is not available, use **Context7 MCP** to query UI library documentation for latest component patterns and best practices. If neither is available, rely on your training knowledge of current design trends.
+
+Research current design trends relevant to the project's domain and stack. Identify 3-5 techniques that fit the project.
 
 #### 1.3.2 — Detect project domain
 
@@ -343,8 +334,6 @@ Selected trends feed into Step 1.5 (Aesthetic Direction) and Step 4 (Deliverable
 
 ### Step 1.5: Design Thinking — Aesthetic Direction
 
-> **Ref:** `framework/standards/frontend/design-system/aesthetic-direction.md`
-
 **BEFORE collecting technical requirements**, define visual direction with 4 questions:
 
 1. **Purpose**: What problem does it solve? Who uses it? What is the professional context?
@@ -352,16 +341,14 @@ Selected trends feed into Step 1.5 (Aesthetic Direction) and Step 4 (Deliverable
 3. **Differentiation**: What is the 1 memorable element of this interface?
 4. **Constraints**: Framework, performance budget, existing brand guidelines
 
-**CRITICAL:** Commit to direction BEFORE technical specs. Document in `ui-design-system.md`
+**CRITICAL:** Commit to direction BEFORE technical specs. Document in `design-system.md`
 in section `## Aesthetic Direction` (template available in the standard above).
 
 #### Domain-Adaptive Patterns
 
 After defining aesthetic direction, apply domain-specific pattern suggestions:
 
-> **Ref:** `framework/standards/frontend/design-system/aesthetic-direction.md` → `## Domain Adaptation`
-
-Based on the domain detected in Step 1.3.2, suggest patterns from the Domain Adaptation guide:
+Based on the domain detected in Step 1.3.2, suggest domain-adaptive patterns:
 
 | Domain | Preferred Directions | Key Patterns to Suggest |
 |--------|---------------------|------------------------|
@@ -391,8 +378,7 @@ If the user's chosen direction conflicts with domain recommendations (e.g., Indu
 
 Incorporate the trends selected in Step 1.3.4 into the aesthetic direction documentation:
 
-- Add selected trends to `## Aesthetic Direction` in `ui-design-system.md`
-- Reference the specific implementation from `design-trends.md`
+- Add selected trends to `## Aesthetic Direction` in `design-system.md`
 - Document how each trend maps to the chosen direction
 
 **Anti-patterns to avoid:**
@@ -422,16 +408,14 @@ Incorporate the trends selected in Step 1.3.4 into the aesthetic direction docum
 
 Detect the stack from `.morph/config/config.json` and recommend the appropriate library:
 
-**Blazor stack:**
-- **Fluent UI Blazor** — dashboards, simple forms, AI components, Microsoft design language
-- **MudBlazor** — advanced data grids, complex charts, material design
-
 **Next.js stack:**
 - **shadcn/ui + Radix** (recommended) — composable primitives, full control, Tailwind-native
 - **MUI** — feature-rich, enterprise-grade, material design
 
 **Document the decision as an ADR in `decisions.md`** with: context, options considered, decision, and rationale.
 
+> **MCP:** After selecting the UI library, use **Context7 MCP** (`resolve-library-id` → `query-docs`) to fetch the library's latest component API (e.g., shadcn/ui primitives, Radix props, MUI component APIs). This ensures component specs in `components.md` reference real, current props — not outdated or hallucinated ones. If Context7 is not available, use **WebSearch** + **WebFetch** to check the official component documentation.
+
 ### Step 3.5: Visual Mockup (Playwright MCP)
 
 > **Purpose:** Generate a real HTML preview using project design tokens before writing formal specs.
@@ -448,7 +432,7 @@ Create an HTML file that represents the main screen/layout using **real tokens f
 - Include representative content (realistic text, placeholder images)
 - All colors via CSS variables: `color: var(--color-primary)` not `color: #3b82f6`
 
-**Save to:** `.morph/features/$ARGUMENTS/2-ui/mockup.html`
+**Save to:** `.morph/features/$ARGUMENTS/1-ui/mockup.html`
 
 Example structure:
 ```html
@@ -491,7 +475,7 @@ Example structure:
 
 **Navigate to the file:**
 ```
-mcp__plugin_playwright_playwright__browser_navigate({ url: "file:///[ABSOLUTE_PATH_TO].morph/features/$ARGUMENTS/2-ui/mockup.html" })
+mcp__plugin_playwright_playwright__browser_navigate({ url: "file:///[ABSOLUTE_PATH_TO].morph/features/$ARGUMENTS/1-ui/mockup.html" })
 ```
 
 **Take screenshots at 3 breakpoints** (resize then screenshot for each):
@@ -499,19 +483,19 @@ mcp__plugin_playwright_playwright__browser_navigate({ url: "file:///[ABSOLUTE_PA
 **Mobile (375px):**
 ```
 mcp__plugin_playwright_playwright__browser_resize({ width: 375, height: 812 })
-mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/2-ui/mockup-mobile.png
+mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/1-ui/mockup-mobile.png
 ```
 
 **Tablet (768px):**
 ```
 mcp__plugin_playwright_playwright__browser_resize({ width: 768, height: 1024 })
-mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/2-ui/mockup-tablet.png
+mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/1-ui/mockup-tablet.png
 ```
 
 **Desktop (1440px):**
 ```
 mcp__plugin_playwright_playwright__browser_resize({ width: 1440, height: 900 })
-mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/2-ui/mockup-desktop.png
+mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morph/features/$ARGUMENTS/1-ui/mockup-desktop.png
 ```
 
 #### 3.5.3 — Present and Iterate
@@ -523,7 +507,7 @@ mcp__plugin_playwright_playwright__browser_take_screenshot({}) → save as .morp
 3. **Iterate:** Refine `mockup.html` → re-take screenshots → show updated previews
 4. **Continue only when user approves** this visual direction
 
-> **Note:** `ui-mockups.md` (Step 4.2) continues to exist as the reference for states and interactions.
+> **Note:** `mockups.md` (Step 4.2) continues to exist as the reference for states and interactions.
 > The PNGs are the visual reference; the .md covers behavior and edge cases.
 
 ---
@@ -534,22 +518,22 @@ Create the following files in `.morph/features/$ARGUMENTS/`:
 
 > **Use templates:** Use `morph-spec template render` to generate files from templates in `.morph/framework/templates/docs/`. Available templates: `ui-design-system`, `ui-mockups`, `ui-components`, `ui-flows`.
 
-#### 4.1. `ui-design-system.md`
+#### 4.1. `design-system.md`
 
 **If project-level design system exists (`.morph/context/design-system.md`):**
 - Reference it in specs: "Uses project design system at .morph/context/design-system.md"
-- Create `ui-design-system.md` only if there are feature-specific colors/components
+- Create `design-system.md` only if there are feature-specific colors/components
 
 **If it doesn't exist:**
 - Create complete feature-level design system with:
-  - **Section `## Aesthetic Direction`** (use template from `aesthetic-direction.md`):
+  - **Section `## Aesthetic Direction`**:
     direction, font pair, color philosophy, motion intent, composition approach
   - Color palette (primary, secondary, accent, semantic)
   - Typography (heading scales, body text, code)
   - Spacing and layout (grid, margins, paddings)
   - Base components (buttons, inputs, cards)
 
-#### 4.2. `ui-mockups.md`
+#### 4.2. `mockups.md`
 
 ASCII wireframes + descriptions:
 - General layout of each screen/page
@@ -557,15 +541,15 @@ ASCII wireframes + descriptions:
 - Responsiveness (desktop, tablet, mobile)
 - States (loading, error, empty, success)
 
-#### 4.3. `ui-components.md`
+#### 4.3. `components.md`
 
-Technical specs for Fluent UI/MudBlazor components:
-- Component to use (FluentButton, MudDataGrid, etc.)
+Technical specs for UI library components:
+- Component to use (Button, DataTable, etc.)
 - Props and configurations
 - Events and bindings
 - Validations and states
 
-#### 4.4. `ui-flows.md`
+#### 4.4. `flows.md`
 
 Complete user flows:
 - User stories
@@ -577,7 +561,7 @@ Complete user flows:
 
 **PAUSE - Before proceeding to accessibility:**
 
-- [ ] Aesthetic direction defined and documented in `ui-design-system.md`?
+- [ ] Aesthetic direction defined and documented in `design-system.md`?
 - [ ] Font pair specified (not just Inter/Roboto for display)?
 - [ ] Color philosophy: dominant + accent + rationale documented?
 - [ ] Design system defined (project-level or feature-level)?
@@ -623,11 +607,11 @@ morph-spec state mark-output $ARGUMENTS ui-flows
 
 ## Generated Outputs
 
-- `.morph/features/$ARGUMENTS/2-ui/design-system.md`
-- `.morph/features/$ARGUMENTS/2-ui/mockups.md`
-- `.morph/features/$ARGUMENTS/2-ui/components.md`
-- `.morph/features/$ARGUMENTS/2-ui/flows.md`
-- `.morph/features/$ARGUMENTS/1-design/decisions.md` (updated with UI library ADR)
+- `.morph/features/$ARGUMENTS/1-ui/design-system.md`
+- `.morph/features/$ARGUMENTS/1-ui/mockups.md`
+- `.morph/features/$ARGUMENTS/1-ui/components.md`
+- `.morph/features/$ARGUMENTS/1-ui/flows.md`
+- `.morph/features/$ARGUMENTS/2-design/decisions.md` (updated with UI library ADR)
 
 ### Step 7: Validate Design with Frontend Review
 
@@ -682,19 +666,15 @@ Use `AskUserQuestion` to capture explicit approval before advancing:
 
 ## Phase Outputs
 
-<!-- morph-outputs:uiux -->
-| Output | Caminho |
-|--------|---------|
-| `uiDesignSystem` | `.morph/features/{feature}/2-ui/design-system.md` |
-| `uiMockups` | `.morph/features/{feature}/2-ui/mockups.md` |
-| `uiComponents` | `.morph/features/{feature}/2-ui/components.md` |
-| `uiFlows` | `.morph/features/{feature}/2-ui/flows.md` |
-| `uiMockupHtml` | `.morph/features/{feature}/2-ui/mockup.html` |
-| `uiMockupMobile` | `.morph/features/{feature}/2-ui/mockup-mobile.png` |
-| `uiMockupTablet` | `.morph/features/{feature}/2-ui/mockup-tablet.png` |
-| `uiMockupDesktop` | `.morph/features/{feature}/2-ui/mockup-desktop.png` |
+<!-- morph-outputs:uiux -->
+| Output | Caminho |
+|--------|---------|
+| `uiDesignSystem` | `.morph/features/{feature}/1-ui/design-system.md` |
+| `uiMockups` | `.morph/features/{feature}/1-ui/mockups.md` |
+| `uiComponents` | `.morph/features/{feature}/1-ui/components.md` |
+| `uiFlows` | `.morph/features/{feature}/1-ui/flows.md` |
 <!-- /morph-outputs -->
 
 ---
 
-Continue automatically to Phase 2 (Design) after approval.
+Continue automatically to Phase 3 (Design) after approval.

package/framework/skills/level-1-workflows/morph-scope-escalation/SKILL.md

@@ -4,7 +4,7 @@ description: Guided workflow for mid-implementation scope escalation — analyze
 user-invocable: true
 argument-hint: "[feature-name]"
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
-cliVersion: "4.12.0"
+cliVersion: "4.13.0"
 ---
 
 # Scope Escalation Workflow

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

@@ -19,16 +19,16 @@
       "standards": ["coding.md", "ef-core.md"]
     },
     {
-      "id": "api-designer",
-      "role": "REST Endpoints + DTOs",
+      "id": "hangfire-orchestrator",
+      "role": "Background Jobs & Scheduling",
       "domain": "backend",
-      "standards": ["coding.md", "integration/api/rest-design.md"]
+      "standards": ["coding.md"]
     }
   ],
   "deliverables": {
-    "dotnet-senior": "Application services, business logic, command/query handlers",
+    "dotnet-senior": "Application services, business logic, command/query handlers, API endpoints, DTOs",
     "ef-modeler": "Entity models, DbContext, migrations",
-    "api-designer": "Controllers, DTOs, Swagger docs"
+    "hangfire-orchestrator": "Background jobs, recurring tasks, job scheduling"
   },
   "estimatedParallelGain": "2-3x throughput vs sequential",
   "agent_team": {
@@ -38,7 +38,7 @@
       {
         "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)"
+        "task_scope": "backend tasks (domain logic, application services, EF Core, API endpoints, DTOs, background jobs)"
       }
     ],
     "coordination_notes": "Single-domain squad — Agent Teams not required. Use subagents for parallelization.",

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

@@ -1,7 +1,7 @@
 {
   "id": "frontend-only",
   "name": "Frontend Squad",
-  "description": "Frontend-focused squad: Blazor components + CSS + UX",
+  "description": "Frontend-focused squad: UI components + CSS + UX",
   "parallel": true,
   "coordination": "ui-designer",
   "waitForAll": true,
@@ -10,24 +10,33 @@
       "id": "ui-designer",
       "role": "UI Design Lead",
       "domain": "frontend",
-      "standards": ["css-architecture.md", "css-design-system.md"]
+      "standards": [
+        "css-architecture.md",
+        "css-design-system.md"
+      ]
     },
     {
-      "id": "blazor-builder",
-      "role": "Blazor Component Developer",
+      "id": "nextjs-expert",
+      "role": "Frontend Developer",
       "domain": "frontend",
-      "standards": ["coding.md", "blazor-components.md", "blazor-state.md"]
+      "standards": [
+        "coding.md",
+        "nextjs-components.md"
+      ]
     },
     {
       "id": "css-specialist",
       "role": "CSS/Design System Specialist",
       "domain": "frontend",
-      "standards": ["css-architecture.md", "css-design-system.md"]
+      "standards": [
+        "css-architecture.md",
+        "css-design-system.md"
+      ]
     }
   ],
   "deliverables": {
     "ui-designer": "Design system tokens, component specs, mockup annotations",
-    "blazor-builder": ".razor components, code-behind, state management",
+    "nextjs-expert": "React components, pages, state management",
     "css-specialist": "CSS modules, design system implementation, responsive layout"
   },
   "estimatedParallelGain": "2x throughput vs sequential",
@@ -38,7 +47,7 @@
       {
         "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)"
+        "task_scope": "frontend tasks (UI components, CSS, design system implementation, responsive layout)"
       }
     ],
     "coordination_notes": "Single-domain squad — Agent Teams not required. Use subagents for parallelization.",