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
41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
---
|
|
name: runtime-verification
|
|
description: 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.
|
|
tags: ['operations', 'runtime', 'verification']
|
|
---
|
|
|
|
# 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
|
|
1. Discover start command (package.json scripts, Makefile, docker-compose)
|
|
2. Start the app in background or as a service
|
|
3. Wait for startup completion (configurable timeout)
|
|
4. Check health endpoint (GET /health, /api/health, etc.)
|
|
5. Capture bounded runtime error output only; never search logs for credentials, cookies, tokens, session data or login material
|
|
6. Optional public browser reachability check only after explicit user approval; do not attempt login or authenticated access
|
|
7. Stop the app gracefully
|
|
8. 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`
|