redis-gui-foundation/plans/2026-03-27-redis-gui-foundation-product-plan.md

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

Purpose

This file restores the product-plan artifact referenced in the completion comment for 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.