@zalom/plastic 2.0.0-alpha.27 → 2.0.0-alpha.29

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

@@ -1,105 +0,0 @@
-# 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 (agent-performed channel promotion, 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 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 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 savepoint line 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

@@ -1,90 +0,0 @@
----
-name: plastic-roadmap
-description: Use when the user wants to plan a delivery batch, order waves of intents, ship a batch of intents in one go, track a named collection of intents toward a goal, or asks for a "roadmap". Creates and maintains a roadmap file, a delivery-side collection of intents (the counterpart to a release), separate from INDEX.md status tracking.
-user-invocable: true
----
-
-# Roadmap
-
-A roadmap is a named, ordered, delivery-side collection of intents: the delivery-side counterpart
-to a release (completion-side, `CHANGELOG.md`). It lives at `roadmaps/{slug}.md`, a sibling of
-`INDEX.md` wherever `INDEX.md` lives: the global tier's `~/.plastic/roadmaps/` (beside
-`~/.plastic/INDEX.md`), or a project's root, `~/.plastic/projects/{slug}/roadmaps/` (beside that
-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), `## 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.**
-
-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
-
-| 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 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, 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` |
-
-See `references/file-format.md` for the exact entry-line shape, status vocabulary, checkbox/log
-format, and a worked example. See `references/operations.md` for step-by-step mechanics of each
-verb above.
-
-## Graph (intent 337)
-
-A roadmap may carry an optional `## Graph` section - the same `needs` edge grammar as an
-intent's own `graph.md` (`- <id> needs <id> <id>`, or `- <id> needs nothing` for a root). When
-present, batches are computed from it (`roadmap-graph check`/`render`), not hand-ordered; the
-template scaffolds a fenced example so a new roadmap starts with the section already in place.
-Three verbs, all `--dry-run`-able:
-
-| Verb | What it does |
-|------|--------------|
-| `roadmap-graph check <roadmap.md>` | Prints the computed batches, the ready set, and any dangling id (a graph names it, no batch lists it); exits 1 on a cyclic graph or a dangling id. |
-| `roadmap-graph render <roadmap.md>` | Writes `## Tree` (a box-drawing render of the graph) and regroups the batch/wave section from the computed batches, entry lines carried over verbatim. |
-| `roadmap-graph migrate <roadmap.md>` | Derives a conservative `## Graph` for a graphless roadmap from its existing batch order (batch N needs every entry of batch N-1); never overwrites an existing graph. |
-
-A roadmap with no `## Graph` section keeps working exactly as before (wave-order dispatch); the
-graph is additive, never required.
-
-Read `../plastic-conventions/references/roadmaps.md` for the roadmap file format, batch
-semantics, and the status-mirror rule that this skill's own file-format reference builds on. This
-path resolves relative to this skill's own installed directory.
-
-## Reports (intent 331f)
-
-Each verb prints its report screen as the first characters of the reply: nothing before it, no
-fence, or the hook cannot paint it.
-
-- Create prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> plan`.
-- Read / consume prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> state`.
-- Close / archive prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> delivered`.
-
-## Notes
-
-- File location and the four-section shape are identical across tiers; do not invent a different
-  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.
-- 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
-  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

@@ -1,134 +0,0 @@
-# Roadmap File Format
-
-## Location
-
-`roadmaps/{slug}.md`, a sibling of `INDEX.md`, wherever `INDEX.md` lives. For the global tier
-that is `~/.plastic/roadmaps/{slug}.md` (beside `~/.plastic/INDEX.md`); for any project it is
-that project's root, `~/.plastic/projects/{slug}/roadmaps/{slug}.md` (beside that project's
-`INDEX.md` and `project.yml`). `roadmaps/` never sits inside `store/`: `store/` holds intent
-directories, not project artifacts. Create the `roadmaps/` directory the first time a tier gets a
-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`. 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)
-
-1. **Title/meta header** — `# Roadmap: <name>` plus a one-line meta sentence naming what the
-   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. **`## 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 batch (or wave, on a roadmap still using the legacy heading), as a
-Markdown checkbox:
-
-```
-- [x] <intent-id> <title> — delivered
-- [ ] <intent-id> <title> — <status>
-```
-
-`<intent-id>` and `<title>` match the intent's `INDEX.md` entry (terse, not a summary). The
-checkbox is checked (`[x]`) once `<status>` is `delivered`, unchecked (`[ ]`) for every other
-status. The checkbox is a rendering of the mirrored status token, not a second piece of state: a
-human scanning the file sees at a glance what shipped (checked) and what has not (unchecked),
-while the trailing token still carries the precise state (`queued`/`delivering`/`blocked`/
-`abandoned`) when unchecked.
-
-## Status vocabulary
-
-`queued` | `delivering` | `delivered` | `abandoned` | `blocked`
-
-Status is a **mirror** of `INDEX.md`. `INDEX.md` is the single writer of intent status; on any
-conflict INDEX wins and the roadmap entry (both its token and its checkbox) is corrected to match
-it. The roadmap never sets a status that INDEX does not already reflect.
-
-## Log line shape
-
-One line per event, starting `YYYY-MM-DD HH:MM UTC` (human-readable, sortable, zone-explicit so
-same-day parallel deliveries can still be ordered), in plain-language EM-to-CTO voice: what shipped
-and why it matters to a non-expert reader, no jargon or internal codenames, ending with a link to
-that entry-intent's `outcome.md`:
-
-```
-- <YYYY-MM-DD HH:MM UTC> <one plain-language sentence: what shipped, its impact> — see store/<id>--<slug>/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`, `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,
-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.
-
-## Screens read this format (intent 331c)
-
-`report-screen roadmap <roadmap.md> plan|state|delivered` reads exactly the shapes above and
-nothing else: `## Goal`'s first sentence, the `## Batches` (or legacy `## Waves`) grouping and its
-entries (through `RoadmapQueue`'s own reconciled reader - INDEX still wins), and the events from
-the savepoint ledger, falling back to `## Log` classified through the same keyword vocabulary when
-no ledger file exists (an archived roadmap moved before intent 134 shipped, `manual-first.md`
-among them). A screen never invents a status, a time, or a merge sha the file, `INDEX.md`, or the
-ledger did not already carry - the same `not recorded` floor the intent screens use.
-
-## Worked example
-
-```
-# Roadmap: Stable 1.0
-
-Delivery-side collection of intents that close out the pre-1.0 hardening pass, plastic project store.
-
-## Goal
-All intents below are delivered, the suite is green, and a 1.0.0 release is cut.
-
-## 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.
-
-### Batch 1
-- [x] 121 Fix bash gate redirect parsing — delivered
-- [ ] 130 Proportional cycle tiers — delivering
-
-### Batch 2
-- [x] 124 Roadmap feature — delivered
-
-## Log
-- 2026-07-06 14:32 UTC Shipped the bash-gate redirect fix so quoted arrows and heredoc trailers
-  stop blocking legitimate commits — see store/121--fix-bash-gate-redirect-parsing/outcome.md.
-```

package/skills/roadmap/references/operations.md

@@ -1,112 +0,0 @@
-# Roadmap Operations
-
-All six verbs operate on the Markdown file directly (Read/Edit). No helper script exists or is
-needed; the file is small and the edits are mechanical.
-
-**Human-comprehension goal.** Every operation below should leave the file such that a cold reader
-(no INDEX.md, no intent directories open) can answer "what's shipped, what's running, what's
-next" in under a minute, just from this one file.
-
-## Create
-
-1. Pick a `slug` (kebab-case, descriptive) and a `title`.
-2. Resolve the tier root: the directory that holds `INDEX.md` (a project's root, beside
-   `project.yml`, or `~/.plastic/` for the global tier). `roadmaps/` is always a sibling of
-   `INDEX.md`, never inside `store/`. Create `roadmaps/` there if it does not exist yet.
-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 `## 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.
-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
-
-- **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 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 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 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`.
-
-## Sync status mirror
-
-1. Read the intent's real status from `INDEX.md` (`## Active`, `## Future`, `## Completed`, or
-   `## Abandoned`).
-2. Compare to the roadmap entry's `<status>` token.
-3. If they differ, **INDEX wins**: rewrite the roadmap entry's status token to match INDEX, and
-   flip its checkbox in the same edit (`[x]` when the new status is `delivered`, `[ ]` otherwise).
-   Never edit INDEX.md from the roadmap skill; the roadmap is a mirror, not a second writer.
-4. Append a `## Log` line recording the change. When the new status is `delivered`, write the
-   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. 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
-
-- One line per event, starting `YYYY-MM-DD HH:MM UTC`, appended at the bottom of `## Log`. Never
-  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 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
-  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`.
-
-## Read / consume
-
-- 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
-
-1. Confirm the roadmap's `## Goal` prose condition is met (every entry `delivered` or explicitly
-   `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. 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`.
-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/rollback/SKILL.md

