"Headless dotnet build misses Razor compile errors"

• dotnet build Code/<project>.csproj reports 0 warnings, 0 errors.
• The in-editor compiler shows real Razor compile errors (e.g. CS8917, CS0029 in .razor files).
• You trust the headless build as a green gate, but the panel is broken in the editor.

Headless dotnet build compiles the C# in your project, but in practice it does not surface the same .razor errors the live editor's Roslyn compiler does. A .razor file with genuine type-inference or expression-body errors (e.g. lambda typing bugs in event bindings) can build clean headlessly while the editor flags real CS0029 / CS8917 errors. The exact reason is inferred — the editor's Razor-to-C# codegen path appears stricter than the headless MSBuild one — but the asymmetry is reliable: the editor is the stricter gate for .razor.

Plain .cs files are validated correctly by both paths — the gap is specifically in Razor codegen.

Never trust dotnet build alone for .razor changes. After any Razor edit:

1. Bump a watched source file's mtime to dirty the in-editor compile.
2. Poll compile_status (via MCP or editor console) until it reports a result.
3. Gate on the editor's compile status, not the headless build.

# Force a recompile by touching any .cs file
(Get-Item Code\SomeFile.cs).LastWriteTime = Get-Date

The headless build remains useful for .cs-only changes and CI smoke tests, but it is necessary and not sufficient for Razor validation.

The MSBuild Razor SDK and the s&box editor's live Roslyn compiler appear to take different codegen paths for .razor files (mechanism inferred from observed behavior). The live compiler is stricter about type inference, expression-vs-statement bodies, and attribute bindings in the generated C# — errors the headless build doesn't surface.