@zalom/plastic 1.3.0 → 1.4.1

package/skills/project-continuing/evals/evals.json

@@ -71,11 +71,11 @@
     },
     {
       "id": 8, "scope": "behavior", "set": "validation",
-      "prompt": "Does the skill carry the intent-149 coordination note?",
-      "expected_output": "A 'Coordination' section records that intent 149 has landed (dashboard demoted to prose, no Value x Effort grid) and intent 149a has landed (the four intent lists render as Markdown tables), and confirms the rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
+      "prompt": "Does the skill carry the intent-202 coordination note (project board short by default)?",
+      "expected_output": "A 'Coordination' section records that intent 202 has landed: the Recently-worked and raw Future tables are gone, replaced by a prose summary (built in dashboard.rb) and an honest-totals footer; Active is capped at 3 (lifecycle-stage descending, D2) and Next-work at 5; conversational paging re-invokes dashboard.rb --data with --limit-active/--limit-next/--all (no state on disk); --plain prints the full uncapped plain-text board. The rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
       "files": ["skills/project-continuing/SKILL.md"],
       "assertions": [
-        { "type": "convention", "check": "'149' present with the landed coordination note", "observed": "present: 'Intent 149 has landed' and 'Intent 149a has landed' (lists render as Markdown tables) with confirmed rule-name citations and dashboard.rb path", "result": "pass" }
+        { "type": "convention", "check": "'202' present with the landed coordination note describing the new shape, caps, paging flags, and --plain", "observed": "present: 'Intent 202 has landed' paragraph with the described content", "result": "pass" }
       ]
     },
     {

package/skills/project-continuing/references/board-fill.md

@@ -7,20 +7,22 @@ would otherwise bloat the SKILL.md body.
 ## Fill rules (owned by plastic-dashboard, summarized here for convenience)
 
 - `{{a.b.count}}` -> the integer (e.g. `counts.active` is that count).
-- `{{<list>.rows}}` -> the four intent lists (`recently_worked`, `next_work`, `active`, `future`)
-  render as Markdown table rows. The template hard-codes each table's header and separator; the
-  placeholder becomes one data row per entry, in that table's fixed column order, cells dropped
-  verbatim from the payload (cells arrive pipe-escaped and whitespace-normalized; do not re-escape
-  or re-truncate). Column order per table:
-  - `recently_worked` -> `| id | what | state | scope |` (global), `| id | what | state |` (project)
+- `{{<list>.rows}}` -> the two intent lists (`active`, `next_work`) render as Markdown table
+  rows. The template hard-codes each table's header and separator; the placeholder becomes one
+  data row per entry, in that table's fixed column order, cells dropped verbatim from the
+  payload (cells arrive pipe-escaped and whitespace-normalized; do not re-escape or
+  re-truncate). Column order per table:
   - `next_work` -> `| id | what | value | disposition | flags_label |`
-  - `active` -> `| id | what | stage |`; `future` -> `| id | what |`
-  Overflow entry (empty `id`, `what` = `+N more`) -> `+N more` in the Id column, other cells blank.
+  - `active` -> `| id | what | stage |`
   Empty list -> one full-width row with `_(none)_` in the Id column, other cells blank, matching
-  that table's column count (e.g. `| _(none)_ | | | | |` for the 5-column next_work table,
-  `| _(none)_ | |` for the 2-column future table). Never emit `<br>`.
+  that table's column count. Neither list carries an overflow "+N more" row (intent 202): the
+  true pool size rides on the payload (`active_total`/`next_total`, shown as
+  `active_shown`/`next_shown`), stated in prose by `{{footer}}` instead. Never emit `<br>`.
 - `{{projects.lines}}` (global board) -> the project rollup stays prose, one line per project.
-- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) -> substitute verbatim.
+- Scalars (`{{date}}`, `{{slug}}`, `{{summary}}`, `{{footer}}`) -> substitute verbatim.
+  `summary` (the 2-3 sentence "what was delivered most recently") and `footer` (the
+  honest-totals + how-to-see-everything line) are finished prose built in `dashboard.rb`,
+  replacing the old recently-worked table and the raw future table respectively.
 
 No re-sorting, no re-summarizing, no hand-written prose replacing a line the payload already
 supplies. Same store state produces a byte-identical payload regardless of model.

package/skills/project-creating/SKILL.md

@@ -122,7 +122,35 @@ ruby ~/.plastic/scripts/qmd-sync register --store ~/.plastic/projects/<slug>/sto
 `qmd-sync` no-ops when QMD is absent, so run it unconditionally. This adds the
 `plastic-<slug>` collection and indexes it.
 
