@zalom/plastic 2.0.0-alpha.9 → 2.0.1

package/skills/releasing/SKILL.md

@@ -1,337 +0,0 @@
----
-name: plastic-releasing
-description: Use when merging a feature branch to main and tagging a release, bumping the version, or when the user says "release", "tag", or "ship it"
-user-invocable: true
----
-
-# Releasing
-
-Merge, bump, tag, push. Annotated tags with changelogs. Semantic versioning.
-Project configuration drives the workflow - no hardcoded assumptions.
-
-## Checklist
-
-- [ ] Read project config
-- [ ] 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
-- [ ] Run post-push actions (GitHub release, npm publish, etc.)
-- [ ] Verify release sync (npm dist-tag, GitHub "Latest", git tag all show the new version)
-- [ ] Clean up the intent's worktrees (merge-then-remove)
-- [ ] Complete active intent
-
-## Workflow
-
-### 0. Read Project Config
-
-Before anything else, determine which project we are releasing and load its config.
-
-1. Read `~/.plastic/projects.yml` - find the project whose `path` matches the current working directory.
-2. Extract the project slug (the key under `projects:`).
-3. Read `~/.plastic/projects/{slug}/project.yml` - this contains the `release:` section.
-
-Expected `release:` keys in project.yml:
-
-```yaml
-release:
-  verify: "bin/rails test"              # command to run before release
-  version_file: package.json            # single file containing the version
-  version_files:                        # multiple files (overrides version_file)
-    - package.json                      # list EVERY file carrying the version;
-    - .claude-plugin/plugin.json        # they must all be bumped together or they drift
-    - .claude-plugin/marketplace.json
-  tag_format: "v{{version}}"            # tag naming pattern ({{version}} is replaced)
-  on_green:                             # actions to run after push succeeds
-    - github_release
-    - npm_publish
-  on_complete: commit_and_push          # what to do with the version bump commit
-  on_red: stop                          # what to do if verification fails
-```
-
-**Fallback:** If no project.yml exists or it has no `release:` section, fall back to asking the user for each step - verify command, version files, tag format, and post-push actions.
-
-### 1. Verify Tests Pass
-
-Run the verification command from `release.verify` in project.yml:
-
-```bash
-# Example: release.verify = "ruby -Itest test/*_test.rb"
-<verify-command-from-config>
-```
-
-- If `release.verify` is present: run it. All checks must pass before proceeding.
-- If `release.verify` is absent or empty: skip verification. Log that no verify command is configured.
-- If `release.on_red` is `stop`: abort the release on failure.
-- If `release.on_red` is `fix_and_retry`: ask the user to fix and re-run.
-
-### 2. Determine Version Bump
-
-| Change type | Bump | Example |
-|-------------|------|---------|
-| Breaking changes | Major | 0.x.0 → 1.0.0 |
-| New features | Minor | 0.3.0 → 0.4.0 |
-| Bug fixes only | Patch | 0.4.0 → 0.4.1 |
-
-Pre-1.0: minor bumps for features, patch for fixes. No major until stable.
-
-### 3. Merge Feature Branch
-
-```bash
-git checkout main
-git merge <branch-name> --no-ff -m "feat: merge intent [ID] - [description]"
-```
-
-Always `--no-ff` to preserve branch history in the merge commit.
-
-**Worktree-isolated intents (intent 73c3).** A worktree-delivered intent's code lives on
-`plastic/{id}--{slug}`, merged together with cleanup in step 9, not on a hand-made feature
-branch. Do not delete the worktree before its branch is merged, or the work is lost. For
-the full rationale and the already-merged-by-hand no-op case, read
-`references/promotion-and-tagging.md`.
-
-### 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).
-- Else if `release.version_file` is set: update that single file.
-- Else: ask the user which files contain the version.
-
-Update the version string in each file, then commit:
-
-**Cut the CHANGELOG entry.** Before committing, edit `CHANGELOG.md` at the repo root so
-the changelog change rides this same version-bump commit and reaches the tag. Write one
-line in the existing shape:
-
-`` `<version>` - shipped <date>; collected <intent-id> (<one-line summary>) ``
-
-Prepend it as the first bullet under `## Released` (newest-first). If this version was
-sitting under `## Unreleased`, move it out of that section and into `## Released`. Keep
-the line intent-centric narrative (which intents the cut collected and why), NOT commit
-detail: step 5's tag-message changelog and step 7's `gh release create --generate-notes`
-already own the commit-level detail, so do not duplicate it here.
-
-```bash
-git add <version-files> CHANGELOG.md
-git commit -m "chore: bump version to X.Y.Z - [one-line summary]"
-```
-
-### 5. Create Annotated Tag
-
-Read `release.tag_format` from project.yml to determine the tag name:
-
-- If set (e.g. `"v{{version}}"`): replace `{{version}}` with the new version string.
-- If not set: default to `vX.Y.Z`.
-
-Generate the changelog from commits since the last tag:
-
-```bash
-git log $(git describe --tags --abbrev=0)..HEAD --oneline --no-merges | grep -E "^[a-f0-9]+ (feat|fix|refactor):"
-```
-
-Create the tag with a multi-line message:
-
-```bash
-git tag -a <tag-name> -m "<tag-name> - [release name]
-
-- [changelog bullet points from feat/fix/refactor commits]"
-```
-
-### 6. Push
-
-```bash
-git push origin main --tags
-```
-
-### 7. Post-Push Actions
-
-Read `release.on_green` from project.yml. This is a list of actions to run after a successful push. Execute each in order:
-
-#### `github_release`
-
-Create a GitHub release from the tag:
-
-```bash
-gh release create <tag-name> --title "<tag-name> - [release name]" --latest --generate-notes --notes-start-tag <previous-tag>
-```
-
-`--latest` is REQUIRED. Pre-release (alpha/beta) tags are NOT auto-promoted to the "Latest"
-badge by GitHub, so without it the Releases page keeps showing an older version as Latest while
-the newest tag sits below it (a real sync drift we hit on the alpha line). Pass `--latest` on
-every release so the newest one always carries the badge. Do NOT pass `--prerelease` unless you
-specifically want the release hidden from Latest.
-
-For the first release (no previous tag), write notes manually with `--notes "..."` instead.
-
-#### `npm_publish`
-
-Publish the package to npm with the appropriate dist-tag:
-
-```bash
-# Alpha pre-release (version contains -alpha):
-npm publish --access public --tag alpha
-
-# Beta pre-release (version contains -beta):
-npm publish --access public --tag beta
-
-# Stable release (no pre-release suffix, >= 1.0.0):
-npm publish --access public
-```
-
-The dist-tag is derived from the version string in `package.json`:
-- Contains `-alpha` → `--tag alpha`
-- Contains `-beta` → `--tag beta`
-- No pre-release suffix → no `--tag` flag (publishes to `latest`)
-
-#### Other values
-
-If `on_green` contains an action not listed above, log it:
-
-```
-[releasing] Action "<action>" is configured but not yet implemented. Skipping.
-```
-
-If `on_green` is empty or absent: skip post-push actions entirely.
-
-#### Verify sync (always, after the post-push actions)
-
-A release is not done until all three surfaces show the SAME newest version. Confirm:
-
-```bash
-npm view <package> dist-tags                      # channel tag (alpha/beta/latest) -> new version
-gh release list --limit 1                         # newest release is the new tag AND marked "Latest"
-git ls-remote --tags origin | grep <tag-name>     # the tag reached the remote
-```
-
-If the GitHub "Latest" badge is on an older tag (the common drift), fix it without re-releasing:
-
-```bash
-gh release edit <tag-name> --latest
-```
-
-### 8. Clean Up the Intent's Worktrees (merge-then-remove)
-
-This step now runs BEFORE step 9's `end-intent` call (intent 188, D7): `scripts/end-intent`
-gained its own step 5 that disarms (releases the worktree, clears `delivery.lock`) as part
-of every close. Its plain-remove shape does not merge, so if `end-intent` ran first on a
-release, its step 5 would remove the worktree WITHOUT merging the code branch first,
-stranding the integrated work (`Worktree.finish` returns early once the worktree block it
-needs is gone, per `worktree.rb`'s own "no-op if nothing was provisioned" contract).
-Running this merge-then-remove step first means the worktree is already gone by the time
-step 9 runs, so `end-intent`'s own disarm becomes a harmless no-op for the worktree
-(nothing left to remove), while for the FIRST time on this path it also clears the delivery
-lock correctly (G5): before intent 188 this path left the lock stranded, exactly the class
-of bug closed by the End-tail enforcement work.
-
-This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: true`), not a
-separate concern: a release is the merge-then-remove path for the intent's worktree (intent
-73c3), so the intent's code branch is merged back into the default branch BEFORE the worktree
-is removed. Drive it through `Worktree.finish` with `merge: true`, which merges the code
-branch, then removes the worktree, and prunes the repo:
-
-```bash
-ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/arm -e \
-  'Worktree.finish(Arm.bridge_hash(intent_dir: "<STORE>/<dir>"), merge: true)'
-```
-
-(The worktree block is derived from `projects.yml` and the intent id, so the one-liner needs
-only the intent directory; the `/tmp` bridge it once discovered was removed in 2.0, intent 307.)
-
-Honor the worktree-cleanup rule: never leave an orphaned worktree, and run `git worktree
-prune` in the affected repo if you hit a stale reference. For why this is the one place the
-merge-vs-remove policy lands on merge, and the fail-open/idempotent guarantees of `finish`,
-read `references/promotion-and-tagging.md`.
-
-### 9. Complete Active Intent
-
-A release IS a delivery. The active intent that drove this work must be completed as part of the release process. This is NOT optional. The mechanical close (outcome/INDEX/savepoint/commit, AND disarm since intent 188) is `plastic-intent-ending`'s job, not this skill's: run its backing script rather than restating that prose here.
-
-1. Read `~/.plastic/INDEX.md` (or the project's INDEX.md) - find active intent(s) related to this release.
-2. For each active intent being delivered:
-   a. Write a real `outcome.md` (never leave the scaffold placeholder), `disposition: delivered`, referencing the release tag.
-   b. Update `## Insights` with final observations.
-   c. Run the mechanical close (`scripts/end-intent`'s steps 1-5): this stamps the intent file's `## Outcome` summary, moves the INDEX.md line to `## Completed` (dated today, with a rich entry description via `--index-note`), appends the savepoint `Done` bookend, commits the store, and disarms (releases the worktree - already gone from step 8 above - and clears `delivery.lock`), all in one call:
-      ```bash
-      ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
-        --session "$CLAUDE_CODE_SESSION_ID" \
-        --outcome-summary "delivered in <tag-name>: <one-line summary>" \
-        --index-note "<tag-name>, <mode>; <what shipped>; <suite result>"
-      ```
-      A non-zero exit needs attention: 4 means a live foreign session holds the lock (back
-      off), 5 means the code worktree is still dirty (should not happen here, since step 8
-      already removed it; investigate before overriding with `--discard-worktree-changes`),
-      3 means disarm ran but the lock is still present (run `/plastic-doctor check the lock
-      status`).
-   d. Update clusters to show `_(completed)_`.
-
-**If no active intent exists for this release**, that itself is a problem - work happened outside the intent system. Log it and move on, but flag it.
-
-## Release lines and channels
-
-Two lanes get code to a release, on top of the workflow above.
-
-- **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
-- **Tag format** - driven by `release.tag_format` in project.yml (default: `vX.Y.Z`)
-- **Tag message** - first line: `<tag> - [short name]`, then blank line, then bullet changelog
-- **Commit prefixes** - `feat:`, `fix:`, `refactor:`, `chore:`, `docs:` (conventional commits)
-- **Hyphens, never em-dashes** - in tag names, release titles, and commit messages, use a hyphen (`-`). Never an em-dash.
-- **Latest badge** - always `gh release create --latest`; the newest release must carry GitHub's "Latest" badge.
-- **Version files** - driven by project.yml; list and bump EVERY file carrying the version (they drift otherwise)
-- **Verify sync** - after pushing, confirm npm dist-tag, GitHub "Latest", and the git tag all show the new version
-- **Branch cleanup** - delete merged feature branches: `git branch -d <branch>`
-
-## 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 (alpha to beta, beta to stable) or
-  tagging a historical release retroactively, read `references/promotion-and-tagging.md`
-  for the exact commands and rules first
-- Read `references/deprecations.md` for the full deprecation process, severity levels, deprecations.yml schema, and dismissal rules when adding or managing deprecations

package/skills/releasing/references/deprecations.md

@@ -1,60 +0,0 @@
-# Deprecation Process
-
-When removing a feature, changing a convention, or making a breaking change:
-
-1. Add entry to `deprecations.yml` in the Plastic source root
-2. Set severity: `info` (awareness), `warning` (action needed), `critical` (urgent)
-3. Provide clear migration steps
-4. Set `removal` version at least 2 minor versions ahead
-5. SessionStart hook displays active deprecations automatically
-6. Remove the feature AND the deprecation entry together
-
-## Pre-1.0 removal policy
-
-The numbered process above is the steady-state rule: a deprecation rides until its `removal`
-version, which step 4 sets at least two minors ahead. While Plastic is still pre-1.0 (any
-version below `1.0.0`), one exception applies:
-
-- **Pre-1.0 exception.** Before `1.0.0`, a *satisfied* deprecation (the migration it
-  announced is complete on installed machines) may be removed immediately, rather than waiting
-  for its declared `removal` major. Delete the entry from `deprecations.yml` (leaving
-  `deprecations: []` if it was the last one) the moment the migration is done.
-
-This exception only holds below `1.0.0`. From `1.0.0` onward, the steady-state grace rule
-(step 4, removal at least two minors ahead) governs again, unchanged. The exception narrows
-*when* a satisfied entry may be pulled early during the pre-release line; it does not loosen
-the grace window for the released-product contract.
-
-## Severity Levels
-
-| Severity | When to use | Dismissable? |
-|----------|-------------|--------------|
-| `info` | Upcoming change | Yes |
-| `warning` | Action needed | Yes (re-shown at removal) |
-| `critical` | Urgent/security | Never |
-
-## deprecations.yml Schema
-
-```yaml
-deprecations:
-  - id: unique-slug
-    severity: info | warning | critical
-    summary: "One-line description"
-    migration_steps:
-      - "Step 1"
-      - "Step 2"
-    introduced: "0.9.0"
-    removal: "1.0.0"
-    link: "optional URL"
-```
-
-## Dismissal
-
-Users dismiss by adding the id to `deprecations_dismissed` in `config.yml`:
-
-```yaml
-deprecations_dismissed:
-  - some-deprecated-feature
-```
-
-Critical deprecations and final-version warnings ignore dismissal.

package/skills/releasing/references/promotion-and-tagging.md

@@ -1,66 +0,0 @@
-# Promotion, Retroactive Tagging, and Worktree Merge Rationale
-
-Occasional variant paths off the main release workflow: promoting a pre-release
-across channels, tagging historical releases retroactively, and the deep rationale
-for why the intent's worktree is merged before removal.
-
-## Table of Contents
-
-- [Worktree merge-then-remove rationale](#worktree-merge-then-remove-rationale)
-- [Promotion](#promotion)
-- [Retroactive Tagging](#retroactive-tagging)
-
-## Worktree merge-then-remove rationale
-
-**Worktree-isolated intents (intent 73c3).** When the intent was delivered in a Plastic
-worktree (the bridge has a provisioned `worktree` block), its code lives on the branch
-`plastic/{id}--{slug}` inside `<repo>/.claude/worktrees/{id}--{slug}`, not on a hand-made
-feature branch. The merge-then-remove of that worktree is handled together with cleanup in
-Workflow step 9, which merges `plastic/{id}--{slug}` into the default branch BEFORE removing the
-worktree. If you already merged here by hand, step 9 is a clean no-op merge ("Already up to
-date") and proceeds straight to removal. Do not delete the worktree before its branch is
-merged, or the work is lost.
-
-A release is the merge-then-remove path for the intent's worktrees. This is the one place
-the merge-vs-remove policy lands on "merge": the intent's code branch (`plastic/{id}--{slug}`)
-is merged back into the repo's default branch BEFORE the worktree is removed, so the
-integrated work is never lost. (The disarm path in `plastic-auto`, by contrast, is a plain
-remove because no release is merging the branch.)
-
-`Worktree.finish` is fail-open and idempotent: a conflicting merge is aborted and logged (the
-worktree is still removed rather than stranded), and a second call with the block already
-cleared is a no-op.
-
-## Promotion
-
-Promotion is not a CLI flag; there is no `--promote` command. It is a set of steps the
-agent performs during the releasing workflow, reusing the normal release mechanics
-(version bump, tag, `npm publish` with the channel's dist-tag, GitHub release):
-
-```bash
-# Promote alpha → beta: set version files from -alpha.N to -beta.1, commit, tag, then
-npm publish --access public --tag beta
-
-# Promote beta → stable: strip the pre-release suffix (e.g., 1.0.0-beta.3 → 1.0.0),
-# commit, tag, then
-npm publish --access public          # no --tag flag publishes to latest
-```
-
-**Promotion rules:**
-- Linear only: alpha → beta → stable. Cannot skip channels.
-- Version files are bumped and committed as in a normal release.
-- An annotated tag is created for the promoted version, and the GitHub release is cut
-  as in the normal workflow (`gh release create ... --latest` for stable).
-- To point a channel at an already-published version without republishing, move the
-  dist-tag directly: `npm dist-tag add @zalom/plastic@<version> <channel>`. To move the
-  GitHub "Latest" badge: `gh release edit <tag> --latest`.
-
-## Retroactive Tagging
-
-For repos without prior tags, tag historical releases:
-
-```bash
-git tag -a v0.1.0 <commit-sha> -m "v0.1.0 - [description]"
-```
-
-Use `git log --oneline` to find the right commits (look for version bump commits or major feature merges).

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 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

@@ -1,64 +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.
-
-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.
-
-## 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.