plumbbob 0.13.1 → 0.13.2

package/skills/finish/SKILL.md

@@ -2,7 +2,7 @@
 name: finish
 description: "Finish the build: write the report (what shipped, decisions, parked/harvested items, deferred tangents), then make the final commit that closes the session. The build folder rides the branch into the PR: no separate archive. Report by default, no gate."
 disable-model-invocation: true
-allowed-tools: Read, Write, Bash(plumbbob status:*), Bash(plumbbob finish:*)
+allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob harvest:*), Bash(plumbbob order:*), Bash(plumbbob finish:*)
 ---
 
 # PlumbBob: finish the build (the close-out)
@@ -17,7 +17,21 @@ record.
 
 ## What this skill does, in order
 
-1. **Write the report** to the active build's `report.md`
+1. **Settle a stop card still waiting.** Read `.plumbbob/detail.md`. When it opens on a
+   `# Detail · Range <N>` header, the last range's stop card is waiting for its reply, and
+   `/plumbbob:finish` typed at it is that reply, the move its Your Call block names
+   ([D102 (settle-in-one-reply)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d102)).
+   Record it the way `looks good` would before anything else: fold each blocker its
+   `## Harvest` section proposes into `intent.md` by the harvest skill's rules (read
+   `../harvest/SKILL.md` from this skill's base directory), then run `plumbbob harvest`,
+   which writes the range's review into the Log and flips the parks the card settled. A
+   finish that skipped it would leave the last range's review out of the Log and its parks
+   open in the report. When `plumbbob harvest` refuses with `step 13 joined it after it
+   landed`, a blocker went into the range the card reviews: move that step to a range
+   still to come, or a bare range of its own, leave the detail file as it is, fold nothing
+   again, and run `plumbbob harvest` once more. On any other refusal, report what it names
+   and stop before the report. Any other detail file, or none, has nothing waiting.
+2. **Write the report** to the active build's `report.md`
    (`.plumbbob/builds/<slug>/report.md`), from `intent.md` + `build-log.md`.
    The build-log's `## Log` is already the chronological history; `plumbbob checkpoint`
    wrote a dated line for every step as it landed. **Read it as the spine; do not
@@ -34,7 +48,7 @@ record.
    `## Stats` (the per-step receipts) itself, so do **not** hand-write either; a report
    that spells them out collides with the CLI's own tail. This is the "yeah, I did that"
    artifact. Write it by default; the human may edit it.
-2. **Finish.** Run `plumbbob finish`, which appends the checkpoint SHAs to the
+3. **Finish.** Run `plumbbob finish`, which appends the checkpoint SHAs to the
    report and makes the final commit (subject `chore(<scope>): finish`, its body
    led by a `plumbbob finish` marker plus an optional proportional `--body`), then
    clears the control state (the in-flight markers, then `STATE` last; one delete
@@ -58,7 +72,7 @@ record.
    cannot analyze the extra redirect, so it blocks the command or stops to ask instead of
    letting this skill's allowance cover it. Omit `--body` entirely and the commit carries
    the `plumbbob finish` marker subject only.
-3. **Point at the next goal.** Relay `plumbbob finish`'s output verbatim, blank lines
+4. **Point at the next goal.** Relay `plumbbob finish`'s output verbatim, blank lines
    included: its lead line, which names the branch the tracked folder now rides into the
    PR, any advisory beneath it, and `**Next Up**: Nothing planned - /plumbbob:plan`. That
    is the orientation tier's close (the

package/skills/harvest/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: harvest
-description: "Triage the park list at a step boundary: propose one class (blocker/tangent/pivot) per parked item, write only after the human confirms each, record under ## Harvest, and fold a confirmed blocker into intent."
+description: "Triage the park list at a step boundary: propose one class (blocker/tangent/pivot) for every open parked item at once, and once the human settles them in one reply, fold a confirmed blocker into intent and record the rest with plumbbob harvest. A run's stop card carries its own harvest."
 disable-model-invocation: true
-allowed-tools: Read, Edit, Bash(plumbbob status:*), Bash(plumbbob order:*)
+allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob order:*), Bash(plumbbob harvest:*)
 ---
 
 # PlumbBob: harvest the park list
@@ -25,12 +25,19 @@ DESIGN boundary, not mid-step. Read the dashboard injected above:
 
 A range's stop is the boundary that matters most. No harvest runs between the steps
 inside a range, so the parks it piled up wait for the stop where it lands, and a
