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>
119 lines
5.1 KiB
Markdown
119 lines
5.1 KiB
Markdown
# 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.
|