redis-gui-foundation/plans/2026-03-31-cto-handoff-current-phase.md

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.