419eda256b
RouteScriptedAlarmMethodCalls now handles ConditionType.AddComment alongside Acknowledge/Confirm, dispatching to engine.AddCommentAsync. An empty comment is rejected by the Part 9 state machine and surfaced as BadInvalidArgument. MapCallOperation gates AddComment at the AlarmAcknowledge tier — there is no dedicated AddComment permission bit. Closes phase-7-status.md Gap 1: all Part 9 alarm methods now route to the engine. Adds 3 unit tests. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
52 lines
2.5 KiB
Markdown
52 lines
2.5 KiB
Markdown
# Loose ends
|
||
|
||
State as of 2026-05-18, after the #9–#29 task-list run. Everything on the
|
||
formal task list is shipped except #20; the items below are what genuinely
|
||
remains, plus follow-ups surfaced during the run.
|
||
|
||
## Open task
|
||
|
||
- **#20 — D.1 dev-rig rollout smoke.** A full 3-service deployment
|
||
(gateway + worker + server + Wonderware historian sidecar): deploy the
|
||
refreshed binaries, run `scripts/install/Refresh-Services.ps1`, exercise
|
||
alarms end-to-end, and capture the rollout artifact. The code blockers
|
||
were cleared by #18; the act itself needs the physical AVEVA dev rig and
|
||
cannot be produced from a dev box. Runbook context in
|
||
`docs/plans/alarms-worker-wiring-plan.md`.
|
||
|
||
## Follow-ups surfaced during the run
|
||
|
||
- **C.1 live SDK binding.** `SdkAlarmHistorianWriteBackend.WriteBatchAsync`
|
||
(`src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Historian.Wonderware/Backend/`) is
|
||
still a placeholder returning `RetryPlease` for every event, so queued
|
||
alarm events are retained rather than written. Pinning the real
|
||
`aahClientManaged` alarm-write entry point is rig-gated — pairs with #20.
|
||
|
||
- **~~#24 Shelve-method routing.~~** DONE. Acknowledge / Confirm already
|
||
routed; OneShotShelve / TimedShelve / Unshelve now route via the native
|
||
`AlarmConditionState.OnShelve` / `OnTimedUnshelve` hooks wired in
|
||
`DriverNodeManager.MarkAsAlarmCondition` (scripted alarms get a shelvable
|
||
`ShelvedStateMachine` subtree created before `alarm.Create`). The three
|
||
per-instance shelve method NodeIds are indexed so the Call gate resolves
|
||
them to `OpcUaOperation.AlarmShelve`. `AddComment` also now routes to the
|
||
engine (gated at the `AlarmAcknowledge` tier) — `phase-7-status.md` Gap 1
|
||
is fully closed. Remaining: address-space materialisation of the shelve
|
||
method nodes is best confirmed by a live OPC UA browse (pairs with the
|
||
G6 / D.1 rig steps).
|
||
|
||
- **mxaccessgw alarm epic branch.** The alarm subsystem work (A.2/A.3/A.4
|
||
+ the two production-gap fixes from #18) lives on the mxaccessgw branch
|
||
`docs/alarm-client-wm-app-finding`. It is NOT merged to mxaccessgw's main.
|
||
Whether/when to merge the alarm epic to main is an open release decision.
|
||
|
||
- **#15 operator/lab GA gates.** Two v2 GA gates are manual lab steps, not
|
||
automatable here: the OPC UA CTT (Compliance Test Tool) pass and the
|
||
deployment-checklist signoff. Documented in
|
||
`docs/plans/v2-ga-lab-gates-plan.md`.
|
||
|
||
## Done — for reference
|
||
|
||
The 5 Phase 7 gaps discovered mid-run (#24–#28) were all completed and
|
||
merged; no Phase 7 gaps remain open. Add any new follow-ups above as they
|
||
are spun out.
|