plumbbob 0.13.0 → 0.13.1

package/dist/verbs/turn.js

@@ -1,33 +1,39 @@
 // `plumbbob turn`: the turn-ledger hook. Wired to the harness's
-// UserPromptSubmit event, it runs once per human prompt and maintains two of the
+// UserPromptSubmit event, it runs once per prompt and maintains two of the
 // sidecar's git-excluded control files (flat files under `.plumbbob/`): it ticks
 // `TURN`, the monotonic count of human turns the checkpoint latch compares
 // against a step's entry stamp to know a human turn intervened since the step
 // began, and it rewrites `GRANT` from the literal prompt, minting a one-turn
-// self-approval only when the human typed `/build --auto` or an `N-M` step
-// range, clearing it otherwise (those strings can only come from a human
+// self-approval only when the human typed `/build --auto` or a step range
+// (`N-M`, or a list such as `20,5-9`), clearing it otherwise (those strings can only come from a human
 // keystroke, because `build` is disable-model-invocation: a grant the model
-// could forge would be no grant). When a step is in flight it also emits ONE
-// `UserPromptSubmit` additionalContext line so a fresh session (post-compaction,
-// or a scripted `-p` turn where no skill prose is in context) still knows the
-// beat: a tangent is parked, not chased, and a message that also asks something
-// is answered before the park's block. Guidance only: it blocks nothing. It
-// ALWAYS exits 0 and any failure degrades to no output, so neither the tick nor
-// the emit can ever wedge prompting.
+// could forge would be no grant). The harness also sends a background job's
+// completion notice through this event, as a prompt the human never typed, so
+// a notice ticks nothing, keeps the grant, and clears only the ending `RELAY`
+// holds from an earlier turn. When a step is in flight a typed prompt also
+// emits ONE `UserPromptSubmit` additionalContext line so a fresh session
+// (post-compaction, or a scripted `-p` turn where no skill prose is in context)
+// still knows the beat: a tangent is parked, not chased, and a message that
+// also asks something is answered before the park's block. Guidance only: it
+// blocks nothing. It ALWAYS exits 0 and any failure degrades to no output, so
+// neither the tick nor the emit can ever wedge prompting.
 import { readFileSync, writeFileSync } from 'node:fs';
