9975be9c08
#375 captured `wasNearBottom` BEFORE the row's initial append so the autoscroll wouldn't be tricked by the new row's own height. That's still right, but it leaves a second gap: renderers commonly call `api.row(cls, text)` to build the shell, then mutate the returned element by appending more children (badges, multi-line turn bodies, tool-result panes). The initial scrollTop assignment in afterAppend only sees the row's INITIAL height — once the renderer adds the body, the row's grown past the visible bottom and the operator's stranded scrolled to the row's TOP, breaking stick-to-bottom for every subsequent event. Mara's symptom: two lines of text appear, the view scrolls only one row, the terminal isn't at the bottom anymore, and the next event doesn't auto-scroll because `isNearBottom()` now returns false. Fix: add a `stickToBottom` boolean (updated synchronously from the scroll event handler) + a MutationObserver on the log subtree (`childList`, `subtree`, `characterData`). On any mutation, if stickToBottom is true, re-snap to bottom. MutationObserver batches mutations into one microtask callback per synchronous block, so it runs once per renderer call regardless of how many children the renderer appends after `api.row` returned. Programmatic `scrollTop = scrollHeight` doesn't trigger MO (the scroll isn't a DOM mutation), so no feedback loop. Operator scrolling up still flips stickToBottom to false via the existing scroll handler — MO becomes a no-op until they scroll back. Same shared `@hive/shared/terminal.js` powers the dashboard's flow page + per-agent terminal, so both pages inherit the fix. |
||
|---|---|---|
| .. | ||
| 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).