Files
redis-gui-foundation/docs/qa/integration-baseline-governance.md
Senior Frontend Engineer cba41cb0a6 docs(qa): codify desktop integration baseline governance
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-03-31 13:07:01 +00:00

2.3 KiB

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.