docs(master-plan): WS-F#2 — uninstall progress bar made truthful (9f17ba68)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
archipelago 2026-06-26 06:15:11 -04:00
parent 9f17ba6867
commit 80146f4476

View File

@ -181,6 +181,13 @@ no-regression; the original hang was load/timing-induced and not separately repr
2. **Progress-UI assertions:** install AND uninstall must report monotonic, truthful progress
(not a stuck full-red bar); a long op must surface a real stage/percentage and a terminal
success/failure — no silent hang. (Likely both a backend progress-event fix AND a UI fix.)
*(✅ 2026-06-26 `9f17ba68`: the "stuck full-red bar" was `AppCard.vue` hardcoding the uninstall
bar to `w-full bg-red-400/60 animate-pulse` — solid, full, red, fake-pulse. Now derives a real
percentage from the backend's existing `uninstall-stage` label ("Stopping containers (X/N)"→1050%,
"Cleaning up volumes"→70%, "Removing app data"→90%) and renders like install (neutral fill, real
width+%, shimmer). FE built `index-DtZyZomC.js`, rolled to .228/.116/.198/.89 (+.88/.5/.120).
STILL TODO: a bats/UI assertion that the bar is monotonic + lands on a terminal state; possibly a
backend numeric-progress field so the UI doesn't parse stage strings.)*
3. **ALL-apps coverage:** a generic per-app lifecycle matrix (install / UI-reach / stop / start /
restart / uninstall / reinstall / reboot-survive) driven by the manifest set, so grafana and
the ~30 uncovered apps are gated too — not just the 8 core. Manifest-driven, so new apps are