paperclip-bot/redis-gui-foundation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(project): refresh baseline verification artifacts

Browse Source 
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>
This commit is contained in:
Senior Frontend Engineer
2026-03-31 10:15:39 +00:00
parent 9c404d54a0
commit b6cbe5a47e
30 changed files with 1619 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
plans/2026-03-27-hac-15-desktop-build-smoke.md
View File

@@ -29,10 +29,14 @@ Make the desktop repository usable through one stable build path, one stable pac
- Passed: `./scripts/redis-fixture/start.sh`
- Passed: `./scripts/redis-fixture/seed.sh`
- Passed: `./scripts/redis-fixture/stop.sh`
- In progress: `pnpm run desktop:tauri:build` now clears the pre-build script failure and reaches Cargo dependency download and compile steps
- Passed: `pkg-config --modversion gtk+-3.0`
- Passed: `pkg-config --modversion webkit2gtk-4.1`
- Passed: `pkg-config --modversion libsoup-3.0`
- Passed: `pnpm run desktop:tauri:build`
- Evidence: Linux package artifacts were emitted under `target/release/bundle/`, including `.deb` and `.rpm`
## Remaining Risk
- This heartbeat has not yet produced a saved unsigned package artifact for Linux, macOS, or Windows.
- First-run Cargo package downloads remain slow and can serialize on the shared package-cache lock, so package verification should be rerun in a clean single-build window.
- End-to-end smoke evidence inside the desktop UI still depends on frontend surfaces that are only partially implemented.
- `HAC-15` exit criteria are satisfied for the documented stable Linux path, but macOS and Windows packaging remain outside this issue's validated evidence set.
- The separate `pnpm run desktop:tauri:build:all` path still has AppImage-stage risk and should not replace the stable QA packaging command.
- End-to-end GUI smoke evidence still depends on a human-run desktop session with screenshots or QA snapshot capture.

11
plans/2026-03-27-qa-acceptance-baseline.md
View File

@@ -23,14 +23,13 @@ Create the first acceptance matrix and cross-platform smoke plan for Redis GUI V
## Known Blockers
- `npm run desktop:tauri:build` currently fails because its pre-build command targets a non-existent parent `build` script.
- Repository does not yet contain Docker, demo, or seed assets.
- Current automated coverage is limited to foundation-model tests in `crates/redis-core`.
- Completed issue comments for `HAC-2` and `HAC-8` reference shared files that are absent from the current workspace, so QA cannot inspect those artifacts locally.
- Existing Rust test artifacts in `target/` are stale relative to current source, so backend baseline verification needs a fresh `cargo test` rerun.
- `pnpm run desktop:tauri:build:all` still fails in the AppImage stage with `failed to run linuxdeploy`.
- Linux `.deb` and `.rpm` bundles now exist, but macOS and Windows artifact evidence is still absent.
- The local fixture and smoke runbook are reproducible, but saved Tauri-window smoke evidence is still missing.
- The current QA environment still has no GUI-capable `DISPLAY`, `WAYLAND_DISPLAY`, or `xvfb-run`, so real-window screenshot capture is blocked in this session even though the desktop binary is built.
## Alignment
- Product acceptance source: `HAC-2` issue scope and completion comment remain the current acceptance baseline for connect, browse, search, edit, and command console flows.
- CTO priority source: `HAC-15` is now the high-priority owner for Tauri build, packaging, local smoke steps, and Redis fixture conventions.
- QA closure for this plan remains downstream of `HAC-15`, backend feature issues `HAC-5` to `HAC-7`, and frontend feature issues `HAC-9` to `HAC-11`.
- QA baseline closure for this plan is now materially achieved on Linux through the shared docs and repeatable smoke path; broader product release sign-off remains downstream of `HAC-15`, backend feature issues `HAC-5` to `HAC-7`, and frontend feature issues `HAC-9` to `HAC-11`.

100
plans/2026-03-27-redis-gui-foundation-product-plan.md Normal file
View File

