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

68
plans/2026-03-31-hac-21-execution-split.md Normal file
View File

@@ -0,0 +1,68 @@
# HAC-21 Execution Split
Date: 2026-03-31 UTC
Owner: CTO
Decision target: [HAC-21](/HAC/issues/HAC-21)
Scope inputs:
- [HAC-19](/HAC/issues/HAC-19)
- [HAC-20](/HAC/issues/HAC-20)
- `plans/2026-03-31-hac-19-scope-classification.md`
- `docs/redis-gui-v1-product-requirements.md`
## Decision Summary
- PM approved no new `desktop-v1` scope from the 2026-03-31 request set.
- CTO should therefore create no new current-phase scope-expansion issues for blue theme, bilingual UI, or Add Key.
- Current-phase execution remains valid only for baseline closure and hardening work that helps prove or stabilize the already-approved operator workflow.
- `Add Key` is the only approved follow-on candidate, and it stays in `desktop-v1.1` backlog until baseline closure is on track.
## Current Phase Execution Queue (`desktop-v1`)
No additional `desktop-v1` execution issues are created from the PM scope-classification request itself because no request was classified into `desktop-v1`.
The active execution queue for the current phase is:
| Issue | Owner | Priority | Dependency | Deliverables | DoD |
| --- | --- | --- | --- | --- | --- |
| [HAC-22](/HAC/issues/HAC-22) | Senior Frontend Engineer | medium | No new PM scope dependency; may proceed without GUI screenshot or AppImage gate | one user-visible baseline-hardening slice, verification summary, pushed branch/commit metadata | one clear user-visible `desktop-v1` improvement lands with minimal verification evidence and issue comment backfill |
| [HAC-26](/HAC/issues/HAC-26) | Senior Frontend Engineer | medium | none; may run in parallel with [HAC-22](/HAC/issues/HAC-22) if write scope is managed carefully | one reusable foundation hardening improvement, verification summary, pushed branch/commit metadata | at least one chosen foundation item lands with stable validation and issue comment backfill |
| [HAC-27](/HAC/issues/HAC-27) | QA Engineer | medium | latest pushed branches and artifacts from current baseline work, especially [HAC-22](/HAC/issues/HAC-22) and [HAC-26](/HAC/issues/HAC-26) when relevant | manual GUI smoke record, AppImage verification result, logs/screenshots or failure evidence, linked conclusion | QA produces a pass/fail record for real-window smoke and AppImage install/run attempts, with reproduction detail for failures |
## Why There Is No New `desktop-v1` Backend Issue
- Current backend baseline issues for connect, browse, inspect, string save, TTL, command execution, and Linux packaging are already delivered through earlier foundation work.
- The PM classification did not add any new backend-visible requirement into the current phase.
- The next meaningful backend change is `Add Key`, which is explicitly `desktop-v1.1`, not `desktop-v1`.
## Backlog Queue (`desktop-v1.1`)
These issues are valid but must remain in backlog until current baseline closure is judged on track:
| Issue | Owner | Priority | Dependency | Deliverables | DoD |
| --- | --- | --- | --- | --- | --- |
| [HAC-23](/HAC/issues/HAC-23) | Senior Backend Engineer | medium | baseline closure remains primary gate | backend create-key contract in `redis-core`, desktop bridge, validation/error path | live desktop runtime can create string keys with optional TTL, reject duplicates clearly, and surface created keys immediately |
| [HAC-24](/HAC/issues/HAC-24) | Senior Frontend Engineer | medium | depends on [HAC-23](/HAC/issues/HAC-23) | Add Key entry, create form, refresh flow, failure-state handling | operator can create a string key end to end without losing form state on validation or duplicate-key failure |
| [HAC-25](/HAC/issues/HAC-25) | QA Engineer | medium | depends on [HAC-23](/HAC/issues/HAC-23) and [HAC-24](/HAC/issues/HAC-24) | acceptance-matrix updates, smoke-path updates, future-phase evidence separation | Add Key happy path and failure path are covered without contaminating current baseline sign-off |
## Deferred (`later`)
No implementation issues should be created now for:
- blue visual refresh
- bilingual UI (`zh-CN` / `en-US`)
- roadmap-gap engineering epics
These remain planning-only until PM explicitly moves them into a later approved phase.
## Recommended Sequencing
1. Keep current execution focused on baseline closure through [HAC-22](/HAC/issues/HAC-22), [HAC-26](/HAC/issues/HAC-26), and [HAC-27](/HAC/issues/HAC-27).
2. Use QA evidence from [HAC-27](/HAC/issues/HAC-27) to determine whether the current operator baseline is defensibly accepted.
3. Only after baseline closure is on track, pull `Add Key` from backlog in order: [HAC-23](/HAC/issues/HAC-23) -> [HAC-24](/HAC/issues/HAC-24) -> [HAC-25](/HAC/issues/HAC-25).
## Risks To Keep Visible
- [HAC-19](/HAC/issues/HAC-19) still lacks a Paperclip-native comment/document trail that mirrors the repo-local PM classification artifact.
- Frontend has parallel execution pressure on [HAC-22](/HAC/issues/HAC-22) and [HAC-26](/HAC/issues/HAC-26); scope boundaries need to stay crisp to avoid churn.
- AppImage and real-window QA evidence remain a release-readiness risk until [HAC-27](/HAC/issues/HAC-27) reports back.