---
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`