-blocker among them is caught there before the next range builds on it.
+blocker among them is caught there before the next range builds on it. A run's stop card
+carries its harvest
+([D100 (stop-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d100)):
+every open park is on the card with a proposed lean, and the reply that settles the card
+records them, so there is nothing left for this skill to do there. If
+`.plumbbob/detail.md` opens on a `# Detail · Range <N>` header, that card is still waiting:
+**refuse**, since writing this skill's detail file would overwrite the range's review, and
+point the human at the card's own reply (`looks good`, or a change to a lean).
 
 ## What this skill does
 
-Walk the **Park list** in `build-log.md` item by item and, for each, **propose exactly
-one class**:
+Walk the **Park list** in `build-log.md` and, for every open item, **propose exactly one
+class**, all of them at once:
 
 - **blocker**: the plan was wrong or incomplete; can't proceed. Folds into `intent.md`
   and is handled now.
@@ -39,23 +46,50 @@ one class**:
 
 ## The one hard contract
 
-You **propose**; the **human calls it**. For each item, state your proposed class and
-one line of reasoning, then **wait for the human to confirm or override**. Write
-**only after** per-item confirmation:
+You **propose**; the **human calls it**. Propose a class for every open item at once,
+with one line of reasoning each, and the human settles them all in one reply
+([D102 (settle-in-one-reply)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d102)):
+one reply per item is what made a harvest a chore, and seeing every proposal at once keeps
+the call on each one theirs. The detail file you write first is the proposal; record
+**only after** that reply confirms them:
 
-- Record each confirmed class in `build-log.md`'s `## Harvest` section.
-- **Flip the harvested item** from `- [ ]` to `- [x]` in the Park list, so `/plumbbob:status`
-  stops counting it as open.
+- Write the proposals into `.plumbbob/detail.md` first, under a `# Detail · Harvest`
+  header, one line per open item in a `## Harvest` section:
+  `- P6 → tangent: <the reason, one clause>`, the class written `blocker`, `tangent`,
+  or `pivot` (for a pivot signal). A park's handle is `P` and its place in the
+  Park list, counting the harvested lines too (the count the note sizes as
+  `parked 3 of 8 open`), and it is the one name the detail file, the turn, and the
+  human's reply all use
+  ([D105 (park-handles)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d105)).
+  Then list the same proposals in the turn, each with its handle and the park's text, and
+  end the turn there.
+- A reply that changes a proposal (`make P7 a tangent`) is the human's call: rewrite
+  that line, list the proposals again, and end the turn. A reply that confirms them
+  (`looks good`) is what lets you write.
+- On that confirmation, run `plumbbob harvest`
+  ([D104 (harvest-records)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d104)).
+  It flips each settled item from `- [ ]` to `- [x]` in the Park list, so
+  `/plumbbob:status` stops counting it as open, and records each confirmed class under
+  `build-log.md`'s `## Harvest` section. Relay its ending whole, the `**Recorded**:` line
+  and the Next Up beneath it. It refuses a proposal naming a handle the list lacks (`P9`
+  with eight parked) or a class other than blocker, tangent, or pivot; fix the line it
+  names and run it again.
 - A confirmed **blocker** also folds its decision into `intent.md`, slugged at birth
   like any Decision, anchored the same way
   (`- <a id="d5"></a>**D5 (retry-cap)**: <the call>, *because* <why>`), never a bare `D5`.
   A blocker that becomes a new step takes the next free number under `## Steps` and,
   when it has to land before an existing undone step, its place in the sequence through
   `plumbbob order 7 8 5` (the `## Build order` line), never by renumbering. When the plan
-  carries `## Build ranges`, the new step goes into a range too (the one it builds with,
-  or a bare range of its own when it brings a call the human has to make before it
-  lands), and a range it breaks is re-cut in the same confirmed edit
+  carries `## Build ranges`, the new step goes into a range too: a range still to come
+  (the one it builds with), or a bare range of its own when it brings a call the human
+  has to make before it lands, and never a range that has landed, since that range's call
+  was made and the step would reopen it. A new range takes the next free item number, and
+  no item is renumbered, because the stop card's stamp, the detail file's header, and
+  `plumbbob harvest` find a landed range by its number. A range the step breaks is re-cut
+  in the same confirmed edit
   ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92));
   `plumbbob status` afterward carries a `⚠` row for any range still broken.
+- Fold a confirmed blocker into `intent.md` before you run `plumbbob harvest`, so the
+  record and the plan agree when it lands.
 - Never reclassify or resolve an item the human hasn't confirmed, and default every
   uncertain item to **tangent**, never to blocker.

package/skills/plan/SKILL.md

