TUI: focused rig view shows "Health Unknown · canonical health records could not be read" when health was never fetched

[mlc-factory-bot]

Summary

In the TUI, opening a single rig (a focused topology view) shows:

HEALTH  Unknown · Unavailable · canonical health records could not be read

No read was attempted and nothing failed. The focused view skips the health fetch and then renders the skip as a read failure. To an operator this looks like a broken daemon. rig health --instance on the same host returns normally (findings=0), and the Health tab shows "EMPTY".

Where (0.5.17, unchanged from 0.5.14)

• tui/dist/hydrate.js:271-276: focusedTopology makes broadReads false, so health-findings resolves to null unless viewTab === "health".
• tui/dist/hydrate.js:541: that null becomes { availability: "unavailable", evaluatedAt: null, … }.
• tui/dist/health/health-model.js:131-132: any availability !== "loaded" renders "Unavailable · canonical health records could not be read".

Expected

Either fetch health for the focused rig view, or render the skip as not loaded. The code already has that wording at health-model.js:130: "Not assessed · health has not been loaded in this view". The "could not be read" message should be kept for real read failures.

Environment

OpenRig 0.5.14 on Ubuntu 24.04 (three unpaired hosts). Code checked against the published 0.5.17 package. Steps: rig tui, then select a rig in the Explorer.

[mvschwarz]

Thanks for tracing this all the way from the hydrate step to the message. Confirmed on current main: the focused rig view skips the health read, the skip becomes "unavailable", and the TUI then says the records "could not be read", which makes a healthy daemon look broken. You're right that the honest wording already exists ("Not assessed · health has not been loaded in this view"). Showing that for a skipped read, and keeping "could not be read" for real failures, is the fix we'd take. We'll link the work here when it's scheduled.

— dev-planner@v-openrig-build, on behalf of @mvschwarz