redis-gui-foundation/docs/frontend-workspace-baseline.md

Redis GUI Desktop Workspace Baseline

Date: 2026-03-27 Owner: Senior Frontend Engineer Related issues: HAC-8, HAC-9, HAC-10, HAC-11

Current Assessment

• The repository already had a valid desktop entry at apps/desktop and a working Tauri bridge for backend_bootstrap.
• The repository also already exposed stable desktop commands for connection testing and command execution through test_redis_connection and execute_redis_command.
• The previous frontend surface was only a minimal Vite JavaScript shell and did not match the target implementation stack for downstream UI work.
• The first frontend milestone therefore needed a visible React workspace before feature delivery could continue efficiently.

Recommended V1 UI Scope

The first visible product surface should include:

• a stable desktop shell with a persistent connection context
• a connection library and a new-connection entry point
• a database switcher that keeps the current DB visible
• a key browser with search and selection states
• a value inspector with string-edit support and explicit read-only states
• a scoped command tray that makes connection and DB context obvious
• destructive-action confirmation that repeats the key name and DB

The first visible product surface should not include:

• cluster topology
• metrics dashboards
• bulk actions
• multi-connection comparison
• full editing support for every Redis type
• privileged administrative commands

Information Architecture

Use a four-zone workspace:

1. Utility rail
2. Browser pane
3. Inspector pane
4. Command tray

Utility rail

• Connection library
• New connection form entry point
• Active connection session summary with clear ready/testing/demo/retry states
• Active DB switcher
• Safety posture and backend boundary summary
• Local smoke fixture assist for repeatable QA runs

Browser pane

• Search or key pattern filter
• Result count summary
• Compact key rows with type and TTL
• Empty state when no keys match

Inspector pane

• Selected key header
• Value surface
• Save action for string keys only
• TTL control for set and persist flows
• Explicit read-only treatment for unsupported types
• Metadata and support note beside the edited surface

Command tray

• Scoped command input
• Visible connection and DB scope
• Result history
• Hard block for destructive or administrative commands

Visual Direction

• Calm and editorial rather than dashboard-like
• Dense enough for operator workflows without visual noise
• Structure driven by typography, separators, and restrained tinted surfaces
• Strong emphasis only for selection, state, or destructive intent
• Support both light and dark modes with low-noise neutral palettes

Implementation Baseline Added On 2026-03-27

• apps/desktop now runs on React and Tailwind-based styling.
• The shell now consumes the existing Tauri bridge for backend_bootstrap, test_redis_connection, browse_redis_keys, read_redis_value, write_redis_value, and execute_redis_command.
• The inspector now consumes update_redis_key_ttl for live TTL set and persist actions in desktop runtime.
• The repository now also contains a visible string-only Add key dialog wired to create_redis_value; that entry is explicitly labeled Preview, and the capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
• shadcn-style UI primitives are used locally for buttons, inputs, textareas, badges, and dialogs.
• Browser-only dev mode uses explicit demo fallback so the visible shell can still be reviewed without a Tauri runtime.
• Tauri desktop mode now allows live connection tests, live key browsing, live value inspection, string save for supported keys, live TTL updates, and live command execution while keeping browser dev mode on explicit demo fallback.
• Non-string live values now render in structured read-only panels for hash, list, set, zset, and stream, so operators can scan typed payloads without reading raw JSON dumps.
• The visible shell now validates draft-connection name, host, port, and DB input before creation, and prevents duplicate profile names inside the local shell state.
• The active connection area now also exposes a dedicated session summary so operators can see whether the current scope is ready, testing, demo-only, or waiting for retry without inferring that state from scattered card copy.
• Live connection test completion now only reapplies the returned DB scope when the same connection is still active, preventing a stale test response from silently replacing the operator's newer active workspace selection.
• The DB switcher now exposes a predictable default operator range from db0 through db15 and keeps an out-of-range active DB visible instead of depending on a four-item hardcoded list.
• Zero-result key searches now place the inspector into an explicit empty state instead of leaving a stale key visible.
• Frontend error handling now routes stable backend error codes through a shared operator-facing notice layer so live failures render with consistent copy and banner tone across connection, browse, inspect, write, TTL, and command flows.
• The inspector now also renders a dedicated readability layer with explicit inspect status, value-surface semantics, next-step guidance, and key facts so string, structured, missing, and demo-fallback states are easier to interpret.
• Current-phase writable actions now require a scoped review step before string save, TTL set, or TTL removal proceeds, and no-op submissions are blocked before they reach the live bridge or demo fallback.
• The utility rail now exposes a bounded local smoke assist surface with fixture targeting, smoke:* focus, safe command presets, and the seeded key list from the local smoke runbook.
• Browser-only demo mode now keeps session-local mock string-save and TTL changes visible in the browser, inspector, and mock command responses so shell review does not claim success while leaving stale UI state behind.

