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.

plans/2026-03-31-hac-22-db-switcher-hardening.md

@@ -17,13 +17,12 @@ Scope: `desktop-v1` user-visible frontend hardening only
 - Keep the existing rail placement and interaction model for the DB switcher.
 - Widen the visible DB switcher to a predictable default operator range and ensure the currently active DB remains selectable even when it falls outside the default range.
 
-## Planned Implementation
+## Implemented Slice
 
-1. Add a shared frontend helper that returns DB labels for the switcher.
-2. Default the visible range to `db0` through `db15`.
-3. If the active DB falls outside that range, inject it into the visible list and keep the options numerically ordered.
-4. Cover the helper with focused Vitest cases.
-5. Update shared frontend and QA docs so runbooks no longer imply a four-item-only DB switcher.
+1. Added a shared frontend helper that returns DB labels for the switcher.
+2. Defaulted the visible range to `db0` through `db15`.
+3. Preserved the currently active DB when it falls outside that range and kept the options numerically ordered.
+4. Covered the helper with focused Vitest cases.
 
 ## Acceptance
 

plans/2026-03-31-hac-28-connection-context-lifecycle.md

@@ -33,7 +33,7 @@ Harden connection-context and session-state clarity without changing backend con
 2. Update `apps/desktop/src/App.tsx` so:
    - the utility rail shows a clear active connection session card
    - the test button distinguishes active-scope testing from another in-flight connection test
-   - live test completion only reapplies DB scope when the same connection is still active
+   - live test completion only reapplies the returned DB scope when the same connection is still active
 3. Revalidate frontend tests and production build.
 
 ## Acceptance

plans/2026-03-31-hac-35-desktop-integration-baseline.md

@@ -0,0 +1,77 @@
+# HAC-35 Desktop Integration Baseline
+
+Date: 2026-03-31 UTC
+Owner: CTO
+Issue: HAC-35
+Current QA branch: `cmp-35-desktop-integration-baseline`
+Base branch: `cmp-31-safe-mutation-guardrails`
+
+## Why This Exists
+
+- `cmp-22-db-switcher-hardening`, `cmp-28-connection-context-lifecycle`, and `cmp-30-inspector-readability-path` were already marked done, but they were not all present on the branch QA would actually pull for current desktop verification.
+- That mismatch made the control plane report "done" while the real testable branch still lagged behind.
+- `HAC-35` fixes the immediate branch state and establishes a stricter closure rule for future engineering issues.
+
+## Integrated Branch Result
+
+- Unified QA / manual-test branch: `cmp-35-desktop-integration-baseline`
+- Base preserved from `cmp-31-safe-mutation-guardrails` at `b6cbe5a`
+- Integrated source branches:
+  - `cmp-22-db-switcher-hardening` at `04da063`
+  - `cmp-30-inspector-readability-path` at `9697447`
+  - `cmp-28-connection-context-lifecycle` at `4839165`
+- Merge commits on the unified branch:
+  - `0edeb27` merged `cmp-22-db-switcher-hardening`
+  - `5b1cb35` merged `cmp-30-inspector-readability-path`
+  - `f890809` merged `cmp-28-connection-context-lifecycle`
+
+## Conflict Handling
+
+The source branches were not cleanly stacked. They overlapped on `App.tsx`, README / QA docs, and helper files that had already drifted on `cmp-31`.
+
+Resolution policy used for this integration:
+
+1. Keep the newer baseline content already present on `cmp-31` when it was strictly more complete.
+2. Reintroduce the missing finished feature slices from `cmp-22`, `cmp-28`, and `cmp-30`.
+3. Prefer the more complete helper implementation when duplicate helper files existed with near-identical intent.
+4. Keep QA and README text aligned to the integrated branch's actual test count and visible capability set.
+
+Net result:
+
+- DB switcher hardening from `HAC-22` is present on the integrated branch.
+- Inspector readability path from `HAC-30` is present on the integrated branch.
+- Connection-session lifecycle hardening from `HAC-28` is present on the integrated branch.
+- The integrated branch still preserves the later baseline work that already lived on `cmp-31`.
+
+## Verification
+
+Executed on `cmp-35-desktop-integration-baseline` after all merges resolved:
+
+- `pnpm --filter @redis-gui/desktop test`
+  - pass
+  - 12 files / 48 tests
+- `pnpm run desktop:build`
+  - pass
+
+## Current Operating Rule
+
+For the current desktop phase, QA and manual testing should pull `cmp-35-desktop-integration-baseline` instead of assembling multiple closed issue branches by hand.
+
+If a newer integration branch replaces it later, the replacing issue must update:
+
+- the current integration branch name
+- the merge result summary
+- the verification summary
+- the branch governance document
+
+## Future Closure Standard
+
+An engineering issue is not truly complete until all of the following are true:
+
+1. Scope implementation is complete on its working branch.
+2. The issue-level verification has passed and is recorded.
+3. The change has been merged into the designated integration baseline branch for its phase.
+4. The issue comment includes branch name, commit SHA, push target, verification summary, and known risk.
+5. QA can test the capability from one unified branch without manually composing other completed issue branches.
+
+If step 3 is missing, the issue may be code-complete, but it is not integration-complete and should not be treated as fully delivered.