serveFromPartition install tests travel with the engine — PluginCatalog.Test drops MeshWeaver.AI by rbuergi · Pull Request #2418 · Systemorph/MeshWeaver

rbuergi · 2026-08-26T18:24:20Z

Implements the maintainer decision of 2026-08-26 for #2276.

Why they move rather than re-point

serveFromPartition — the DB-served capability these tests exercise — exists only on MeshWeaver.AI's node types:

AddThreadType  AddModelTierType  AddSkillType  AddHarnessType
AddLanguageModelType  AddModelProviderType  AddAgentType   → all src/MeshWeaver.AI/

AddCodeType, AddCommentType, AddAppType take no such parameter. Substituting one would compile, pass, and silently delete the dimension under test — so the six install/composition tests travel to MeshWeaver.AI.Test instead.

MeshWeaver.PluginCatalog.Test drops its AI reference and stays green at 636/636.

🚨 A consequence worth your decision, not my silence

These are white-box tests of the catalog. They call RunDefaultInstall, Parse and ExcludedBy — internal to MeshWeaver.PluginCatalog, previously visible only via InternalsVisibleTo("MeshWeaver.PluginCatalog.Test").

Moving them required extending that grant to MeshWeaver.AI.Test. It works, and it survives the move (grants match on assembly simple name) — but it means AI.Test will reach into core's internals across a repository boundary once it lands in MeshWeaver.Plugins.

That is a real argument for the option not chosen: giving a core node type the serveFromPartition capability would keep these tests white-box and in core. I have implemented the decision as made and recorded the coupling so it can be revisited deliberately rather than discovered later.

Mechanics

AI.Test gains a MeshWeaver.PluginCatalog ProjectReference
moved files gain an explicit using MeshWeaver.PluginCatalog; — the parent namespace stops resolving implicitly outside PluginCatalog.Test

Verification

both projects -c Release -p:CIRun=true -warnaserror → 0 Error(s)
14 moved tests green in AI.Test
PluginCatalog.Test 636/636 without the reference

Depends on #2415 (main is red from a duplicate using).

Refs #2276

🤖 Generated with Claude Code

…s using (CS0105) My #2349 removed `using MeshWeaver.AI;` from MeshApiEndpoints.cs, breaking main. TWO sessions then fixed it independently: c01ed69 HOTFIX: main is red — MeshApiEndpoints lost sight of MeshOperations (bare import) 3a6f955 fix: restore the MeshOperations using I deleted as a phantom (annotated, #2408) Both landed, so the import appears twice and CS0105 fails the build under -warnaserror. Keeping the ANNOTATED one — it carries the explanation of why the import must never be deleted, which is the very thing whose absence caused this whole sequence — and dropping the bare duplicate. 🚨 The lesson is the same one the original break taught, and I did not apply it: a defect can exist ONLY IN THE COMBINATION. I verified main green at 831e63b and said so; the other hotfix merged after, and my statement was stale the moment I made it. A clean build on my own branch says nothing about main once main moves — only main's own post-merge run does. Verified: Memex.Portal.Shared builds -c Release -warnaserror at 0 Error(s) with exactly one import remaining. Refs #2344, #2370, #2408 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…engine Maintainer decision (2026-08-26): serveFromPartition exists ONLY on MeshWeaver.AI's node types — no core node type accepts it — so PluginCatalog.Test's six install/composition tests cannot keep that coverage in core once AI leaves. They move to MeshWeaver.AI.Test, which travels with the engine. EnvironmentCompositionTest, GhostPartitionRootRecoveryTest, PackageParameterGateTest, PreInstalledOptOutTest, PreInstalledPackageInstallTest, StaticShadowedInstallTest MeshWeaver.PluginCatalog.Test drops its MeshWeaver.AI reference and stays green at 636/636. 🚨 One consequence worth surfacing rather than absorbing: these are WHITE-BOX tests of the catalog. They call RunDefaultInstall, Parse and ExcludedBy, which are INTERNAL to MeshWeaver.PluginCatalog and were visible only through InternalsVisibleTo. Moving them required extending that grant to MeshWeaver.AI.Test. Grants match on assembly SIMPLE NAME, so it survives the move — but it means AI.Test will reach into core's internals across a repository boundary once it lands in MeshWeaver.Plugins. That is an argument for the alternative that was not chosen (give a core node type the serveFromPartition capability, keeping these tests white-box AND in core). The decision is implemented as made; the coupling is recorded so it can be revisited deliberately rather than discovered later. AI.Test also gains a MeshWeaver.PluginCatalog ProjectReference, and the moved files gain an explicit `using MeshWeaver.PluginCatalog;` — the parent namespace no longer resolves implicitly outside MeshWeaver.PluginCatalog.Test. Verified: both projects build -c Release -warnaserror at 0 Error(s); the 14 moved tests pass in AI.Test; PluginCatalog.Test 636/636 without the reference. No What's New entry: test-only refactor. Refs #2276 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Moves the serveFromPartition-specific plugin-catalog install/composition tests out of MeshWeaver.PluginCatalog.Test and into MeshWeaver.AI.Test, aligning test ownership with the AI node-type capability they exercise, while keeping MeshWeaver.PluginCatalog.Test independent of the AI engine.

