Why this matters
Visual evidence clarifies intent and reduces UI regressions.
When altering UI, include before/after screenshots or a short clip demonstrating the change, and note responsive states and accessibility impacts.
Visual evidence clarifies intent and reduces UI regressions.
Side-by-side examples engineers can pattern-match during review.
No visuals for layout overhaul.Screenshots: desktop/mobile before vs after; notes: contrast + keyboard nav unaffected.Changed styles; no screenshotsBefore/after images + notesFrom 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.