What
Both sidecar packages now pass the coverage gate on the ratchet's 1pp tolerance rather than by meeting the stored threshold:
| Package |
Stored |
Effective |
Actual |
sharplsp-sidecar-csharp |
95% |
94% |
94.69% |
sharplsp-sidecar-fsharp |
95% |
94% |
~94.45% |
The stored thresholds were not lowered — check-coverage.mjs hard-fails if a committed threshold ever decreases, and it only ratchets upward. But actual coverage did fall below 95%, so the gate is green while the historical bar is not met.
Why it dropped
The restructure branch added roughly 2,700 lines of new C# sidecar code and ~560 lines of new F# rename/code-action code whose only tests ran through the VS Code extension host. Those tests exercise the code but generate no sidecar coverage, so from the gate's perspective the new code was untested. PR #200 closed most of the gap by driving the same paths directly through the sidecar suites, but not all of it.
What's left
C# needs roughly 16 more covered lines to reach 95%. Largest remaining gaps, all reachable in principle:
AnalyzerDiagnosticResolver.cs — error/edge branchesHeadlessOverrideSyntax.cs — ToInitAccessor is defensive: Roslyn's generator already emits init directly, so the set-to-init conversion never fires in practiceHeadlessOverrideCodeAction.cs, CodeActionResolver.cs, WorkspaceManager.cs
Note that raising the stored threshold requires actual > 96%, since the ratchet sets the new threshold to actual - 1pp and only applies it when that exceeds the current value.
Not a regression in the gate
Worth recording for whoever picks this up: the same branch also changed .NET coverage measurement from max-of-reports to union-of-reports (tools/coverage/merge-cobertura.cs). Union is the correct measurement — max-of-reports systematically undercounts, ignoring lines covered only by a test assembly whose report wasn't the maximum — but it is also more generous, so the pre-existing shortfall would read worse under the old algorithm, not better.
What
Both sidecar packages now pass the coverage gate on the ratchet's 1pp tolerance rather than by meeting the stored threshold:
sharplsp-sidecar-csharpsharplsp-sidecar-fsharpThe stored thresholds were not lowered —
check-coverage.mjshard-fails if a committed threshold ever decreases, and it only ratchets upward. But actual coverage did fall below 95%, so the gate is green while the historical bar is not met.Why it dropped
The restructure branch added roughly 2,700 lines of new C# sidecar code and ~560 lines of new F# rename/code-action code whose only tests ran through the VS Code extension host. Those tests exercise the code but generate no sidecar coverage, so from the gate's perspective the new code was untested. PR #200 closed most of the gap by driving the same paths directly through the sidecar suites, but not all of it.
What's left
C# needs roughly 16 more covered lines to reach 95%. Largest remaining gaps, all reachable in principle:
AnalyzerDiagnosticResolver.cs— error/edge branchesHeadlessOverrideSyntax.cs—ToInitAccessoris defensive: Roslyn's generator already emitsinitdirectly, so the set-to-init conversion never fires in practiceHeadlessOverrideCodeAction.cs,CodeActionResolver.cs,WorkspaceManager.csNote that raising the stored threshold requires actual > 96%, since the ratchet sets the new threshold to
actual - 1ppand only applies it when that exceeds the current value.Not a regression in the gate
Worth recording for whoever picks this up: the same branch also changed .NET coverage measurement from max-of-reports to union-of-reports (
tools/coverage/merge-cobertura.cs). Union is the correct measurement — max-of-reports systematically undercounts, ignoring lines covered only by a test assembly whose report wasn't the maximum — but it is also more generous, so the pre-existing shortfall would read worse under the old algorithm, not better.