feat(modules): retire the Approvals→Graph IVT; view packs stay thin-lane pending the static-asset provider (task #67) by rbuergi · Pull Request #1686 · Systemorph/MeshWeaver

rbuergi · 2026-08-16T18:48:26Z

What

Task #67 of the modularization program, two steps:

Step 1 — the Approvals→Graph `InternalsVisibleTo` is retired ✅

Compiling MeshWeaver.Approvals without the grant enumerated exactly two internal symbols in use, both the shared node-page chrome:

MeshNodeLayoutAreas.GetContainerStyle — the standard node-page container style (max-width resolution → centered/padded geometry)
MeshNodeLayoutAreas.BuildHeader — the standard icon/title/action/meta header

Both are promoted to public with XML docs naming the contract: an out-of-tree module (Approvals is slated for the Plugins repo) composes this chrome so its pages stay visually consistent with built-in node pages — the alternative is a hand-built copy that drifts. MeshNodeLayoutAreas is already a public API class (25 public members); no other visibility changed. The IVT grant to MeshWeaver.Approvals is deleted; Approvals compiles against public surface only. The #1683/#1685 GraphLegacySurface shims are unaffected (they delegate within the Approvals assembly / to Graph public surface).

The brief's "exactly one remaining IVT consumer" was falsified: MeshWeaver.Hosting is a LIVE consumer (verified by compiling without the grant — MeshNodeCompilationService, NodeTypeCompilationHelpers, MeshDataSourceExtensions.TryCreateReleaseNode), and MeshWeaver.Plugin.Build is deliberate (documented). Both stay, now with a csproj comment naming the coupling; retiring the Hosting grant is a separate (bigger) task.

Step 2 — view packs: not flippable yet, verdict documented at the list ⛔

Investigated whether the module lane can serve a view pack's static web assets on today's main. It cannot — every asset path runs through the host's build-time static-web-assets graph, i.e. through the very ProjectReference the flip removes:

src/MeshWeaver.Blazor.Radzen/RadzenViewBase.cs:66-67 self-loads _content/Radzen.Blazor/css/material-base.css + _content/Radzen.Blazor/Radzen.Blazor.js — package assets that enter the host manifest only via the host's reference graph
src/MeshWeaver.Blazor.GoogleMaps/GoogleMapView.razor.cs:36 imports ./_content/MeshWeaver.Blazor.GoogleMaps/GoogleMapView.razor.js — a collocated-JS static web asset
Analysis/GoogleMaps scoped .razor.css bundles into the host's aggregate at HOST build; memex/Memex.Portal.Shared/App.razor:31 links only that aggregate
Nothing serves modules/<Name>/wwwroot: UseStaticFiles (MemexConfiguration.cs:1079) + MapStaticAssets (:1220) read the host's build-time manifests; no module static-file provider exists anywhere in src/
Measured: a standalone RCL publish lays the pack's own assets at wwwroot/ ROOT, not at the _content/<pack>/ URLs its components request — so the provider work includes a path-convention mapping plus fingerprint/precompressed endpoint variants (the collision-gate exemption in MeshModuleEndpointExtensions.FindRouteCollisions covers platform duplicates only)
UiExtensibility.md "Razor assets from a runtime-loaded assembly" documents the same gap

Per the "do not force it" rule: zero packs flipped; the verdict + evidence now live as a comment block in memex/MeshModulesPublish.targets where the next wave will read it (alongside the #1681 reasons for Speech/Social/Grpc). A falsified brief is a licensed result.

Verification

Full solution dotnet build -c Release -warnaserror --no-incremental: 0 warnings, 0 errors (185 project outputs, fresh artifacts verified by mtime)
MeshWeaver.Approvals compiles clean against public-only Graph surface (grant deleted)
Monolith Release build still lays out bin/Release/net10.0/modules/<Name>/ for all 9 closure modules (targets edit is comment-only)
Tests (Release, --no-build, fresh .trx each): MeshWeaver.Graph.Test filter ~Approval 40/40 passed; MeshWeaver.Hosting.Monolith.Test filter ApprovalsLegacySurfaceCompileTest|OverviewHeaderRenderTest 6/6 passed

No What's New entry: pure-internal build-graph/API-visibility change with no user-visible effect.

Refs #1644. Prerequisite for the Approvals relocation to MeshWeaver.Plugins (tracked separately).

🤖 Generated with Claude Code

…de-page chrome is a public module-facing contract (task #67) The last module-facing IVT consumer of MeshWeaver.Graph internals was MeshWeaver.Approvals, which composes exactly two symbols: the standard node-page container style (MeshNodeLayoutAreas.GetContainerStyle) and the standard node header (MeshNodeLayoutAreas.BuildHeader). Both are promoted to public with XML docs naming the contract: out-of-tree modules render pages visually consistent with built-in node pages by composing this chrome — the alternative is a hand-built copy that drifts. The IVT grant to MeshWeaver.Approvals is deleted; Approvals now compiles against public surface only (prerequisite for its relocation to the Plugins repo). The remaining src→src grants are LIVE and out of this task's scope, now documented in the csproj: MeshWeaver.Hosting (build/bake pipeline drives NodeType compilation via MeshNodeCompilationService / NodeTypeCompilation- Helpers / TryCreateReleaseNode — verified by compiling without the grant) and MeshWeaver.Plugin.Build (calls the skeleton generator by design). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ot ride the module lane yet (task #67) Verdict for flipping Blazor.Radzen / Blazor.Analysis / Blazor.GoogleMaps off the host build graph: BLOCKED, documented at the list the next wave reads. Every asset path runs through the HOST's build-time static-web- assets graph — Radzen self-loads _content/Radzen.Blazor/* (RadzenViewBase), GoogleMaps imports its collocated GoogleMapView.razor.js, Analysis ships scoped .razor.css that bundles into the host's aggregate styles.css at host build. Nothing serves modules/<Name>/wwwroot (no module static-file provider exists; UseStaticFiles/MapStaticAssets read the host manifests), and a standalone RCL publish lays the pack's own assets at wwwroot/ ROOT, not at the _content/<pack>/ URLs its components request. The flip needs the module static-asset provider design, not a list edit. Also records the three service modules' not-flippable reasons from #1681 beside their entries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Copilot

Pull request overview

This PR advances the module modularization effort by removing the Approvals→Graph InternalsVisibleTo coupling and promoting the two node-page chrome helpers Approvals depended on to public API, while documenting why view packs can’t yet be moved to the closure lane due to static web asset constraints.

Changes:

Removed InternalsVisibleTo for MeshWeaver.Approvals from MeshWeaver.Graph.
Promoted MeshNodeLayoutAreas.GetContainerStyle and MeshNodeLayoutAreas.BuildHeader to public with contract-focused XML docs for out-of-tree modules.
Added an in-file “blocked” rationale for view-pack flipping in MeshModulesPublish.targets (static-web-assets provider gap).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/MeshWeaver.Graph/MeshWeaver.Graph.csproj	Drops the Approvals IVT grant and clarifies the remaining Hosting coupling rationale.
src/MeshWeaver.Graph/MeshNodeLayoutAreas.cs	Makes the shared node-page container/header helpers public for module consumption and documents the API contract.
memex/MeshModulesPublish.targets	Documents why view packs must remain thin-lane until static web assets can be served from runtime-loaded modules.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

github-actions · 2026-08-16T19:02:11Z