scadaproj/ZB.MOM.WW.Overview/CLAUDE.md

ZB.MOM.WW.Overview

The hosted family dashboard (Blazor Server). Build/test from this directory: dotnet build ZB.MOM.WW.Overview.slnx, dotnet test ZB.MOM.WW.Overview.slnx (fully offline).

Index history (migrated from the scadaproj root CLAUDE.md)

Moved verbatim out of the scadaproj root CLAUDE.md on 2026-09-03 so it loads only when needed. This file is now the authoritative place for this history — append new entries here and keep the root index row short.

Besides the shared libraries, this repo hosts one application: ZB.MOM.WW.Overview/ — a Blazor Server single-pane dashboard that polls every registered instance's anonymous /health/ready + /health/active, caches one snapshot (pages never poll) and renders per-cluster state including the Akka leader chip, which is what the ZB.MOM.WW.Health 0.2.0/0.3.0 per-entry data work exists to feed. No login, strictly read-only, holds no credentials — a requirement, not an omission; it references no Auth/Audit/ Secrets package. Design + impl plan: docs/plans/2026-07-22-overview-dashboard-{design,impl-plan}.md (ledger 19/20; the open task is Phase 4 live acceptance, recorded in 41013dc as 7 of 9 design §9 checks passing, 2 blocked on an OtOpcUa rig redeploy).

The Applications registry ships empty on purpose: a deployment supplying none fails startup naming the key rather than booting an empty dashboard. Per-deployment overlays are committed — appsettings.Docker.json (the local rigs, joined via external networks) and appsettings.Wonder.json.

Deployed to wonder-app-vd03 2026-08-11 (main @ 4f97e72) as that box's fifth app: service ZbOverview on :5320 under the shared NSSM, ASPNETCORE_ENVIRONMENT=Wonder, 5/5 instances Up. Two constraints worth carrying to any future box:

• Publish self-contained (-r win-x64 --self-contained true). wonder has no .NET 10 runtime — every app there carries its own. An FDD publish installs fine and then fails at service start.
• Registry BaseUrl must not put co-located instances on a shared host name. Leader-address → instance resolution matches on host only (Akka and HTTP ports differ by design), which assumes distinct hosts per instance — true on the rig, false on a single box, where the fleet-wide scan lets the first matching entry win the chip for every group. On wonder that made ScadaBridge's site card claim Leader · central, a different Akka cluster. Fixed by using 127.0.0.1, which matches nothing, so each chip falls back to the raw Akka address.

QA runs an instance on EACH pair node — wonder-app-vq03:5320 and (since 2026-08-14) wonder-app-vq04:5320 — both watching the same registry, now 10 instances across 4 applications after the 2026-08-14 VQ04 singleton clone (MxGateway + HistorianGateway added on vq04; see deployment.md §7.1). It is the fastest way to read QA's whole topology. Its registry uses real FQDNs, and that is correct rather than a divergence: the 127.0.0.1 rule above exists only because VD03 co-locates every instance on one host. QA is a 2-node pair (vq03/vq04) with genuinely distinct hosts, so leader resolution works as designed and the chips resolve to real names (node-a (vq03)). Carry the reason, not the literal 127.0.0.1.

Commands (from the index)

# ZB.MOM.WW.Overview  (~/Desktop/scadaproj/ZB.MOM.WW.Overview — the hosted family dashboard)
dotnet build ZB.MOM.WW.Overview.slnx
dotnet test  ZB.MOM.WW.Overview.slnx      # 177 tests, fully offline
cd docker && docker compose up -d --build # local rigs → http://localhost:5320 (start the rigs first)
# wonder deploy artifact — SELF-CONTAINED, the box has no .NET 10 runtime:
dotnet publish src/ZB.MOM.WW.Overview/ZB.MOM.WW.Overview.csproj -c Release -r win-x64 --self-contained true -o <out>