# HAC-20 V1 Scope Adjustment Decomposition

Date: 2026-03-30 UTC
Owner: CTO
Source issue: [HAC-20](/HAC/issues/HAC-20)
Decision dependency: [HAC-19](/HAC/issues/HAC-19)

## Verified Current Product State

- The repository is now present at `/workspace/repo/redis-gui-foundation`; the 2026-03-27 CTO environment gap is no longer active.
- The desktop app already has a visible React + Tauri shell with live bridges for connection test, key browse, typed value inspect, string save, TTL update, and command execution.
- There is no implemented `Add Key` or `Create Key` flow in the current desktop code.
- There is no visible i18n or locale infrastructure in the current desktop code for `zh-CN` / `en-US`.
- The current visual token set is not a blue primary direction. The shared CSS tokens are still beige/green oriented.
- Current validation evidence in this heartbeat:
  - `cargo test -p redis-core`: 16 tests passed
  - `pnpm --filter @redis-gui/desktop test`: 13 tests passed
  - `pnpm run desktop:build`: passed
  - `pnpm run desktop:tauri:build`: passed and produced Linux `.deb` and `.rpm`
  - `pnpm run desktop:tauri:build:all`: not re-run in this plan after the stable Linux bundle pass; the latest repo evidence still treats AppImage as non-default and unstable
  - `./scripts/redis-fixture/start.sh && seed.sh && stop.sh`: passed

## Gate Before Task Creation

- [HAC-20](/HAC/issues/HAC-20) must not create implementation issues until [HAC-19](/HAC/issues/HAC-19) classifies each request into `desktop-v1`, `desktop-v1.1`, or `later`.
- Current blocker is product scope, not engineering readiness.
- The repo is stable enough to support follow-on implementation once PM scope is explicit.

## 2026-03-31 Product-Spec Update

- The repo now contains `docs/redis-gui-v1-product-requirements.md`, an active PM-owned product spec dated 2026-03-30.
- The missing companion artifact referenced by [HAC-2](/HAC/issues/HAC-2) has been restored in-repo at `plans/2026-03-27-redis-gui-foundation-product-plan.md`.
- That PM product spec explicitly excludes create-new-key workflows from the current phase.
- Inference from the same PM spec: blue visual refresh, bilingual UI, and roadmap-gap work are also not approved into the current phase because they are absent from current-phase included scope and acceptance standards.
- CTO conclusion from the currently inspectable PM source: there are no newly approved implementation items to add to the current V1 execution queue from [HAC-20](/HAC/issues/HAC-20).
- The remainder of this decomposition should therefore be treated as a future-phase template, not as an active implementation split for the current phase.

## 2026-03-31 Scope-Classification Update

- PM later provided an explicit classification artifact at `plans/2026-03-31-hac-19-scope-classification.md`.
- That classification confirms:
  - Blue visual refresh -> `later`
  - Add Key -> `desktop-v1.1`
  - Bilingual UI -> `later`
  - Roadmap-gap to engineering epics -> `later`
- CTO execution decision from that artifact:
  - create no new `desktop-v1` execution issues from this request set
  - create backlog issues only for the `desktop-v1.1` Add Key slice
  - keep the `later` items out of implementation planning for now

Created backlog issues:

- [HAC-23](/HAC/issues/HAC-23): backend Add Key contract and desktop bridge
- [HAC-24](/HAC/issues/HAC-24): desktop Add Key entry, form, and refresh flow
- [HAC-25](/HAC/issues/HAC-25): QA and release-readiness coverage for Add Key

## Engineering-Ready Decomposition Once PM Confirms Scope

### 1. Blue visual adjustment

Create only if PM puts the item into `desktop-v1`.

Recommended issue split:

- `redis-gui-desktop-v1`
  - Frontend issue
  - Owner: Senior Frontend Engineer
  - Scope:
    - replace current neutral/accent tokens with approved blue direction
    - retune shell surfaces, focus states, selection, banners, and destructive contrast
    - preserve current information architecture and interaction model unless PM explicitly expands scope
  - Acceptance:
    - shared token set updated
    - shell remains readable in light and dark modes
    - key browse, inspector, command tray, dialogs, and banners use the approved theme consistently

- `redis-gui-release-readiness`
  - QA issue
  - Owner: QA Engineer
  - Scope:
    - refresh acceptance screenshots and visual smoke checklist for the approved theme shift

Dependency chain:

- frontend visual refresh -> QA regression

### 2. Add Key capability

Create only if PM puts the item into `desktop-v1`.

Recommended issue split:

- `redis-gui-foundation`
  - Backend issue
  - Owner: Senior Backend Engineer
  - Scope:
    - add a key-creation contract to `redis-core` and Tauri bridge
    - keep V1 explicitly gated to string-key creation only
    - support optional TTL at creation time so the UI does not need a second write to complete the happy path
    - reject overwrite-by-default; duplicate key names must fail explicitly
  - Acceptance:
    - create string key with and without TTL
    - duplicate key attempt returns stable error
    - created key is visible to browse and inspect flows immediately

- `redis-gui-desktop-v1`
  - Frontend issue
  - Owner: Senior Frontend Engineer
  - Scope:
    - add a prominent `Add Key` entry after connection is active
    - add create form for key name, string value, and optional TTL
    - refresh browser and inspector after successful creation
    - render duplicate-key and validation failures through the shared notice layer
  - Acceptance:
    - connected user can create a string key end to end
    - new key becomes selected or visibly discoverable after submit
    - failure path does not destroy typed form state

- `redis-gui-release-readiness`
  - QA issue
  - Owner: QA Engineer
  - Scope:
    - extend acceptance matrix and local smoke path with key-creation coverage

Dependency chain:

- backend create-key contract -> frontend entry/form -> QA regression

### 3. Bilingual support (`zh-CN` / `en-US`)

Create only if PM puts the item into `desktop-v1`.

Recommended issue split:

- `redis-gui-foundation`
  - Frontend platform issue
  - Owner: Senior Frontend Engineer
  - Scope:
    - establish i18n runtime, message catalog structure, locale detection, fallback strategy, and persistence boundary
    - default strategy: follow system locale when supported, otherwise fall back to `en-US`
    - allow explicit manual override in desktop shell state
    - localize backend error-code mapping at the frontend notice layer; do not attempt to localize raw Redis command output
  - Acceptance:
    - `zh-CN` and `en-US` catalogs load through one adapter
    - fallback and override rules are deterministic

- `redis-gui-desktop-v1`
  - Frontend product issue
  - Owner: Senior Frontend Engineer
  - Scope:
    - extract visible shell copy into message catalogs
    - add language switcher and apply localized UI copy to current V1 surfaces
  - Acceptance:
    - all primary shell copy on the current V1 surface is localized
    - switching language updates visible UI without requiring a rebuild

- `redis-gui-release-readiness`
  - QA issue
  - Owner: QA Engineer
  - Scope:
    - add bilingual smoke and fallback-language checks

Dependency chain:

- i18n foundation -> visible shell localization -> QA regression

### 4. Gap analysis to roadmap engineering epics

Do not turn this into feature implementation work until PM classifies the capability groups.

Recommended follow-up after PM decision:

- PM keeps ownership of product taxonomy and `V1 / V1.1 / later` classification.
- Project Manager updates milestone grouping and sequencing.
- CTO creates or updates engineering epics only for categories that are explicitly approved to move into engineering planning.

Expected output shape:

- one engineering epic per approved capability family
- milestone group
- dependency order
- explicit current non-goals

## First-Round Owner Map

- Senior Backend Engineer: create-key backend contract if and only if Add Key enters current V1
- Senior Frontend Engineer: blue visual refresh, Add Key UX flow, i18n foundation, localized shell
- QA Engineer: acceptance and smoke updates for each approved user-visible scope change
- Product Manager: final scope classification in [HAC-19](/HAC/issues/HAC-19)
- Project Manager: milestone and dependency scheduling after PM classification

## Recommended Execution Order After PM Decision

1. PM closes scope classification in [HAC-19](/HAC/issues/HAC-19).
2. CTO creates only the approved child issues and assigns owners.
3. If Add Key is approved, backend contract starts before frontend flow.
4. If bilingual support is approved, i18n foundation starts before shell-wide copy extraction.
5. Blue visual work can run in parallel with backend and i18n foundation because it is largely UI-surface scoped.
6. QA regression issues should start only after the corresponding implementation issue lands or reaches review.

## Risks To Keep Explicit

- [HAC-19](/HAC/issues/HAC-19) still lacks control-plane comments or documents even though PM scope now exists in the repo; this is a Paperclip traceability gap.
- Linux `.deb` and `.rpm` packaging is stable, but AppImage is still not established as the default bundle path.