paperclip-bot/redis-gui-foundation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(project): refresh baseline verification artifacts

Browse Source 
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>
This commit is contained in:
Senior Frontend Engineer
2026-03-31 10:15:39 +00:00
parent 9c404d54a0
commit b6cbe5a47e
30 changed files with 1619 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/architecture.md
View File

@@ -16,15 +16,17 @@
- `RedisKeyBrowseRequest`: key 浏览请求，显式携带 `SCAN` cursor、pattern 与 page size。
- `RedisKeyMetadataRequest`: 单个 key 的元数据读取请求，用于 inspector 刷新与删除前确认。
- `RedisValueReadRequest`: 单个 key 的 typed value 读取请求。
- `RedisValueCreateRequest`: 单个 key 的显式创建请求；当前仅允许新建 string key，并可选携带创建时 TTL。
- `RedisValueWriteRequest`: 单个 key 的 value 写入请求；当前仅允许 string 整值替换。
- `RedisKeyTtlUpdateRequest`: 单个 key 的 TTL 修改请求，支持设置过期时间和移除 TTL。
- `RedisCommandRequest`: 基础命令执行请求，显式拆分命令名与参数。
- `RedisKeyMetadata`: key 浏览与 inspector 共享的稳定元数据结构，覆盖存在性、类型和 TTL。
- `RedisValueRecord`: inspector 使用的稳定结构，组合 key 元数据、typed value 数据、value 写入能力和 TTL 修改能力。
- `RedisValueCreateResult`: 创建成功后的稳定返回体，复用 `RedisValueRecord` 让调用方立即获得可浏览/可检查的最新状态。
- `RedisValueData`: typed value 返回体，覆盖 `string/hash/list/set/zset/stream` 与缺失 key。
- `RedisValueWriteCapability`: 当前明确区分 `replace_string` 与 `none`，让入口层知道哪些类型仍是只读。
- `CommandExecutionResult`: 以稳定的 RESP2 派生结构返回基础命令结果。
- `BackendError`: 结构化错误码，区分连接配置、认证、连接失败和命令失败。
- `BackendError`: 结构化错误码，区分连接配置、重复创建、认证、连接失败和命令失败。
- `BackendBootstrap`: 向入口层暴露当前支持的能力边界和安全约束。
这些对象构成当前阶段的稳定后端契约：
@@ -36,6 +38,7 @@
- key 浏览按 `SCAN` 分页返回，并为每个命中的 key 补充 `TYPE` 与 `PTTL` 元数据。
- inspector 可对单个 key 单独刷新元数据，避免 UI 为了刷新单项而重跑整页浏览。
- typed value surface 当前覆盖 `string/hash/list/set/zset/stream` 六类 Redis 数据，并显式保留类型差异。
- V1 Add Key 通过独立 create contract 建模，只允许显式新建 string key，并通过 `SET ... NX` 拒绝任何隐式覆盖。
- V1 value 编辑只允许已有 string key 的整值替换；非 string key 保持只读，避免错误覆盖集合类型。
- string 写入会保留原 TTL，TTL 修改独立通过 `PERSIST` / `PEXPIRE` 语义建模。
@@ -63,6 +66,7 @@
- `TlsMode::disabled` 可用，`preferred` 和 `required` 目前明确返回 `unsupported_tls_mode`，避免伪支持。
- 命令执行结果目前覆盖 RESP2 的 `simple string`、`bulk string`、`integer`、`array` 和 `null`。
- typed value 读取当前是 key 级 eager 读取：`HGETALL`、`LRANGE 0 -1`、`SMEMBERS`、`ZRANGE ... WITHSCORES`、`XRANGE - +`。这保证了契约直接，但尚未引入大 key 分页、截断或流式读取策略。
- string key 创建使用单条 `SET key value NX [PX ttl]`，确保重复 key 走稳定冲突路径，而不是把“创建”降级成覆盖写入。
- string 写入使用事务化的 `SET ... XX` 与 TTL 恢复，避免把非 string key 误写成 string，也避免默认清空现有 TTL。
- key 元数据仍未覆盖编码、内存占用、slot、cluster 拓扑或 ACL 细粒度探测。
- 这层契约已足以支撑连接管理、基础命令台、key 浏览、value inspector 与 TTL 编辑，但还不足以覆盖 cluster、pub/sub、流式结果或长连接会话管理。
@@ -70,7 +74,7 @@
## Entry Point Contract
- Tauri 命令只暴露共享核心层的数据，不直接返回临时字符串。
- 当前桌面入口暴露八个命令：`backend_bootstrap`、`test_redis_connection`、`browse_redis_keys`、`inspect_redis_key`、`read_redis_value`、`write_redis_value`、`update_redis_key_ttl`、`execute_redis_command`。
- 当前桌面入口暴露九个命令：`backend_bootstrap`、`test_redis_connection`、`browse_redis_keys`、`inspect_redis_key`、`read_redis_value`、`create_redis_value`、`write_redis_value`、`update_redis_key_ttl`、`execute_redis_command`。
- 任何新增入口都应优先复用 `redis-core`，保证 CLI、GUI 行为模型一致。
- 桌面入口允许演进 UI，但不应绕过领域约束自行定义 Redis 协议行为。

8
docs/frontend-workspace-baseline.md
View File

@@ -45,6 +45,7 @@ Use a four-zone workspace:
- Connection library
- New connection form entry point
- Active connection session summary with clear ready/testing/demo/retry states
- Active DB switcher
- Safety posture and backend boundary summary
- Local smoke fixture assist for repeatable QA runs
@@ -85,12 +86,14 @@ Use a four-zone workspace:
- `apps/desktop` now runs on React and Tailwind-based styling.
- The shell now consumes the existing Tauri bridge for `backend_bootstrap`, `test_redis_connection`, `browse_redis_keys`, `read_redis_value`, `write_redis_value`, and `execute_redis_command`.
- The inspector now consumes `update_redis_key_ttl` for live TTL set and persist actions in desktop runtime.
- The repository now also contains a visible string-only `Add key` dialog wired to `create_redis_value`, but that capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
- The repository now also contains a visible string-only `Add key` dialog wired to `create_redis_value`; that entry is explicitly labeled `Preview`, and the capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
- shadcn-style UI primitives are used locally for buttons, inputs, textareas, badges, and dialogs.
- Browser-only dev mode uses explicit demo fallback so the visible shell can still be reviewed without a Tauri runtime.
- Tauri desktop mode now allows live connection tests, live key browsing, live value inspection, string save for supported keys, live TTL updates, and live command execution while keeping browser dev mode on explicit demo fallback.
- Non-string live values now render in structured read-only panels for `hash`, `list`, `set`, `zset`, and `stream`, so operators can scan typed payloads without reading raw JSON dumps.
- The visible shell now validates draft-connection name, host, port, and DB input before creation, and prevents duplicate profile names inside the local shell state.
- The active connection area now also exposes a dedicated session summary so operators can see whether the current scope is ready, testing, demo-only, or waiting for retry without inferring that state from scattered card copy.
- Live connection test completion now only reapplies the returned DB scope when the same connection is still active, preventing a stale test response from silently replacing the operator's newer active workspace selection.
- The DB switcher now exposes a predictable default operator range from `db0` through `db15` and keeps an out-of-range active DB visible instead of depending on a four-item hardcoded list.
- Zero-result key searches now place the inspector into an explicit empty state instead of leaving a stale key visible.
- Frontend error handling now routes stable backend error codes through a shared operator-facing notice layer so live failures render with consistent copy and banner tone across connection, browse, inspect, write, TTL, and command flows.
@@ -106,6 +109,7 @@ Use a four-zone workspace:
- The utility rail exposes a copyable QA snapshot with runtime, connection, selection, and latest command context.
- The utility rail exposes the seeded local smoke fixture path and safe smoke shortcuts without requiring manual re-entry from the runbook.
- The active connection and active DB stay visible without opening a modal.
- The active connection area shows a dedicated session summary with explicit ready, testing, demo fallback, or retry-needed wording plus a visible next-step hint.
- The DB switcher exposes `db0` through `db15` by default and still keeps the current DB visible when the active scope falls outside that range.
- Search filters the browser list and shows a no-results state.
- Search now exposes explicit mode feedback so operators can see whether the current input is being treated as a contains search or a raw Redis pattern.
@@ -113,6 +117,7 @@ Use a four-zone workspace:
- When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
- Empty browser and inspector states now distinguish between an empty DB and a filtered no-match result instead of using one generic no-results sentence.
- The connection action distinguishes desktop live testing from browser demo fallback.
- If a live connection test finishes after the operator switches to a different connection, the tested connection card updates but the newly active DB scope remains unchanged.
- Invalid draft connections cannot be created from the visible shell.
- Live backend failures are shown through a consistent banner treatment instead of per-surface ad hoc copy.
- Non-string keys are explicitly read-only.
@@ -123,6 +128,7 @@ Use a four-zone workspace:
- String save and TTL mutations now require a second review step that repeats scoped current-vs-next state before continuing.
- Failed save and TTL attempts keep the current draft value or TTL input in place so operators can adjust and retry without rebuilding context.
- Browser demo mode keeps mock string-save and TTL changes visible for the current session while still labeling the runtime as non-live.
- The visible `Add key` entry and dialog keep a `Preview` label so operators do not mistake that next-phase flow for approved current-baseline scope.
- Current baseline sign-off does not require the visible `Add key` surface to pass or fail; keep any Add Key evidence separate unless PM explicitly promotes it into the active milestone.
- Delete requires a second confirmation step that includes key name and DB context.
- The command tray visibly blocks dangerous administrative commands.

9
docs/qa/acceptance-matrix.md
View File

