feat(desktop): add redis gui foundation baseline

Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
Senior Frontend Engineer
2026-03-28 10:39:40 +00:00
commit 8d50243d36
56 changed files with 17423 additions and 0 deletions

92
docs/architecture.md Normal file
View File

@@ -0,0 +1,92 @@
# Backend Foundation
## Goals
- 使用 Rust workspace 作为产品的长期结构。
- 将可复用业务能力放入 `crates/redis-core`,避免把 Redis 语义散落在 GUI 层。
- 让 desktop 壳层只负责窗口与命令桥接,不负责领域规则。
## Current Domain Model
当前只定义启动和连接建模所需的最小领域对象:
- `ConnectionTarget`: Redis 目标地址、端口、数据库序号、用户名和 TLS 模式。
- `ConnectionProfileDraft`: GUI 或未来 CLI 收集到的连接表单草稿。
- `RedisConnectionRequest`: 一次请求内使用的连接上下文,包含非持久化密码。
- `RedisKeyBrowseRequest`: key 浏览请求,显式携带 `SCAN` cursor、pattern 与 page size。
- `RedisKeyMetadataRequest`: 单个 key 的元数据读取请求,用于 inspector 刷新与删除前确认。
- `RedisValueReadRequest`: 单个 key 的 typed value 读取请求。
- `RedisValueWriteRequest`: 单个 key 的 value 写入请求;当前仅允许 string 整值替换。
- `RedisKeyTtlUpdateRequest`: 单个 key 的 TTL 修改请求,支持设置过期时间和移除 TTL。
- `RedisCommandRequest`: 基础命令执行请求,显式拆分命令名与参数。
- `RedisKeyMetadata`: key 浏览与 inspector 共享的稳定元数据结构,覆盖存在性、类型和 TTL。
- `RedisValueRecord`: inspector 使用的稳定结构,组合 key 元数据、typed value 数据、value 写入能力和 TTL 修改能力。
- `RedisValueData`: typed value 返回体,覆盖 `string/hash/list/set/zset/stream` 与缺失 key。
- `RedisValueWriteCapability`: 当前明确区分 `replace_string``none`,让入口层知道哪些类型仍是只读。
- `CommandExecutionResult`: 以稳定的 RESP2 派生结构返回基础命令结果。
- `BackendError`: 结构化错误码,区分连接配置、认证、连接失败和命令失败。
- `BackendBootstrap`: 向入口层暴露当前支持的能力边界和安全约束。
这些对象构成当前阶段的稳定后端契约:
- 单实例连接测试通过 `PING` 验证回路。
- 认证通过请求态 `AUTH` 握手完成。
- DB 切换在连接建立后通过 `SELECT` 保证。
- 命令执行按 RESP2 基础类型映射为稳定结构体,避免 GUI 直接处理原始 socket 数据。
- key 浏览按 `SCAN` 分页返回,并为每个命中的 key 补充 `TYPE``PTTL` 元数据。
- inspector 可对单个 key 单独刷新元数据,避免 UI 为了刷新单项而重跑整页浏览。
- typed value surface 当前覆盖 `string/hash/list/set/zset/stream` 六类 Redis 数据,并显式保留类型差异。
- V1 value 编辑只允许已有 string key 的整值替换;非 string key 保持只读,避免错误覆盖集合类型。
- string 写入会保留原 TTLTTL 修改独立通过 `PERSIST` / `PEXPIRE` 语义建模。
## Persistence Boundary
当前阶段明确保持以下约束:
- 连接密钥和密码不落盘。
- 密码仅存在于单次 `RedisConnectionRequest` 的内存生命周期内。
- 连接配置目录和迁移策略尚未启用,因此不存在历史数据兼容承诺。
- GUI 仅消费 `redis-core` 导出的稳定结构体,不直接定义持久化格式。
后续进入产品化时,应新增独立的存储 crate并补充
- 配置文件 schema
- 版本字段与迁移器
- 敏感信息存储策略
- 向前/向后兼容测试
## Compatibility Notes
- 当前后端只覆盖单实例 Redis 的同步 RESP2 交互。
- workspace 通过 `.cargo/config.toml` 启用 `resolver.incompatible-rust-versions = "fallback"`,避免在 `rustc 1.85` 环境下把 Tauri 传递依赖解析到更高 MSRV 的版本带。
- key 浏览当前基于 Redis `SCAN` + 每 key `TYPE`/`PTTL` 的顺序读取,优先保证正确性和契约清晰,而不是在原型期过早做 pipeline 或并发优化。
- `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 写入使用事务化的 `SET ... XX` 与 TTL 恢复,避免把非 string key 误写成 string也避免默认清空现有 TTL。
- key 元数据仍未覆盖编码、内存占用、slot、cluster 拓扑或 ACL 细粒度探测。
- 这层契约已足以支撑连接管理、基础命令台、key 浏览、value inspector 与 TTL 编辑,但还不足以覆盖 cluster、pub/sub、流式结果或长连接会话管理。
## 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`
- 任何新增入口都应优先复用 `redis-core`,保证 CLI、GUI 行为模型一致。
- 桌面入口允许演进 UI但不应绕过领域约束自行定义 Redis 协议行为。
## Verification Notes
当前已验证的重点是:
- Rust 核心 crate 的测试与格式正确性
- Tauri desktop 命令桥可以在当前 Linux 环境完成编译检查
- Linux 下 Tauri 所需系统依赖已通过 `pkg-config` 验证
当前已完成的验证:
- `cargo test -p redis-core`
- mock Redis 测试覆盖 AUTH、SELECT、PING、SCAN 分页、TYPE、PTTL、缺失 key 元数据映射、typed value 读取、string 安全写入和 TTL 修改
- `Cargo.lock` 已重新解析到 Rust 1.85 兼容版本带:`serde_with 3.17.0``darling 0.21.0``time 0.3.44`
- `cargo check -p desktop-shell --locked`
- `pkg-config` 校验通过:`gtk+-3.0``webkit2gtk-4.1``libsoup-3.0``javascriptcoregtk-4.1`
- `pnpm run desktop:build`

View File

@@ -0,0 +1,123 @@
# Redis GUI Desktop Workspace Baseline
Date: 2026-03-27
Owner: Senior Frontend Engineer
Related issues: HAC-8, HAC-9, HAC-10, HAC-11
## Current Assessment
- The repository already had a valid desktop entry at `apps/desktop` and a working Tauri bridge for `backend_bootstrap`.
- The repository also already exposed stable desktop commands for connection testing and command execution through `test_redis_connection` and `execute_redis_command`.
- The previous frontend surface was only a minimal Vite JavaScript shell and did not match the target implementation stack for downstream UI work.
- The first frontend milestone therefore needed a visible React workspace before feature delivery could continue efficiently.
## Recommended V1 UI Scope
The first visible product surface should include:
- a stable desktop shell with a persistent connection context
- a connection library and a new-connection entry point
- a database switcher that keeps the current DB visible
- a key browser with search and selection states
- a value inspector with string-edit support and explicit read-only states
- a scoped command tray that makes connection and DB context obvious
- destructive-action confirmation that repeats the key name and DB
The first visible product surface should not include:
- cluster topology
- metrics dashboards
- bulk actions
- multi-connection comparison
- full editing support for every Redis type
- privileged administrative commands
## Information Architecture
Use a four-zone workspace:
1. Utility rail
2. Browser pane
3. Inspector pane
4. Command tray
### Utility rail
- Connection library
- New connection form entry point
- Active DB switcher
- Safety posture and backend boundary summary
### Browser pane
- Search or key pattern filter
- Result count summary
- Compact key rows with type and TTL
- Empty state when no keys match
### Inspector pane
- Selected key header
- Value surface
- Save action for string keys only
- TTL control for set and persist flows
- Explicit read-only treatment for unsupported types
- Metadata and support note beside the edited surface
### Command tray
- Scoped command input
- Visible connection and DB scope
- Result history
- Hard block for destructive or administrative commands
## Visual Direction
- Calm and editorial rather than dashboard-like
- Dense enough for operator workflows without visual noise
- Structure driven by typography, separators, and restrained tinted surfaces
- Strong emphasis only for selection, state, or destructive intent
- Support both light and dark modes with low-noise neutral palettes
## Implementation Baseline Added On 2026-03-27
- `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.
- 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.
- 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.
- Zero-result key searches now place the inspector into an explicit empty state instead of leaving a stale key visible.
## QA Acceptance For This Milestone
- The shell renders four distinct zones: rail, browser, inspector, command tray.
- The header keeps app version, runtime mode, and build mode visible for smoke validation.
- The utility rail exposes a copyable QA snapshot with runtime, connection, selection, and latest command context.
- The active connection and active DB stay visible without opening a modal.
- Search filters the browser list and shows a no-results state.
- When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
- The connection action distinguishes desktop live testing from browser demo fallback.
- Invalid draft connections cannot be created from the visible shell.
- Non-string keys are explicitly read-only.
- String keys show a save affordance near the value surface.
- TTL controls stay beside the inspector metadata and expose both set and remove flows.
- Delete requires a second confirmation step that includes key name and DB context.
- The command tray visibly blocks dangerous administrative commands.
- Command history marks whether each result came from the live desktop bridge or the demo shell.
## Run Notes
Use:
```bash
pnpm install
pnpm run desktop:dev
```
Notes:
- `pnpm run desktop:dev` is the browser shell path. It supports layout review and demo fallback only.
- `pnpm run desktop:tauri:dev` is the desktop integration path. Use it when QA or backend needs to validate the existing command bridge against a live Redis target.
- Use `pnpm run desktop:build` for a production bundle check before handing the shell to QA or integration work.

View File

@@ -0,0 +1,38 @@
# Redis GUI V1 Acceptance Matrix
Date: 2026-03-27
Owner: QA Engineer
## Evidence Collected On 2026-03-27
- A fresh `cargo test -p redis-core` rerun passes in this session with 16 tests green.
- `pnpm install --lockfile-only` passes at repository root after adding `pnpm-workspace.yaml`.
- `pnpm run desktop:build` passes and emits `apps/desktop/dist/`.
- `pnpm run desktop:tauri:build` now completes Linux `.deb` and `.rpm` artifact generation under `target/release/bundle/`, then fails later in the AppImage stage with `io: Connection reset by peer (os error 104)`.
- 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.
- A repeatable local Redis fixture and smoke runbook now exist in `scripts/redis-fixture/` and `docs/qa/local-desktop-smoke.md`.
## Matrix
| Scope | Happy Path Acceptance | Failure Path Acceptance | Required Evidence | Current Status |
| --- | --- | --- | --- | --- |
| Linux app smoke | App installs or launches from a documented command, opens main window, connects to test Redis, exits cleanly | Missing Redis, bad host, bad password, unsupported DB or network loss surface actionable error and app stays stable | Launch steps, versioned artifact or dev command, screenshots, QA run log | Partially blocked: documented fixture and smoke path now exist, but a full Linux launch-and-connect evidence set is still pending |
| 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, and a copyable QA snapshot visible; command history labels live vs demo results | Empty search state clears the inspector selection, read-only non-string value state, destructive confirmation, and browser-mode demo fallback stay stable and explicit | `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, 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 clear messaging | Tauri run log, screenshots, repeatable steps, Redis target | Partially blocked: the shell now validates draft name/host/port/DB locally and calls the real connection-test command, and a seeded Redis smoke path exists, 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 | 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 | No matches, invalid pattern, and very large result sets are handled predictably | Seed dataset, search queries, measured behavior | Partially blocked: desktop UI now maps search to live browse requests, but fixture-backed evidence and measured limits are still pending |
| Value editing | Open supported value types, edit, save, and refresh persisted value | Concurrent modification, invalid payload, and permission error preserve user context and surface failure | Before/after values, screenshots, repeatable steps | Partially blocked: string read/save/refresh is wired through the live desktop bridge and non-string types stay explicitly read only, but fixture-backed evidence and broader editing scope remain pending |
| TTL operations | View TTL, set TTL, remove TTL, and verify expiration behavior | Invalid TTL, already expired key, and permission error handled safely | Seed dataset, timestamps, verification steps | Partially blocked: desktop UI now exposes live TTL set and remove controls through the existing contract, but seeded-fixture validation evidence is still missing |
| Command console | Execute safe Redis commands in Tauri desktop mode and show result or error output with explicit live/demo labeling | Invalid command, long-running command, and blocked dangerous command are handled predictably | Command transcript, screenshots, allow or deny rules | Partially blocked: the desktop UI now calls the real command execution bridge, but it is not yet validated against a shared live Redis fixture and dangerous mutations still stay blocked at shell level |
| Dangerous operation confirmation | Delete, flush, overwrite, or destructive commands require explicit confirmation | Cancel path does not mutate data; confirm path mutates only intended scope | Confirmation UX screenshots, before/after data | Blocked: feature not implemented |
| Installer and packaging | Package metadata, icon, version, and uninstall behavior are correct on each target OS | Corrupt install, upgrade, downgrade, and missing dependency behavior are documented or handled | Artifact checklist, install logs, uninstall evidence | Partially blocked: Linux `.deb` and `.rpm` artifacts now exist, but AppImage failed and install or uninstall evidence is still absent |
## Current Acceptance Judgment
- No Redis-backed Redis GUI V1 feature acceptance item can be marked passed on 2026-03-27.
- 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, value read/write, and command execution, draft-validation and empty-state behavior are explicit, and shared UI scope documentation is present in-repo.
- Rust source-level test evidence is now current for `redis-core`, Linux package artifacts exist for `.deb` and `.rpm`, but live Redis screenshots and installation evidence are still required.
- QA can now reuse the documented fixture and smoke path, but feature acceptance and release sign-off remain blocked on end-to-end desktop evidence.

