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

feat(desktop): add redis gui foundation baseline

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

28
plans/2026-03-27-desktop-live-bridge.md Normal file
View File

@@ -0,0 +1,28 @@
# Desktop Live Bridge Plan
Date: 2026-03-27
Owner: Senior Frontend Engineer
Related issues: HAC-9, HAC-11
## Goal
Move the visible desktop shell from pure mock interaction to partial real integration by consuming the existing Tauri connection-test and command-execution commands without changing backend scope.
## Scope Delivered
1. Wire the connection test action to `test_redis_connection` in Tauri desktop mode.
2. Wire the command tray to `execute_redis_command` in Tauri desktop mode.
3. Keep browser-only `npm run desktop:dev` explicit about demo fallback so PM, CTO, and QA do not mistake it for live Redis behavior.
4. Update shared docs so run paths and acceptance language distinguish shell review from desktop integration review.
## Constraints
- Do not add or alter Rust command contracts.
- Do not present browser-shell fallback as live Redis evidence.
- Keep key browsing, editing, and destructive actions inside current shell scope until backend feature contracts are ready.
## Exit Criteria
- `npm run desktop:build` succeeds after the bridge work.
- The UI labels command history as live or demo.
- Tauri desktop mode can attempt a real connection test and command execution through existing commands.

28
plans/2026-03-27-frontend-ui-foundation.md Normal file
View File

@@ -0,0 +1,28 @@
# Frontend UI Foundation Plan
Date: 2026-03-27
Owner: Senior Frontend Engineer
Related issues: HAC-8, HAC-9, HAC-10, HAC-11
## Goal
Move `apps/desktop` from a placeholder shell to a visible React workspace that downstream product, backend, and QA work can inspect.
## Scope Delivered
1. React and Tailwind baseline inside `apps/desktop`.
2. Visible desktop workspace with connection library, DB switcher, key browser, inspector, and command tray.
3. Mock interaction for string edits, command history, and destructive confirmation.
4. Shared UI baseline and QA-facing acceptance notes in project docs.
## Constraints
- Do not expand backend contract beyond the existing `backend_bootstrap` surface.
- Do not imply real Redis persistence; mock interactions must stay clearly marked.
- Keep the UI shaped for long-session operator work rather than generic dashboard styling.
## Exit Criteria
- `npm run desktop:build` succeeds.
- The shell is visually inspectable by PM, CTO, and QA.
- Shared docs explain scope, run path, and acceptance checks.

38
plans/2026-03-27-hac-15-desktop-build-smoke.md Normal file
View File

@@ -0,0 +1,38 @@
# HAC-15 Desktop Build, Packaging, And Smoke Plan
Date: 2026-03-27 UTC
Owner: Senior Backend Engineer
Issue: HAC-15
## Goal
Make the desktop repository usable through one stable build path, one stable package path, and one repeatable local Redis smoke path.
## Current Findings
- The original `tauri.conf.json` pre-build and pre-dev commands assumed the wrong working directory and caused `tauri build` to fail before the real Rust/Tauri flow began.
- The repo already had a valid desktop frontend build and a validated shared Rust backend core, but no stable `pnpm` workspace setup for the desktop shell.
- QA had explicit blockers around missing seed data, missing Docker or smoke automation, and missing reusable build instructions.
## Changes In This Pass
1. Standardize the workspace on `pnpm` by adding `packageManager`, `pnpm-workspace.yaml`, and root desktop scripts.
2. Fix Tauri `beforeDevCommand` and `beforeBuildCommand` so they execute against the desktop workspace directly.
3. Add a Docker-backed Redis fixture with start, seed, and stop scripts.
4. Add a local desktop smoke runbook and refresh README and QA evidence docs around the new commands and fixture path.
## Verification
- Passed: `cargo test -p redis-core`
- Passed: `pnpm install --lockfile-only`
- Passed: `pnpm run desktop:build`
- Passed: `./scripts/redis-fixture/start.sh`
- Passed: `./scripts/redis-fixture/seed.sh`
- Passed: `./scripts/redis-fixture/stop.sh`
- In progress: `pnpm run desktop:tauri:build` now clears the pre-build script failure and reaches Cargo dependency download and compile steps
## Remaining Risk
- This heartbeat has not yet produced a saved unsigned package artifact for Linux, macOS, or Windows.
- First-run Cargo package downloads remain slow and can serialize on the shared package-cache lock, so package verification should be rerun in a clean single-build window.
- End-to-end smoke evidence inside the desktop UI still depends on frontend surfaces that are only partially implemented.

36
plans/2026-03-27-qa-acceptance-baseline.md Normal file
View File

