redis-gui-foundation/docs/redis-gui-v1-product-requirements.md

Redis GUI V1 Product Requirements

Date: 2026-03-30 Owner: Product Manager Status: Active working product spec

1. Document Purpose

This document defines the first usable product scope for the Redis desktop GUI based on the repository state inspected on 2026-03-30. It is intended to be specific enough for the CTO to split engineering work and for QA to validate acceptance.

This document supersedes the 2026-03-27 assumption that the workspace or demo was not accessible.

2. Current Demo Inventory On 2026-03-30

Confirmed from README.md, docs/architecture.md, docs/frontend-workspace-baseline.md, docs/qa/acceptance-matrix.md, docs/qa/local-desktop-smoke.md, apps/desktop/src/App.tsx, and apps/desktop/src-tauri/src/main.rs:

• The project now contains an inspectable desktop implementation path built around apps/desktop and a shared Rust core in crates/redis-core.
• Tauri desktop mode exposes live backend commands for backend_bootstrap, test_redis_connection, browse_redis_keys, inspect_redis_key, read_redis_value, write_redis_value, update_redis_key_ttl, and execute_redis_command.
• The visible desktop shell already implements the intended four-zone workspace: utility rail, browser pane, inspector pane, and command tray.
• Browser dev mode is intentionally a demo fallback. It does not pretend to be a live Redis runtime.
• The shell supports draft connection creation with local validation for profile name, host, port, and DB. Duplicate profile names are rejected in local shell state.
• Live connection testing exists in Tauri mode. Active connection and DB context stay visible in the workspace.
• Key browsing is wired to live SCAN-style pagination with type and TTL metadata.
• Search is currently key-name and pattern based within the active DB and reuses the browse contract.
• The inspector supports structured value viewing for string, hash, list, set, zset, and stream.
• Live editing is intentionally narrow: only existing string keys can be replaced as a whole value. The current TTL is preserved during string save.
• TTL update and TTL removal are already live in desktop mode.
• The command tray executes live commands in desktop mode and explicitly blocks FLUSH*, CONFIG*, and SHUTDOWN* from the visible shell.
• The shell includes a local smoke assist path for the seeded fixture on 127.0.0.1:6380 and a copyable QA snapshot for evidence capture.
• Linux packaging evidence now exists for .deb and .rpm. AppImage is still blocked. macOS and Windows smoke evidence do not yet exist.

Known gaps that remain product-significant:

• No persisted connection catalog or secret storage is enabled yet.
• Real key deletion is not implemented. The current delete confirmation is a mock-only flow.
• Non-string value editing remains unsupported.
• The accepted runtime target is still single-instance Redis, not cluster or Sentinel.
• TLS modes other than disabled are not actually supported by the backend yet.
• QA has not yet collected enough end-to-end live desktop evidence to mark Redis-backed feature acceptance as passed.

3. Target Users

Primary users:

• Backend or full-stack engineers who need to inspect and make low-risk fixes to Redis data in local, development, test, or staging environments.
• QA or support engineers who need to verify keys, values, and TTL behavior without relying on Redis CLI fluency.
• Engineers debugging application behavior who need visible DB context and safer workflows than raw shell commands.

Not the primary V1 user:

• Infra operators managing cluster topology, failover, replication, or production fleet administration.
• Users expecting observability dashboards, performance analytics, or admin-level server management.

4. Problem Statement

The target user needs a faster and safer way to inspect Redis data, verify key state, make narrow string fixes, adjust TTL, and run basic safe commands without falling back to raw CLI for every step.

Today, the fallback path is still Redis CLI or ad hoc shell commands. That path is efficient for experts but has three product problems:

• it hides active connection and DB context too easily
• it increases the chance of destructive mistakes
• it is slower for routine inspection, especially for typed values and TTL checks

5. Product Goal

Ship a desktop Redis operator tool for single-instance Redis workflows that makes routine inspect, verify, string-fix, TTL-adjust, and safe-command tasks faster and safer than raw CLI in local, dev, test, and staging environments.

6. Core Operator Flow

1. User selects or creates a connection profile.
2. User tests the connection before relying on the workspace.
3. User enters the workspace with the active connection and DB visibly pinned.
4. User browses or searches keys in the active DB.
5. User inspects metadata and value structure for the selected key.
6. User either saves a string value, updates TTL, or runs a safe command in the same scoped context.
7. User verifies the result immediately in the browser and inspector without reconnecting.

7. Current Phase Scope

7.1 Phase Definition

The current phase is not "full product release". It is a desktop operator baseline with live Redis-backed workflows for the smallest reliable surface that can support real usability testing and downstream hardening.

7.2 Included In The Current Phase

• One active standalone Redis connection at a time.
• Connection inputs for host, port, optional username, optional password, and DB index.
• Local validation for draft profile creation.
• Live connection test in Tauri desktop mode.
• Visible active connection and active DB context across the workspace.
• Key browsing with incremental loading through the current backend browse contract.
• Key-name and pattern search within the active DB.
• Metadata display for key name, key type, existence state, and TTL.
• Structured inspector views for string, hash, list, set, zset, and stream.
• String edit support only for existing string keys through whole-value replacement.
• TTL set and TTL removal for the selected key.
• Safe command execution in the active connection and DB context.
• Consistent operator-facing error banner mapping across connection, browse, inspect, save, TTL, and command flows.
• Local fixture assist and QA snapshot support for repeatable smoke runs.

7.3 Explicitly Not Included In The Current Phase

