plumbbob 0.13.0 → 0.13.2

package/skills/order/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: order
 description: "Set the build order: turn the human's sequence (or a relative one, such as 7 and 8 before 5) into the full list of undone steps and write it by shelling `plumbbob order`, never by editing intent.md. A step keeps its number; the sequence moves."
-argument-hint: "[steps in the sequence to build them]"
+argument-hint: "[steps in the sequence to build them, such as 1, 6, 2-4, 7, 5]"
 disable-model-invocation: true
 model: haiku
 allowed-tools: Bash(plumbbob status:*), Bash(plumbbob order:*)
@@ -27,20 +27,30 @@ after the step in flight is the usual reason to run it.
 ## What this skill does
 
 1. **Compose the full sequence.** Read the step list and the `build order` row on the
-   dashboard. Take the human's instruction, whether a full list (`7 8 5 10 6`) or a relative
-   one ("7 and 8 before 5", "10 last"), and turn it into **every undone step, in the sequence
-   to build them**. Never renumber a step and never move one inside `## Steps`; the sequence
-   lives in this one line.
+   dashboard. Take the human's instruction, whether a full list (`7 8 5 10 6`, or
+   `1, 6, 2-4, 7, 5` with spans and commas) or a relative one ("7 and 8 before 5", "10
+   last"), and turn it into **every undone step, in the sequence to build them**. Never
+   renumber a step and never move one inside `## Steps`; the sequence lives in this one
+   line.
 2. **Show the sequence and get the human's OK in-turn.** When the human's own message states
    the full sequence, that message **is** the approval: run the verb directly.
-3. **Write it by shelling `plumbbob order 7 8 5 10 6`** via Bash. `plumbbob order --reset`
-   drops the line, and the plan reads in document order again.
+3. **Write it by shelling `plumbbob order 7 8 5 10 6`** via Bash. The verb reads spans and
+   commas, with or without a space after one, so a list typed as `1, 6, 2-4, 7, 5` goes to it
+   as typed, and the line it writes spells the span out. `plumbbob order --reset` drops the
+   line, and the plan reads in document order again.
 4. **Relay the ending verbatim, then stop.** The verb prints its whole ending: the
    `**Build order**: 7, 8, 5, 10, 6` line, a blank line, and the `**Next Up**` pointer (back
    at the step in flight, or forward to the first step in the new sequence). Run no second
-   command. A refusal (a number the plan lacks, a repeat, a step already checkpointed) is the
-   CLI's call: report it verbatim, never retry or work around it, and ask the human which
-   number they meant.
+   command but the one in step 5. A refusal (a number the plan lacks, a repeat, a step
+   already checkpointed) is the CLI's call: report it verbatim, never retry or work around
+   it, and ask the human which number they meant.
+5. **Read the ranges when the plan has them.** If the dashboard injected above shows a
+   `ranges` block, run `plumbbob status` after the verb and read that block again. A `⚠`
+   row that was not there before means the new sequence broke a range (most often
+   `the build order puts step 11 inside it`). This skill edits nothing, so it cannot re-cut
+   one: open the turn with one line naming the range, its drift words, and
+   `/plumbbob:refine` as the move that re-cuts it, then the verb's ending, whole, as the
+   turn's last text. With no new `⚠` row, or no ranges block, relay the ending alone.
 
 ## The one hard contract
 

package/skills/plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plan
-description: "Frame a fresh goal and author the whole plan (Frame, Decisions, Constraints, and all Steps) before any code. Three input modes: no arg interviews you; a file path (or @-mention) absorbs a spec; any other text expands your inline intent."
+description: "Frame a fresh goal and author the whole plan (Frame, Decisions, Constraints, all Steps, and the build ranges) before any code. Three input modes: no arg interviews you; a file path (or @-mention) absorbs a spec; any other text expands your inline intent."
 argument-hint: "[spec-path | intent]"
 disable-model-invocation: true
 allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob handoff:*), Bash(plumbbob start:*), Bash(plumbbob checkpoint:*), Bash(plumbbob agent list:*)
@@ -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
 
@@ -117,7 +120,58 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
    It is advisory metadata for the human (`/plumbbob:status` surfaces it before each build),
    never a gate, and nothing switches models automatically. Write it plain (no
    backticks) and omit it when any model would do.
