plumbbob 0.13.0 → 0.13.1

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

@@ -220,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