| Filename | Latest commit message | Latest commit date |
|---|---|---|
45710ab739
hyperhive#2822/PR#3026 moved swarm.js's per-agent in-flight status off the rebuild queue. Two other reads of the same rebuild_queue field survived that PR by design (a different feature, atlas flagged it on #2985) and are the last DagView/NodeView consumers on the frontend: queuedOpsByAgent()'s pending-row fallback and the SW4RM queue-summary banner. Both now read GET /api/jobq/graph (hive-jobq-wire's generic GraphNode shape) instead, matching the pattern builds.js already established for <hive-jobq-graph>. Along the way: DagView no longer carries state/kind fields (removed in an earlier refactor that pushed roll-up derivation client-side), so both migrated functions were silently reading undefined fields and had become permanent no-ops — the pending-badge fallback never lit and the queue-summary banner never rendered. This restores real behavior rather than porting broken logic forward. The queue-summary banner's node-count-vs-group-count question (flagged on hyperhive#3028 as needing a decision) resolves cleanly: a GraphNode group root (parent: null) is an ordinary node whose own state already IS the group's roll-up per hive-jobq-wire's contract, so counting roots by state is a direct filter, not a parent-chain walk or a client-side rollup calculation. Verified the derivation logic against constructed GraphNode fixtures (multi-step chains, settled history that must not count, Finishing roots, multi-agent single-DAG groups) before wiring it in — 13/13 checks passed. docs/web-ui/dashboard.md's Container-row + BU1LDS sections updated to match. |
||
| .. | ||
| packages | ||
| .gitignore | ||
| 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/modules/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).