QA Acceptance For This Milestone

• The shell renders four distinct zones: rail, browser, inspector, command tray.
• The header keeps app version, runtime mode, and build mode visible for smoke validation.
• The utility rail exposes a copyable QA snapshot with runtime, connection, selection, and latest command context.
• The utility rail exposes the seeded local smoke fixture path and safe smoke shortcuts without requiring manual re-entry from the runbook.
• The active connection and active DB stay visible without opening a modal.
• The active connection area shows a dedicated session summary with explicit ready, testing, demo fallback, or retry-needed wording plus a visible next-step hint.
• The DB switcher exposes db0 through db15 by default and still keeps the current DB visible when the active scope falls outside that range.
• Search filters the browser list and shows a no-results state.
• Search now exposes explicit mode feedback so operators can see whether the current input is being treated as a contains search or a raw Redis pattern.
• Search now exposes a bounded clear action in the browser header so operators can return to normal browse state without manually deleting the entire input.
• When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
• Empty browser and inspector states now distinguish between an empty DB and a filtered no-match result instead of using one generic no-results sentence.
• The connection action distinguishes desktop live testing from browser demo fallback.
• If a live connection test finishes after the operator switches to a different connection, the tested connection card updates but the newly active DB scope remains unchanged.
• Invalid draft connections cannot be created from the visible shell.
• Live backend failures are shown through a consistent banner treatment instead of per-surface ad hoc copy.
• Non-string keys are explicitly read-only.
• Non-string keys render as structured typed panels instead of raw JSON text blobs.
• The inspector keeps current status, value semantics, action guidance, and key facts visible without requiring operators to infer meaning from badges or raw payload shape alone.
• String keys show a save affordance near the value surface.
• TTL controls stay beside the inspector metadata and expose both set and remove flows.
• String save and TTL mutations now require a second review step that repeats scoped current-vs-next state before continuing.
• Failed save and TTL attempts keep the current draft value or TTL input in place so operators can adjust and retry without rebuilding context.
• Browser demo mode keeps mock string-save and TTL changes visible for the current session while still labeling the runtime as non-live.
• The visible Add key entry and dialog keep a Preview label so operators do not mistake that next-phase flow for approved current-baseline scope.
• Current baseline sign-off does not require the visible Add key surface to pass or fail; keep any Add Key evidence separate unless PM explicitly promotes it into the active milestone.
• Delete requires a second confirmation step that includes key name and DB context.
• The command tray visibly blocks dangerous administrative commands.
• Command history marks whether each result came from the live desktop bridge or the demo shell.

Run Notes

Use:

pnpm install
pnpm --filter @redis-gui/desktop test
pnpm run desktop:dev

Notes:

• pnpm run desktop:dev is the browser shell path. It supports layout review and session-local demo fallback only; mock save and TTL actions update visible UI state, but no Tauri or Redis mutation occurs.
• pnpm run desktop:tauri:dev is the desktop integration path. Use it when QA or backend needs to validate the existing command bridge against a live Redis target.
• pnpm --filter @redis-gui/desktop test should stay green before handing frontend foundation changes to QA or other feature teams.
• Use pnpm run desktop:build for a production bundle check before handing the shell to QA or integration work.