redis-gui-foundation/plans/2026-03-31-hac-19-scope-classification.md

HAC-19 Scope Classification

Date: 2026-03-31 Owner: Product Manager Decision target: HAC-19 Related dependency: 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.