-import { findSessionRoot, setGrant, stepPath, turnPath } from "../lib/sidecar.js";
+import { clearRelay, findSessionRoot, notePrompt, readPrompt, setGrant, stepPath, turnPath, } from "../lib/sidecar.js";
+import { normalizeStepList, readBuildArgs } from "../lib/steplist.js";
 /**
- * The hook entry point: apply the tick, then emit the in-flight-step nudge.
+ * The hook entry point: apply the prompt, then emit the in-flight-step nudge
+ * when it counted as a human turn.
  *
  * Always returns 0: a broken turn must never wedge a prompt, so any failure is
  * swallowed and degrades to no output.
  */
 export function turn(cwd, _args) {
     try {
-        applyTurn(cwd, readStdin());
-        const context = stepInFlightContext(cwd);
-        if (context !== null)
-            process.stdout.write(context);
+        if (applyTurn(cwd, readStdin())) {
+            const context = stepInFlightContext(cwd);
+            if (context !== null)
+                process.stdout.write(context);
+        }
     }
     catch {
         // A broken turn must never wedge a prompt: swallow and exit 0.
@@ -78,7 +84,17 @@ function inFlightStep(root) {
     }
 }
 /**
- * The testable core: apply one tick given the raw hook stdin.
+ * The testable core: apply one prompt given the raw hook stdin, and say
+ * whether it counted as a human turn.
+ *
+ * A typed prompt ticks TURN and rewrites GRANT. A notice touches neither,
+ * because the latch reads TURN passing a step's entry stamp as its one sign
+ * that a human answered, and a grant the human typed has to outlive a job
+ * that reports back partway through the range. A notice that starts a turn of
+ * its own clears RELAY, whose ending was judged when its own turn ended; one
+ * the harness folds into the running turn arrives under that turn's prompt id
+ * and leaves RELAY alone, since the ending the turn just printed has yet to be
+ * judged.
  *
  * Split from the fd-0 read so the unit tests can drive it directly: an
  * in-process test cannot feed fd 0 (the same constraint checkpoint's `--body`
@@ -87,10 +103,35 @@ function inFlightStep(root) {
 export function applyTurn(cwd, raw) {
     const root = findSessionRoot(cwd);
     if (root === null)
-        return 0; // no active session above cwd: silent no-op.
-    writeFileSync(turnPath(root), `${readTurn(root) + 1}\n`);
-    setGrant(root, grantFromPrompt(extractPrompt(raw)));
-    return 0;
+        return false; // no active session above cwd: silent no-op.
+    const { prompt, promptId } = readPayload(raw);
+    const notice = isNotice(prompt);
+    if (notice) {
+        if (promptId === null || promptId !== readPrompt(root))
+            clearRelay(root);
+    }
+    else {
+        writeFileSync(turnPath(root), `${readTurn(root) + 1}\n`);
+        setGrant(root, grantFromPrompt(prompt));
+    }
+    // Last, so a record that cannot be written never costs the tick or the grant.
+    notePrompt(root, promptId);
+    return !notice;
+}
+/**
+ * Whether a prompt is the harness reporting on background work rather than
+ * the human typing.
+ *
+ * Nothing in the payload marks one, but every notice opens on a frame of the
+ * harness's own at its very first character: `<task-notification>` for a
+ * finished shell job, a Monitor event, or a subagent's task, and
+ * `<agent-message ` for a subagent's or another session's report. A misread
+ * errs safe: a typed prompt taken for a notice costs one tick and one grant,
+ * so the latch only grows stricter, while a notice taken for a typed prompt
+ * is a turn no human took.
+ */
+export function isNotice(prompt) {
+    return prompt.startsWith('<task-notification>') || prompt.startsWith('<agent-message ');
 }
 /**
  * Derive the GRANT content from the human's prompt, or null to clear it.
@@ -98,9 +139,12 @@ export function applyTurn(cwd, raw) {
  * A grant is minted only from a literal `build` invocation the human typed:
  * `build` is disable-model-invocation, so this string can only come from a
  * human keystroke, never model-authored pressure: a grant the model can forge
- * is no grant. A bounded range beats `--auto` (bounded wins); a bare
- * `/build`, or any non-invocation prompt, mints nothing. The namespaced
- * `/plumbbob:build` form is honored alongside the bare one.
+ * is no grant. A range mints `steps <list>`, exactly the steps it names in
+ * their normal form (`20, 5-9` mints `steps 5-9,20`), and beats `--auto`
+ * (bounded wins), so a range that does not parse mints nothing rather than
+ * falling back to `auto`. A bare `/build`, a bare step number, or any
+ * non-invocation prompt mints nothing. The namespaced `/plumbbob:build` form is
+ * honored alongside the bare one.
  *
  * The invocation must *start* a token: a slash preceded by a word character,
  * `/`, `.`, `-`, or `~` is a path segment (`src/build`, `./build`), not a
@@ -120,43 +164,30 @@ export function grantFromPrompt(prompt) {
     if (invocation === null)
         return null;
     const line = prompt.slice(invocation.index + invocation[0].length).split('\n', 1)[0] ?? '';
-    let auto = false;
-    let ceiling;
-    for (const token of line.split(/\s+/)) {
-        const word = token.replace(/[.,;:!?]+$/, '');
-        if (word === '')
-            continue;
-        if (word === '--auto') {
-            auto = true;
-            continue;
-        }
-        const range = /^\d+-(\d+)$/.exec(word);
-        if (range !== null) {
-            ceiling = range[1];
-            continue;
-        }
-        if (/^\d+$/.test(word))
-            continue; // a bare step number: keep scanning for a range/--auto
-        break; // an unrecognized flag or free text: the arguments have ended
-    }
-    if (ceiling !== undefined)
-        return `range ${ceiling}`;
-    return auto ? 'auto' : null;
+    const args = readBuildArgs(line);
+    if (args.range)
+        return args.steps === null ? null : `steps ${normalizeStepList(args.steps)}`;
+    return args.auto ? 'auto' : null;
 }
 /**
- * Extract the `prompt` field from the UserPromptSubmit JSON, or '' otherwise.
+ * The `prompt` and `prompt_id` fields of the UserPromptSubmit JSON, as '' and
+ * null when either is absent.
  *
  * Absent, unparseable, or non-string input contributes nothing rather than
- * wedging the tool: the tick still lands (a human turn did occur) and the empty
- * prompt clears any GRANT; the verb never throws over bad stdin.
+ * wedging the tool: the tick still lands (a human turn did occur), the empty
+ * prompt clears any GRANT, and a missing id records none; the verb never
+ * throws over bad stdin.
  */
-function extractPrompt(raw) {
+function readPayload(raw) {
     try {
         const parsed = JSON.parse(raw);
-        return typeof parsed.prompt === 'string' ? parsed.prompt : '';
+        return {
+            prompt: typeof parsed.prompt === 'string' ? parsed.prompt : '',
+            promptId: typeof parsed.prompt_id === 'string' && parsed.prompt_id !== '' ? parsed.prompt_id : null,
+        };
     }
     catch {
-        return '';
+        return { prompt: '', promptId: null };
     }
 }
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "plumbbob",
-  "version": "0.13.0",
+  "version": "0.13.1",
   "description": "Attention-first build process: 15 skills + a CLI that keep you the decider — guidance on the work, a latch on the record.",
   "keywords": [
     "claude-code",

package/skills/build/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: build
-description: "The default engine: read the next planned step from intent, implement it (its done-when, seam, Decisions, Constraints), then verify it through to the approval pause. Swappable: build by hand/vibed/another harness and run /plumbbob:verify instead. `--auto` self-approves and chains to done; a step range like `1-3` self-approves through step 3, then stops."
-argument-hint: "[step-number | step-range] [--auto]"
+description: "The default engine: read the next planned step from intent, implement it (its done-when, seam, Decisions, Constraints), then verify it through to the approval pause. Swappable: build by hand/vibed/another harness and run /plumbbob:verify instead. `--auto` self-approves and chains to done; a step range like `1-3`, or a list like `20,5-9`, self-approves exactly the steps it names, in build order, then stops."
+argument-hint: "[step-number | step-range | step-list] [--auto]"
 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:*)
 ---
@@ -35,9 +35,10 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
 ## What this skill does, in order
 
 1. **Pick the step.** Use the number you were invoked with (for example `/plumbbob:build 4`), or,
-   if you were given a range like `/plumbbob:build 1-3`, start at the first number and treat
-   the second as the last step you approve and land yourself (see the range note under
-   `--auto`). With no argument, don't resolve the next step yourself; the CLI does: bare `plumbbob build`
+   if you were given a range like `/plumbbob:build 1-3` or a list like `/plumbbob:build 20,5-9`,
+   start at its first undone step in build order, the one the dashboard above marks
+   `← requested`, and land only the steps it names (see the range note under `--auto`).
+   With no argument, don't resolve the next step yourself; the CLI does: bare `plumbbob build`
    (step 2) enters the next undone step in build order (the `## Build order` line when the
    plan has one, else the numbering) and refuses with a `/plumbbob:step` nudge when every
    step is checkpointed.
@@ -181,6 +182,12 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
    line in the build-log's `## Log` and then truncates it, so the detail lands in the
    tracked ledger rather than piling up on disk.
 
+   **A bare range's pause is its stop.** When the injected dashboard's ranges block lists
+   this step as a bare range (`/plumbbob:build 5`, its row marked `▸`), the plan reserved a
+   call for this pause, and the `stop:` line beneath the row names it. The recommendation
+   speaks to that call: the move you would take on the plan's question, and why, rather
+   than a verdict on the diff alone.
+
    *Paste the turn.* Run `plumbbob handoff` and paste its output whole, verbatim, at top
    level, trailing blank line included, then end the turn. Never nest it inside a fence of
    your own; it carries fences of its own and they cannot nest. It prints the Now line
@@ -223,8 +230,11 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
 
    **Then hand off with the next model.** `plumbbob checkpoint` prints the whole boundary
    ending itself: `**Checkpoint**: Step N complete (<sha>)`, the Verdict the step earned,
-   any advisory (a staged path outside the seam is the common one), and Next Up. Relay
-   that block whole, run no second command, and write nothing around it. It is the
+   any advisory (a staged path outside the seam is the common one), the Stop part when
+   this landing completes a range (`**Stop**: Range 3 of 5 landed - <its stop>`, the reason
+   the build stops here), and Next Up. Relay that block whole, the Stop part with the rest
+   (the relay check holds a boundary that dropped it), run no second command, and write
+   nothing around it. It is the
    orientation tier (no Your Call block, no recommendation), and it points at the next
    undone step carrying that step's `- model:` recommendation (the plan's
    smallest-model-that-fits call) so the human knows which `/model` to select before
@@ -287,7 +297,18 @@ and approves in the human's place**, and it **chains**:
     advance the loop), or a new decision is needed. The step is still in flight and the
     human has a call to make about it, so end on the same turn the default pause does:
     write the detail file, run `plumbbob handoff`, and paste its block.