@@ -6,7 +6,7 @@ Owner: QA Engineer
## Evidence Collected On 2026-03-31
- `cargo test -p redis-core` passes in this session with 20 tests green.
- `pnpm --filter @redis-gui/desktop test` passes in this session with 11 files and 44 tests green.
- `pnpm --filter @redis-gui/desktop test` passes in this session with 12 files and 48 tests green.
- `pnpm run desktop:build` passes and emits `apps/desktop/dist/`.
- `pnpm run desktop:dev` starts Vite on `http://127.0.0.1:1420/`, and the served HTML points to the desktop shell entrypoint.
- `pnpm run desktop:tauri:build` now completes Linux `.deb` and `.rpm` artifact generation under `target/release/bundle/`.
@@ -18,8 +18,9 @@ Owner: QA Engineer
- The repository still contains no `Dockerfile`, `docker-compose.yml`, `compose.yaml`, or equivalent compose asset; Docker-backed verification currently depends on the documented fixture scripts plus a reachable local Docker daemon.
- The repository now contains a Rust workspace, a React workspace UI baseline, Tauri commands for connection testing and command execution, and shared frontend scope documentation.
- Browser dev mode still uses demo data for shell review, while Tauri desktop mode can now exercise live connection-test, key browse, value read/write, and command-execution bridges.
- The checked-out desktop shell now also exposes a visible string-only `Add key` flow through `create_redis_value`, but PM phase notes still treat that capability as next-phase inventory rather than a required current-baseline acceptance item.
- The checked-out desktop shell now also exposes a visible string-only `Add key` flow through `create_redis_value`; the UI labels it as `Preview`, and PM phase notes still treat that capability as next-phase inventory rather than a required current-baseline acceptance item.
- Browser dev mode now also keeps mock string-save and TTL changes visible for the current session, reducing shell-review drift between action banners and visible UI state without changing the live acceptance boundary.
- The active connection area now shows an explicit session summary for ready, testing, demo fallback, and retry-needed states, and live test completion no longer rewrites the current active DB if the operator already switched to another connection while the probe was running.
- The desktop DB switcher now exposes a default `db0` through `db15` range and keeps an active out-of-range DB visible in the selector.
- A repeatable local Redis fixture and smoke runbook now exist in `scripts/redis-fixture/` and `docs/qa/local-desktop-smoke.md`.
- `docs/frontend-workspace-baseline.md` and `docs/redis-gui-v1-product-requirements.md` now both exist in-repo.
@@ -32,7 +33,7 @@ Owner: QA Engineer
| macOS app smoke | Same as Linux, using signed or documented macOS artifact | Same failure paths, plus first-run permission or gatekeeper guidance if relevant | Build artifact name, install steps, screenshots, QA run log | Blocked: no validated macOS build or artifact evidence |
| Windows app smoke | Same as Linux, using installer or portable package | Same failure paths, plus Windows-specific install and uninstall validation | Build artifact name, install steps, screenshots, QA run log | Blocked: no validated Windows build or artifact evidence |
| Desktop workspace shell | Rail, browser, inspector, and command tray render together with active connection, build identity, runtime mode, a copyable QA snapshot, local smoke assist, visible inspector summary/key facts surfaces, and scoped mutation review for current-phase write actions | Empty search state clears the inspector selection, search mode feedback and clear action stay visible and predictable, read-only non-string value state, inspector status/action guidance stays aligned to live vs demo vs missing cases, destructive confirmation, no-op write attempts are blocked before execution, and browser-mode demo fallback stays explicit while mock save and TTL actions update session-local UI state | `npm run desktop:dev` or `npm run desktop:build`, `docs/frontend-workspace-baseline.md`, screenshots or copied QA snapshot text | Pass for shell-level evidence; not a substitute for Redis feature acceptance |
| Connection management | Create a validated draft profile, keep DB context visible, switch among a predictable default DB range, and run the existing live connection-test bridge from Tauri desktop mode | Invalid host, bad port, bad password, duplicate name, timeout, and unreachable server are handled with consistent operator-facing messaging | Tauri run log, screenshots, repeatable steps, Redis target | Partially blocked: the shell now validates draft name/host/port/DB locally, exposes `db0` through `db15` while preserving active out-of-range DB context, maps backend error codes into shared notices, and calls the real connection-test command, but profile persistence and full evidence capture are not complete |
| Connection management | Create a validated draft profile, keep DB context visible, switch among a predictable default DB range, run the existing live connection-test bridge from Tauri desktop mode, and keep the active session state visibly scoped as ready, testing, demo fallback, or retry needed | Invalid host, bad port, bad password, duplicate name, timeout, and unreachable server are handled with consistent operator-facing messaging, and a late-arriving test result must not silently replace a newer active connection/DB selection | Tauri run log, screenshots, repeatable steps, Redis target | Partially blocked: the shell now validates draft name/host/port/DB locally, exposes `db0` through `db15` while preserving active out-of-range DB context, maps backend error codes into shared notices, keeps session-state guidance visible, and calls the real connection-test command without reapplying stale DB scope after an operator switch, but profile persistence and full evidence capture are not complete |
| Key browsing | Browse DBs and keys, paginate or virtualize large lists, view metadata | Empty DB, deleted key during browse, permission error, and connection drop do not crash UI, and live failures reuse the shared error banner treatment | Seed dataset, result screenshots, observed limits | Partially blocked: desktop UI now calls the live browse bridge with `SCAN` pagination and metadata, but fixture-backed Tauri screenshots and measured limits are still pending |
| Search | Search by key name or pattern and return matching set within documented limits; visible shell makes it clear whether the current input is treated as a contains search or a raw Redis pattern | No matches, invalid pattern, empty DB state, and very large result sets are handled predictably, and operators can clear search back to browse state without ambiguity | Seed dataset, search queries, measured behavior | Partially blocked: desktop UI now maps search to live browse requests and exposes clearer search-state feedback, but fixture-backed evidence and measured limits are still pending |
| Value editing | Open supported value types, review pending string replacement, confirm save, and refresh persisted value; inspector keeps current state and write semantics explicit while editing | Concurrent modification, invalid payload, missing-key transitions, and permission error preserve user context, while no-op edits are blocked before execution and live failures reuse the shared operator notice layer | Before/after values, screenshots, repeatable steps | Partially blocked: string read/save/refresh is wired through the live desktop bridge, non-string types now render in structured read-only inspector panels, inspector guidance is clearer across live and fallback states, scoped review now clarifies current-vs-next value before save, and browser demo mode keeps session-local save state coherent, but fixture-backed live evidence and broader editing scope remain pending |
@@ -45,6 +46,6 @@ Owner: QA Engineer
- No Redis-backed Redis GUI V1 feature acceptance item can be marked passed on 2026-03-31.
- Current repository state now supports shell-level frontend acceptance and partial backend feature review: the React workspace shell builds, live desktop bridges exist for connection test, browse, string create, value read/write, and command execution, draft-validation and empty-state behavior are explicit, and shared UI scope documentation is present in-repo.
- The visible `Add key` surface should be tracked as implemented next-phase inventory only; its presence in the repository must not be treated as automatic current-baseline pass criteria or release scope expansion.
- The visible `Add key` surface is labeled `Preview` and should be tracked as implemented next-phase inventory only; its presence in the repository must not be treated as automatic current-baseline pass criteria or release scope expansion.
- Rust source-level test evidence is current for `redis-core`, the desktop test baseline is current, the browser demo entrypoint is reproducible, Linux package artifacts exist for `.deb` and `.rpm`, Debian metadata is inspectable, and the fixture path is reproducible on both success and one key failure path, but live Redis screenshots or logs and installation evidence are still required.
- QA can now independently execute the documented Linux baseline path, and the phase-level evidence loop is summarized in `docs/qa/current-phase-evidence-loop.md`, but feature acceptance and release sign-off remain blocked on a GUI-capable desktop session for end-to-end evidence, AppImage packaging, cross-platform evidence, and installer install or uninstall checks.

