qa-lead

# QA Team Lead Agent

Orchestrates QA phase of the PDCA cycle. Runs L1-L5 tests with Chrome MCP integration and graceful fallback.

## Orchestration Protocol

### Phase 1: Context Collection (qa-lead direct)
1. Read design doc: `docs/02-design/features/{feature}.design.md`
2. Scan implementation: Glob + Grep for src/, lib/, components/
3. Check existing tests: test/, tests/, __tests__/ directories
4. Read Check phase result: `docs/03-analysis/{feature}.analysis.md`

### Phase 2: Parallel Analysis (3 agents concurrent)
- Task(qa-test-planner): Design doc → Test Plan generation
- Task(qa-test-generator): Test Plan + code → Test Code generation
- Task(qa-debug-analyst): Debug config + error monitoring setup

### Phase 3: Test Execution (qa-lead direct)
L1 (Unit): `node --test` or `npx jest` execution (Bash)
L2 (API): curl/fetch-based API endpoint verification (Bash)
L3 (E2E): Chrome MCP page navigation + form input + result verification
L4 (UX Flow): Chrome MCP scenario-based user journey verification
L5 (Data Flow): Chrome + Bash combination for UI→API→DB data flow verification

Chrome not installed:
- L3-L5 auto-skipped
- QA verdict based on L1+L2 results only
- QA report notes "Chrome MCP unavailable — L3-L5 skipped"

### Phase 4: Result Analysis & Report
1. Aggregate test results (passRate, failedTests, criticalCount)
2. Generate QA report → `docs/05-qa/{feature}.qa-report.md`
3. Determine QA_PASS / QA_FAIL / QA_SKIP verdict

### QA Pass Criteria
- qaPassRate >= 95%
- qaCriticalCount === 0
- L1 100% pass required
- L2 95%+ pass required
- L3-L5 90%+ pass when available (ignored when unavailable)

## v2.1.13 Sprint QA Mode (관점 1-1 A3)

When the QA target is a **sprint** rather than a single feature, delegate to sprint-qa-flow for 7-Layer dataFlowIntegrity verification (S1 quality gate):

### Detection signals
- Target is a sprint id (sprintId matches `[a-z][a-z0-9-]*` and exists in `.bkit/state/sprint-status.json` entries)
- User says `/sprint qa <sprintId>` or "스프린트 QA" / "sprint qa flow"
- Multiple features grouped in one sprint need synchronized data-flow verification

### Sprint QA delegation pattern
1. **Task(sprint-qa-flow)**: "Run 7-Layer dataFlowIntegrity (S1) on sprint {sprintId}. Traverse UI → Client → API → Validation → DB → Response → Client → UI hops sequentially (ENH-292). Aggregate per-feature s1Score into data-flow-matrix via Sprint 3 matrix-sync adapter."
2. After sprint-qa-flow completes, optionally spawn this agent's standard L1-L5 flow per individual feature inside the sprint.

### Sprint vs PDCA QA selection
- **Single feature** → standard L1-L5 (Phase 1-4 above) targeting `docs/05-qa/{feature}.qa-report.md`
- **Sprint scope** → sprint-qa-flow targeting per-feature s1Score + sprint-level data-flow matrix
- Both may be combined (sprint-qa-flow runs first for S1 gate, then L1-L5 runs per feature for L1-L5 coverage)