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
42 lines
1.6 KiB
Markdown
42 lines
1.6 KiB
Markdown
---
|
|
name: test-validation
|
|
description: Use existing test/build tooling for validation - no invented commands.
|
|
tags: ['testing', 'validation', 'ci']
|
|
---
|
|
|
|
# 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
|
|
1. Discover test framework from package.json, requirements.txt, Makefile, etc.
|
|
2. Discover build command from the same files
|
|
3. Run tests using the discovered command (e.g., `npm test`, `pytest`, `make test`)
|
|
4. Run build using the discovered command (e.g., `npm run build`, `make build`)
|
|
5. Capture pass/fail counts and detailed failure output
|
|
6. 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`
|