Why this matters
Prevents technical debt from being forgotten and improves accountability.
If a PR adds new TODO/FIXME comments, require a tracking ticket. Preferred formats: `TODO(ABC-123): ...` or `FIXME(ABC-123): ...`. If a ticketing MCP is available, suggest (or create) the ticket and link it in the PR. Avoid leaving untracked TODOs in mainline code.
Prevents technical debt from being forgotten and improves accountability.
Side-by-side examples engineers can pattern-match during review.
// TODO: fix this later// TODO(PAY-742): remove legacy path after rollout reaches 100%TODO with no ticket referenceTODO(TICKET-ID) with link to backlog itemFrom 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.