/qa-coverage

Phase: 3 (design gap check) and 5 (release readiness gate)
Command: /qa-coverage
Allowed tools: Read, Write

---

What it does

/qa-coverage has two modes depending on when it is called.

---

Mode 1 - Design gap check (after Phase 3)

Compares the requirements in requirements/ against the test designs produced in Phase 3 and answers:

Have we designed tests for every requirement that was planned?

Reads:

• qa-plan.md - what was planned
• qa-reports/api/api-test-plan.json - API coverage
• qa-reports/ui/ui-test.yaml - UI coverage
• qa-reports/a11y/ - accessibility coverage
• load-tests/dq-nbomber.yaml - performance coverage

Outputs qa-coverage.md with a gap table:

## 2026-05-26 - Design gap check

| Requirement | Domain | Designed? | Notes |
|-------------|--------|-----------|-------|
| Login with email | UI | ✅ | qa-reports/ui/ui-test.yaml: Login flow |
| WCAG 2.1 AA on login | A11y | ✅ | |
| /auth/refresh endpoint | API | ✅ | |
| p95 < 300ms on /products | Perf | ❌ | Missing - add to dq-nbomber.yaml |

**Gap count: 1**  
**Recommended action:** Add /products load scenario before execution.

---

Mode 2 - Release readiness gate (before Phase 5 closure)

After execution, compares execution results against the test plan and answers:

Have all planned tests been executed and is it safe to ship?

Reads:

• All design artifacts (above)
• All execution reports in qa-reports/

Outputs an updated qa-coverage.md section with a ship/hold recommendation:

## 2026-05-26 - Release readiness gate

| Domain | Tests planned | Tests executed | Pass rate | Gate |
|--------|-------------|----------------|-----------|------|
| API | 24 | 24 | 100% | ✅ Pass |
| Accessibility | 2 pages | 2 pages | 0 critical violations | ✅ Pass |
| Performance | 3 scenarios | 3 scenarios | All thresholds met | ✅ Pass |

**Verdict: SHIP ✅**

---

Versioning

qa-coverage.md uses dated sections. Each invocation prepends a new section. History is preserved.