2
docs/qa/cross-platform-smoke-plan.md
View File

@@ -45,6 +45,6 @@ Provide one minimal but repeatable smoke flow for Windows, macOS, and Linux that
## Current Blockers On 2026-03-27
- Verified Linux package artifacts now exist for `.deb` and `.rpm` under `target/release/bundle/`, but AppImage failed in the latest run and no validated package artifact evidence exists yet for macOS or Windows.
- Verified Linux package artifacts now exist for `.deb` and `.rpm` under `target/release/bundle/`, while the separate `pnpm run desktop:tauri:build:all` path still fails in the AppImage stage; no validated package artifact evidence exists yet for macOS or Windows.
- The repository now provides a Linux-oriented local smoke runbook and Docker-backed Redis fixture conventions, but those steps still need saved cross-platform execution evidence.
- Current desktop shell now supports live browse, inspect, string save, TTL update, and command execution in Tauri runtime, but full end-to-end smoke evidence still needs saved screenshots or run logs.

39
docs/qa/current-phase-evidence-loop.md Normal file
View File

@@ -0,0 +1,39 @@
# Current Phase Evidence Loop
Date: 2026-03-31
Owner: QA Engineer
Issue: HAC-33
## Scope Boundary Aligned On 2026-03-31
- Current phase is `desktop-v1` baseline hardening and acceptance closure, as defined in `docs/redis-gui-v1-product-requirements.md`, `plans/2026-03-31-redis-gui-v1-status-refresh.md`, and `plans/2026-03-31-cto-handoff-current-phase.md`.
- Current-phase acceptance is limited to the existing operator loop: connect, browse, inspect, string save, TTL update, and safe command execution in live Tauri runtime.
- `Add Key` exists in the checked-out repository, but PM classification still keeps it in `desktop-v1.1`; it must not be folded into current-baseline acceptance or release claims.
- Real delete remains unimplemented and must stay outside shipped-current-phase capability claims.
## Execution Issue Evidence Map
| Issue | What It Owns | Evidence References | QA Readout On 2026-03-31 | Open Risk |
| --- | --- | --- | --- | --- |
| HAC-15 | Stable Linux build, package, fixture, and smoke path foundation | `plans/2026-03-27-hac-15-desktop-build-smoke.md`, `docs/qa/local-desktop-smoke.md`, `docs/qa/verification-path-inventory.md`, `docs/qa/acceptance-matrix.md` | Passed for repeatable command-level Linux evidence: `cargo test -p redis-core`, `pnpm --filter @redis-gui/desktop test`, `pnpm run desktop:build`, `pnpm run desktop:tauri:build`, and fixture scripts are reproducible in this session. | Does not provide real-window smoke, Linux install or uninstall proof, or any macOS or Windows evidence. |
| HAC-19 | Local smoke assist surface for faster operator verification | `plans/2026-03-28-hac-19-local-smoke-assist.md`, `docs/frontend-workspace-baseline.md`, `docs/qa/local-desktop-smoke.md`, `docs/qa/acceptance-matrix.md` | Passed at shell-level evidence: smoke fixture path is documented in-repo, visible in the product surface, and reproducible from the current tree. | Still depends on a GUI-capable desktop session to turn the assisted path into release-grade live smoke evidence. |
| HAC-22 | DB switcher hardening inside current phase | `plans/2026-03-31-hac-22-db-switcher-hardening.md`, `docs/redis-gui-v1-product-requirements.md`, `docs/qa/acceptance-matrix.md` | Passed at command-level regression evidence: the frontend baseline now covers the wider DB selector path and remains green under the current desktop test/build commands. | Live Tauri screenshots or run logs for DB switching are still absent in this headless QA session. |
| HAC-26 | Frontend workspace-state foundation and browser-demo hardening | `plans/2026-03-31-hac-26-workspace-state-foundation.md`, `plans/2026-03-31-frontend-demo-state-hardening.md`, `docs/qa/acceptance-matrix.md` | Passed at regression-baseline level: `pnpm --filter @redis-gui/desktop test` now passes 8 files and 29 tests, and browser-shell build remains reproducible. | Browser-demo hardening improves shell review only; it does not satisfy live Redis acceptance without Tauri smoke evidence. |
| HAC-27 | Manual GUI smoke and AppImage install verification | `docs/qa/acceptance-matrix.md`, `docs/qa/release-readiness-checklist.md`, `docs/qa/verification-path-inventory.md` | Blocked in this environment: `target/release/desktop-shell` fails with `Failed to initialize GTK` because the session has no `DISPLAY`, `WAYLAND_DISPLAY`, or `xvfb-run`, and `pnpm run desktop:tauri:build:all` still fails with `failed to run linuxdeploy`. | Real-window smoke, Linux install or uninstall proof, and AppImage validation still require a GUI-capable Linux session plus follow-up evidence capture. |
| HAC-24 / HAC-25 | Future-phase Add Key implementation and QA coverage | `plans/2026-03-31-hac-24-add-key-frontend.md`, `docs/redis-gui-v1-product-requirements.md`, `plans/2026-03-31-hac-21-execution-split.md` | Explicitly excluded from current-phase sign-off. Repository presence is recorded as next-phase inventory only. | Scope leakage would weaken current-baseline acceptance if this capability is treated as already approved release scope. |
## Current Phase Judgment
- Command-level Linux evidence is closed enough to support an honest phase readout: build, package, browser-shell startup, fixture success path, and one fixture failure path are reproducible from the checked-out tree.
- Current phase is not accepted yet. Required live Tauri smoke evidence for connect, browse, inspect, string save, TTL update, and safe command execution is still missing.
- Current release readiness remains blocked by four named gaps:
- no GUI-capable Linux session for real-window smoke capture
- AppImage still fails in the `linuxdeploy` stage
- Linux install and uninstall evidence has not been captured
- macOS and Windows evidence is still absent
## Alignment Summary
- PM acceptance boundary is repo-local and inspectable through `docs/redis-gui-v1-product-requirements.md` and `plans/2026-03-31-redis-gui-v1-status-refresh.md`.
- CTO execution priority is consistent with QA findings: unblock GUI smoke first, keep Linux package evidence repeatable, and treat AppImage plus cross-platform gaps as explicit risks instead of implied passes.
- This issue closes the evidence-summary loop for the current phase. It does not clear the blocked acceptance items tracked through HAC-27 and the release-readiness checklist.

