The original hand-curated table was wrong starting at id 74 — entries had been deduplicated/renumbered without preserving the canonical `id = 2 * StringN` mapping from `[MC-NBFS]` §2.2, leaving most of the SOAP-fault subset at the wrong ids: ours had Fault at 114, canonical is 134 ours had Code at 122, canonical is 142 ours had Reason at 124, canonical is 144 ours had Text at 126, canonical is 146 ours had Value at 134, canonical is 154 ours had Subcode at 136, canonical is 156 Wire captures from the live AVEVA MxDataProvider use the canonical ids — verified earlier via `MX_ASB_TRACE_REPLY` showing `<resultCodeField>` correctly resolved through the F30 post-pass once the ids matched. Replaced the entire STATIC_ENTRIES array with a faithful port of the first 200 entries from `dotnet/wcf`'s `src/System.ServiceModel.Primitives/src/System/ServiceModel/ ServiceModelStringsVersion1.cs` (sourced via WebFetch — that file is the canonical [MC-NBFS] §2.2 table mirrored in code). The wire id is `2 * StringN` for `StringN` at 0-based position N. Coverage now spans id 0..400, picking up the full SOAP / WS-Addressing / WS-RM / WS-Security / WS-SecureConversation / WS-Trust / xmldsig+xenc URIs / SAML / Kerberos / X509 token-type subset. The 436..444 xsi/xsd/nil extras (used by .NET XmlSerializer for [MessageContract] value-type bodies) are preserved. Four new regression tests: - ids monotonic (was already there); - ids all even (`[MC-NBFS]` reserves odd ids for the dynamic dict); - SOAP-fault subset (s, Fault, MustUnderstand, Code, Reason, Text, Node, Role, Detail, Value, Subcode) resolves to the canonical strings — pins the fix against accidental regression; - `position_of_static` round-trips for known strings. Followups: - F29 moved to ## Resolved with full audit-trail. - F18 M5 status block updated to strike F29 from the remaining-work list. The remaining open M5 items are F32 (live type-matrix beyond Int32/String/Bool, gated on Galaxy provisioning) and F28 (canonical XML signing for Read/Write/Subscribe ops, P2 latent). Workspace: 712 unit tests pass (was 711 + 1 new fault-subset test + existing tests now matching canonical). Clippy clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
design/ — Rust port architectural plan
This folder is the design contract for the Rust replacement of AVEVA/Wonderware MXAccess. It is the gap between the .NET reference in src/ and the Rust crates that will be written under a sibling rust/ workspace (per CLAUDE.md).
The folder is structured as a small set of focused documents. Read in order; each builds on the previous.
| File | Purpose |
|---|---|
00-overview.md |
Mission, two-layer goal, architectural principles, non-goals |
10-raw-layer.md |
Byte-accurate raw MXAccess layer (codec + transport + session) |
20-async-layer.md |
Idiomatic Tokio async layer on top of the raw layer |
30-crate-topology.md |
Cargo workspace, crates, dependencies, build/test commands |
40-protocol-invariants.md |
Bill of materials: IIDs, opnums, envelope/handle bytes |
50-error-model.md |
MxStatus, error types, panic/cancellation policy |
60-roadmap.md |
Milestones M0..M6, validation strategy |
70-risks-and-open-questions.md |
Parity gaps, unproven flows, cross-platform constraints |
dependencies.md |
Cross- and within-milestone parallelism map; agent budget per phase |
review.md |
Adversarial review log (BLOCKER/MAJOR/MINOR/NIT findings, all resolved) |
prompt.md |
/loop driver prompt for autonomous M2–M6 execution |
followups.md |
Open / resolved deferred work items; auto-triaged by prompt.md Step 0 (created on first /loop run if missing) |
The design is grounded in the .NET reference at src/ and the protocol artifacts in docs/, analysis/, and captures/. Do not introduce protocol behavior in these documents that is not already proven in the reference. When adding a new claim about wire format, cite either:
- a
.csfile path insrc/MxNativeCodec/,src/MxNativeClient/, orsrc/MxAsbClient/, or - a
docs/*.mdspec file, or - a
captures/0NN-frida-*directory oranalysis/frida/*.tsvrow.
This folder is documentation, not code. When the Rust workspace is created, the design here is the contract it must satisfy. When evidence in captures/ invalidates a design decision here, update the design first, then the code.
Reading order
- New contributor: 00 → 30 → 10 → 40 → 20 → 50 → 60 → 70.
- Protocol question: 40 first, then the relevant section of 10.
- API question: 20 first, then 50.
- Planning a milestone: 60 first, cross-reference 70 for blockers.
- Scheduling concurrent work:
dependencies.mdfor the per-phase parallelism map. - Driving M2–M6 autonomously via
/loop:prompt.md(and thefollowups.mdtriage log it maintains).