-  - **A clean halt lands its step first.** The top of a requested range is reached, or no
+  - **A call the plan reserves halts at its pause.** A step the plan's `## Build ranges`
+    names as a bare range (`/plumbbob:build 10`) is a decision the plan left for the human,
+    and `plumbbob build` says so as it enters the step (`step 10 ends at its pause, where
+    the plan reserves the call for the human`). Build it, verify it, and end on the same
+    turn a halt on trouble does: write the detail file, run `plumbbob handoff`, and paste
+    its block. The latch would let it land, since `--auto` grants every step, so keeping
+    the step open is yours to do
+    ([D94 (auto-and-stops)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d94)).
+    A range that lands its steps runs through, since its stop is a review that can wait
+    for the end of the run, and a typed range stays exactly as typed.
+  - **A clean halt lands its step first.** The top of a requested range is reached (the
+    next step in build order is one the range does not name, or none is left), or no
     planned steps remain, and `plumbbob build` names that step as it enters it (for
     example `step 3 is the last undone step in the plan`). That step checkpoints like
     every step before it, and its
@@ -302,36 +323,54 @@ only because the human asked for it by name. A range hands the clock back once i
 step has landed: the step after it waits for the human's next run. The default (no flag,
 no range) always ends at the pause.
 
-### A step range (`N-M`) is a bounded `--auto`
+### A step range (`N-M`, or a list like `20,5-9`) is a bounded `--auto`
 
 `/plumbbob:build 1-3` self-approves steps 1 through 3 exactly as `--auto` does, then **stops
