Task: System Verification — End-to-End Application Testing

Task: System Verification — End-to-End Application Testing

Objective

Produce a SYSTEM_VERIFICATION.md that documents whether the fully composed application actually works by bootstrapping the entire stack and running cross-cutting user scenarios that span multiple components. This is the system-level equivalent of per-unit verification — it catches integration bugs, contract mismatches, missing configuration, and system glue issues that are invisible when each unit is tested in isolation. After this skill runs, the reader knows whether the application works as a whole and exactly where it breaks if it does not.

Inputs

1. Use cases or user scenarios (required) — the cross-cutting user flows to test. Accepted formats: a USE_CASES.md document, user stories, feature descriptions, or freeform instructions. Each scenario should describe a complete user journey that exercises multiple components in sequence.
2. Application start instructions (optional) — how to bootstrap the full stack. If not provided, discover from the codebase: docker-compose files, Makefiles, package.json scripts, README setup instructions. The skill must start ALL services, not just one.
3. Architecture documents (optional) — system structure, component list, service dependencies. Helps identify what needs to start and in what order.
4. INTERFACES.md (auto-discovered) — if present, used to verify that cross-boundary communication uses correct wire formats during live testing.
5. Per-unit VERIFICATION.md files (optional) — prior verification results. Useful for understanding what already works at the unit level, so system verification can focus on cross-boundary behavior.

Workflow

System verification has two phases: bootstrap and scenario testing. Bootstrap must succeed before scenarios run — there is no point testing features against a system that cannot start.

Phase A: Bootstrap

Verify the application can start as a complete system. This phase catches "system glue" issues — missing environment variables, unconfigured databases, broken service dependencies, missing migration scripts.

Step 1: Environment check.

• Identify all required environment variables across all components. Check .env files, .env.example files, docker-compose environment sections, and application config files.
• Verify that all required variables are set or have defaults. If .env files are missing, check whether .env.example files exist and can be copied.
• Check for database connection strings, API keys, service URLs, and auth configuration.
• Record every environment issue found.

Step 2: Dependency startup.

Start services in dependency order:

1. Infrastructure services first: databases, message queues, cache servers (typically via docker-compose or local install).
2. Internal services next: git engines, background workers, any internal APIs.
3. Application services last: the main server, web dev server.