@polymorphism-tech/morph-spec 4.9.0 → 4.10.1

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

@@ -0,0 +1,312 @@
+---
+name: morph: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, AskUserQuestion
+cliVersion: "4.10.1"
+---
+
+# MORPH Tasks — Phase 4
+
+> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
+
+Break the approved specification into executable tasks, define execution order, and establish checkpoints.
+
+## Prerequisites
+
+- [ ] Phase 3 (Clarify) completed
+- [ ] `spec.md` updated with clarifications
+- [ ] All edge cases documented
+
+## Recommended Tools
+
+> **Ref:** `framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md` for complete guide.
+> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` for MCP reference.
+> **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.
+
+| Action | Tool | Alternative |
+|--------|------|-------------|
+| Read spec + contracts + decisions | **Read** all outputs | — |
+| Analyze implementation complexity | **Grep** patterns in existing code | — |
+| Count similar existing patterns | **Glob** `**/Services/**/*.cs` | — |
+| Look up implementation patterns | **Context7 MCP** `query_docs()` | **WebSearch** |
+| Create GitHub issues from tasks | **GitHub MCP** `create_issue()` | **Bash** `gh issue create ...` |
+| Render tasks template | **Bash** `npx morph-spec template render docs/tasks ...` | — |
+| Update state with task count | **Bash** `npx morph-spec state set ... tasks.total N` | — |
+
+**Phase MCPs:** Context7 (estimate complexity), GitHub (create issues).
+
+**Anti-patterns:**
+- 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)** 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)
+
+---
+
+## Pre-flight (before starting task breakdown)
+
+### 0. Ensure tasks phase
+
+```bash
+npx morph-spec state get $ARGUMENTS
+```
+
+Check the `"phase"` field:
+
+**If `"phase": "tasks"`** → correct phase, proceed.
+
+**If `"phase": "clarify"`** → run in sequence:
+1. `npx morph-spec state mark-output $ARGUMENTS clarifications`
+2. `npx morph-spec phase advance $ARGUMENTS` (→ tasks)
+
+**Any other value** → STOP — inconsistent state, report to user.
+
+> **Rule:** Never write to `4-tasks/` until the phase is `tasks`. The hook will block writes.
+
+---
+
+### 1. Read all prerequisites in PARALLEL
+
+```
+# 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/config/config.json                               (→ architecture.style)
+```
+
+### 2. Create session tasks for visibility
+
+```
+TaskCreate: "Analyze spec and define tasks" → activeForm: "Analyzing spec"
+TaskCreate: "Generate tasks.md"             → activeForm: "Generating tasks.md"
+TaskCreate: "Phase advance"                 → activeForm: "Advancing phase"
+```
+
+> **Note:** Individual T001-T00N tasks are created as native tasks during the implementation phase (`phase-implement`). Here we only keep the 3 high-level tasks for this planning session.
+
+---
+
+### 3. Entry checkpoint — verify prerequisites
+
+Before starting the breakdown:
+
+- [ ] `spec.md` exists and approved by user?
+- [ ] `contracts.cs`/`.ts` exists and matches real schema?
+- [ ] `schema-analysis.md` validated (if applicable)?
+- [ ] `decisions.md` contains ADRs for all critical choices?
+- [ ] Design gate (`morph-spec approve $ARGUMENTS design`) approved?
+- [ ] Clarifications (Phase 3) resolved and spec updated?
+
+If any checkbox is NOT checked → return to corresponding phase and resolve.
+
+```bash
+npx morph-spec state get $ARGUMENTS
+npx morph-spec approval-status $ARGUMENTS
+```
+
+---
+
+## Workflow
+
+### Step 0: Detect Architecture Style
+
+Before anything else, determine if the project is VSA or DDD:
+
+```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.
+
+---
+
+### Step 0.5: VSA Task Plan
+
+> For VSA task patterns and DDD-level mappings, 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"
+```
+
+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).
+
+Use VSA-specific categories: `entity`, `errors`, `tags`, `migration`, `slice`, `frontend`, `tests`.
+
+**After defining VSA tasks, skip directly to Step 3 (Dependencies).**
+
+---
+
+### 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:
+
+1. **Functional requirements** (FR001, FR002, ...)
+2. **Technical components** (Entities, Services/Slices, Controllers/Endpoints, Pages)
+3. **Infrastructure** (Bicep, migrations, configs)
+4. **Tests** (Unit tests, integration tests)
+
+### Step 2: Break Into Tasks
+
+> For structure, categories, and implementation order, see `references/task-planning-patterns.md`
+
+Create tasks using the **T{NNN}** format (T001, T002, ...) following bottom-up order: domain → infrastructure → application → presentation → tests → infra → docs.
+
+The T### format is mandatory — it is used by `morph-spec task start/done` commands and the validate-tasks script. Do not use TASK-001, T01, or other formats.
+
+### Step 3: Define Dependencies
+
+For each task, specify dependencies:
+
+```json
+{
+  "id": "T005",
+  "title": "Create {Name}Service",
+  "dependencies": ["T001", "T002"],
+  "status": "pending"
+}
+```
+
+**Rule:** A task can only be executed when all its dependencies are `completed`.
+
+### Step 4: Establish Checkpoints
+
+Define checkpoints after every **3 tasks** — this cadence matches the implementation phase's checkpoint-save frequency. Regular checkpoints catch integration issues early rather than at the end.
+
+```json
+{
+  "id": "CHECKPOINT_001",
+  "title": "Domain Layer Complete",
+  "afterTasks": ["T001", "T002", "T003"],
+  "validations": [
+    "All entities created",
+    "Migrations applied",
+    "Domain tests passing"
+  ]
+}
+```
+
+### Step 5: Estimate Effort
+
+For each task, estimate time **in minutes** (not vague labels like "Low/Medium"). Specific estimates help the plan phase determine execution strategy and parallelization.
+
+| Complexity | Estimated Time |
+|------------|----------------|
+| Trivial (basic CRUD) | 15-30 min |
+| Simple (Service, Controller) | 30-60 min |
+| Medium (Business logic, validations) | 60-120 min |
+| Complex (Integrations, AI) | 120-240 min |
+
+### Step 6: Generate `tasks.md`
+
+Create `.morph/features/$ARGUMENTS/4-tasks/tasks.md` with the complete task structure, checkpoints, and estimates.
+
+### Step 7: Include IaC Tasks (if needed)
+
+If there are Azure resources, add Bicep and migration tasks.
+
+### Step 8: Update State
+
+```bash
+npx morph-spec state set $ARGUMENTS tasks.total {N}
+npx morph-spec state mark-output $ARGUMENTS tasks
+```
+
+## Outputs
+
+- `.morph/features/$ARGUMENTS/4-tasks/tasks.md` — Complete task breakdown
+
+## Mandatory Approval Pause
+
+Use `AskUserQuestion` to capture explicit approval before advancing. This gate prevents implementation from starting with an unapproved task list.
+
+```json
+{
+  "questions": [{
+    "header": "Approval",
+    "question": "Tasks generated. Approve to start implementation?",
+    "multiSelect": false,
+    "options": [
+      { "label": "Approve and implement", "description": "Advance to implementation phase" },
+      { "label": "I have feedback",       "description": "Type what you want to change" }
+    ]
+  }]
+}
+```
+
+- **"Approve and implement"** →
+  ```bash
+  npx morph-spec approve $ARGUMENTS tasks
+  npx morph-spec phase advance $ARGUMENTS
+  ```
+- **"I have feedback" or "Other"** → apply the feedback and repeat this PAUSE
+
+## Completion Criteria
+
+- [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] Dependencies mapped
+- [x] Checkpoints defined (every 3 tasks)
+- [x] Effort estimated in minutes per task
+- [x] Execution order clear
+- [x] IaC tasks included (if applicable)
+- [x] State updated with total tasks (`state set tasks.total`)
+- [x] User approved breakdown via `AskUserQuestion`
+
+---
+
+## Superpowers Integration
+
+> Available when the `superpowers` plugin is installed.
+
+| Skill | When to Use | Invocation |
+|-------|-------------|-----------|
+| `writing-plans` | After task breakdown, to plan implementation sequence | `Skill(superpowers:writing-plans)` |
+| `executing-plans` | To execute the task plan in a separate session | `Skill(superpowers:executing-plans)` |
+
+---
+
+## Phase Outputs
+
+<!-- morph:outputs:tasks -->
+| Output | Path |
+|--------|------|
+| `tasks` | `.morph/features/{feature}/4-tasks/tasks.md` |
+<!-- /morph:outputs -->
+
+---
+
+After approval: "Planning complete! Run `/morph-apply $ARGUMENTS` to start implementation."

package/framework/skills/level-1-workflows/{phase-tasks → morph-phase-tasks}/scripts/validate-tasks.mjs

@@ -7,7 +7,7 @@
  *
  * Usage:
  *   node validate-tasks.mjs <tasks-file>
- *   node validate-tasks.mjs .morph/features/my-feature/3-tasks/tasks.md
+ *   node validate-tasks.mjs .morph/features/my-feature/4-tasks/tasks.md
  *
  * Checks:
  *   - Summary table exists with T### IDs and valid statuses
@@ -57,9 +57,9 @@ if (summaryTasks.length === 0) {
   errors.push('No summary table found — expected rows matching | T### | Type | Title | Status |');
 }
 
-// 2. Parse task headers (### T001: Title)
+// 2. Parse task headers (### T001: Title  or  ### T001 — Title  or  ### T001 - Title)
 const taskHeaders = lines
-  .map((l, i) => ({ line: i + 1, match: l.match(/^###\s+(T\d{3}):\s+(.+)/) }))
+  .map((l, i) => ({ line: i + 1, match: l.match(/^###\s+(T\d{3})\s*[—–:\-]\s+(.+)/) }))
   .filter(r => r.match);
 
 // Check sequential IDs

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

@@ -0,0 +1,324 @@
+---
+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.
+argument-hint: "[feature-name]"
+user-invocable: false
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
+cliVersion: "4.10.1"
+---
+
+# MORPH UI/UX Design - Phase 1.5
+
+> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
+
+Conditional phase for features with front-end. Collects UI/UX requirements, generates wireframes, component specs, and user flows.
+
+## Prerequisites
+
+- [ ] Phase 1 (Setup) completed
+- [ ] Feature has detected UI keywords (blazor, ui, component, page, dashboard, wizard, form, chart)
+- [ ] `uiux-designer` agent activated
+
+## Recommended Tools
+
+> **Ref:** `framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md` for complete guide.
+> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` for MCP reference.
+
+| Action | Tool | Alternative |
+|--------|------|-------------|
+| 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` | — |
+| UI component documentation | **Context7 MCP** `query_docs({ libraryId, query })` | **WebSearch** + **WebFetch** |
+| Preview existing page | **Playwright MCP** `browser_navigate()` + `browser_take_screenshot()` | **WebFetch** URL |
+| Inspect page structure | **Playwright MCP** `browser_snapshot()` | **WebFetch** + manual parse |
+| Test responsive layout | **Playwright MCP** `browser_resize()` + `browser_take_screenshot()` | Manual testing |
+| External design references | **WebSearch** + **WebFetch** | — |
+| Render UI templates | **Bash** `npx morph-spec template render docs/ui-mockups ...` | — |
+| Generate design system from existing CSS | **Bash** `npx morph-spec generate design-system --scan` | — |
+| Update state | **Bash** `npx morph-spec state mark-output ...` | — |
+
+**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)
+
+---
+
+## Workflow
+
+### Step 0: Ensure uiux phase
+
+```bash
+npx morph-spec state get $ARGUMENTS
+```
+
+Check the `"phase"` field in the output:
+
+**If `"phase": "uiux"`** → correct phase, proceed.
+
+**If `"phase": "setup"`** → execute:
+1. `npx 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.
+
+---
+
+### Step 0.5: Check Design System Exists
+
+**CRITICAL:** Before starting UI/UX phase, check if a design system exists:
+
+```
+Read: .morph/context/design-system.md
+```
+
+If the file doesn't exist (design system not found):
+
+1. **Option A - Automatic scaffold:**
+   - The system will automatically create a design system when advancing to implementation
+   - You can generate manually now: `npx morph-spec generate design-system`
+
+2. **Option B - Create manually:**
+   - Create `.morph/context/design-system.md` (project-level, shared)
+   - Or `.morph/features/$ARGUMENTS/2-ui/design-system.md` (feature-specific)
+
+3. **Option C - Scan existing CSS:**
+   - If the project already has CSS with variables: `npx morph-spec generate design-system --scan`
+
+**IMPORTANT:**
+- Design system is **mandatory** for UI features
+- Automatic gate will block implementation (Phase 5) if design system doesn't exist
+- Better to create now to ensure visual consistency
+
+### Step 1: Detect If Phase Is Needed
+
+Check if active agents include `uiux-designer`:
+
+```bash
+npx morph-spec state get $ARGUMENTS
+```
+
+If `uiux-designer` is NOT in `activeAgents`, skip this phase and continue to Phase 2 (Design).
+
+### 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?
+2. **Tone**: What direction? (Minimal Refined / Editorial / Soft Professional / Industrial / Modern Luxury)
+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`
+in section `## Aesthetic Direction` (template available in the standard above).
+
+**Anti-patterns to avoid:**
+- Purple gradient on white background (AI cliche)
+- Inter/Roboto as display font
+- 3-column card grid without visual differentiation
+- 5-color palette with equal weight (without dominant + accent)
+
+### Step 2: Collect User Input
+
+**ALWAYS ask the user FIRST:**
+
+1. **Layout and style**:
+   - Do you have any layout ideas in mind?
+   - Do you have visual references? (sites, apps, screenshots)
+   - How do you envision the user flow?
+
+2. **Components and interactions**:
+   - What are the main components of this screen/page?
+   - What states need to be considered? (loading, error, empty, success)
+
+3. **Reference images**:
+   - Do you have example images I can analyze?
+   - If YES: use Read tool to read screenshots and extract patterns
+
+### Step 3: Choose UI Library
+
+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.
+
+### Step 4: Generate Deliverables
+
+Create the following files in `.morph/features/$ARGUMENTS/`:
+
+> **Use templates:** Use `npx 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`
+
+**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
+
+**If it doesn't exist:**
+- Create complete feature-level design system with:
+  - **Section `## Aesthetic Direction`** (use template from `aesthetic-direction.md`):
+    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`
+
+ASCII wireframes + descriptions:
+- General layout of each screen/page
+- Component positioning
+- Responsiveness (desktop, tablet, mobile)
+- States (loading, error, empty, success)
+
+#### 4.3. `ui-components.md`
+
+Technical specs for Fluent UI/MudBlazor components:
+- Component to use (FluentButton, MudDataGrid, etc.)
+- Props and configurations
+- Events and bindings
+- Validations and states
+
+#### 4.4. `ui-flows.md`
+
+Complete user flows:
+- User stories
+- Flow diagrams (text/ASCII)
+- Edge cases (what happens if...?)
+- Validations and feedback
+
+### CHECKPOINT: Validate UI Deliverables
+
+**PAUSE - Before proceeding to accessibility:**
+
+- [ ] Aesthetic direction defined and documented in `ui-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)?
+- [ ] Wireframes cover all states (loading, error, empty, success)?
+- [ ] Components specified with actual props from chosen UI library?
+- [ ] Complete user flows with edge cases?
+- [ ] Chosen UI library documented as ADR in `decisions.md`?
+
+**If any checkbox is NOT checked:**
+→ Go back and complete the missing deliverable
+
+**If ALL checkboxes are checked:**
+→ Proceed to accessibility validation
+
+---
+
+### Step 5: Validate Accessibility and Responsiveness
+
+Document in UI files:
+- **WCAG 2.1 Level AA** compliance
+  - Adequate color contrast
+  - Accessible labels for screen readers
+  - Keyboard navigation
+- **Responsive breakpoints**
+  - Desktop (>1200px)
+  - Tablet (768px - 1199px)
+  - Mobile (<768px)
+
+### Step 6: Update State
+
+```bash
+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
+npx morph-spec state mark-output $ARGUMENTS ui-flows
+```
+
+> **Format note:** The `mark-output` commands accept BOTH kebab-case (`ui-design-system`)
+> AND camelCase (`uiDesignSystem`). Both formats work equally! Use whichever is more
+> comfortable for you. Examples:
+> - `npx morph-spec state mark-output my-feature uiDesignSystem`
+> - `npx morph-spec state mark-output my-feature ui-design-system`
+
+## 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)
+
+### Step 7: Validate Design with Frontend Review
+
+After generating all 4 UI outputs and updating state (Step 6):
+
+```bash
+/frontend-review $ARGUMENTS
+```
+
+The skill validates: WCAG token contrast, existence of all outputs, static design accessibility, and generates mockup screenshots if dev server is available.
+
+**If frontend-review blocks**, fix issues before presenting to user.
+
+---
+
+## MANDATORY PAUSE
+
+Use `AskUserQuestion` to capture explicit approval before advancing:
+
+```json
+{
+  "questions": [{
+    "header": "Approval",
+    "question": "UI/UX generated. Approve to advance to technical design?",
+    "multiSelect": false,
+    "options": [
+      { "label": "Approve UI/UX", "description": "Advance to technical design phase" },
+      { "label": "I have feedback", "description": "Type what you want to adjust in the field below (Other)" }
+    ]
+  }]
+}
+```
+
+- **"Approve UI/UX"** →
+  ```bash
+  npx morph-spec approve $ARGUMENTS uiux
+  npx morph-spec phase advance $ARGUMENTS
+  ```
+- **"I have feedback" or "Other"** → apply the received feedback and repeat this PAUSE
+
+## Advancement Criteria
+
+- [x] User input collected (layout, references)
+- [x] UI library chosen and justified (ADR)
+- [x] 4 deliverables created (design-system, mockups, components, flows)
+- [x] WCAG 2.1 accessibility documented
+- [x] Responsiveness specified
+- [x] State updated
+- [x] User approved UI/UX
+
+---
+
+## Phase Outputs
+
+<!-- morph:outputs:uiux -->
+| Output | Path |
+|--------|------|
+| `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` |
+<!-- /morph:outputs -->
+
+---
+
+Continue automatically to Phase 2 (Design) after approval.