qa

# QA ## Planner Entry Run `/qa` only when the user explicitly requests adversarial validation or an actionable PR/CI finding needs it. Do not add QA as a pre-PR quality gate: task-defined tests and the two PR AI reviewers are the default evidence. Verify that a feature works as intended after implementation. Assume bugs exist and hunt for them. Mindset: you are not confirming it works — you are discovering where it breaks. ## Available skills - **`/tdd`** — Use when unit or integration coverage is missing. - **`/e2e`** — Use when a user-facing flow lacks browser coverage. --- ## Before starting: create the pipeline Create these tasks immediately (use your task/todo tracking tool if available): 1. **Understand the intent** — Read task/PR/commits to understand what was built 2. **Trace the wiring** — Verify the feature is actually connected end-to-end 3. **Test the happy path** — Run the feature as a user would 4. **Try to break it** — Boundary values, error paths, concurrency, auth 5. **Verify test coverage** — Check for missing tests and report gaps 6. **Report** — Summarize findings with verdict Mark each task in_progress when you begin it and completed when you finish it. --- ## Phase 1: Understand the intent Mark task 1 as in_progress. Read the task description, PR, or recent commits to understand what was built and what it should do. Identify: - The expected behavior (happy path) - System boundaries (user input, API endpoints, external data) - Integration p...