@zalom/plastic 2.0.0-alpha.9 → 2.0.1

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

@@ -1,124 +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.
-
-## 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,65 +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**: hand delivery to the agent and watch 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.

package/skills/tutorial/evals/evals.json

@@ -1,186 +0,0 @@
-{
-  "skill_name": "plastic-tutorial",
-  "notes": "Intent 166, Phase 1. Scopes: triggering (1-6, should and should-not with near-misses) and track routing (7-10, one case per track plus a direct-menu case). plastic-tutorial is a natural-language guided command with no backing Ruby test, so every assertion carries result: expect-pass pending a real observed run, per the intent-speccing evals.json convention. Phase 2 (post-164) can tighten these into observed pass/fail after a paired run.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "I want a tutorial on how Plastic works.",
-      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Teach me Plastic from scratch.",
-      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Walk me through Plastic before I try it on my real project.",
-      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "How do I use Plastic day to day?",
-      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "I have never touched this tool before. What can it actually do for me before I commit real work to it?",
-      "expected_output": "Activates plastic-tutorial; an indirect trigger that names neither the skill nor the word tutorial.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 6,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Create an intent for adding a search feature.",
-      "expected_output": "Does NOT activate plastic-tutorial; activates plastic-intent-creating (a near-miss that shares the word intent but starts real work, not a walkthrough).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 7,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Just run the whole thing for me, I do not want to steer any of it.",
-      "expected_output": "Does NOT activate plastic-tutorial; activates plastic-auto (a near-miss that describes autonomous delivery of real work, not a walkthrough of how auto works).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-tutorial",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 8,
-      "scope": "track-routing",
-      "set": "train",
-      "prompt": "Inside the tutorial menu: show me auto mode.",
-      "expected_output": "Routes to track 2 (references/track-2-auto.md), the auto handover track.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "TRACK == track-2-auto",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 9,
-      "scope": "track-routing",
-      "set": "train",
-      "prompt": "Inside the tutorial menu: I want a roadmap.",
-      "expected_output": "Routes to track 3 (references/track-3-projects-and-roadmaps.md), the projects and roadmaps track.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "TRACK == track-3-projects-and-roadmaps",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 10,
-      "scope": "track-routing",
-      "set": "validation",
-      "prompt": "Inside the tutorial menu: start a project.",
-      "expected_output": "Routes to track 3 (references/track-3-projects-and-roadmaps.md), the projects and roadmaps track.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "TRACK == track-3-projects-and-roadmaps",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 11,
-      "scope": "track-routing",
-      "set": "validation",
-      "prompt": "Walk me through my first intent, one stage at a time.",
-      "expected_output": "Routes to track 1 (references/track-1-guided.md), the guided delivery track.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "TRACK == track-1-guided",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 12,
-      "scope": "track-routing",
-      "set": "train",
-      "prompt": "Tutorial. (No further detail given.)",
-      "expected_output": "Activates plastic-tutorial and presents the three-track menu itself, since no track was named; this is the one case where the menu is the expected output rather than a routed track.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "the reply shows the three-track menu (guided, auto, projects and roadmaps) and does not jump into any one track uninvited",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}

package/skills/uninstall/SKILL.md

@@ -1,75 +0,0 @@
----
-name: plastic-uninstall
-description: Use when the user wants to remove Plastic from an agent. Runs the manifest-driven uninstaller (removes skills, hooks, statusline, and any legacy plugin layout), reports exactly what was removed and what was left behind, then gives verification steps. The intent store always stays.
-user-invocable: true
----
-
-# Uninstall Plastic
-
-The installer tracks every file it writes in a manifest, so uninstall is exact and
-leaves no orphans. Prefer running it through the CLI; this skill wraps the same
-underlying uninstaller and adds reporting + verification.
-
-## Channel rule
-
-If Plastic is installed, derive `<channel>` from `~/.plastic/VERSION`: a version containing
-`-alpha` means `@alpha`, `-beta` means `@beta`, otherwise `@latest`. If not installed,
-default to `@latest`. The user can always override with `--alpha` / `--beta` / `--latest`.
-
-## Procedure
-
-### Step 1: Run the uninstaller
-
-```bash
-npx -y @zalom/plastic@<channel> uninstall --claude
-```
-
-(Use `--codex` / `--hermes` / `--all` to target other agents. `bunx -y @zalom/plastic@<channel> uninstall --claude` works too.)
-
-This removes, for the targeted agent:
-- all `~/.claude/skills/plastic-*/` skills
-- all `~/.claude/hooks/plastic-*` hooks (and restores any saved original statusline)
-- the `~/.claude/plastic/` state dir + manifest
-- any **legacy** plugin layout: `plugins/marketplaces/plastic`, `plugins/cache/plastic`,
-  the old nested `skills/plastic/`, and the `plastic@plastic` /
-  `extraKnownMarketplaces.plastic` / `known_marketplaces.json` registrations
-
-### Step 2: Report removed vs left
-
-Relay the uninstaller's output to the user: what was **removed** and what was
-**left in place**.
-- **Left:** `~/.plastic/` (intent store, history, projects) and any non-Plastic
-  settings.json entries.
-
-### Step 3: Verify removal
-
-Tell the user to confirm:
-
-```bash
-ls ~/.claude/skills | grep '^plastic-'    # -> no output
-ls ~/.claude/hooks  | grep '^plastic-'    # -> no output
-grep -n plastic ~/.claude/settings.json   # -> no plastic hook/plugin refs
-```
-
-### Step 4: Report
-
-Emit the reporting block, using the Step 3 checks for the verification line:
-
-```
-Plastic uninstall (<channel>)
-Command:  npx -y @zalom/plastic@<channel> uninstall --claude <flags>
-Version:  removed
-Verification: <Step 3 results, or "clean">
-```
-
-Then:
-
-```
-Plastic is uninstalled from [agent].
-Your intent store at ~/.plastic/ is untouched.
-```
-
-Uninstall removes installed harness files only. The store at `~/.plastic/` (intents,
-history, projects, config, version ledger) always stays; no uninstall path deletes it.
-Tell the user: "Your data is at ~/.plastic/. Re-install anytime with
-`npx -y @zalom/plastic@latest install --claude` (or your channel)."