After running the matrix end-to-end against the live rig for the
first time, three of the nine failures were false positives — bugs in
the harness and test invariants, not real backend deltas:
1. ParityHarness configured the legacy backend with
OTOPCUA_GALAXY_BACKEND=db, which is Discover-only. Reads, writes,
and reinits all returned "MXAccess code lift pending — DB-backed
backend covers Discover only". Switched to mxaccess backend; the
ZB connection string still drives the discovery path.
2. HistoryReadParityTests asserted "neither backend implements
IHistoryProvider" — but the legacy GalaxyProxyDriver still does
(it's an accepted back-compat delta retired in PR 7.2). The
architectural pin we *want* is "the new path doesn't regress to
per-driver history", so the test now asserts only the mxgw side.
3. AlarmTransitionParityTests strict-pinned the five sub-attribute
refs (InAlarmRef, etc.) on the legacy condition. PR 2.1 added
those refs specifically so the new mxgw driver could populate them
via AlarmRefBuilder; legacy pre-dates PR 2.1 and leaves them null
— that's correct, not a regression. Test now asserts a one-way
invariant: when legacy populated a ref, mxgw must match. When
legacy is null, mxgw is free to populate (the mxgw → server-side
AlarmConditionService direction).
The six remaining failures are real:
- 2 from the gw-side `[]` array suffix (filed in
mxaccessgw/requirements-array-suffix-fix.md)
- 2 write-StatusCode mapping deltas (0x80050000 vs 0x80020000) —
Bad-status both ways but mapped to different OPC UA codes
- 1 event-rate ratio of 5x (mxgw dispatches 5x legacy in the same
3s window)
- (Plus the 2 ScanState scenarios that skip cleanly — single-platform
rig as documented)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5e890ec9d6