@@ -0,0 +1,36 @@
# QA Acceptance Baseline Plan
Date: 2026-03-27
Owner: QA Engineer
## Objective
Create the first acceptance matrix and cross-platform smoke plan for Redis GUI V1, based only on repository evidence.
## Outputs
- `docs/qa/acceptance-matrix.md`
- `docs/qa/cross-platform-smoke-plan.md`
- `docs/qa/test-strategy.md`
- `docs/qa/defect-severity.md`
- `docs/qa/release-readiness-checklist.md`
## Immediate QA Priorities
1. Keep blocked acceptance items visible until product entrypoints exist.
2. Require a reproducible seed or demo path before any feature is marked accepted.
3. Require at least one smoke run per supported OS before release sign-off.
## Known Blockers
- `npm run desktop:tauri:build` currently fails because its pre-build command targets a non-existent parent `build` script.
- Repository does not yet contain Docker, demo, or seed assets.
- Current automated coverage is limited to foundation-model tests in `crates/redis-core`.
- Completed issue comments for `HAC-2` and `HAC-8` reference shared files that are absent from the current workspace, so QA cannot inspect those artifacts locally.
- Existing Rust test artifacts in `target/` are stale relative to current source, so backend baseline verification needs a fresh `cargo test` rerun.
## Alignment
- Product acceptance source: `HAC-2` issue scope and completion comment remain the current acceptance baseline for connect, browse, search, edit, and command console flows.
- CTO priority source: `HAC-15` is now the high-priority owner for Tauri build, packaging, local smoke steps, and Redis fixture conventions.
- QA closure for this plan remains downstream of `HAC-15`, backend feature issues `HAC-5` to `HAC-7`, and frontend feature issues `HAC-9` to `HAC-11`.

153
plans/2026-03-27-redis-gui-v1-status.md Normal file
View File

@@ -0,0 +1,153 @@
# Redis GUI V1 Status
Date: 2026-03-27 UTC
Project: `redis-gui-foundation`
Scope owner: Project Manager
Note:
- Frontend stack-baseline observations in this snapshot are superseded by `plans/2026-03-27-frontend-ui-foundation.md` and `docs/frontend-workspace-baseline.md`.
## Snapshot
- Project and goal are still marked `planned` in Paperclip, but execution has already started across product, architecture, backend, frontend, QA, and PM tracks.
- The repository contains a visible foundation: Rust workspace, `apps/desktop` Tauri shell, `crates/redis-core`, and `docs/architecture.md`.
- No issue is currently marked `blocked`, but the critical path is still concentrated in a few serial owner chains.
- There is no git commit history yet. Current project state exists only as an uncommitted workspace snapshot.
## Milestones
### 1. Foundation
Exit criteria:
- Product scope is inspectable.
- Architecture boundary is inspectable.
- Repo bootstrap is usable for follow-on implementation.
Issue alignment:
- Done: `HAC-2` Product scope definition
- In progress: `HAC-3` Architecture plan
- In progress: `HAC-4` Repo and Tauri/Rust foundation
- In progress: `HAC-13` Milestones, dependency map, risk tracking
Assessment:
- Foundation has visible repo evidence for architecture and bootstrap.
- Product scope has status evidence in Paperclip, but its comment points to files that are not present in the current workspace. This is an evidence gap that should be resolved before downstream teams rely on that artifact as the single source of truth.
### 2. Desktop
Exit criteria:
- Connection management, key browsing, value editing, and command console have an agreed UI baseline and working implementation path.
Issue alignment:
- In progress: `HAC-8` Desktop information architecture and visual baseline
- Todo: `HAC-9` Desktop shell and connection management UI
- Todo: `HAC-10` Key browser, viewer, editor
- Todo: `HAC-11` Command console and result panel
Assessment:
- Desktop execution has started only at the design baseline layer.
- The current repository still uses a minimal Vite shell with plain JS/CSS. The target stack in the project goal is React + shadcn/ui + Tailwind, so the desktop milestone is not yet on a stable implementation baseline.
### 3. Release
Exit criteria:
- QA matrix exists.
- Cross-platform smoke path is defined and executable.
- Desktop packaging path is proven on target operating systems.
Issue alignment:
- In progress: `HAC-12` Acceptance matrix and cross-platform smoke plan
Assessment:
- QA can define matrix structure now, but release readiness remains downstream of architecture, backend implementation, desktop implementation, and packaging verification.
## Issue Board By State
### Completed
- `HAC-2` Define Redis GUI V1 user scenarios, scope, and acceptance standards
### In Progress
- `HAC-3` Produce Tauri + Rust + React architecture
- `HAC-4` Initialize repo and Tauri / Rust foundation
- `HAC-8` Define desktop information architecture and visual baseline
- `HAC-12` Build QA matrix and smoke plan
- `HAC-13` Build milestones, dependency map, and risk tracking
### Not Started
- `HAC-5` Implement connection management and base command execution
- `HAC-6` Implement key browsing, search, and type detection
- `HAC-7` Implement typed value read/write abstraction
- `HAC-9` Implement desktop shell and connection management UI
- `HAC-10` Implement key browser, value viewer, and editor
- `HAC-11` Implement command console and result panel
### Blocked
- No issue is explicitly marked `blocked` as of 2026-03-27 UTC.
- Practical blockers still exist in the dependency chain and should be treated as pre-block conditions, not as proof of smooth execution.
## Dependency Map
- `HAC-2` -> `HAC-3`, `HAC-8`, `HAC-12`
- `HAC-3` -> `HAC-4`, `HAC-5`, `HAC-6`, `HAC-7`, `HAC-9`, `HAC-10`, `HAC-11`
- `HAC-4` -> `HAC-5`, `HAC-6`, `HAC-7`, `HAC-9`, `HAC-10`, `HAC-11`
- `HAC-8` -> `HAC-9`, `HAC-10`, `HAC-11`
- `HAC-5`, `HAC-6`, `HAC-7` -> `HAC-9`, `HAC-10`, `HAC-11`
- `HAC-9`, `HAC-10`, `HAC-11` -> `HAC-12`
## Current Critical Path
`HAC-2` -> `HAC-3` + `HAC-4` -> `HAC-5` + `HAC-6` + `HAC-7` and `HAC-8` -> `HAC-9` + `HAC-10` + `HAC-11` -> `HAC-12`
Notes:
- `HAC-4` has visible repo output already, but it is not yet marked done.
- The frontend implementation branch cannot move cleanly until `HAC-8` defines the intended interaction and visual contract.
- QA closure is downstream of both implementation branches, not parallel to them.
## CTO Attention Required
### 1. Product evidence gap
- `HAC-2` is marked done, but its completion comment references `docs/redis-gui-v1-product-requirements.md` and `plans/2026-03-27-redis-gui-foundation-product-plan.md`.
- Those files are not present in the current project workspace.
- Risk: downstream teams believe the product baseline is settled, but the local source of truth is missing.
### 2. Frontend baseline does not yet match target stack
- The goal and issue constraints specify React + shadcn/ui + Tailwind.
- The current desktop shell is plain Vite JS/CSS with no visible React or Tailwind setup.
- Risk: `HAC-9` to `HAC-11` may need stack migration work before feature delivery can become efficient.
### 3. Serial ownership on both critical branches
- One backend engineer owns `HAC-4` to `HAC-7`.
- One frontend engineer owns `HAC-8` to `HAC-11`.
- Risk: any stall in either owner chain becomes a full milestone delay because there is little parallel slack.
### 4. Release work started before packaging proof exists
- `HAC-12` is in progress, but there is no demonstrated cross-platform packaging result yet.
- Risk: the smoke plan may be structurally correct but still disconnected from the actual install/build path.
### 5. Project-level status drift
- Active execution is happening, but the project and goal still show `planned`.
- Risk: board-level reporting understates active work and can hide overdue coordination.
## Fixed Sync Rhythm
- Every owner must leave a comment when an issue moves from exploration to concrete output, from output to blocker, or from blocker to unblocked.
- PM heartbeat snapshot: 10:00 UTC and 18:00 UTC, or immediately when a critical-path issue changes to `blocked`.
- CTO escalation conditions:
- a critical-path issue has no new artifact or comment across one full sync window
- a done issue references missing artifacts
- frontend or backend baseline changes invalidate downstream queued work
## Immediate Follow-Up
- Confirm whether `HAC-2` deliverables exist outside the current workspace or need to be recreated here.
- Keep `HAC-3`, `HAC-4`, and `HAC-8` under tight observation because they define the usable baseline for all queued implementation work.
- Do not promote any milestone from foundation to desktop-complete until the repo contains inspectable artifacts for product, architecture, and frontend baseline together.

