LowPR-scope

Maintain an ADR index

Keep docs/adr/README.md updated with a table of ADRs (number, title, status, date). Update the index in the same PR that adds/changes an ADR.

Why this matters

An index provides a single entry point for newcomers and supports audits.

Side-by-side examples engineers can pattern-match during review.

Avoid

No index; ADRs discovered by grep.

Prefer

docs/adr/README.md
| # | Title | Status | Date |
|----|-------|--------|------|
| 001 | choose-postgresql | accepted | 2025-03-12 |

Good

docs/adr/README.md (index table)

Bad

Missing docs/adr/README.md

From the same buckets as this rule.

Critical
Require an ADR for any architectural or cross-team decision
For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.
docs-adrsmodule-architecture+1
High
Call out breaking changes explicitly
If an API/contract or behavior is breaking, add a 'BREAKING CHANGE' section detailing what breaks, migration steps, and affected consumers.
pr-hygieneapi-contracts-versioning+1
High
Capture security and privacy implications
Add a 'Security & Privacy' section in ADRs addressing threat model impacts, secrets handling, data retention, and PII processing; link to relevant runbooks and DPA if applicable.
docs-adrssecurity-hardening+2