plumbbob 0.13.3 → 0.13.5

package/skills/build/SKILL.md

@@ -168,15 +168,16 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
    fence's 80 columns (13 of label, 67 of value); two or more items break onto indented
    continuation lines opening with `-`, and a red row's evidence onto an indented `→` line.
 
-   The `## Summary` lead and the `## <n>` section titles are the turn's opening block:
-   handoff prints the lead behind the `**Summary**:` label, appends the `(details: …)`
-   bracket, and renders the titles as the numbered highlights, so you type neither the path
-   nor the list. Five highlights at most, each one sentence and one move, plain English
-   first, a path in backticks only when the name itself is the news. The numbers are
-   handles: "expand 2" opens `## 2`, so every highlight has a section behind it with the
-   full story. A judgment or a flag (a stray the seam row will name, a decision you had to
-   bend, a doubt about the done-when) is one of those highlights, never a paragraph of its
-   own. The recommendation is the last section: the move you would take as its own
+   The `## Summary` lead opens the card: handoff prints it behind the `**Summary**:` label.
+   The `## <n>` sections stay in the detail file, where `expand 2` opens `## 2` and the
+   build log's record keeps them; the card prints none of them and closes instead on a
+   `[more details](…)` link to the file, which handoff writes, so you type no path. Five
+   sections at most, each titled with one sentence and one move, plain English first, a
+   path in backticks only when the name itself is the news. A judgment or a flag (a stray
+   the seam row will name, a decision you had to bend, a doubt about the done-when) is one
+   of those sections, and the card carries it where it bears on the call: a bent row's `→`
+   line points at it, and your recommendation names it when it changes the move. It is
+   never a paragraph of its own. The recommendation is the last section: the move you would take as its own
    sentence, closed by a period, then the reason as a capitalized sentence or two. The lead
    and the recommendation are flowing prose and handoff unwraps both to the renderer's
    width, so never hard-wrap them; handoff also prepends the bold `**Recommendation**:`
@@ -192,14 +193,15 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
 
    *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
-   naming the step in flight, 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 --full` and paste that. The gate verdict's one home is that `check`
+   your own; it carries fences of its own and they cannot nest. It prints the Summary, the
+   Readout fence (its measured `check`, `seam`, `diff`, and `spent` rows folded with your
+   three, the changed files listed beneath `diff`), a `diff` fence when the change is 20
+   lines or fewer, Your Call, the state table (the Verdict folded worst-of from the same
+   rows, the Now row naming the step in flight, Next Up, and the Range, Order, and Parked
+   rows when they apply), your recommendation, and the `more details` link last. Run it
+   once: a second run at the same 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 --full` and paste that. The gate verdict's one home is that `check`
    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
@@ -208,37 +210,39 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
    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` 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 --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`. Once the change is made, rewrite the detail file and
-   end on `plumbbob handoff` as the first render did; the pause has changed, so it prints
-   the whole card.
+   *Then answer the reply in your own words.* The card shows once
+   ([D110 (reply-after-the-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d110)):
+   every later turn at this pause is your reply, closed by one line. 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. A message that **directs** is needs-work:
+   make the change, run the check, and say what moved and what the check found; when the
+   change moves what the card said (a judgment row, the Summary, the recommendation), write
+   the detail file again so the record matches what lands. Nothing lands until the human
+   says `looks good`. Either way, then run `plumbbob handoff` and paste its output beneath
+   your reply, whole and verbatim: at a pause whose card has shown it prints one line,
+   `**Next Up**: Back to Step <N> of <M> - <title>`, whatever changed since, so your reply
+   stays on screen. The turn is your reply, then that line, and nothing after it. The CLI
+   picks the form, never you: paste whichever one it prints, and never retype the card.
+
+   The card comes back one way: the human asks to see it (`show the pause`, or any wording
+   of it). Then run `plumbbob handoff --full` and paste its output whole, with nothing
+   written around it. Never run `--full` to read the card for yourself, after a compaction
+   or in a fresh session; what it prints is the turn's ending, and the relay check holds a
+   turn that does not close on it. Read the detail file and `plumbbob status` instead. A
+   tangent the human hands you at the pause is still a park.
 
    **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), 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
