Could you share what did not work for you in the introduction? Was it unclear what Fuse does, why I built it, or who it is for? Any specific feedback, including where you became confused or lost interest, would help me rewrite it.
I picked the name in the context of a .NET global tool, and Fuse was available on NuGet. I looked into the project you mean: FUSE is the Linux Filesystem in Userspace layer, and SSHFS is one filesystem built on it. Their commands are sshfs and fusermount, so there should not be an actual CLI or NuGet conflict. The real issue is name and search confusion, which is fair, so I will make "Fuse for .NET" more obvious when I mention it outside NuGet.
I built Fuse after watching coding agents repeatedly read and search the same .NET files to
recover symbols, references, DI wiring, and project structure. On the write path, proposed
C# changes often went through a longer edit and dotnet build loop just to get semantic
feedback.
Fuse loads the solution through MSBuild and Roslyn, persists the derived index locally, and
updates changed files incrementally. The same index supplies exact symbol lookup, .NET
framework wiring, reduced task-scoped source, change impact, and Git-seeded review.
For proposed single-file C# content, fuse_check uses compiler state captured from the real
build when available. It falls back to a scoped build and abstains if neither path can run.
This is not a claim that repository indexes or code graphs are new. CodeGraphContext,
Serena, Sourcegraph, and coding-client indexes cover related parts of the category. Fuse is
narrower: local .NET analysis through MSBuild and Roslyn, including framework-specific
wiring and captured-compiler checks.
On the recorded NodaTime semantic index with 14,760 symbols, exact lookup was 1.8 ms at the
median and task localization was 15.7 ms. In a separate compiler-labeled suite over the
OrderingApp test families, Fuse recorded 0 false green and 0 false red on 1,000 generated
single-file edits plus 8 curated cases. Both results are machine- and sample-bounded.
Analysis runs locally and can work offline. No model is required. The update check and a
build using configured package feeds are the network-dependent cases.
This project desperately needs a rewritten introduction, hopefully with outside feedback.
Could you share what did not work for you in the introduction? Was it unclear what Fuse does, why I built it, or who it is for? Any specific feedback, including where you became confused or lost interest, would help me rewrite it.
Fuse is already a ssh fs driver project
I picked the name in the context of a .NET global tool, and Fuse was available on NuGet. I looked into the project you mean: FUSE is the Linux Filesystem in Userspace layer, and SSHFS is one filesystem built on it. Their commands are sshfs and fusermount, so there should not be an actual CLI or NuGet conflict. The real issue is name and search confusion, which is fair, so I will make "Fuse for .NET" more obvious when I mention it outside NuGet.
I built Fuse after watching coding agents repeatedly read and search the same .NET files to recover symbols, references, DI wiring, and project structure. On the write path, proposed C# changes often went through a longer edit and dotnet build loop just to get semantic feedback.
Fuse loads the solution through MSBuild and Roslyn, persists the derived index locally, and updates changed files incrementally. The same index supplies exact symbol lookup, .NET framework wiring, reduced task-scoped source, change impact, and Git-seeded review.
For proposed single-file C# content, fuse_check uses compiler state captured from the real build when available. It falls back to a scoped build and abstains if neither path can run.
This is not a claim that repository indexes or code graphs are new. CodeGraphContext, Serena, Sourcegraph, and coding-client indexes cover related parts of the category. Fuse is narrower: local .NET analysis through MSBuild and Roslyn, including framework-specific wiring and captured-compiler checks.
On the recorded NodaTime semantic index with 14,760 symbols, exact lookup was 1.8 ms at the median and task localization was 15.7 ms. In a separate compiler-labeled suite over the OrderingApp test families, Fuse recorded 0 false green and 0 false red on 1,000 generated single-file edits plus 8 curated cases. Both results are machine- and sample-bounded.
Analysis runs locally and can work offline. No model is required. The update check and a build using configured package feeds are the network-dependent cases.
Methods and limits: https://fuse.codes/docs/project/benchmarks
Reproduction: https://fuse.codes/docs/project/reproduce
Install: dotnet tool install -g Fuse
Repository: https://github.com/Litenova-Solutions/Fuse
Why can’t you use the charp LSP plugin for Claude code?
What does this give beyond that?
[flagged]