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-cto-handoff-current-phase.md

@@ -0,0 +1,216 @@
+# CTO Handoff For Current Phase
+
+Date: 2026-03-31
+Owner: Product Manager
+Project: `redis-gui-foundation`
+Primary sources:
+
+- `docs/redis-gui-v1-product-requirements.md`
+- `plans/2026-03-31-hac-19-scope-classification.md`
+- `plans/2026-03-31-redis-gui-v1-status-refresh.md`
+- `docs/qa/acceptance-matrix.md`
+
+## Purpose
+
+This handoff translates the current PM-approved product scope into execution-ready product slices for the CTO.
+
+It is not an architecture document. It defines what must be made provable in the current phase, what must stay out, and what can be prepared only as a next-phase candidate.
+
+## User And Problem
+
+Primary users:
+
+- backend or full-stack engineers inspecting and making low-risk Redis fixes in local, development, test, or staging environments
+- QA or support engineers verifying key, value, and TTL behavior without relying on CLI fluency
+
+Core problem:
+
+- Redis CLI is flexible, but it hides connection and DB context too easily, raises the chance of destructive mistakes, and is slower for routine inspect or verify work
+
+Product promise for the current phase:
+
+- make the single-instance Redis operator loop safer and faster than raw CLI for inspect, verify, string-fix, TTL-adjust, and safe-command workflows
+
+## Current Phase Definition
+
+Current phase name:
+
+- `desktop-v1` baseline hardening and acceptance closure
+
+This phase is already implemented at a feature-baseline level. The remaining work is to make that baseline provable, repeatable, and clearly bounded.
+
+## What Must Be True In This Phase
+
+### 1. The core operator loop is the thing being accepted
+
+The current phase is about proving this loop end to end:
+
+1. create or select a connection profile
+2. test the connection
+3. enter the workspace with active connection and DB visible
+4. browse or search keys
+5. inspect key metadata and typed value structure
+6. save a supported string value, update TTL, or run a safe command
+7. verify the result in the same workspace
+
+### 2. Current phase scope is intentionally narrow
+
+Included:
+
+- one active standalone Redis connection at a time
+- local validation for profile draft creation
+- live connection test in Tauri mode
+- browse and key-name or pattern search in active DB
+- typed inspection for `string`, `hash`, `list`, `set`, `zset`, and `stream`
+- string replace for existing string keys only
+- TTL set and TTL removal
+- safe command execution with explicit scope
+- consistent operator-facing error treatment
+- repeatable local smoke-fixture path
+
+### 3. Current phase acceptance is evidence-driven
+
+Current phase should not be called accepted until there is live Tauri evidence for:
+
+- connect
+- browse
+- inspect
+- string save
+- TTL update
+- command execution
+
+## What Must Stay Out In This Phase
+
+The CTO should treat these as hard scope boundaries, not as optional backlog candidates for the active phase:
+
+- real delete execution
+- create-new-key workflows
+- non-string editing
+- cluster, Sentinel, replication, or topology features
+- secret persistence and production-grade credential handling
+- blue visual refresh
+- bilingual UI (`zh-CN` / `en-US`)
+- multi-connection compare workflows
+- admin-level Redis operations
+
+## Current Product Slices For CTO
+
+These are the product slices that engineering and QA should use for current-phase execution.
+
+### Slice 1: Connection Context Integrity
+
+User value:
+
+- operator always knows which Redis target and DB they are about to affect
+
+Must be provable:
+
+- draft validation is predictable
+- active connection and DB stay visible
+- connection test success and failure produce stable operator-facing outcomes
+- browser demo mode remains visibly non-live
+
+### Slice 2: Browse And Search Confidence
+
+User value:
+
+- operator can find the right key without CLI pagination or guesswork
+
+Must be provable:
+
+- browse works against live Redis in Tauri mode
+- search stays scoped to the active DB
+- empty and failure states are explicit
+- metadata stays visible enough for safe selection
+
+### Slice 3: Inspect And Understand
+
+User value:
+
+- operator can inspect the current key without mentally decoding raw protocol output
+
+Must be provable:
+
+- typed value surfaces are readable
+- unsupported edit states are explicit
+- inspector refresh reflects the selected key accurately
+
+### Slice 4: Safe Mutation Boundary
+
+User value:
+
+- operator can make the smallest useful changes without stepping outside a safe product contract
+
+Must be provable:
+
+- only existing string keys are writable
+- successful string save keeps TTL semantics intact
+- TTL set and remove are visibly reflected after success
+- failed write or TTL operations preserve user context
+
+### Slice 5: Safe Command Boundary
+
+User value:
+
+- operator can run simple read or inspection commands without leaving the app
+
+Must be provable:
+
+- command scope is visible
+- live and demo outputs are distinguishable
+- blocked dangerous commands do not appear to succeed
+
+### Slice 6: Acceptance Evidence Closure
+
+User value:
+
+- the product team can honestly say the current baseline works in real desktop runtime
+
+Must be provable:
+
+- a GUI-capable session exists for real Tauri smoke
+- QA can capture screenshots or logs for the current operator loop
+- Linux packaging remains repeatable for the accepted path
+
+## CTO Execution Priority
+
+The CTO should sequence current work in this order:
+
+1. Unblock a GUI-capable Tauri smoke environment.
+2. Close evidence for the already-implemented operator loop.
+3. Keep Linux package evidence repeatable.
+4. Decide whether AppImage is a required release path or an explicit non-default gap.
+5. Only after the above, evaluate next-phase expansion.
+
+## Next-Phase Candidate, But Not Current Phase
+
+Only one request is currently approved as a plausible next-phase candidate:
+
+- `Add Key` -> `desktop-v1.1`
+
+Even this item should not enter active implementation until current baseline closure is materially on track.
+
+Repository-state clarification:
+
+- the repo now contains an implemented Add Key path
+- that implementation does not change PM scope approval for the current phase
+- before any `desktop-v1` release claim, CTO should either gate the Add Key surface or label it as preview and keep it outside current-phase acceptance
+
+If it is pulled into the next phase, PM guardrails are:
+
+- string-key creation only
+- optional TTL at create time
+- duplicate key names fail explicitly
+- no implicit overwrite behavior
+
+## Product-Level Risks CTO Should Keep Visible
+
+- Delete UI affordance exists before real delete capability exists.
+- Add Key is implemented in the repo ahead of current-phase approval, which can blur the release boundary if left visible without phase labeling.
+- Current evidence gap is environmental and operational, not conceptual.
+- Scope expansion before baseline acceptance will make product sign-off weaker, not stronger.
+- Cross-platform release expectations are still ahead of current evidence.
+
+## PM Decision Summary
+
+The current phase is not asking engineering to invent a broader product. It is asking engineering and QA to prove, harden, and correctly bound the product that is already visible in the repository.