+   ending itself: `**Checkpoint**: Step N complete (<sha>)`, any advisory (a staged path
+   outside the seam is the common one), and the state table: the Verdict the step earned,
+   the Stop row when this landing completes a range (`| Stop | Range 3 of 5 landed - <its
+   stop> |`, the reason the build stops here), Next Up, and the rows beneath it. Relay that
+   block whole, the table with the rest (the relay check holds a boundary that dropped a
+   row), run no second command, and write nothing around it. A later turn at this boundary
+   is your reply; a `plumbbob handoff` there prints Next Up's one line, since the boundary
+   has shown. It is the
+   orientation tier (no Your Call block, no recommendation), and its Next Up 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
    running `/plumbbob:build` again. It is what carries the plan's suggestion across a fresh
    context window, which inherits the session model, not the plan's. No `- model:` line
@@ -376,13 +380,13 @@ out, or the next step in build order is one the range does not name),
   the next one. A run's range ends on the stop card, which lists every open park with a
   proposed class, and the reply that settles the card records them (the run skill's
   section on the reply at a stop). A range landed here, by a typed range, ends on the plain
-  boundary instead; when the human asks what comes next there with parks open (the note's
-  `parked 2 of 7 open`), the move is `/plumbbob:harvest`, then the run the card names.
+  boundary instead; when the human asks what comes next there with parks open (the table's
+  `Parked` row, `2 of 7 open`), the move is `/plumbbob:harvest`, then the run 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 the run that lands
-  what is left of the range (`· range 3 of 5: /plumbbob:run (steps 8-9)`), and that is what
-  the human types to carry on; `/plumbbob:build 8-9` lands the same steps by hand.
+  human approves and the step lands, the state table's Range row names the run that lands
+  what is left of the range (`| Range | 3 of 5: /plumbbob:run (steps 8-9) |`), and that is
+  what the human types to carry on; `/plumbbob:build 8-9` lands the same steps by hand.
 
 ## The hard contracts
 

package/skills/finish/SKILL.md

@@ -41,7 +41,13 @@ record.
    - `## Decisions and why`: the settled calls that shaped the build (the *why* behind
      the log). Copy each one's `D# (slug)` from `intent.md` (never a bare `D#`) so
      the report reads without flipping back to the intent.
-   - `## Parked & harvested`: what was captured and how each was classified.
+   - `## Parked & harvested`: what was captured and how each was classified, as the
+     table the stop card's leans use, with the settled class where the card had the lean
+     ([D112 (lean-table)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d112)):
+     `| Park | What it is | Why it matters | Settled |`, one row per park, its handle and a
+     short title, the park's text as the Park list holds it, why it matters (the why the
+     stop's record kept, or your own clause for a park harvested before the table), and
+     the class it settled as with its reason.
    - `## Final status`: done or partial, and what is left.
    - `## Deferred tangents`: the harvested items that become future work.
    Stop there. `plumbbob finish` appends `## Checkpoints` (the baseline and step SHAs) and
@@ -74,9 +80,9 @@ record.
    the `plumbbob finish` marker subject only.
 4. **Point at the next goal.** Relay `plumbbob finish`'s output verbatim, blank lines
    included: its lead line, which names the branch the tracked folder now rides into the
-   PR, any advisory beneath it, and `**Next Up**: Nothing planned - /plumbbob:plan`. That
-   is the orientation tier's close (the
-   [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)):
+   PR, any advisory beneath it, and its state table, whose one row is
+   `| **Next Up** | Nothing planned - /plumbbob:plan |`. That is the orientation tier's close
+   (the [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)):
    the lead line, then the forward pointer. `finish` renders that pointer itself rather
    than leaving it to `plumbbob handoff`, because finish has just cleared the session
    handoff would read one from. Relay the block and write nothing after it.

package/skills/harvest/SKILL.md

@@ -2,7 +2,7 @@
 name: harvest
 description: "Triage the park list at a step boundary: propose one class (blocker/tangent/pivot) for every open parked item at once, and once the human settles them in one reply, fold a confirmed blocker into intent and record the rest with plumbbob harvest. A run's stop card carries its own harvest."
 disable-model-invocation: true
-allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob order:*), Bash(plumbbob harvest:*)
+allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob order:*), Bash(plumbbob handoff:*), Bash(plumbbob harvest:*)
 ---
 
 # PlumbBob: harvest the park list
@@ -54,41 +54,59 @@ the call on each one theirs. The detail file you write first is the proposal; re
 **only after** that reply confirms them:
 
 - Write the proposals into `.plumbbob/detail.md` first, under a `# Detail · Harvest`
-  header, one line per open item in a `## Harvest` section:
-  `- P6 → tangent: <the reason, one clause>`, the class written `blocker`, `tangent`,
-  or `pivot` (for a pivot signal). A park's handle is `P` and its place in the
-  Park list, counting the harvested lines too (the count the note sizes as
-  `parked 3 of 8 open`), and it is the one name the detail file, the turn, and the
-  human's reply all use
+  header, one proposal per open item in a `## Harvest` section, with two lines indented
+  beneath it:
+
+  ```markdown
+  - P6 → tangent: <the reason, one clause>
+    - title: <two to five words naming the park>
+    - why: <why it matters, one clause>
+  ```
+
+  The class is written `blocker`, `tangent`, or `pivot` (for a pivot signal). A park's
+  handle is `P` and its place in the Park list, counting the harvested lines too (the
+  count the state table's Parked row sizes as `3 of 8 open`), and it is the one name the
+  detail file, the turn, and the human's reply all use
   ([D105 (park-handles)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d105)).
-  Then list the same proposals in the turn, each with its handle and the park's text, and
-  end the turn there.
-- A reply that changes a proposal (`make P7 a tangent`) is the human's call: rewrite
-  that line, list the proposals again, and end the turn. A reply that confirms them
-  (`looks good`) is what lets you write.
+  Then run `plumbbob handoff --harvest` and paste its output whole, verbatim, and end the
+  turn there: it prints the lean table, one row per open park with its handle and your
+  title, the park's text as the list holds it, your why, and your lean, then the moves that
+  settle it
+  ([D112 (lean-table)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d112)).
+  Write nothing before or after it; the park's text is the CLI's to quote, never yours.
+- A reply that changes a proposal (`make P7 a tangent`) is the human's call and your
+  reply: rewrite that line, say in your own words which lean moved, and end the turn
+  without printing the table again; the human who wants to see it asks, and
+  `plumbbob handoff --harvest` prints it. A reply that confirms them (`looks good`) is what
+  lets you write.
 - On that confirmation, run `plumbbob harvest`
   ([D104 (harvest-records)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d104)).
   It flips each settled item from `- [ ]` to `- [x]` in the Park list, so
   `/plumbbob:status` stops counting it as open, and records each confirmed class under
   `build-log.md`'s `## Harvest` section. Relay its ending whole, the `**Recorded**:` line
-  and the Next Up beneath it. It refuses a proposal naming a handle the list lacks (`P9`
+  and the state table beneath it. It refuses a proposal naming a handle the list lacks (`P9`
   with eight parked) or a class other than blocker, tangent, or pivot; fix the line it
   names and run it again.
 - A confirmed **blocker** also folds its decision into `intent.md`, slugged at birth
   like any Decision, anchored the same way
   (`- <a id="d5"></a>**D5 (retry-cap)**: <the call>, *because* <why>`), never a bare `D5`.
-  A blocker that becomes a new step takes the next free number under `## Steps` and,
-  when it has to land before an existing undone step, its place in the sequence through
-  `plumbbob order 7 8 5` (the `## Build order` line), never by renumbering. When the plan
-  carries `## Build ranges`, the new step goes into a range too: a range still to come
-  (the one it builds with), or a bare range of its own when it brings a call the human
-  has to make before it lands, and never a range that has landed, since that range's call
-  was made and the step would reopen it. A new range takes the next free item number, and
-  no item is renumbered, because the stop card's stamp, the detail file's header, and
-  `plumbbob harvest` find a landed range by its number. A range the step breaks is re-cut
-  in the same confirmed edit
-  ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92));
-  `plumbbob status` afterward carries a `⚠` row for any range still broken.
+  A blocker that becomes a new step takes the next free number under `## Steps` and its
+  place in the sequence through `plumbbob order 7 8 5` (the `## Build order` line, every
+  undone step in the sequence to build them), never by renumbering, even when it builds
+  last. When the plan carries `## Build ranges`, the verb files the new step for you: it
+  re-cuts the ranges to follow the sequence it writes, so the step joins the range still
+  to come that the order puts it in, the one it builds ahead of when it lands first, and
+  never a range that has landed, since that range's call was made and the step would
+  reopen it
+  ([D109 (ranges-follow-the-order)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d109)).
+  Give the step a bare range of its own instead, written before you run the verb, when it
+  brings a call the human has to make before it lands. 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
+  ([D92 (build-ranges)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d92)).
+  The verb's ending names each range it re-cut, and an advisory names any it left for
+  you; re-cut that one in the same confirmed edit, and `plumbbob status` afterward carries
+  a `⚠` row for any range still broken.
 - Fold a confirmed blocker into `intent.md` before you run `plumbbob harvest`, so the
   record and the plan agree when it lands.
 - Never reclassify or resolve an item the human hasn't confirmed, and default every

