docs: reconcile alarms-over-gateway banner with audited source #419

2026-05-01T06:34:01-04:00

dohertj2 commented

2026-05-01 06:34:01 -04:00

Summary

The docs/plans/alarms-over-gateway.md banner claimed All 19 PRs merged while the same block warned that worker-side alarm subscription is blocked. An audit of both repos on 2026-05-01 found the banner overstated reality on four merged PRs and asked for an architectural decision that had actually been resolved on 2026-04-30.

What the audit found

Functional end-to-end (verified against source): B.1 / B.2 / B.3 / B.4 / B.5 / C.2 / D.1 script / E.1–E.7.

Merged-but-inert scaffolds (gated on worker AlarmClient wiring):

A.2 — MxAccessAlarmEventSink.Attach is a no-op (mxaccessgw repo).
A.3 / A.4 — MxAccessGatewayService RPC handlers route through NotWiredAlarmRpcDispatcher (Ack returns OK with worker dispatch pending dev-rig wiring diagnostic; Query yields empty stream).
C.1 — SdkAlarmHistorianWriteBackend.WriteBatchAsync returns RetryPlease for every event with a placeholder log; live aahClientManaged SDK call site pinned during D.1 dev-rig smoke.

Architectural decision RESOLVED 2026-04-30 (recorded in mxaccessgw MxAccessAlarmEventSink.cs xmldoc): the worker hosts aaAlarmManagedClient.AlarmClient (x86 net48 — same bitness as the existing MxAccess COM consumer) alongside the COM consumer, sharing the STA + WM_APP message pump. The earlier AVEVA SDK is x64-only concern proved wrong against the deployed assemblies. 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.

Doc-only change

The banner is the only file touched. The plan body and design record are preserved verbatim.

Test plan

Read the new banner top-to-bottom — every claim resolves against the source tree referenced.
Confirm the four inert-scaffold call-outs name files / classes that exist on master in their respective repos.

🤖 Generated with Claude Code

## Summary The `docs/plans/alarms-over-gateway.md` banner claimed *All 19 PRs merged* while the same block warned that worker-side alarm subscription is blocked. An audit of both repos on 2026-05-01 found the banner overstated reality on four merged PRs and asked for an architectural decision that had actually been resolved on 2026-04-30. ## What the audit found **Functional end-to-end (verified against source):** B.1 / B.2 / B.3 / B.4 / B.5 / C.2 / D.1 script / E.1–E.7. **Merged-but-inert scaffolds (gated on worker AlarmClient wiring):** - **A.2** — `MxAccessAlarmEventSink.Attach` is a no-op (`mxaccessgw` repo). - **A.3 / A.4** — `MxAccessGatewayService` RPC handlers route through `NotWiredAlarmRpcDispatcher` (Ack returns OK with *worker dispatch pending dev-rig wiring* diagnostic; Query yields empty stream). - **C.1** — `SdkAlarmHistorianWriteBackend.WriteBatchAsync` returns `RetryPlease` for every event with a placeholder log; live `aahClientManaged` SDK call site pinned during D.1 dev-rig smoke. **Architectural decision RESOLVED 2026-04-30** (recorded in `mxaccessgw` `MxAccessAlarmEventSink.cs` xmldoc): the worker hosts `aaAlarmManagedClient.AlarmClient` (x86 net48 — same bitness as the existing MxAccess COM consumer) alongside the COM consumer, sharing the STA + WM_APP message pump. The earlier *AVEVA SDK is x64-only* concern proved wrong against the deployed assemblies. 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. ## Doc-only change The banner is the only file touched. The plan body and design record are preserved verbatim. ## Test plan - [ ] Read the new banner top-to-bottom — every claim resolves against the source tree referenced. - [ ] Confirm the four inert-scaffold call-outs name files / classes that exist on master in their respective repos. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dohertj2 added 1 commit 2026-05-01 06:34:03 -04:00

docs: reconcile alarms-over-gateway banner with audited source 64d8838e18

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>

dohertj2 referenced this pull request

2026-05-01 06:34:40 -04:00

alarms-over-gateway: wire worker AlarmClient + pin SDK call site (4 inert scaffolds + D.1 smoke) #420

Checking for merge conflicts…

View command line instructions