@@ -0,0 +1,100 @@
# Redis GUI Foundation Product Plan
Original reference date: 2026-03-27
Reconstructed in repo: 2026-03-31
Owner: Product Manager
Primary source: `docs/redis-gui-v1-product-requirements.md`
Related issue: [HAC-2](/HAC/issues/HAC-2)
## Purpose
This file restores the product-plan artifact referenced in the completion comment for [HAC-2](/HAC/issues/HAC-2). The original referenced path was missing from the workspace; this version reconstructs the intended planning baseline from the in-repo product requirements document and the current verified repository state.
## Product Baseline
The current product direction is a desktop Redis operator tool for single-instance workflows. The product is intended to make routine inspect, verify, narrow string-fix, TTL-adjust, and safe-command tasks faster and safer than raw CLI in local, development, test, and staging environments.
## Current-Phase Scope
The current phase is a live desktop operator baseline, not a full product release.
Included:
- one active standalone Redis connection at a time
- connection draft creation with local validation
- live connection test in Tauri desktop mode
- visible active connection and DB context
- key browsing with incremental loading
- key-name and pattern search within the active DB
- typed inspection for `string`, `hash`, `list`, `set`, `zset`, and `stream`
- string replace for existing string keys only
- TTL set and TTL removal
- safe command execution with visible scope and blocked dangerous commands
- operator-facing error mapping
- local smoke fixture assist and QA snapshot support
- Linux packaging evidence for `.deb` and `.rpm`
Excluded from the current phase:
- create-new-key workflows
- real delete execution
- non-string editing
- multi-connection workflows
- cluster, Sentinel, replication, or topology awareness
- secret persistence and production-grade credential handling
- macOS and Windows acceptance
## User And Workflow Focus
Primary users:
- backend or full-stack engineers inspecting or repairing Redis data in non-production-like environments
- QA or support engineers validating key, value, and TTL behavior
- engineers debugging application state with safer context than CLI alone
Core workflow:
1. Create or select a connection profile.
2. Test the connection.
3. Enter the workspace with active connection and DB pinned.
4. Browse or search keys.
5. Inspect metadata and typed value structure.
6. Save a string value, update TTL, or run a safe command.
7. Verify the result in the same workspace.
## Engineering Boundary
The product baseline is intentionally narrow. It is intended to harden the existing live desktop workflow before any scope expansion into richer editing, destructive operations, or broader Redis administration.
Current product constraints that engineering must respect:
- browser mode remains demo-only
- desktop mode is the only valid Redis-backed acceptance path
- delete mock must not be treated as shipped delete capability
- string and TTL workflows must be evidenced before broader editing surface expands
- unsupported TLS modes remain outside current usable environments
## Planning Implication For Scope Adjustments
As of the reconstructed plan date:
- `Add Key` is not approved for the current phase because create-new-key workflows are explicitly excluded in `docs/redis-gui-v1-product-requirements.md`
- blue visual refresh is not approved into the current phase in the product baseline
- bilingual UI (`zh-CN` / `en-US`) is not approved into the current phase in the product baseline
- roadmap-gap analysis may continue as planning input, but not as current-V1 implementation scope
This means current engineering work should continue to focus on validating and hardening the shipped operator baseline rather than expanding visible scope.
## Exit Criteria For This Phase
- live desktop evidence exists for connect, browse, inspect, string save, TTL update, and command execution
- Linux build and packaging stay repeatable
- product requirements stay aligned with QA acceptance artifacts
- unsupported and non-goal surfaces remain explicitly gated
## Follow-On Productization Order
1. Complete live acceptance evidence for the current desktop baseline.
2. Close remaining release-readiness gaps on Linux and make platform gaps explicit.
3. Reassess whether Add Key, blue visual refresh, bilingual UI, or broader editing justify entry into a later phase.
4. Only then expand into persisted profiles, secret handling, real destructive flows, and wider data-type editing.

2
plans/2026-03-27-redis-gui-v1-status.md
View File

@@ -1,5 +1,7 @@
# Redis GUI V1 Status
Superseded on 2026-03-31 by `plans/2026-03-31-redis-gui-v1-status-refresh.md`.
Date: 2026-03-27 UTC
Project: `redis-gui-foundation`
Scope owner: Project Manager

13
plans/2026-03-28-frontend-smoke-validation.md
View File

@@ -14,8 +14,9 @@ Revalidate the current desktop frontend and packaging path against the repositor
2. Passed: `pnpm run desktop:build`
3. Passed: `./scripts/redis-fixture/start.sh`
4. Passed: `./scripts/redis-fixture/seed.sh`
5. Passed: `./scripts/redis-fixture/stop.sh`
6. Partial pass: `pnpm run desktop:tauri:build`
5. Passed: `pnpm run desktop:tauri:build`
6. Passed: `./scripts/redis-fixture/stop.sh`
7. Partial pass: `pnpm run desktop:tauri:build:all`
## Artifact Evidence
@@ -24,17 +25,17 @@ Revalidate the current desktop frontend and packaging path against the repositor
## Packaging Outcome
- Tauri build completed the Linux release binary and produced `.deb` and `.rpm` artifacts.
- The same run failed in the AppImage step with `io: Connection reset by peer (os error 104)`.
- The standard Linux packaging path now completes successfully: `pnpm run desktop:tauri:build` produces `.deb` and `.rpm` artifacts.
- The separate full-bundle path `pnpm run desktop:tauri:build:all` still fails in the AppImage step because `linuxdeploy` aborts.
## Remaining Gaps
- No saved Tauri-window screenshots or interaction logs exist yet for live browse, edit, TTL, or command flows.
- macOS and Windows package evidence remains absent.
- AppImage packaging needs a separate rerun or targeted investigation if that bundle format is required.
- AppImage packaging still needs a separate rerun or targeted investigation if that bundle format is required.
- This environment currently has no `DISPLAY`, `xvfb-run`, or desktop screenshot utility, so real-window visual evidence cannot be captured from this session alone.
- The desktop shell now includes a copyable QA snapshot so smoke context can still be recorded as text when screenshots are unavailable.
## Frontend Conclusion
The current repository is beyond shell-only validation: backend tests, browser build, Redis fixture bootstrapping, and Linux package generation all succeed in this environment. The next frontend validation step should happen in a launchable Tauri desktop session so QA can capture visual evidence for the live bridge workflows.
The current repository is beyond shell-only validation: backend tests, browser build, Redis fixture bootstrapping, and the standard Linux `.deb`/`.rpm` package path all succeed in this environment. The next frontend validation step should happen in a launchable Tauri desktop session so QA can capture visual evidence for the live bridge workflows while AppImage remains a separate packaging investigation.

34
plans/2026-03-28-hac-19-local-smoke-assist.md Normal file
View File

