@zalom/plastic 1.0.3 → 1.1.1

package/skills/{creating-project → project-creating}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic-creating-project
+name: plastic-project-creating
 description: >-
   Create a new project from an implementation intent. Sets up project directory,
   git init, AGENTS.md with founding intent decisions, plastic-install --local,
@@ -79,7 +79,7 @@ writes `INDEX.md` and `project.yml` only if missing. It is idempotent, so it is
 safe even when the tactical mirror in step 5 already created the store directory.
 Do not create the store with an inline `mkdir`; the provisioner is the only place
 a store is made. For a project that is already registered but store-less, use the
-`plastic-add-project-store` skill instead.
+`plastic-store-provisioning` skill instead.
 
 ### 8. Mark Global Intent(s) Completed
 

package/skills/releasing/SKILL.md

@@ -15,6 +15,7 @@ Project configuration drives the workflow - no hardcoded assumptions.
 - [ ] All tests pass (or verification skipped per config)
 - [ ] Merge feature branch to main
 - [ ] Bump version in configured version files
+- [ ] Stable-cut guard passes (version files agree, no pre-release suffix; stable/latest cuts only)
 - [ ] Commit version bump
 - [ ] Create annotated tag
 - [ ] Push to remote with tags
@@ -94,6 +95,25 @@ the full rationale and the already-merged-by-hand no-op case, read
 
 ### 4. Bump Version
 
+**Stable-cut guard.** Before touching any version file for a stable (no pre-release suffix,
+`latest`) cut, run the guard in `scripts/lib/release_guard.rb`:
+
+```ruby
+require "./scripts/lib/release_guard"
+result = ReleaseGuard.check(
+  package_json: "package.json",
+  plugin_json: ".claude-plugin/plugin.json",
+  marketplace_json: ".claude-plugin/marketplace.json",
+  stable: true
+)
+raise "release guard failed: #{result.mismatches} #{result.prerelease_suffix}" unless result.ok?
+```
+
+If it reports a mismatch or a pre-release-suffix violation, stop and resolve it before bumping
+any file. For a beta or alpha cut, pass `stable: false`; only version-file agreement is checked,
+a pre-release suffix is expected. Read `references/release-lines.md` for the stable-line
+guarantees this guard protects.
+
 Determine which files to update from project.yml:
 
 - If `release.version_files` is set: update ALL listed files (they must stay in sync).
@@ -214,26 +234,30 @@ 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.
+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` → find active intent(s) related to this release
+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 `outcome.md` with detailed results
-   b. Write `## Outcome` summary in the intent file (reference the release tag)
-   c. Update `## Insights` with final observations
-   d. Move from `## Active` to `## Completed` in INDEX.md (with today's date)
-   e. Update clusters to show `_(completed)_`
-3. Auto-commit: `cd ~/.plastic && git add . && git commit -m "feat: complete intent <ID> - delivered in <tag-name>"`
+   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.
 
 ### 9. Clean Up the Intent's Worktrees (merge-then-remove)
 
-A release is the merge-then-remove path for the intent's worktrees (intent 73c3): the
-intent's code branch is merged back into the default branch BEFORE the worktree is removed.
-Drive it through `Worktree.finish` with `merge: true`, which merges the code branch, then
-removes both worktrees (code + paired store), prunes both repos, and clears the worktree block
-from the bridge:
+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
+73c3), so the intent's code branch is merged back into the default branch BEFORE the worktree
+is removed. Drive it through `Worktree.finish` with `merge: true`, which merges the code
+branch, then removes both worktrees (code + paired store), prunes both repos, and clears the
+worktree block from the bridge:
 
 ```bash
 ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/bridge -e \
@@ -241,13 +265,39 @@ ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/bridge -e \
 ```
 
 (Uses `discover_bridge`, not a bare session-keyed `Bridge.read`, because a session can own more
-than one live bridge now — intent 131 — and `discover_bridge` resolves the right one for this cwd.)
+than one live bridge now (intent 131) and `discover_bridge` resolves the right one for this cwd.)
 
 Honor the worktree-cleanup rule: never leave an orphaned worktree, and run `git worktree
 prune` in the affected repo if you hit a stale reference. For why this is the one place the
 merge-vs-remove policy lands on merge, and the fail-open/idempotent guarantees of `finish`,
 read `references/promotion-and-tagging.md`.
 
