Why this matters
Traceability ties changes to requirements and makes auditing simpler.
Reference at least one tracking ID (e.g., JIRA/GitHub issue) in the PR description using a consistent format (e.g., 'Refs: ABC-123').
Traceability ties changes to requirements and makes auditing simpler.
Side-by-side examples engineers can pattern-match during review.
No linked issues.Refs: PAY-742
Closes: GH-1189Implements new thingRefs: OPS-22; Closes: #4512From the same buckets as this rule.
If the PR claims to fix a specific issue (e.g., 'Fixes #123' / 'Fix PAY-123'), validate it against the real production error. - If an observability MCP is available (Sentry/Datadog/Bugsnag): fetch the event/stack trace and confirm the change addresses the root cause. - Require a regression test (or a clearly documented reason why a test cannot be added). Call out fixes that only hide symptoms (catch-and-ignore, broader retries, defaulting values) without removing the underlying failure mode.