@@ -0,0 +1,34 @@
# HAC-19 Local Smoke Assist Surface
Date: 2026-03-28 UTC
Owner: Senior Frontend Engineer
Issue: HAC-19
## Goal
Reduce QA and engineer friction during local desktop smoke runs by exposing the existing Redis fixture path and its expected verification actions directly in the desktop shell.
## Selected Scope
- add one bounded utility-rail surface for the local Redis smoke fixture
- surface the seeded fixture target and expected keys without changing backend contracts
- add quick actions that switch to the fixture profile and prefill common smoke inputs such as `smoke:` search and safe read commands
- keep the rest of the desktop shell behavior, backend calls, and destructive boundaries unchanged
## Non-Goals
- no new backend or Tauri commands
- no fixture lifecycle control from the UI
- no destructive Redis execution path
- no visual redesign outside the current workspace language
## Verification Plan
- `pnpm --filter @redis-gui/desktop test`
- `pnpm run desktop:build`
## Expected User Impact
- QA can move from runbook to in-app validation with less manual typing
- smoke sessions become easier to reproduce because the fixture path is visible inside the shell
- browser demo mode and live desktop smoke mode remain clearly separated

27
plans/2026-03-30-frontend-verification-pass.md Normal file
View File

@@ -0,0 +1,27 @@
# Frontend Verification Pass
Date: 2026-03-30 UTC
Owner: Senior Frontend Engineer
Related issues: HAC-17, HAC-18, HAC-19
## Goal
Verify that the current desktop frontend state remains shippable for QA-facing Linux validation after the recent error-handling, structured-inspector, local-smoke-assist, icon, and packaging updates.
## Evidence Captured
1. Passed: `pnpm --filter @redis-gui/desktop test`
2. Passed: `pnpm run desktop:build`
3. Passed: `cargo test -p redis-core`
4. Passed: `pnpm run desktop:tauri:build`
## Verification Detail
- Frontend tests are 11 green across operator notices, structured inspector rendering helpers, and local smoke fixture helpers.
- The browser build completes successfully with the current desktop shell and utility-rail assist surfaces.
- The shared Rust backend core still passes 16 tests.
- The stable Linux packaging path still emits `.deb` and `.rpm` artifacts under `target/release/bundle/`.
## Current Conclusion
The current repository state is internally consistent for the documented stable Linux path: frontend tests, frontend build, backend tests, and standard `.deb`/`.rpm` packaging all succeed together. The remaining evidence gap is still GUI-capable smoke capture, not repository correctness on the validated build path.

204
plans/2026-03-30-hac-20-v1-scope-adjustment-decomposition.md Normal file
View File

@@ -0,0 +1,204 @@
# 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.

86
plans/2026-03-31-add-key-phase-boundary.md Normal file
View File

@@ -0,0 +1,86 @@
# Add Key Phase Boundary Note
Date: 2026-03-31
Owner: Product Manager
Related items:
- `docs/redis-gui-v1-product-requirements.md`
- `plans/2026-03-31-hac-19-scope-classification.md`
- `plans/2026-03-31-cto-handoff-current-phase.md`
- `plans/2026-03-31-hac-24-add-key-frontend.md`
## Decision
The repository now contains an implemented `Add Key` path, including backend contract, desktop bridge, and visible frontend UI. PM does not reclassify this capability into the current `desktop-v1` phase.
Current PM classification remains:
- `Add Key` = `desktop-v1.1` candidate
- not part of current `desktop-v1` acceptance
- not part of current `desktop-v1` release claim
## Why This Needs An Explicit Note
Without a boundary note, the repository state can create a false product signal:
- users or reviewers may assume visible UI equals approved current-phase scope
- QA may accidentally mix Add Key evidence into current baseline sign-off
- CTO may treat implementation presence as PM approval
The product decision remains scope-first, not code-presence-first.
## PM Interpretation Of Current Repo State
- `Add Key` is no longer only a backlog concept; it is now an implemented next-phase candidate in the repository.
- That implementation does not change the PM-approved current-phase scope on its own.
- The active product promise for `desktop-v1` is still inspect, verify, string-fix, TTL-adjust, and safe-command workflows.
## Current-Phase Rule
For `desktop-v1` acceptance and release communication:
- do not count Add Key as required current-phase functionality
- do not count missing Add Key evidence as a blocker for current-phase sign-off
- do not market or describe Add Key as part of the approved current baseline
## Required Containment Before Any `desktop-v1` Release Claim
The CTO should ensure one of these product-safe outcomes before current-phase release messaging:
1. Preferred: hide or gate the Add Key entry from the `desktop-v1` release surface.
2. Acceptable fallback: keep the entry visible only if it is explicitly labeled as preview or next-phase, and keep its evidence and documentation separated from current-phase acceptance.
PM preference:
- hide or gate is cleaner than visible-but-not-approved
Reason:
- a visible unlabeled create flow reads like shipped scope to operators
- that weakens the current phase boundary and confuses release judgment
## QA Separation Rule
If QA validates Add Key before PM formally promotes it into an active phase:
- store evidence separately from `desktop-v1` baseline sign-off
- do not let Add Key pass or fail alter the current baseline acceptance judgment
- treat it as future-phase evidence or preview evidence only
## CTO Guidance
CTO may keep the implementation in-repo, but should not let that implementation silently redefine product scope.
Current CTO-safe interpretation:
- baseline closure remains the priority
- Add Key remains next-phase inventory
- any user-visible release narrative for the current phase must keep Add Key out unless PM explicitly reclassifies it
## Future Reclassification Trigger
PM can reconsider Add Key promotion only after:
- current baseline evidence is materially closed
- the visible release surface is stable enough to absorb one more workflow
- QA can keep Add Key evidence cleanly separated or deliberately fold it into a new accepted phase

