.nornir/status-board-design.md · nordisk/dwarves

status board pane — design

Class: design · Function axis: f0 the Status board pane (the whole) · f1 the run-history fixture · f2 the per-pipeline badge resolution (reuse) · f3 the chip render · f4 the select→SVG seam Strict: this file states only what the Status board IS — its parts and why. Sibling how-to: status-board-guide.md; zero-knowledge walkthrough: status-board-for-idiots.md. The badge primitive itself: status-badge-design.md.

The Status board is the forge's health wall: one status badge per pipeline (green/amber/red/grey), the egui UI surface of the dwarves badge verb. It is the dwarves-gui tab that closes the L4 robot-tested-UI obligation for the badge surface built in status-badge-design.md.

The system as one — the function map (f0)

part	lives in	what it is
`f1` fixture	`dwarves-gui/src/status.rs`	a `Vec<PipelineRunRow>` run history (no backend/network/fs)
`f2` resolution	`dwarves-gui/src/status.rs` `board()`	each pipeline → its latest status via the SHARED [`badge::latest_status`]
`f3` chip render	`dwarves-gui/src/status.rs` `ui()`	a colour-filled status chip per row; fill = [`badge::color_for`], word = [`badge::status_text`]
`f4` select seam	`dwarves-gui/src/status.rs` `update_json`/`state_json`	`{"select":"<pipeline>"}` expands that pipeline's wire-identical [`badge::svg`]

Why it is shaped this way

A pure consumer of brokkr::badge (Law #1). The pane owns NO badge logic. It calls badge::latest_status for each row's status, badge::color_for / badge::status_text for the chip's colour + word, and badge::svg for the expanded artifact — the exact functions the dwarves badge CLI and the Badge RPC use. So the on-screen board, a dwarves badge render, and a README <img> all agree byte-for-byte. egui only draws the chip; it makes no colour or status decision.
The board proves "latest wins." The fixture runs the history pipeline twice — an older green then a newer red — so the board asserting history == failing is a red-when-broken check that the shared selector picks the newest matching run, not the first. bench (running→amber) and an unknown-pipe (no run→grey found=false) likewise pin the enhanced colour map through the UI path.
Driven over the same JSON seam as every dwarves pane. state_json ({kind,count,green_count,badges[],selected,selected_svg}) out, update_json ({"select":…}) in — the identical remote-control channel nornir-robotui and the other panes use, so the robot scenario drives it headless with no pixels.
Additive. A new 7th tab in the native shell; no existing pane touched. Native-only (the pane consumes dwarves::brokkr::badge, and dwarves is a native-only dep of the demo — the wasm web demo keeps its single Forge panel, exactly like Pipeline/Forge(live)/Jobs).

Place in the nordisk constellation

This is a dwarves-owned pane (the CI/CD forge health surface). It mirrors the constellation's pane convention: a self-contained Facet/Panel fed a fixture, robot- tested over state_json/update_json. When the shell is promoted onto live server data (parity P5), the board swaps its fixture for the Badge/History RPCs behind the same state_json shape — no viewer change.

Deferred

No egui_kittest PIXEL leg. Like every dwarves pane, the board is driven headless over the JSON seam (the matrix side of wire-once); a real egui_kittest::Harness click
- robotui watch on DISPLAY:0 for the whole tabbed shell is the standing follow-up flagged since the funnel/pipeline rows.
Fixture, not live. The board reads a built-in run history, not a live dwarves-server. The live repoint (over the Badge/History RPCs) rides the same state_json shape when the shell is promoted to the real UI.
Chip, not rasterised SVG. The on-screen pill is a native egui chip (colour+word from the shared module); the exact SVG is shown as copyable text on select, not rasterised in-canvas (no resvg/egui_extras pull — that would twin a rasteriser).