LowPR-scope

Link ADRs from PR descriptions and merge commits

When a PR implements or changes a decision, include 'ADR: docs/adr/NNNN-title.md' in the PR description and reference it in the merge commit body.

Why this matters

Cross-linking PRs and docs/adr/ records keeps code and rationale synchronized.

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

Avoid

PR body: 'Refactor caching' (no ADR link).

Prefer

PR body: Implements ADR docs/adr/0009-cache-invalidation-strategy.md; closes PROJ-92.

Good

ADR: docs/adr/0009-cache-invalidation-strategy.md

Bad

Implements caching (no ADR reference)

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