41
plans/2026-03-31-add-key-preview-containment.md Normal file
View File

@@ -0,0 +1,41 @@
# Add Key Preview Containment
Date: 2026-03-31
Owner: Senior Frontend Engineer
Related items:
- `plans/2026-03-31-add-key-phase-boundary.md`
- `docs/redis-gui-v1-product-requirements.md`
- `docs/frontend-workspace-baseline.md`
- `docs/qa/acceptance-matrix.md`
## Goal
Keep the already-implemented `Add Key` surface visible without letting it read like approved `desktop-v1` scope.
## Decision
- Do not hide the flow in this worktree.
- Use the PM-approved fallback containment path instead: visible `Preview` labeling in the key-browser header and inside the Add Key dialog.
- Keep docs and QA wording aligned so the visible preview label and the acceptance boundary say the same thing.
## Scope
- add a visible preview label beside the `Add key` entry point
- repeat the preview label inside the dialog header
- make the dialog description explicit that Add Key stays outside current `desktop-v1` baseline acceptance
- sync shared README and QA/frontend docs
## Non-Goals
- no Add Key contract change
- no Add Key workflow expansion
- no current-phase reclassification
- no hide-or-gate implementation
## Acceptance
- operators can see from the shell that `Add Key` is preview inventory rather than baseline scope
- docs do not describe the visible Add Key entry as approved `desktop-v1` acceptance
- `pnpm --filter @redis-gui/desktop test` passes
- `pnpm run desktop:build` passes

216
plans/2026-03-31-cto-handoff-current-phase.md Normal file
View File

@@ -0,0 +1,216 @@
# CTO Handoff For Current Phase
Date: 2026-03-31
Owner: Product Manager
Project: `redis-gui-foundation`
Primary sources:
- `docs/redis-gui-v1-product-requirements.md`
- `plans/2026-03-31-hac-19-scope-classification.md`
- `plans/2026-03-31-redis-gui-v1-status-refresh.md`
- `docs/qa/acceptance-matrix.md`
## Purpose
This handoff translates the current PM-approved product scope into execution-ready product slices for the CTO.
It is not an architecture document. It defines what must be made provable in the current phase, what must stay out, and what can be prepared only as a next-phase candidate.
## User And Problem
Primary users:
- backend or full-stack engineers inspecting and making low-risk Redis fixes in local, development, test, or staging environments
- QA or support engineers verifying key, value, and TTL behavior without relying on CLI fluency
Core problem:
- Redis CLI is flexible, but it hides connection and DB context too easily, raises the chance of destructive mistakes, and is slower for routine inspect or verify work
Product promise for the current phase:
- make the single-instance Redis operator loop safer and faster than raw CLI for inspect, verify, string-fix, TTL-adjust, and safe-command workflows
## Current Phase Definition
Current phase name:
- `desktop-v1` baseline hardening and acceptance closure
This phase is already implemented at a feature-baseline level. The remaining work is to make that baseline provable, repeatable, and clearly bounded.
## What Must Be True In This Phase
### 1. The core operator loop is the thing being accepted
The current phase is about proving this loop end to end:
1. create or select a connection profile
2. test the connection
3. enter the workspace with active connection and DB visible
4. browse or search keys
5. inspect key metadata and typed value structure
6. save a supported string value, update TTL, or run a safe command
7. verify the result in the same workspace
### 2. Current phase scope is intentionally narrow
Included:
- one active standalone Redis connection at a time
- local validation for profile draft creation
- live connection test in Tauri mode
- browse and key-name or pattern search in active DB
- typed inspection for `string`, `hash`, `list`, `set`, `zset`, and `stream`
- string replace for existing string keys only
- TTL set and TTL removal
- safe command execution with explicit scope
- consistent operator-facing error treatment
- repeatable local smoke-fixture path
### 3. Current phase acceptance is evidence-driven
Current phase should not be called accepted until there is live Tauri evidence for:
- connect
- browse
- inspect
- string save
- TTL update
- command execution
## What Must Stay Out In This Phase
The CTO should treat these as hard scope boundaries, not as optional backlog candidates for the active phase:
- real delete execution
- create-new-key workflows
- non-string editing
- cluster, Sentinel, replication, or topology features
- secret persistence and production-grade credential handling
- blue visual refresh
- bilingual UI (`zh-CN` / `en-US`)
- multi-connection compare workflows
- admin-level Redis operations
## Current Product Slices For CTO
These are the product slices that engineering and QA should use for current-phase execution.
### Slice 1: Connection Context Integrity
User value:
- operator always knows which Redis target and DB they are about to affect
Must be provable:
- draft validation is predictable
- active connection and DB stay visible
- connection test success and failure produce stable operator-facing outcomes
- browser demo mode remains visibly non-live
### Slice 2: Browse And Search Confidence
User value:
- operator can find the right key without CLI pagination or guesswork
Must be provable:
- browse works against live Redis in Tauri mode
- search stays scoped to the active DB
- empty and failure states are explicit
- metadata stays visible enough for safe selection
### Slice 3: Inspect And Understand
User value:
- operator can inspect the current key without mentally decoding raw protocol output
Must be provable:
- typed value surfaces are readable
- unsupported edit states are explicit
- inspector refresh reflects the selected key accurately
### Slice 4: Safe Mutation Boundary
User value:
- operator can make the smallest useful changes without stepping outside a safe product contract
Must be provable:
- only existing string keys are writable
- successful string save keeps TTL semantics intact
- TTL set and remove are visibly reflected after success
- failed write or TTL operations preserve user context
### Slice 5: Safe Command Boundary
User value:
- operator can run simple read or inspection commands without leaving the app
Must be provable:
- command scope is visible
- live and demo outputs are distinguishable
- blocked dangerous commands do not appear to succeed
### Slice 6: Acceptance Evidence Closure
User value:
- the product team can honestly say the current baseline works in real desktop runtime
Must be provable:
- a GUI-capable session exists for real Tauri smoke
- QA can capture screenshots or logs for the current operator loop
- Linux packaging remains repeatable for the accepted path
## CTO Execution Priority
The CTO should sequence current work in this order:
1. Unblock a GUI-capable Tauri smoke environment.
2. Close evidence for the already-implemented operator loop.
3. Keep Linux package evidence repeatable.
4. Decide whether AppImage is a required release path or an explicit non-default gap.
5. Only after the above, evaluate next-phase expansion.
## Next-Phase Candidate, But Not Current Phase
Only one request is currently approved as a plausible next-phase candidate:
- `Add Key` -> `desktop-v1.1`
Even this item should not enter active implementation until current baseline closure is materially on track.
Repository-state clarification:
- the repo now contains an implemented Add Key path
- that implementation does not change PM scope approval for the current phase
- before any `desktop-v1` release claim, CTO should either gate the Add Key surface or label it as preview and keep it outside current-phase acceptance
If it is pulled into the next phase, PM guardrails are:
- string-key creation only
- optional TTL at create time
- duplicate key names fail explicitly
- no implicit overwrite behavior
## Product-Level Risks CTO Should Keep Visible
- Delete UI affordance exists before real delete capability exists.
- Add Key is implemented in the repo ahead of current-phase approval, which can blur the release boundary if left visible without phase labeling.
- Current evidence gap is environmental and operational, not conceptual.
- Scope expansion before baseline acceptance will make product sign-off weaker, not stronger.
- Cross-platform release expectations are still ahead of current evidence.
## PM Decision Summary
The current phase is not asking engineering to invent a broader product. It is asking engineering and QA to prove, harden, and correctly bound the product that is already visible in the repository.

