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-hac-19-scope-classification.md

@@ -0,0 +1,118 @@
+# HAC-19 Scope Classification
+
+Date: 2026-03-31
+Owner: Product Manager
+Decision target: [HAC-19](/HAC/issues/HAC-19)
+Related dependency: [HAC-20](/HAC/issues/HAC-20)
+Primary source: `docs/redis-gui-v1-product-requirements.md`
+
+## Decision Summary
+
+PM scope classification for the current request set:
+
+| Request | Classification | PM Decision |
+| --- | --- | --- |
+| Blue visual refresh | `later` | Not approved for the current desktop baseline or the next closure slice |
+| Add Key | `desktop-v1.1` | Candidate next-phase capability after current baseline evidence is closed |
+| Bilingual UI (`zh-CN` / `en-US`) | `later` | Not approved for the current operator baseline |
+| Roadmap-gap to engineering epics | `later` | Planning input only after product phase is explicitly expanded |
+
+There are no newly approved `desktop-v1` implementation items in this classification.
+
+## Why Nothing Enters `desktop-v1`
+
+The current product phase is still a live desktop operator baseline centered on:
+
+- connection test
+- browse and search
+- typed inspect
+- existing-string save
+- TTL set and remove
+- safe command execution
+
+That baseline is implemented but not yet fully accepted with end-to-end live desktop evidence. Expanding scope before that evidence is closed would dilute the current phase and make acceptance less defensible.
+
+## Classification Rationale
+
+### 1. Blue visual refresh -> `later`
+
+Reasoning:
+
+- The current user problem is workflow safety and clarity, not visual identity mismatch.
+- No acceptance blocker in the current PM spec requires a blue theme in order to validate operator usefulness.
+- A visual-direction change would create regression surface across the shell without improving the core Redis task loop enough to outrank current evidence and hardening gaps.
+
+Product stance:
+
+- Keep the current visual system acceptable and stable for the baseline.
+- Revisit a theme refresh only after the operator workflow is accepted and there is a business reason to rebrand or reposition the surface.
+
+### 2. Add Key -> `desktop-v1.1`
+
+Reasoning:
+
+- Create-key workflows are useful, but they are not required to validate the current operator baseline.
+- The present product goal is faster and safer inspect, verify, string-fix, TTL-adjust, and safe-command work.
+- Add Key is a plausible next functional expansion once the baseline is accepted, especially for QA and engineers preparing test data.
+- It should not enter the current phase because current acceptance is still blocked on evidence for already-implemented workflows.
+
+Product stance:
+
+- Treat Add Key as the highest-likelihood next feature after current baseline closure.
+- If scheduled, keep it narrow:
+  - string key only
+  - optional TTL at creation time
+  - explicit duplicate-key failure
+  - no implicit overwrite
+
+### 3. Bilingual UI (`zh-CN` / `en-US`) -> `later`
+
+Reasoning:
+
+- There is no validated current-phase user requirement showing that language support is blocking adoption of the baseline.
+- i18n infrastructure would cut across the full shell and introduce broad copy extraction and QA scope.
+- This work does not improve the core Redis operator loop as directly as closing existing evidence, persistence direction, or future create-key support.
+
+Product stance:
+
+- Do not open i18n implementation work in the current phase.
+- Reassess only if user targeting changes or bilingual rollout becomes a business requirement.
+
+### 4. Roadmap-gap to engineering epics -> `later`
+
+Reasoning:
+
+- Roadmap-gap analysis is not a user-visible feature and should not generate implementation epics until PM expands product scope.
+- Creating epics too early invites engineering inventory without product approval.
+
+Product stance:
+
+- Keep this as planning follow-up after the next product phase is approved.
+
+## What CTO Can Do Now
+
+The CTO can use this classification immediately:
+
+- create no new `desktop-v1` implementation issues from the current HAC-20 request set
+- keep the current execution queue focused on baseline evidence and hardening
+- prepare `desktop-v1.1` decomposition only for Add Key, and only after baseline closure is on track
+- hold blue visual and bilingual work out of implementation planning for now
+
+## Priority Order After Current Baseline Closes
+
+If the team needs the next product-facing expansion decision, PM priority is:
+
+1. `desktop-v1.1` candidate: Add Key, limited to safe string-key creation
+2. Follow-on baseline hardening still likely outranks cosmetic or locale expansion
+3. Blue visual refresh and bilingual UI remain lower-priority future work unless new user evidence changes the ordering
+
+## Acceptance Guardrails For Any Future `desktop-v1.1` Add Key Approval
+
+- User can create a new string key with or without TTL from the active connection and DB context.
+- Duplicate key names fail clearly and do not overwrite existing data.
+- Successful creation refreshes browser and inspector context without reconnecting.
+- Validation and backend failures preserve typed form state and use the shared notice layer.
+
+## Traceability Note
+
+This file is the PM-side classification artifact that the CTO decomposition in `plans/2026-03-30-hac-20-v1-scope-adjustment-decomposition.md` was waiting on.