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>

plans/2026-03-31-add-key-phase-boundary.md

@@ -0,0 +1,86 @@
+# 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