feat(core-status): multi-select cores, bulk update to a named build - #446
Merged
Conversation
The Core Status panel could send a named test build to exactly one core: the only entry point was the row context menu, and every bulk path (the server-row arrow, the footer buttons) was hard-wired to the release build. Updating a fleet to a tester build meant one right-click per core. Rows now carry a CoreId-keyed selection in both presentations (plain click, Ctrl toggle, Shift range, Ctrl+A over the visible rows, Escape), built on the controlled-selection algorithm the Report panel already used, lifted into controls/row_selection.rs with Report repointed at it. The row menu acts on the selection when the clicked row belongs to it and names the count it will enqueue; the same menu opens on a server row and on a Flat exchange heading. The footer gains a "to a build..." button whose build-name field lives inside the existing single confirm. Behaviour change: the footer buttons act on the cores the panel shows (or the selection when one exists), no longer on the whole fleet. A panel scoped to one group used to offer a button reaching every core. Scope resolution is a pure function (controls/core_update/scope.rs) with mutation-proven tests; a static contract pins every Core Status enqueue to the shared controls::core_update route. Claude-Session: https://claude.ai/code/session_018e8iwJ8ejRvnev4XkscuHs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The Core Status panel could send a named test build to exactly one core: the only entry point was the row context menu, and every bulk path (server-row arrow, footer buttons) was hard-wired to the release build. Updating a fleet to a tester build meant one right-click per core.
CoreId-keyed selection in both presentations (plain click, Ctrl toggle, Shift range, Ctrl+A over the visible rows, Escape). The click algorithm is the one Report already used, lifted intocontrols/row_selection.rs; Report is repointed at it with its tests untouched.controls/core_update/scope.rs) with mutation-proven tests; a static contract pins every Core Status enqueue to the sharedcontrols::core_updateroute.How to verify
Ctrl/Shift-click and Ctrl+A in both Core Status views; right-click a selected row (count in the menu) vs an unselected one (single core, selection unchanged); right-click a server row / exchange heading; footer "Update all" relabels to "Update selected (N)" while a selection exists.
cargo test -p moon-ui-gpuigreen (1804 tests).https://claude.ai/code/session_018e8iwJ8ejRvnev4XkscuHs