-once step 3 has landed** instead of chaining to done. The range *is* the opt-in; you do not
-also pass `--auto`. Run it as the `--auto` loop with one extra halt: **stop before building
-any next step whose plan number is past the top of the range.** It adds no machinery: just
-the one more entry already in the halt list above, and it is a clean halt, so the top step
-is never held back for approval. The human approved it by typing the range, and
-`plumbbob build` says so as it enters that step:
-`step 3 is the top of the range you granted`, or, when the plan ends first,
+once step 3 has landed** instead of chaining to done. A range may also list its steps, numbers
+and spans joined by commas (`/plumbbob:build 20,5-9`, typed with or without a space after a
+comma), and it grants exactly the steps it names: the checkpoint refuses any other
+([D91 (step-list-grants)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d91)).
+The range *is* the opt-in; you do not also pass `--auto`.
+
+Run it as the `--auto` loop, walked in build order. **Start at the range's first undone step
+in build order, however it is written** (`5-9,20` under an order that puts 20 first starts at
+20), and after each landing take the next undone step in build order. Build it if the range
+names it; **stop before building any step the range does not name**, or once none is left. It
+adds no machinery: just the one more entry already in the halt list above, and it is a clean
+halt, so the top step is never held back for approval. The human approved it by typing the
+range, and `plumbbob build` says so as it enters that step:
+`step 3 is the top of the range you granted`, or, when the walk ends early (the plan runs
+out, or the next step in build order is one the range does not name),
 `the last undone step in the range you granted`.
 
