@zalom/plastic 2.0.0-alpha.21 → 2.0.0-alpha.22

package/skills/releasing/SKILL.md

@@ -312,7 +312,7 @@ A release IS a delivery. The active intent that drove this work must be complete
 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:
+   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 terminal savepoint line, 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" \

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

@@ -81,7 +81,7 @@ 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 Done bookend still writes a live `savepoint.md`; every other
+  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.

package/skills/tutorial/SKILL.md

@@ -21,7 +21,8 @@ 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
+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

package/skills/tutorial/references/track-1-guided.md

@@ -58,66 +58,47 @@ next, it does not write `spec.md` itself.
 Checkpoint: after two or three answers, look at the intent file. Every ruling given out loud
 is already sitting in `### Decisions` and in `## Insights`, in writing.
 
-### 4. Consolidate the spec
+### 4. How, write the graph
 
-Type `/plastic-intent-speccing`.
+Ask the same conversation (`/plastic-intent-speccing`) to turn the rulings into the graph.
 
-Artifact: `spec.md`, its eight sections filled from the rulings recorded in station 3.
+Artifact: `graph.md` (nodes, edges, dispatch policy) and one `nodes/N.md` file per node this
+small delivery needs. A delivery this size is one node; many independent tasks instead get
+one node each, dispatched in parallel by the runner.
 
-Checkpoint: point at one sentence in `spec.md` that traces back to an answer given in
-station 3.
+Checkpoint: open `graph.md` and point at the one node this worked example needs.
 
-### 5. Plan
-
-Ask the same conversation to write the action files and the plan.
-
-Artifact: `plan.md`, `checklist.md`, and at least one real `actions/ACTION_N.md`. A small
-delivery like this one consolidates the whole delivery into a single `actions/ACTION_1.md`
-(the ordered steps plus the exact changes); many independent tasks, dispatched in parallel,
-instead get one `actions/ACTION_N.md` file per task. `checklist.md` follows a fixed form: tasks start under `## In Progress`, move to
-`## Completed` as they land, and a `## Session Log` table records what happened each session.
-A task that depends on an owner decision landing first (a destructive step, a structural
-ruling) gets an `[ORCHESTRATOR]` prefix and blocks every other item until that decision is
-made; this worked example has none.
-
-Checkpoint: open `checklist.md`. Every task in `plan.md` has a matching checkbox under
-`## In Progress`; that checklist, not `plan.md` itself, is what gets ticked off and moved to
-`## Completed` during Exec.
-
-### 6. Exec, verify before you report
+### 5. Exec, drive the runner loop
 
 Type `/plastic-intent-executing`.
 
-Teach the order: first the agent syncs its working copy with the main line, so no edit lands
-on a path a merged change upstream has already touched or removed. Then it makes the change,
-runs whatever verifies it (a test suite, or a manual check for a docs change like this one),
-and only then ticks the checklist box, moving the task from `## In Progress` to
-`## Completed` and adding a `## Session Log` row, before moving to the next task. Verifying
-always comes before checking a box, never after, and each task is ticked the moment it lands,
-never batched for later.
+Teach the loop: `ruby scripts/runner step <intent_dir>` computes which nodes are ready and
+prints a spawn block to dispatch, `ruby scripts/runner status <intent_dir>` reads the
+ledger (running, done, blocked, or waiting on a decision), and `ruby scripts/runner answer`
+closes a node that needs an owner's ruling. Call `step` again after each dispatched node
+returns, until the graph is empty.
 
 Artifact: the actual change on disk (the new README Usage section, or, in the global-store
-fallback, a short written note saved as the intent's deliverable) and a fully ticked
-`checklist.md`.
+fallback, a short written note saved as the intent's deliverable) and every node in
+`graph.md` at a terminal status.
 
-Checkpoint: find the new Usage section in the README (or the written note) and confirm every
-box in `checklist.md` is checked and moved to `## Completed`, with a `## Session Log` row for
-this session, before moving to station 7.
+Checkpoint: run `runner status` and confirm no node is left running or blocked, before
+moving to station 6.
 
-### 7. Done
+### 6. End
 
 Type `/plastic-intent-ending`.
 
-Artifact: a real `outcome.md` (Summary, Delivered, Verification, Follow-ups), the intent
-moved from `## Active` to `## Completed` in `INDEX.md`, and a closing `Done` line in
-`savepoint.md`.
+Artifact: a real `outcome.md` (Summary, Delivered, Verification, Follow-ups) generated by
+`scripts/outcome-report` from `graph.md` and the ledger, the intent moved from `## Active`
+to `## Completed` in `INDEX.md`, and the terminal savepoint line.
 
 Checkpoint: open `outcome.md` and read its Summary. It should describe, in a sentence or
 two, exactly the README section (or note) just delivered.
 
 ## Wrap and where to go next
 
-That is the full cycle once: create, board, decide, spec, plan, build, done. Read
+That is the full cycle once: create, graph, runner step, end. Read
 [`your-first-intent-in-10-minutes.md`](https://github.com/zalom/plastic/blob/main/docs/guides/your-first-intent-in-10-minutes.md) for the same path condensed to a single
 read, and [`reading-the-ledgers.md`](https://github.com/zalom/plastic/blob/main/docs/guides/reading-the-ledgers.md) for where each station wrote its
 work down.

package/skills/tutorial/references/track-2-auto.md

@@ -33,7 +33,7 @@ queued intent from the dashboard's queue itself.)
 
 No new command at this station. Watch how the work splits.
 
-Auto owns How (the plan, the checklist, the action files) and Exec (the code, the tests, the
+Auto owns How (`graph.md`, `nodes/`) and Exec (the code, the tests, the
 mechanical close) from here on. Inside Exec it follows a few fixed habits: it syncs its
 working copy with the main line before touching anything, ticks each task the moment it
 lands rather than batching several into one later edit, and independently verifies its own
@@ -63,7 +63,7 @@ Checkpoint: open the intent's `savepoint.md` and name the stage its last line re
 
 ### 4. Reading the per-stage reports
 
-No new command. At each stage boundary (What, Why, How, Exec, Done) the agent briefs in a
+No new command. At each stage boundary (What, Why, How, Exec) the agent briefs in a
 fixed three-line shape: State (what happened and why it matters), Risk (the one thing that
 could bite, or "nothing flagged"), and Call (the decision left to the user, or the call the
 agent is taking on its own). That is the depth for a medium or large intent. A small intent

package/templates/agents.md

@@ -58,10 +58,10 @@ Plastic has its own lifecycle skills. When a Plastic skill exists for the curren
 | Why | `plastic-intent-speccing` | Rulings as insights, `resources/*.md`, `spec.md` |
 | How | `plastic-intent-speccing` | `actions/`, `plan.md`, `checklist.md` |
 | Exec | `plastic-intent-executing` | Code + `outcome.md` |
-| Done | `plastic-intent-ending` | Lifecycle transition |
+| End | `plastic-intent-ending` | Lifecycle transition |
 
 **Artifact convention:** ALL lifecycle artifacts go to the active intent directory (`store/{id}--{slug}/`). Never write specs to `docs/superpowers/specs/` or plans to `docs/superpowers/plans/`.
 
-## When You're Done
+## When the Project Wraps
 
 When this project satisfies the governing intent's goal, report back. The orchestrator will complete the strategic intent.