didericis
d89d389bef
Surface the metric ADR 0004 says matters — the critical security/logic core, currently 95% — as a README badge, distinct from the informational global `coverage` badge. - scripts/critical-modules.txt: single source of truth for the core module list. scripts/coverage.sh now reads it (instead of a hardcoded string) and update-badges.yml reads the same file, so the badge and the `critical` report cannot drift. - update-badges.yml: a `core coverage` step reuses the unit-coverage data (every core module is unit-tested, so unit-only is accurate for it) and sed-updates the new badge, like the existing ones. - README: `core coverage 95%` badge linking to ADR 0004 so a reader can find out what "core" means. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NkwFXLFff9PYPy4wgVBJp9
Docs
How this project records what it builds and why — and a guide to picking the right document for what you're capturing.
When to write which document
| Artifact | For |
|---|---|
PRD (docs/prds/) |
A feature: what to build, scope, success criteria. |
Research note (docs/research/) |
A landscape/tradeoff investigation. |
Decision record (docs/decisions/) |
A decision that isn't itself a feature — a policy, a convention, a "we will / won't do this," or a load-bearing choice made inside a larger PRD that deserves to be discoverable on its own. |
A decision that's fully specified by a PRD doesn't need duplicating in a decision record. Write one when the decision would otherwise be buried in prose, lost in an issue thread, or have no in-repo home at all (small requests that don't merit a PRD; non-feature choices like merge strategy or a trust posture).