39
plans/2026-03-31-frontend-demo-state-hardening.md Normal file
View File

@@ -0,0 +1,39 @@
# Frontend Demo-State Hardening
Date: 2026-03-31 UTC
Owner: Senior Frontend Engineer
Scope: `desktop-v1` frontend hardening only
## Context
- `apps/desktop` is already the active frontend entry and contains the current four-zone Redis operator workspace.
- PM scope on 2026-03-31 did not approve new `desktop-v1` features such as `Add Key`, bilingual UI, or a visual refresh.
- Browser dev mode remains the primary shell-review path when Tauri runtime is unavailable.
## Problem
- In browser demo mode, the UI currently claims string save and TTL actions succeeded, but the visible mock key state does not update.
- That mismatch weakens shell review because browser-mode interaction feedback is less trustworthy even though it is explicitly demo-only.
## Decision
- Do not expand product scope.
- Keep the existing workspace information architecture and current visual system.
- Harden browser demo mode so session-local mock interactions update the visible browser, inspector, and command context consistently.
## Planned Implementation
1. Replace static demo key usage in `apps/desktop/src/App.tsx` with local state derived from the existing seed data.
2. Extract demo-state mutation helpers for:
- string value save
- TTL set
- TTL remove
3. Add focused frontend tests for those helpers.
4. Update shared run and QA docs to state that browser demo mode now supports session-local mock state changes, but still does not provide live Redis evidence.
## Acceptance
- In `pnpm run desktop:dev`, saving a string key updates the visible value surface and downstream mock command behavior for the current session.
- In `pnpm run desktop:dev`, TTL set and TTL remove update the visible TTL badges and inspector state for the current session.
- The UI continues to clearly distinguish browser demo fallback from live Tauri runtime.
- `pnpm --filter @redis-gui/desktop test` and `pnpm run desktop:build` remain green.

118
plans/2026-03-31-hac-19-scope-classification.md Normal file
View File

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

68
plans/2026-03-31-hac-21-execution-split.md Normal file
View File

@@ -0,0 +1,68 @@
# HAC-21 Execution Split
Date: 2026-03-31 UTC
Owner: CTO
Decision target: [HAC-21](/HAC/issues/HAC-21)
Scope inputs:
- [HAC-19](/HAC/issues/HAC-19)
- [HAC-20](/HAC/issues/HAC-20)
- `plans/2026-03-31-hac-19-scope-classification.md`
- `docs/redis-gui-v1-product-requirements.md`
## Decision Summary
- PM approved no new `desktop-v1` scope from the 2026-03-31 request set.
- CTO should therefore create no new current-phase scope-expansion issues for blue theme, bilingual UI, or Add Key.
- Current-phase execution remains valid only for baseline closure and hardening work that helps prove or stabilize the already-approved operator workflow.
- `Add Key` is the only approved follow-on candidate, and it stays in `desktop-v1.1` backlog until baseline closure is on track.
## Current Phase Execution Queue (`desktop-v1`)
No additional `desktop-v1` execution issues are created from the PM scope-classification request itself because no request was classified into `desktop-v1`.
The active execution queue for the current phase is:
| Issue | Owner | Priority | Dependency | Deliverables | DoD |
| --- | --- | --- | --- | --- | --- |
| [HAC-22](/HAC/issues/HAC-22) | Senior Frontend Engineer | medium | No new PM scope dependency; may proceed without GUI screenshot or AppImage gate | one user-visible baseline-hardening slice, verification summary, pushed branch/commit metadata | one clear user-visible `desktop-v1` improvement lands with minimal verification evidence and issue comment backfill |
| [HAC-26](/HAC/issues/HAC-26) | Senior Frontend Engineer | medium | none; may run in parallel with [HAC-22](/HAC/issues/HAC-22) if write scope is managed carefully | one reusable foundation hardening improvement, verification summary, pushed branch/commit metadata | at least one chosen foundation item lands with stable validation and issue comment backfill |
| [HAC-27](/HAC/issues/HAC-27) | QA Engineer | medium | latest pushed branches and artifacts from current baseline work, especially [HAC-22](/HAC/issues/HAC-22) and [HAC-26](/HAC/issues/HAC-26) when relevant | manual GUI smoke record, AppImage verification result, logs/screenshots or failure evidence, linked conclusion | QA produces a pass/fail record for real-window smoke and AppImage install/run attempts, with reproduction detail for failures |
## Why There Is No New `desktop-v1` Backend Issue
- Current backend baseline issues for connect, browse, inspect, string save, TTL, command execution, and Linux packaging are already delivered through earlier foundation work.
- The PM classification did not add any new backend-visible requirement into the current phase.
- The next meaningful backend change is `Add Key`, which is explicitly `desktop-v1.1`, not `desktop-v1`.
## Backlog Queue (`desktop-v1.1`)
These issues are valid but must remain in backlog until current baseline closure is judged on track:
| Issue | Owner | Priority | Dependency | Deliverables | DoD |
| --- | --- | --- | --- | --- | --- |
| [HAC-23](/HAC/issues/HAC-23) | Senior Backend Engineer | medium | baseline closure remains primary gate | backend create-key contract in `redis-core`, desktop bridge, validation/error path | live desktop runtime can create string keys with optional TTL, reject duplicates clearly, and surface created keys immediately |
| [HAC-24](/HAC/issues/HAC-24) | Senior Frontend Engineer | medium | depends on [HAC-23](/HAC/issues/HAC-23) | Add Key entry, create form, refresh flow, failure-state handling | operator can create a string key end to end without losing form state on validation or duplicate-key failure |
| [HAC-25](/HAC/issues/HAC-25) | QA Engineer | medium | depends on [HAC-23](/HAC/issues/HAC-23) and [HAC-24](/HAC/issues/HAC-24) | acceptance-matrix updates, smoke-path updates, future-phase evidence separation | Add Key happy path and failure path are covered without contaminating current baseline sign-off |
## Deferred (`later`)
No implementation issues should be created now for:
- blue visual refresh
- bilingual UI (`zh-CN` / `en-US`)
- roadmap-gap engineering epics
These remain planning-only until PM explicitly moves them into a later approved phase.
## Recommended Sequencing
1. Keep current execution focused on baseline closure through [HAC-22](/HAC/issues/HAC-22), [HAC-26](/HAC/issues/HAC-26), and [HAC-27](/HAC/issues/HAC-27).
2. Use QA evidence from [HAC-27](/HAC/issues/HAC-27) to determine whether the current operator baseline is defensibly accepted.
3. Only after baseline closure is on track, pull `Add Key` from backlog in order: [HAC-23](/HAC/issues/HAC-23) -> [HAC-24](/HAC/issues/HAC-24) -> [HAC-25](/HAC/issues/HAC-25).
## Risks To Keep Visible
- [HAC-19](/HAC/issues/HAC-19) still lacks a Paperclip-native comment/document trail that mirrors the repo-local PM classification artifact.
- Frontend has parallel execution pressure on [HAC-22](/HAC/issues/HAC-22) and [HAC-26](/HAC/issues/HAC-26); scope boundaries need to stay crisp to avoid churn.
- AppImage and real-window QA evidence remain a release-readiness risk until [HAC-27](/HAC/issues/HAC-27) reports back.

33
plans/2026-03-31-hac-22-db-switcher-hardening.md Normal file
View File

