From 9ed4700eb40f444788b712620b29c87cbff9865a Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Thu, 7 May 2026 04:32:28 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20audit=20pass=20=E2=80=94=20fix=20stale?= =?UTF-8?q?=20F-number=20references?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Walked all 18 docs/*.md for stale followup references and outdated TODO markers. Two real fixes: docs/M6-buffered-evidence.md: - Three references to "F45" for the LMX-proxy Suspend/Activate Frida instrumentation were stale. That work was actually filed as F46 when the followups list got renumbered (F45 was reassigned to "Recovery replay should re-issue RegisterReference for buffered subscriptions"). F46 landed in commit 808fea1, and the follow-up live capture landed as F50 in commit 349e217. - Updated all three references to point at F46 + F50 + the resolution evidence in docs/F50-suspend-activate-evidence.md. - Renamed the "Sub-followup filed: F45" section to "Sub-followup F46 — RESOLVED 2026-05-06" with the verdict from the live capture. docs/M6-live-verification.md: - "Open work" section listed F50 as a residual gap. F50 closed 2026-05-06 per docs/F50-suspend-activate-evidence.md. Updated to "None. F49 sweep complete; F50 closed". Other docs scanned, no real staleness: - Capture-Run-2026-04-25.md, Current-Sprint-State.md, DotNet10-Native-Library-Plan.md — historical snapshot docs, intentionally pinned to their dates. - ASB-Native-Integration-Decision.md, MxNativeSession-API.md, NMX-COM-Contracts.md, MXAccess-* — describe the .NET reference's state; "not yet" wording reflects the .NET planning context, not the Rust port's current state. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/M6-buffered-evidence.md | 34 +++++++++++----------------------- docs/M6-live-verification.md | 2 +- 2 files changed, 12 insertions(+), 24 deletions(-) diff --git a/docs/M6-buffered-evidence.md b/docs/M6-buffered-evidence.md index 1a978e1..6d3a2da 100644 --- a/docs/M6-buffered-evidence.md +++ b/docs/M6-buffered-evidence.md @@ -95,12 +95,7 @@ throws `ArgumentException("Suspend requires an advised item handle")`). Consequently no `0x32`/`0x33` frame in 077's TCP capture corresponds to the suspend; the capture has nothing to falsify. -**R5 boundary that is still unproven.** Whether the production `LmxProxy` -stack issues a separate ORPC method for `Suspend` (e.g. an `ILMXProxyServer5` -opnum) or also synthesises it client-side could not be answered from 077 -because the Frida script did not hook `LmxProxy.dll!CLMXProxyServer.Suspend`. -A follow-up capture with that hook installed would close the residual gap; -filed as **F45** below. +**R5 boundary** (was unproven at the time of this evidence walk; see "Sub-followup F46 — RESOLVED" below). Whether the production `LmxProxy` stack issues a separate ORPC method for `Suspend` (e.g. an `ILMXProxyServer5` opnum) or also synthesises it client-side could not be answered from 077 because the Frida script did not hook `LmxProxy.dll!CLMXProxyServer.Suspend`. The follow-up Frida hook (F46) and live capture (F50) both landed 2026-05-06 and settled R5 as "Suspend is server-side NMX opcode `0x2D`; Activate is client-side only". ## 079 — Buffered + supervisory advise @@ -274,16 +269,16 @@ Per F44 DoD step 2 ("if a multi-sample body is observed, surface a typed carry the verbatim inner-body bytes of capture 094 lines 48 and 145 for reproducibility. -## Sub-followup filed: F45 +## Sub-followup F46 — RESOLVED 2026-05-06 -A residual gap remains at the LMX-proxy boundary: capture 077 did not -instrument `LmxProxy.dll!CLMXProxyServer.Suspend` / `.Activate`, so we cannot -say whether the production stack issues a dedicated ORPC opnum for these -operations or also synthesises them client-side. The R5 trigger conditions -documented above ("subscription must exist") are derived from the -.NET-reference compatibility server, not from a captured wire frame. Filed -as F45 in `design/followups.md` to instrument those entrypoints in the next -capture wave. +A residual gap remained at the LMX-proxy boundary: capture 077 did not instrument `LmxProxy.dll!CLMXProxyServer.Suspend` / `.Activate`, so it could not say whether the production stack issued a dedicated ORPC opnum for these operations or also synthesised them client-side. + +This was filed as **F46** in `design/followups.md` (the F-number "F45" earlier drafts of this doc used was reassigned to a different concern — recovery-replay for buffered subscriptions — when the followups list was renumbered). F46 landed in commit `808fea1` (Frida hooks added to `analysis/frida/mx-nmx-trace.js`) and the live capture ran in commit `349e217` as F50. Verdict, per `docs/F50-suspend-activate-evidence.md`: + +- **Suspend** is server-side: emits NMX `PutRequest` with command `0x2D` ~140 ms after the LMX-proxy entry, body shape `2d 01 00 + correlation_id + 22 bytes` (same family as `0x1F` AdviseSupervisory). +- **Activate** against a non-suspended item is client-side only — no wire traffic, returns Success synchronously. + +R5 in `design/70-risks-and-open-questions.md` is now settled. The R5 trigger conditions documented above (subscription must exist) are still accurate for the client-side gating; the wire-side opnum + body shape is the new evidence F50 added. ## Consolidated R2 / R5 status @@ -293,11 +288,4 @@ capture wave. Future regressions are guarded by the new round-trip tests. Status moves from "P3 likely-not-a-real-risk" to "settled per option (b) with codec change landed under F44". -- **R5 trigger conditions — observed.** From capture 077: `Suspend` - succeeds (returning `MxStatus.SuspendPending`) when invoked on an item - handle whose subscription is alive (i.e. immediately following a - successful `Advise`/`AdviseSupervisory`). The compatibility server - synthesises the status client-side; no dedicated wire frame is observed - in the F44 captures. The remaining unknown — does `LmxProxy.dll` itself - issue a Suspend/Activate ORPC method? — is filed under F45 with a Frida - hook plan. +- **R5 trigger conditions — observed + wire shape settled.** From capture 077: `Suspend` succeeds (returning `MxStatus.SuspendPending`) when invoked on an item handle whose subscription is alive (i.e. immediately following a successful `Advise`/`AdviseSupervisory`). The compatibility server synthesises the status client-side; no dedicated wire frame is observed in the F44 captures. The remaining unknown — does `LmxProxy.dll` itself issue a Suspend/Activate ORPC method? — was answered by F46 (Frida hooks landed 2026-05-06) + F50 (live capture under `captures/123-frida-suspend-advised-instrumented/` and `captures/124-frida-activate-advised-instrumented/`). Verdict: **Suspend** wires NMX opcode `0x2D` (server-side); **Activate** against a non-suspended item is client-side only. R5 closed. diff --git a/docs/M6-live-verification.md b/docs/M6-live-verification.md index 1526acd..9fea8b7 100644 --- a/docs/M6-live-verification.md +++ b/docs/M6-live-verification.md @@ -157,4 +157,4 @@ cargo test -p mxaccess-compat --features live-windows-com ` ## Open work -- **F50** — residual Frida capture for Suspend/Activate (independent of F49). +None. F49 sweep complete; F50 (residual Frida capture for Suspend/Activate) closed 2026-05-06 per `docs/F50-suspend-activate-evidence.md`.