feat(directives): scavenge sweep 4/5 (tracks + commands + styleguides + todos): 18 batch-4 directives + concurrent worker batches

2026-07-04 02:00:42 -04:00
parent e8d3578f2e
commit 79124774ec
82 changed files with 2430 additions and 0 deletions
@@ -0,0 +1,10 @@
+# timeline_is_immutable
+
+## v1
+
+**Why this iteration:** Lifted from `conductor/tier2/agents/tier2-autonomous.md:92-115` — the "TIMELINE-IS-IMMUTABLE PRINCIPLE" section (added 2026-06-27 after the `cruft_elimination_20260627` track corruption). When an agent fucks up a commit, the right answer is a forward commit with a clear message; `git revert`/`git reset`/`git stash` make the user's review harder, not easier, and stashing throws away the user's in-progress edits silently.
+**Source:** `conductor/tier2/agents/tier2-autonomous.md:92-115`
+
+---
+
+**Lifted:** 2026-07-03 scavenge sweep batch 4/5: tracks + commands + styleguides + todos
@@ -0,0 +1,37 @@
+# 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.