Framework analyzer spikes: .NET solution model and Java/Spring project model

[serge-ivo]

Summary

Create discovery spikes for .NET and Java/Spring so the analyzer platform contract accounts for non-JS enterprise stacks before the public plugin SDK is designed.

Why

The roadmap explicitly targets broad stack support: React, Flutter, .NET, Rails, Java/Spring, and more. .NET and Java are useful stress tests because their project shape, build tools, package managers, test layout, and static analyzers differ substantially from TypeScript apps.

.NET questions

• How should VCQA model .sln, .csproj, test projects, and project references?
• Which tools are first-class: dotnet build, dotnet test, dotnet format, analyzers, coverage collectors?
• How should NuGet dependency health map into existing Dependencies/Deps UX?
• What is the framework-specific split between ASP.NET, Blazor, MAUI, libraries, and worker services?

Java/Spring questions

• How should VCQA model Maven vs Gradle, multi-module builds, and source sets?
• Which tools are first-class: mvn test, gradle test, Checkstyle, SpotBugs, PMD, JaCoCo?
• How should Spring-specific concerns be represented without hardcoding Java assumptions into generic checks?
• How should generated code and build output be excluded/visual-neutralized?

Tasks

• Draft minimal LanguageProfile candidates for C# and Java.
• Build tiny fixture repos or identify reference fixtures for .NET and Java/Spring.
• Define what should be generic vs framework-specific for each stack.
• Identify which analyzers must run out of process.
• Produce follow-up implementation tickets for the first one chosen.

Acceptance criteria

• We have enough concrete shape to avoid designing the analyzer/plugin protocol only around TypeScript/Flutter.
• The public plugin SDK requirements list reflects .NET and JVM analyzer needs.
• Follow-up tickets are filed for the chosen first enterprise-stack analyzer.

Related

• Umbrella: Tracking: analyzer-platform groundwork (schema, stack-gating, fixtures, engine decision) #24
• Language profiles: Language profiles: define LanguageProfile, dedupe test/SFC logic, add toolchain commands, and emit meta.profile #23
• Internal out-of-process analyzer protocol: Internal out-of-process analyzer protocol over stdio JSON #32
• Language profile spec: cli/docs/language-profiles.md
• Protocol spec: cli/docs/out-of-process-analyzers.md

[serge-ivo]

Audited for closure and leaving open — but it should be rescoped, and it is blocked. Recording what I checked so the next reader does not repeat it.

I came here expecting to close this on three blockers. Two hold, one does not.

• The LanguageProfile type does not exist in code. grep -rn "LanguageProfile" --include="*.ts" src returns nothing on main (d1c5314). It exists only as a spec in docs/language-profiles.md:35-53. Task 1 here — "draft minimal LanguageProfile candidates for C# and Java" — is drafting against a documented interface that nothing implements. Language profiles: define LanguageProfile, dedupe test/SFC logic, add toolchain commands, and emit meta.profile #23 was rescoped on 2026-08-11 to deliver exactly that type, so this is a straightforward blocked-on-Language profiles: define LanguageProfile, dedupe test/SFC logic, add toolchain commands, and emit meta.profile #23, not a reason to close.
• *.csproj / *.sln are deferred, not forbidden. docs/language-profiles.md:93-96 says "Do not add these markers yet", under the project-marker list, alongside :100 ("discovery-only profiles must not emit lint/type/test/audit commands and must be reported as unsupported/unavailable"). That is a sequencing rule about claiming .NET discovery before analyzers exist. The same document uses C# as its worked example of the profile/analyzer split at :167 — "C# profile knows .csproj; .NET analyzer knows solution/test-project mapping" — so the doc anticipates this work rather than prohibiting it. A spike that produces no markers does not violate it. I was wrong to treat this as a blocker.
• The acceptance criteria are genuinely unfalsifiable, and one is worse than that. "We have enough concrete shape to avoid designing the protocol only around TypeScript/Flutter" cannot be checked by anyone. "The public plugin SDK requirements list reflects .NET and JVM analyzer needs" names an artifact that does not exist and is explicitly out of the current milestone — Tracking: analyzer-platform groundwork (schema, stack-gating, fixtures, engine decision) #24 states "Explicitly not in scope: a public plugin SDK … Not the current milestone." So that criterion cannot be satisfied even in principle right now.

Why it stays open. #24 was audited on 2026-08-11 and still carries this as its Layer-4 enterprise-stack item ("#34 — .NET/Java/Spring spikes; Python remains a later language-profile/analyzer candidate when demand pulls it"). The product still wants the work; the issue is just written against a milestone that moved.

What a re-fileable version looks like. Rescope to one deliverable a reviewer can check, and drop the plugin-SDK criterion:

• Depend on Language profiles: define LanguageProfile, dedupe test/SFC logic, add toolchain commands, and emit meta.profile #23 landing LanguageProfile, then add discovery-only csharp and java profiles — extensions, test patterns, skip dirs, generated patterns, support: unsupported, no toolchain commands — the same shape e4c4221 (Expand project discovery to manifest-backed non-Node ecosystems #80) already shipped for go/rust/java-maven/java-gradle/python/pants in src/data/discovery-conventions.json:104. Note that pom.xml, build.gradle and settings.gradle are already permitted markers (docs/language-profiles.md:85-92), so the Java half may be closer to done than this issue assumes — check discovery-conventions.json before writing anything.
• Falsifiable acceptance: scanning a small .NET and a small Java/Spring fixture reports the projects with the right language and support: unsupported, emits no lint/type/test commands, and scores nothing.
• Keep the open design questions (Maven vs Gradle multi-module, .sln project references, which analyzers must be out of process) as prose in docs/language-profiles.md / docs/out-of-process-analyzers.md — :139-140 of the latter already lists ".NET spike analyzers" and "Java/Spring spike analyzers" as future entries.
• Choosing which enterprise stack goes first is a maintainer call and should be stated as an open question, not assumed by the ticket.

Blocked on #23. Related: #24 (which schedules this), #80 and #79 (the discovery mechanism a rescoped version would reuse), #32 (out-of-process protocol).