@@ -12,9 +12,11 @@ Current session state (injected when this skill runs): !`plumbbob status 2>/dev/
 
 `/plumbbob:plan` is the **whole-goal** move; it opens a session and gets the deciding out
 of your head and onto `intent.md` *before* any code. By default it authors the
-**complete plan, including all the Steps**, so the happy path afterward is just
-`/plumbbob:build` until done. (Revising a single increment later is the separate `/plumbbob:step`
-move; do not confuse the two.)
+**complete plan, including all the Steps and the build ranges**, so the happy path
+afterward is `/plumbbob:run` until done: each run lands one range and stops where the plan
+says a human call is due. A plan without ranges is driven with `/plumbbob:build`, a step
+at a time, and `/plumbbob:build` stays the granular move inside any plan. (Revising a
+single increment later is the separate `/plumbbob:step` move; do not confuse the two.)
 
 A model note: this skill **inherits the session model**; nothing pins or switches
 it. Planning is where frontier-class judgment pays for itself, so if the session is
@@ -42,7 +44,8 @@ Look at the argument the human gave and pick the mode yourself:
    genuinely ambiguous.
 
 All three modes converge on the **same artifact**: a complete, standalone `intent.md`
-an agent can follow with `/plumbbob:build`. The argument only seeds how you get there.
+an agent can follow with `/plumbbob:run`, or with `/plumbbob:build` when it cuts no ranges.
+The argument only seeds how you get there.
 
 ## What this skill does
 
@@ -120,8 +123,8 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
 5. **Cut the build ranges.** With the steps written, say where the build stops for a
    human call, under `## Build ranges`
    ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92)):
-   one sentence on how to drive the build, then one numbered item per range, in the
-   format the parser reads:
+   one sentence on how to drive the build, a `/plumbbob:run` per range, then one numbered
+   item per range, in the format the parser reads:
 
    ```markdown
    1. `/plumbbob:build 1`, **stop:** at step 1's pause, approve the schema before anything writes to it
@@ -148,16 +151,26 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
    Name every step in exactly one range, by its plan number. A fresh plan has no build
    order, so the ranges follow the numbering. Give each range a `- model:` line naming the
    strongest model any step inside it recommends, written plain the way a step's is,
-   because that is the `/model` the human picks before typing the command; any other
+   because that is the `/model` the human picks before typing the run; any other
    sub-line (a `- note:` on what to watch for) is the reader's, and the CLI leaves it
    alone. Replace the template's placeholder item rather than writing beside it: an item
    still holding its `<...>` fill-ins reads as no range at all.
 
    **Size the ranges to the work.** A plan of two or three steps may carry one range, or
    none. When every step would be its own bare range, delete the section: the default
-   loop already stops at each step's pause. A range is advice, never a grant
-   ([D67 (auto-not-a-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d67)):
-   the card names the range to type beneath Next Up, and the human still types it.
+   loop already stops at each step's pause, and `/plumbbob:build` drives a plan without
+   ranges a step at a time.
+
+   **The card names the run, not the item.** The item's command is the range's
+   definition: the form the parser reads, and the kind of stop it makes. The card names
+   `/plumbbob:run` beneath Next Up for the range holding the next step, with the steps it
+   will land beside it, and `/plumbbob:run 3` runs range 3 by its item number
+   ([D95 (run-verb)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d95)).
+   A range grants nothing until the human types the run that names it, and then the turn
+   hook mints the grant from the plan as it stands
+   ([D96 (plan-names-the-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d96)),
+   so a range you cut is never a grant you mint
+   ([D67 (auto-not-a-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d67)).
 6. **Offer harness bindings** *(optional)*. If the build will lean on
    user-authored agents, author `harness.json` in the build folder (beside `intent.md`)
    and review it at the **same plan pause**, alongside the steps; bindings are
@@ -195,11 +208,13 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
      renders the your-call block with the moves that apply before anything is recorded and
      prints your recommendation last (the decision tier of the
      [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)),
-     so the moves are relayed, never hand-composed. *looks good* marks the plan decided and
-     starts `/plumbbob:build` at the first undone step; a message that asks (`expand 2`, or
-     any question) is answered from the detail file or `intent.md` and changes nothing; a
-     message that directs is what to sharpen, cheap now, before any code. The revert move
-     vanishes there on its own: nothing has landed to wind back.
+     so the moves are relayed, never hand-composed. *looks good* marks the plan decided, and
+     its row names the move the human types next: `/plumbbob:run` for the range holding
+     Step 1 when the plan declares ranges, `/plumbbob:build` for Step 1 when it does not;
+     a message that asks (`expand 2`, or any question) is answered from the detail file or
+     `intent.md` and changes nothing; a message that directs is what to sharpen, cheap
+     now, before any code. The revert move vanishes there on its own: nothing has landed
+     to wind back.
    - **The plan commit is latched too.** Once the turn ledger exists, `checkpoint
      --plan` refuses to land in the same turn `start` stamped it: present the plan,
      **end the turn**, and the human's approving message is the tick that lets it
@@ -210,7 +225,8 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
      refusal.)
    - **The plan commit prints its own close.** `plumbbob checkpoint --plan` emits the
      whole boundary ending: `**Plan**: committed (<sha>)`, any advisory, and the pointer at
-     the step the build starts on. Relay that block whole and run no second command; the
+     the step the build starts on, with the run that lands its range named beneath it when
+     the plan declares ranges. Relay that block whole and run no second command; the
      plan-pause card above is the one place `handoff` is still called, because no verb has
      run yet there.
    - **Say what the commit publishes.** The close-out line names the tracked folder:

package/skills/refine/SKILL.md

@@ -59,8 +59,11 @@ is fine; refining is always available.
 
   **A repair keeps the build ranges true.** When the plan carries `## Build ranges`, a
   step the repair adds goes into a range (the one it builds with, or a bare range of its
-  own when it brings a call the human has to make before it lands), and a range the
-  repair breaks is re-cut in the same before/after
+  own when it brings a call the human has to make before it lands), never a range that
+  has landed, since that range's call was made and the step would reopen it. A new range
+  takes the next free item number, and no item is renumbered, because the stop card's
+  stamp, the detail file's header, and `plumbbob harvest` find a landed range by its
+  number. A range the repair breaks is re-cut in the same before/after
   ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92)).
   Read `plumbbob status` once the edits are written: its ranges block carries a `⚠` row
   for a range naming a step the plan lacks, a step two ranges name, a step the build order

package/skills/run/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: run
+description: "Run what is left of the range holding the next step, or of range N: the plan's `## Build ranges` names the steps, the turn hook mints their grant from the plan, and the run walks them the way a typed range is walked, then ends on the stop card, the range's review with every open park proposed, which one reply settles. A bare range builds its one step to its pause. Reads the build skill beside it for the per-step loop."
+argument-hint: "[range-number]"
+disable-model-invocation: true
+allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob build:*), Bash(plumbbob handoff:*), Bash(plumbbob check:*), Bash(plumbbob checkpoint:*), Bash(plumbbob park:*), Bash(plumbbob agent:*), Bash(plumbbob spike:*), Bash(git diff:*), Bash(plumbbob harvest:*), Bash(plumbbob order:*), Bash(git log:*)
+---
+
+# PlumbBob: run a range
+
+Current session state (injected when this skill runs): !`plumbbob status --run "$ARGUMENTS" 2>/dev/null || echo "plumbbob CLI not on PATH in this session. Marketplace install: confirm the plugin is enabled in /plugin, then /reload-plugins. Skills-dir/global install: npm i -g plumbbob && plumbbob init."`
+
+A run is one range of the plan being built. `/plumbbob:run` runs what is left of the range
+holding the next undone step in build order, the step in flight counted undone, and
+`/plumbbob:run 3` runs range 3, by the item number the plan's `## Build ranges` gives it
+([D95 (run-verb)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d95)).
+The plan names the steps, so you never work them out from the chat: the run header above the
+dashboard names them, and the turn hook minted their grant from the plan when the human typed
+the run
+([D96 (plan-names-the-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d96)).
+
+This skill carries only what is the run's own: reading the header, refusing, how a run
+starts, and the stop card it ends on. The loop that builds each step belongs to the build
+skill, and the classes a park settles as belong to the harvest skill; you read both rather
+than recall them
+([D99 (one-loop)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d99)).
+
+## 1. Read the build skill first
+
+Before anything else, read `../build/SKILL.md` from this skill's base directory: the path
+printed above this skill as its base directory, so `<base directory>/../build/SKILL.md`.
+Read the file every run, whole; a copy of it from memory drifts. The parts a run follows are
+its sections **What this skill does, in order** (steps 2 to 5: entering a step, reading the
+plan, implementing within the seam, parking a tangent, and the verify tick with its pause),
+**`--auto`: let the agent be the clock (opt-in)** with its halt list, **A step range (`N-M`,
+or a list like `20,5-9`) is a bounded `--auto`**, **Running bound agents** when the dashboard
+shows a `harness bindings:` block, and **The hard contracts**.
+
+Its rules about its own invocation are about `/plumbbob:build` and do not apply here: its
+first step (picking the step from its arguments) and its rule that the invocation outranks
+its injected dashboard. For a run, this skill's invocation and the run header take their
+place, below. Its rule for a clean halt (relay the top step's checkpoint block and end the
+turn) gives way to the stop card here, below.
+
+At the stop card you also read `../harvest/SKILL.md` from the same base directory, for its
+three classes, its default, and its rules for folding a confirmed blocker into the plan.
+
+## 2. Read the run header
+
+The injected state opens on the run header when the run names a range it can walk:
+
+```text
+run  range 3 of 5 · steps 6-9 · ends at step 9's boundary
+     stop: review the card on a live boundary before the skills teach it
+     grant: steps 6-9
+```
+
+The first line is the range, what is left of it in the order the run builds it, and where
+the run ends: at the boundary after its last step for a range that lands its steps, or at
+the pause of its one step for a bare range. The `stop:` line is the call the plan reserved
+for the end of the range. The `grant:` line is what the turn hook minted at the keystroke,
+and the dashboard beneath marks the run's first step `← requested`.
+
+A fourth line, `waiting: range 2 of 5's stop card, recorded before the run`, means the last
+range's stop card is still waiting for its reply. The run typed at it is that reply: settle
+the card first (section 6, below), then walk the run.
+
+**The typed number and the grant outrank the header.** The hook read the plan the human
+typed against, so its grant is the run. When the human typed a number and the header names
+another range (the host never passed the number through), or the grant line says
+`unlike the run`, walk exactly the steps the grant names and say so in one line. A
+`range M` grant, from a hook older than step lists, lands the steps up to M.
+
+`grant: none` beside a range that lands its steps means the hook minted nothing, because
+the plugin's hook is older than the run or the prompt was not a typed `/plumbbob:run`, so
+no step could land without a pause. Report that in a sentence or two, name the range's own
+command from the plan's `## Build ranges` (`/plumbbob:build 6-9`) as the way to land it by
+hand, and stop without building. **Never write a grant yourself to get past it: a grant you
+mint is no grant, and the latch ignores it
+([D67 (auto-not-a-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d67)).**
+
+## 3. Refuse what the run cannot walk
+
+No run header above the dashboard means the run names nothing it can walk, and the hook
+minted nothing for it
+([D97 (run-refuses)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d97)).
+The dashboard's `next →` line carries the refusal and the move that unblocks it: a plan
+without ranges (`/plumbbob:refine ranges`, or `/plumbbob:build` for the next step alone), a
+next step no range names or a flagged range (`/plumbbob:refine ranges`), a range that has
+landed or a number the plan lacks (the run the card names instead), nothing left
+(`/plumbbob:finish`), a step in flight outside the range typed (`/plumbbob:verify` or
+`/plumbbob:abandon` it), or a spike open (`plumbbob spike done`). A span or a list of ranges
+(`/plumbbob:run 2-4`) is a form no run defines, and it refuses the same way.
+
+Report the refusal in a sentence or two, quoting the move from that line, and stop: enter
+no step, build nothing, and run no checkpoint. `NO ACTIVE SESSION` refuses too, with
+`/plumbbob:plan` as the move.
+
+## 4. Run the range
+
+**A step waiting at its pause.** When the dashboard's phase reads `[BUILD]`, a step is in
+flight, and the header's first step is that step. A run typed there is that pause's
+`looks good`: land it the way the build skill lands an approved pause, with
+`plumbbob checkpoint <n> --body <<'BODY'` and a body proportional to the step, and do not
+enter it again with `plumbbob build`. The checkpoint runs the check, so the step lands only
+on green. When the checkpoint refuses on a red check, the step stays at its pause: write the
+detail file, run `plumbbob handoff`, paste its block, and end the turn. When the step is not
+finished (its done-when unmet, and no pause card for it in this conversation), finish
+building it first, then verify and land it the same way. Once it lands, a bare range's run
+ends there: relay the checkpoint's block whole and end the turn. A run whose landing range
+that step completed ends on the stop card, below, even when the paused step was the range's
+last. Otherwise carry on through what is left, below. A halt the human approves with
+`looks good` lands its step the same way, and when that landing completes the run's range
+(its checkpoint block carries the `**Stop**:` part for it), the run ends on the stop card
+too.
+
+**A range that lands its steps.** Walk it exactly as the build skill walks a typed range,
+in its section on step ranges: start at the header's first undone step, build each step the
+grant names in build order, check, self-review, and checkpoint it on green, and take the
+next undone step in build order after each landing. A step the grant does not name halts the
+walk before it, since the checkpoint would refuse it. The halt list is the build skill's: a
+red check, a self-review mismatch, a bound agent's `blocked` or `drift`, or a new decision
+ends at that step's pause card. `plumbbob build` names the top step as the top of the range
+you granted when it enters it. Once that step lands, its checkpoint prints the boundary
+with the Stop part (`**Stop**: Range 3 of 5 landed - <its stop>`); relay none of it, and end
+the run on the stop card, below, in the same turn.
+
+**A bare range.** `grant: none, as a bare range builds to its pause`: build the range's one
+step to its pause exactly as the build skill's default path does for `/plumbbob:build <n>`:
+enter it, implement it, verify it, write the detail file, run `plumbbob handoff`, paste its
+block, and end the turn. The plan reserved this pause for a call, and the header's `stop:`
+line names it, so your recommendation speaks to that call.
+
+## 5. End on the stop card
+
+A run that lands its range ends on the stop card
+([D100 (stop-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d100)):
+the review the plan's stop asked for, with every open park on it and a lean proposed for
+each. The checkpoint that landed the range's last step marked its ending as owing the card,
+and the turn will not close on that boundary
+([D103 (stop-latched)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d103)).
+
+*Write the range's detail file.* Overwrite `.plumbbob/detail.md` in the range's shape:
+
+```markdown
+# Detail · Range <N> · <the stop, as the plan words it>
+
+── recap · range <N> of <M> ──
+done-when    met
+decisions    honored: D1 (some-slug), D2 (another-slug)
+constraints  all honored
+
+## Summary
+
+<what the whole range built, in a sentence or a short paragraph>
+
+## 1 <the first highlight across the range: one sentence, one move>
+
+<the full story>
+
+## Harvest
+
+- P<handle> → <blocker, tangent, or pivot>: <the reason, one clause>
+
+## Recommendation
+
+<The move.> <The reason, one or two sentences.>
+```
+
+The header names the range by its item number, and that is how `checkpoint` and
+`plumbbob harvest` tell the file from a step's. The three rows judge the whole range: every
+step's done-when, the decisions any step exercised, and the constraints. The Summary and the
+highlights are the range's, not its last step's, and you draw them from the range's
+checkpoint bodies (`git log` over its commits) and their entries in the build-log's `## Log`,
+never from recall, since a long run can compact its context partway through and lose its
+early steps. A step that landed a hair off comes first among the highlights; five at most.
+
+The `## Harvest` section carries one line for every open park in the build-log's
+`## Park list`. A park's handle is `P` and its place in that list, counting the harvested
+lines too, which is the count the note sizes as `parked 3 of 8 open`: the third line ever
+parked is `P3` whether or not the two above it are flipped, and the card, the detail file,
+and the human's reply all name it `P3`
+([D105 (park-handles)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d105)).
+Propose one class per park by the harvest skill's rules, `tangent` for anything uncertain,
+with the reason in one clause; the card prints it as the park's lean
+(`→ lean: tangent, <the reason>`), so write the class and the reason alone and leave the
+punctuation to handoff. A park you leave out reads `no lean proposed` on the card and stays
+open. The section vanishes when no park is open, and so does the card's Harvested part
+([D100 (stop-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d100)).
+The recommendation speaks to the plan's stop, the header's `stop:` line, and to the
+proposals: the move you would take on both, then why.
+
+*Render it and stop.* Run `plumbbob handoff --stop` and paste its output whole, verbatim, at
+top level, trailing blank line included, then end the turn. Write nothing before it or after
+it, and record nothing in this turn: `plumbbob harvest` refuses in the turn the card printed,
+because the human has not read it yet. If the turn is held with a reason saying the stop card
+is still owed, do exactly what the reason says.
+
+## 6. The reply at a stop
+
+The card's proposals are settled in one reply
+([D102 (settle-in-one-reply)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d102)),
+and the Your Call block names the replies. Read the human's message as one of them:
+
+- **`looks good`** confirms the review and locks in every lean as proposed, as the line
+  beneath the card's Your Call label says. Fold each confirmed blocker into `intent.md` by
+  the harvest skill's rules first, then run `plumbbob harvest`, which flips the parks,
+  writes the Harvest lines, and writes the range's review beneath a dated line in the Log.
+  A blocker that becomes a step goes into a range still to come, or a bare range of its
+  own, never into the range this card reviews: that range has landed, its call is the one
+  being made, and the step would reopen it. Relay the record's ending whole and end the
+  turn. It commits nothing; the record rides the next step's checkpoint.
+- **A change** (`make P7 a tangent`, or a change to the review) is direction. Rewrite the
+  detail file's line or section, run `plumbbob handoff --stop`, paste the whole card it
+  prints, and end the turn. Nothing is recorded until `looks good`.
+- **A question**, or `expand 2`, is answered from the detail file, the range's commits, or
+  the Log, never from recall; then run `plumbbob handoff --stop` and paste what it prints
+  beneath your answer, which is the one-line reminder while the stop is unchanged.
+  `show the stop`, or a session without the card in front of it, takes
+  `plumbbob handoff --stop --full`.
+- **`/plumbbob:run`** typed at the card confirms everything the way `looks good` does, and
+  runs the next range. Record first: fold the blockers and run `plumbbob harvest`, then read
+  `plumbbob status --run "<the same argument>"` again. When its grant line says
+  `unlike the run`, the record re-cut the range the run would walk (a blocker added or moved a
+  step in it), and the grant the hook minted before the record no longer covers it: relay
+  the record's ending whole and end the turn there, where its note names the re-cut run for
+  the human to type
+  ([D102 (settle-in-one-reply)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d102)).
+  Otherwise relay the record's ending and walk the run from section 4.
+- **`/plumbbob:finish`** at the plan's last range is the finish skill's to settle: it
+  records the card the way `looks good` would before it writes the report.
+
+`plumbbob harvest` refuses a proposal naming a handle the list lacks (`P9` with eight
+parked) and a class outside the three, and it refuses a detail file no card showed; fix what the refusal names, run
+`plumbbob handoff --stop` again, and end the turn on the card. One refusal takes another
+path: `step 13 joined it after it landed` means a blocker went into the range the card
+reviews. Move that step to a range still to come, or a bare range of its own, leave
+`.plumbbob/detail.md` as it is, fold nothing again, and run `plumbbob harvest` once more in
+the same turn, which records; `plumbbob handoff --stop` would refuse there.
+
+## The hard contracts
+
+- **The human types the run.** You never start one: `looks good` lands a step and never
+  starts the next range, and nothing chains ranges. A run ends where its range does, on the
+  stop card, or at a pause for a bare range or a halt, and the next run waits for the human's
+  next prompt.
+- **The plan names the steps.** Walk what the header and the grant name, never a range
+  worked out from the chat, and never a step beyond the grant.
+- **The latch holds the record.** A refused checkpoint is a pause, never an error to route
+  around: write the detail file, run `plumbbob handoff`, paste its block, and end the turn.
+  Never land a step with a raw `git commit`, and never write a grant into a settings or
+  control file; ask the human to type the run again instead.
+- **The reply records the stop.** Never run `plumbbob harvest` in the turn the stop card
+  printed; the human's reply to the card is what records it, and the classes stay their call.
+- **One loop.** Read `../build/SKILL.md` every run; the build skill is the engine both verbs
+  drive, and two copies of it would drift apart.

package/skills/status/SKILL.md

@@ -34,6 +34,8 @@ annotate it.
 3. When the plan carries `## Build ranges`, the dashboard lists them beneath the steps:
    `ranges  2 of 5 done`, `✓` on a landed range and `▸` on the one holding the next step,
    each undone range's stop on the line beneath it, and a `⚠` row for any range the plan
-   has outgrown. Its `next →` then names the range's command to type. You relay the block
-   with the rest; a `⚠` row is `/plumbbob:refine`'s to fix.
+   has outgrown. A landed range whose stop card still waits for its reply reads
+   `← stop card waiting`, and the `next →` names that card first. Each row keeps the command the plan wrote, the range's definition, while
+   the `next →` names the run to type, `/plumbbob:run` with the steps it will land beside
+   it. You relay the block with the rest; a `⚠` row is `/plumbbob:refine`'s to fix.
 4. If it reads `NO ACTIVE SESSION`, tell the human to `/plumbbob:plan` to frame a goal.

package/skills/step/SKILL.md

@@ -59,12 +59,21 @@ grew, but its everyday job is to sharpen, not to invent.
    `6-9,14` for a step numbered past the next range), or a bare range of its own when it
    brings a call the human has to make before it lands
    ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92)).
+   Either way it is a range still to come, never a range that has landed, since that
+   range's call was made and the step would reopen it. A new range takes the next free
+   item number, and no item is renumbered, because the stop card's stamp, the detail
+   file's header, and `plumbbob harvest` find a landed range by its number.
    A step the build order places between two of a range's steps belongs to that range. A
    split or re-cut that moves where a call falls moves the stop with it, so re-cut any
    range the edit breaks, and show the range edit in the same before/after, since it
-   changes where the human will be asked. Then read `plumbbob status`: its ranges block
-   carries a `⚠` row for any range still broken, and none once every undone step sits in
-   exactly one range.
+   changes where the human will be asked. The edit lands on the item's command, the
+   range's definition, not on the command the card names: the card names `/plumbbob:run`
+   for the range, and the turn hook mints a run's grant from the plan as the human types
+   the run, so the next run lands the range as you re-cut it, while a run already typed
+   keeps the grant it minted
+   ([D96 (plan-names-the-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d96)).
+   Then read `plumbbob status`: its ranges block carries a `⚠` row for any range still
+   broken, and none once every undone step sits in exactly one range.
 4. **Revise the step's harness bindings if they drifted too** *(optional)*. If the
    build carries a `harness.json` (beside `intent.md`) and the reality that moved the
    step also changed which agents it wants, sharpen that step's slot bindings

package/skills/verify/SKILL.md

@@ -58,7 +58,11 @@ this skill verifies it the same way: **it reads the diff, not the author**
    "here is the pause", for reading the check verdict back in prose, or for a closing
    courtesy. Each fact appears once, in its part.
 
-   *Write the detail file.* Before you call `plumbbob handoff`, overwrite
+   *Write the detail file.* If `.plumbbob/detail.md` opens on a `# Detail · Range <N>`
+   header and the dashboard above marks that range `← stop card waiting`, that card is still
+   waiting: **refuse**, since writing this skill's detail file would overwrite the range's
+   review, and point the human at the card's own reply (`looks good`, or a change to a
+   lean). Otherwise, before you call `plumbbob handoff`, overwrite
    `.plumbbob/detail.md`. It is the wire handoff parses, and it is the only path by which
    the judgment you formed in steps 2 through 4 reaches the turn:
 

package/templates/intent.md

@@ -69,9 +69,11 @@ characters (GitHub's subject convention: soft, no gate).
 The `(scope)` names the primary code area the step touches (`plan`, `commitmsg`); the
 build's `**Scope:**` header is the feature-level catch-all a step overrides. Scope
 resolves title-scope → `**Scope:**` default → build slug → bare, and type resolves
-title-type → `feat`. Then drive `/plumbbob:build` until done. Later steps may be
-fuzzier than the first; sharpen the next one just-in-time with `/plumbbob:step` (empty input
-auto-syncs it), and use `/plumbbob:refine` to repair the whole plan when a blocker rewrites it.)*
+title-type → `feat`. Then drive the build: `/plumbbob:run` a range at a time when the
+plan cuts ranges below, `/plumbbob:build` a step at a time when it does not. Later
+steps may be fuzzier than the first; sharpen the next one just-in-time with
+`/plumbbob:step` (empty input auto-syncs it), and use `/plumbbob:refine` to repair the
+whole plan when a blocker rewrites it.)*
 
 1. [ ] feat: <step>, **done when:** <criterion, ideally a test or check result>
    - seam: `<file>`, `<file>`
