@zalom/plastic 1.3.0 → 1.4.0

package/skills/auto/references/end-tail.md

@@ -33,19 +33,33 @@ purge-eligible. Disarming also purges stale bridge files from the temp directory
 automatically (it keeps the current bridge, any live run, and any bridge whose intent
 still holds a delivery lock), so no manual `/tmp` cleanup is needed.
 
-**Worktree cleanup (mandatory, intent 73c3).** Disarming performs the worktree release:
-`disarm_auto` calls `Worktree.release`, which removes both per-intent worktrees (the code
-worktree under `<repo>/.claude/worktrees/{id}--{slug}` and the paired store worktree under
-`<plastic_home>/.worktrees/{id}--{slug}`), prunes both repos, and clears the worktree block
-from the bridge. This is the plain remove path: the disarm route does NOT merge, so use it
-only when no release merges the branch (the branch survives and can be reclaimed).
-
-When the work is being shipped through a release, do NOT rely on this plain remove. The
-release path (Completion step 4, via `plastic-releasing`) is responsible for merging the
-intent's code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE the
-worktree is removed, so the integrated work is not lost. It does this with
-`Worktree.finish(bridge_data, merge: true)` (merge-then-remove). Never leave an orphaned
-worktree, and run `git worktree prune` if you hit a stale reference.
+**Mechanized since intent 188.** `scripts/end-intent` performs this disarm itself, as its
+own step 5, after steps 1-4 (outcome/INDEX/savepoint/commit) commit. No agent needs to run
+a separate `Bridge.disarm_auto` one-liner any more on the auto mode / curator path: the
+single `end-intent` call in `SKILL.md`'s Completion section already does it. A pre-flight
+lock guard (before anything is written) refuses on a live foreign session (exit 4) and
+reclaims a stale foreign lock automatically (audited to savepoint.md); a dirty code
+worktree refuses before removal (exit 5, `--discard-worktree-changes` overrides
+deliberately); and the durable lock file is checked again after disarm, never merely
+trusted (exit 3 if it is somehow still present).
+
+**Worktree cleanup (mandatory, intent 73c3).** `end-intent`'s step 5 calls
+`Bridge.disarm_auto` by default, which calls `Worktree.release`, which removes both
+per-intent worktrees (the code worktree under `<repo>/.claude/worktrees/{id}--{slug}` and
+the paired store worktree under `<plastic_home>/.worktrees/{id}--{slug}`), prunes both
+repos, and clears the worktree block from the bridge. This is the plain remove path: the
+disarm route does NOT merge, so use it only when no release merges the branch (the branch
+survives and can be reclaimed).
+
+When the work is being shipped through a release, do NOT rely on this plain remove.
+`skills/releasing/SKILL.md` reorders its own two steps for exactly this reason (intent 188,
+D7): its worktree-merge step now runs BEFORE its `end-intent` call, merging the intent's
+code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE the worktree
+is removed, via `Worktree.finish(bridge_data, merge: true)` (merge-then-remove), so the
+integrated work is not lost. By the time `end-intent`'s own step 5 runs afterward, the
+worktree is already gone (a harmless no-op) and only the delivery lock is left to clear,
+correctly, for the first time on that path. Never leave an orphaned worktree, and run
+`git worktree prune` if you hit a stale reference.
 
 ## QMD reindex ordering rationale
 

package/skills/install/SKILL.md

@@ -103,10 +103,10 @@ Non-interactive sessions (no tty) skip the question entirely: the install ships
 shipped default, advisor enabled with no `--advisor` flag (the `plastic-agent-advisor`
 skill's own routing falls back to `plastic-faux-advisor` at consult time).
 
-Update flow: if `advisor.enabled` or `advisor.claude.default` are already set in
-`~/.plastic/config.yml`, do not re-ask; the existing value is respected, the same
-ask-once-when-unset rule the statusline choice below already follows. Either flag can
-also be passed again on `install --reinstall` to change a prior answer.
+Update flow: pending config questions, including this one, are now announced
+generically by `plastic-update`'s Step 2, sourced from `config_asks.yml` - not
+duplicated here. A value already set by either path is never re-asked by the
+other.
 
 **Statusline**
 

package/skills/intent-creating/SKILL.md

@@ -69,6 +69,11 @@ Having a "parent" in mind does NOT automatically mean branch. Choose by meaning:
   `--sources` when it was genuinely created from / emerged from that intent's lifecycle.
   Topic similarity alone is not a `sources` edge.
 
+When a branch intent exists because a late ruling arrived AFTER its parent was already
+completed (the owner's late-ruling rule), the parent is restored to v1 via
+`scripts/restore-intent-v1`, never by a hand-run `git checkout`/revert. See `PLASTIC.md` >
+Terminal immutability for the rule and the tool.
+
 `## Links` is a DERIVED view of `sources`/`chain`. Never hand-write a `## Links` line; add the
 frontmatter edge and reproject. Links are decided by context influence (a `chain` edge has a high
 bar: the candidate's context must materially help deliver this intent), not by shared files or a

package/skills/intent-ending/SKILL.md

@@ -24,15 +24,16 @@ failure branch: only outcome.md content and the INDEX section differ.
 | 2 | INDEX.md terminal move (Active -> Completed/Abandoned) | `scripts/end-intent` |
 | 3 | savepoint `Done` bookend | `scripts/end-intent` |
 | 4 | store auto-commit | `scripts/end-intent` |
-| 5 | disarm (worktree + lock) | You, after end-intent exits 0 |
+| 5 | disarm (worktree + lock) | `scripts/end-intent` (intent 188) |
 | 6 | QMD reindex, async, LAST | You |
 | 7 | EM-to-CTO report | You |
 
-Steps 1-4 are ONE callable script, not four separate one-liners: this is
-exactly what the failure mode this intent fixes looked like (releasing hand
+Steps 1-5 are ONE callable script call, not several separate one-liners: this
+is exactly what the failure mode this intent fixes looked like (releasing hand
 authored the close in prose and dropped the savepoint bookend for two real
-deliveries). Never restate outcome/INDEX/savepoint prose inline again; call
-`scripts/end-intent`.
+deliveries; separately, one session delivered four intents back to back and
+never ran the old step-5 one-liner at all, intent 188). Never restate
+outcome/INDEX/savepoint/disarm prose inline again; call `scripts/end-intent`.
 
 ### Step 0. Precondition (the gate is section-blind, not selective)
 
@@ -55,7 +56,7 @@ for orchestrator-owned or completion-tracking items.
    (tick it if the described work is actually done, or do the remaining
    work); do not attempt outcome.md and fight the gate's deny.
 
-### Step 1-4. Run `scripts/end-intent`
+### Step 1-5. Run `scripts/end-intent`
 
 First author outcome.md for real (never leave the scaffold placeholder in
 place): copy `templates/outcome.md`, set the frontmatter to
@@ -72,40 +73,52 @@ Then call the script once:
 ```bash
 ruby ~/.plastic/scripts/end-intent \
   --store <store_path> --id <intent_id> --disposition delivered|abandoned \
+  --session "$CLAUDE_CODE_SESSION_ID" \
   --outcome-summary "<one-line ## Outcome summary for the intent file>" \
   --index-note "<rich Completed/Abandoned entry description>"
 ```
 
-This does all of steps 1-4 in order: guards outcome.md (refuses a missing,
+This does all of steps 1-5 in order: guards outcome.md (refuses a missing,
 still-placeholder, or wrong-disposition file with exit 2 and authors
 nothing), stamps the intent file's `## Outcome` section, moves the INDEX.md
 line from `## Active` to `## Completed` or `## Abandoned` (dated today,
-idempotent) with the `--index-note` text appended after the date so the
-entry stays rich, appends the savepoint `Done` bookend, and commits the
-store repo. Omit `--index-note` for a thin id+date entry, add `--no-commit`
-when a separate commit step already covers the store, and `--dry-run` to
-preview with no writes. Exit 0 is success; exit 1 is a usage or resolution
-failure; exit 2 is the outcome.md guard refusing (fix outcome.md and re-run,
-nothing was written).
-
-### Step 5. Disarm (worktree + lock)
-
-Two branches, decided by how this intent ships:
-
-- **Shipped through a release** (the `plastic-releasing` flow reached this
-  close): merge the code branch back BEFORE removing the worktrees, via
-  `Worktree.finish(bridge_data, merge: true)`. Releasing's own workflow
-  already drives this; this skill's job here is only the outcome/INDEX/
-  savepoint/commit core above.
-- **Auto mode or the curator path** (no release involved): plain remove,
-  branch survives for reclaim.
-  ```bash
-  ruby -r ~/.plastic/scripts/lib/bridge -e \
-    'Bridge.disarm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>")'
-  ```
-  `disarm_auto` releases both worktrees, clears the `delivery.lock`, and only
-  then makes the bridge purge-eligible, in that order. Never leave an
-  orphaned worktree; run `git worktree prune` on a stale reference.
+idempotent, accepting either a real em dash or a plain hyphen as the id/
+title separator on read while always emitting the real em dash on write)
+with the `--index-note` text appended after the date so the entry stays
+rich, appends the savepoint `Done` bookend, commits the store repo, and
+disarms (releases the code worktree and clears `delivery.lock`, verified
+against the durable lock file on disk, never merely trusted). Omit
+`--index-note` for a thin id+date entry, add `--no-commit` when a separate
+commit step already covers the store (this never skips disarm), and
+`--dry-run` to preview steps 1-5 with no writes.
+
+A pre-flight lock guard runs before anything is written: it resolves the
+calling session (`--session`, else `CLAUDE_CODE_SESSION_ID`, else the
+existing lock's own recorded owner, else a no-op) and checks it against any
+existing `delivery.lock`. A live foreign session refuses the whole run
+(exit 4, nothing written); a stale foreign lock is reclaimed automatically
+(audited to savepoint.md) and the run proceeds as the new owner. Before
+removing the worktree, step 5 also refuses on an unexpectedly dirty code
+worktree (exit 5, naming the worktree path) rather than force-discarding
+uncommitted changes; pass `--discard-worktree-changes` only when you mean
+to override that deliberately.
+
+On the auto mode / curator path (no release), this single call performs the
+FULL disarm (plain worktree remove, since the branch survives for later
+reclaim). On a release-shipped path, `skills/releasing/SKILL.md` merges and
+removes the worktree FIRST (its own step 8, merge-then-remove) before ever
+calling this script, so by the time this call's step 5 runs, the worktree is
+already gone (a harmless no-op) and only the lock is left to clear,
+correctly, for the first time on that path (D7).
+
+Exit codes: 0 success (the intent is closed AND its delivery lock is gone);
+1 a usage or resolution failure, OR an INDEX id that resolves to neither
+`## Active` nor the terminal section; 2 the outcome.md guard refusing (fix
+outcome.md and re-run, nothing was written); 3 steps 1-4 already committed
+but disarm could not verify the lock is gone afterward (run `/plastic-doctor
+check the lock status`); 4 a live foreign session holds the lock (back off);
+5 the code worktree is dirty (commit/stash first, or pass
+`--discard-worktree-changes` deliberately).
 
 ### Step 6. QMD reindex, LAST
 
@@ -146,6 +159,6 @@ historical record of what was planned.
 
 `plastic-releasing`, `plastic-auto`, the curator agent, `store-curating`, and
 `store-indexing` all delegate their mechanical close to this skill (or call
-`scripts/end-intent` directly for steps 1-4). None of them restate the
-outcome/INDEX/savepoint prose inline any more; if you find one that does,
-that surface has drifted and should route here instead.
+`scripts/end-intent` directly for steps 1-5). None of them restate the
+outcome/INDEX/savepoint/disarm prose inline any more; if you find one that
+does, that surface has drifted and should route here instead.

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.