View File

@@ -0,0 +1,50 @@
# Cross-Platform Smoke Plan
Date: 2026-03-27
Owner: QA Engineer
## Goal
Provide one minimal but repeatable smoke flow for Windows, macOS, and Linux that proves a release candidate is installable, launchable, connectable to Redis, and safe around destructive actions.
## Preconditions Required Before Smoke Can Run
- A documented build command or signed artifact exists for each target OS.
- A seedable Redis dataset exists with strings, hashes, lists, sets, sorted sets, JSON or binary payload samples if supported, and keys with TTL.
- A documented demo or local startup path exists.
- Smoke environment variables, sample credentials, and cleanup steps are documented.
## Minimal Smoke Flow Per Platform
1. Install or launch the app from the documented artifact or dev command.
2. Verify window renders and version or build identity is visible.
3. Add a connection to the seeded Redis instance and reconnect once.
4. Browse keys and open at least one key from each supported type.
5. Search for known keys and confirm zero-result handling.
6. Edit one value, then verify persisted data through refresh or re-open.
7. Change TTL on one key, remove TTL on another, and verify the observed state.
8. Trigger one dangerous action and verify both cancel and confirm paths.
9. Open command console, run one safe read command and one invalid command.
10. Close and relaunch the app, then confirm recent connection state is consistent with product requirements.
## Failure-Path Smoke
- Start app when Redis is unreachable.
- Attempt login with bad host or credential data.
- Disconnect Redis mid-session.
- Trigger invalid value save.
- Attempt dangerous action, then cancel.
- Run unsupported or invalid command in console.
## Required Evidence
- Platform, build identifier, and execution timestamp.
- Screenshots for launch, connection success, key browse, edit save, dangerous-action confirmation, and error state.
- Exact dataset version and Redis image or binary version.
- QA log with pass, fail, blocked, or not-run result per step.
## 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.
- 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.