-### 12. Announce
+### 12. Self-Check with validate-project
+
+Before announcing, verify the spawn actually landed everything it claims to
+have created. Run:
+
+```bash
+ruby ~/.plastic/scripts/validate-project <slug>
+```
+
+If this exits 0, proceed to step 13. If it exits non-zero, STOP: do not
+proceed to Announce. Read the `missing:` and error lines it printed to
+stderr, fix the named gap(s), for example:
+
+- missing `project.yml` or `INDEX.md` or `store/`: re-run
+  `ruby ~/.plastic/scripts/provision-project-store <slug>` (step 7), then
+  re-check
+- missing project-root `AGENTS.md`: repeat step 4 (populate AGENTS.md at the
+  project root, not `~/.plastic/projects/<slug>/`)
+- project directory missing on disk: repeat step 2
+- not registered in projects.yml: repeat step 6
+
+Re-run `validate-project <slug>` after each fix until it exits 0. Only a
+project spawn that passes this self-check moves on to be announced as
+created. A spawn that never verifies itself is exactly the bug this step
+exists to close (intent 190; the intent-26 spawn shipped with no
+`project.yml` and no root `AGENTS.md`, caught only weeks later by a doctor
+sweep).
+
+### 13. Announce
 
 Log in `## Insights` of each founding intent:
 > "Project `<slug>` created at `<path>`. Tactical mirror: `project-<slug>:1` (autonomous)"

package/skills/releasing/SKILL.md

@@ -21,8 +21,8 @@ Project configuration drives the workflow - no hardcoded assumptions.
 - [ ] Push to remote with tags
 - [ ] Run post-push actions (GitHub release, npm publish, etc.)
 - [ ] Verify release sync (npm dist-tag, GitHub "Latest", git tag all show the new version)
-- [ ] Complete active intent
 - [ ] Clean up the intent's worktrees (merge-then-remove)
+- [ ] Complete active intent
 
 ## Workflow
 
