LowFile-scope

Record alternatives considered and trade-offs

Add an 'Alternatives' section listing at least two plausible options with pros/cons and reasons for rejection.

Why this matters

Capturing alternatives prevents repeated debates and clarifies why the chosen path won.

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

Avoid

We chose Kafka.

Prefer

Alternatives: (1) Kafka: strong ordering, ops overhead; (2) SQS: simpler, limited ordering; Chosen: Kafka for exactly-once via transactions.

Good

## Alternatives
- Kafka
- SQS

Bad

## Alternatives
N/A

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