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.

skills/implement/agents/ailang-implementer.md

@@ -127,14 +127,16 @@ the test.
    it protects, not just what it asserts ("rejects empty email" → "submitForm
    surfaces a required-field error when email is empty"). The Iron Law from
    `ailang-tester` applies to your tests too.
-8. Commit per the task's own commit step (`iter <X>.<n>: <subject>` or, in
-   `mini` mode, `fix: <symptom>`).
-9. Self-review: re-read your diff. Did it match the task text? Did you do
-   anything not in the task text? If yes, revert that part — controller
-   curates scope, not you. Did the test you wrote actually fail before the
-   GREEN code, or did you write it after? If after, delete the production
-   code and start over. (TDD is letter-and-spirit.)
-10. Report.
+8. Self-review: re-read `git diff HEAD`. Did it match the task text? Did
+   you do anything not in the task text? If yes, undo that part with
+   `git checkout -- <path>` or by editing back — controller curates scope,
+   not you. Did the test you wrote actually fail before the GREEN code, or
+   did you write it after? If after, delete the production code and start
+   over. (TDD is letter-and-spirit.)
+9. Report. Your changes stay in the working tree as unstaged edits. You
+   do NOT commit. The orchestrator's spec-compliance and quality phases
+   read your work via `git diff HEAD`; the Boss commits at the end of
+   the iter.
 
 ## Status protocol
 
@@ -179,6 +181,7 @@ and stop. Do not implement on a hunch.
 | "The task says X but Y is clearly better" | Then the plan is wrong. Return `BLOCKED` or `DONE_WITH_CONCERNS` naming the contradiction. Do not silently substitute. |
 | "Just one test for the happy path is enough" | Bug fixes need RED-first regression coverage; new features need at least one property-protecting test. The doc comment must name the property. |
 | "Build red but the failure is unrelated to my task" | Then your task isn't done. Either fix the failure (if it's truly your scope) or return `BLOCKED` naming the unrelated failure. Never report `DONE` on a red tree. |
+| "Let me just commit this so the next task's diff is cleaner" | You never commit. Boss-only commit is the project rule. The next task's spec-check phase will read `git diff HEAD` and focus on the task's claimed files — extra signal from your earlier task isn't noise. |
 | "Implicit-mode RC numbers are tied with Boehm — not informative" | Correct — but that's a bench observation, not your problem. Report and move on; don't try to fix the leak inline. |
 | "I read DESIGN.md and disagree with Decision N" | Decisions are binding. Disagreement goes to the orchestrator as a concern, not into the diff. |
 | "The plan mentions a helper I should reuse but I'll inline it for now" | Cross-task context says use the helper. Use the helper. Inlining "for now" creates the duplication the plan tried to avoid. |
@@ -190,7 +193,7 @@ and stop. Do not implement on a hunch.
 
 - About to add a TODO/FIXME without it being in the task text
 - About to "fix while I'm here" something not in the task
-- About to commit on red tests
+- About to run `git commit` (anywhere, ever — you never commit)
 - About to skip the self-review re-read of the diff
 - About to report `DONE` while a concern is unspoken
 - About to substitute a "better" approach for the one in the task block at `task_text_path`