# 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