Checks an incident and its follow-up: evidence, guards, and owned actions. Use it for this input: incident. Report each check as PASS, FAIL, or N/A with file:line evidence. A FAIL carries the card's severity. Any blockFAIL means request changes. A should-fix or discussFAIL goes in the review but does not block.
An incident review also checks the stable cards of the level where the cause lived: change for a bad release or migration, function, module, service, or system for code and design, and production for rollout, alerting, and capacity. Quote the incident text as evidence in place of file:line. Those FAIL and PASS lines are real verdicts, and any blockFAIL still means request changes.
An example:
FAIL [block] chg-expand-contract - postmortem, Cause: "the deploy renamed the column and dropped the old one in one migration"
PASS inc-perf-fix-has-profile-evidence - postmortem, Fix: "CPU profile: 61% in json.Marshal; after the fix, p99 1.9 s -> 240 ms under the same load"
FAIL [block] chg-expand-contract - src/a.py:42 - renames the column and drops the old one in one migration
FAIL [should-fix] chg-one-concern - src/b.py:7 - a logging rewrite rides along with the bug fix
PASS chg-breaking-change-taxonomy - src/c.py:15 - no signature or return shape changes
N/A chg-perf-claim-evidence - the description makes no performance claim
Checklist
CardSeverityConcernsRule
inc-perf-fix-has-profile-evidenceshould-fixperformancetestingTie the performance fix to evidence that names the bottleneck: a profile, a trace, or a USE check.
inc-rollback-path-testedshould-fixreliabilityExercise each mitigation that a runbook names (rollback, failover, flag off) on a regular schedule.
What the badges mean
blockmust be fixed before merge or release.
should-fixfix it, but it need not block.
discussraise it and decide together.
stablevetted; use for verdicts.
draftnot vetted; do not use for a verdict.
Tool gate: what a linter or CI check could enforce instead of a reviewer.
Filters
Concerns
Topic tags
Topics
Cards
inc-perf-fix-has-profile-evidence
should-fixstableperformancetesting
Applies when: An incident or a slowdown is closed by a code or config change meant to make it faster.
Rule. Tie the performance fix to evidence that names the bottleneck: a profile, a trace, or a USE check.
Why. A guessed fix often speeds up code that was not slow, and the incident comes back. The profile that found the bottleneck is also the cheapest proof that the fix removed it, so take the same measurement again after the fix, under the same load (chg-perf-claim-evidence).
FAIL
postmortem: "latency spike; increased pod memory and added a cache"
no profile, no trace, nothing that names where the time went
PASS
CPU profile: 61% in json.Marshal on /export (flame graph linked)
fix: stream the response; after: p99 1.9 s -> 240 ms, same load replay
Counterpoint. "In an outage we mitigate first." Yes. Rolling back or adding capacity to stop the bleeding needs no profile. The rule covers the fix that closes the incident, which comes after the system is stable. Capacity kept as that fix, with no profile behind it, hides a code problem rather than removing it.
Applies when: A runbook or incident response relies on rollback, failover, or a manual mitigation.
Rule. Exercise each mitigation that a runbook names (rollback, failover, flag off) on a regular schedule.
Why. Rollbacks fail on schema changes or removed artifacts, backups stop running without anyone noticing, and untested failover paths rot. People who rarely use a rollback tool hesitate to use it in an incident. The runbook should also say who may trigger each mitigation, so nobody waits for permission during the outage.
FAIL
Runbook: "roll back to previous version" (last attempted: never; migration not reversible)
PASS
Runbook: rollback drilled monthly, last run 2026-10-01; schema is expand-only; on-call may trigger.
Counterpoint. "Drills are costly." Start with the mitigations an incident would need first, and drill again when a migration or release process changes. A drill is cheaper than finding out during an outage that the rollback is impossible.
A draft card is not vetted. Read it for ideas, but do not use it for a verdict.
inc-perf-regression-guard
should-fixdraftperformancetesting
Applies when: A postmortem covers a performance regression or a resource-exhaustion incident.
Rule. Add an automated check that would have caught the regression (a benchmark, a budget, a load-test threshold, or a resource guard) as one of the postmortem's actions.
Why. A fix without a guard leaves the next change free to bring the regression back, and performance regressions arrive silently. The guard turns what the incident taught into a check that runs on every change.
FAIL
action items: "be careful with regex in WAF rules"; "review perf more closely"
PASS
action: CI benchmark per WAF rule, fails above 1 ms per request (owner: WAF team, due 2026-11-15)
action: CPU guard aborts a rule over its budget in production
Counterpoint. "Some regressions can't be reproduced in a test." Then guard the symptom in production: an alert on the resource, or a limit that stops runaway work. A "be careful" action is not a guard. inc-postmortem-owned-actions asks for an owner on every action, and this card says what a performance action looks like.
Applies when: A postmortem or incident review is written or audited.
Rule. Give every postmortem action one named owner, a due date, and a tracker link.
Why. Actions without owners are wishes. A list that only adds alerts leaves the failure mechanism in place, so actions should also address a cause, not just detection.
FAIL
Actions: improve monitoring; be more careful with deploys.
PASS
A1 (owner: db-team, due 2026-11-15, ISSUE-412): add lock_timeout to migration template
Counterpoint. "Blameless means no names." Blameless is about cause, not ownership. An owner is a task assignee, not a culprit.
Tool gate: Template that requires owner and due date per action.