manual_slop/conductor/directives/timeline_is_immutable/v1.md

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.