View File

@@ -0,0 +1,26 @@
# Defect Classification
Date: 2026-03-27
Owner: QA Engineer
## Severity
| Severity | Definition | Release Impact |
| --- | --- | --- |
| S0 | Data loss, irreversible destructive action without confirmation, security exposure, or app cannot launch on a supported platform | Ship blocker |
| S1 | Core workflow broken: cannot connect, browse keys, search, edit values, manage TTL, or execute documented console flow | Ship blocker unless scope is formally descoped |
| S2 | Important workflow degraded with workaround, repeatable crash in non-core flow, major UI corruption, or packaging issue with workaround | Fix before release candidate or explicitly waive |
| S3 | Minor UI issue, copy issue, low-impact inconsistency, or edge-case defect with narrow reach | Can ship with tracking |
## Priority Guidance
- `critical`: active release blocker or broad regression.
- `high`: should be fixed in current milestone.
- `medium`: should be fixed after core acceptance path is stable.
- `low`: backlog candidate.
## QA Reporting Rules
- Every defect report should include environment, build id, exact steps, expected result, actual result, and evidence.
- If a defect is not reproducible, state attempts and why the result is inconclusive.
- If a defect is blocked by missing product implementation, report it as a gap, not as a functional failure.

View File

@@ -0,0 +1,87 @@
# Local Desktop Build And Smoke Runbook
Date: 2026-03-27
Owner: Senior Backend Engineer
## Goal
Provide one repeatable local build and smoke path that any engineer or QA can run against a seeded Redis fixture.
## Prerequisites
- Rust 1.85+
- Node.js 24+
- `pnpm` 10+
- Docker CLI with permission to run containers
- Linux desktop build prerequisites for Tauri, including WebKitGTK and GTK3 development packages
## Standard Commands
```bash
pnpm install
cargo test -p redis-core
pnpm run desktop:build
pnpm run desktop:tauri:build
```
Expected package output path on Linux after a successful Tauri build:
```text
target/release/bundle/
```
Linux preflight checks for native desktop libraries:
```bash
pkg-config --modversion gtk+-3.0
pkg-config --modversion webkit2gtk-4.1
pkg-config --modversion libsoup-3.0
```
All three commands should return a version. If any of them fail, `pnpm run desktop:tauri:build` is still environment-blocked even if the repository scripts are correct.
## Local Redis Fixture
Start and seed a deterministic Redis instance on `127.0.0.1:6380`:
```bash
./scripts/redis-fixture/start.sh
./scripts/redis-fixture/seed.sh
```
Stop and remove the fixture:
```bash
./scripts/redis-fixture/stop.sh
```
Seeded keys:
- `smoke:string`
- `smoke:string:ttl`
- `smoke:hash`
- `smoke:list`
- `smoke:set`
- `smoke:zset`
- `smoke:stream`
## Linux Smoke Steps
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.
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.
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.
## Current Validation Boundary
- `cargo test -p redis-core` passes in the current workspace.
- `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.

View File

@@ -0,0 +1,35 @@
# Release Readiness Checklist
Date: 2026-03-27
Owner: QA Engineer
## Must Be True Before Redis GUI V1 Can Ship
- A documented build or package path exists for Linux, macOS, and Windows.
- Smoke steps are executable and repeatable by someone other than the original implementer.
- Seed data or demo environment is documented and reproducible.
- Core workflows have explicit pass evidence:
- connection management
- key browsing
- search
- value editing
- TTL operations
- command console
- dangerous operation confirmation
- 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
- 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: 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.
## Minimum Sign-Off Evidence
- Test run log with date, platform, build id, and tester.
- Screenshots or terminal evidence for each smoke step.
- Defect list with severity and explicit disposition.
- Final QA judgment: pass, fail, blocked, or pass with waiver.

46
docs/qa/test-strategy.md Normal file
View File

@@ -0,0 +1,46 @@
# QA Test Strategy
Date: 2026-03-27
Owner: QA Engineer
## Test Objectives
- Validate Redis GUI V1 against explicit acceptance criteria, not against "it runs on my machine".
- Cover both happy paths and failure paths for connection, browsing, editing, TTL, console, and destructive actions.
- Keep release blocking conditions visible before packaging and launch week.
## Test Layers
| Layer | Purpose | Expected Automation | Exit Signal |
| --- | --- | --- | --- |
| Unit | Validate pure logic, parsing, serialization, and state transitions | High | Deterministic CI pass |
| Integration | Validate Redis protocol handling, repository layer, seed setup, and persistence boundaries | Medium | Seeded Redis scenarios pass |
| UI smoke | Validate launch, connect, browse, edit, TTL, console, dangerous-action confirmation | Medium | One repeatable smoke flow per OS passes |
| Regression | Validate previously broken paths and high-risk areas before release | Mixed | No open critical regressions |
| Release readiness | Validate artifact, install, uninstall, and basic recovery behavior | Low to medium | Checklist complete with evidence |
## Environments
- Linux: current local environment available to QA.
- macOS: required for release acceptance, currently not provisioned in this repository.
- Windows: required for release acceptance, currently not provisioned in this repository.
## Test Data Strategy
- Maintain one documented seed dataset for predictable keys, TTL, and value shapes.
- Track Redis version used for QA evidence.
- Ensure cleanup steps return the environment to a known state.
## Evidence Standard
- Every pass or fail must cite the command, artifact, or screenshot used.
- "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
- 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`.