fix: Use explicit solution file in DotNetTests to prevent flaky failures

[thomhurst]

Summary

• Fix flaky DotNetTests.Has_Not_Errored test on Windows CI
• Changed from picking first .sln file alphabetically to explicitly using ModularPipelines.sln

Problem

The test was using:

FindFile(x => x.Extension == ".sln")

This returns the first .sln file alphabetically, which on Windows CI picks ModularPipelines.Analyzers.sln. Running dotnet list package on this solution intermittently fails with exit code -1.

Solution

Explicitly target the main solution file:

FindFile(x => x.Name == "ModularPipelines.sln")

Test plan

• Build succeeds
• Windows CI passes consistently

🤖 Generated with Claude Code

[thomhurst]

Summary

Fixes flaky test by explicitly targeting the main solution file instead of relying on alphabetical ordering.

Critical Issues

None found ✅

Analysis

The change is straightforward and correct:

Problem identified: The code was using FindFile(x => x.Extension == ".sln") which returns the first match alphabetically. In the repository root, there are three .sln files:

• ModularPipelines.Analyzers.sln (first alphabetically)
• ModularPipelines.Examples.sln
• ModularPipelines.sln (main solution)

On Windows CI, this non-deterministic behavior picked ModularPipelines.Analyzers.sln, causing dotnet list package to fail intermittently.

Solution: Changed to FindFile(x => x.Name == "ModularPipelines.sln") which explicitly targets the main solution file, consistent with CLAUDE.md's documentation (line 10).

Verification:

• ✅ The fix is minimal and targeted - only changes the problematic line
• ✅ Comment clearly explains the issue for future maintainers
• ✅ ModularPipelines.sln is documented as the main solution in CLAUDE.md
• ✅ No security, performance, or architectural concerns
• ✅ Change aligns with the test's intent (testing dotnet list package on the main solution)

Verdict

✅ APPROVE - No critical issues