redis-gui-foundation/plans/2026-03-31-redis-gui-v1-status-refresh.md

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.