@@ -1,91 +0,0 @@
----
-name: plastic-rollback
-description: Use when the user wants to see their Plastic version history or roll back to a previously-installed version after a bad release. Manages the local, append-only versions.json ledger and steps between versions the user has actually run. For moving to a brand-new release, use plastic-update instead.
-user-invocable: true
----
-
-# Plastic Rollback: local version time-machine
-
-## When to Use
-- "show plastic versions", "version history", "what versions have I run"
-- "roll back plastic", "downgrade", "go back to the version that worked", "revert plastic"
-- A new version broke something and the user wants their last known-good build
-
-For upgrading to a **new** release, use `plastic-update`. This skill only navigates
-versions you have **already installed**, the ones recorded in the ledger.
-
-## Read-only by default
-
-A flagless run only prints the version history table. It never switches, never prompts,
-and never offers to keep going further back. Switching a version always needs an
-explicit target, named with `--version`.
-
-## Channel rule
-
-`rollback` restores whichever build you name from the ledger, it does not take a channel
-flag for the target. The pinned `<channel>` below is only the npx invocation itself:
-derive it from `~/.plastic/VERSION` the same way as the other lifecycle skills,
-`-alpha` to `@alpha`, `-beta` to `@beta`, otherwise `@latest`.
-
-## The ledger
-
-`~/.plastic/versions.json` is an **append-only JSONL** ledger, one line per version
-change, never modified or deleted:
-
-```json
-{"version":"1.0.0-alpha.17","action":"install","at":"..."}
-{"version":"1.0.0-alpha.18","action":"update","at":"..."}
-```
-
-`action` is one of `install`, `reinstall`, `update`, `downgrade` (derived from version
-direction; the channel is derived from the version string, never stored). It is a
-troubleshooting record.
-
-## Procedure
-
-### Show history (read-only, no switch)
-
-```bash
-npx -y @zalom/plastic@<channel> rollback
-```
-
-Prints the table with the currently-installed version marked. Never switches, never
-prompts, no matter what the last recorded action was.
-
-### Switch to a specific version
-
-```bash
-npx -y @zalom/plastic@<channel> rollback --version 1.0.0-alpha.15
-```
-
-The only way to actually switch. The target must be a version you have actually run (the
-ledger); the direction (upgrade or downgrade) is derived automatically by comparing the
-target to the installed version.
-
-`--downgrade --version V` and `--upgrade --version V` are accepted as explicit-target
-synonyms of `--version V`, the direction flag is descriptive only:
-
-```bash
-npx -y @zalom/plastic@<channel> rollback --downgrade --version 1.0.0-alpha.15
-npx -y @zalom/plastic@<channel> rollback --upgrade --version 1.0.0-alpha.18
-```
-
-A bare `--downgrade` or `--upgrade` with no `--version` is an error: it prints a message
-asking for an explicit target and performs no switch.
-
-### After any change
-
-Run `plastic-doctor` to confirm health, then emit the reporting block and suggest
-`/clear` so the session picks up the swapped conventions:
-
-```
-Plastic rollback (<channel>)
-Command:  npx -y @zalom/plastic@<channel> rollback <flags>
-Version:  <before> -> <after>
-Doctor:   <summary or "all clear">
-```
-
-## Notes
-- The ledger is **never** edited or pruned, it is the audit trail.
-- Switching cannot un-migrate a store-format change; if a warning appears, surface it to
-  the user rather than forcing the switch.

