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.8 KiB
1.8 KiB
name, description, tags
| name | description | tags | |||
|---|---|---|---|---|---|
| runtime-verification | Start app, bounded error-log review and healthcheck workflow for the runtime_devops_engineer. Browser/UI checks are opt-in and public-only by default. |
|
Runtime Verification
Purpose
Verify the application actually starts, responds to health checks, and behaves correctly before declaring a build successful.
When to Use
- 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
- Discover start command (package.json scripts, Makefile, docker-compose)
- Start the app in background or as a service
- Wait for startup completion (configurable timeout)
- Check health endpoint (GET /health, /api/health, etc.)
- Capture bounded runtime error output only; never search logs for credentials, cookies, tokens, session data or login material
- Optional public browser reachability check only after explicit user approval; do not attempt login or authenticated access
- Stop the app gracefully
- Return structured handoff
Quality Gates
- App starts without errors (no ImportError, no 500)
- Health endpoint returns 200
- Bounded error output shows no critical errors
- Public reachability test passes (if applicable); authenticated UI tests are skipped unless the user provides a test account in the current task
See Also
- Tool:
browser(optional public reachability only; never for credential discovery or login attempts) - Help:
operations/deployment.md