fix: label the prune merged-scan as scanning and drop danger styling while it runs (#2451) - #2482
Conversation
Opus 4.8 Review — ✅ no blocking findingsReviewed Review detailsThe diff is a small, self-consistent UX change: the button's No findings. [OPUS-REVIEWED] bb3ef8c Verdict parsed from the review's SHA-scoped output markers for commit False positive or not applicable? A repository writer can comment: |
Design Review (Fable 5) — ✅ PASSAdvisory design-level review of Design-Verdict: PASS Real misleading-affordance harm, fixed at the right layer with existing state and the [DESIGN-REVIEWED] bb3ef8c |
UX Review (Fable 5) — ✅ PASSAdvisory UX-level review of UX-Verdict: PASS Busy label now truthfully names the read-only scan; confirmation dialog still guards deletion — the screenshots confirm both states render as claimed. Suggestions
[UX-REVIEWED] bb3ef8c |
GPT 5.6 Review — ✅ no blocking findingsGPT 5.6 completed its review of This comment is updated in place on each push. Review detailsNo findings. False positive or not applicable? A repository writer can comment: |
…while it runs (#2451) While `busy['__prune']` is set, the Prune merged button now renders a dedicated "Scanning for merged…" label (new `pages.devFleetPage.scanning_merged` key, translated into all 12 catalogs) instead of keeping the destructive label under a spinner, and the `danger` variant is suppressed for the scan's whole window — the scan is read-only (`pruneShipped` only builds the candidate list; the review dialog remains the mandatory confirmation step), so the destructive affordance was misleading exactly when a nervous user might reload and throw away the in-flight git+gh walk. Answering the reporter's open question: yes, the danger styling is suppressed during the scan, via the existing `danger` boolean prop on `Btn` (no new prop or variant). The button stays visibly disabled and `aria-busy` is unchanged. Closes #2451
5d221b7 to
bb3ef8c
Compare
…while it runs (kirodotdev#2451) (kirodotdev#2482) While `busy['__prune']` is set, the Prune merged button now renders a dedicated "Scanning for merged…" label (new `pages.devFleetPage.scanning_merged` key, translated into all 12 catalogs) instead of keeping the destructive label under a spinner, and the `danger` variant is suppressed for the scan's whole window — the scan is read-only (`pruneShipped` only builds the candidate list; the review dialog remains the mandatory confirmation step), so the destructive affordance was misleading exactly when a nervous user might reload and throw away the in-flight git+gh walk. Answering the reporter's open question: yes, the danger styling is suppressed during the scan, via the existing `danger` boolean prop on `Btn` (no new prop or variant). The button stays visibly disabled and `aria-busy` is unchanged. Closes kirodotdev#2451
Summary
Fixes the ambiguous affordance on the Dev Fleet Prune merged button: while
busy['__prune']is set the button now says what it is actually doing —"Scanning for merged…" — instead of showing a spinner under the destructive
label, and the
dangerstyling is suppressed for the scan's whole window.Nothing is deleted during that window:
pruneShippedonly builds the candidatelist, and the review dialog's checkboxes remain the mandatory confirmation step.
A spinner on a danger-styled "Prune merged" read as "deletion already running",
which is exactly when a nervous user reloads and throws away the in-flight
git+ghwalk.Answering the issue's open question: yes, the danger styling is suppressed
during the scan. The scan is read-only, so the destructive affordance is
misleading for its entire duration. This uses
Btn's existingdangerbooleanprop (
danger={!busy['__prune']}) — no new prop, no new variant. The buttonstays visibly disabled (
disabled+ the component's disabled opacity) andaria-busyis unchanged for assistive tech.Changes
website/src/pages/DevFleetPage.tsx— label swaps to the newpages.devFleetPage.scanning_mergedkey while the scan runs;dangerbecomesdanger={!busy['__prune']}. No behaviour change topruneShippedor thereview-dialog confirmation flow.
website/src/i18n/locales/en.manual.json— new hand-authored keyscanning_merged: "Scanning for merged…"(ellipsis style matches theneighbouring busy strings
Building…/Loading…).en.jsoniscodemod-generated and correctly untouched.
real translations consistent with each file's existing
prune_mergedandbusy-string wording, inserted in each file's sorted key position.
en-XA.json— regenerated vianpm run i18n:pseudo(not hand-edited).website/src/test/DevFleetPage.test.tsx— the existing in-flight spinner testnow also locks the label swap, the danger suppression during the scan, and the
restoration of both after it resolves.
Screenshots
Idle — destructive affordance on (hovered):
Scanning — read-only label, spinner kept, danger suppressed, visibly disabled:
Full-page context: idle · scanning
Testing
npx tsc -b— cleannpx vitest run— full website suite: 876 files, 11794 passednpm run i18n:check— full chain green (catalog parity, DNT, manifest sync)in-flight button reports
aria-busy=true, labelScanning for merged…, andno
dangerclasses; both states captured in the screenshots above.Closes #2451