@@ -91,15 +93,17 @@ agree. A step keeps its number for life; this line is where the sequence lives.)
 ## Build ranges
 
 *(Where the build stops for a human call, written with the steps: one numbered item per
-range, the command the human types, then `**stop:**` and the call that ends it, with an
+range, the command that defines it, then `**stop:**` and the call that ends it, with an
 optional `- model:` line naming the model to run it on. The command's form says where it
 stops: a bare `/plumbbob:build 4` builds step 4 to its pause, so its stop is a decision
 made before the step lands, and a span such as `/plumbbob:build 5-9` lands every step it
 names, so its stop is a review of what landed. A range ends where a human call is due
-and nowhere else, so a plan of two or three steps may need one range or none. The card
-names the range to type beneath Next Up and the dashboard lists them, but a range is
-advice, never a grant: the human still types the command (plumbbob
-[D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92)).
+and nowhere else, so a plan of two or three steps may need one range or none. The
+dashboard lists the ranges, and the card names `/plumbbob:run` beneath Next Up for the
+range holding the next step: it runs what is left of that range, and `/plumbbob:run 3`
+runs range 3. The item's command stays the range's definition, and a range grants
+nothing until the human types the run that names it (plumbbob
+[D96 (plan-names-the-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d96)).
 The item below is scaffold while it holds its `<...>` fill-ins; fill it in, or delete
 the section when the build needs no range.)*