@lemoncode/lemony 0.3.0 → 0.4.0

package/catalog/VERSION

@@ -1 +1 @@
-0.3.0
+0.4.0

package/catalog/agents/architect.md

@@ -52,7 +52,7 @@ acceptance for `write-adr` / `playbook-iterate`. See the Orchestrator's §Closeo
    block is recorded, the decision arrives in the spawn prompt instead — don't
    stall looking for it in the entry); the changed code from the PR diff when a PR
    exists (closeout) or from the branch when none does (mid-task routes — under
-   pre-commit review ON read the **worktree**: mid-task the branch holds only
+   auto-commit OFF read the **worktree**: mid-task the branch holds only
    OK'd groups, or nothing before the first OK); or the
    request. If the codebase is unfamiliar and the
    task needs it, run `code-explorer` first.

package/catalog/agents/implementer.md

@@ -52,7 +52,7 @@ what you run, only how many calls carry it.
    already committed there.
 2. **Implement via TDD** — run the `tdd` skill: one red → green → refactor cycle per
    behavior (vertical slices, never all-tests-then-all-code). When your invocation
-   says **pre-commit review is ON**, the whole run obeys §Staging protocol (below) —
+   says **auto-commit is OFF**, the whole run obeys §Staging protocol (below) —
    zero commits, staged save-points.
    **Scope: exactly what the invocation hands you.** By default that is the whole
    `tasks.md` list (all-at-once). In **step-by-step mode** the Orchestrator
@@ -60,8 +60,8 @@ what you run, only how many calls carry it.
    group's id + header line): read that group's tasks from the spec's `tasks.md`
    yourself. On a later iteration the reference comes with reviewer or
    human-checkpoint feedback. Work the group's tasks
-   in order — one TDD cycle and small commits per task, as always (ON: staged
-   save-points per task — §Staging protocol) — then stop: do
+   in order — one TDD cycle and small commits per task, as always (auto-commit
+   OFF: staged save-points per task — §Staging protocol) — then stop: do
    **not** run ahead into the next group (the human checkpoints each group before the
    next starts), and don't re-open tasks the human already OK'd unless the feedback
    you were handed says so.
@@ -98,7 +98,7 @@ what you run, only how many calls carry it.
    lint / tests + coverage / audit + a real run); otherwise run those gates inline.
    Commit your work to the branch and **push it, best-effort** — a failed push (offline,
    auth) is a warning in your summary, never a blocker; the commits stay safe locally,
-   then return a summary to the Orchestrator. (Pre-commit review ON: no commit and
+   then return a summary to the Orchestrator. (Auto-commit OFF: no commit and
    no push — leave **everything staged** and say so in the summary; the Orchestrator
    commits at the human's OK.) The Orchestrator opens
    the PR when you signal done — you don't open it.
@@ -108,14 +108,14 @@ what you run, only how many calls carry it.
    checkpoint's "how to run it" is presented from it), and any `## Side-findings`
    block. Long-form material — reasoning, alternatives weighed, per-task notes —
    belongs in `progress.md` and the commit messages, never in the summary
-   (pre-commit review ON: in `progress.md` alone — there are no commit messages
+   (auto-commit OFF: in `progress.md` alone — there are no commit messages
    until the human OK, so it carries everything a fresh iteration will need): the
    Orchestrator carries your summary in context for the rest of the task, so every
    extra line taxes the whole run. The cap trims narrative, not signal — a blocker,
    a deviation from the spec, or a side-finding is always stated, however long the
    list.
 
-## Staging protocol (pre-commit review ON)
+## Staging protocol (auto-commit OFF)
 
 Active **only when your invocation says so** — the human chose to review the work
 **uncommitted**, so the branch must receive nothing until their OK. This inverts

package/catalog/agents/orchestrator.md

@@ -205,9 +205,9 @@ define's close (`.claude/agents/partition.md`); a parent issue carrying
    context) once with the `tdd` skill and the branch — it keeps `progress.md` live and
    signals done; **step-by-step** runs the per-group loop (§Step-by-step
    implementation) instead, and rejoins this flow at step 8 after the last group. With
-   **pre-commit review ON** (the gate's second knob), either mode runs the zero-commit
-   protocol — no commit touches the branch before a checkpoint OK (§Pre-commit review
-   ON); in all-at-once its single gate runs when the Implementer signals done,
+   **auto-commit OFF** (the gate's second knob), either mode runs the zero-commit
+   protocol — no commit touches the branch before a checkpoint OK (§Auto-commit
+   OFF); in all-at-once its single gate runs when the Implementer signals done,
    **before** step 8 — the PR never opens on uncommitted work.
 8. **Review** — flip to `harness:status:in-review` and **open the PR**
    (`gh pr create`, `harness/<id>-<slug> → <default>`, with `Closes #<id>` in the PR
@@ -319,28 +319,32 @@ applies. The mode is switchable **downward only** (step-by-step → all-at-once,
 at every checkpoint); there is no upgrade path — all-at-once has no stop where the
 switch could be offered.
 
-**The second knob, same interaction — pre-commit review.** Alongside the mode, settle
-whether the human reviews the work **uncommitted**, before anything lands on the
-branch. Read `implementation.pre_commit_review` from `harness.config.yml` first (an
-absent key means `human`): `on` / `off` **pin the answer — record it without asking**;
-`human` (the default) asks here, in the same interaction, suggesting OFF:
-
-> **Pre-commit review OFF** (default) — the Implementer commits and best-effort
-> pushes as it works, exactly as today; checkpoints present committed work per
-> the checkpoint contract.
+**The second knob, same interaction — auto-commit.** Alongside the mode, settle
+whether the agent commits automatically as it works, or the human reviews the work
+**uncommitted** before anything lands on the branch. Read
+`implementation.auto_commit` from `harness.config.yml` first (an absent key means
+`human`): `on` / `off` **pin the answer — record it without asking**; `human` (the
+default) asks here, in the same interaction. Ask the **decision, not the mechanism**:
+header **Auto-commit**, question _"Should the agent commit automatically as it
+works?"_, exactly these two options in this order — **OFF first, marked recommended** —
+with these descriptions (short and closed; do not pad them with mode arithmetic or
+your own reading of the trade-off):
+
+> **OFF (recommended)** — the agent makes **zero commits**: you review the work
+> uncommitted in the Source Control panel (and can edit it in place); the branch
+> gets its first commit on your OK. Choose this for more control.
 >
-> **Pre-commit review ON** — the Implementer makes **zero commits**: the work
-> accumulates in the worktree under a staging protocol, you review it
-> **uncommitted** (the Source Control panel shows it natively, and you can edit
-> it in place), and the branch receives its first commit only on your OK.
-
-Record it next to the mode line (`Pre-commit review: off` / `on`) — execution state,
-like the mode. The knob is **L1-only** (it rides this question; L2 always runs today's
-flow) and orthogonal to the mode: it moves **when the branch first receives commits**,
-never whether review happens. In step-by-step the uncommitted gate runs per group; in
-all-at-once it is **one gate over the entire implementation** (its single "group" is
-the whole `tasks.md`). ON's mechanics — staging save-points, full deferral,
-watch-fors — live in §Pre-commit review ON.
+> **ON** — the agent commits and pushes as it works; checkpoints present
+> committed work. Choose this to be interrupted less (in step-by-step it avoids
+> one dirty-tree review per group).
+
+Record it next to the mode line (`Auto-commit: off` / `on`) — execution state, like
+the mode. The knob is **L1-only** (it rides this question; L2 always runs the
+commit-as-you-go flow) and orthogonal to the mode: it moves **when the branch first
+receives commits**, never whether review happens. In step-by-step the uncommitted
+gate runs per group; in all-at-once it is **one gate over the entire implementation**
+(its single "group" is the whole `tasks.md`). Auto-commit OFF's mechanics — staging
+save-points, full deferral, watch-fors — live in §Auto-commit OFF.
 
 ## Step-by-step implementation (the per-group loop)
 
@@ -362,7 +366,7 @@ numbers still never shift. For each group, in order:
    task-state paths, and the group's id + header line in `tasks.md` — by reference
    (§Sub-agent invocation), it reads the group's tasks from the file itself (`tdd`
    skill — checkbox by checkbox with small commits, as always). It commits to the
-   branch (pre-commit review ON: it **stages** instead of committing — point the
+   branch (auto-commit OFF: it **stages** instead of committing — point the
    invocation at the staging protocol in `implementer.md`), logs to `progress.md`,
    and signals done. **No PR yet** — the PR opens after the last group,
    as in all-at-once; the human inspects and runs the **local checkout** (a checkpoint
@@ -372,7 +376,8 @@ numbers still never shift. For each group, in order:
    group's tasks and requirements itself — scoped to the **group's diff against its
    slice of the spec**. **Hand the group's anchor OID (step 1's step-log line) in the
    spawn prompt in both knob states** — the Reviewer self-validates its ledger
-   against it (`--anchor`); pre-commit review ON additionally hands the ON flag —
+   against it (`--anchor`); under auto-commit OFF the prompt additionally says
+   `auto-commit is OFF` —
    the diff is then the group's **uncommitted work against the anchor**,
    `git diff <anchor> -- ':(exclude).claude/state'`; worktree == index
    within that scope at review time. The
@@ -401,9 +406,10 @@ numbers still never shift. For each group, in order:
    invocation handed it, and your authoritative run catches a green built on the
    wrong anchor — that red routes like any sidecar-side red below.
 
-   **In pre-commit review OFF, run the verb on a clean tree.** The floor's owed set
-   reads the diff against the anchor _including uncommitted work_ — correct in ON,
-   where the group's work is uncommitted by design, but in OFF an uncommitted tracked
+   **In auto-commit ON, run the verb on a clean tree.** The floor's owed set
+   reads the diff against the anchor _including uncommitted work_ — correct in
+   auto-commit OFF, where the group's work is uncommitted by design, but in
+   auto-commit ON an uncommitted tracked
    edit outside `.claude/state` at validation time is a **human delta the Reviewer
    never saw**, and it would red the floor as `unaccounted-file` on a ledger that is
    not wrong. Check `git status --porcelain -- . ':(exclude).claude/state'` first; a
@@ -457,9 +463,9 @@ numbers still never shift. For each group, in order:
    the unresolved disagreement (both positions, the spec slice) instead of a clean
    step.
 
-   In pre-commit review ON, `OK` is also the moment the group's single code commit
+   In auto-commit OFF, `OK` is also the moment the group's single code commit
    lands, and `changes` sends the fresh Implementer to iterate **over the worktree**
-   — both per §Pre-commit review ON.
+   — both per §Auto-commit OFF.
 
 3. **Human checkpoint** — first run §Checkpoint contract's **spec check** (item
    4): the state commit below sweeps `spec/`, so an unconfirmed human spec edit
@@ -486,8 +492,8 @@ numbers still never shift. For each group, in order:
    A failed push — offline, auth — warns and never blocks; the next push carries
    it. This long wait is where a session likeliest dies — the push is what lets
    another machine's `/resume` see the pending checkpoint.
-   **Pre-commit review ON skips this state commit and push entirely** — until the
-   OK the branch receives _nothing_, state included (§Pre-commit review ON): update
+   **Auto-commit OFF skips this state commit and push entirely** — until the
+   OK the branch receives _nothing_, state included (§Auto-commit OFF): update
    the `progress.md` line on disk only, accepting the documented price that the
    pending checkpoint is invisible to a cold `/resume` from another machine.
    Then present the step **per §Checkpoint contract**: what was built and how to
@@ -508,7 +514,7 @@ numbers still never shift. For each group, in order:
      (`Mode: step-by-step (downgraded to all-at-once at step N)` — the gate choice
      stays first; the downgrade is a suffix, because `task_done.mode` records the gate
      choice), and run the **remaining** tasks as a single Implementer invocation
-     (all-at-once; the pre-commit review knob keeps its recorded setting).
+     (all-at-once; the auto-commit knob keeps its recorded setting).
      Checkpoint OKs already given stand.
 
    Aborting needs no protocol: the human interrupts the session; `/resume` picks the
@@ -521,11 +527,11 @@ numbers still never shift. For each group, in order:
    `-- .claude/state/tasks/<id>/` pathspec as step 3's twin so other staged
    content never rides mislabeled) + best-effort push ride as
    **one composite turn** (§Turn economy) — without that commit a cold `/resume`
-   still reads `awaiting` after the last group. Pre-commit review ON: on OK the
+   still reads `awaiting` after the last group. Auto-commit OFF: on OK the
    same composite additionally carries the group's **code commit** — the deferral
    ends here, so code commit + state commit + push + emit land together (exact
    commands, the pathspec split of the mixed index, and the all-at-once no-emit
-   rule in §Pre-commit review ON); on
+   rule in §Auto-commit OFF); on
    `changes` nothing is committed and the deferral continues. `<review-iterations>` is the number
    of Reviewer invocations that preceded this checkpoint (≥ 1; resets after a
    "changes"):
@@ -557,7 +563,7 @@ numbers still never shift. For each group, in order:
 
    Per-step Reviewer REJECTs also emit `review_rejected` as usual, with the extra
    `--step=<N>` flag (the `iteration` count stays task-global, as today; an
-   all-at-once single-group pass — pre-commit review ON's pre-gate review —
+   all-at-once single-group pass — auto-commit OFF's pre-gate review —
    omits `--step`, per the events schema).
 
 5. **`progress.md` step log** — keep the sub-state explicit so `/resume` can re-enter
@@ -593,24 +599,24 @@ checkpoint OK means "right direction and it runs", not a review waiver; the full
 wins, and the human still holds the merge gate to disagree.
 
 **Every full-pass APPROVE is ledger-validated too** — the step-8 review in either mode,
-pre-commit review ON's single-group pre-gate pass, and a re-APPROVE after the merge gate
+auto-commit OFF's single-group pre-gate pass, and a re-APPROVE after the merge gate
 or PR comments sent the PR back to review. The Reviewer writes `full-pass.json` (no step
 number → the union of every group); you run
 `lemony review-ledger validate --task-id=<id> --anchor=<merge-base> --full-pass` —
 the merge-base of the freshly fetched base and the PR head, the Diff-fingerprint's
-own OID (L1 step 8; pre-commit review ON's pre-gate pass instead anchors at the OID
+own OID (L1 step 8; auto-commit OFF's pre-gate pass instead anchors at the OID
 you recorded when its single group started) — and route a red exactly as
 in step 2 above: one fresh Reviewer retry with the lines verbatim, a second red or any
 spec-side problem to the human, and never an APPROVE relayed on a red ledger. Outside
 the step loop the transient line is `awaiting ledger retry (full pass, retry 1/1)` in
 `progress.md` (no step counter), and "the human" is the gate the pass feeds: the
-pre-commit-ON checkpoint when there is one, otherwise the merge-gate presentation,
+auto-commit-OFF checkpoint when there is one, otherwise the merge-gate presentation,
 with the verb's lines as the content.
 
 ## Checkpoint contract (how a human gate presents work)
 
 Every human checkpoint — per-group in step-by-step, and the single all-at-once gate
-when pre-commit review is ON — presents the same way. "Present the step" is a
+when auto-commit is OFF — presents the same way. "Present the step" is a
 contract, not a vibe:
 
 1. **Anchored scope.** The group's **anchor** — the branch head OID recorded when
@@ -620,10 +626,10 @@ contract, not a vibe:
    at the head after the last OK'd group) — bounds exactly what is
    under review. Present the commit list + touched-files table, then the **exact
    group diff**, always excluding task state:
-   - OFF: `git log --oneline <anchor>..HEAD` +
+   - auto-commit ON: `git log --oneline <anchor>..HEAD` +
      `git diff --stat <anchor>..HEAD -- ':(exclude).claude/state'`,
      then `git diff <anchor>..HEAD -- ':(exclude).claude/state'`;
-   - ON (nothing committed):
+   - auto-commit OFF (nothing committed):
      `git diff --stat <anchor> -- ':(exclude).claude/state'`, then
      `git diff <anchor> -- ':(exclude).claude/state'` — staged new files are in
      the index, so they appear.
@@ -631,13 +637,13 @@ contract, not a vibe:
    a difftool is configured (or an extension like GitLens is present), **offer**
    the richer side-by-side view — an ephemeral config works without touching the
    repo's (`git -c diff.tool=<tool> difftool <range>`). Never assume an extension
-   exists. In ON the Source Control panel already shows the work natively — it IS
-   uncommitted.
+   exists. In auto-commit OFF the Source Control panel already shows the work
+   natively — it IS uncommitted.
 3. **What was built and how to run it** — from the Implementer's verification line,
    as today. Checkpoint narration is the product, never overhead (§Turn economy).
 4. **The human delta — always detected, always revalidated.** Whatever the answer
-   (`ok` or `changes: …`), first detect the human's own edits — in ON, **two
-   checks with distinct routes** (every agent save-point is staged at
+   (`ok` or `changes: …`), first detect the human's own edits — in auto-commit
+   OFF, **two checks with distinct routes** (every agent save-point is staged at
    presentation time, so the staged/unstaged seam is the auto-detect):
    - **Work delta**: the unstaged section outside task state —
      `git diff -- ':(exclude).claude/state'` **plus untracked files outside
@@ -664,10 +670,10 @@ contract, not a vibe:
      recorded `**Resolution**` in `discoveries.md` is confirmed content — stage
      it, don't re-raise.
 
-   The **spec check runs in both knob states** — in OFF, run it **before** step
-   3's `awaiting` state commit, which would otherwise silently commit a
-   pre-existing spec edit before detection. OFF's work-delta detection is
-   simply any uncommitted working-tree change.
+   The **spec check runs in both knob states** — in auto-commit ON, run it
+   **before** step 3's `awaiting` state commit, which would otherwise silently
+   commit a pre-existing spec edit before detection. Auto-commit ON's work-delta
+   detection is simply any uncommitted working-tree change.
    The **work delta** then runs the pipeline: present it, confirm it is
    intended, and **re-run the suite with the delta applied** — the delta never
    inherits the group's green. **A red revalidation blocks the OK**: never run
@@ -675,15 +681,16 @@ contract, not a vibe:
    `changes` (the human decides: fix it themselves, drop the delta, or hand it
    to the Implementer). On a green revalidation the delta rides with the group:
    on OK it lands with
-   the group's work (ON: staged into the group's commit; OFF: committed as its
+   the group's work (auto-commit OFF: staged into the group's commit; auto-commit ON:
+   committed as its
    own commit — `step(<id>): step <N> human delta` — before the next group); on
    `changes` it stays in the worktree for
-   the fresh Implementer (ON: staged first as the safe starting point —
-   §Pre-commit review ON).
+   the fresh Implementer (auto-commit OFF: staged first as the safe starting point —
+   §Auto-commit OFF).
 
-## Pre-commit review ON (zero commits + staging save-points)
+## Auto-commit OFF (zero commits + staging save-points)
 
-The knob's ON state (chosen at the approval gate — §Implementation mode) moves
+The auto-commit OFF state (chosen at the approval gate — §Implementation mode) moves
 **when the branch first receives commits**; review, fix-loop routing, and the merge
 gate are unchanged. v1 is deliberately an experiment — the watch-fors below are its
 pre-registered exit signals.
@@ -716,8 +723,8 @@ pre-registered exit signals.
   line drops the step counter). Its APPROVE is ledger-validated with `--full-pass`
   and `--anchor=<oid>` — the anchor you recorded when its single group started
   (§Step-by-step implementation, after the last group), never relayed on a red.
-  Hand that pre-gate Reviewer the anchor, the ON
-  flag, and "the whole `tasks.md` as the single group" in place of a group id.
+  Hand that pre-gate Reviewer the anchor, the words `auto-commit is OFF`, and "the
+  whole `tasks.md` as the single group" in place of a group id.
   All agent work is
   staged at presentation time; present per §Checkpoint contract. The human
   inspects the work natively in the Source Control panel and edits/discards
@@ -749,7 +756,8 @@ pre-registered exit signals.
   `step(<id>): step <N> checkpoint OK`, and the `step_completed` emit rides the
   same turn (step 4). All-at-once (a downgraded remainder resolves as
   all-at-once here too): `<code-msg>` = `task(<id>): implementation`,
-  `<state-msg>` = `task(<id>): pre-commit gate OK`, and **nothing is emitted** —
+  `<state-msg>` = `task(<id>): implementation checkpoint OK`, and **nothing is
+  emitted** —
   `step_completed` is step-by-step-only (its `--step` has no meaning here, and
   closeout's mode recovery reads any `step_completed` as proof of step-by-step);
   the gate resolution reaches telemetry through `task_done` as usual. One commit

package/catalog/agents/partition.md

@@ -193,7 +193,7 @@ offer to resume it (`/resume #<k-id>`) in this session. A k already merged
     a task branch (human-gated by house rules); merge is uglier history but safe. While k
     is unmerged the source is `origin/harness/<k-id>-<k-slug>`. The merge-in is **your**
     move at a checkpoint boundary (or the Implementer's on re-invoke, named in the spawn
-    prompt), never inside a staging save-point; under pre-commit review ON it goes right
+    prompt), never inside a staging save-point; under auto-commit OFF it goes right
     after a checkpoint OK commit;
   - record it in the child's trace line (`stacked — assumes it lands as-is`) and the
     parent row (`→ #<id> spec-in-progress (stacked on #<k-id>)` — the status at opening,
@@ -243,7 +243,7 @@ mediation). On **"keep together"**: record the resolution and resume. On
 this order:
 
 1. **Ask the second half in the same mediation** — later-unit work already on the branch
-   (commits; under pre-commit review ON, staged save-points): keep it or drop it? Name
+   (commits; under auto-commit OFF, staged save-points): keep it or drop it? Name
    the commits. (A second fork that only exists because of the first answer: record it in
    the same `**Resolution**` block, no second entry.)
 2. **Create the parent** partition-plan issue with the current task as Part 1 (row
@@ -258,7 +258,7 @@ this order:
    the narrowed `tasks.md` is re-presented at the next checkpoint — no new gate.
 5. **Record and resume**: the Implementer re-invoke carries the keep/drop answer — it
    performs the `git revert`s by commit (never a force-push), or discards the staged
-   later-unit changes under pre-commit review ON — and resumes on the narrowed slice.
+   later-unit changes under auto-commit OFF — and resumes on the narrowed slice.
 
 On an **L2 (triage) task** — no PRD — "partition" means the task was mis-levelled: keep
 the triage on its first unit (you narrow its fix plan in the issue body, read-modify-write)

package/catalog/agents/reviewer.md

@@ -69,7 +69,7 @@ verbatim — the spinoff offer depends on it surviving.
 Every review of a spec-backed change that ends in an **APPROVE** writes a **ledger**: a
 JSON sidecar at `.claude/state/tasks/<id>/review-ledger/step-<N>.json` — or
 `full-pass.json` when the review has no step number (the all-at-once full pass, and
-pre-commit review ON's single-group pre-gate pass). You write the file yourself, beside
+auto-commit OFF's single-group pre-gate pass). You write the file yourself, beside
 your verdict; it is the one artifact you write besides your `progress.md` evidence
 section, and the source under review stays untouched. A REJECT owes no ledger: nothing
 is being approved, and its failing points already ride your return in full. A task with
@@ -241,7 +241,7 @@ lemony review-ledger validate --task-id=<id> --anchor=<anchor> --step=<N>
 ```
 
 (`--full-pass` in place of `--step` on a full pass.) `<anchor>` is the anchor your
-invocation handed you (per-step, and pre-commit review ON's pre-gate pass); on the PR
+invocation handed you (per-step, and auto-commit OFF's pre-gate pass); on the PR
 full pass it is the merge-base you already compute for the stale-approve record —
 `git merge-base FETCH_HEAD HEAD` after the fetch, the same OID the Diff-fingerprint
 digests from. The Orchestrator re-validates with the anchor **it** recorded, so a
@@ -257,7 +257,7 @@ The change is a PR (`harness/<id>-<slug> → default`) the Orchestrator opened;
 that PR's diff. Run your review skills in order — which ones you have depends on the
 repo's capabilities (see Skills below); run whichever landed.
 
-**Per-step review (step-by-step mode — and pre-commit review ON's all-at-once
+**Per-step review (step-by-step mode — and auto-commit OFF's all-at-once
 pre-gate pass, where the whole implementation is the single group).** The
 Orchestrator may instead invoke you
 mid-implementation, scoped to **one `tasks.md` group of tasks** — handed **by
@@ -265,7 +265,7 @@ reference** (the group's id + header line): read the group's tasks and the
 requirements they reference from the spec files yourself. There is no PR yet —
 review the **group's diff on the branch against its slice of the spec** (the whole
 repo is your context; the verdict stays bounded to that slice). When the invocation
-says **pre-commit review is ON**, the group's work is **uncommitted by design**:
+says **auto-commit is OFF**, the group's work is **uncommitted by design**:
 the diff is the group's uncommitted work against its anchor
 (`git diff <anchor> -- ':(exclude).claude/state'`, the anchor handed in your
 invocation; worktree == index within that scope at review time) — review it as
@@ -276,8 +276,8 @@ below, both in step 4: the verdict is **local** — return it in your summary fo
 your ledger is `step-<N>.json` (the pre-gate single group, which has no step number,
 writes `full-pass.json`) — and a
 REJECT's `review_rejected` emit carries the extra `--step=<N>` flag **only when the
-group is a step-by-step step** — an all-at-once single group (pre-commit review
-ON's pre-gate pass) omits `--step`, which the events schema defines as absent on
+group is a step-by-step step** — an all-at-once single group (auto-commit
+OFF's pre-gate pass) omits `--step`, which the events schema defines as absent on
 all-at-once rejections (`iteration` stays
 task-global). Cross-group interactions are the final full-pass's job, not this one's;
 that full-pass reviews everything as usual and may reject anything, including

package/catalog/commands/pause.md

@@ -50,8 +50,8 @@ A two-step pause:
 
 The hook prints `git status --porcelain` after emitting — it never
 auto-commits. Decide what (if anything) to stage and commit before leaving.
-Exception — a task running **pre-commit review ON** (orchestrator §Pre-commit
-review ON): do **not** commit; the zero-commit deferral binds `/pause` too.
+Exception — a task running **auto-commit OFF** (orchestrator §Auto-commit
+OFF): do **not** commit; the zero-commit deferral binds `/pause` too.
 Leave the staged save-point untouched (it survives the session; staging
 anything now is the mid-experiment `add` the protocol forbids), note the pause
 in `progress.md` — disk-only, per the mode's contract.

package/catalog/commands/resume.md

@@ -36,15 +36,16 @@ drop `harness:needs-design` and continue toward spec-ready. When `progress.md` r
 `Mode: step-by-step`, the `## Step log` carries the step sub-state — resume
 exactly there: `awaiting human checkpoint (step N/M)` re-presents that pending
 checkpoint (inspect / run / OK / changes / OK+downgrade; in all-at-once under
-pre-commit review ON the line carries no `(step N/M)` counter — same
+auto-commit OFF the line carries no `(step N/M)` counter — same
 re-entry); a `fix-loop iteration K`
 line re-enters the per-step implement→review loop at that iteration; an
 `awaiting ledger retry (step N/M, retry 1/1)` line — or its full-pass twin
 `awaiting ledger retry (full pass, retry 1/1)` — re-runs
 `lemony review-ledger validate` on the sidecar on disk (`--anchor` per the
 orchestrator: per-step, the `(anchor <oid>)` on the step-log line; full pass, the
-fingerprint merge-base — except pre-commit review ON's pre-gate twin, which anchors
-at the recorded single-group anchor, = the branch head: ON defers every commit) —
+fingerprint merge-base — except auto-commit OFF's pre-gate twin, which anchors
+at the recorded single-group anchor, = the branch head: auto-commit OFF defers every
+commit) —
 green re-presents the gate
 the pass feeds, red goes to that gate with the verb's lines, the single retry being spent
 (authority: the orchestrator §Step-by-step implementation). If the Mode line carries a
@@ -55,13 +56,13 @@ history, not sub-state).
 **Cross-machine pickup of an `in-progress` task**: the branch on origin
 carries the last **successful** best-effort WIP push — the Implementer pushes on
 signaling done, and step-by-step pushes at each checkpoint-wait. Exception: a task
-running **pre-commit review ON** defers every commit and push until a checkpoint OK
+running **auto-commit OFF** defers every commit and push until a checkpoint OK
 — in-flight work and its `progress.md` updates exist only in the implementing
 machine's worktree, so from another machine the branch reads as of the last OK'd
 group; before the first OK it is **indistinguishable from idle** (the knob record
-itself is deferred — the documented price of the mode, orchestrator §Pre-commit
-review ON). When config pins `implementation.pre_commit_review: on`, or the
-branch's `progress.md` already carries the `Pre-commit review: on` line (some OK
+itself is deferred — the documented price of the mode, orchestrator §Auto-commit
+OFF). When config pins `implementation.auto_commit: off`, or the
+branch's `progress.md` already carries the `Auto-commit: off` line (some OK
 landed), surface the mode instead of concluding the task is idle. A discovery
 pause still surfaces cross-machine via its labels and issue comment, though the
 full `discoveries.md` entry stays machine-local. If a **local** copy

