@zalom/plastic 1.2.0 → 1.4.0

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/references/track-3-projects-and-roadmaps.md

@@ -56,16 +56,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 +74,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,7 +57,37 @@ 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: Relay the result, announce convention changes
+### 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
 
 Relay what `update` printed, do not recompute the version transition or the doctor
 summary:
@@ -73,14 +103,14 @@ Then read `~/.plastic/PLASTIC.md` and announce convention changes that affect th
 current session, and recommend `/clear` for a clean session with all new conventions
 loaded.
 
-### Step 3: Health check only on a relayed failure
+### Step 4: Health check only on a relayed failure
 
 If the relayed doctor summary shows a failure, invoke `plastic-doctor` for the full
 report and offer to fix. If it already reads clean, do not re-run doctor.
 
-### Step 4: Commit + clear update cache
+### 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
 ```

package/templates/config.yml

@@ -12,11 +12,36 @@ agent:
 architect:
   style:
 
-# Per-agent model override (intent 116). Uncomment and set to a Claude Code
-# alias (opus, sonnet, haiku) to override the shipped tier for one agent. With
-# no entry, the shipped default applies and never resolves to Fable; naming
-# Fable here is an explicit, sanctioned override, honored as written.
+# Per-agent model override (intent 116), harness-scoped. Uncomment and set to
+# a Claude Code alias (opus, sonnet, haiku) to override the shipped tier for
+# one agent on one harness. The legacy flat form (agents.models.<name>: value,
+# no harness nesting) still works and is read as the claude harness; nested
+# wins over flat for the same agent. A model named under claude is never read
+# for codex, and vice versa, so a literal model id can never leak into the
+# wrong harness's config. With no entry, the shipped default applies and never
+# resolves to Fable; naming Fable here is an explicit, sanctioned override,
+# honored as written.
 # agents:
 #   models:
-#     plastic-executor: sonnet
-#     plastic-enforcer: opus
+#     claude:
+#       plastic-executor: sonnet
+#       plastic-enforcer: opus
+#     codex:
+#       plastic-executor: gpt-5.1-codex
+
+# The advisor (intent 185): two consultation agents, plastic-advisor (the real
+# advisor, expensive, model fable by default) and plastic-faux-advisor (the
+# cheaper imitation, model opus by default, carrying the same reasoning
+# discipline inline). advisor.enabled defaults to enabled; missing or
+# unreadable counts as enabled (fail-open). The claude.default/primary/
+# secondary values are AGENT NAMES, never model names, so a slot can point at
+# a locally registered agent instead. Set at install time via --no-advisor /
+# --advisor, or uncomment here directly. Each agent's actual model is a plain
+# agents.models.claude.<name> override, same mechanism as any other agent.
+# advisor:
+#   enabled: false               # skip installing both advisor agents and the
+#                                 # agent-advisor skill entirely
+#   claude:
+#     default: plastic-faux-advisor    # which agent the advisor skill routes to
+#     primary: plastic-advisor         # the real advisor slot
+#     secondary: plastic-faux-advisor  # the cheaper advisor slot

package/templates/roadmap.md

@@ -9,17 +9,17 @@ roadmap's goal is reached, move this file from `roadmaps/{slug}.md` to
 (a checkable prose condition — one or a few sentences a human or coordinator reads to decide the
 roadmap is done. Not an executable checker.)
 
-## Waves
-Entries in a wave are parallel-safe; waves run top to bottom. The checkbox is checked once an entry
-is delivered, unchecked otherwise; the trailing token after the em-dash is the precise mirrored
-status (queued | delivering | delivered | abandoned | blocked) from INDEX.md. INDEX always wins on
-any conflict between the checkbox/token here and INDEX's real status.
+## Batches
+Entries in a batch are parallel-safe; batches run top to bottom. The checkbox is checked once an
+entry is delivered, unchecked otherwise; the trailing token after the em-dash is the precise
+mirrored status (queued | delivering | delivered | abandoned | blocked) from INDEX.md. INDEX
+always wins on any conflict between the checkbox/token here and INDEX's real status.
 
-### Wave 1
+### Batch 1
 - [ ] <intent-id> <title> — queued
 - [ ] <intent-id> <title> — queued
 
-### Wave 2
+### Batch 2
 - [x] <intent-id> <title> — delivered
 
 ## Log
@@ -27,4 +27,4 @@ any conflict between the checkbox/token here and INDEX's real status.
 what shipped and its impact for a non-expert reader, no jargon or internal codenames, ending with a
 link to that entry-intent's `outcome.md`. Never restate outcome detail here; link to it instead.
 Newest at the bottom.)
-- 2026-01-01 00:00 UTC Shipped the first wave of this roadmap; see store/<intent-id>--<slug>/outcome.md.
+- 2026-01-01 00:00 UTC Shipped the first batch of this roadmap; see store/<intent-id>--<slug>/outcome.md.