qa-review

Review QA coverage read-only

Assess whether the supplied QA record covers the governing requirements and supports its stated results. This is a read-only review: it reports gaps and findings without changing product code, tests, contracts, approvals, evidence, or recorded state. Read workflow, safety, artifacts, and evidence first.

Inputs

• Project root, target/environment/build/change identity, explicit objective or intent, identified contract source/hash, and the complete supplied criterion catalog with exact IDs, text, applicability, and current results.
• Risks, planned and executed cases, stable case/attempt IDs, expected and observed values, exclusions, prerequisites, limitations, and verified local evidence references.
• Complete current-defect inventory, including unlinked and out-of-scope defects, retest history, findings already accepted or deferred, and the recorded QA verdict.
• Explicit authorization boundary for this read-only review and any separately proposed follow-up. Load, penetration, production, and external effects require separate exact authorization.

Procedure

1. Preserve the explicit objective or intent, target, contract, criterion IDs/text, existing results, findings, limitations, approvals, and authorization exactly. Never infer missing criteria, applicability, approval, execution permission, or risk acceptance.
2. Identify affected surfaces and consult the installed applicable qa-specialist-* skills, starting with qa-specialist-requirements; use functional, API, Web, mobile, data, accessibility, security, performance, automation, CI/CD, regression, defects, metrics, or production specialists only when their surfaces apply. An unavailable applicable specialist is a limitation. Specialist guidance does not expand authorization.
3. Review requirements first: confirm catalog completeness, preserve each ID and text, and assess applicability, clarity, consistency, testability, observable oracle, source identity, and traceability. Ambiguity or contradiction remains BLOCKED; proposed wording is never an authoritative correction.
4. Review coverage against each applicable requirement and risk. Trace inclusions, exclusions, cases, attempts, environments, data, positive/negative/boundary/recovery paths, expected and observed results, evidence, and defects. A hash proves integrity, not semantic completeness.
5. Report findings with stable IDs, affected requirement/risk/case/defect IDs, severity and rationale, supporting evidence or explicit evidence gap, owner, and smallest valid follow-up. Keep proven failures, coverage gaps, limitations, and editorial observations distinct.
6. Apply verdict precedence to the supplied facts without mutating them: a proven current in-scope failure, including an unlinked defect, is FAIL; otherwise any missing criterion, coverage, evidence, prerequisite, capability, decision, or unresolved finding is BLOCKED. PASS requires every applicable criterion PASS, no current in-scope defects, no pending item or limitation, and a complete review scope. Zero applicable criteria is BLOCKED.
7. Return the review read-only. It never corrects, modifies, or mutates the product, tests, contracts, approvals, evidence, findings, or state. Product code corrections are only allowed when explicitly requested in a separate authorized operation.
8. A later inert export may use qa_report.py report --manifest PATH --project-root PATH; the report does not run or re-run tests and does not resolve findings.