# 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