From 470465dfbdfed08e8792d7c663b6daee9b9b5c90 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Thu, 12 Nov 2026 14:06:09 -0500 Subject: [PATCH] docs(scadabridge-history): #129 alarm Severity one direction (dd4f1c2a), raw priority kept, MES deploy gate #131 Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi --- .claude/skills/sister-project-history/scadabridge.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.claude/skills/sister-project-history/scadabridge.md b/.claude/skills/sister-project-history/scadabridge.md index d34ed8c..da9e372 100644 --- a/.claude/skills/sister-project-history/scadabridge.md +++ b/.claude/skills/sister-project-history/scadabridge.md @@ -5,3 +5,5 @@ - **2026-10-13 #36 runtime regression proof refreshed.** Rebuilt HandshakeResetEchoTests passed all three cases with local fakes, terminal exit0; an earlier no-build attempt matched no tests and is excluded from evidence. Tracker now distinguishes implemented runtime b623fdb0 from remaining QA/prod database-owned script rollout (deployment register row119, scripts13/14/36 and15/16/25/26/37/38). No database writes, deployments or fresh live rig claims. - **2026-11-11 deployed `424db155` to wonder-app-vd03 (DEV)** (was `0e540291`). Owner-approved WinRM deploy. Migrations 58→64 (`AddNativeAlarmSourceMesReportable`, `PrefixSearchIndexes`, `AddAuditLogHashChain`, `AddConfigGraphRowVersions`, `FlipAuditLogClusteredKey`, `AuditMaintenanceGrants`) applied by script with central + site stopped; #111 DEV sizing: 2,394 rows / 8 MB flip in ~1.5 s. **The plain `dotnet ef migrations script --idempotent` output fails (Msg 207 `ChainSeq`: column added and indexed in one batch)** — the deployed script adds `GO` per guarded block + `XACT_ABORT`; forward/rollback rehearsed on a restored copy of the vd03 DB. Downtime ~50 s; verify OK. Backup `ScadaBridge-backups\ScadaBridge_pre-424db155_20261111T164219.bak`. QA not deployed. + +- **2026-11-12 #129 alarm Severity runs one direction (higher = more urgent), main `dd4f1c2a`.** MxGateway native alarms and computed `PriorityLevel` now band AVEVA-style priority onto `AlarmConditionState.Severity` with OtOpcUa's `GalaxyAlarmPriority` table (lmxopcua#887): 1–250→1000, 251–500→750, 501–750→500, 751–999→250, ≤0→1000, >999→250 (`AlarmPriorityBands`). OPC UA rows are unchanged. The raw number (= pre-#129 Severity) is kept on new `AlarmConditionState.Priority`, `ScriptAlarm.Priority` and `AlarmStateChanged.Priority`. There is no proto change: central derives Severity from the wire `priority` by kind, and pre-#129 `native_alarm_state` rows are upgraded on rehydrate. The native MES 900–999 band and the MES API `Severity`/`MinSeverity`/`MaxSeverity` key off `Priority`, so they select the same alarms as before. The rig seed scripts were switched; **deployed MES scripts (CvdReactor, vd03 SBTEST01/02) must switch `a.Severity`→`a.Priority` in the same deploy: deploy gate ScadaBridge#131.** **Visible flip:** Alarm Summary worst/filter/sort and the Sev column now rank AVEVA priority 1 highest. A computed raise logs `Error` at priority 1–500 (was raw ≥700). Tests (Release): Commons 977, DCL 549, Communication 834, SiteRuntime 1055, CentralUI 1545, all green; a mutation revert turned 62 red. Not deployed.