@zalom/plastic 1.1.0 → 1.1.2

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

@@ -0,0 +1,100 @@
+{
+  "skill_name": "plastic-project-continuing",
+  "notes": "Intent 158a1. New project route, absorbing intent-continuing's Continue/Priority Order/Stale Future Intents sections (move, not duplicate). Scopes: description triggering (1-3) and behavior/convention compliance (4-10), the latter checked against SKILL.md.",
+  "results": {
+    "triggering": { "cases": 3, "passed": 3, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 7, "passed": 7, "evidence": "convention checks against skills/project-continuing/SKILL.md after the 158a1 extraction; id 10 (intent 170) added for the research-dispatch wiring of plastic-future-intent-researcher" }
+  },
+  "evals": [
+    {
+      "id": 1, "scope": "triggering", "set": "train",
+      "prompt": "what should I work on in this project",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 2, "scope": "triggering", "set": "train",
+      "prompt": "land me on the project board",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 3, "scope": "triggering", "set": "validation",
+      "prompt": "continue",
+      "expected_output": "Bare 'continue' with no specific intent or roadmap named reaches plastic-project-continuing via plastic-continuing's default route.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 4, "scope": "behavior", "set": "train",
+      "prompt": "Is dashboard selection project-aware?",
+      "expected_output": "Project loaded -> `dashboard.rb project <slug> --data` -> fills dashboard-project.md; otherwise -> `dashboard.rb continue --data`. Skill only invokes, does not render.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the board)' section", "result": "pass" }
+      ]
+    },
+    {
+      "id": 5, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill cite the classification rules by name instead of copying the logic?",
+      "expected_output": "SKILL.md's 'Deciding rules' section names Effort/Value/Flags/Override/Caps and points to plastic-dashboard's references/classification.md; it does not restate the rule definitions.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "rule names cited, no copied Effort/Value/Flags/Override/Caps definitions", "observed": "present in 'Deciding rules'", "result": "pass" }
+      ]
+    },
+    {
+      "id": 6, "scope": "behavior", "set": "train",
+      "prompt": "Does the project route ask 'auto or guided?' before stopping?",
+      "expected_output": "No. The project route presents state then stops; it asks nothing. The single ask lives in plastic-intent-starting once a specific intent is named.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "no 'auto or guided' ask anywhere in SKILL.md", "observed": "absent", "result": "pass" }
+      ]
+    },
+    {
+      "id": 7, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill present the board before stopping?",
+      "expected_output": "The filled Markdown board is presented in the reply (non-optional), then a 'Then stop' section waits for the user.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "presentation is mandatory and precedes the 'Then stop' wait", "observed": "present", "result": "pass" }
+      ]
+    },
+    {
+      "id": 8, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill carry the intent-149 coordination note?",
+      "expected_output": "A 'Coordination' section records that intent 149 has landed (dashboard demoted to prose, no Value x Effort grid) and confirms the rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'149' present with the landed coordination note", "observed": "present: 'Intent 149 has landed' with confirmed rule-name citations and dashboard.rb path", "result": "pass" }
+      ]
+    },
+    {
+      "id": 9, "scope": "behavior", "set": "validation",
+      "prompt": "Are Priority Order and Stale Future Intents present here and only here (not in intent-continuing)?",
+      "expected_output": "Both sections are present verbatim in this skill; they no longer exist in skills/intent-continuing/SKILL.md.",
+      "files": ["skills/project-continuing/SKILL.md", "skills/intent-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'## Priority Order' and '## Stale Future Intents' present here, absent from intent-continuing", "observed": "present here, absent there", "result": "pass" }
+      ]
+    },
+    {
+      "id": 10, "scope": "behavior", "set": "validation",
+      "prompt": "In the stale-future-intent triage, the user picks option c) Defer to agent: research. What happens?",
+      "expected_output": "A real dispatch, not a label: plastic-future-intent-researcher's model is resolved via `read-config agents.models.<basename> --project <repo>` (never bare frontmatter, sanctioned-override-aware), the agent is dispatched via the Agent tool on the selected stale future intent and writes its findings into that intent's `## Context`, then the skill re-presents the stale-future-intent triage.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "the 'Defer to agent: research' paragraph under Stale Future Intents resolves the model via read-config (not bare frontmatter), dispatches plastic-future-intent-researcher via the Agent tool, and re-presents the triage after the agent returns", "observed": "'Defer to agent: research.' paragraph present: resolves via read-config agents.models.<basename> --project <repo>, dispatches subagent_type plastic-future-intent-researcher, findings land in ## Context, then re-presents the triage", "result": "pass" }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,33 @@
+# Board Fill Mechanics
+
+Depth reference for the "Continue (present the board)" section of `SKILL.md`. The fill itself
+is mechanical; `plastic-dashboard` owns the rules, this page is a pointer plus the detail that
+would otherwise bloat the SKILL.md body.
+
+## Fill rules (owned by plastic-dashboard, summarized here for convenience)
+
+- `{{a.b.count}}` -> the integer (e.g. `counts.active` is that count).
+- `{{...lines}}` -> join the list's `.line` strings with real newlines (one per line). These
+  are ordinary prose lines; never add a `-` prefix, never emit `<br>`. An empty list renders
+  `_(none)_`.
+- `next_work.lines` -> the most-valuable next work, already ranked and capped.
+- `active.lines` / `future.lines` (project board) -> one line per intent, already formatted.
+- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) -> substitute verbatim.
+
+No re-sorting, no re-summarizing, no hand-written prose replacing a line the payload already
+supplies. Same store state produces a byte-identical payload regardless of model.
+
+## Store-health surfacing
+
+Every board load runs the scoped `doctor --store <scope>` check server-side (inside
+`dashboard.rb`, not this skill). The payload carries the result as `store_health` (`{scope,
+status, summary, failing_checks}`). Render it as a single line, for example `store health:
+pass (3/3)` or `store health: warn (orphaned_intents)`. A warn or fail is informational only;
+it never blocks presenting the board.
+
+## Project vs. global fallback
+
+The project route's default target is the project board. When no project is loaded (the rare
+case where this route is reached without a registered project in scope), fall back to the
+global board payload (`dashboard.rb continue --data`) rather than failing. This mirrors the
+router's D6 default: a bare "continue" always lands somewhere useful.

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).
@@ -252,6 +272,32 @@ 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`.
 
+## 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
@@ -266,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" }
+      ]
+    }
+  ]
+}