package/skills/order/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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."
+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, and the CLI re-cuts the build ranges to follow it."
 argument-hint: "[steps in the sequence to build them, such as 1, 6, 2-4, 7, 5]"
 disable-model-invocation: true
 model: haiku
@@ -15,7 +15,10 @@ A step keeps its number for life, so once `/plumbbob:step` or `/plumbbob:refine`
 that has to land before an existing one, the sequence to build them stops being the
 numbering (`4, 7, 8, 5, 10, 6`). This skill writes that sequence down where every other move
 reads it: the `## Build order` line in `intent.md`, which `plumbbob status`, a bare
-`/plumbbob:build`, `plumbbob checkpoint`, and the card's Next Up all follow.
+`/plumbbob:build`, `plumbbob checkpoint`, and the card's Next Up all follow. When the plan
+carries `## Build ranges`, the same verb re-cuts them to follow the sequence, so
+`/plumbbob:run` walks the steps the new order put in its range
+([D109 (ranges-follow-the-order)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d109)).
 
 ## Wrong-state refusal
 
@@ -39,22 +42,22 @@ after the step in flight is the usual reason to run 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 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.
+   `**Build order**: 7, 8, 5, 10, 6` line; a
+   `**Build ranges**: range 2 of 3 re-cut (steps 10,4-6)` line when the new sequence moved a
+   step into or out of a range, naming each range it re-cut; an advisory for each range the
+   order left for the human, in the words its dashboard row carries
+   (`Range 2 of 3 needs a re-cut ⚠ (...)`), with
+   `→ /plumbbob:refine ranges` beneath the last; and the `**Next Up**` pointer (back at the
+   step in flight, or forward to the first step in the new sequence). Relay it whole as the
+   turn's last text and run no second command: the advisory already names the range and the
+   move, so there is no dashboard to read again. 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.
 
 ## The one hard contract
 
 The line is written by the **dumb CLI**, never by an edit. This skill carries **no Edit and
 no Write tool** on purpose: you may not touch `intent.md` yourself. Compose, get approval,
-then shell `plumbbob order`; that is the only write path, and it is the one that validates
-every number against the plan.
+then shell `plumbbob order`; that is the only write path, it validates every number against
+the plan, and it is the one that re-cuts the ranges, so a range the order leaves for the
+human is `/plumbbob:refine`'s to re-cut, never yours to edit here.

package/skills/plan/SKILL.md

@@ -163,8 +163,8 @@ The argument only seeds how you get there.
 
    **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
+   `/plumbbob:run` in the Range row 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
@@ -205,8 +205,9 @@ The argument only seeds how you get there.
      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
