Release severity triage (1.0)¶
Status: planning / published rules
Programme: pre_release_roadmap_1_0.md §7
Linked from: ROADMAP.md, release_governance.md
Without explicit severity, hardening expands indefinitely because every imperfection looks equally important. Apply these rules during 0.9.x hardening and RC triage.
Severity |
Definition |
1.0 action |
|---|---|---|
Release blocker |
Data loss; unsafe deletion; corrupt outputs; broken supported install; incorrect run truth; security/privacy failure |
Must fix before RC/1.0; no known-limitation escape |
Must fix |
Principal journey broken; misleading prominent analysis; unusable error state; documentation cannot complete a supported workflow |
Must fix before 1.0 |
May ship as known limitation |
Optional module failure; unsupported language/model/platform combination; specialist UI friction; non-critical performance problem |
Document honestly; do not block 1.0 |
Post-1.0 |
Aesthetic refactors; experimental analyses; specialist convenience; non-supported configurations |
Explicitly out of scope for the release gate |
Gate rules¶
Severity rules written and linked from ROADMAP / release governance
Hardening backlog tagged with severity before RC (provisional — analysis_quality_audit_judgements.md 0.9.7; owner confirm)
RC entry requires zero open release blockers and zero open must-fix items
Tag each hardening finding with one severity before scheduling work. Known limitations must be listed in release notes or a known-limitations section when shipping under that class.