Tool refactoring Phase 3: drop Cake.Frosting

[rdeago]

Closes #237.

Summary

Phase 3 of #228 — the package-removal step. Cake.Http was already removed in Phase 2 (#253), so this PR removes the remaining Cake.Frosting reference and cleans up four stale Cake mentions in adjacent docs and comments. After this lands, the only surviving Cake reference in the repo is the historical CHANGELOG.md entry, which the issue explicitly allows to stay.

Changes

• Package removal
  • src/Buildvana.Tool/Buildvana.Tool.csproj — drop the Cake.Frosting PackageReference.
  • Directory.Packages.props — drop the matching PackageVersion.
• Stale-mention cleanup (none of these matched the strict Cake. grep, but all read as rot now that the host is gone)
  • src/Buildvana.Tool/Cli/BaseSettings.cs — --verbosity description no longer calls Quiet/Minimal/Normal/Verbose/Diagnostic "Cake-compat names"; just lists both name sets.
  • src/Buildvana.Tool/Services/Solution/HomeDirectorySolutionContextFactory.cs — drop the cross-reference to "Cake's old eager-load behavior in DotNetService's constructor"; keep the why (serializer is synchronous internally).
  • src/Buildvana.Core.Abstractions/BuildFailedException.cs — XML doc no longer cites <c>CakeException</c> as an example host failure mechanism; replaced with "a non-zero process exit code".
  • .claude/rules/architecture.md — drop the "(no Cake, no MSBuild)" / "(Cake, MSBuild, etc.)" examples; MSBuild stays as the lone example since Buildvana.Sdk.Tasks still depends on it.

Acceptance criteria — all met

• Cake.Frosting and Cake.Http no longer appear in Directory.Packages.props or in any csproj.
• dotnet list package --include-transitive for Buildvana.Tool shows no Cake.* packages.
• Repo-wide grep for Cake. in src/**/*.cs returns zero matches.
• dotnet bv build self-hosts locally.
• CI (build-test-pack workflow) succeeds — verified after push.

Test plan

• dotnet bv pack — 0 errors, 0 warnings.
• inspectcode --swea --severity=WARNING — 0 results.
• Both packages produced (Buildvana.Sdk, bv).
• Self-hosting smoke check after merge & publish (next build cycle).

[rdeago]

@claude please review this PR.

[claude]

Claude finished @rdeago's task in 2m 8s —— View job

---

PR Review

• Read changed files and diff
• Review package removal changes
• Review stale-mention cleanup changes
• Review architecture.md update
• Post final review

---

This is a clean, surgical PR. All six changes are correct and appropriately scoped. Here's my file-by-file pass:

Directory.Packages.props + src/Buildvana.Tool/Buildvana.Tool.csproj

Straightforward package removal. Cake.Frosting 6.1.0 is gone from both the version declaration and the reference. I verified that no Cake.* entries remain anywhere in Directory.Packages.props or any *.csproj in src/.

src/Buildvana.Core.Abstractions/BuildFailedException.cs

The replacement example is well-chosen:

(e.g., <c>CakeException</c>, <c>TaskLoggingHelper.LogError</c>, etc.)

(e.g., <c>TaskLoggingHelper.LogError</c>, a non-zero process exit code, etc.)

TaskLoggingHelper.LogError covers the MSBuild tasks host; "a non-zero process exit code" covers the bv CLI tool host. Both are actual hosts in this repo, so the new example set is more accurate than the old one.

src/Buildvana.Tool/Cli/BaseSettings.cs

// before
"...or Cake-compat names (Quiet/Minimal/Normal/Verbose/Diagnostic)."
// after
"Accepts either Trace/.../None or Quiet/.../Diagnostic."

The distinction between "LogLevel names" and "Cake-compat names" was only meaningful while Cake was in the picture. The new phrasing is shorter, accurate, and user-facing-friendly.

src/Buildvana.Tool/Services/Solution/HomeDirectorySolutionContextFactory.cs

// before (two lines)
// The package's serializers read the file synchronously; sync-waiting on the returned task
// is fine here and matches Cake's old eager-load behavior in DotNetService's constructor.

// after (one line)
// The package's serializers read the file synchronously; sync-waiting on the returned task is fine here.

The essential "why" (synchronous serializer ⇒ .GetAwaiter().GetResult() is safe) is preserved. The now-meaningless Cake cross-reference is gone. Good.

.claude/rules/architecture.md

Both updated lines are accurate:

• Sub-project description: No host references (e.g., no MSBuild). — MSBuild is now the sole meaningful example.
• Tier definition: no host references (e.g., MSBuild) — same reasoning.

One cosmetic thought, not a blocker: the first instance wraps the prohibition as (e.g., no MSBuild) while the second uses (e.g., MSBuild) (no "no"). They're consistent in meaning — both say "MSBuild is an example of a host you can't reference" — but the phrasing differs slightly. If you want uniformity it would be easy to align them; I'd lean toward keeping "no" in both ((e.g., no MSBuild)) since it makes the prohibition explicit at a glance.

---

Verdict: looks good to merge. No correctness issues. The one micro-nit above is purely cosmetic and your call entirely.

[rdeago]

One cosmetic thought, not a blocker: the first instance wraps the prohibition as (e.g., no MSBuild) while the second uses (e.g., MSBuild) (no "no"). They're consistent in meaning — both say "MSBuild is an example of a host you can't reference" — but the phrasing differs slightly. If you want uniformity it would be easy to align them; I'd lean toward keeping "no" in both ((e.g., no MSBuild)) since it makes the prohibition explicit at a glance.

Aligned by dropping the "no". "No host references (e.g., no MSBuild)" might read as a double negation, thus confusing the reader.