[Xueyang-Song]

Step 2, part 5 of the MarkdownRenderer structure cleanup. It is stacked on #112 and targets that branch; it retargets as the branches below it merge.

The TextMate grammar packs shared their TextMateSharp adapter by compiling one source file into both assemblies, the last file link in the renderer. That adapter now lives in a new shipping package, MarkdownRenderer.SyntaxHighlighting.TextMate.Engine, and both packs reference it. No file links remain, and no ProjectStructureException remains anywhere.

The engine package

You chose a shared engine package whose API takes TextMateSharp's registry options.

...SyntaxHighlighting.TextMate   (lean integration and provider contracts; no TextMateSharp)
  └─ ...TextMate.Engine          (TextMateSharpGrammarProvider; brings TextMateSharp and Onigwrap)
       ├─ ...Grammars.Common     (curated embedded grammars)
       └─ ...Grammars.All        (TextMateSharp.Grammars)

• TextMateSharpGrammarProvider is the former internal BundledTextMateGrammarProvider, moved with history. It is unchanged apart from its constructor. The required inputs (revision, registry-options factory, scope resolver) come first, then optional allowedLanguageIds and options; null options now mean the defaults. The test-only checkpoint hook stays on an internal constructor, and the engine grants internal access to its TextMate test project.
• Common and All wrap it exactly as before. Their public API, revisions and behavior are unchanged.
• Package rules, as checked by the TextMate release evidence:
  • the lean integration still depends on no TextMateSharp, TextMateSharp.Grammars or Onigwrap;
  • the engine depends on the integration and TextMateSharp, and never on TextMateSharp.Grammars;
  • Common depends on the engine and TextMateSharp, and still never on TextMateSharp.Grammars;
  • All depends on the engine and TextMateSharp.Grammars.
• The Common deployment cap (6 MiB per RID) now counts the engine DLL too, because a Common deployment ships it.

The one public TextMateSharp dependency

The PublicApi tests forbid third-party types in any shipping public signature. The engine is now the single exception: ForbiddenContractTypeTests allows TextMateSharp. for that assembly only. A new test, ThirdPartyExceptions_NameShippingAssembliesThatActuallyUseThem, fails if the exception stops being needed. The lean integration and both grammar packs still expose no TextMateSharp type. As a result, the engine package's version has to follow TextMateSharp's breaking changes. public-api.md says so, and the package description tells hosts to install a grammar pack instead.

Wiring the ninth package

• Both solutions, the CI workflow's locked-restore and pack lists, the expected release package set and its TextMate scope, the managed-architecture map, and the TextMate release-evidence script (restore, pack, entries, dependencies, managed assets and the selected-RID payload).
• The compliance tooling self-test pinned 8 package IDs and matched error text with "8" in three places. It now pins 9 and derives the rest from the expected set.
• ShippingAssemblies, and the app's security-gate test, which lists the shipping projects inside the app's locked graph.
• Lock files: the engine's own, plus the nine projects that reach it through a grammar pack. The changes are only the engine entry and its TextMateSharp dependency.
• Docs: the package table and dependency graph in packaging-and-distribution.md, and public-api.md. The packaging table's Mermaid row no longer calls the MMIR scene contracts public, which follows from MarkdownRenderer structure step 2d: overload rules on, Mermaid and Math expose configuration only #112.

Decisions for review

• Package name ...TextMate.Engine, as proposed. The lean pack keeps its name. The release-evidence script used to call the lean pack $enginePackage, so that variable is now $integrationPackage, to avoid two different "engines".
• No size gate for the engine. It packs to 18 KB; the lean integration and Grammars.All have no gate either. Its bytes count toward the Common selected-RID cap above.
• No notices file in the engine package. It embeds no third-party content; TextMateSharp arrives as a NuGet dependency carrying its own license.
• Common keeps its direct TextMateSharp reference even though the engine brings TextMateSharp transitively, because CuratedRegistryOptions implements TextMateSharp's registry contract itself.

Verification

Check	Result
MarkdownRenderer.slnx Release x64	0 warnings, 0 errors
Test-ProjectStructure.ps1	passes: 32 projects, 1,053 files; no ProjectStructureException in any project
MarkdownRenderer.Tests / GitHub.Tests / Svg.Resvg.Tests	1,408 / 3,043 / 808
Math / Mermaid / Html / TextMate / Conformance	80 / 259 / 10 / 70 / 9
PublicApi.Tests / Sample.Automation.Tests	19 / 4
JitHub.WinUI.Tests Debug	3,126 of 3,126
JitHub.WinUI Release x64 with the security gate	passes; 84/84 ReleaseSecurity tests, including the engine in the app's locked graph. One warning: MSB3774, this machine has no VCLibs SDK
Invoke-TextMateReleaseEvidence.ps1	passes: contract tests, provenance, two reproducible packs, entries and dependency rules for all four packages, compliance, and package consumers for x86, x64 and ARM64
Common selected-RID payload, now including the engine DLL	5,399,040 / 5,392,384 / 5,353,472 bytes (x86 / x64 / ARM64), under the 6 MiB cap
NativeAOT project smokes, win-x64	all publish with 0 warnings and run; TextMate highlights through both Common and All
MarkdownRenderer package consumed by NativeAOT and trimmed single-file	x86 and x64 run; ARM64 cross-published
Packed packages	9; size gates pass (936,971 bytes compressed, 2,301,952 managed); engine 18,454 bytes
Managed package architecture	8 managed assemblies across 9 packages, all AnyCPU
--locked-mode restore	every project except JitHub.Web and JitHub.Web.Tests, whose locks don't match this machine's SDK (10.0.14 vs 10.0.11); unchanged here
Engineering and compliance script self-tests	pass
resvg worker identity, x86/x64/arm64	verified

Not run: Sandbox UI cases, PixelTests and the external performance-gate subset. This change moves code between assemblies without changing rendering.

🤖 Generated with Claude Code