Backend (dotnet) is live. Source: the SonarCloud API (measures/search_history), read with an organisation read token, collected by scripts/collect_sonar_coverage.py. The figure is line coverage — Sonar's coverage equals line_coverage exactly on every one of these projects because no branch coverage is computed, so it is labelled line coverage rather than the more flattering unqualified "coverage".

Counting rule: one figure per service, taken from its most recent Sonar analysis; the repo maps to its Sonar project by key (meridian_<repo>), with mapping exceptions recorded in definitions.json. Trend is the last analysis in each ISO week over a 26-week window — deliberately longer than this tab's 12 weeks, because coverage moves slowly enough that a 12-week line would be flat and say nothing. History reaches back to each project's first analysis (Nov 2023 for the oldest). 14 of 18 mapped services report a figure; median 89.2%.

A trend line is drawn only where the window actually moved. If the 26-week range is 2 percentage points or less the service shows the number alone with a muted "stable" note; above 2 points it gets the sparkline. Ink goes where attention should go — the same convention as grey-equals-healthy on the status grid — and a flat sparkline costs a reader a glance to learn nothing. The range is on hover either way. Currently 6 services move, 8 are stable.

Absent-report points are excluded from the trend, not plotted as zeros. A 0.0% analysis carrying no test-execution data, sitting *between* reporting analyses in a service that otherwise reports, is a failed upload rather than a measured zero — the same reasoning applied to core-api below. Three such runs on media-service (12, 19 and 20 July) would otherwise have drawn a 90-point cliff to zero across an honest 2.2-point drift. Leading zeros are kept: a service that genuinely had no tests yet really was at 0%. Any dropped point is named in the build log, never discarded silently.

Unreported is a state, never 0%. A service whose Sonar analysis uploads no coverage report shows an explicit "unreported" chip — hatched, and labelled in words — never a zero and never an empty cell.

The core-api monolith is unreported by deliberate choice, not a broken pipeline: coverage reporting is intentionally not enabled on it because of the size of the repo (per Sam, 2026-07-29). Its analysis runs, so it reads exactly 0.0% across all 36 analyses since Aug 2024 with all 72,297 lines counted uncovered and no test-execution data — an absent report, not an untested codebase. Publishing that as a score would be false. Also unreported: orgs-backend (last analysed 2022), graphql-gateway (analysed, never a coverage metric), unified-search (project exists, never analysed).

authorization maps to the authorization_relationship-manager Sonar project and reports 89.3%. The mapping is confirmed by Sam on 2026-07-29 and carries no caveat marker. Note the hyphen before "manager": the all-underscore spelling of that key does not exist in Sonar.

Frontend is still not shown. Vitest computes coverage in CI but nothing persists it yet. Priya's team is choosing between the ep-reporting-code-coverage-fe S3 bucket (raw Istanbul JSON per run; preferred, because it keeps history) and a GitHub Actions step-summary route. Neither needs a pipeline change. Until one is wired up, frontend repos read "not sourced" — which is not the same as untested.