40
plans/2026-03-28-frontend-smoke-validation.md Normal file
View File

@@ -0,0 +1,40 @@
# Frontend Smoke Validation Snapshot
Date: 2026-03-28 UTC
Owner: Senior Frontend Engineer
Related issues: HAC-9, HAC-11, HAC-15
## Goal
Revalidate the current desktop frontend and packaging path against the repository's shared smoke prerequisites.
## Evidence Captured
1. Passed: `cargo test -p redis-core`
2. Passed: `pnpm run desktop:build`
3. Passed: `./scripts/redis-fixture/start.sh`
4. Passed: `./scripts/redis-fixture/seed.sh`
5. Passed: `./scripts/redis-fixture/stop.sh`
6. Partial pass: `pnpm run desktop:tauri:build`
## Artifact Evidence
- `target/release/bundle/deb/Redis GUI Foundation_0.1.0_amd64.deb`
- `target/release/bundle/rpm/Redis GUI Foundation-0.1.0-1.x86_64.rpm`
## Packaging Outcome
- Tauri build completed the Linux release binary and produced `.deb` and `.rpm` artifacts.
- The same run failed in the AppImage step with `io: Connection reset by peer (os error 104)`.
## Remaining Gaps
- No saved Tauri-window screenshots or interaction logs exist yet for live browse, edit, TTL, or command flows.
- macOS and Windows package evidence remains absent.
- AppImage packaging needs a separate rerun or targeted investigation if that bundle format is required.
- This environment currently has no `DISPLAY`, `xvfb-run`, or desktop screenshot utility, so real-window visual evidence cannot be captured from this session alone.
- The desktop shell now includes a copyable QA snapshot so smoke context can still be recorded as text when screenshots are unavailable.
## Frontend Conclusion
The current repository is beyond shell-only validation: backend tests, browser build, Redis fixture bootstrapping, and Linux package generation all succeed in this environment. The next frontend validation step should happen in a launchable Tauri desktop session so QA can capture visual evidence for the live bridge workflows.