# 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.