b6cbe5a47e
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>
69 lines
5.0 KiB
Markdown
69 lines
5.0 KiB
Markdown
# 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.
|