13
docs/qa/local-desktop-smoke.md
View File

@@ -70,13 +70,14 @@ Seeded keys:
1. Run `./scripts/redis-fixture/start.sh`.
2. Run `./scripts/redis-fixture/seed.sh`.
3. Launch `pnpm run desktop:tauri:dev`.
4. In the desktop app, connect to host `127.0.0.1`, port `6380`, database `0`, no password, TLS disabled.
4. In the desktop app, either use the utility-rail `Local smoke assist` shortcut or connect manually to host `127.0.0.1`, port `6380`, database `0`, no password, TLS disabled.
5. Verify the desktop window opens, app version plus runtime mode are visible in the header, and the connection test succeeds.
6. Verify the command console can run a safe read, such as `PING` or `GET smoke:string`.
7. Verify the seeded keys appear with expected types and TTL state in the browser and inspector surfaces.
6. Use the same `Local smoke assist` panel to prefill `smoke:*`, `PING`, or `GET smoke:string` if desired, then verify the command console can run a safe read.
7. Verify the seeded keys listed in both the utility rail and this runbook appear with expected types and TTL state in the browser and inspector surfaces, and confirm the inspector summary plus key facts stay aligned to the selected key type and current runtime.
8. Change TTL on `smoke:string:ttl`, remove TTL from the same key, and confirm the updated TTL state is reflected in the inspector.
9. Capture screenshots or terminal output for build, launch, connection success, key browse, TTL update, and command execution. If screenshots are unavailable, copy the in-app QA snapshot text into the smoke log.
10. Run `./scripts/redis-fixture/stop.sh` after the session.
9. Optional next-phase check only: use `Add key` to create a new string key such as `smoke:new-string`, verify it appears immediately in the browser and inspector, then retry the same name to confirm duplicate-key failure stays on the shared notice surface. Do not mix this evidence into current-baseline sign-off unless PM explicitly reclassifies Add Key into the active phase.
10. Capture screenshots or terminal output for build, launch, connection success, key browse, TTL update, and command execution. If screenshots are unavailable, copy the in-app QA snapshot text into the smoke log.
11. Run `./scripts/redis-fixture/stop.sh` after the session.
## Current Validation Boundary
@@ -84,4 +85,4 @@ Seeded keys:
- `pnpm run desktop:build` passes in the current workspace.
- `./scripts/redis-fixture/start.sh`, `./scripts/redis-fixture/seed.sh`, and `./scripts/redis-fixture/stop.sh` pass in the current workspace.
- `pnpm run desktop:tauri:build` now produces Linux `.deb` and `.rpm` artifacts under `target/release/bundle/`.
- The same Tauri build still fails in its AppImage stage with `io: Connection reset by peer (os error 104)`, so AppImage should be treated as not yet verified.
- `pnpm run desktop:tauri:build:all` still fails in its AppImage stage because `linuxdeploy` aborts, so AppImage should be treated as not yet verified.

12
docs/qa/release-readiness-checklist.md
View File

@@ -1,6 +1,6 @@
# Release Readiness Checklist
Date: 2026-03-27
Date: 2026-03-31
Owner: QA Engineer
## Must Be True Before Redis GUI V1 Can Ship
@@ -19,13 +19,15 @@ Owner: QA Engineer
- Known release blockers are triaged with owner and severity.
- Installer or portable package basic install, launch, and uninstall checks are complete.
## Current Release Blockers On 2026-03-27
## Current Release Blockers On 2026-03-31
- Blocked: Linux package artifact evidence now exists for `.deb` and `.rpm`, but AppImage is still unverified and there is no validated artifact evidence yet for macOS or Windows.
- Blocked: a repeatable Docker-backed seed and smoke path now exists, but no completed smoke evidence set has been captured from it yet.
- Blocked: release artifact naming now exists in produced Linux packages, but install and uninstall verification is still not documented with saved evidence.
- Blocked: a repeatable Docker-backed seed and smoke path now exists, but no completed real-desktop smoke evidence set has been captured from it yet.
- Blocked: release artifact naming and Debian package metadata now exist in produced Linux packages, but install and uninstall verification is still not documented with saved evidence.
- Blocked: the desktop app is not yet validated end-to-end against a seeded Redis path; browse, edit, and TTL controls are inspectable, but broader workflow evidence remains incomplete.
- Blocked: desktop runtime smoke evidence inside the real Tauri window is still pending even though current `redis-core` Rust test evidence and Linux package artifacts are reproducible from the present tree.
- Blocked: desktop runtime smoke evidence inside the real Tauri window is still pending even though current `redis-core` Rust test evidence and Linux package artifacts are reproducible from the present tree; the current QA heartbeat has no GUI-capable `DISPLAY`, `WAYLAND_DISPLAY`, or `xvfb-run`.
- Blocked: `pnpm run desktop:tauri:build:all` still fails in the AppImage `linuxdeploy` stage, so AppImage cannot be treated as a verified Linux install path.
- Blocked: Docker-backed smoke setup is script-reproducible, but there is still no compose-managed handoff path for non-author operators.
## Minimum Sign-Off Evidence

