b6cbe5a47e
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>
42 lines
1.4 KiB
Markdown
42 lines
1.4 KiB
Markdown
# Add Key Preview Containment
|
|
|
|
Date: 2026-03-31
|
|
Owner: Senior Frontend Engineer
|
|
Related items:
|
|
|
|
- `plans/2026-03-31-add-key-phase-boundary.md`
|
|
- `docs/redis-gui-v1-product-requirements.md`
|
|
- `docs/frontend-workspace-baseline.md`
|
|
- `docs/qa/acceptance-matrix.md`
|
|
|
|
## Goal
|
|
|
|
Keep the already-implemented `Add Key` surface visible without letting it read like approved `desktop-v1` scope.
|
|
|
|
## Decision
|
|
|
|
- Do not hide the flow in this worktree.
|
|
- Use the PM-approved fallback containment path instead: visible `Preview` labeling in the key-browser header and inside the Add Key dialog.
|
|
- Keep docs and QA wording aligned so the visible preview label and the acceptance boundary say the same thing.
|
|
|
|
## Scope
|
|
|
|
- add a visible preview label beside the `Add key` entry point
|
|
- repeat the preview label inside the dialog header
|
|
- make the dialog description explicit that Add Key stays outside current `desktop-v1` baseline acceptance
|
|
- sync shared README and QA/frontend docs
|
|
|
|
## Non-Goals
|
|
|
|
- no Add Key contract change
|
|
- no Add Key workflow expansion
|
|
- no current-phase reclassification
|
|
- no hide-or-gate implementation
|
|
|
|
## Acceptance
|
|
|
|
- operators can see from the shell that `Add Key` is preview inventory rather than baseline scope
|
|
- docs do not describe the visible Add Key entry as approved `desktop-v1` acceptance
|
|
- `pnpm --filter @redis-gui/desktop test` passes
|
|
- `pnpm run desktop:build` passes
|