diff --git a/docs/plans/2026-07-24-mtconnect-driver.md b/docs/plans/2026-07-24-mtconnect-driver.md
index 87aa9ea6..2a1d20db 100644
--- a/docs/plans/2026-07-24-mtconnect-driver.md
+++ b/docs/plans/2026-07-24-mtconnect-driver.md
@@ -69,6 +69,36 @@ absence of a physical `LICENSE` file is not a fail. Task 1 adds
 `PackageReference MTConnect.NET-Common 6.9.0.2` + `PackageReference MTConnect.NET-HTTP 6.9.0.2` to
 `Driver.MTConnect.csproj`; the hand-roll fallback is not needed.
 
+**CORRECTION (Task 6, commit `bdfefadc`) — the decision above rested on incomplete evidence, and the
+hand-roll fallback IS in use for parsing.** Task 0 verified the packages *exist, restore, and are MIT*;
+it never verified they can actually parse an MTConnect document. As pinned, they cannot. Task 6 proved
+this empirically before writing any parser code: reflection over both referenced assemblies
+(`MTConnect.NET-Common`, 1297 types; `-HTTP`, 410 types) found **zero `IResponseDocumentFormatter`
+implementations and zero public static `FromXml`/parse entry points**, and a live invocation of
+TrakHound's own entry point (`ResponseDocumentFormatter.CreateDevicesResponseDocument("xml", stream)`)
+against this repo's `Fixtures/probe.xml`, with both DLLs loaded, returned:
+
+```
+Success = False
+ERROR:  Document Formatter Not found for "xml"
+```
+
+TrakHound 6.x resolves formatters from loaded assemblies at runtime, and the XML formatter ships in a
+**third package, `MTConnect.NET-XML`**, which Task 0 did not evaluate. Even with it added, TrakHound
+exposes no socket-free `Parse(string)` entry point of the shape this plan mandates. So `/probe` parsing
+is a hand-rolled `System.Xml.Linq` walk (~250 LoC, `MTConnectProbeParser`); the driver above the
+`IMTConnectAgentClient` seam is unaffected, exactly as the decision rule anticipated.
+
+**The two `PackageReference`s remain and are, so far, dead weight.** Task 6 deliberately did not remove
+them: the hard remaining problem is Task 7's `multipart/x-mixed-replace` chunk framing for `/sample`,
+and `MTConnect.Clients.MTConnectHttpClientStream` in `-HTTP` may be usable for framing alone. **Task 7
+owns the final call:** (a) use `-HTTP` for framing only, (b) add `MTConnect.NET-XML` and reconsider
+wholesale, or (c) hand-roll the boundary reader and **drop both package references** — in which case the
+Task-0 rationale comment in `Directory.Packages.props` goes with them. Record the outcome here.
+
+**Process lesson:** "the dependency restores" is not "the dependency does the job." A library
+verification checklist needs one end-to-end call against a real input, not just a restore.
+
 ---
 
 ## Task 1: Scaffold the two driver projects + the test project