@@ -0,0 +1,33 @@
# HAC-22 DB Switcher Hardening
Date: 2026-03-31 UTC
Owner: Senior Frontend Engineer
Issue: HAC-22
Scope: `desktop-v1` user-visible frontend hardening only
## Context
- `apps/desktop` already ships a visible DB switcher, but the current UI only renders four fixed choices: `db0`, `db1`, `db2`, and `db5`.
- Current product scope already includes one active standalone Redis connection, explicit DB context, and DB-scoped browse / inspect / command flows.
- The hardcoded four-item list is weaker than the current product boundary and makes shell-level verification less representative for operators who need to move across common DB indexes.
## Decision
- Do not expand product scope or alter backend contracts.
- Keep the existing rail placement and interaction model for the DB switcher.
- Widen the visible DB switcher to a predictable default operator range and ensure the currently active DB remains selectable even when it falls outside the default range.
## Planned Implementation
1. Add a shared frontend helper that returns DB labels for the switcher.
2. Default the visible range to `db0` through `db15`.
3. If the active DB falls outside that range, inject it into the visible list and keep the options numerically ordered.
4. Cover the helper with focused Vitest cases.
5. Update shared frontend and QA docs so runbooks no longer imply a four-item-only DB switcher.
## Acceptance
- The visible DB switcher no longer depends on a four-item hardcoded list.
- Operators can select common DB indexes from `db0` through `db15` without editing connection drafts.
- An active DB outside the default range still appears in the switcher and stays selectable.
- `pnpm --filter @redis-gui/desktop test` and `pnpm run desktop:build` remain green.

56
plans/2026-03-31-hac-24-add-key-frontend.md Normal file
View File

@@ -0,0 +1,56 @@
# HAC-24 Add Key Frontend
Date: 2026-03-31 UTC
Owner: Senior Frontend Engineer
Issue: `HAC-24`
Phase: `desktop-v1.1` candidate
## Context
- `HAC-24` covers the frontend slice for Add Key only.
- The checked-out repo now exposes the Add Key backend and Tauri bridge contract:
- function: `create_value`
- request fields: `connection`, `key`, `value`, `ttl_millis`
- duplicate-key error code: `already_exists`
- result payload: `record`
- The frontend must not expand beyond string-only creation or add destructive follow-up actions.
## UI Decisions
- Add a visible `Add key` entry in the key-browser header rather than burying the flow in the utility rail or inspector.
- Keep the create surface in a dialog so active connection and DB remain visible while the form stays bounded.
- Scope the form to:
- key name
- string value
- optional TTL in milliseconds
- On success, focus the browser on the created key name so the new record is immediately visible and inspectable without reconnecting.
- Preserve typed form state on failure, including validation failure, duplicate-name failure, or an unexpected bridge regression.
## Implemented Frontend Slice
1. Added `apps/desktop/src/lib/add-key-draft.ts` plus focused tests for:
- key-name validation
- optional TTL parsing
- duplicate-name detection for demo mode
- demo key-record creation
2. Extended the shared notice layer with:
- `already_exists`
- `key_create`
so create-path validation and duplicate failures stay on the same operator-notice surface as the rest of the shell.
3. Added an `Add key` dialog to `apps/desktop/src/App.tsx` that:
- keeps connection and DB context visible
- exposes string-only copy and optional TTL input
- supports browser-demo creation with immediate browser/inspector refresh
- targets the live command `create_redis_value`
- preserves form state if a bridge error prevents create completion
## Verification
- `pnpm --filter @redis-gui/desktop test` -> pass (8 files / 29 tests)
- `pnpm run desktop:build` -> pass
- `cargo test -p redis-core` -> pass (20 tests, including Add Key create and duplicate-path coverage)
- `pnpm run desktop:tauri:build` -> pass (`.deb` and `.rpm` bundles emitted)
## Remaining Risk
- This environment still cannot launch a visible Tauri window, so final GUI-level Add Key smoke evidence remains a QA follow-up rather than a blocker on the implemented frontend slice.

46
plans/2026-03-31-hac-28-connection-context-lifecycle.md Normal file
View File

@@ -0,0 +1,46 @@
# HAC-28 Connection Context Lifecycle
Date: 2026-03-31
Owner: Senior Frontend Engineer
Issue: HAC-28
## Goal
Harden connection-context and session-state clarity without changing backend contracts or pulling next-phase scope into `desktop-v1`.
## Scope
- keep connection status copy consistent between the header, connection cards, and the active-session summary
- make ready, checking, demo, and retry-needed states visibly distinct in the utility rail
- prevent a finished live connection test from yanking the current active DB after the operator has already switched to another connection
- keep retry guidance explicit when a live test fails
- add focused frontend tests around the connection-session helper
## Non-Goals
- no Add Key expansion
- no delete execution
- no non-string editing
- no visual refresh
- no backend contract changes
## Delivery Shape
1. Add a shared connection-session helper for:
- connection test state transitions
- consistent status and connection-card copy
- visible active-session summary copy
2. Update `apps/desktop/src/App.tsx` so:
- the utility rail shows a clear active connection session card
- the test button distinguishes active-scope testing from another in-flight connection test
- live test completion only reapplies DB scope when the same connection is still active
3. Revalidate frontend tests and production build.
## Acceptance
- connection session state is visible as ready, testing, demo fallback, or retry needed
- connection-card detail and header status use the same wording model
- switching to another connection during a live test does not silently replace the current active DB when the earlier test returns
- failed live tests leave a clear retry path in visible UI copy
- `pnpm --filter @redis-gui/desktop test` passes
- `pnpm run desktop:build` passes

46
plans/2026-03-31-hac-30-inspector-readability.md Normal file
View File