Changes:

Removed the MeshWeaver.AI project reference from MeshWeaver.PluginCatalog.Test.
Added a MeshWeaver.PluginCatalog project reference to MeshWeaver.AI.Test and updated the moved test files’ namespaces/usings accordingly.
Extended MeshWeaver.PluginCatalog’s InternalsVisibleTo to include MeshWeaver.AI.Test (to keep white-box coverage after the move) and removed the duplicate using MeshWeaver.AI; in MeshApiEndpoints.cs (related to #2415).

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
test/MeshWeaver.PluginCatalog.Test/MeshWeaver.PluginCatalog.Test.csproj	Drops the direct `MeshWeaver.AI` reference so the catalog tests can stay green without the AI engine.
test/MeshWeaver.AI.Test/StaticShadowedInstallTest.cs	Updates namespace/usings so the moved install test compiles and can use `MeshWeaver.PluginCatalog` internals.
test/MeshWeaver.AI.Test/PreInstalledPackageInstallTest.cs	Same move adjustments (namespace + explicit `using MeshWeaver.PluginCatalog;`).
test/MeshWeaver.AI.Test/PreInstalledOptOutTest.cs	Same move adjustments (namespace + explicit `using MeshWeaver.PluginCatalog;`).
test/MeshWeaver.AI.Test/PackageParameterGateTest.cs	Same move adjustments (namespace + explicit `using MeshWeaver.PluginCatalog;`).
test/MeshWeaver.AI.Test/GhostPartitionRootRecoveryTest.cs	Same move adjustments (namespace + explicit `using MeshWeaver.PluginCatalog;`).
test/MeshWeaver.AI.Test/EnvironmentCompositionTest.cs	Same move adjustments (namespace + explicit `using MeshWeaver.PluginCatalog;`).
test/MeshWeaver.AI.Test/MeshWeaver.AI.Test.csproj	Adds `MeshWeaver.PluginCatalog` reference so the moved tests compile in their new home.
src/MeshWeaver.PluginCatalog/MeshWeaver.PluginCatalog.csproj	Adds `InternalsVisibleTo("MeshWeaver.AI.Test")` so the moved tests can continue white-box coverage of internal APIs.
memex/Memex.Portal.Shared/Api/MeshApiEndpoints.cs	Removes the duplicate `using MeshWeaver.AI;` while keeping the single annotated import needed for `MeshOperations`.

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

…g-ai-tests-travel # Conflicts: # memex/Memex.Portal.Shared/Api/MeshApiEndpoints.cs

github-actions · 2026-08-26T19:07:48Z