Bug: coverage-aggregation-double-counts-method-rows

[drmoisan]

• Work Mode: full-bug

Summary

The coverage aggregation method pinned in atomic plans double-counts method rows when it sums
Cobertura output, so reported first-party coverage is inflated. On issue 809's delivery the plan's
artifacts reported 79.38% first-party branch coverage; recomputing the same run de-duplicated gives
77.03%. The method is reused by other plans, so every gate that depends on it reads high.

Environment

• OS/version: Windows 11 Pro 10.0.26200, .NET Framework 4.8
• Python version: not applicable
• Command/flags used: the repository coverage route (dotnet-coverage), Cobertura output consumed by
  the aggregation step written into atomic plans
• Data source or fixture: the raw Cobertura report from issue 809's final QA gate run

Steps to Reproduce

1. Run the repository coverage route to produce a Cobertura report.
2. Aggregate first-party branch coverage using the method pinned in a current atomic plan.
3. Recompute the same figure de-duplicating method rows before summing.
4. Compare: the two disagree, with the pinned method reporting the higher value.

Expected Behavior

A coverage figure quoted in a QA gate equals the figure a de-duplicated recomputation from the same
raw Cobertura report produces. Two methods over one report do not give two answers.

Actual Behavior

The pinned aggregation counts method rows more than once. Measured on issue 809: 79.38% reported
versus 77.03% recomputed, a 2.35 point overstatement on first-party branch coverage.

Both figures clear the 75% branch threshold, so no verdict changed on 809 and the merge was not
affected. The defect is that the counting method is wrong and is copied forward into other plans,
where a smaller true margin would not survive the same overstatement.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: the recomputation was performed by the feature reviewer for issue 809 from the raw
  Cobertura report committed under that item's evidence/qa-gates/ tree.

Impact / Severity

• Blocker
• High
• Medium
• Low

High because it silently corrupts a quality gate across many future plans rather than affecting one
item. A gate that reports a number nobody can reproduce provides no assurance, and the error is in
the optimistic direction, so it fails to stop the cases it exists to stop.

Source

From: docs/features/potential/2026-09-08-coverage-aggregation-double-counts-method-rows.md

[drmoisan]

A second, distinct coverage-measurement defect surfaced on item 812 of run bugs-2026-09-06 and belongs with this one.

The merged Cobertura report carries a constant placeholder branch-rate, so the C# branch-coverage threshold is currently unevaluable — the number the gate reads is not a measurement.

This is separate from the double-counting defect in the issue body, and separate again from the language-classification defect that leaves the line gate's language set empty. Three independent faults, all in the same direction:

1. the aggregation method double-counts method rows (this issue);
2. the merged report's branch-rate is a constant placeholder, so the branch threshold cannot be evaluated;
3. the PR-context generator classifies .cs and .csproj as documentation, so the line gate computes an empty language set and passes vacuously.

Taken together, no C# coverage gate enforced anything across the eight items of run bugs-2026-09-06. Repository line coverage currently sits at 84.63%, which is what a set of gates in this state would let through.

Fault 3 is push-down-owned and is recorded upstream in drm-copilot rather than here. Fault 2 is recorded here because it shares this issue's blast radius: whatever change corrects the aggregation should establish, in the same pass, that the branch-rate it reads is a real measurement.

Source: child-reported advisory finding in the #818 audit artifacts, not independently re-derived.