Two shipping packages are excluded from the solution build and only compile during Pack

[jeremydmiller]

wolverine.slnx marks seven projects <Build Project="false" />. Two of them are shipping NuGet packages:

project	package	published
src/Http/Wolverine.Http.Polecat	WolverineFx.Http.Polecat	yes — 6.24.6
src/Http/Wolverine.Http.AspVersioning	WolverineFx.Http.AspVersioning	yes — 6.24.6

Both appear in the explicit nugetProjects array in build/build.cs, so Pack compiles them at publish time. Nothing else does. dotnet build wolverine.slnx — the command CI's Compile target runs, and the one CLAUDE.md tells contributors to run before pushing — skips them entirely.

Both build clean today. This is a missing gate, not a current break. But it means a tightening change in a dependency can break a shipping package and every per-PR CI run stays green; the first thing that fails is a release, at the moment you least want to be debugging.

That is not hypothetical for this repo. CLAUDE.md already carries a warning that wolverine_slim.slnx omitting projects makes a clean slim build insufficient evidence for exactly this class of change (a new AOT/trim annotation in JasperFx, a type lift from Marten/Polecat into JasperFx.Events). Build=false inside the full solution reintroduces the same blind spot one level down, where nobody is looking for it.

The full list

src/Http/Wolverine.AdminApi/Wolverine.AdminApi.csproj
src/Http/Wolverine.Http.AspVersioning/Wolverine.Http.AspVersioning.csproj          <-- shipped
src/Http/Wolverine.Http.AspVersioning.Tests/Wolverine.Http.AspVersioning.Tests.csproj
src/Http/Wolverine.Http.Polecat/Wolverine.Http.Polecat.csproj                      <-- shipped
src/Persistence/Polecat/PolecatIncidentService/PolecatIncidentService.csproj
src/Persistence/Polecat/PolecatIncidentService.Tests/PolecatIncidentService.Tests.csproj
build/build.csproj

I built all of them directly while verifying the JasperFx 2.39.5 upgrade (#3837). Six are clean; PolecatIncidentService.Tests does not compile at all and has not since April — filed separately as #3839. That one is the proof this blind spot is real rather than theoretical: a project sat broken for four months and no gate noticed.

None of the flags carry a comment explaining why. An unexplained Build=false is indistinguishable from an accident, and there is no inventory of what is hidden.

Suggested direction

1. Re-enable the two shipping projects in wolverine.slnx and confirm the full-solution build stays clean.
2. For anything that genuinely must stay excluded, require a comment naming the reason next to the flag.
3. Add the check to the guard proposed in Guard that every CI* target runs somewhere must walk the Nuke dependency graph, not grep workflow files #3816 — that issue is about every CI* target running somewhere, and this is the same failure mode one layer down: something in the build graph that no gate actually executes. A guard that walks the Nuke dependency graph should also assert that every project in nugetProjects is built by the solution.

Related: #3816 (CI-target coverage guard), #3839 (the Polecat sample this surfaced from).

[jeremydmiller]

Correction to the issue body: it names two shipping packages, and only one of them is actually excluded.

I built that list with a grep -B 2 'Build Project="false"', and the two-line context window pulled in neighbouring <Project> entries that carry no such flag. Parsing the elements properly gives the real list:

EXCLUDED: src/Http/Wolverine.Http.AspVersioning.Tests/Wolverine.Http.AspVersioning.Tests.csproj
EXCLUDED: src/Http/Wolverine.Http.AspVersioning/Wolverine.Http.AspVersioning.csproj
EXCLUDED: src/Persistence/Polecat/PolecatIncidentService.Tests/PolecatIncidentService.Tests.csproj
EXCLUDED: src/Persistence/Polecat/PolecatIncidentService/PolecatIncidentService.csproj
EXCLUDED: build/build.csproj

Wolverine.Http.Polecat is not excluded — it sits in the solution as a plain <Project Path="..." /> at line 119 and is built normally. Wolverine.AdminApi likewise. Sorry for the noise on those two.

So the accurate finding is one shipping package outside the solution build, not two:

project	package	in solution build?
Wolverine.Http.AspVersioning	WolverineFx.Http.AspVersioning	no
Wolverine.Http.Polecat	WolverineFx.Http.Polecat	yes — retracted

That does not change the substance of the issue. A published package that compiles only during Pack still means a dependency change can break a release while every per-PR run stays green, and PolecatIncidentService.Tests (#3839) still proves the blind spot is real rather than theoretical — it sat broken for four months behind the same flag. It does shrink the blast radius by one package, and the issue title should really say "a shipping package", singular.

build/build.csproj is excluded deliberately and correctly — the Nuke build project is not part of the product solution. It is the only one of the five that should keep the flag.