| Filename | Latest commit message | Latest commit date |
|---|---|---|
6f57b1f57c
mara, hyperhive#4079: "agent wanted state is multiple buttons insteaf of a badge with dropdown ... same pattern as agent term badges with dropdowns". The wanted column used to be a toggle badge plus a separate quiet destroy badge, stacking under each other in the narrow column. Replaced both with one WantedMenu badge that opens a Dropdown with the three explicit states (up/offline/destroy) -- the exact badge-triggers-a-dropdown shape the per-agent terminals StatusChips already uses (and swarm-uis own ComponentsPage already demos with sample data), built from the same shared Badge/Dropdown components. "up" still declares straight away with no confirmation; "offline" and "destroy" still go through the existing ConfirmDialog modals unchanged -- only the trigger moved, the confirm behavior for the two directions that already had one is untouched. Explicit dropdown options also fix a real bug the old toggle had: mara also asked "when no state is declared, i want to set it to online" -- the old toggle inferred a target as the opposite of snapshot.running for an undeclared row, so a click on an undeclared-but-running agent silently declared it offline rather than making its actual state explicit. The dropdown just lets "up" be picked directly regardless of any inference, which is what she is asking for -- flagging this reading explicitly in case an actual one-time migration (auto-declaring every currently-undeclared agent up) was intended instead, which this does not do. Added a shared .ui-dropdown-anchor utility class to Dropdown.css -- this is the third near-identical "position: relative wrapper for a badge that opens a Dropdown" (after agents own StatusChips.css and swarm-uis ComponentsPage.css), so a new caller should not reinvent a fourth copy. Left the two existing ones alone rather than migrating them as a drive-by. Verified with a local esbuild build + a throwaway mock /api/agents/status server, screenshotted headlessly: the wanted column now shows exactly one badge per row instead of stacked badges. |
||
| .. | ||
| packages | ||
| .gitignore | ||
| npm-deps-hash | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
hyperhive frontend
npm workspaces project for the hyperhive browser-facing assets:
packages/shared/— shared modules used by both surfaces (terminal pane, Catppuccin palette + body typography).packages/dashboard/— the hive-c0re dashboard SPA.packages/agent/— the per-container web UI (default agent page, stats, screen).
Build
npm install # one-off; uses the checked-in package-lock.json
npm run build # builds every workspace into packages/*/dist/
The Rust binaries serve packages/dashboard/dist/ and
packages/agent/dist/ via tower_http::ServeDir at runtime; the
build derivation is wired up in nix/packages/frontend.nix. Per-agent
additions are layered on top of the default agent dist via the
hyperhive.frontend.extraFiles option in agent.nix.
Why npm + esbuild
- Hermetic: dependencies vendored via the checked-in lockfile;
buildNpmPackagein nix uses it as the source-of-truth so the output is reproducible without network access at build time. - esbuild: vanilla-JS bundler, no framework runtime overhead.
Each workspace's
build.mjsis ~30 lines. - Single-PR migration: see issue #273 for the design proposal and the four-commit shape (npm scaffold → nix derivations → container plumbing → Rust cutover).