redis-gui-foundation/plans/2026-03-31-hac-21-execution-split.md

HAC-21 Execution Split

Date: 2026-03-31 UTC Owner: CTO Decision target: HAC-21 Scope inputs:

• HAC-19
• 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	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	Senior Frontend Engineer	medium	none; may run in parallel with 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	QA Engineer	medium	latest pushed branches and artifacts from current baseline work, especially HAC-22 and 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	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	Senior Frontend Engineer	medium	depends on 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	QA Engineer	medium	depends on HAC-23 and 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-26, and HAC-27.
2. Use QA evidence from 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-24 -> HAC-25.

Risks To Keep Visible

• 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 and 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 reports back.