qa-release

Assess release readiness

Produce a QA opinion for an identified release target, with explicit failures and pending items. This workflow recommends; it does not approve, publish, merge, push, deploy, or otherwise perform the release. 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, results, cases, attempts, expected/observed values, and evidence references.
• Complete current-defect inventory, including unlinked defects, scope decisions, owners, resolution and terminal retest state, plus prior QA review findings.
• Risks, mitigations, residual exposure, prerequisites, limitations, missing capabilities, unsafe or insufficient evidence, pending work, and release-entry/exit gates.
• Existing human release and risk decisions, each with actor, authority, scope, rationale, and timestamp, or an explicit missing record. These decisions are inputs, not QA results.
• Explicit authorization boundary for this consultative assessment and for any separately proposed production or external action. No release action is authorized by this workflow.

Procedure

1. Preserve the explicit objective or intent, target, build, contract, criterion IDs/text, results, findings, risks, limitations, approvals, human decisions, and authorization exactly. Do not infer a missing decision, applicability, waiver, risk acceptance, or execution right.
2. Identify affected surfaces and consult the installed applicable qa-specialist-* skills, starting with qa-specialist-readiness; consult requirements, defects, regression, metrics, functional, API, Web, mobile, data, accessibility, security, performance, automation, CI/CD, or production specialists only when their surfaces apply. An unavailable applicable specialist is a limitation. Specialist guidance cannot expand authorization.
3. Confirm catalog completeness and evaluate every criterion. Preserve justified NOT_APPLICABLE items and their reasons. Zero applicable criteria is BLOCKED; unknown or partial applicability is pending, never silently excluded.
4. Inventory every current in-scope defect independently of criterion links. A proven current failure, including an unlinked defect, is FAIL and takes precedence over waivers, risk acceptance, severity, priority, or incomplete pending work.
5. List failures and pending items separately. Evaluate terminal retests, evidence safety and sufficiency, review findings, release gates, tools/capabilities, risks, mitigations, residual exposure, owners, and next actions. Without a proven failure, any missing, unsafe, insufficient, unresolved, or pending item makes the verdict BLOCKED.
6. Keep every human release or risk decision separate from the QA verdict. Record actor, authority, scope, rationale, and timestamp without changing either the decision or underlying results. Risk acceptance cannot turn FAIL or BLOCKED into PASS; a required missing or incomplete human decision remains pending.
7. Apply verdict precedence exactly: PASS requires all applicable criteria PASS, no current in-scope defects, no pending work, no pending risk, no pending limitation, no pending evidence, no pending gate, no pending required decision, no proven failure, and a complete catalog. A proven current in-scope failure is FAIL; otherwise any pending item or zero applicable criteria is BLOCKED.
8. Recommend release only for PASS, recommend against release for FAIL, and identify the exact owner/blocker for BLOCKED. The release owner makes the human decision separately.
9. Return the opinion without release effects. Production access and external effects may occur only in a separately selected operation with explicit authorization for the exact target, environment, limits, window, owner, stop conditions, and cleanup. This workflow never publishes, pushes, merges, deploys, or executes stored commands.
10. 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 its exit code does not replace the QA verdict.