feat(desktop): add redis gui foundation baseline

Co-Authored-By: Paperclip <noreply@paperclip.ing>

docs/qa/defect-severity.md

@@ -0,0 +1,26 @@
+# 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.