docs(qa): codify desktop integration baseline governance

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

docs/qa/integration-baseline-governance.md

@@ -0,0 +1,70 @@
+# Integration Baseline Governance
+
+Date: 2026-03-31
+Owner: CTO
+
+## Purpose
+
+Keep issue status aligned with the code branch that QA and manual testers actually use.
+
+## Current Desktop Baseline
+
+- Current designated desktop integration branch: `cmp-35-desktop-integration-baseline`
+- Source issue: `HAC-35`
+- Intended consumers:
+  - QA smoke and acceptance work
+  - manual product review
+  - release-readiness spot checks for the current desktop phase
+
+## Required Delivery States
+
+Engineering work now has three separate states:
+
+1. `implemented`
+   - code exists on the issue branch
+2. `verified`
+   - issue-scoped test or build evidence exists
+3. `integrated`
+   - the verified change exists on the designated shared integration branch
+
+An issue is only fully complete after it reaches `integrated`.
+
+## Required Handoff Rule
+
+Before an engineer or manager closes a delivery issue, the issue record must identify:
+
+- work branch
+- final commit SHA
+- push target
+- verification result
+- designated integration branch
+- whether the change is already present on that integration branch
+
+If the change is not yet present on the integration branch, the issue should stay open or be explicitly marked as waiting for integration.
+
+## Baseline Branch Rules
+
+- The integration baseline branch must be explicit and named in the owning integration issue.
+- QA should always test from that branch, not from a hand-built local composition of "done" branches.
+- When a new integration branch supersedes the old one, the superseding issue must publish:
+  - the new branch name
+  - what source branches or commits were absorbed
+  - whether conflicts were resolved
+  - the verification commands and outcomes
+- A completed feature branch does not become the test baseline automatically.
+
+## Conflict Resolution Rule
+
+When completed branches overlap, the integration owner must:
+
+- state the preserved base branch
+- state the absorbed source branches or SHAs
+- record which files needed manual conflict resolution
+- re-run the minimum branch-level verification after resolution
+
+## Minimum Verification For Desktop Integration
+
+- `pnpm --filter @redis-gui/desktop test`
+- `pnpm run desktop:build`
+
+Additional verification may still be required by QA or release readiness, but these two commands are the minimum gate before the integration branch can be handed off as the current desktop test baseline.