• Real delete execution.
• Create-new-key workflows.
• Editing support for hash, list, set, zset, or stream values.
• Multiple simultaneous connections or compare views.
• Cluster, Sentinel, replication, or topology awareness.
• SSH tunnel orchestration, secret vault integration, or production-grade credential persistence.
• Administrative or fleet-level Redis operations.
• Release sign-off for macOS or Windows.

8. Non-Goals

The following should stay out of V1 unless the CEO and CTO explicitly re-scope:

• Redis Cluster and Sentinel support.
• Replication insight, failover tooling, slot views, or topology diagrams.
• Pub/Sub tooling, monitor streams, slowlog, or performance dashboards.
• Value-content full-text search across all keys.
• Bulk actions, mass delete, import or export, migration, or schema management.
• Editing support for every Redis data type.
• Administrative commands such as FLUSHALL, CONFIG SET, or SHUTDOWN.
• Multi-pane workflows or collaborative operator features.

9. Acceptance Standards For This Phase

9.1 Runtime Mode Boundary

• Browser dev mode must remain explicitly demo-only.
• Desktop mode must clearly indicate that it is operating against live Redis.
• The UI must not blur demo output and live output.

9.2 Connection Management

• User can create a visible profile draft with validated host, port, DB, and name fields.
• User can run a live connection test in Tauri mode before treating the profile as usable.
• Workspace always shows the active connection and DB after selection.
• Connection failures surface stable, operator-readable messaging for at least auth failure, invalid target, and connection failure.

9.3 Browse And Search

• User can browse keys in the active DB without assuming a full blocking fetch.
• Search is scoped to the active DB and returns predictable empty states.
• Key rows expose at minimum name, type, and TTL state when available.
• Clearing search returns the user to normal browse behavior without reconnecting.

9.4 Inspect, Save, And TTL

• Selecting a key opens a readable inspector with metadata and typed value structure.
• String keys expose save actions only when the backend confirms write support.
• Saving a string key refreshes the visible value state and preserves TTL.
• Non-string keys remain explicitly read-only.
• TTL can be set or removed for the selected key and the inspector reflects the new TTL state after success.
• Failed save or TTL operations preserve user context and show a clear outcome.

9.5 Command Console

• The console always shows which connection and DB it targets.
• The user can run a single command and see a clear result or error.
• Dangerous or administrative commands outside scope are blocked before they appear to succeed.
• Command history distinguishes live results from demo fallback results.

9.6 Release Evidence Required Before Calling V1 Accepted

• Live Tauri smoke evidence against the seeded fixture must exist for connect, browse, inspect, string save, TTL update, and command execution.
• Linux launch and packaging evidence must remain repeatable.
• macOS and Windows remain outside current acceptance until build and smoke evidence exist.
• The in-repo product requirements document must exist and stay aligned with QA artifacts.

10. CLI Demo To Product Evolution

The repository currently centers on the desktop path, but the intended evolution still follows a CLI-to-product logic at the capability level:

Stage A: Shared Redis capability proof

Use redis-core or a thin CLI surface to prove:

• connection and authentication
• DB selection
• browse pagination
• typed value reads
• narrow string write rules
• TTL mutation rules
• safe command execution

Stage B: Live desktop workflow

Map those validated capabilities into one operator workspace with:

• visible connection scope
• browse and search
• typed inspection
• string save and TTL actions
• safe command tray

Stage C: Product hardening

Add the product behaviors that make the workflow trustworthy:

• consistent failure copy
• explicit unsupported-state messaging
• confirmation and safety boundaries
• smoke evidence capture
• clearer onboarding and profile handling

Stage D: Productization

Only after the operator baseline is stable should the team expand toward:

• persisted profile management
• secure secret handling
• true destructive flows with audited confirmation
• cross-platform packaging evidence
• broader data-type editing if still justified by user demand

11. Handoff To CTO

The CTO should split implementation and closure work into these product slices:

• Connection profile handling, validation, and runtime-mode boundary
• Browse and search flows on top of the existing SCAN contract
• Inspector and typed value presentation
• String save and TTL workflows
• Command safety boundary and blocked-command rules
• Release hardening, evidence capture, and cross-platform packaging follow-up

The CTO should treat the following as boundary conditions, not optional polish:

• do not expand editing surface before current string and TTL flows are fully evidenced
• do not treat mock delete confirmation as shipped delete capability
• do not treat browser demo mode as release evidence for Redis-backed acceptance

12. Open Risks And Dependencies

• Delete is visible in the shell but not real in the backend. That can confuse operators unless messaging stays explicit.
• Lack of persisted profiles and secrets limits day-to-day usability and onboarding continuity.
• The backend contract still rejects TLS modes beyond disabled, which narrows usable environments.
• QA evidence is improving, but Redis-backed feature acceptance remains incomplete as of 2026-03-30.

13. Scope Classification Follow-Up On 2026-03-31

The PM scope-classification follow-up for HAC-19 is recorded in plans/2026-03-31-hac-19-scope-classification.md.

Result:

• no new requests were approved into desktop-v1
• Add Key is classified as a desktop-v1.1 candidate only
• blue visual refresh and bilingual UI remain later

This keeps the current phase focused on proving and accepting the existing live desktop operator baseline before any visible scope expansion.

14. Add Key Boundary On 2026-03-31

The repository now contains an implemented Add Key path, but PM does not treat code presence as automatic current-phase approval.

Current rule:

• Add Key remains outside desktop-v1 acceptance and release claim
• it stays a desktop-v1.1 candidate until PM explicitly reclassifies it

The boundary note for CTO and QA is recorded in plans/2026-03-31-add-key-phase-boundary.md.