package/catalog/harness.config.schema.json

@@ -114,7 +114,7 @@
       "default": {},
       "type": "object",
       "properties": {
-        "pre_commit_review": {
+        "auto_commit": {
           "default": "human",
           "type": "string",
           "enum": [

package/catalog/hooks/init.sh

@@ -130,9 +130,17 @@ if [ ! -x "$PEER_HOOK" ]; then
   WARNINGS+=("$PEER_HOOK is missing or not executable — \`/pause\` and SessionEnd telemetry will fail. Re-run \`lemony install\` (or chmod +x).")
 fi
 
-# ── Warning 3 ─ local branch behind origin (no fetch — uses existing refs) ─
+# ── Warning 3 ─ default branch behind origin (no fetch — uses existing refs) ─
+# Scoped to a session sitting ON the default branch: "pull before starting" is
+# advice for main, and a task branch is behind origin/main by construction.
+# The nudge used to fire branch-agnostic: mid-task under auto-commit OFF
+# the worktree is dirty by design with the staged index as the save-point
+# ladder, and following `git pull --rebase` with `rebase.autostash` set flattens
+# that index — the documented rollback then reverts to the last commit and the
+# group's whole uncommitted work is gone. So on any other branch: silence.
+CURRENT_BRANCH="$(git symbolic-ref --quiet --short HEAD 2>/dev/null || true)"
 DEFAULT_BRANCH="$(git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')"
-if [ -n "$DEFAULT_BRANCH" ]; then
+if [ -n "$DEFAULT_BRANCH" ] && [ "$CURRENT_BRANCH" = "$DEFAULT_BRANCH" ]; then
   BEHIND="$(git rev-list --count "HEAD..origin/$DEFAULT_BRANCH" 2>/dev/null || echo 0)"
   if [ "${BEHIND:-0}" -gt 0 ]; then
     WARNINGS+=("local branch is $BEHIND commit(s) behind origin/$DEFAULT_BRANCH. Consider \`git pull --rebase\` before starting.")
@@ -142,7 +150,6 @@ fi
 # ── Warning 4 ─ residual harness branches (parked tasks) ───────────────────
 STALE_BRANCHES="$(git for-each-ref --format='%(refname:short)' refs/heads/harness/ 2>/dev/null | wc -l | tr -d ' ')"
 if [ "${STALE_BRANCHES:-0}" -gt 0 ]; then
-  CURRENT_BRANCH="$(git symbolic-ref --quiet --short HEAD 2>/dev/null || true)"
   case "$CURRENT_BRANCH" in
     harness/*) : ;;
     *) WARNINGS+=("$STALE_BRANCHES parked harness branch(es) present. Resume with \`continue <id>\` or close them with task-closeout.") ;;

package/catalog/templates/claude-code/agents.md.tpl

@@ -87,10 +87,11 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
 7. **Implement** — Implementer sub-agent, `tdd` skill, on the branch, keeping
    `.claude/state/tasks/<id>/progress.md` live. The gate interaction settles two
    knobs, both recorded in `progress.md`: the **implementation mode** (all-at-once,
-   or step-by-step with per-group human checkpoints) and **pre-commit review**
-   (config `implementation.pre_commit_review`; ON = the human reviews the work
-   **uncommitted** — zero commits until each checkpoint OK). Authority:
-   orchestrator §Implementation mode / §Pre-commit review ON.
+   or step-by-step with per-group human checkpoints) and **auto-commit**
+   (config `implementation.auto_commit`; auto-commit OFF = zero commits — the human
+   reviews the work **uncommitted** until each checkpoint OK; auto-commit ON =
+   commit-as-you-go).
+   Authority: orchestrator §Implementation mode / §Auto-commit OFF.
 8. **Review** — flip to `harness:status:in-review`, open the PR (`gh pr create`,
    branch → default), Reviewer sub-agent reviews it (`senior-review`, fresh context). If
    the task touched UI, the **UI Designer** reviews as a distinct design + a11y lens too

package/catalog/templates/claude-code/harness.config.yml.tpl

@@ -59,13 +59,17 @@ rollback:
 #   allow_no_checks: false
 
 # Implementation-phase knobs the Orchestrator reads at the L1 approval gate.
-# pre_commit_review — human review of the UNCOMMITTED work before anything is
-# committed (zero-commit mode): `human` (default) asks at the gate, in the same
-# interaction as the all-at-once / step-by-step choice, suggesting OFF (today's
-# commit-as-you-go flow); `on` / `off` pin the answer and skip the question
-# (bench/headless runs pin `off`). Bare on/off are strings here (YAML 1.2).
+# auto_commit — does the agent commit automatically as it works? `on`: the
+# Implementer commits and pushes as it goes; `off`: zero commits — the work
+# accumulates in the worktree, you review it UNCOMMITTED (Source Control) and
+# the branch gets its first commit on your OK (more control). `human` (default)
+# asks at the gate, in the same interaction as the all-at-once / step-by-step
+# choice, recommending OFF; `on` / `off` pin the answer and skip the question
+# (a headless/bench run must pin `on`). Bare on/off are strings here (YAML 1.2).
+# Replaces `pre_commit_review` (0.3.0, inverse polarity): the old key is
+# tolerated and removed on the next config write; its value is not migrated.
 # implementation:
-#   pre_commit_review: human
+#   auto_commit: human
 
 # Review gates. The mechanical gates a Reviewer must attest in its evidence
 # ledger, one entry per name, beyond the always-required real run — a flat list of

package/dist/cli.mjs

@@ -23,18 +23,22 @@ const DEPRECATED_PATHS_KEYS = [
 	"skills",
 	"agents"
 ];
+const DEPRECATED_IMPLEMENTATION_KEYS = ["pre_commit_review"];
 const HARNESS_CONFIG_SCHEMA_FILENAME = "harness.config.schema.json";
-const CONFIG_KEY_SINCE = { gates: "0.3.0" };
+const CONFIG_KEY_SINCE = {
+	gates: "0.3.0",
+	"implementation.auto_commit": "0.4.0"
+};
 const TASK_STORAGE_REPO_PLACEHOLDER = "OWNER/REPO";
 const TARGETS = ["claude-code"];
 const TASK_STORAGE_TYPES = ["github"];
 const TASK_STORAGE_REPO_PATTERN = /^[^\s/]+\/[^\s/]+$/;
-const PRE_COMMIT_REVIEW_MODES = [
+const AUTO_COMMIT_MODES = [
 	"human",
 	"on",
 	"off"
 ];
-const PRE_COMMIT_REVIEW_DEFAULT = "human";
+const AUTO_COMMIT_DEFAULT = "human";
 const VENDOR_VERSION_REGEX = /^\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$/;
 const VENDOR_VERSION_EXAMPLE = "0.1.0-alpha.0";
 const PATHS_DEFAULTS = {
@@ -121,7 +125,7 @@ const mergeSchema = z.object({
 	checks_timeout_secs: z.int().positive().default(600),
 	allow_no_checks: z.boolean().default(false)
 }).strict().prefault({});
-const implementationSchema = z.object({ pre_commit_review: z.enum(PRE_COMMIT_REVIEW_MODES).default(PRE_COMMIT_REVIEW_DEFAULT) }).strict().prefault({});
+const implementationSchema = z.object({ auto_commit: z.enum(AUTO_COMMIT_MODES).default(AUTO_COMMIT_DEFAULT) }).strict().prefault({});
 const gatesSchema = z.array(z.string().trim().min(1)).optional();
 const harnessConfigSchema = z.object({
 	vendor_version: z.string().regex(VENDOR_VERSION_REGEX),
@@ -161,6 +165,12 @@ const readHarnessConfig = async (repoRoot) => {
 		for (const key of DEPRECATED_PATHS_KEYS) delete pathsCandidate[key];
 		candidate.paths = pathsCandidate;
 	}
+	const implementation = candidate.implementation;
+	if (implementation && typeof implementation === "object" && !Array.isArray(implementation)) {
+		const implementationCandidate = { ...implementation };
+		for (const key of DEPRECATED_IMPLEMENTATION_KEYS) delete implementationCandidate[key];
+		candidate.implementation = implementationCandidate;
+	}
 	const result = harnessConfigSchema.safeParse(candidate);
 	if (!result.success) throw new Error(`${HARNESS_CONFIG_FILENAME} is invalid:\n${formatConfigError(harnessConfigSchema, result.error)}`);
 	return result.data;
@@ -222,6 +232,7 @@ const setConfigValues = (rawYaml, updates) => {
 	for (const key of DEPRECATED_PATHS_KEYS) if (doc.hasIn(["paths", key])) doc.deleteIn(["paths", key]);
 	const pathsNode = doc.get("paths", true);
 	if (isMap(pathsNode) && pathsNode.items.length === 0) doc.delete("paths");
+	for (const key of DEPRECATED_IMPLEMENTATION_KEYS) if (doc.hasIn(["implementation", key])) doc.deleteIn(["implementation", key]);
 	return doc.toString();
 };
 const writeConfigValues = async (repoRoot, updates) => {
@@ -5840,7 +5851,7 @@ const reviewLedgerValidate = async (args) => {
 	if (taskId === void 0) throw new Error(`${REVIEW_LEDGER_USAGE} --task-id is required.`);
 	if (taskId !== basename(taskId) || taskId === "." || taskId === "..") throw new Error(`Invalid --task-id="${taskId}": a task id names one directory under the task state, never a path.`);
 	const anchor = parseFlag(args, "anchor");
-	if (anchor === void 0) throw new Error(`${REVIEW_LEDGER_USAGE} --anchor is required — the group's recorded head OID on a step, the fingerprint merge-base on a full pass (pre-commit review ON's pre-gate pass anchors at the recorded group anchor instead); the owed set of the mutant floor is the diff from it.`);
+	if (anchor === void 0) throw new Error(`${REVIEW_LEDGER_USAGE} --anchor is required — the group's recorded head OID on a step, the fingerprint merge-base on a full pass (auto-commit OFF's pre-gate pass anchors at the recorded group anchor instead); the owed set of the mutant floor is the diff from it.`);
 	const address = parseLedgerAddress(args);
 	const result = await runLedgerValidate({
 		repoRoot: cwd(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lemoncode/lemony",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Lemony — a Harness for AI Coding. Vendor package: installer, agent role catalog, generic skill catalog, hooks, and templates for a Spec-Driven Development workflow.",
   "type": "module",
   "private": false,