paperclip-bot/redis-gui-foundation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cmp-35-desktop-integration-baseline
redis-gui-foundation/plans/2026-03-31-add-key-phase-boundary.md
Senior Frontend Engineer b6cbe5a47e docs(project): refresh baseline verification artifacts 
Check in the PM product requirements, refreshed QA acceptance evidence, shared execution split plans, and current-phase status notes so the repo matches the current delivery baseline.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-03-31 10:15:39 +00:00

3.3 KiB
Raw Permalink Blame History

Add Key Phase Boundary Note

Date: 2026-03-31 Owner: Product Manager Related items:

  • docs/redis-gui-v1-product-requirements.md
  • plans/2026-03-31-hac-19-scope-classification.md
  • plans/2026-03-31-cto-handoff-current-phase.md
  • plans/2026-03-31-hac-24-add-key-frontend.md

Decision

The repository now contains an implemented Add Key path, including backend contract, desktop bridge, and visible frontend UI. PM does not reclassify this capability into the current desktop-v1 phase.

Current PM classification remains:

  • Add Key = desktop-v1.1 candidate
  • not part of current desktop-v1 acceptance
  • not part of current desktop-v1 release claim

Why This Needs An Explicit Note

Without a boundary note, the repository state can create a false product signal:

  • users or reviewers may assume visible UI equals approved current-phase scope
  • QA may accidentally mix Add Key evidence into current baseline sign-off
  • CTO may treat implementation presence as PM approval

The product decision remains scope-first, not code-presence-first.

PM Interpretation Of Current Repo State

  • Add Key is no longer only a backlog concept; it is now an implemented next-phase candidate in the repository.
  • That implementation does not change the PM-approved current-phase scope on its own.
  • The active product promise for desktop-v1 is still inspect, verify, string-fix, TTL-adjust, and safe-command workflows.

Current-Phase Rule

For desktop-v1 acceptance and release communication:

  • do not count Add Key as required current-phase functionality
  • do not count missing Add Key evidence as a blocker for current-phase sign-off
  • do not market or describe Add Key as part of the approved current baseline

Required Containment Before Any desktop-v1 Release Claim

The CTO should ensure one of these product-safe outcomes before current-phase release messaging:

  1. Preferred: hide or gate the Add Key entry from the desktop-v1 release surface.
  2. Acceptable fallback: keep the entry visible only if it is explicitly labeled as preview or next-phase, and keep its evidence and documentation separated from current-phase acceptance.

PM preference:

  • hide or gate is cleaner than visible-but-not-approved

Reason:

  • a visible unlabeled create flow reads like shipped scope to operators
  • that weakens the current phase boundary and confuses release judgment

QA Separation Rule

If QA validates Add Key before PM formally promotes it into an active phase:

  • store evidence separately from desktop-v1 baseline sign-off
  • do not let Add Key pass or fail alter the current baseline acceptance judgment
  • treat it as future-phase evidence or preview evidence only

CTO Guidance

CTO may keep the implementation in-repo, but should not let that implementation silently redefine product scope.

Current CTO-safe interpretation:

  • baseline closure remains the priority
  • Add Key remains next-phase inventory
  • any user-visible release narrative for the current phase must keep Add Key out unless PM explicitly reclassifies it

Future Reclassification Trigger

PM can reconsider Add Key promotion only after:

  • current baseline evidence is materially closed
  • the visible release surface is stable enough to absorb one more workflow
  • QA can keep Add Key evidence cleanly separated or deliberately fold it into a new accepted phase