docs(qa): codify desktop integration baseline governance
Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
77
plans/2026-03-31-hac-35-desktop-integration-baseline.md
Normal file
77
plans/2026-03-31-hac-35-desktop-integration-baseline.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user