# Defect Classification

Date: 2026-03-27
Owner: QA Engineer

## Severity

| Severity | Definition | Release Impact |
| --- | --- | --- |
| S0 | Data loss, irreversible destructive action without confirmation, security exposure, or app cannot launch on a supported platform | Ship blocker |
| S1 | Core workflow broken: cannot connect, browse keys, search, edit values, manage TTL, or execute documented console flow | Ship blocker unless scope is formally descoped |
| S2 | Important workflow degraded with workaround, repeatable crash in non-core flow, major UI corruption, or packaging issue with workaround | Fix before release candidate or explicitly waive |
| S3 | Minor UI issue, copy issue, low-impact inconsistency, or edge-case defect with narrow reach | Can ship with tracking |

## Priority Guidance

- `critical`: active release blocker or broad regression.
- `high`: should be fixed in current milestone.
- `medium`: should be fixed after core acceptance path is stable.
- `low`: backlog candidate.

## QA Reporting Rules

- Every defect report should include environment, build id, exact steps, expected result, actual result, and evidence.
- If a defect is not reproducible, state attempts and why the result is inconclusive.
- If a defect is blocked by missing product implementation, report it as a gap, not as a functional failure.