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>
101 lines
4.4 KiB
Markdown
101 lines
4.4 KiB
Markdown
# 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.
|