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