+## Release lines and channels
+
+Two lanes get code to a release, on top of the workflow above.
+
+- **Default lane.** Branch, merge to main, cut stable, publish to npm `latest`. This is the
+  workflow in the steps above, unchanged. Use it for additive, suite-verifiable,
+  low-blast-radius work.
+- **Beta-verified lane.** Branch, merge to `beta`, publish to the npm `beta` channel, verify in
+  real use, then merge to main and cut stable. Use it for work that changes operational
+  substrate, or carries data, migration, lock, or state-format risk, or that a hermetic suite
+  cannot fully validate on its own.
+
+**Stable-line guarantees.** An external `latest` user can rely on:
+
+- `main` is always green and releasable; no pending revert awaiting re-land sits on `main`.
+- A stable release carries no pre-release suffix, publishes to `latest`, and the newest release
+  always carries the GitHub "Latest" badge.
+- The three version files always agree, checked by `scripts/lib/release_guard.rb` (see Bump
+  Version above).
+- A stable cut collects only intents that cleared their lane's verification bar.
+- Channel semantics are fixed: `latest` is stable, `beta` is the verification line, `alpha` is
+  experimental.
+
+Read `references/release-lines.md` for the full lane-routing detail, the version-line map, and
+the intent-41 re-land playbook.
+
 ## Conventions
 
 - **Annotated tags only** - `git tag -a`, never lightweight tags
@@ -262,6 +312,8 @@ read `references/promotion-and-tagging.md`.
 
 ## References
 
+- Read `references/release-lines.md` for the two release lanes, the stable-line guarantees,
+  the version-line map, and the intent-41 re-land playbook before starting any release
 - When promoting a pre-release across channels (`--promote beta`/`--promote stable`) or
   tagging a historical release retroactively, read `references/promotion-and-tagging.md`
   for the exact commands and rules first

package/skills/releasing/references/release-lines.md

@@ -0,0 +1,105 @@
+# Release Lines and Channels
+
+The two release lanes, the version-line map, and the intent-41 re-land playbook: the deep
+material behind SKILL.md's "Release lines and channels" section.
+
+## Table of Contents
+
+- [The two lanes](#the-two-lanes)
+- [Routing rule](#routing-rule)
+- [Stable-line guarantees](#stable-line-guarantees)
+- [Version-line map](#version-line-map)
+- [Intent 41 re-land playbook](#intent-41-re-land-playbook)
+
+## The two lanes
+
+**Default lane.** Branch, merge to `main` with `--no-ff`, cut stable, publish to npm `latest`.
+This is the workflow SKILL.md documents step by step. It is the path for additive,
+suite-verifiable, low-blast-radius work: new skills, prose, deterministic scripts, anything a
+green Minitest run can fully vouch for.
+
+**Beta-verified lane.** Branch, merge to the `beta` branch, publish to the npm `beta` dist-tag,
+verify in real use, then merge `beta` into `main` and cut stable. It sits on top of the existing
+promotion mechanics (`--promote beta` / `--promote stable`, linear only, see
+`promotion-and-tagging.md`); it names when to use them, not new machinery.
+
+## Routing rule
+
+Work rides the beta-verified lane when it changes operational substrate, carries data,
+migration, lock, or state-format risk, or cannot be fully validated by a hermetic suite alone.
+Everything else merges straight to main.
+
+Intent 41's DB layer is the archetypal beta-lane case: it replaces the bridge, lock, and session
+file formats with a new persistent SQLite substrate. A green suite proves the code correct; it
+cannot prove the new substrate survives real, uncontrolled usage, so real-use verification on
+beta comes first.
+
+The manual-first roadmap's eight 1.1.0 intents (158a, 163, 161, 164, 165, 168, 166, 159) are all
+default-lane: skill directory renames, prose rewrites, deterministic step scripts. Additive, and
+fully suite-verified.
+
+## Stable-line guarantees
+
+What an external `latest` user can rely on:
+
+1. `main` is always green and releasable. No pending revert awaiting re-land sits on `main`.
+   When something needs beta verification, it comes out of `main` the same day that need is
+   found (the 226023f precedent), never left half-landed.
+2. A stable release carries no pre-release suffix, publishes to npm `latest`, and the newest
+   stable release always carries the GitHub "Latest" badge (`gh release create --latest` on
+   every cut).
+3. The three repo version files (`package.json`, `.claude-plugin/plugin.json`,
+   `.claude-plugin/marketplace.json`) always agree. Checked mechanically by
+   `scripts/lib/release_guard.rb`.
+4. A stable cut collects only intents that cleared their lane's bar: default-lane intents by a
+   green suite, beta-lane intents by suite green plus their lane's own verification (real-use
+   signal, owner sign-off).
+5. Channel semantics are fixed: `latest` is stable and what an external user should run; `beta`
+   is the verification line, published but expected to move; `alpha` is experimental,
+   pre-verification.
+
+## Version-line map
+
+| Line | State | What lands here |
+|---|---|---|
+| `1.1.x` | Current stable line (main) | Additive or low-risk work merged straight to main; interim stable cuts, including 171's wave-6 cut, stay in this line |
+| `1.2.0-beta.1` | On beta (`9ec194b`, unpublished) | Intent 41's DB layer, restored over 1.1.0 by revert-of-revert (`c48601a` then `9ec194b`) |
+| `1.2.0` | Reserved | The stable graduation of the DB layer, once beta verification passes; not claimed by any interim `1.1.x` cut |
+
+A beta-graduated substrate change claims its reserved minor at the moment it actually merges to
+main, not before. Nothing else on the `1.1.x` line is blocked waiting for `1.2.0`.
+
+## Intent 41 re-land playbook
+
+Written for the wave-6 cut intent (171) and any future reader to pick a version without
+re-deriving this decision.
+
+**Current state.** The revert-of-revert already sits on the `beta` branch at `9ec194b`, on top
+of 1.1.0, versioned `1.2.0-beta.1` (`c48601a`). There is nothing left to execute on the git side;
+this playbook describes what happens next, not a pending action.
+
+**Preconditions**, both required before any npm publish of `1.2.0-beta.1`:
+
+- (a) One documentation pass over beta-line skills and docs for the hybrid savepoint contract:
+  on beta, only the terminal Done bookend still writes a live `savepoint.md`; every other
+  milestone lives in `savepoint_events` plus a committed JSONL export. Beta-line prose that
+  still assumes an always-live ledger needs updating first, so a beta-line reader does not
+  mistake an empty ledger for a broken one.
+- (b) The owner's manual verification of the DB layer in real use. This is a dogfood signal,
+  distinct from the independently-reviewed green suite that already exists on beta.
+
+**Trigger**, owner-gated: the owner publishes `1.2.0-beta.1` to the npm `beta` dist-tag. This is
+explicitly not this intent's, nor any agent's, call to make.
+
+**Verification.** An external tester plus the owner verify the DB layer on the beta channel.
+
+**Completion.** Once verified, `beta` merges into `main`, `1.2.0` is cut stable, and it publishes
+to npm `latest`.
+
+**Version mechanics.** `1.2.0` is reserved for this graduation. The `1.1.x` line stays the
+stable line until `1.2.0` actually lands. `1.2.0-beta.1` graduates to `1.2.0` stable by dropping
+the pre-release suffix; nothing else about the version number changes.
+
+**Consumed by 171.** The wave-6 consistency-dividend cut stays in the `1.1.x` line. It does not
+ride intent 41 and needs no further derivation: intent 41 keeps its own `1.2.0` line on beta,
+independent of whatever `1.1.x` number 171 lands on.

package/skills/roadmap/SKILL.md

@@ -21,7 +21,10 @@ wave entry mirrors that intent's status in `INDEX.md` (`queued`/`delivering`/`de
 **`INDEX.md` is the single writer of intent status; on any conflict INDEX wins and the roadmap
 entry is corrected to match.**
 
-The skill operates on the file directly via Read/Edit; no helper script.
+The skill operates on the roadmap file directly via Read/Edit. The one deterministic helper it
+uses is the savepoint ledger writer (`scripts/roadmap-savepoint`, `append`/`rebuild`); every verb's
+closing step calls `append` after its Read/Edit, and the roadmap `.md` file itself stays
+Read/Edit-only.
 
 ## Verbs
 
@@ -50,3 +53,6 @@ verb above.
 - Additive: this skill introduces no gate, lock, or hook, and does not change `INDEX.md`'s section
   list or the intent frontmatter schema.
 - Closing a roadmap moves it to `roadmaps/archived/{slug}.md` so `roadmaps/` lists only live ones.
+- Every verb also appends a machine ledger line to the roadmap's name-paired
+  `roadmaps/{slug}.savepoint.md`, the derived counterpart to the human `## Log`; see
+  `references/file-format.md` for its shape and location.

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

@@ -11,7 +11,9 @@ roadmap.
 
 `roadmaps/` lists only live (open or in-flight) roadmaps. Once a roadmap's `## Goal` is reached,
 its file moves to `roadmaps/archived/{slug}.md` (see Close/archive in `operations.md`); the
-`archived/` subdirectory is scaffolded once, alongside `roadmaps/`, with a `.gitkeep`.
+`archived/` subdirectory is scaffolded once, alongside `roadmaps/`, with a `.gitkeep`. Its
+name-paired ledger, `roadmaps/{slug}.savepoint.md` (see Savepoint ledger below), moves alongside
+it in the same Close/archive step.
 
 ## The four sections (in order)
 
@@ -63,6 +65,33 @@ that entry-intent's `outcome.md`:
 The log line never restates `outcome.md` detail; it points at it (lossless-by-reference). This
 complements, and does not replace, `INDEX.md`'s `## Completed` section or `CHANGELOG.md`.
 
+## Savepoint ledger
+
+`roadmaps/{slug}.savepoint.md` is the name-paired sibling of `roadmaps/{slug}.md`: the machine
+counterpart to the human `## Log`, moving to `roadmaps/archived/{slug}.savepoint.md` alongside its
+roadmap on close (see Close/archive). It is created lazily by the first `append` call; there is no
+template to scaffold.
+
+Line shape, one event per line, append-only, newest at the bottom:
+
+```
+<UTC-iso8601>  <event>  <detail>
+```
+
+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.
+
+`## 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,
+controlled-vocabulary record a coordinator reads at a glance. Both are append-only; neither edits
+the other.
+
+The ledger is derived and rebuildable (`ruby ~/.plastic/scripts/roadmap-savepoint rebuild --roadmap
+roadmaps/{slug}.md`, reconstructing it from `## Log`), never a status source: `INDEX.md` stays the
+single writer of intent status, exactly as for the roadmap file itself.
+
 ## Worked example
 
 ```

package/skills/roadmap/references/operations.md

@@ -20,7 +20,10 @@ next" in under a minute, just from this one file.
    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.
-7. Refresh the QMD index for this roadmap (no-op when QMD is absent), in the background so it
+7. Append the ledger event (derived, idempotent, safe to re-run; never writes INDEX or roadmap
+   status; creates `roadmaps/<slug>.savepoint.md` lazily): `ruby ~/.plastic/scripts/roadmap-savepoint
+   append --roadmap roadmaps/<slug>.md --event created --detail "<slug>: <title>"`.
+8. 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`.
 
 ## Add / reorder entries
@@ -34,6 +37,10 @@ next" in under a minute, just from this one file.
   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`).
+- 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
+  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`.
 
@@ -49,7 +56,12 @@ next" in under a minute, just from this one file.
    one-line EM-to-CTO entry described in `file-format.md` (date, what shipped and its impact in
    plain language, then a link to that intent's `outcome.md`). For other transitions, write a
    short dated plain-language line (no codenames, no jargon).
-5. Refresh the QMD index for this roadmap (no-op when QMD is absent), in the background so it
+5. Append the ledger event, only when the status token actually changed (derived, idempotent,
+   never writes INDEX or roadmap status): map the new status to its mechanized event (`delivered`
+   -> `merged`, `delivering` -> `dispatched`, `blocked`/`abandoned` -> `parked`), then `ruby
+   ~/.plastic/scripts/roadmap-savepoint append --roadmap roadmaps/<slug>.md --event <event>
+   --detail "<intent-id>"` (add a sha in `<detail>` when one is known).
+6. 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`.
 
 ## Append a log line
@@ -60,6 +72,10 @@ next" in under a minute, just from this one file.
   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
   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
+  roadmaps/<slug>.md --event release --detail "<version>"`; otherwise append the mechanized event
+  matching the bookkeeping line just written (see the per-verb event mapping on this page).
 - 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`.
 
@@ -80,9 +96,13 @@ next" in under a minute, just from this one file.
    `abandoned` with a recorded reason, plus whatever else the goal states).
 2. Create `roadmaps/archived/` beside `roadmaps/` (both siblings of `INDEX.md`) if it does not
    exist yet.
-3. Move the file: `roadmaps/{slug}.md` -> `roadmaps/archived/{slug}.md`. `roadmaps/` itself then
-   lists only live (open or in-flight) roadmaps.
-4. Append the final `## Log` line before or as part of the move:
+3. Append the ledger closed event, while the roadmap is still at its live path (derived,
+   idempotent, never writes INDEX or roadmap status): `ruby ~/.plastic/scripts/roadmap-savepoint
+   append --roadmap roadmaps/<slug>.md --event closed --detail "<slug>"`.
+4. Move BOTH files: `roadmaps/{slug}.md` -> `roadmaps/archived/{slug}.md` AND
+   `roadmaps/{slug}.savepoint.md` -> `roadmaps/archived/{slug}.savepoint.md`. `roadmaps/` itself
+   then lists only live (open or in-flight) roadmaps.
+5. Append the final `## Log` line before or as part of the move:
    `- <YYYY-MM-DD HH:MM UTC> roadmap closed`.
-5. Refresh the QMD index for this roadmap (no-op when QMD is absent), in the background so it
+6. 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`.

package/skills/roadmap-continuing/SKILL.md

@@ -0,0 +1,85 @@
+---
+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
+  indirect ask that never names a roadmap directly (for example "where did that batch of
+  tickets 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.
+user-invocable: true
+---
+
+# Roadmap Continuing - resume the mid-flight roadmap
+
+`plastic-roadmap-continuing` is the roadmap route of `plastic-continuing`. It finds the tier's
+mid-flight roadmap, presents its state, then asks the user how to proceed, exactly once.
+
+Before intent 158a1 there was no automated way to do this: the `171` (consistency-dividend)
+roadmap handoff had to be resumed by hand, carried as a free-prose note in `171`'s own
+`## Insights`. This skill closes that gap.
+
+## Find the mid-flight roadmap
+
+1. Determine the tier (project vs. global) and enumerate that tier's live `roadmaps/*.md`
+   (exclude `roadmaps/archived/`). Read via Read/glob, or `plastic-roadmap`'s Read/consume
+   verb. See `plastic-roadmap`'s `references/file-format.md` for the file grammar; do not
+   duplicate it here.
+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
+   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):
+
+   ```bash
+   ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <tier>/roadmaps --which
+   ```
+
+   Read `state` and the winning `roadmap`. When `state` is `tie`, `tie_candidates` lists the
+   equally-live roadmaps to present side by side; the single "auto or guided?" ask below
+   doubles as the resolution. `roadmap-next` liveness-ranks the same way this skill used to do
+   by eye (a `delivering` or `blocked` entry wins, else the newest ledger or `## Log`
+   timestamp), now deterministically. See `references/liveness-ranking.md` for the algorithm it
+   implements.
+4. A genuine tie (two candidates equally live) is presented to the user and resolved by the
+   single ask below, not silently picked.
+
+## Present state
+
+Present the chosen roadmap's `## Goal`, the current wave 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.
+
+## Ask once
+
+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.
+
+Never re-ask. No new roadmap or INDEX status field is invented anywhere in this flow.
+
+## The shared reader
+
+Liveness ranking and frontier selection live in one place, `scripts/lib/roadmap_queue.rb`
+(intent 148), behind the `scripts/roadmap-next` CLI. This skill calls it in which mode rather
+than ranking roadmaps in prose, so the auto loop (`plastic-auto`) and this skill share exactly
+one implementation (no forked ranking logic). 158a1 originally added no script because the
+benefit was marginal for a read-time judgment; the auto-loop consumer flipped that calculus by
+making the ranking load-bearing and deterministic. The reader is read-only: it consumes the
+roadmap `.md`, the 134 `<slug>.savepoint.md` ledger, and INDEX.md, and writes nothing. INDEX.md
+stays the single status writer.
+
+## Caller contract: who writes the ledger
+
+This skill is a reader, not a writer, of `roadmaps/<slug>.savepoint.md`. The coordinator flows
+(`plastic-auto`, the enforcer, and this skill's own resume-and-hand-off path) call `ruby
+~/.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.
+
+## References
+
+- `references/liveness-ranking.md` - the read-time ranking algorithm and the tie rule.

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

@@ -0,0 +1,82 @@
+{
+  "skill_name": "plastic-roadmap-continuing",
+  "notes": "Intent 158a1. New roadmap route, closing the gap that forced the 171 (consistency-dividend) roadmap handoff to be resumed by hand. Scopes: description triggering (1-3) and behavior/convention compliance (4-8), the latter checked against SKILL.md.",
+  "results": {
+    "triggering": { "cases": 3, "passed": 3, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 5, "passed": 5, "evidence": "convention checks against skills/roadmap-continuing/SKILL.md and references/liveness-ranking.md" }
+  },
+  "evals": [
+    {
+      "id": 1, "scope": "triggering", "set": "train",
+      "prompt": "continue the roadmap",
+      "expected_output": "Activates plastic-roadmap-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-roadmap-continuing", "observed": "plastic-roadmap-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 2, "scope": "triggering", "set": "train",
+      "prompt": "resume the delivery batch we were shipping",
+      "expected_output": "Activates plastic-roadmap-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-roadmap-continuing", "observed": "plastic-roadmap-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 3, "scope": "triggering", "set": "validation",
+      "prompt": "where did that batch of tickets land",
+      "expected_output": "Activates plastic-roadmap-continuing (indirect trigger: a roadmap-resume request that never names 'roadmap' or 'continue').",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-roadmap-continuing", "observed": "plastic-roadmap-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "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.",
+      "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" }
+      ]
+    },
+    {
+      "id": 5, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill fall back to newest Log date when no candidate is delivering/blocked?",
+      "expected_output": "Among remaining candidates, the most recent ## Log entry timestamp wins.",
+      "files": ["skills/roadmap-continuing/references/liveness-ranking.md"],
+      "assertions": [
+        { "type": "convention", "check": "newest-Log-date fallback documented as step 3", "observed": "present", "result": "pass" }
+      ]
+    },
+    {
+      "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.",
+      "files": ["skills/roadmap-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "Present state precedes Ask once in document order", "observed": "present", "result": "pass" }
+      ]
+    },
+    {
+      "id": 7, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill ask 'auto or guided?' exactly once?",
+      "expected_output": "Exactly one ask, after presenting state; never re-asked.",
+      "files": ["skills/roadmap-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "the literal phrase 'auto or guided' appears on exactly one line of SKILL.md", "observed": "one occurrence", "result": "pass" }
+      ]
+    },
+    {
+      "id": 8, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill invent a new roadmap or INDEX status field, or add a new script?",
+      "expected_output": "No. Liveness is computed at read time from existing files; INDEX.md stays the sole status writer; the enumeration/ranking is prose, not a helper script.",
+      "files": ["skills/roadmap-continuing/SKILL.md", "skills/roadmap-continuing/references/liveness-ranking.md"],
+      "assertions": [
+        { "type": "convention", "check": "no new field or script introduced; 'No new script' section present", "observed": "present", "result": "pass" }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,56 @@
+# Liveness Ranking (read time, no new field)
+
+Depth reference for "Find the mid-flight roadmap" in `SKILL.md`. This is the full algorithm the
+body summarizes. Since intent 148, this algorithm is IMPLEMENTED in
+`scripts/lib/roadmap_queue.rb` behind the `scripts/roadmap-next` CLI; it is no longer a by-eye
+procedure. This page documents what that reader does, and is the specification the reader
+satisfies.
+
+## Why read-time, not a stored field
+
+INDEX.md stays the sole writer of intent status; the roadmap file mirrors it (see
+`plastic-roadmap`'s `references/file-format.md`). Adding a "mid-flight" flag to the roadmap
+file or to INDEX.md would create a second thing to keep in sync for a question that is cheap to
+answer by reading what is already there. So liveness is computed fresh, every call, from the
+tier's live `roadmaps/*.md` files (excluding `roadmaps/archived/`), by `RoadmapQueue` (intent
+148) rather than by eye.
+
+## The algorithm
+
+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.
+   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
+   the bottom) and rank by that line's `YYYY-MM-DD HH:MM UTC` timestamp. The most recent wins.
+   When a candidate's paired `roadmaps/<slug>.savepoint.md` (intent 134) is present, its last
+   line is a cheaper, machine-timestamped read of the same fact (the ledger is derived from `##
+   Log`, so the two should already agree); reading it first is an optimization, not a second
+   source of truth, so a missing or stale ledger never blocks falling back to `## Log` itself.
+4. **Genuine tie -> present, do not silently pick.** If two or more candidates are equally live
+   (for example two roadmaps both idle with `## Log` entries on the same timestamp, or two both
+   showing `delivering` entries with no other signal to separate them), do not choose for the
+   user. Present both/all tied candidates' state side by side, then let the single "auto or
+   guided?" ask (asked once regardless of how many candidates were presented) double as the
+   resolution: the user's answer implicitly picks by naming which roadmap to continue, or the
+   agent asks a short one-line disambiguation immediately before that same single ask, never a
+   second separate prompt.
+
+## What this closes
+
+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
+rather than a by-eye judgment, is the mechanism that replaces that hand-carried note.
+
+## Grammar pointer (do not duplicate)
+
+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
+only the liveness-ranking judgment on top of it.