Skip to content

Nerthus.Core.Dashboard

Nerthus.Core (until cutover). This page describes the frozen system that runs today and is deleted at cutover. Replaced by: not yet written.

The narrator dashboard: a static single-page app over the daemon's read surface, served from GitLab Pages.

Read at nerthus.core.dashboard 469bdcc (2026-08-25).

The dashboard owns the component's own design - its route and tab tables, the two sign-in token kinds, the module layout. This page is about the repository around it.

What it owns

  • src/ui/destinations.ts - every place the app can be, as one table. One row per destination carries its path, its label, its one-line hint, which tab lights, whether the card strip stands over it and which group it belongs to. Five hand-kept lists used to answer those questions separately; a row cannot disagree with itself.
  • The browser-side crypto under src/crypto/, which opens a moderation record when the tab is holding a member's identity. The daemon holds no key and never will, so this is the only place a sealed record is read.
  • A static TypeScript bundle with no runtime dependencies and no framework, matching the rest of the family.

It never reads the lore repository. Every read goes through the daemon's closed route table, so a behaviour that is not a route in Nerthus.Core cannot be a feature here.

Where its CI runs

node:26-slim, six jobs: lint, format, typecheck, unit, build, pages.

unit clones two other repositories before it runs. It takes nerthus.core at the same branch name, falling back to main, and nerthus.core.infra.common, and it fails loudly when either clone produces nothing. The tests then read the real route table and the real vault inventory rather than a fixture of them, which is what makes a destination naming a route that no longer exists a red pipeline here.

What it pins, and what pins it

Nothing pins the dashboard, and the dashboard pins nothing.

What it carries instead is a build-time address: NERTHUS_API_BASE is baked into the bundle at build, so the deployed app is bound to one daemon origin. pages publishes the default branch and serves both public origins from one deployment.

That baked address is worth knowing, because the failure it produces is silent. A bundle built against a host that later stops resolving loads perfectly and answers nothing, with no message on the screen saying why. That is the state Use the web dashboard warns an operator about today.

What breaks if it stops

Every screen an operator uses, and nothing else. The daemon does not know the dashboard exists, the committed lore is untouched, and the cmdlet client keeps working. Moderation is the sharpest loss: this is the only surface in the estate that can open a sealed record at all.

See also