-- **`N-M` with N ≤ M**: build N…M, self-approving and checkpointing each, M included, then
-  relay M's checkpoint block and end the turn. `N-N` is a range like any other: it builds
-  and lands the single step `N`. Only a bare `/plumbbob:build N` ends at the pause.
-- **N > M** (for example `3-1`): that is not a range you can walk; report it and stop rather
-  than guess the intent.
-- **M past the last planned step** (for example `1-9` with three steps): build through the
-  last planned step and stop; that is the existing "no planned steps remain" halt, not
-  an error.
-- **A step inside the range won't build** (missing, or its seam won't parse): `plumbbob
-  build <n>` fails exactly as it always does; surface it and stop, the same as a red
-  check. Do not skip past the gap.
-- **N is above the next undone step**: you are jumping over earlier planned work; note
-  that you are skipping the steps before N, then proceed (the same latitude as a
+- **A range that parses**: build each step it names in build order, self-approving and
+  checkpointing each, the last included, then relay the last one's checkpoint block and end
+  the turn. `N-N` is a range like any other: it builds and lands the single step `N`. Only a
+  bare `/plumbbob:build N` ends at the pause.
+- **A range that does not parse** (for example `3-1`, or `1--3`): that is not a range you can
+  walk, and it grants nothing; report it and stop rather than guess the intent.
+- **A number past the last planned step** (for example `1-9` with three steps): build through
+  the last planned step the range names and stop; that is the existing "no planned steps
+  remain" halt, not an error. A number the plan lacks is never reached.
+- **A step inside the range won't build** (its seam won't parse): `plumbbob build <n>` fails
+  exactly as it always does; surface it and stop, the same as a red check. Do not skip past
+  the gap.
+- **The range starts above the next undone step**: you are jumping over earlier planned work;
+  note that you are skipping the steps before it, then proceed (the same latitude as a
   single-number jump like `/plumbbob:build 4`).
-- **The build order puts a number past the top ahead of the rest** (the order reads
-  `1, 4, 2, 3` under `/plumbbob:build 1-3`): a range names plan numbers, so the halt above
-  fires before step 4 and `plumbbob build` names step 1 as the last undone step in the
-  range. Build a re-sequenced stretch step by step, or grant `--auto`.
+- **The build order puts a step the range does not name inside it** (the order reads
+  `1, 4, 2, 3` under `/plumbbob:build 1-3`): the halt above fires before step 4, and
+  `plumbbob build` names step 1 as the last undone step in the range. The range that walks
+  the whole stretch lists step 4 too (`/plumbbob:build 1-4`, or `/plumbbob:build 1,4,2,3`).
+- **At a range's stop, harvest before the next range.** No harvest runs between the steps
+  inside a range, so the parks pile up, and a blocker among them would otherwise ride into
+  the next one. When the human asks what comes next at a stop with parks open (the note's
+  `parked 2 of 7 open`), the move is `/plumbbob:harvest`, then the range the card names.
+- **After an early stop, settle the step, then rerun what is left.** A halt on trouble
+  inside a range ends at that step's pause, and the grant ends with the turn. Once the
+  human approves and the step lands, the note beneath Next Up names what is left of the
+  range (`· range 3 of 5: /plumbbob:build 8-9`), and that is the command the human types
+  to carry on.
 
 ## The hard contracts
 

package/skills/harvest/SKILL.md

@@ -23,6 +23,10 @@ DESIGN boundary, not mid-step. Read the dashboard injected above:
   Chasing parked items mid-step is the disease parking prevents.
 - At the boundary (the dashboard reads `[DESIGN]`): go ahead.
 
+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.
+
 ## What this skill does
 
 Walk the **Park list** in `build-log.md` item by item and, for each, **propose exactly
@@ -47,6 +51,11 @@ one line of reasoning, then **wait for the human to confirm or override**. Write
   (`- <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.
+  `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
+  ([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.
 - Never reclassify or resolve an item the human hasn't confirmed, and default every
   uncertain item to **tangent**, never to blocker.

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:*)
@@ -117,7 +117,48 @@ 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, 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 command; 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.
+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 +179,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,8 +189,9 @@ 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)),
@@ -182,7 +224,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 +240,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,24 @@ 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), and 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/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,9 @@ 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. 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.
+4. If it reads `NO ACTIVE SESSION`, tell the human to `/plumbbob:plan` to frame a goal.