Repository navigation
Autocomplete.Test drops MeshWeaver.AI — keeping the import that only looks like one - #2410
Merged
Merged
Conversation
…oes not compile MAIN IS BROKEN and this is my regression. 48b3e31 (#2349) removed `using MeshWeaver.AI;` from memex/Memex.Portal.Shared/Api/MeshApiEndpoints.cs as the "fourth phantom" of a repo-wide sweep. It was not a phantom: line 335 takes a `Func<MeshOperations, IObservable<string>>`, and MeshOperations is in namespace MeshWeaver.AI. Control, on pristine main c753ad2 with no edits: error CS0246: The type or namespace name 'MeshOperations' could not be found Memex.Portal.Shared → Build FAILED, 1 Error(s) With the using restored: 0 Error(s). WHY THE SWEEP WAS WRONG. It classified an import by asking whether the project can reach the MeshWeaver.AI ASSEMBLY through ProjectReference. Memex.Portal.Shared cannot — and the import was still load-bearing, because MeshOperations SHIPS in MeshWeaver.Mesh.Operations while DECLARING namespace MeshWeaver.AI. That namespace is a frozen binary contract (#2370): a plugin compiled against it would break if it moved, which is exactly why ec56366 kept it. So the right question is "does any referenced assembly contribute a type to this namespace", not "can we reach the assembly of the same name". This is the FuzzyScorer pattern with the opposite intent. FuzzyScorer declaring MeshWeaver.AI.Completion from MeshWeaver.Data was an accident that manufactured phantom imports, and #2349 fixed it. MeshOperations declaring MeshWeaver.AI from MeshWeaver.Mesh.Operations is deliberate and load-bearing. Same shape, and I had documented the first while failing to recognise the second. The using is restored WITH the reason it exists, so the next sweep does not delete it again. 🚨 It also merged green, which is its own finding: the required check passed while Memex.Portal.Shared did not compile. My last verification was a solution build on the pre-merge branch; nothing rebuilt that project against the merged tree. Verified: pristine main FAILS, this commit builds Memex.Portal.Shared -c Release -warnaserror at 0 Error(s). Refs #2344, #2370 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…reference
Two imports named MeshWeaver.AI, and only ONE was a dependency on the engine.
UnifiedReferenceAutocompleteProviderTest AI.MarkdownReferenceExtractor — a real AI type.
Its one Theory moves to AI.Test's existing
MarkdownReferenceExtractorTest.
AutocompleteMultiSourceTest MeshOperations — STAYS. The type ships in
MeshWeaver.Mesh.Operations while DECLARING
namespace MeshWeaver.AI, a frozen binary
contract (#2370). The import is load-bearing and
is not an AI-assembly dependency.
🚨 That second case is the one I got wrong in #2349 and broke main with: the sweep asked
"can this project reach the MeshWeaver.AI ASSEMBLY" when the question is "does any
referenced assembly contribute a type to this NAMESPACE". Same shape as FuzzyScorer with the
opposite intent — FuzzyScorer's split was an accident worth fixing, MeshOperations' is
deliberate and must be preserved. Applied correctly here in both directions.
Depends on the MeshOperations restoration (#2408): without it Memex.Portal.Shared does not
compile and neither project builds.
Verified: both projects build -c Release -warnaserror at 0 Error(s); AI.Test
MarkdownReferenceExtractorTest 41/41, Autocomplete.Test 146/146.
No What's New entry: test-only refactor.
Refs #2276, #2370
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR continues the #2276 extraction work by removing the last real MeshWeaver.AI engine dependency from MeshWeaver.Autocomplete.Test, while preserving the intentionally “AI-looking” MeshWeaver.AI namespace import that actually binds to MeshWeaver.Mesh.Operations (MeshOperations) as a frozen binary contract.
Changes:
- Removed the
MarkdownReferenceExtractortest fromMeshWeaver.Autocomplete.Testand moved it into the existingMeshWeaver.AI.Testcoverage. - Dropped the direct
ProjectReferencetosrc/MeshWeaver.AI/MeshWeaver.AI.csprojfromMeshWeaver.Autocomplete.Test. - Restored/annotated
using MeshWeaver.AI;inMemex.Portal.Shared/Api/MeshApiEndpoints.csto make theMeshOperationsdependency explicit and non-“phantom”.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/MeshWeaver.Autocomplete.Test/UnifiedReferenceAutocompleteProviderTest.cs | Removes the MarkdownReferenceExtractor theory that was the suite’s last true AI-engine dependency. |
| test/MeshWeaver.Autocomplete.Test/MeshWeaver.Autocomplete.Test.csproj | Removes the direct project reference to MeshWeaver.AI, ensuring the test project no longer pulls the AI engine. |
| test/MeshWeaver.AI.Test/MarkdownReferenceExtractorTest.cs | Adds the moved theory to the AI test suite so coverage stays with the shipped AI type. |
| memex/Memex.Portal.Shared/Api/MeshApiEndpoints.cs | Keeps the load-bearing MeshWeaver.AI namespace import for MeshOperations (type provided by MeshWeaver.Mesh.Operations). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
rbuergi
enabled auto-merge
August 26, 2026 17:47
Contributor
Test Results (shard 3) 9 files 9 suites 4m 18s ⏱️ Results for commit 84dc192. |
Contributor
Test Results (shard 5) 9 files 9 suites 6m 55s ⏱️ Results for commit 84dc192. |
Contributor
Test Results (shard 0)616 tests 612 ✅ 17m 47s ⏱️ Results for commit 84dc192. |
Contributor
Test Results (shard 2)2 878 tests 2 775 ✅ 8m 1s ⏱️ Results for commit 84dc192. |
Contributor
Test Results (shard 1)2 036 tests 1 843 ✅ 9m 39s ⏱️ Results for commit 84dc192. |
Contributor
Test Results (shard 4)2 195 tests 2 193 ✅ 14m 38s ⏱️ Results for commit 84dc192. |
Contributor
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.
Eighth suite cleared for #2276.
Two imports named
MeshWeaver.AI, one dependencyUnifiedReferenceAutocompleteProviderTestAI.MarkdownReferenceExtractor[Theory]moves toAI.Test's existingMarkdownReferenceExtractorTestAutocompleteMultiSourceTestMeshOperationsMeshWeaver.Mesh.Operationswhile declaringnamespace MeshWeaver.AI, a frozen binary contract (#2370)🚨 The second case is the one that broke main
In #2349 I deleted exactly this kind of import from
MeshApiEndpoints.csas a "phantom". My sweep asked "can this project reach the MeshWeaver.AI assembly?" — it cannot — when the right question is "does any referenced assembly contribute a type to this namespace?". It does, and main stopped compiling. #2408 restores it.Same shape as
FuzzyScorer, opposite intent:FuzzyScorerdeclaringMeshWeaver.AI.CompletionfromMeshWeaver.Data— an accident that manufactured phantom imports. FuzzyScorer joins its own assembly's namespace — and three phantom AI imports go with it #2349 correctly fixed it.MeshOperationsdeclaringMeshWeaver.AIfromMeshWeaver.Mesh.Operations— deliberate, load-bearing, must be preserved.This PR applies the distinction in both directions on the same file set, which is the first time I have got both halves right in one pass.
Dependency
Requires #2408. Without the
MeshOperationsrestoration,Memex.Portal.Shareddoes not compile and neither project here builds.Verification
-c Release -p:CIRun=true -warnaserror→0 Error(s)AI.TestMarkdownReferenceExtractorTest: 41/41Autocomplete.Test: 146/146Refs #2276, #2370
🤖 Generated with Claude Code