Coverage has drifted to 78.25% line / 69.32% branch (gate expects 85% / 75%)

[systemslibrarian]

Recording this so it is tracked rather than lost — surfaced while fixing the System.Security.Cryptography.Xml advisories in #24.

What

The Linux coverage run now completes for the first time since 2026-06-04 and reports:

line-rate=0.7825    FAIL: line coverage 78.25% < 85%
branch-rate=0.6932  FAIL: branch coverage 69.32% < 75%

#24 was merged with the gate red. That was a deliberate trade: it clears five HIGH-severity advisories from 8 published packages, and holding a security fix behind a coverage percentage is the wrong order. Main was already red before it, and is now red for a benign reason instead of a vulnerable one.

Why it went unnoticed

CI failed at restore on every main commit from 2026-06-04 onward — NU1903 treated the vulnerable System.Security.Cryptography.Xml 8.0.3 as an error, so build-and-test never reached the test step, let alone coverage. The gate has been unenforceable for two and a half months, and coverage drifted in that window with no signal.

Both Release 1.0.0 and Release 1.0.1 were cut from that red build.

This is genuine, not a measurement artifact

Checked before filing:

• coverlet.runsettings scopes collection to <Include>[PostQuantum.DataProtection]*</Include> — the core assembly only. The satellite packages (.Aws, .AzureKeyVault, .Redis, .Fips, .OpenTelemetry, .Testing) and their four test projects are not being counted against this number.
• All 108 tests ran with 0 skipped — confirmed by the new zero-skip gate. This is not skipped tests deflating the figure.

So the number reflects real coverage of the core assembly by PostQuantum.DataProtection.Tests.

Options

1. Write tests back to 85% / 75%. Correct, and the gate then means something again.
2. Re-baseline the gate to current levels with a documented ratchet-up plan. Honest, but lowers the bar.
3. Widen coverage collection to include the satellite assemblies and run all five test projects. Changes what the number measures — worth considering on its own merits, but it should not be used as a way to make this number look better.

Whichever route, the gate should end up enforceable again — an unenforceable gate is how this drifted in the first place.