Dogfooding

Why this repository runs on itself

There is deliberately no .mcp.json here. Committing one would either pin every contributor to one machine's install path or point at a build output that may not exist yet; a user-scope registration covers this repository along with every other.

This is not ceremony. Two of the sharper bugs in this codebase were found by using it on itself and not by its tests: a custom AnalyzerReference that made find_references and rename throw on any member in a solution containing XAML, and a resolution failure whose message the MCP layer replaced with "An error occurred". Both were invisible to a green suite and obvious within a minute of real use. After a tools/deploy.ps1 run the tray restarts, so the first call afterwards reloads the solution and is slow; that is expected rather than a fault.

What building Rose with Rose has turned up so far.

An agent session that added the whole live-app debugging and XAML surface to this repository -- ten commits, and the unit and integration tests that came with them -- used zero rose_* tools on this repository's own code. Every read was grep; every check was dotnet build, used as a syntax checker dozens of times at 14--25 seconds a go, while rose_diagnostics sat unused.

Roughly fourteen distinct failures in that session were mechanical rather than logical: not one was a wrong decision about what to change, all of them were in applying a change already decided. Stripped CRLF failing IDE0055. A heredoc eating a backslash so a native provider wrote to a tab-named path. A splice that dropped a private: and duplicated a }. A call site missed and found only from CS7036. Every one is a category Roslyn cannot produce.

The diagnosis is the part worth keeping: a non-semantic edit path poisons the read path. Because the editing was textual, the workspace was permanently mid-edit and a build was being paid for anyway -- so the semantic reads were never worth reaching for. That is why "let an agent write C# semantically" (issue #30) ranks above every other feature: it is not one more tool, it is what pulls the existing surface into use.

None of that was discoverable by reasoning about the tool surface. It came from using it, badly, at length, and then counting.