Announcing Fuse v4: local semantic index and compiler verification for .NET agents

Fuse v4 indexes your .NET solution locally, resolves DI and routes from a typed graph, and lets any MCP-compatible coding agent ask the compiler about a proposed C# file before writing it. Install and connect from your project directory:

dotnet tool install -g Fuse
fuse mcp install --rules

Reload your MCP client, then ask:

Before changing OrderService.cs, check the proposed file with fuse_check and show the
compiler result before writing it.

The warm index and compiler-backed checks ship together in v4. fuse_check does not write the proposed content to the source file. Wiring lookup reads the same store.

What v4 Adds to Daily Work

• fuse_check typechecks one proposed file and returns compiler diagnostics without changing the working tree.
• fuse_impact shows callers, implementations, and referencing types before a signature change.
• fuse_find follows dependency injection, requests, routes, and configuration to the code that handles them.
• fuse_review starts from the Git diff and gathers focused context from related files.
• fuse_refactor stages a compiler-executed refactor as a diff and returns it only when no new compiler diagnostic appears.

Each check states which compiler path produced the answer. Fuse calls this the verification grade. Oracle grade uses a compilation captured from the real build. Build grade runs a scoped dotnet build. If neither path can answer, Fuse abstains and states what is missing.

Why agents still run dotnet build

The agent-loop benchmark counts agent-visible dotnet build and dotnet test calls separately from speculative fuse_check turns. On the recorded run those build counts were essentially equal: 3.1 for the Fuse arm versus 3.2 for native. Fuse's measured edge was higher test-verified pass@1 (89 versus 82 percent on scored rollouts) and one fewer false-done rollout (8 versus 9), not half the builds.

Pre-write checks catch compile errors before the working tree changes. The warm index replaces serial file reads during discovery. Together they cut wrong finishes and blind searching; they do not remove the need for normal builds and tests before merge.

What the Recorded Tests Support

The results below come from tests/benchmarks/results. Each applies only to the named repository, edits, or pull requests.

• In the recorded OrderingApp test app, fuse_check correctly separated all 1,000 compiler-labeled breaking and neutral edits. This does not cover every possible .NET edit.
• In that test app, Fuse matched all 24 expected .NET wiring links with no extra matches. Reflection and runtime dispatch remain limits for static analysis.
• Across 69 real pull requests, branch review retained every Git-changed file by construction at 93.4 percent precision. It returned focused context with a median size of 1,026 tokens. This does not prove that every file needed by a reviewer was returned.
• In a reduced-size agent run, Fuse completed 89 percent of scored tasks and native tools completed 82 percent. The confidence intervals overlap. Average build and test command counts were 3.1 and 3.2, so the result does not support a claim that Fuse halves those commands.

The benchmarks page contains the exact methods, confidence intervals, and weaker results. The reproduction page contains the commands.

Boundaries

• File ranking from a task title alone is less reliable than a request anchored to Git, a symbol, a route, a service, or a request type. Fuse can return a workspace map when the title lacks enough code detail.
• Compiler-backed wiring analysis is .NET-only. Other languages receive syntax-level search and source reduction.
• Faster repeated checks require the opt-in FUSE_RESIDENT=1 mode. Its timing depends on the repository and machine.
• Fuse runs locally and does not write source during check, impact, review, or read operations. fuse_workspace with action=apply is the explicit write path.

Follow the quickstart for the first checked edit, or connect your coding agent for project, user, and manual setup.