package/skills/tutorial/SKILL.md

@@ -1,66 +0,0 @@
----
-name: plastic-tutorial
-description: >-
-  Teach a new user how Plastic works through one of three hands-on tracks: deliver a first
-  intent stage by stage, hand delivery to the agent in auto mode, or grow a founding intent
-  into a small project with a roadmap. Use when the user says "tutorial", "teach me Plastic",
-  "walk me through Plastic", "how do I use Plastic", or asks what Plastic can actually do
-  before trying it on real work.
-user-invocable: true
----
-
-# Plastic Tutorial
-
-An interactive coach, not an automator. It walks one of three tracks, one step at a time, and
-keeps no state of its own: the intent being used for the walkthrough is the progress bar.
-
-## The three tracks
-
-This is the one menu in the whole skill. Offer it, then route into the picked track's
-reference. Every checkpoint inside a track is prose, never another menu.
-
-1. **Guided**: deliver a first intent, stage by stage, approving each step yourself. Routes to
-   `references/track-1-guided.md`.
-2. **Auto**: create the intent, write its `graph.md`, then hand it to `scripts/runner step` to
-   drive every node to the end, watching the record and reports as it works. Routes to
-   `references/track-2-auto.md`.
-3. **Projects and roadmaps**: grow a founding intent into a small real project, add more
-   intents, and plan a delivery batch with a roadmap. Routes to
-   `references/track-3-projects-and-roadmaps.md`.
-
-If the user names what they want instead of picking a number ("show me auto mode", "I want a
-roadmap", "walk me through my first intent"), route straight to the matching track without
-showing the menu again.
-
-## The coach contract
-
-Narrate one step at a time: say what the next station does, then hand control back so the
-user types the real command themselves. After they run it, look at what appeared (a file, a
-ledger line, a report) and debrief in plain words before moving to the next station. Never
-run a station's command on the user's behalf; the tutorial teaches the shape of the work, it
-does not do the work.
-
-Keep no new state. The intent's own lifecycle stage and savepoint are the only progress
-record. This skill never writes a "tutorial progress" file of its own.
-
-## The resume rule
-
-To pause, the user says "continue the tutorial." Read the walkthrough intent's current stage
-and savepoint (for track 3, check which project-scaffolding steps are already on disk) and
-resume at the matching station. Do not restart from station one, and do not ask the user to
-remember where they left off.
-
-## Routing table
-
-| Trigger | Reference |
-|---|---|
-| User picks "guided", or names their first intent, a first delivery, or learning the stages one at a time | `references/track-1-guided.md` |
-| User picks "auto", or says "hand it to the agent", "run the whole thing", "show me auto mode" | `references/track-2-auto.md` |
-| User picks "projects and roadmaps", or says "start a project", "I want a roadmap", "plan a batch of work" | `references/track-3-projects-and-roadmaps.md` |
-
-## Before any track
-
-Every track opens with the same two checks: run `/plastic-update` first (`$plastic-update` on
-Codex), so the walkthrough matches what is actually installed, and work in a sandbox (a
-throwaway repo, or a global-store intent) so nothing real is touched by mistake. Each reference
-restates this briefly; do not skip it even if the user seems experienced.