Connection 2 / template 27 / instance 16 on site-a, bound to the OtOpcUa script-runner
canaries; serviceLevelFailover at its defaults. Under Warm the connection moved off the
Standby by ServiceLevel (connect-time preference, 0.1 s) and on the booting Standby (50);
a graceful Primary stop still took the connectivity path (66 s, #141). Kept as monitor.
Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi
Pair window per pack 8ffa6394: COPY_ONLY backup + VERIFYONLY, stop both pairs,
idempotent EF script 58->64 from the Mac (flip in ~2 s), swap, centrals then
sites started together. Site data path ~2 min 6 s, central API ~58 s.
leader-auto-down started on all 4 nodes; no #116 drills; hash chain off;
recovery flag TRUE on all 4 (actions kept). Env digest-identical; only the
strategy key changed in appsettings; per-node JWT/idle values preserved.
Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi
No migration (64). ~45 s site outage. SCM non-crash recovery flag set for exit 75 (#132).
#131: SBTEST01/02 AlarmStatus on ScriptAlarm.Priority, verify 13/13 before and after.
Hash chain: SourceNode backfill 843 rows, Enabled=true (ChainBacklog unset, head export off),
one anchor at 2026-11-13T12:16:53Z, 0 pre-cutoff rows chained, verify-chain 2026-11 Intact.
Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi
vd03 is the DEV box (vd = DEV, vq03/vq04 = QA). Historical docs called it prod/production.
Only vd03-referential uses are changed; generic 'production' wording (production HOCON,
production code paths, ASPNETCORE_ENVIRONMENT=Production, real-world production guidance)
is unchanged. One verbatim git commit message quoted in PLAN-07 is left as recorded.
Second vd03 window of the day: no migrations, appsettings.Site.json gains ScriptFileAccess:AllowedRoots
(pushed over SMB before the swap), sample recipes in E:\ApiInstall\ScadaBridge\recipes. The Delmia
test receiver now reads + parses the downloaded file; real HTTP R100 -> 12 values loaded, R900 -> rejected
with line numbers. verify-mes-test-machine.sh: D1's cleared check reads through BTDB, so it only runs
with group C (the rig runs VERIFY_GROUPS=AD).
vd03 (DEV) upgraded 2b9a7c3c -> fe89363b via the deployment-only winrm channel: COPY_ONLY backup,
55->57 delta script (AddAlarmMesReportable, AddSiteArtifactRevision), ~53 s window, snapshots
identical to baseline, artifacts deployed. Register row 126 now covers the QA pair only.
docker/seed-mes-test-machine.sh (idempotent) builds a standalone TestMesMachine base template -
Left/Right TestMESReceiver + TestDelmiaReceiver (prod attribute names, STATIC), computed alarms
with IsMesReportable, CvdReactor-compatible MesMoveIn/MesMoveOut/ProcessRecipeDownload/AlarmStatus
scripts ported to SetAsync+WaitAsync, and Galaxy-side simulators with reject/no-response knobs -
plus instances SBTEST01/02 and the SimpleAlarmStatusRequest (was a stub) / AlarmStatusRequest
inbound methods in the legacy /mes/(simple)alarmstatus shapes, resolving machines through BTDB.
BTDB rows SBTEST01=990001 / SBTEST02=990002 added on vd03.
docker/verify-mes-test-machine.sh drives the real inbound methods via flow-debug: PASS 25/25.
Both driven from the Mac over the winrm CLI (WinRM 5985 + SMB 445, no helper
on the boxes). Migration 53->55; the first Central boot encrypts
DataConnections.PrimaryConfiguration (dp:protocol:v1:), so rollback is the
COPY_ONLY DB restore, not a binary swap. QA: all four nodes stopped together,
one shared-DB migration, 2 min 35 s window, preflight against a restored clone.
Claude-Session: https://claude.ai/code/session_01RgthVLVU5CJ8SUuEwruTkt
Joseph Doherty