LowFile-scope

Document measurable acceptance criteria

Include clear, testable success metrics or SLOs in ADRs (e.g., p95 latency < 120ms, error rate < 0.1%) under a 'Measures of Success' section.

Why this matters

Explicit metrics connect architecture to outcomes and enable verification.

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

Avoid

Decision: 'Make it faster' (no metric).

Prefer

Measures of Success: p95 < 120ms; cache hit ratio > 80%; cost < $X/month.

Good

## Measures of Success
p95 < 120ms

Bad

## Measures of Success
TBD

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