plumbbob 0.12.1 → 0.13.1

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/park/SKILL.md

@@ -47,6 +47,13 @@ Then:
    the capture plus that one pointer are the whole turn, and both are the CLI's to render,
    never yours to compose from the dashboard. The capture is a one-beat interruption; the
    step keeps its focus.
+4. **A question beside the tangent is answered first.** When the human's message also
+   asks something, answer the question, then relay the park's block after the answer,
+   and write nothing after it. A message that is only a tangent ends on the block alone.
+   Either way the block's pointer back at the step closes the turn, so run no
+   `plumbbob handoff` after it. The answer is what the human asked for; dropping it to
+   keep the block alone, or stacking a second ending under the block, are the two ways
+   this goes wrong.
 
 ## 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:
@@ -207,6 +251,7 @@ left, the findings first and the recommendation last:
 # Detail · Plan · <the title>
 
 ## 1 <the first hole: one sentence, naming where it sits in intent.md>
+
 <what it is, and what closing it would take>
 
 ## 2 ...

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.

package/skills/step/SKILL.md

@@ -53,6 +53,18 @@ 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)).
+   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.
 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 +78,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

@@ -76,6 +76,7 @@ this skill verifies it the same way: **it reads the diff, not the author**
    short paragraph when the step needs explaining>
 
    ## 1 <the first highlight: one sentence, one move>
+
    <the full story: what moved, why, what was tried and dropped>
 
    ## 2 ...
@@ -118,26 +119,42 @@ this skill verifies it the same way: **it reads the diff, not the author**
    turn. The number is what lets a diff built outside `/plumbbob:build` reach its pause:
    nothing is in flight for that diff, and a bare `handoff` would read the moment as a
    boundary and render no Your Call block. Never nest it inside a fence of
-   your own; it carries fences of its own and they cannot nest. It prints the Summary and
-   its highlights, the Readout fence (its measured `check`, `seam`, `diff`, and `spent`
-   rows folded with your three), a `diff` fence when the change is 20 lines or fewer, the
-   Verdict folded worst-of from the same rows, Next Up, Your Call, and your recommendation
-   last. At the pause the check row reads green, since a red one stopped you back at step
-   1. The gate verdict's one home is that row: no standalone verdict line exists, and you
-   never restate the verdict in prose. A narrowed run names the slots it skipped there
-   (`· without test`), and that named narrowing is the whole disclosure. The notice
-   checkride's Stop hook appends after your turn is not yours to relay or repeat; the
-   trailing blank line you kept is what lands it on its own line. Relayed CLI strings keep
-   their em-dashes; your own lines never use one, the write-versus-relay line of
+   your own; it carries fences of its own and they cannot nest. It prints the Now line
+   naming the step you reviewed, the Summary and its highlights, the Readout fence (its
+   measured `check`, `seam`, `diff`, and `spent` rows folded with your three), a `diff`
+   fence when the change is 20 lines or fewer, the Verdict folded worst-of from the same
+   rows, Next Up, Your Call, and your recommendation last. Run it once: a second run at an
+   unchanged pause prints the one-line reminder instead of the card, so if that line comes
+   back where the card belongs (you ran handoff earlier in this turn), run
+   `plumbbob handoff <n> --full` and paste that. At the pause the check row reads green,
+   since a red one stopped you back at step 1. The gate verdict's one home is that row:
+   no standalone verdict line exists, and you never restate the verdict in prose. A
+   narrowed run names the slots it skipped there (`· without test`), and that named
+   narrowing is the whole disclosure. The notice checkride's Stop hook appends after your
+   turn is not yours to relay or repeat; the trailing blank line you kept is what lands it
+   on its own line. Relayed CLI strings keep their em-dashes; your own lines never use
+   one, the write-versus-relay line of
    [D78 (em-dash-ban)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d78).
 
    *Then read the reply as an ask or a direction.* A message that **asks** ("expand 2",
-   "what does that mean?", "why did the seam row flag that?") is an expand: answer it from the detail file, from
-   `git diff`, or from the build-log's `## Log` for an older step, never from recall, then run `plumbbob handoff <n>` again and
-   paste it. The step has not landed, so it renders the same pause, and the Your Call
-   block stays the CLI's to render rather than yours to retype. A message that **directs**
-   is needs-work: take it as what to change, and nothing lands until the human says
-   `looks good`.
+   "what does that mean?", "why did the seam row flag that?") is an expand: answer it from
+   the detail file, from `git diff`, or from the build-log's `## Log` for an older step,
+   never from recall, then run `plumbbob handoff <n>` and paste its output beneath your
+   answer, whole and verbatim. The turn is your answer, then that output, and nothing after
+   it. The pause renders its card once
+   ([D87 (pause-once)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d87)):
+   while nothing about it has changed, handoff prints one line,
+   `**Next Up**: Back to Step <N> of <M> - <title>`, in place of the card the human already
+   read, so your answer stays on screen. The CLI picks the form, never you: paste whichever
+   one it prints, and never retype the card or reach for `--full` to put it beneath an
+   answer.
+
+   Two moments bring the whole card back, and in both you run `plumbbob handoff <n> --full`
+   and paste its output whole, with nothing written around it: the human asks to see the
+   pause (`show the pause`, or any wording of it), or the card is not in this conversation
+   (a fresh session, or one after `/clear`, that finds the step still at its pause). A
+   message that **directs** is needs-work: take it as what to change, and nothing lands
+   until the human says `looks good`.
 
    - **Reconcile a drifted subject here, in the open.** The planned title *is* the
      checkpoint subject ([D68 (conventional-subjects)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d68)). If the diff drifted from it (the
@@ -203,7 +220,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.**

package/templates/intent.md

@@ -82,11 +82,29 @@ auto-syncs it), and use `/plumbbob:refine` to repair the whole plan when a block
 ## Build order
 
 *(Optional. The sequence to build the steps in once it stops being their numbering: one
-line of comma-separated step numbers, such as `7, 8, 5, 10, 6`; empty means document
-order. `plumbbob order 7 8 5 10 6` (`/plumbbob:order`) writes it, and `status`, `build`,
-`checkpoint`, and `handoff` all read it, so the dashboard's `← next`, a bare
-`/plumbbob:build`, and the card's Next Up agree. A step keeps its number for life; this
-line is where the sequence lives.)*
+line of step numbers and spans, comma-separated, such as `7, 8, 5, 10, 6` or
+`1, 6, 2-4, 7, 5`; empty means document order. `plumbbob order 7 8 5 10 6`
+(`/plumbbob:order`) writes it, and `status`, `build`, `checkpoint`, and `handoff` all
+read it, so the dashboard's `← next`, a bare `/plumbbob:build`, and the card's Next Up
+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
+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)).
+The item below is scaffold while it holds its `<...>` fill-ins; fill it in, or delete
+the section when the build needs no range.)*
+
+1. `/plumbbob:build <N-M>`, **stop:** <the call that is the human's here: a decision the plan leaves open, a review before later steps build on what landed, or a thing only a human can do>
+   - model: <the strongest model any step inside it recommends>
 
 ## Open questions