-5. **Offer harness bindings** *(optional)*. If the build will lean on
+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, 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
+      - model: opus
+   2. `/plumbbob:build 2-5`, **stop:** review the parser before the renderers build on it
+      - model: sonnet
+      - note: <optional; what the range should watch for>
+   ```
+
+   **A range ends where a human call is due, and nowhere else.** Three things make a
+   call: a decision the plan leaves open (an Open question, or a fork only a spike can
+   settle), a review before later steps build on what landed, and a thing only the human
+   can do, such as a push, a live key, or spending money. A range that runs through one
+   has the model make the human's call; a stop that marks none of them is a pause nobody
+   needed. The command's form says what kind of stop it is
+   ([D85 (range-top-lands)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d85)).
+   A span such as `2-5` lands every step it names and stops at the boundary after the
+   last, so its stop is a review of what landed, or a decision the next steps need before
+   they build. A bare `N` builds step N to its pause, so write one for a call that has to
+   be made before its step lands, on the step's own work: approving the wording it
+   drafted, or the rule it found. Write each stop as what the human decides or reviews
+   there, in words they can act on cold.
+
+   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 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, 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
    plan-adjacent configuration, so they converge with the plan. It binds agents to a
@@ -138,7 +192,7 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
    `note` and decides when to run one mid-build. Skip the file entirely when no step
    uses an agent; the loop runs identically without it. The plan commit picks it
    up automatically (it lives in the build folder).
-6. **Commit the plan.** Once the human approves the frame and steps, run
+7. **Commit the plan.** Once the human approves the frame and steps, run
    `plumbbob checkpoint --plan` to commit the scaffold on its own: subject
    `chore(<scope>): plan` (with a `plumbbob plan` body marker), only `.plumbbob/builds/<slug>/`,
    a `plan <sha>` line in
@@ -148,16 +202,19 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
    rationale is worth carrying; skip it for a small plan. Do this
    only on the human's approval; the plan is their convergence.
    - **The plan pause is a decision turn.** Present the framed plan for the human's call,
-     then give it the cold read (**§ The cold read**), write the result into
-     `.plumbbob/detail.md`, and relay `plumbbob handoff --plan`'s block whole: the CLI
+     its build ranges with it (each range's command and its stop, since a stop is where
+     the human will be asked, and moving one is cheapest now), then give it the cold
+     read (**§ The cold read**), write the result into `.plumbbob/detail.md`, and relay `plumbbob handoff --plan`'s block whole: the CLI
      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
@@ -168,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:
@@ -182,7 +240,7 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
        (the `--body` earns its keep here), the files staying untracked. Say that
        instead: the rationale is published in `git log`, not the folder, so pass a
        fuller `--body` than you otherwise would, since the message is the whole record.
-7. **Offer to stress-test it.** Suggest `/plumbbob:refine` to attack the frame for holes (or
+8. **Offer to stress-test it.** Suggest `/plumbbob:refine` to attack the frame for holes (or
    to repair the plan as it drifts). Optional, the human's call.
 
 ## The cold read
@@ -198,7 +256,9 @@ Open questions, and keep it to one screen of reading. The lens:
 - a collision with the existing code (read the files the seams name);
 - a done-when no test or check can measure, or a seam that names a file that does not
   exist or misses one that must change;
-- a step too large to review in one pass, or a Decision with no *because*.
+- a step too large to review in one pass, or a Decision with no *because*;
+- a range that runs through a call the plan leaves open, so the model would make it;
+- a range that stops where no call is due, a pause the human did not need.
 
 Write what you found into `.plumbbob/detail.md`, overwriting whatever a past session
 left, the findings first and the recommendation last:

package/skills/refine/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: refine
-description: "Keep intent.md true: attack the plan for holes (append as Open questions) and refine or repair the Frame, Decisions, Constraints, and Steps to match reality. Usable at any point; you propose, the human approves."
-argument-hint: "[focus]"
+description: "Keep intent.md true: attack the plan for holes (append as Open questions) and refine or repair the Frame, Decisions, Constraints, Steps, and build ranges to match reality (`ranges` re-cuts the whole section). Usable at any point; you propose, the human approves."
+argument-hint: "[focus | ranges]"
 disable-model-invocation: true
 allowed-tools: Read, Edit, Bash(plumbbob status:*), Bash(plumbbob order:*)
 ---
@@ -22,7 +22,7 @@ it is `NO ACTIVE SESSION`, **refuse** in one line and tell the human to run
 `plumbbob start "<title>"` (or `/plumbbob:plan`) first, and edit nothing. Every active state
 is fine; refining is always available.
 
-## Two modes
+## Two modes, and a re-cut
 
 - **Attack (diverge in the problem space).** Hand the **Frame**, **Decisions**, and
   **Architecture sketch** a cold, adversarial read and surface holes: ambiguities,
@@ -57,6 +57,27 @@ is fine; refining is always available.
   sequence to build them, and the `## Build order` line it writes is what every next-step
   pick follows. Never renumber, and never edit that line by hand.
 
+  **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), 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
+  puts inside a range that does not name it, and an undone step no range names, and none
+  once the section is sound.
+- **Re-cut the ranges (`/plumbbob:refine ranges`).** On request, re-cut the whole
+  `## Build ranges` section against the plan as it stands, by the rule `/plumbbob:plan`
+  cuts it with: a range ends where a human call is due (a decision the plan leaves open,
+  a review before later steps build on what landed, or a thing only the human can do)
+  and nowhere else, a bare build for a call made on a step's own work before it lands,
+  every undone step in exactly one range, walked in build order, and a `- model:` line
+  per range. A landed range stays as written, since its call was made. Show the section
+  before and after, and write only what the human approves.
+
 ## The hard contracts
 
 - **You propose; the human converges.** Surface holes and draft repairs, but the human

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

@@ -11,8 +11,8 @@ allowed-tools: Bash(plumbbob status:*)
 Current session state (injected when this skill runs): !`plumbbob status 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."`
 
 This is a **thin driver** for `plumbbob status`. The dashboard above is your
-orientation: the intent, the step list, the parked/open-question counts, and the
-inferred next move. Report it verbatim and point the human at that next move. This
+orientation: the intent, the step list, the build ranges when the plan has them, the
+parked/open-question counts, and the inferred next move. Report it verbatim and point the human at that next move. This
 skill carries **no Edit and no Write tool**: the CLI is the source of truth, so
 **never retry**, and never edit a file to change what the orientation says.
 
@@ -31,4 +31,11 @@ annotate it.
    can switch (for example `/model sonnet`) before firing `/plumbbob:build`, or ignore it.
    Guidance, never a gate. You relay that line; you do not re-state it on top of the
    verbatim dashboard.
-3. If it reads `NO ACTIVE SESSION`, tell the human to `/plumbbob:plan` to frame a goal.
+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. 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

@@ -53,6 +53,27 @@ grew, but its everyday job is to sharpen, not to invent.
    renumbering: shell `plumbbob order 7 8 5` with every undone step in the sequence to
    build them, and the `## Build order` line it writes is what `status`, a bare
    `/plumbbob:build`, and the card's Next Up then follow.
+
+   **Keep the build ranges true.** When the plan carries `## Build ranges`, a step you add
+   goes into a range: the one it builds with (`/plumbbob:build 6-9` becomes `6-10`, or
+   `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. 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
@@ -66,9 +87,10 @@ grew, but its everyday job is to sharpen, not to invent.
 
 - **One verifiable increment.** Each step carries a done-when `/plumbbob:verify` can check
   and a seam small enough to review in one pass.
-- **Edit `## Steps` only**, in the standard format `status` and `build` parse: never
-  the Roadmap, never loose prose. A done step (`[x]`) is history; do not rewrite it. The
-  `## Build order` line is `plumbbob order`'s to write, never yours to edit.
+- **Edit `## Steps` only**, in the standard format `status` and `build` parse, plus the
+  `## Build ranges` items a step edit moves: never the Roadmap, never loose prose. A done
+  step (`[x]`) is history; do not rewrite it. The `## Build order` line is
+  `plumbbob order`'s to write, never yours to edit.
 - **Cite the plan's own numbers in the linked form.** A `D`/`C`/`Q` you write into a
   step's done-when, seam, or notes reads `[D4 (default-waves)](#d4)`; the slug travels
   with the number, and the link lands on the `<a id="d4">` anchor minted where the item

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:
 
@@ -220,7 +224,7 @@ the checkpoint land when you run it again. **Never reach for a raw `git commit`
 land**; that forges the very record the latch exists to keep honest, and the
 commit-ask hook asks the human about it anyway. The refusal is a healthy latch doing its
 job on the *record* while the *work* plane stays free; a `/plumbbob:build --auto` or
-a typed step range in the human's own prompt is the only self-approval; **never write
+a typed step range (`1-3`, or a list like `20,5-9`) in the human's own prompt is the only self-approval; **never write
 `auto` into a settings file to unlock the land; the latch ignores a model-minted grant
 ([D67 (auto-not-a-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d67)), so ask the human to type `/plumbbob:build --auto` again
 instead.**