@@ -232,25 +232,19 @@ If the GitHub "Latest" badge is on an older tag (the common drift), fix it witho
 gh release edit <tag-name> --latest
 ```
 
-### 8. Complete Active Intent
-
-A release IS a delivery. The active intent that drove this work must be completed as part of the release process. This is NOT optional. The mechanical close (outcome/INDEX/savepoint/commit) is `plastic-intent-ending`'s job, not this skill's: run its backing script rather than restating that prose here.
-
-1. Read `~/.plastic/INDEX.md` (or the project's INDEX.md) - find active intent(s) related to this release.
-2. For each active intent being delivered:
-   a. Write a real `outcome.md` (never leave the scaffold placeholder), `disposition: delivered`, referencing the release tag.
-   b. Update `## Insights` with final observations.
-   c. Run the mechanical close (steps 1-4 of `plastic-intent-ending`): this stamps the intent file's `## Outcome` summary, moves the INDEX.md line to `## Completed` (dated today, with a rich entry description via `--index-note`), appends the savepoint `Done` bookend, and commits the store, all in one call:
-      ```bash
-      ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
-        --outcome-summary "delivered in <tag-name>: <one-line summary>" \
-        --index-note "<tag-name>, <mode/tier>; <what shipped>; <suite result>"
-      ```
-   d. Update clusters to show `_(completed)_` (the store-curating skill's job on its next pass).
-
-**If no active intent exists for this release**, that itself is a problem - work happened outside the intent system. Log it and move on, but flag it.
+### 8. Clean Up the Intent's Worktrees (merge-then-remove)
 
-### 9. Clean Up the Intent's Worktrees (merge-then-remove)
+This step now runs BEFORE step 9's `end-intent` call (intent 188, D7): `scripts/end-intent`
+gained its own step 5 that disarms (releases the worktree, clears `delivery.lock`) as part
+of every close. Its plain-remove shape does not merge, so if `end-intent` ran first on a
+release, its step 5 would remove the worktree WITHOUT merging the code branch first,
+stranding the integrated work (`Worktree.finish` returns early once the worktree block it
+needs is gone, per `worktree.rb`'s own "no-op if nothing was provisioned" contract).
+Running this merge-then-remove step first means the worktree is already gone by the time
+step 9 runs, so `end-intent`'s own disarm becomes a harmless no-op for the worktree
+(nothing left to remove), while for the FIRST time on this path it also clears the delivery
+lock correctly (G5): before intent 188 this path left the lock stranded, exactly the class
+of bug closed by the End-tail enforcement work.
 
 This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: true`), not a
 separate concern: a release is the merge-then-remove path for the intent's worktrees (intent
@@ -272,6 +266,30 @@ prune` in the affected repo if you hit a stale reference. For why this is the on
 merge-vs-remove policy lands on merge, and the fail-open/idempotent guarantees of `finish`,
 read `references/promotion-and-tagging.md`.
 
+### 9. Complete Active Intent
+
+A release IS a delivery. The active intent that drove this work must be completed as part of the release process. This is NOT optional. The mechanical close (outcome/INDEX/savepoint/commit, AND disarm since intent 188) is `plastic-intent-ending`'s job, not this skill's: run its backing script rather than restating that prose here.
+
+1. Read `~/.plastic/INDEX.md` (or the project's INDEX.md) - find active intent(s) related to this release.
+2. For each active intent being delivered:
+   a. Write a real `outcome.md` (never leave the scaffold placeholder), `disposition: delivered`, referencing the release tag.
+   b. Update `## Insights` with final observations.
+   c. Run the mechanical close (`scripts/end-intent`'s steps 1-5): this stamps the intent file's `## Outcome` summary, moves the INDEX.md line to `## Completed` (dated today, with a rich entry description via `--index-note`), appends the savepoint `Done` bookend, commits the store, and disarms (releases the worktree - already gone from step 8 above - and clears `delivery.lock`), all in one call:
+      ```bash
+      ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
+        --session "$CLAUDE_CODE_SESSION_ID" \
+        --outcome-summary "delivered in <tag-name>: <one-line summary>" \
+        --index-note "<tag-name>, <mode/tier>; <what shipped>; <suite result>"
+      ```
+      A non-zero exit needs attention: 4 means a live foreign session holds the lock (back
+      off), 5 means the code worktree is still dirty (should not happen here, since step 8
+      already removed it; investigate before overriding with `--discard-worktree-changes`),
+      3 means disarm ran but the lock is still present (run `/plastic-doctor check the lock
+      status`).
+   d. Update clusters to show `_(completed)_` (the store-curating skill's job on its next pass).
+
+**If no active intent exists for this release**, that itself is a problem - work happened outside the intent system. Log it and move on, but flag it.
+
 ## Release lines and channels
 
 Two lanes get code to a release, on top of the workflow above.

package/skills/roadmap/SKILL.md

@@ -13,10 +13,12 @@ to a release (completion-side, `CHANGELOG.md`). It lives at `roadmaps/{slug}.md`
 project's `INDEX.md` and `project.yml`). It never sits inside `store/`, which holds intent
 directories, not project artifacts.
 
-A roadmap file has four parts: a title/meta header, `## Goal` (prose), `## Waves` (ordered; entries
-inside a wave are parallel-safe, waves run sequentially), and an append-only dated `## Log`. Each
-wave entry mirrors that intent's status in `INDEX.md` (`queued`/`delivering`/`delivered`/
-`abandoned`/`blocked`).
+A roadmap file has four parts: a title/meta header, `## Goal` (prose), `## Batches` (ordered;
+entries inside a batch are parallel-safe, batches run sequentially), and an append-only dated
+`## Log`. A roadmap written before owner ruling 145 may instead use the legacy `## Waves` heading;
+reading accepts both, but every new roadmap is scaffolded with `## Batches`, and an existing
+roadmap file's heading is never renamed to migrate it. Each batch entry mirrors that intent's
+status in `INDEX.md` (`queued`/`delivering`/`delivered`/`abandoned`/`blocked`).
 
 **`INDEX.md` is the single writer of intent status; on any conflict INDEX wins and the roadmap
 entry is corrected to match.**
@@ -31,9 +33,9 @@ Read/Edit-only.
 | Verb | When | Mechanics |
 |------|------|-----------|
 | Create | user wants to start a new roadmap / plan a delivery batch | `references/operations.md#create` |
-| Add / reorder entries | user wants to add intents to a wave or resequence waves | `references/operations.md#add--reorder-entries` |
+| Add / reorder entries | user wants to add intents to a batch or resequence batches | `references/operations.md#add--reorder-entries` |
 | Sync status mirror | an entry's status may be stale against INDEX | `references/operations.md#sync-status-mirror` |
-| Append log line | a roadmap event just happened (created, wave done, closed) | `references/operations.md#append-a-log-line` |
+| Append log line | a roadmap event just happened (created, batch done, closed) | `references/operations.md#append-a-log-line` |
 | Read / consume | a human or a coordinator needs the roadmap's current state | `references/operations.md#read--consume` |
 | Close / archive | the roadmap's `## Goal` is reached | `references/operations.md#close--archive` |
 
@@ -47,7 +49,7 @@ verb above.
   layout per project. The general rule: `roadmaps/` is a sibling of `INDEX.md`, wherever `INDEX.md`
   lives.
 - `## Goal` is a checkable prose condition read by a human or agent, not an executable checker.
-- Wave entries render as checkboxes (`- [x] ... — delivered` / `- [ ] ... — <status>`); a human
+- Batch entries render as checkboxes (`- [x] ... — delivered` / `- [ ] ... — <status>`); a human
   reading cold should see shipped/running/next within a minute. `## Log` lines are one-sentence,
   EM-to-CTO-voice, dated, and link each entry-intent's `outcome.md` (lossless-by-reference).
 - Additive: this skill introduces no gate, lock, or hook, and does not change `INDEX.md`'s section

package/skills/roadmap/references/file-format.md

@@ -21,15 +21,19 @@ it in the same Close/archive step.
    roadmap delivers and which tier (project or global) it lives in.
 2. **`## Goal`** — a checkable prose condition: one or a few sentences a human or coordinator reads
    to decide the roadmap is done. Not an executable checker, not a list of tasks.
-3. **`## Waves`** — ordered waves (`### Wave 1`, `### Wave 2`, ...). Entries inside a wave are
-   parallel-safe (can be dispatched together); waves run top to bottom, sequentially (wave 2 does
-   not start until wave 1's entries are no longer `queued`/`delivering`).
+3. **`## Batches`** — ordered batches (`### Batch 1`, `### Batch 2`, ...). Entries inside a batch
+   are parallel-safe (can be dispatched together); batches run top to bottom, sequentially (batch 2
+   does not start until batch 1's entries are no longer `queued`/`delivering`). A roadmap written
+   before owner ruling 145 may instead use `## Waves` / `### Wave N`; both headings are accepted
+   when reading, but every new roadmap is scaffolded with `## Batches`, and an existing roadmap
+   file's heading is never renamed to migrate it.
 4. **`## Log`** — append-only, dated, one line per event. Newest entry at the bottom. Never edit or
    remove an existing log line.
 
 ## Entry line shape
 
-One line per intent, inside its wave, as a Markdown checkbox:
+One line per intent, inside its batch (or wave, on a roadmap still using the legacy heading), as a
+Markdown checkbox:
 
 ```
 - [x] <intent-id> <title> — delivered
@@ -80,8 +84,8 @@ Line shape, one event per line, append-only, newest at the bottom:
 
 Two-space fields, mirroring the intent-dir cycle-step ledger (`savepoint.md`). The controlled event
 vocabulary: `created`, `dispatched`, `parked`, `merged`, `release`, `handoff`, `closed`, and
-optionally `added`, `reordered`, `wave`. The `(event, detail)` pair is the idempotency key, so
-re-appending the same pair is a no-op.
+optionally `added`, `reordered`, `wave`, `batch`. The `(event, detail)` pair is the idempotency key,
+so re-appending the same pair is a no-op.
 
 `## Log` and the ledger record the same events in two voices: the Log is the dated, one-sentence,
 EM-to-CTO-plain-language record a human reads cold; the ledger is the terse, machine-timestamped,
@@ -102,16 +106,16 @@ Delivery-side collection of intents that close out the pre-1.0 hardening pass, p
 ## Goal
 All intents below are delivered, the suite is green, and a 1.0.0 release is cut.
 
-## Waves
-Entries in a wave are parallel-safe; waves run top to bottom. The checkbox tracks delivered/not;
+## Batches
+Entries in a batch are parallel-safe; batches run top to bottom. The checkbox tracks delivered/not;
 the token after the em-dash carries the precise mirrored status (queued | delivering | delivered |
 abandoned | blocked); INDEX wins on any conflict.
 
-### Wave 1
+### Batch 1
 - [x] 121 Fix bash gate redirect parsing — delivered
 - [ ] 130 Proportional cycle tiers — delivering
 
-### Wave 2
+### Batch 2
 - [x] 124 Roadmap feature — delivered
 
 ## Log

package/skills/roadmap/references/operations.md

@@ -16,7 +16,7 @@ next" in under a minute, just from this one file.
 3. Copy `templates/roadmap.md` to `roadmaps/{slug}.md`.
 4. Fill the header (`# Roadmap: <title>` + the one-line meta) and write a real `## Goal` prose
    condition.
-5. Add at least one `## Waves` wave with real entries (see Add / reorder below), each entry's
+5. Add at least one `## Batches` batch with real entries (see Add / reorder below), each entry's
    status mirroring that intent's current `INDEX.md` status.
 6. Append the first `## Log` line, a short `YYYY-MM-DD HH:MM UTC`-prefixed plain-language note
    that the roadmap was created.
@@ -28,18 +28,20 @@ next" in under a minute, just from this one file.
 
 ## Add / reorder entries
 
-- **Add**: append an entry line (`- <intent-id> <title> — <status>`) to the target wave. Pick the
+- **Add**: append an entry line (`- <intent-id> <title> — <status>`) to the target batch. Pick the
   intent's title and status straight from `INDEX.md`.
-- **New wave**: add a new `### Wave N` heading after the last wave; entries in it are gated behind
-  every earlier wave's entries leaving `queued`/`delivering`.
-- **Reorder**: move an entry line to a different wave, or move a `### Wave` heading (with its
-  entries) earlier or later. Reordering never changes an entry's status; it only changes when the
-  entry is eligible to run.
+- **New batch**: add a new `### Batch N` heading after the last batch; entries in it are gated
+  behind every earlier batch's entries leaving `queued`/`delivering`. A roadmap still on the legacy
+  `## Waves` heading keeps using `### Wave N` for a new entry; never migrate an existing roadmap's
+  heading to add one.
+- **Reorder**: move an entry line to a different batch, or move a `### Batch` (or, on a legacy
+  roadmap, `### Wave`) heading (with its entries) earlier or later. Reordering never changes an
+  entry's status; it only changes when the entry is eligible to run.
 - After any add/reorder, append a `## Log` line describing the change (e.g.
-  `- <YYYY-MM-DD HH:MM UTC> added 132 to wave 2`).
+  `- <YYYY-MM-DD HH:MM UTC> added 132 to batch 2`).
 - Append the ledger event (derived, idempotent, safe to re-run; never writes INDEX or roadmap
   status): `ruby ~/.plastic/scripts/roadmap-savepoint append --roadmap roadmaps/<slug>.md --event
-  added --detail "<id> to wave N"` for an add, or `--event reordered` for a reorder (describe the
+  added --detail "<id> to batch N"` for an add, or `--event reordered` for a reorder (describe the
   move in `<detail>`).
 - Refresh the QMD index for this roadmap (no-op when QMD is absent), in the background so it
   never blocks: `ruby ~/.plastic/scripts/qmd-sync reindex --store <roadmaps-dir> --async`.
@@ -70,7 +72,7 @@ next" in under a minute, just from this one file.
   edit or delete an existing line (append-only).
 - Every line is plain language a non-expert can read, never a codename or a raw `field -> value`.
   A delivery event follows the EM-to-CTO one-line shape with an `outcome.md` link (see
-  `file-format.md`); bookkeeping events (created, an intent added to a wave, a wave completed, a
+  `file-format.md`); bookkeeping events (created, an intent added to a batch, a batch completed, a
   roadmap closed) are short dated plain-language lines.
 - Append the matching ledger event (derived, idempotent, never writes INDEX or roadmap status):
   when the line records a release cut, `ruby ~/.plastic/scripts/roadmap-savepoint append --roadmap
@@ -81,14 +83,16 @@ next" in under a minute, just from this one file.
 
 ## Read / consume
 
-- A human reading the file gets the current picture directly: `## Goal` for the target, `## Waves`
-  for what is queued/delivering/delivered per wave (checkboxes give the shipped/not-shipped view at
-  a glance), `## Log` for a one-line, plain-language history with a link into each intent's
-  `outcome.md` for detail.
-- A future coordinator (for example, an auto-mode dispatcher) reads `## Waves` top to bottom:
-  a wave is eligible to dispatch once every entry in the previous wave is no longer
-  `queued`/`delivering`; within an eligible wave, entries still `queued` are parallel-dispatchable.
-  Always re-sync against `INDEX.md` before dispatch decisions, since INDEX is the source of truth.
+- A human reading the file gets the current picture directly: `## Goal` for the target, `## Batches`
+  (or, on a roadmap still using the legacy `## Waves` heading, that section instead) for what is
+  queued/delivering/delivered per batch (checkboxes give the shipped/not-shipped view at a glance),
+  `## Log` for a one-line, plain-language history with a link into each intent's `outcome.md` for
+  detail.
+- A future coordinator (for example, an auto-mode dispatcher) reads the grouping section
+  (`## Batches`, or legacy `## Waves`) top to bottom: a batch is eligible to dispatch once every
+  entry in the previous batch is no longer `queued`/`delivering`; within an eligible batch, entries
+  still `queued` are parallel-dispatchable. Always re-sync against `INDEX.md` before dispatch
+  decisions, since INDEX is the source of truth.
 
 ## Close / archive
 

package/skills/roadmap-continuing/SKILL.md

@@ -2,7 +2,7 @@
 name: plastic-roadmap-continuing
 description: >-
   Use when the user wants to continue or resume a roadmap, pick up a mid-flight delivery batch,
-  asks "where is the roadmap", or wants to resume the wave that was shipping, including an
+  asks "where is the roadmap", or wants to resume the batch that was shipping, including an
   indirect ask that never names a roadmap directly (for example "where did that batch of
   intents land"). This is the roadmap route of plastic-continuing: it finds the tier's
   mid-flight roadmap, presents its state, then asks how to proceed exactly once.
@@ -27,7 +27,7 @@ roadmap handoff had to be resumed by hand, carried as a free-prose note in `171`
 2. For each candidate, also read its paired ledger `roadmaps/<slug>.savepoint.md` when present
    (see `plastic-roadmap`'s `references/file-format.md#savepoint-ledger`): its last line(s) are a
    cheaper, precise last-event signal (for example `dispatched 134` or `merged 172`), read
-   alongside the existing `## Waves`/`## Log` judgment. The ledger is read-only here, a derived
+   alongside the existing `## Batches` (or legacy `## Waves`) / `## Log` judgment. The ledger is read-only here, a derived
    signal, never a new status field; INDEX.md stays the sole status writer.
 3. Rank liveness by calling the shared reader in which mode (one implementation across the
    auto loop and this skill):
@@ -47,7 +47,7 @@ roadmap handoff had to be resumed by hand, carried as a free-prose note in `171`
 
 ## Present state
 
-Present the chosen roadmap's `## Goal`, the current wave with each entry's mirrored status, the
+Present the chosen roadmap's `## Goal`, the current batch with each entry's mirrored status, the
 ledger's newest line(s) (the last mechanized event) alongside the newest `## Log` line, before any
 ask, so the coordinator sees the machine last-event at a glance.
 
@@ -56,7 +56,7 @@ ask, so the coordinator sees the machine last-event at a glance.
 Ask "auto or guided?" exactly once, after presenting state, mirroring
 `plastic-intent-starting`'s single-ask contract:
 - **guided** -> continue step by step with the user.
-- **auto** -> hand off to `plastic-auto` to drive the next wave or entry.
+- **auto** -> hand off to `plastic-auto` to drive the next batch or entry.
 
 Never re-ask. No new roadmap or INDEX status field is invented anywhere in this flow.
 
@@ -78,7 +78,7 @@ This skill is a reader, not a writer, of `roadmaps/<slug>.savepoint.md`. The coo
 ~/.plastic/scripts/roadmap-savepoint append` at their own dispatch, merge, park, handoff, and
 release points, the same events `plastic-roadmap`'s verbs append at their closing steps. A
 resuming coordinator therefore both reads the ledger here and writes to it as it drives the next
-wave or entry.
+batch or entry.
 
 ## References
 

package/skills/roadmap-continuing/evals/evals.json

@@ -35,8 +35,8 @@
     },
     {
       "id": 4, "scope": "behavior", "set": "train",
-      "prompt": "Does the skill rank liveness correctly when a wave entry is delivering or blocked?",
-      "expected_output": "A roadmap with any delivering/blocked wave entry wins the ranking outright over every other candidate.",
+      "prompt": "Does the skill rank liveness correctly when a batch entry is delivering or blocked?",
+      "expected_output": "A roadmap with any delivering/blocked batch entry wins the ranking outright over every other candidate.",
       "files": ["skills/roadmap-continuing/references/liveness-ranking.md"],
       "assertions": [
         { "type": "convention", "check": "delivering/blocked-wins rule documented as step 2 of the algorithm", "observed": "present", "result": "pass" }
@@ -54,7 +54,7 @@
     {
       "id": 6, "scope": "behavior", "set": "train",
       "prompt": "Does the skill present the roadmap state before asking?",
-      "expected_output": "The '## Present state' section (Goal, current wave, newest Log line) runs before the '## Ask once' section.",
+      "expected_output": "The '## Present state' section (Goal, current batch, newest Log line) runs before the '## Ask once' section.",
       "files": ["skills/roadmap-continuing/SKILL.md"],
       "assertions": [
         { "type": "convention", "check": "Present state precedes Ask once in document order", "observed": "present", "result": "pass" }

package/skills/roadmap-continuing/references/liveness-ranking.md

@@ -19,8 +19,9 @@ tier's live `roadmaps/*.md` files (excluding `roadmaps/archived/`), by `RoadmapQ
 
 1. **Enumerate.** List every `roadmaps/*.md` at the tier (project or global), skipping
    `roadmaps/archived/`.
-2. **Delivering/blocked wins outright.** If any candidate roadmap has at least one `## Waves`
-   entry whose mirrored status token is `delivering` or `blocked`, it is in flight right now.
+2. **Delivering/blocked wins outright.** If any candidate roadmap has at least one grouping-section
+   entry (`## Batches`, or legacy `## Waves`) whose mirrored status token is `delivering` or
+   `blocked`, it is in flight right now.
    That candidate wins the ranking immediately; skip the rest of the ranking for it.
 3. **Otherwise, newest `## Log` entry wins.** Among the remaining candidates (none have a
    `delivering`/`blocked` entry), read each file's last `## Log` line (append-only, newest at
@@ -42,8 +43,8 @@ tier's live `roadmaps/*.md` files (excluding `roadmaps/archived/`), by `RoadmapQ
 
 Before this skill existed, nothing resumed a mid-flight roadmap automatically. The `171`
 (consistency-dividend) roadmap handoff had to be resumed by hand: a free-prose "SESSION
-HANDOFF" note written into `171`'s own `## Insights`, because nothing read `## Waves` +
-`## Log` and reconstructed where the batch stood. This ranking, now a deterministic reader
+HANDOFF" note written into `171`'s own `## Insights`, because nothing read the grouping section
+(`## Batches`/legacy `## Waves`) + `## Log` and reconstructed where the batch stood. This ranking, now a deterministic reader
 rather than a by-eye judgment, is the mechanism that replaces that hand-carried note.
 
 ## Grammar pointer (do not duplicate)
@@ -52,5 +53,5 @@ The roadmap file's four sections, entry line shape, and status vocabulary
 (`queued|delivering|delivered|abandoned|blocked`) are owned by `plastic-roadmap`:
 `skills/roadmap/references/file-format.md` for the shape, and
 `skills/roadmap/references/operations.md#read--consume` for how a reader (human or
-coordinator) is meant to walk `## Waves` and `## Log`. This page assumes that grammar and adds
+coordinator) is meant to walk `## Batches` (or legacy `## Waves`) and `## Log`. This page assumes that grammar and adds
 only the liveness-ranking judgment on top of it.

package/skills/tutorial/SKILL.md

@@ -59,7 +59,7 @@ remember where they left off.
 
 ## Before any track
 
-Every track opens with the same two checks: run `/plastic-update` first, so the walkthrough
-matches what is actually installed, and work in a sandbox (a throwaway repo, or a global-store
-intent) so nothing real is touched by mistake. Each reference restates this briefly; do not
-skip it even if the user seems experienced.
+Every track opens with the same two checks: run `/plastic-update` first (`$plastic-update` on
+Codex), so the walkthrough matches what is actually installed, and work in a sandbox (a
+throwaway repo, or a global-store intent) so nothing real is touched by mistake. Each reference
+restates this briefly; do not skip it even if the user seems experienced.

package/skills/tutorial/references/track-1-guided.md

@@ -9,7 +9,8 @@ end to end: a piece of work moved through What, Why, How, and Exec, with a finis
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: this track always creates a global-store intent; the throwaway repo below
 is never registered as a Plastic project. Pick a throwaway git repository if you have one

package/skills/tutorial/references/track-2-auto.md

@@ -9,7 +9,8 @@ agent end to end, and pausing and resuming that delivery will feel familiar.
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: a throwaway git repository, or a global-store intent. Nothing in this
 track touches a real project.

package/skills/tutorial/references/track-3-projects-and-roadmaps.md

@@ -9,7 +9,8 @@ will exist with more than one intent inside it and a roadmap file describing the
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: this whole track is a walked example. It creates a real project directory
 and a real roadmap file on disk, but the project is a throwaway one made for learning, not
@@ -56,16 +57,16 @@ in the global store.
 Type `/plastic-roadmap`.
 
 Teach the roadmap file shape exactly: a title and short meta header, a `## Goal` section in
-prose describing what "done" looks like for the whole batch, a `## Waves` section (an
-ordered list of groups of intents; intents inside one wave are safe to run in parallel,
-waves themselves run one after another), and an append-only, dated `## Log`. `INDEX.md`
+prose describing what "done" looks like for the whole batch, a `## Batches` section (an
+ordered list of groups of intents; intents inside one batch are safe to run in parallel,
+batches themselves run one after another), and an append-only, dated `## Log`. `INDEX.md`
 stays the single source of truth for each intent's status; the roadmap only mirrors it.
 
 Artifact: a new `roadmaps/<slug>.md` file, sitting next to the project's `INDEX.md`, listing
-the two or more intents from station 3 across one or more waves.
+the two or more intents from station 3 across one or more batches.
 
-Checkpoint: name which of the two intents from station 3 share a wave (so they run in
-parallel) and which one, if any, sits in a later wave (so it waits).
+Checkpoint: name which of the two intents from station 3 share a batch (so they run in
+parallel) and which one, if any, sits in a later batch (so it waits).
 
 ### 5. Drive delivery with /goal
 
@@ -74,18 +75,18 @@ and Claude keeps working, turn after turn, until a fast checker model confirms f
 Claude has actually reported that the condition holds; `/goal` never reads files on its own,
 so the condition has to name a check Claude's own output can prove.
 
-Turn the roadmap's `## Goal` and current `## Waves` into that condition, for example:
+Turn the roadmap's `## Goal` and current `## Batches` into that condition, for example:
 
-`/goal every intent in wave 1 of roadmaps/<slug>.md shows Completed in INDEX.md, and the test
+`/goal every intent in batch 1 of roadmaps/<slug>.md shows Completed in INDEX.md, and the test
 suite is green`
 
-Claude then works through the wave itself, one intent at a time, and stops on its own once the
+Claude then works through the batch itself, one intent at a time, and stops on its own once the
 checker agrees the condition holds. Run `/goal` with no argument at any point to see how long
 it has run and how many turns it has spent; run `/goal clear` to stop it before that.
 
 On a harness without `/goal`, just tell the agent to deliver the roadmap in auto mode instead.
 
-Checkpoint: point at the exact file (`roadmaps/<slug>.md`) whose `## Goal` and `## Waves`
+Checkpoint: point at the exact file (`roadmaps/<slug>.md`) whose `## Goal` and `## Batches`
 sections you turned into the condition above.
 
 ### 6. Merge discipline and releases

package/skills/update/SKILL.md

@@ -57,22 +57,35 @@ unavailable. The command prints the transition (`vX -> vY`) or "already up to da
 a post-update doctor summary, and records the move in the append-only
 `~/.plastic/versions.json` ledger.
 
-### Step 2: Ask the advisor question once, if unset (Claude Code only)
-
-If this update brought in the advisor feature and `advisor.claude.default` is still
-unset in `~/.plastic/config.yml`, ask the same question `plastic-install` asks on a
-fresh install, once, then never again (a key already set is respected, never re-asked):
-> "Which advisor should be the default?"
-> - **Faux Fable** (recommended): Opus 4.8 carrying the frontier reasoning
->   instructions. Much cheaper, available on any plan, reasons in the same
->   disciplined way.
-> - **Fable 5**: the frontier model itself. The strongest reasoning available,
->   billed through usage credits, so summon it for a few rounds and close it.
-
-Write the answer with `npx -y @zalom/plastic@<channel> install --claude --reinstall
---advisor faux` (or `--advisor real`). Non-interactive sessions skip the question; the
-`plastic-agent-advisor` skill's own routing falls back to `plastic-faux-advisor` at
-consult time, so nothing is silently broken by leaving the key unset.
+### Step 2: Relay any pending config question(s) the update printed
+
+If `update`'s own output (Step 1) printed a "Config question(s) introduced by
+this update" block, relay each question to the user exactly as printed
+(question, options, and the `write-config` command for each option). Do not
+invent or hardcode a specific question here: it comes from the CLI's fresh
+output (`config_asks.yml`, read by code that just synced from the new version),
+never from this skill file, which is always one release behind and cannot know
+what a future release will ask.
+
+Once the user picks an option, run the printed `write-config` command for that
+option, for example:
+
+```
+ruby ~/.plastic/scripts/write-config advisor.claude.default plastic-faux-advisor
+```
+
+If they say "not now" / want to keep the default, run the printed dismissal
+command instead, for example:
+
+```
+ruby ~/.plastic/scripts/write-config config_asks_dismissed --push advisor-default
+```
+
+If `update` printed nothing under that heading, skip this step silently - there
+is nothing pending. A question already answered or dismissed is never re-asked
+(both the CLI print and the doctor check verify this before showing anything),
+and a pending question missed here still shows up as a `config_asks` warn on
+the next `/plastic-doctor` run, so nothing is silently lost.
 
 ### Step 3: Relay the result, announce convention changes
 
@@ -98,6 +111,6 @@ report and offer to fix. If it already reads clean, do not re-run doctor.
 ### Step 5: Commit + clear update cache
 
 ```bash
-cd ~/.plastic && git add PLASTIC.md scripts/ AGENTS.md VERSION versions.json 2>/dev/null && git commit -m "chore: update Plastic to $(cat ~/.plastic/VERSION)" --allow-empty
+cd ~/.plastic && git add PLASTIC.md scripts/ AGENTS.md VERSION versions.json deprecations.yml config_asks.yml 2>/dev/null && git commit -m "chore: update Plastic to $(cat ~/.plastic/VERSION)" --allow-empty
 rm -f ~/.plastic/.cache/update-check.json
 ```