+     renders the your-call block with the moves that apply before anything is recorded,
+     the state table headed by Next Up, your recommendation, and a `more details` link to
+     the cold read (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
      its row names the move the human types next: `/plumbbob:run` for the range holding
@@ -224,9 +225,9 @@ The argument only seeds how you get there.
      commit predates the ledger and stays guidance-governed; it lands without a
      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, 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
+     whole boundary ending: `**Plan**: committed (<sha>)`, any advisory, and the state
+     table headed by the pointer at the step the build starts on, its Range row naming the
+     run that lands that step's range 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:
@@ -282,8 +283,8 @@ read checked and found sound. A plan with a hole gets `Sharpen <the one worst ho
 and why it matters; when the read found more than one, say how many sit behind `expand`
 and name `/plumbbob:refine` as the move that writes them up as Open questions, with their
 plain and lean sub-lines, for the human to settle. Three findings at most; the rest is
-refine's. `plumbbob handoff --plan` prints the label and your recommendation as the turn's
-last text, "expand 2" opens `## 2`, and `checkpoint --plan` records the read beneath the
+refine's. `plumbbob handoff --plan` prints the label and your recommendation beneath the
+state table, then the `more details` link to the file, "expand 2" opens `## 2`, and `checkpoint --plan` records the read beneath the
 plan's line in the build-log's `## Log`, the build's first entry. The cold read is the tip of refine: it makes the
 full attack discoverable at the moment it would pay, and lets a sound plan skip it. Refine
 is where the real adversary looks; this is an estimate, and it says so by staying short.

package/skills/refine/SKILL.md

@@ -54,18 +54,25 @@ is fine; refining is always available.
   Show the before/after for each, and **write only what the human approves**. A repair
   that inserts a step, or moves one ahead of another, keeps every number where it is and
   writes the sequence instead: shell `plumbbob order 7 8 5` with the undone steps in the
-  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.
+  sequence to build them, an inserted step included even when it builds last, 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
+  **A repair keeps the build ranges true.** When the plan carries `## Build ranges`,
+  `plumbbob order` re-cuts them to follow the sequence it writes
+  ([D109 (ranges-follow-the-order)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d109)):
+  a step it places joins the range whose steps sit on both sides of it, else the one it
+  builds ahead of, else the one it builds after, never a bare range, and never a range that
+  has landed, since that range's call was made and the step would reopen it; its ending
+  names each range it re-cut. Edit a range yourself only where the
+  order cannot say it, and before you run the verb: a bare range of its own for a step
+  that brings a call the human has to make before it lands, or a re-cut that moves where a
+  call falls, shown 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
+  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 verb's ending names as still needing a re-cut is yours to re-cut in
+  the same approved edit. 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.

package/skills/run/SKILL.md

@@ -111,7 +111,7 @@ ends there: relay the checkpoint's block whole and end the turn. A run whose lan
 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
+(its checkpoint block's table carries the `Stop` row 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,
@@ -122,7 +122,7 @@ walk before it, since the checkpoint would refuse it. The halt list is the build
 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
+with the Stop row (`| 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
@@ -161,6 +161,8 @@ constraints  all honored
 ## Harvest
 
 - P<handle> → <blocker, tangent, or pivot>: <the reason, one clause>
+  - title: <two to five words naming the park>
+  - why: <why it matters, one clause>
 
 ## Recommendation
 
@@ -170,22 +172,28 @@ constraints  all honored
 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
+numbered sections 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.
+early steps. A step that landed a hair off comes first among the sections; five at most. The
+card prints the Summary and links the rest
+([D113 (short-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d113)).
 
-The `## Harvest` section carries one line for every open park in the build-log's
+The `## Harvest` section carries one proposal 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`
+lines too, which is the count the table's Parked row sizes as `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
+with the reason in one clause, and beneath it two indented lines: a title of two to five
+words that names the park, and why it matters in one clause. The card prints each park as a
+row of the lean table: its handle and your title, the park's text as the list holds it, your
+why, and the lean (`tangent: <the reason>`)
+([D112 (lean-table)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d112)),
+so write the class, the reason, the title, and the why alone and leave the table to handoff.
+A park you leave out reads `no lean proposed` on the card and stays open, and a missing why
+reads `not given`. 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.
@@ -210,29 +218,32 @@ and the Your Call block names the replies. Read the human's message as one of th
   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 change** (`make P7 a tangent`, or a change to the review) is direction, and the turn
+  that makes it is your reply
+  ([D110 (reply-after-the-card)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d110)).
+  Rewrite the detail file's line or section, say in your own words what moved, then run
+  `plumbbob handoff --stop` and paste the one-line reminder it prints beneath your reply.
+  The card does not come back for a change; nothing is recorded until `looks good`, which
+  records every lean as the detail file then reads.
 - **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`.
+  the Log, never from recall; then run `plumbbob handoff --stop` and paste the one-line
+  reminder it prints beneath your answer. Only `show the stop`, or any wording of it, takes
+  `plumbbob handoff --stop --full`, and never to read the card for yourself.
 - **`/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
+  the record's ending whole and end the turn there, where its Range row 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
+parked) and a class outside the three, and it refuses a range no card showed; fix what the
+refusal names, run `plumbbob handoff --stop` again, and end the turn on what it prints. 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