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

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

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).