Files

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

1.4 KiB

Raw Blame History

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

1.4 KiB Raw Blame History