What it does
Pulls the sibling Release and Status reports (never re-deriving), evaluates each gate (pass rate, open defects by severity, perf, security, a11y, contracts, regression, residual risk) against a deterministic decision table, renders a readiness scorecard, and applies an aggregate rule to a GO / GO-with-conditions / NO-GO outcome with a stakeholder sign-off block.
When to use it
At the release gate, as the formal ship/hold decision. Pairs with status-report and release-report.
Prerequisites
qa.config.yml — paths, gates, tooling toggles, risk_areas (assumes conservative defaults if missing). Quality signals must exist (RELEASE-REPORT/STATUS-REPORT/TEST-PLAN, results).
Output
Release Go/No-Go Decision Record (governance extension of the 29119-3 Test Completion Report; no dedicated 29119-3 template) -> <paths.docs_dir>/GO-NO-GO-<release>.md.
Mechanics
How it works
- Config guard; resolve the release from args (or default to in-flight critical work)
- Consolidate inputs from the matching Release/Status/Plan reports; flag missing ones as gaps
- Evaluate G1–G8 gates against the deterministic decision table (met/not-met/waived)
- Render a readiness scorecard with measured values and evidence per gate
- Apply the aggregate rule: any blocker not met forces NO-GO or GO-with-conditions
- Confirm rollback + post-deploy plan and a stakeholder sign-off table; write the record
Why it works
The theory behind it
Release decision against exit criteria plus residual risk (CTFL §5.3; CTAL-TM release-decision practice). It is a cross-functional decision record layered over the 29119-3 reports, embodying Principle 1 — ship with stated residual risk, never claim 'zero bugs'; in doubt, default to the more conservative outcome.
CTFL v4.0 §5.3 · CTAL-TM
Example
See it in use
> /qa:go-no-go R2.4✓ Correct when It consolidates the signals into a single ship/hold decision against the gates, with residual risk and sign-off lines.
Used by