@@ -0,0 +1,46 @@
# HAC-30 Inspector Readability
Date: 2026-03-31
Owner: Senior Frontend Engineer
Issue: HAC-30
## Goal
Improve inspector readability and operator understanding without changing backend contracts or pulling next-phase scope into the current desktop-v1 slice.
## Scope
- clarify current inspector state for live, demo, loading, and missing-key paths
- make value-surface semantics explicit for string and structured types
- keep next-step operator guidance visible near the inspector surface
- expose key facts in a stable summary card instead of relying on scattered badges and support copy
- add focused frontend tests for the readability helper
## Non-Goals
- no Add Key expansion
- no delete execution contract
- no non-string edit support
- no visual-theme refresh
- no bilingual UI pass
## Delivery Shape
1. Add a shared inspector-readability helper that maps selected key, live record, runtime mode, and edit capability into:
- inspect status
- value-surface title and description
- next-step operator guidance
- key facts
2. Use that helper in `apps/desktop/src/App.tsx` to:
- show an explicit inspector status badge
- add a semantic summary block above the value surface
- replace the previous generic support note with summary and facts cards
3. Revalidate frontend tests and production build.
## Acceptance
- inspector makes live string, structured read-only, demo fallback, loading, and missing-key paths visibly distinct
- operators can identify scope, type, TTL state, value shape, and write path without inferring them from raw payload text
- no backend contract change is required
- `pnpm --filter @redis-gui/desktop test` passes
- `pnpm run desktop:build` passes

111
plans/2026-03-31-redis-gui-v1-status-refresh.md Normal file
View File

@@ -0,0 +1,111 @@
# Redis GUI V1 Status Refresh
Date: 2026-03-31 UTC
Owner: Product Manager
Project: `redis-gui-foundation`
Supersedes: `plans/2026-03-27-redis-gui-v1-status.md`
## Current Judgment
The project is no longer in a "foundation-only" state. It now has an implemented desktop operator baseline, but it is not yet in release-ready state.
PM classification on 2026-03-31:
- Current phase: `desktop-v1` baseline hardening and acceptance closure
- Next likely expansion: `desktop-v1.1` candidate is `Add Key`, only after current baseline evidence closes
- Deferred: blue visual refresh, bilingual UI, and broader roadmap-gap engineering expansion
## Verified Product State
Based on the current in-repo artifacts:
- Product scope is inspectable in `docs/redis-gui-v1-product-requirements.md`.
- PM scope classification for `HAC-19` is inspectable in `plans/2026-03-31-hac-19-scope-classification.md`.
- The desktop app already has a visible React + Tauri shell rather than only a design baseline.
- The live Tauri path already exposes connection test, key browse, typed inspect, string save, TTL update, and command execution.
- Browser dev mode remains demo-only and is not valid evidence for Redis-backed acceptance.
- Delete is still mock-only and is not part of the shipped backend contract.
- QA evidence now confirms Linux `.deb` and `.rpm` packaging, browser entrypoint reproducibility, fixture reproducibility, and current test passes.
## Phase View
### 1. Product Baseline
Status:
- In place and inspectable
Meaning:
- User, problem, scope, non-goals, and acceptance standards are no longer the main blocker.
- The main PM responsibility is now scope protection and artifact alignment, not first-pass definition.
### 2. Desktop Baseline
Status:
- Implemented, but not fully accepted
Meaning:
- The app already supports the intended core operator loop for a single Redis instance.
- The remaining work is mostly acceptance evidence, environment closure, and selective hardening rather than first implementation discovery.
### 3. Release Readiness
Status:
- Blocked
Meaning:
- Live end-to-end Tauri evidence is still missing from a GUI-capable session.
- AppImage remains unverified.
- macOS and Windows evidence remain absent.
## Current Critical Path
The current path is no longer "product spec -> architecture -> repo bootstrap". It is:
1. Run live Tauri smoke in a GUI-capable environment.
2. Capture end-to-end evidence for connect, browse, inspect, string save, TTL update, and command execution.
3. Keep Linux packaging evidence repeatable.
4. Decide whether AppImage is required for current Linux release expectations or remains a non-default gap.
5. Only after baseline evidence closes, decide whether `Add Key` enters `desktop-v1.1`.
## CTO Attention Required
### 1. Protect the current phase boundary
- No new `desktop-v1` items were approved in the 2026-03-31 PM classification.
- Do not create implementation issues for blue visual refresh or bilingual UI.
- Treat `Add Key` as next-phase candidate only.
### 2. Solve the evidence environment gap
- The strongest current blocker is not product ambiguity. It is lack of a GUI-capable runtime session for real Tauri smoke evidence.
- Without that environment, QA can keep proving package and fixture reproducibility but cannot close Redis-backed desktop acceptance.
### 3. Keep destructive scope gated
- Delete confirmation exists in the shell, but real delete capability does not.
- Engineering and QA should continue to treat delete as unimplemented, not partially shipped.
### 4. Reframe cross-platform expectations
- Linux `.deb` and `.rpm` are currently the only inspectable stable package path.
- AppImage, macOS, and Windows should remain explicit release gaps rather than implied near-term deliverables.
## What Changed Since The 2026-03-27 Snapshot
- Product requirements now exist in-repo.
- The reconstructed product plan now exists in-repo.
- The desktop stack is no longer a plain Vite shell baseline; the React + Tauri workspace is implemented.
- Frontend acceptance baseline exists and QA evidence is materially stronger.
- The critical path has moved from foundation setup to evidence closure and release gating.
## PM Recommendation
- Keep current work focused on acceptance closure for the implemented baseline.
- Avoid scope expansion until the team can prove the current operator loop end to end in real desktop runtime.
- Once that closes, use `plans/2026-03-31-hac-19-scope-classification.md` as the gate for any next-phase expansion.