Software Orchestrator
f6691b74f6
- 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
1.6 KiB
1.6 KiB
name, description, tags
| name | description | tags | |||
|---|---|---|---|---|---|
| test-validation | Use existing test/build tooling for validation - no invented commands. |
|
Test Validation
Purpose
Run the project's existing test and build tooling to validate a change, without inventing new commands.
When to Use
- 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)
Procedure
- Discover test framework from package.json, requirements.txt, Makefile, etc.
- Discover build command from the same files
- Run tests using the discovered command (e.g.,
npm test,pytest,make test) - Run build using the discovered command (e.g.,
npm run build,make build) - Capture pass/fail counts and detailed failure output
- If failures, classify and delegate to test_debug_engineer for root cause
Quality Gates
- Tests pass (no failures, no skips without justification)
- Build succeeds without warnings (or warnings documented)
- Type check passes (e.g.,
tsc --noEmit,mypy)
See Also
- Tool:
terminal(for running test commands) - Subagent:
test_debug_engineer