Standard: README Badges

Every repo's README opens with a status badge block — as many applicable badges as the project supports, so the repo's health, release, security posture, and links are legible at a glance. Badges aren't decoration: each one is a live signal (CI state, coverage, Scorecard, quality gate) that also nudges the project to actually wire up the service behind it.

Canonical, project-agnostic standard (the version other repos copy). Copy-paste block: templates/README-badges.md. Several badges front the same services as supply-chain-hardening (Scorecard) and dependencies (CI/coverage).

The rule

Show as many applicable badges as possible, grouped in rows, all in the same style (?style=flat-square). "Applicable" is the only filter: a badge whose backing service the project genuinely doesn't use is dropped, not faked — a library with no deploy has no Netlify badge; a non-npm repo uses github/v/tag instead of package-json/v. Every badge that can apply, does.

The canonical set (grouped)

Link each badge to the thing it reports (the Actions tab, the Codecov project, the releases page, the LICENSE), so a click goes somewhere useful. The docs badge always points at the project's page on the shared domain, https://fairyfox.io/<key>/, tying the repo back into the mesh.

Applicability notes

• Version — npm repo → github/package-json/v (set filename= for a monorepo sub-package); otherwise → github/v/tag.
• Coverage / quality gate / code quality — only once Codecov / SonarCloud / CodeFactor are actually wired; don't show a badge that will render "unknown" forever.
• Netlify — only for a Netlify-deployed app; a static Pages project can skip it or show a Pages deploy badge.
• Scorecard — public repos only (the Scorecard action + API are free for public repos).

Verify (is it being followed?)

The per-standard slice the compliance audit aggregates — report done/partial/missing: