iter disc.1: boss-only commits + main-as-quarantine (no branches in implement)

Two project-wide rules are now explicit across every skill:

1. Only the Boss commits. No skill agent (implementer,
   brainstormer, planner, debugger, fieldtester, docwriter,
   architect, bencher) runs `git commit`. Agents write their
   artefacts to the working tree as unstaged changes; the Boss
   inspects, decides commit shape, and commits.
2. main HEAD is sacrosanct. No actor runs `git reset` or
   `git revert` on main. Bad work stays in the working tree
   where it is still discardable via `git checkout -- <paths>`.

Implement loses the `iter/<iter_id>` branch mechanic entirely;
Phase 0 of the orchestrator-agent now does a clean-tree check
and refuses to start on a dirty tree. Per-task agent commits
are removed everywhere; reviewers operate against
`git diff HEAD` instead of `pre_task_sha..head_sha`.

Motivation: 2026-05-11 iter 23.4 stranded prep2/prep3 commits on
an iter-branch that never integrated to main, then a corrected
spec falsely claimed those commits had shipped. Branch-per-iter
+ manual-Boss-merge + iter-stacking made the strand structurally
possible. See docs/journals/2026-05-11-iter-disc.1.md for the
full per-task notes and motivation.

CLAUDE.md

@@ -77,6 +77,34 @@ See @skills/README.md for the skill + agent roster.
   outcome. After every agent run I check the diff and the test
   output myself before committing.
 
+### Commit discipline and main-branch sanctity
+
+Two project-wide rules govern who touches git history and how:
+
+- **Only the Boss (me) commits.** No skill agent — implementer,
+  brainstormer, planner, debugger, fieldtester, docwriter,
+  architect, bencher — runs `git commit`. Every agent writes its
+  output (spec, plan, code, tests, fixtures, rustdoc edits, RED
+  tests, journal files, stats, updated baselines) into the working
+  tree as unstaged changes. I inspect the result with
+  `git status` / `git diff`, decide commit shape (often one
+  cohesive iter-level commit; sometimes a few logical commits when
+  the changes genuinely cover separate concerns), and commit.
+  Per-task or per-phase commits are not a goal in themselves.
+- **main HEAD is sacrosanct.** Nobody (including me) runs
+  `git reset` or `git revert` on main. main moves forward only via
+  my commits. The consequence is the working-tree-as-quarantine
+  discipline: nothing half-baked enters main, because nothing can
+  be taken back off. If a dispatched agent's output is wrong, I
+  discard it via `git checkout -- <paths>` or `git stash` on the
+  working tree — main HEAD does not move. If something wrong does
+  land on main, the remedy is a forward-fix commit, never a rewind.
+
+These rules supersede earlier mechanics that involved per-iter
+branches and per-task agent commits. See `skills/README.md`
+"Conventions" for the same rules in skill-system form, and the
+2026-05-11 journal for the failure mode that motivated the change.
+
 ### Authority over `skills/` and the agent roster
 
 I am free to add, edit, retire, or replace skill or agent definitions
@@ -142,15 +170,17 @@ applied as a gate by `skills/brainstorm/SKILL.md` during spec writing.
 ### Direction freedom
 
 I have authority to choose the next iteration, refactor, or feature
-without asking. Wrong calls are recoverable: every commit is
-reachable via git, branches and tags exist for sharper rollback
-points (`pre-rc` is one such), and reverting one or several commits
-is cheap.
+without asking. Wrong calls are contained, not recovered: only the
+Boss commits, and only when the working-tree state is consistent —
+so bad work doesn't reach main in the first place. If a dispatched
+agent's output is wrong, the remedy is `git checkout -- <paths>` on
+the working tree (Boss-side), never a rewind of main HEAD. main is
+forward-only.
 
 The cost of asking "what should I do next" — context-switch for
-the user, latency on my side — exceeds the expected cost of an
-occasional rollback. So when the queue is non-empty and the path
-is clear, just pick and proceed.
+the user, latency on my side — exceeds the expected cost of
+discarding a bad working-tree state. So when the queue is non-empty
+and the path is clear, just pick and proceed.
 
 Bounce back to the user only when: