# Fixing your own mistakes is always top priority

When an error, mistake, bad merge, regression, broken test, or policy violation is identified in your work:
- **Remediating it is the absolute top priority** --- it supersedes all feature development, new issue pickup, and backlog progression.
- **Act immediately**: Revert the bad merge (see [revert-premature-merge.md](revert-premature-merge.md)), fix the regression, or resolve the failure before proceeding with any other work.
  The revert is the default and not the rule: where reverting would restore a defect the merge closed, that fragment's "A revert is the default, not the rule" section fixes forward instead, and re-files every open finding as an issue against `main`.
- **Next top priority: prevent recurrence mechanically**: Immediately after reverting or fixing the mistake, the unconditional next priority is creating or repairing a mechanical system (a harness hook, automated CI check, linter rule, or deterministic test) to ensure that mistake can never be made again (see [`no-mistake-without-a-hook.py`](../../hooks/no-mistake-without-a-hook.py), [`memories/preferences.md`](../../memories/preferences.md), and [no-empty-promises.md](no-empty-promises.md)).
- **Never make empty promises**: Do not substitute verbal assurances or apologies for mechanical gates and concrete fixes (see [no-empty-promises.md](no-empty-promises.md)).
- **Treat user profanity as an urgent defect alert**: Profanity or exasperation from the user signals an urgent failure to diagnose and remediate immediately without tone policing or canned apologies (see [user-profanity-signal.md](user-profanity-signal.md)).

## Undo it yourself, the moment you notice it

The bullets above govern a mistake someone else identifies in your work, and
say to act immediately.
They do not cover the narrower case where the mistake is one you made, you
are the one who noticed, and undoing it is a single call you already hold.
That case has its own failure, and it wears the vocabulary of care rather
than of avoidance.

The near-miss is **offering** to undo it.
"I created this blocker; shall I withdraw it?" reads as deference, costs the
user a turn, and leaves the blocker standing in the meantime --- which is
the cop-out offer
[`no-cop-out-offers`](no-cop-out-offers.md) already rules out, arriving by a
route that rule's own examples do not name, since those are about work you
were asked to do rather than about damage you caused.
Undoing your own erroneous action is repair.
It needs no permission, because the action it reverses never had any.

The second failure is subtler and is what made the offer feel principled.
A mistake that shows up as a red gate invites a rule against tuning the
instrument to agree with you ---
[`fully-clean`](fully-clean.md) states exactly that, and it is correct about
a gate you failed honestly.
It says nothing about a gate you tripped by your own error, where removing
your own input restores the reading the instrument would have produced had
you never acted.
Read the two apart by asking what changes: silencing a true finding is
tuning, and withdrawing your own false input is repair.

The third is reaching the right answer and stopping there.
Telling the user you were wrong is not the fix, and a correction offered in
prose while the artifact still carries the error leaves them to do the
undoing.

- **Do:** reverse your own erroneous action in the turn you notice it, then
  report it in the past tense.
- **Do:** name what you undid and what it unblocked, so the reversal is
  checkable rather than merely asserted.
- **Don't:** ask whether to undo something you should not have done.
- **Don't:** cite an anti-gaming rule to justify leaving your own error in
  place --- withdrawing a false input you supplied is not tuning the
  instrument.
- **Don't:** treat admitting the mistake as having fixed it.

(Directive from the user, 2026-09-19: "cai: always fix your own mistakes as
soon as you notice them".
It followed a thread that requested a human review on its own PR against
this corpus's own rule to request human review only after an AI verdict or a
deadlock, then reported that request as the blocker holding the PR and asked
permission to withdraw it.
One API call removed it.

Name the PR whenever an entry like this one cites an interval, because an
unnamed incident sends a later reader to whichever PR looks closest and the
figure then refutes itself against the wrong timeline.
Measured on [ai-config#3778](https://github.com/Morrison-Lab/ai-config/pull/3778):
first commit `98ecdde2` at 2026-09-18T18:47:10Z, first `review_requested`
at 2026-09-18T18:48:11Z, 61 seconds later and 9 seconds after the PR itself
was opened.
The request was re-added and removed twice more before the last
`review_request_removed` at 2026-09-20T00:09:17Z, so the single call cleared
the standing request rather than the whole sequence.)