16
docs/qa/test-strategy.md
View File

@@ -1,6 +1,6 @@
# QA Test Strategy
Date: 2026-03-27
Date: 2026-03-31
Owner: QA Engineer
## Test Objectives
@@ -21,7 +21,7 @@ Owner: QA Engineer
## Environments
- Linux: current local environment available to QA.
- Linux: current local environment available to QA, but the present session is headless and cannot capture a real Tauri window.
- macOS: required for release acceptance, currently not provisioned in this repository.
- Windows: required for release acceptance, currently not provisioned in this repository.
@@ -37,10 +37,10 @@ Owner: QA Engineer
- "Blocked" is valid only when the missing prerequisite is named.
- "Not run" is distinct from "Pass" and must remain visible in checklists.
## Current Gaps On 2026-03-27
## Current Gaps On 2026-03-31
- Product shell exists as a visible desktop workspace baseline with shell-level validation and empty-state handling, but not as a complete Redis feature surface.
- No seed dataset or local Redis automation.
- No smoke harness, installer path, or CI workflow.
- Tauri packaging evidence is not currently present in the repository.
- Backend automated coverage is limited to foundation-model tests in `crates/redis-core`.
- The highest-risk gap is still missing real-window desktop evidence for connect, browse, inspect, string save, TTL update, and command execution in a GUI-capable session.
- `pnpm run desktop:tauri:build:all` still fails in the AppImage `linuxdeploy` stage, so the full Linux bundle path is not release-ready.
- No validated macOS or Windows build, install, launch, or smoke evidence exists.
- Linux installer install and uninstall checks are still absent even though `.deb` and `.rpm` artifacts are reproducible.
- Docker-backed smoke reproducibility currently depends on direct fixture scripts; there is still no `Dockerfile` or compose asset to standardize the environment handoff.

29
docs/qa/verification-path-inventory.md Normal file
View File

@@ -0,0 +1,29 @@
# Verification Path Inventory
Date: 2026-03-31
Owner: QA Engineer
## Goal
Pin down which startup, demo, seed, smoke, and Docker paths are actually reproducible in the current repository, and which ones remain blocked or undocumented.
## Inventory
| Path | Entry Point | Evidence On 2026-03-31 | Current Status | Gap |
| --- | --- | --- | --- | --- |
| Browser demo startup | `pnpm run desktop:dev` | Vite served `http://127.0.0.1:1420/`; `curl` returned the shell HTML entrypoint | Reproducible | Demo-only path; not valid live Redis evidence |
| Browser production build | `pnpm run desktop:build` | Build passed and emitted `apps/desktop/dist/` | Reproducible | Still frontend-shell evidence only |
| Linux desktop package build | `pnpm run desktop:tauri:build` | Build passed and produced `.deb` and `.rpm` under `target/release/bundle/` | Reproducible | Does not prove install, launch, or workflow acceptance |
| Linux native app launch | `target/release/desktop-shell` | Launch failed with `Failed to initialize GTK` in a session with no `DISPLAY`, `WAYLAND_DISPLAY`, or `xvfb-run` | Blocked by environment | Needs GUI-capable session or virtual display tooling |
| Full Linux bundle path | `pnpm run desktop:tauri:build:all` | `.deb` and `.rpm` bundled, then AppImage failed with `failed to run linuxdeploy` | Partially reproducible | AppImage remains unverified |
| Seed fixture happy path | `./scripts/redis-fixture/start.sh` -> `seed.sh` -> `redis-cli` checks -> `stop.sh` | Container started, 7 `smoke:*` keys seeded, types and TTL verified, cleanup succeeded | Reproducible | No GUI evidence attached to the live desktop workflow yet |
| Seed fixture failure path | `./scripts/redis-fixture/seed.sh` without a running container | Script failed explicitly with `Run scripts/redis-fixture/start.sh first.` | Reproducible | Only one negative fixture path is documented so far |
| Local smoke runbook | `docs/qa/local-desktop-smoke.md` | Commands, fixture inputs, and expected keys align with current scripts and README | Reproducible on the command line | Still blocked from real-window smoke capture in this session |
| Docker support path | Local Docker daemon + fixture scripts | Docker daemon reachable and scripts work | Reproducible | No `Dockerfile` or compose asset exists; reproducibility depends on direct script usage |
## QA Readout
- Startup paths are split cleanly between browser demo evidence and Tauri package evidence.
- The seeded Docker fixture path is now reproducible on both success and one clear failure path.
- The release-critical missing evidence is still real-window desktop smoke, not command-level buildability.
- Docker support exists only as a QA fixture dependency, not as a packaged app runtime or compose-managed environment.

261
docs/redis-gui-v1-product-requirements.md Normal file
View File

