Default to LF line endings, and add a local SonarCloud reproduction

[matt-edmondson]

Closes #89. Addresses #88 — with one acceptance criterion I could not meet; see below.

#89 — LF becomes the default line terminator [major]

CodeBlocker writes through IndentedTextWriter, which terminates lines with Environment.NewLine. That made the same calls produce different bytes on different machines. Generated code is almost always committed, diffed, or compared against a golden file, and every one of those wants reproducibility more than it wants the local convention — so the deterministic terminator is the better default, and the old one is the thing worth opting into.

• CodeBlocker.DefaultNewLineString is NewLines.Lf, used by every constructor and factory overload that does not take a terminator, and substituted for a null one.
• NewLines.Host is unchanged and still reachable: CodeBlocker.Create(CodeBlocker.DefaultIndentString, NewLines.Host).
• Tagged [major]: anyone on Windows relying on the old default gets different bytes out.

The test suite was asserting the bug into place. Every expectation was written against Environment.NewLine, which on a Linux runner is LF — so the suite would have gone green on this change while Windows silently broke. All of them now assert against CodeBlocker.DefaultNewLineString, and NewLineTests gained explicit coverage that the default is LF regardless of host and that the host terminator is still available by asking for it.

README.md is reworded to match: NewLines.Host is presented as the opt-in rather than the default, the samples drop the now-redundant explicit NewLines.Lf argument, and the API reference gains a Constants table.

#88 — local SonarCloud reproduction [patch]

CI runs the Sonar analyzers via the SonarCloud scanner; a plain dotnet build does not, so findings only surface after a push and the bot comment links to a dashboard rather than naming them. .sonarlint/ wires the same analyzers into a local build, imported by nothing and pointed at explicitly:

dotnet build -p:CustomAfterMicrosoftCommonProps=$PWD/.sonarlint/sonar-local.props

After, not Before. Every project here declares its SDK with <Sdk Name="..." /> elements rather than the <Project Sdk="..."> attribute, and CustomBeforeMicrosoftCommonProps does not reach that form — which is exactly why the equivalent setup in ktsu.Semantics only ever reached one of its projects. That repo's CLAUDE.md records the limitation but not the fix.

This is what identified #87's three findings (two S3267, one S3878) and let them be fixed before the next push.

Criterion not met

Its output matches what SonarCloud reports for the same commit — including the outstanding issue from #87.

I can't confirm this. sonarcloud.io is unreachable from this sandbox (the proxy returns 403 on CONNECT), so there's no dashboard read to calibrate against, and the one unidentified finding from #87 is still unidentified. What's here is the Semantics globalconfig with S1481 left enabled and S3267/S2699 raised because CI named them on #87 — a starting point, not a verified match. The gap is recorded in both sonar-local.globalconfig and CLAUDE.md so it doesn't read as calibrated when it isn't. Leave #88 open for whoever has dashboard access to close it.

Also

CLAUDE.md picks up the architecture refresh the merged work left it owing: the TextWriter constructors, the other scopes, the preamble helpers, the template object model, and the WriteLineNoTabs pending-tab trap. It also now states the line-ending rule for tests, which is the thing that would have caught the false green above.

Verification

• 168/168 tests pass in Release.
• The local Sonar run over the branch reports S4144 and S2699 only in test files byte-identical to main — nothing new from this change.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
85.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud