docs(project): refresh baseline verification artifacts

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>

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

@@ -0,0 +1,111 @@
+# 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.