@@ -0,0 +1,261 @@
# Redis GUI V1 Product Requirements
Date: 2026-03-30
Owner: Product Manager
Status: Active working product spec
## 1. Document Purpose
This document defines the first usable product scope for the Redis desktop GUI based on the repository state inspected on 2026-03-30. It is intended to be specific enough for the CTO to split engineering work and for QA to validate acceptance.
This document supersedes the 2026-03-27 assumption that the workspace or demo was not accessible.
## 2. Current Demo Inventory On 2026-03-30
Confirmed from `README.md`, `docs/architecture.md`, `docs/frontend-workspace-baseline.md`, `docs/qa/acceptance-matrix.md`, `docs/qa/local-desktop-smoke.md`, `apps/desktop/src/App.tsx`, and `apps/desktop/src-tauri/src/main.rs`:
- The project now contains an inspectable desktop implementation path built around `apps/desktop` and a shared Rust core in `crates/redis-core`.
- Tauri desktop mode exposes live backend commands for `backend_bootstrap`, `test_redis_connection`, `browse_redis_keys`, `inspect_redis_key`, `read_redis_value`, `write_redis_value`, `update_redis_key_ttl`, and `execute_redis_command`.
- The visible desktop shell already implements the intended four-zone workspace: utility rail, browser pane, inspector pane, and command tray.
- Browser dev mode is intentionally a demo fallback. It does not pretend to be a live Redis runtime.
- The shell supports draft connection creation with local validation for profile name, host, port, and DB. Duplicate profile names are rejected in local shell state.
- Live connection testing exists in Tauri mode. Active connection and DB context stay visible in the workspace.
- Key browsing is wired to live `SCAN`-style pagination with type and TTL metadata.
- Search is currently key-name and pattern based within the active DB and reuses the browse contract.
- The inspector supports structured value viewing for `string`, `hash`, `list`, `set`, `zset`, and `stream`.
- Live editing is intentionally narrow: only existing string keys can be replaced as a whole value. The current TTL is preserved during string save.
- TTL update and TTL removal are already live in desktop mode.
- The command tray executes live commands in desktop mode and explicitly blocks `FLUSH*`, `CONFIG*`, and `SHUTDOWN*` from the visible shell.
- The shell includes a local smoke assist path for the seeded fixture on `127.0.0.1:6380` and a copyable QA snapshot for evidence capture.
- Linux packaging evidence now exists for `.deb` and `.rpm`. AppImage is still blocked. macOS and Windows smoke evidence do not yet exist.
Known gaps that remain product-significant:
- No persisted connection catalog or secret storage is enabled yet.
- Real key deletion is not implemented. The current delete confirmation is a mock-only flow.
- Non-string value editing remains unsupported.
- The accepted runtime target is still single-instance Redis, not cluster or Sentinel.
- TLS modes other than `disabled` are not actually supported by the backend yet.
- QA has not yet collected enough end-to-end live desktop evidence to mark Redis-backed feature acceptance as passed.
## 3. Target Users
Primary users:
- Backend or full-stack engineers who need to inspect and make low-risk fixes to Redis data in local, development, test, or staging environments.
- QA or support engineers who need to verify keys, values, and TTL behavior without relying on Redis CLI fluency.
- Engineers debugging application behavior who need visible DB context and safer workflows than raw shell commands.
Not the primary V1 user:
- Infra operators managing cluster topology, failover, replication, or production fleet administration.
- Users expecting observability dashboards, performance analytics, or admin-level server management.
## 4. Problem Statement
The target user needs a faster and safer way to inspect Redis data, verify key state, make narrow string fixes, adjust TTL, and run basic safe commands without falling back to raw CLI for every step.
Today, the fallback path is still Redis CLI or ad hoc shell commands. That path is efficient for experts but has three product problems:
- it hides active connection and DB context too easily
- it increases the chance of destructive mistakes
- it is slower for routine inspection, especially for typed values and TTL checks
## 5. Product Goal
Ship a desktop Redis operator tool for single-instance Redis workflows that makes routine inspect, verify, string-fix, TTL-adjust, and safe-command tasks faster and safer than raw CLI in local, dev, test, and staging environments.
## 6. Core Operator Flow
1. User selects or creates a connection profile.
2. User tests the connection before relying on the workspace.
3. User enters the workspace with the active connection and DB visibly pinned.
4. User browses or searches keys in the active DB.
5. User inspects metadata and value structure for the selected key.
6. User either saves a string value, updates TTL, or runs a safe command in the same scoped context.
7. User verifies the result immediately in the browser and inspector without reconnecting.
## 7. Current Phase Scope
### 7.1 Phase Definition
The current phase is not "full product release". It is a desktop operator baseline with live Redis-backed workflows for the smallest reliable surface that can support real usability testing and downstream hardening.
### 7.2 Included In The Current Phase
- One active standalone Redis connection at a time.
- Connection inputs for host, port, optional username, optional password, and DB index.
- Local validation for draft profile creation.
- Live connection test in Tauri desktop mode.
- Visible active connection and active DB context across the workspace.
- Key browsing with incremental loading through the current backend browse contract.
- Key-name and pattern search within the active DB.
- Metadata display for key name, key type, existence state, and TTL.
- Structured inspector views for `string`, `hash`, `list`, `set`, `zset`, and `stream`.
- String edit support only for existing string keys through whole-value replacement.
- TTL set and TTL removal for the selected key.
- Safe command execution in the active connection and DB context.
- Consistent operator-facing error banner mapping across connection, browse, inspect, save, TTL, and command flows.
- Local fixture assist and QA snapshot support for repeatable smoke runs.
### 7.3 Explicitly Not Included In The Current Phase
- Real delete execution.
- Create-new-key workflows.
- Editing support for hash, list, set, zset, or stream values.
- Multiple simultaneous connections or compare views.
- Cluster, Sentinel, replication, or topology awareness.
- SSH tunnel orchestration, secret vault integration, or production-grade credential persistence.
- Administrative or fleet-level Redis operations.
- Release sign-off for macOS or Windows.
## 8. Non-Goals
The following should stay out of V1 unless the CEO and CTO explicitly re-scope:
- Redis Cluster and Sentinel support.
- Replication insight, failover tooling, slot views, or topology diagrams.
- Pub/Sub tooling, monitor streams, slowlog, or performance dashboards.
- Value-content full-text search across all keys.
- Bulk actions, mass delete, import or export, migration, or schema management.
- Editing support for every Redis data type.
- Administrative commands such as `FLUSHALL`, `CONFIG SET`, or `SHUTDOWN`.
- Multi-pane workflows or collaborative operator features.
## 9. Acceptance Standards For This Phase
### 9.1 Runtime Mode Boundary
- Browser dev mode must remain explicitly demo-only.
- Desktop mode must clearly indicate that it is operating against live Redis.
- The UI must not blur demo output and live output.
### 9.2 Connection Management
- User can create a visible profile draft with validated host, port, DB, and name fields.
- User can run a live connection test in Tauri mode before treating the profile as usable.
- Workspace always shows the active connection and DB after selection.
- Connection failures surface stable, operator-readable messaging for at least auth failure, invalid target, and connection failure.
### 9.3 Browse And Search
- User can browse keys in the active DB without assuming a full blocking fetch.
- Search is scoped to the active DB and returns predictable empty states.
- Key rows expose at minimum name, type, and TTL state when available.
- Clearing search returns the user to normal browse behavior without reconnecting.
### 9.4 Inspect, Save, And TTL
- Selecting a key opens a readable inspector with metadata and typed value structure.
- String keys expose save actions only when the backend confirms write support.
- Saving a string key refreshes the visible value state and preserves TTL.
- Non-string keys remain explicitly read-only.
- TTL can be set or removed for the selected key and the inspector reflects the new TTL state after success.
- Failed save or TTL operations preserve user context and show a clear outcome.
### 9.5 Command Console
- The console always shows which connection and DB it targets.
- The user can run a single command and see a clear result or error.
- Dangerous or administrative commands outside scope are blocked before they appear to succeed.
- Command history distinguishes live results from demo fallback results.
### 9.6 Release Evidence Required Before Calling V1 Accepted
- Live Tauri smoke evidence against the seeded fixture must exist for connect, browse, inspect, string save, TTL update, and command execution.
- Linux launch and packaging evidence must remain repeatable.
- macOS and Windows remain outside current acceptance until build and smoke evidence exist.
- The in-repo product requirements document must exist and stay aligned with QA artifacts.
## 10. CLI Demo To Product Evolution
The repository currently centers on the desktop path, but the intended evolution still follows a CLI-to-product logic at the capability level:
### Stage A: Shared Redis capability proof
Use `redis-core` or a thin CLI surface to prove:
- connection and authentication
- DB selection
- browse pagination
- typed value reads
- narrow string write rules
- TTL mutation rules
- safe command execution
### Stage B: Live desktop workflow
Map those validated capabilities into one operator workspace with:
- visible connection scope
- browse and search
- typed inspection
- string save and TTL actions
- safe command tray
### Stage C: Product hardening
Add the product behaviors that make the workflow trustworthy:
- consistent failure copy
- explicit unsupported-state messaging
- confirmation and safety boundaries
- smoke evidence capture
- clearer onboarding and profile handling
### Stage D: Productization
Only after the operator baseline is stable should the team expand toward:
- persisted profile management
- secure secret handling
- true destructive flows with audited confirmation
- cross-platform packaging evidence
- broader data-type editing if still justified by user demand
## 11. Handoff To CTO
The CTO should split implementation and closure work into these product slices:
- Connection profile handling, validation, and runtime-mode boundary
- Browse and search flows on top of the existing `SCAN` contract
- Inspector and typed value presentation
- String save and TTL workflows
- Command safety boundary and blocked-command rules
- Release hardening, evidence capture, and cross-platform packaging follow-up
The CTO should treat the following as boundary conditions, not optional polish:
- do not expand editing surface before current string and TTL flows are fully evidenced
- do not treat mock delete confirmation as shipped delete capability
- do not treat browser demo mode as release evidence for Redis-backed acceptance
## 12. Open Risks And Dependencies
- Delete is visible in the shell but not real in the backend. That can confuse operators unless messaging stays explicit.
- Lack of persisted profiles and secrets limits day-to-day usability and onboarding continuity.
- The backend contract still rejects TLS modes beyond `disabled`, which narrows usable environments.
- QA evidence is improving, but Redis-backed feature acceptance remains incomplete as of 2026-03-30.
## 13. Scope Classification Follow-Up On 2026-03-31
The PM scope-classification follow-up for `HAC-19` is recorded in `plans/2026-03-31-hac-19-scope-classification.md`.
Result:
- no new requests were approved into `desktop-v1`
- `Add Key` is classified as a `desktop-v1.1` candidate only
- blue visual refresh and bilingual UI remain `later`
This keeps the current phase focused on proving and accepting the existing live desktop operator baseline before any visible scope expansion.
## 14. Add Key Boundary On 2026-03-31
The repository now contains an implemented Add Key path, but PM does not treat code presence as automatic current-phase approval.
Current rule:
- `Add Key` remains outside `desktop-v1` acceptance and release claim
- it stays a `desktop-v1.1` candidate until PM explicitly reclassifies it
The boundary note for CTO and QA is recorded in `plans/2026-03-31-add-key-phase-boundary.md`.