The 'All 19 PRs merged' banner contradicted the warning paragraph in
the same block and overstated reality against the source tree. Audit
of the lmxopcua + mxaccessgw repos on 2026-05-01 found:
- 17 of 19 PRs merged. Four merged PRs ship inert scaffolds:
- A.2: MxAccessAlarmEventSink.Attach is a no-op.
- A.3 / A.4: NotWiredAlarmRpcDispatcher returns OK-with-diagnostic
for AcknowledgeAlarm and an empty stream for QueryActiveAlarms.
- C.1: SdkAlarmHistorianWriteBackend.WriteBatchAsync returns
RetryPlease for every event with a placeholder log.
- The architectural decision the warning paragraph asks the operator
to make was already resolved 2026-04-30. MxAccessAlarmEventSink.cs
in mxaccessgw records that aaAlarmManagedClient.AlarmClient is x86
net48 (same bitness as the worker), and pins the discovered API
surface (RegisterConsumer / Subscribe / GetStatistics /
GetAlarmExtendedRec / AlarmAckByGUID). What remains is wiring PRs
in the worker, not architectural choice.
- D.1 smoke artifact (docs/plans/artifacts/d1-rollout-YYYY-MM-DD.md)
not yet captured; directory does not exist.
Banner rewritten to split functional-end-to-end vs merged-but-inert
PRs explicitly so future readers don't have to reconcile the doc
against the source tree themselves.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the "ships as a follow-up gated on dev-rig validation"
banner with the actual finding from the dev-rig inspection: the
MXAccess COM Toolkit on this AVEVA install does not expose any
alarm-event family, and the AVEVA alarm-subscription managed
assemblies (aaAlarmManagedClient, ArchestrAAlarmsAndEvents.SDK)
are x64-only and incompatible with the worker's x86 bitness.
Two operator-facing paths forward documented inline:
1. Stay on the value-driven sub-attribute path (current production
behaviour). Operator-comment fidelity is the only v1 regression.
2. Add an x64 alarm-helper sub-process alongside the worker that
loads aaAlarmManagedClient and forwards transitions over a
named-pipe IPC. Recovers full v1 fidelity but adds operational
complexity.
The full architectural notes live in the mxaccessgw repo at
src/MxGateway.Worker/MxAccess/MxAccessAlarmEventSink.cs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sixteenth PR of the alarms-over-gateway epic
(docs/plans/alarms-over-gateway.md). Closes the documentation sweep
the plan calls for.
- docs/AlarmTracking.md — promoted top-level v2-final architecture
doc (was a worktree-only draft pre-epic). Covers the three alarm
sources (Galaxy MxAccess driver-native / Galaxy sub-attribute
fallback / scripted alarms), how they converge on
AlarmConditionService, the Acknowledge routing decision in
DriverNodeManager (driver-native preferred over IWritable
sub-attribute fallback), the sidecar historian write-back path
for non-Galaxy producers, and cross-references to the plan +
v1 archive.
- docs/v1/AlarmTracking.md — banner pointing readers at the v2
doc; preserved as historical record.
- docs/drivers/Galaxy.md — capability list updated to include
IAlarmSource (now eight capabilities, restored by B.2). Replaced
the "IAlarmSource retired in 7.2" sentence with the restoration
note + cross-link to docs/AlarmTracking.md.
- docs/plans/alarms-over-gateway.md — completion banner at the
top of the plan, marking 14 of 16 PRs shipped 2026-04-30 and
noting that A.2 + A.4 + D.1 are the hardware-gated follow-up.
Memory entries updated separately:
- project_alarms_over_gateway_epic.md (new) — epic summary +
per-PR digest.
- project_galaxy_via_mxgateway.md — added "Alarms restored"
bullet pointing at the new architecture.
- project_server_history_alarm_subsystems.md — bullet 2 updated
to describe the new ack-routing decision (B.3) + bullet 3
added describing the historian write-back path that B.4 + C.1
+ C.2 light up.
- MEMORY.md index — new pointer entry.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cover both client surfaces that become user-visible when the alarm
path lights up:
- mxaccessgw client SDKs in 5 languages (.NET, Python, Go, Java,
Rust). E.1 regens proto across all of them; E.2-E.6 add per-language
alarms helpers (subscribe / acknowledge / query-active) plus matching
CLI verbs.
- lmxopcua OPC UA-facing clients (Client.CLI, Client.UI). E.7 extends
AlarmEventArgs with the new optional fields, surfaces them in the
CLI's --verbose / --json output and the UI's Show-details toggle,
and updates ClientRequirements + Client.{CLI,UI}.md.
Sequencing: E.1 first (mechanical regen), then E.2-E.7 in parallel.
E.2 (.NET) is on the critical path because lmxopcua consumes it; the
other-language SDKs can ship asynchronously without gating D.1.
12 PRs grew to 19 total: 4 in A, 5 in B, 2 in C, 7 in E, 1 in D.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After A/B/C all merge, the running services on C:\publish need to be
refreshed before the Galaxy alarm-event family flows end-to-end. Add
PR D.1: a Refresh-Services.ps1 script + runbook for stopping in
reverse-dependency order, restaging binaries from the build outputs,
restarting in forward-dependency order, and capturing a smoke-run
artifact.
D.1 gates B.5 (docs sweep) — the documentation records the
as-deployed shape, so the deployment has to be live first.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Revise the alarms-over-gateway plan based on review feedback:
The gateway is for MxAccess (live data + Galaxy hierarchy); the
Wonderware historian sidecar is for aahClientManaged (time-series +
alarms historian). Two SDKs, two concerns. Routing alarm-historian
write-back through the gateway would force coupling that doesn't need
to exist — the sidecar already has a dormant WriteAlarmEvents IPC slot
ready to wire.
Drop A.5 (gateway WriteHistorianEvent RPC). Add Track C — two PRs in
the historian sidecar that complete the dormant slot:
C.1 AahClientManagedAlarmEventWriter implementation
C.2 Program.cs wires the writer into HistorianFrameHandler
B.4 reverses from "delete the IPC slot" to "consume the IPC slot" via
a new SidecarAlarmHistorianWriter on the lmxopcua side.
Also tightens Why-section #3 + D5 to make explicit that the path is
exclusively for non-Galaxy alarm producers (scripted alarms today, AB
CIP ALMD or others future). Galaxy-native alarms reach AVEVA Historian
via System Platform's own HistorizeToAveva toggle, independent of
anything in our stack.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Coordinated cross-repo epic to restore the three v1 alarm capabilities
that PR 7.2 regressed: rich MxAccess alarm-event metadata, native
Acknowledge semantics, and the IAlarmHistorianWriter write-back path.
Architectural split: gateway owns MxAccess transport (new
OnAlarmTransition event family + AcknowledgeAlarm / QueryActiveAlarms /
WriteHistorianEvent RPCs); lmxopcua keeps the OPC UA Part 9 state
machine, ACL/role enforcement, and multi-source aggregation. The
existing value-driven sub-attribute path stays as fallback.
10 PRs total — 5 in mxaccessgw, 5 in lmxopcua — sequenced so each
side's work is independently reviewable. End-of-epic gate is a parity
matrix run with five new alarm scenarios.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
