# The git timeline is immutable — when you fuck up, write a forward commit that fixes the mistake, NEVER `git revert` / `git reset --hard` / `git stash` to "undo" the past

## What it says

When an agent makes a wrong commit, breaks a file, or takes a bad path, the FIRST instinct is to "undo" with `git revert`, `git reset`, or `git stash`. THIS INSTINCT IS WRONG. The git history is IMMUTABLE on this branch. Every commit is part of the record.

## The rule

- **The right pattern:** write a NEW commit that fixes the problem. The commit message briefly says what was wrong and what you fixed.
- **The wrong pattern:** `git revert <sha>` to undo a commit, `git reset --hard <sha>` to throw away a bad commit, `git stash` to "save" uncommitted work (it just disappears when you lose the branch), or `git checkout <old-sha> -- .` to "go back to when things were good" (and then commit on top).

## Why

1. **The user's review is harder, not easier, with rewrites.** When you `git revert` a bad commit, the user has to read the diff between the bad and the "fix" to understand what went wrong. The bad commit's diff is invisible to the user; the revert commit looks like a clean undo.
2. **The user's CI / reviews / git log will all show both commits.** With a forward commit, the user sees: "bad commit did X" and "fix commit reverted X and did Y instead." The story is complete; the audit trail is honest.
3. **Stashing throws away the user's in-progress edits silently.** If you stash when the user has uncommitted edits in the working tree, the stash drops them on the next session boundary. The user loses work without knowing.
4. **The timeline is the truth.** If a bad commit introduced data corruption, the user can `git revert` it during their review — that's the user's choice, not yours.

## The concrete pattern when you fuck up

1. **Pause.** Read the actual file. Confirm the state.
2. **Write a NEW commit** that fixes the problem. The commit message should briefly say what was wrong and what you fixed.
3. **If you need to recover an old version of a file** (because the bad commit destroyed it), use `git show <good-sha>:<path> > <path>` to extract it. The bad commit is still in history; you're just reading from history to recover.

## The forbidden commands

- `git revert <sha>` (any form) — BANNED
- `git reset --hard <sha>` (any form) — BANNED
- `git reset --soft <sha>` (any form) — BANNED
- `git stash`, `git stash pop`, `git stash apply`, `git stash drop`, `git stash clear` (any form) — BANNED
- `git checkout <sha> -- <file>` — allowed ONLY for file extraction from history; `git checkout <branch>` to switch is BANNED

If you think you need a stash, you don't — use a NEW BRANCH or a WORKTREE instead.

## Concrete example

If commit N introduced a bug, write commit N+1 that fixes the bug. The user can see both commits in the diff and understand the full story. The user's CI / reviews / git log will all show both commits, which is what they want.