feat: add ui_design_specialist (Phase 3 UI Design) v0.2.0

- New specialist: ui_design_specialist with iterative mockup dialog
- New Phase 3 (UI Design) between Architecture and Implementation
- Relay model: orchestrator passes responses verbatim in Phase 3
- Cost-control exception for UI Design phase (unlimited subagent calls)
- Webspace mockup workflow with cache-buster and obscure dirs
- UX states coverage (loading, empty, error, partial)
- WCAG 2.1 AA accessibility guidelines
- Design tokens (CSS custom properties) in design system
- Component states (hover, focus, active, disabled, loading, error)
- Sitemap/wireframe before mockups for complex UIs
- Real content strategy (no Lorem Ipsum)
- Form validation UX in mockups
- Dark mode and i18n support (optional)
- Design handoff support (specialist available during implementation)
- Skip mechanism for non-UI projects
- Mockup state file for context compression recovery
- Multi-page mockup strategy with index.html
- task_graph.json mockup references
- Plugin version: 0.1.14 -> 0.2.0
- 47 files changed across 7 implementation blocks
- 3 review rounds with 41 corrections integrated

help/handover/help.md

@@ -48,7 +48,7 @@ handover_to_specialist(
 
 | Argument | Required | Notes |
 |----------|----------|-------|
-| `specialist_profile` | ✅ | One of the 11 known profiles (see below). |
+| `specialist_profile` | ✅ | One of the 12 known profiles (see below). |
 | `topic` | ✅ | Short slug. Used in the briefing filename. |
 | `summary` | recommended | LLM-curated; max 300 tokens recommended. |
 | `recent_turns` | optional | Auto-trimmed to `include_recent_turns`. |
@@ -77,11 +77,11 @@ allow-list (defence-in-depth): a typo in the profile name produces a clear
 - `runtime_devops_engineer`
 - `security_data_engineer`
 - `solution_architect`
+- `ui_design_specialist`
 - `test_debug_engineer`
 - `hacker`
 
-`frontend_designer` is **not** a known profile in Phase 1. It is on the
-roadmap for Phase 2.
+`frontend_designer` is **not** a known profile. Use `ui_design_specialist` instead for UI design tasks.
 
 ---
 

help/management/tool-governance.md

@@ -34,6 +34,20 @@ Maintain a registry of available tools, verify capabilities before use, and defi
 - Tool not found: use `capability_check` to find closest alternative
 - Tool disabled: ask user to enable or use alternative
 - Tool errors persistently: delegate to test_debug_engineer for diagnosis
+- UI design tool issues: delegate to ui_design_specialist for UI design workflow questions
+
+## Available Specialist Profiles
+- `requirements_analyst` – Requirements, acceptance criteria
+- `solution_architect` – Architecture, design, task graph
+- `ui_design_specialist` – UI design planning, mockup creation, design handoff support
+- `implementation_engineer` – Code implementation
+- `test_debug_engineer` – Tests, debugging, root cause
+- `quality_reviewer` – Quality review at every phase gate
+- `runtime_devops_engineer` – Runtime verification, deployment basics
+- `security_data_engineer` – Security, data, migration risks
+- `deploy_agent` – Coolify deployment
+- `release_auditor` – Release audit, handoff
+- `codebase_explorer` – Read-only codebase exploration
 
 ## See Also
 - Plugin tool: `tool_registry`

help/operations/runtime.md

@@ -10,11 +10,15 @@ tags: ['operations', 'runtime', 'verification']
 Verify the application actually starts, responds to health checks, and behaves correctly before declaring a build successful.
 
 ## When to Use
-- After implementation completes
+- After implementation completes (Phase 4)
 - Before declaring a build successful
 - After deployment for health/reachability testing
 - During debugging of startup issues
 
+## Phase Context
+Full phase sequence: 1 (Intake) → 2 (Architecture) → 3 (UI Design) → 4 (Implementation) → 5 (Test) → 6 (Runtime) → 7 (Deployment) → 8 (Release)
+Runtime verification occurs in Phase 6, after UI Design (Phase 3) and Implementation (Phase 4) are complete.
+
 ## Procedure
 1. Discover start command (package.json scripts, Makefile, docker-compose)
 2. Start the app in background or as a service

help/testing/validation.md

@@ -10,11 +10,15 @@ tags: ['testing', 'validation', 'ci']
 Run the project's existing test and build tooling to validate a change, without inventing new commands.
 
 ## When to Use
-- After any implementation block
+- After any implementation block (Phase 4)
 - Before declaring a feature complete
 - Before a release
 - When verifying a bug fix
 
+## Phase Context
+Full phase sequence: 1 (Intake) → 2 (Architecture) → 3 (UI Design) → 4 (Implementation) → 5 (Test) → 6 (Runtime) → 7 (Deployment) → 8 (Release)
+Test validation occurs in Phase 5, after Implementation (Phase 4). UI Design (Phase 3) produces mockups and design specs that guide implementation.
+
 ## When Not to Use
 - When no test framework exists (create one first, see implementation_engineer)
 - For purely documentation changes (no test needed)