Repository navigation
The AI engine leaves the content surface — the gate lands it as a module (#2276) - #2524
Merged
Merged
Conversation
…ULE (#2276) FrameworkBuildIdentity.ContentSurfaceAssemblies drops MeshWeaver.AI: the engine is a registry module now, composed into content compiles per-mesh via ComposeWithModules, never part of the framework identity. An image shipping AI.dll in its app closure would 409 the registry module — this is the core half of clearing that gate; the plugins half drops the portal Gui and LocalMesh ProjectReferences against this commit's pin. The bake host (mw-plugin-test) keeps needing the AI node types — plugin packages ship Agent/Skill nodes, and a mesh without the types refuses those installs — so the gate now activates the engine the way a portal does: - the tester csproj replaces the ProjectReference with a tester-local MeshModuleClosure row (written AFTER the MeshModulesPublish import, so the shared inventory is untouched and no portal image gains the module), laying modules/MeshWeaver.AI/ into build and publish output; - PluginGateRunner builds an in-memory configuration (Modules:Assemblies + Modules:Required + one StaticRepoSync partition, union-expanded by the module's served-as-a-unit rule) and InstallConfiguredModules activates the engine through AiMeshModuleAttribute — no compiled call; - a missing module fails the gate RED before the mesh boots (a gate never tests its own inputs); - the import-settled signal is registered pre-settled — the documented "nothing to import" state — since gate content arrives via installs. Four projects that arrived transitively through the engine and are still part of the content surface (Mesh.Operations, Application.Styles, Markdown.Collaboration, ContentCollections.Indexing.Graph) become direct tester references, so the canonical list and the tester closure stay equal — CanonicalList_MatchesTheTesterClosure passes unchanged in shape. MeshWeaver.PluginTester.Test imports the same lane with the same single row (nine of its suites boot the gate in-process); all 91 pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tz1i2fFcJhvR1Eje8yFH5F
Contributor
There was a problem hiding this comment.
Pull request overview
This PR continues #2276 by removing MeshWeaver.AI from the platform “content surface” identity and treating the AI engine as a module that is activated via Modules:Assemblies, rather than a compiled reference. It also updates the plugin gate/tester to load the AI engine from the modules/MeshWeaver.AI/ layout (closure lane) and fail early when the required module bits are missing.
Changes:
- Dropped
MeshWeaver.AIfromFrameworkBuildIdentity.ContentSurfaceAssemblies, reflecting that the AI engine no longer contributes to the framework identity. - Updated
mw-plugin-testgate boot to activate the AI engine through module configuration (InstallConfiguredModules) and to hard-fail when the required module cannot be resolved. - Reworked the PluginTester and its test project to lay out the AI engine via
MeshModuleClosure(module publish layout) instead of aProjectReference, and added direct references for assemblies that remain on the content surface.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tools/MeshWeaver.PluginTester/PluginGateRunner.cs | Replaces compiled .AddAI(...) with module activation + required-module preflight; registers StaticRepoImportSettled pre-settled for the gate. |
| tools/MeshWeaver.PluginTester/MeshWeaver.PluginTester.csproj | Removes AI ProjectReference; adds direct references for remaining surface assemblies; imports module publish targets and declares a tester-local MeshModuleClosure for AI. |
| test/MeshWeaver.PluginTester.Test/MeshWeaver.PluginTester.Test.csproj | Ensures the test output also gets the AI module layout by running the same closure lane (targets import + single-row MeshModuleClosure). |
| src/MeshWeaver.Compiler/FrameworkBuildIdentity.cs | Removes MeshWeaver.AI from the framework content-surface assembly list and documents the module-based composition rationale. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
This was referenced Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The core half of clearing #2276's remaining gate (the 409):
FrameworkBuildIdentity.ContentSurfaceAssembliesdropsMeshWeaver.AI. The engine is a registry module — composed into content compiles per-mesh viaCompileReferences.ComposeWithModules, never part of the framework identity. The plugins half (dropping the portal Gui / LocalMeshProjectReferences + the hosts' cutover to registry delivery) lands against this commit's platform pin; until then plugins builds at its current pin are untouched.The bake host keeps the engine — as a module
Plugin packages ship
Agent/Skillnodes, and a mesh without the AI node types refuses those installs. Somw-plugin-testnow runs the engine exactly the way a portal does:ProjectReferencewith a tester-localMeshModuleClosurerow, written AFTER theMeshModulesPublishimport so the shared inventory is untouched — no portal image gains a closure copy (that would be the 409 back again). The real closure lane laysmodules/MeshWeaver.AI/(entry DLL + its private NuGet closure) into build and publish output.PluginGateRunneractivates it via an in-memory configuration (Modules:Assemblies+Modules:Required+ oneFeatures:StaticRepoSyncpartition, union-expanded to all AI content partitions by the module's served-as-a-unit rule) throughInstallConfiguredModules→AiMeshModuleAttribute. No compiled call.The closure equality holds
Four projects that arrived transitively through the engine and are still content surface (
Mesh.Operations,Application.Styles,Markdown.Collaboration,ContentCollections.Indexing.Graph) become direct tester references, soCanonicalList_MatchesTheTesterClosureand the manifest-host closure check pass unchanged in shape (all 23 identity tests green).Tests
FrameworkBuildIdentityTest: 23/23 green.MeshWeaver.PluginTester.Test: 91/91 green — nine of those suites boot the gate in-process, so this is the in-proc proof that installs, compiles, renders andTestsareas all work with the engine module-activated.Deploy note
Merging this changes the bake identity core CI publishes under. Deployed portals keep their own (pin-frozen) identity and their existing bakes until the plugins pin bump + image roll, which should follow promptly — the flip sequence is tracked on #2276.
No What's New entry: pure-internal platform step — the user-facing story (the AI Store entry) ships with MeshWeaver.Plugins#687.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Tz1i2fFcJhvR1Eje8yFH5F