[rbuergi]

What

The platform no longer carries YamlDotNet. Since #7180 no core code has used it: core reads and writes YAML with its own MeshWeaver.Yaml (Doc/Architecture/TolerantYaml). The reference in MeshWeaver.Hosting and the central PackageVersion were kept only because MeshWeaver.Plugins' MeshWeaver.AI and MeshWeaver.Publish referenced YamlDotNet versionless. Systemorph/MeshWeaver.Plugins#4227 moves both to MeshWeaver.Yaml. This PR is the deleting half:

• src/MeshWeaver.Hosting/MeshWeaver.Hosting.csproj: the YamlDotNet PackageReference is removed, and the comment now says why there is none.
• Directory.Packages.props: the YamlDotNet PackageVersion and its comment are removed.
• TolerantYaml.md gains a section, "No third-party YAML library in the platform". DependencyMajorUpgrades.md records that YamlDotNet has left the fleet. The 16.3 → 18.1 entry and the incident history are unchanged.

Pairs-with: Systemorph/MeshWeaver.Plugins#4227 — this PR lands only after that PR has merged into Plugins main. Until then, removing the PackageVersion would break Plugins' restore of the versionless references (NU1010).

Satellite-pins: YamlDotNet — I ran git grep -i yamldotnet origin/main in every repository that imports or pins this package list. MeshWeaver.Plugins, after #4227: no PackageReference, no code use and no in-mesh node source left; the only mentions are incident history in Hosting/BuildAndReleaseProcess.md, Hosting/BuildService.md and the ModuleLinkVersionTest stand-ins, which need no package. MeshWeaver.Education, .Reinsurance, .SocialMedia, .Manufacturing, .Crm and .FundReporting: 0 hits each. A semantic search 'YamlDotNet DeserializerBuilder partitions:all' on the control instance returned 2 hits, a doc page and a triage item, and no node source. It read 60 partitions, 13 of them only in part, so that count is a floor. The same search on the public instance's MCP failed with a provider timeout, so no sweep was established there.

An already-deployed bundle on an image without YamlDotNet

The AI bundles already published were built while MeshWeaver.AI still referenced YamlDotNet. They ship their own YamlDotNet.dll in their closure: that is the 2026-09-11 incident shape recorded in ModulePlatformLinkGate.md, where the bundle "shipped its own YamlDotNet". The link rule (ModulePlatformLink: a closure reference stays out of the denominator unless surface.IsPlatformBound(name)) handles such a reference as follows:

• On a platform that carries YamlDotNet, the platform's copy wins, and the reference is version-compared. This was the 09-11 case.
• On an image without YamlDotNet, the name is not carried, so the module's own copy is outside the denominator. The probe says Linkable, and at run time the module binds the copy beside it, like any private dependency.

So an already-deployed bundle keeps loading. There is no binding conflict, because no platform copy remains to conflict with, and there is no FileNotFoundException, because the copy travels with the bundle. Bundles published after Plugins#4227 reference MeshWeaver.Yaml, which is a platform assembly (MeshWeaver.Hosting references it). Not established: I did not open a currently published AI or Publish bundle to confirm that YamlDotNet.dll is in it today. The statement above rests on the recorded incident and the closure rule.

Verified locally

Each project built -c Release -warnaserror with 0 Error(s): MeshWeaver.Hosting and MeshWeaver.Documentation.Test, which embeds the edited pages. git grep -i yamldotnet over every non-Markdown file in core finds no code use: only doc-comment examples of the 09-11 status line and string data in PlatformLinkDecisionTest. Documentation guards, run from the built executable: DocumentationLinkIntegrityTest, DocumentationFrontMatterGuard, PackageFamiliesMoveTogetherGuard and ModuleBuildLedgerLaneGuard, 16/16 passed. scripts/check-package-pin-removal.py was run against this body locally: "Every removed entry is declared: YamlDotNet", exit 0. Negative control: a body without the declaration exits 1 and names YamlDotNet.

Not armed

The ordering was held by draft, not by a gate: neither Pairs-with: nor Satellite-pins: is resolved when only a dependency leaves (see the review thread). The PR left draft only after Systemorph/MeshWeaver.Plugins#4227 merged into Plugins main (9142c1c99b).

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The stated pairing gate does not enforce the prerequisite Plugins merge for this dependency-only removal.

1 open issue

• Enforce merge barrier for dependency-only removals · New

What changed in this PR

This PR completes core’s move to MeshWeaver.Yaml by removing the remaining YamlDotNet dependency, following the planned Plugins migration.

Changes:

• Remove the hosting package reference and central YamlDotNet version.
• Document the dependency removal and expected loading behavior for older module bundles.
• Preserve the historical dependency-upgrade record.

File	Description
src/​MeshWeaver.Hosting/​MeshWeaver.Hosting.csproj	Remove YamlDotNet and explain use of the platform YAML library.
src/​MeshWeaver.Documentation/​Data/​Architecture/​TolerantYaml.md	Document module migration and legacy-bundle compatibility.
src/​MeshWeaver.Documentation/​Data/​Architecture/​DependencyMajorUpgrades.md	Record YamlDotNet’s removal while retaining upgrade history.
Directory.Packages.props	Remove the central YamlDotNet package version.

_{Review effort: Balanced}

[rbuergi]

Confirmed, on both counts. check-cross-repo-pair.py returns success at "No public type or member left src/" without resolving Pairs-with:. check-package-pin-removal.py checks the Satellite-pins: declaration only, which its own docstring says is by design. So no gate held this PR. The description's "the Pairs-with: gate holds it red" was wrong, and I've corrected it.

The hold that applied is the one you named: the PR stayed in draft. A watcher script marked it ready only after it saw Systemorph/MeshWeaver.Plugins#4227 merged: true over REST. #4227 is on Plugins main as 9142c1c99b. On that tree, git grep YamlDotNet finds no PackageReference and no code use. The remaining mentions are doc comments and ModuleLinkVersionTest, which now measures against Markdig. So removing the pin here leaves no versionless reference to strand.

The gap itself, that a declared Pairs-with: goes unresolved when only a dependency leaves, is filed for triage rather than widened in this PR.

[github-actions]

Test Results

    25 files      25 suites   56m 57s ⏱️
11 683 tests 11 681 ✅ 2 💤 0 ❌
11 709 runs  11 707 ✅ 2 💤 0 ❌

Results for commit 9e3fe42.