@zalom/plastic 2.0.2 → 2.0.3

package/docs/help/track-1-guided.md

@@ -12,11 +12,15 @@ end to end: a piece of work moved through What, Why, How, and Exec, with a finis
 Run `plastic update` first, so the commands below match what is
 actually installed.
 
-Work in a sandbox: this track always creates a global-store intent; the throwaway repo below
-is never registered as a Plastic project. Pick a throwaway git repository if you have one
-handy, since the worked example edits its README: station 6's deliverable is that file edit.
-No repo handy? Station 6's deliverable becomes a short written note saved in the intent's own
-directory instead (see station 6). Either way, nothing in this track touches a real project.
+This track walks a graph intent: the plan is a `graph.md` of nodes that the runner dispatches.
+For the simpler checklist path, a small Ruby example taken from a new intent to merged code and
+a delivered close, run `plastic help tutorial` instead.
+
+Work in a sandbox. Run `plastic intent new` outside any registered project and the intent lands
+in the global store; run it inside a registered throwaway repository and it lands in that
+project's store, and the close can check the merge. The worked example edits the repository's
+README. With no repository, the deliverable is a short written note saved in the intent's own
+directory (see station 5). Either way, nothing in this track touches a real project.
 
 ## Stations
 
@@ -33,16 +37,15 @@ Checkpoint: open the new file. It already has a real id and a one-line descripti
 was hand-typed into it directly. That is the point: intents are always scaffolded by the
 tool, never written by hand.
 
-### 2. Board the intent
+### 2. Read where it stands
 
-Run `plastic continue` and name the intent.
+Run `plastic intent show ID`.
 
-Artifact: a delivery lock (a `delivery.lock` file in the intent directory) naming this
-session as the one owner, and a line in `savepoint.md` recording the stage. The agent then
-resumes at the last delivered station and asks nothing.
+Artifact: none. The command only reads. It prints the intent's state screen, and its `next:`
+line names the step to run: `plastic intent spec ID` while the intent has no spec or graph.
+`plastic continue` reads the same way for the whole project. Neither takes a lock.
 
-Checkpoint: explain in one sentence why the lock matters: it stops two
-sessions from editing the same intent at the same time.
+Checkpoint: name the step the `next:` line points at, and why.
 
 ### 3. Why, rulings one at a time
 
@@ -50,17 +53,20 @@ Run `plastic intent spec` (say "grill me" for a harder, interview-style pass ove
 the same ground). It asks conversational prose questions, one at a
 time, never a multiple-choice menu, and answers them one at a time in return.
 
-Artifact: `## Context` and `### Decisions` in the intent file fill in as each answer lands, and
-each ruling also lands as its own `## Insights` entry the moment it is made, never batched for
-later. This station's product is the enriched Why; it hands off to `plastic intent spec`
-next, it does not write `spec.md` itself.
+Artifact: each ruling lands as its own `## Insights` entry the moment it is made, never batched
+for later, through `plastic intent rule ID "TEXT"`, stamped with the time, the `Why` stage and
+the `human` author. `intent rule` writes nothing else: the agent edits `## Context` and any
+`### Decisions` list by hand. This station's product is the enriched Why; neither command
+writes `spec.md`.
 
 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.
+is already sitting in `## Insights`, in writing.
 
 ### 4. How, write the graph
 
-Ask the same conversation (`plastic intent spec`) to turn the rulings into the graph.
+In the same conversation, the agent turns the rulings into the graph. It writes `graph.md` from
+`templates/graph.md`. No command creates it; once it exists, the runner behind
+`plastic intent step` and `plastic intent answer` updates it.
 
 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
@@ -70,35 +76,47 @@ Checkpoint: open `graph.md` and point at the one node this worked example needs.
 
 ### 5. Exec, drive the runner loop
 
-Run `plastic intent step`.
+Run `plastic intent step ID`.
+
+Graph execution needs the delivery lock. Without it, `intent step` names
+`plastic auto take ID` as the next step. From a conversation session, `auto take` refuses with
+exit 3 unless the owner approves `--allow-inline`; stop and report the refusal.
 
-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.
+Teach the loop: `plastic intent step ID` runs the internal `runner step`, which computes which
+nodes are ready and prints a spawn block to dispatch. Pass a returned node back with
+`plastic intent step ID --return NODE=PATH`. `plastic intent answer ID --node NODE --decision
+"TEXT"` closes a node that waits on an owner's ruling. The internal
+`ruby ~/.plastic/scripts/runner status <intent_dir>` reads the ledger (running, done, blocked,
+or waiting on a decision); no public command wraps it. 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 every node in
 `graph.md` at a terminal status.
 
 Checkpoint: run `runner status` and confirm no node is left running or blocked, before
-moving to station 6.
+moving to station 6. When the graph is complete, `intent step` names `plastic intent verify ID`.
 
 ### 6. End
 
-Run `plastic intent end`.
+Run `plastic intent end ID --delivered --summary "TEXT"`. Add `--dry-run` first to see what
+the close would do without writing anything.
+
+When the intent has a code branch or worktree, merge the branch yourself first. Plastic does
+not merge, and a delivered close refuses unmerged code with exit 1.
 
-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.
+Artifact: a real `outcome.md` (Summary, Delivered, Verification, Follow-ups) generated from
+`graph.md` and the ledger (the same model as the internal `scripts/outcome-report`), the
+intent moved from `## Active` to `## Completed` in `INDEX.md`, the terminal savepoint line,
+and the lock and worktree released.
 
 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, graph, runner step, end. Read
+That is the full cycle once: create, graph, runner step, end. Run `plastic help tutorial` for
+the checklist path with a merged code change. 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/docs/help/track-2-auto.md

@@ -3,7 +3,7 @@
 ## Who it is for and what you will have done
 
 For someone who has seen the stages once (track 1) and now wants to hand the work to the
-agent, watch it move through the gates and reports on its own, and learn how to check in on
+agent, watch it move through the stages and reports on its own, and learn how to check in on
 it and step back in later. After this track, one small intent will have been delivered by the
 agent end to end, and pausing and resuming that delivery will feel familiar.
 
@@ -22,12 +22,26 @@ track touches a real project.
 Start from an active intent (create one first with `plastic intent new` if none
 exists, the same way as track 1 station 1). Run `plastic auto take ID`.
 
-Artifact: the delivery lock arms, and the agent announces it is taking over the intent for
-autonomous delivery.
+Artifact: the delivery lock arms (`delivery.lock` in the intent directory) and the code
+worktree is made at `<repo>/.claude/worktrees/ID--slug` on branch `plastic/ID--slug`. The
+command prints both:
 
-Checkpoint: name the one precondition auto needs before it will start: an active intent must
-already exist for the intent you name. (Say "auto" with nothing named, and it can pick a
-queued intent from the dashboard's queue itself.)
+```text
+intent    2--shout
+lock      acquired by auto-9184f6c4fa, auto mode
+worktree  /home/you/greeter/.claude/worktrees/2--shout
+```
+
+Run from inside a conversation session, `plastic auto take` refuses with exit 3: an intent is
+not delivered inline. The owner may approve an inline take with `--allow-inline`. Otherwise
+the harness spawns the team, and the team takes the intent. Exit 3 means stop and report; never
+retry with another flag on your own.
+
+`plastic auto brief ID` prints the preamble the spawned lead starts from, and
+`plastic auto lock status ID` shows who holds the lock.
+
+Checkpoint: name the one precondition auto needs before it will start: the intent you name
+must already exist in the store the command resolves to.
 
 ### 2. What auto does, and what stays with the user
 
@@ -39,7 +53,7 @@ working copy with the main line before touching anything, ticks each task the mo
 lands rather than batching several into one later edit, and independently verifies its own
 work (running the test suite, or checking the changed file) before presenting anything back
 to you. For a task shaped like an audit or a sweep, checking many files rather than building
-one artifact, it also drops a short methods report into `resources/` before the gate, so you
+one artifact, it also drops a short methods report into `resources/` before the close, so you
 can review how it checked, not just what it found.
 
 The user keeps two things: the rulings made along the way, and the review points, moments
@@ -76,13 +90,24 @@ line.
 
 Run `plastic continue`.
 
-Artifact: the current state, presented and then the session stops. If a specific intent is
-named, the agent reads its stage and savepoint and resumes exactly there, rather than
-starting over.
+Artifact: where the project stands and a `next:` line naming what runs next. `plastic
+continue` only reads: it takes no lock and changes no file. To resume one intent, run
+`plastic intent show ID`; its Next row names the step it resumes at, read from the files on
+disk.
 
 Checkpoint: after stepping away and running this command, name the stage the intent resumed
 at and how that matched what was actually on disk.
 
+### 6. The close
+
+The lead closes the intent with `plastic intent end ID --delivered --summary "TEXT"`. The
+close checks that the code branch is merged and refuses with exit 1 when it is not; Plastic
+does not merge. It also refuses to deliver an untouched scaffold. On success it writes
+`outcome.md` from the record, moves the intent to `## Completed`, and releases the lock and
+the worktree.
+
+Checkpoint: open `outcome.md` and read its Summary.
+
 ## Wrap and where to go next
 
 Auto keeps the same stages and the same record as thinking; the only difference is who steers.

package/docs/help/track-3-projects-and-roadmaps.md

@@ -20,8 +20,8 @@ one this tutorial keeps or ships.
 
 ### 1. Start from a founding implementation intent
 
-Create and board an intent the same way as track 1, stations 1 and 2: `plastic intent new`,
-then `plastic continue`. Describe something meant to grow into a small real project,
+Create an intent and read where it stands, the same way as track 1, stations 1 and 2:
+`plastic intent new`, then `plastic intent show ID`. Describe something meant to grow into a small real project,
 for example "build a personal todo app."
 
 Then type `plastic intent spec` and record a couple of real rulings on this founding
@@ -66,8 +66,10 @@ and an append-only, dated `## Log`. `INDEX.md` stays the single source of truth
 intent's status; the roadmap only mirrors it. List the two or more intents from station 3
 across one or more batches.
 
-Run `plastic roadmap check <slug>` to confirm the file parses, then `plastic roadmap show
-<slug>` to see it rendered as a report.
+Run `plastic roadmap check <slug>` to confirm the file parses. A roadmap copied from the
+template may have no `## Graph` section yet; `check` then exits 1 and names
+`plastic roadmap migrate <slug>`, which writes the section from the batches. Then run
+`plastic roadmap show <slug>` to see it rendered as a report.
 
 Artifact: a new `roadmaps/<slug>.md` file, sitting next to the project's `INDEX.md`, listing
 the two or more intents from station 3 across one or more batches.
@@ -101,13 +103,14 @@ sections you turned into the condition above.
 No command run here; describe the step instead. Each delivered intent's code merges to main
 as it lands. When the batch (or a meaningful slice of it) is ready to ship, cutting a release
 is a push to `alpha`, `beta`, or `main`: the version files are bumped in that push, and CI
-tags, publishes, and completes the intents it collects.
+tags and publishes. CI never sees your stores, so it closes no intent: each intent is closed
+with `plastic intent end ID --delivered --summary "TEXT"` after its code is merged.
 
 Releases and any npm publish step are described here, not run: this walkthrough stays in a
 sandbox and never touches a real package registry.
 
-Checkpoint: explain why a release completes the intents it collects, rather than an intent
-waiting on a release to exist first.
+Checkpoint: explain why an intent closes when its code is merged, rather than waiting on a
+release to exist first.
 
 ## Wrap and where to go next
 

package/docs/help/tutorial.md

@@ -0,0 +1,421 @@
+# Tutorial: from a new intent to merged, delivered code
+
+## What you will do
+
+This tutorial takes one small change to a Ruby project from a new intent to a delivered
+close. You create the intent, record a ruling, write the spec, plan, and checklist, make the
+change on a branch with a failing test first, merge the branch, and close the intent as
+delivered. At the end, the intent sits under `## Completed` with the `outcome.md` you wrote and
+a verification that passed.
+
+The tutorial uses the checklist path, which needs no hooks, no lock, and no agent team. Every
+command here was run in a disposable `HOME` and `PLASTIC_HOME`. The output blocks come from
+that run, and some are shortened. Paths, times, commit hashes, and lock names differ on your
+machine: `/home/you` stands for your home directory.
+
+Plastic records the work. It does not write the spec, the code, or the Git history for you.
+Each step says who does it:
+
+- **Plastic**: a `plastic` command.
+- **You or your agent**: writing a file, running tests, or running Git.
+
+## Before you start
+
+- Plastic is installed. `plastic version` prints a version.
+- Ruby and Git are on your `PATH`.
+- To try the tutorial without touching your real stores, open a new shell, point `HOME` and
+  `PLASTIC_HOME` at a scratch directory, and install there first. Type `exit` at the end to
+  return to your normal `HOME`:
+
+  ```sh
+  bash
+  export HOME=/tmp/plastic-tutorial/home
+  export PLASTIC_HOME="$HOME/.plastic"
+  export PATH="$PLASTIC_HOME/bin:$PATH"
+  mkdir -p "$HOME/.claude"
+  npx -y @zalom/plastic install --claude
+  hash -r
+  command -v plastic
+  ```
+
+  The installer needs an existing `~/.claude` directory. It stops with `.claude not found`
+  otherwise. It places the `plastic` command at `$PLASTIC_HOME/bin/plastic`, and
+  `command -v plastic` must print that path. If it prints another path, the commands below
+  would run your normal installation.
+- In that shell, check that Ruby can load Minitest: `ruby -e 'require "minitest"'`. Some Ruby
+  builds do not include it, and gems installed under your normal `HOME` may not be found from
+  the scratch one. Run `gem install minitest` if the check fails.
+
+## 1. Create a small Ruby project
+
+**You.** Create a Git repository named `greeter` with one method and one test:
+
+```ruby
+# lib/greeter.rb
+# frozen_string_literal: true
+
+module Greeter
+  def self.greet(name)
+    "Hello, #{name}!"
+  end
+end
+```
+
+```ruby
+# test/greeter_test.rb
+# frozen_string_literal: true
+
+require "minitest/autorun"
+require "greeter"
+
+class GreeterTest < Minitest::Test
+  def test_greets_by_name
+    assert_equal "Hello, Ada!", Greeter.greet("Ada")
+  end
+end
+```
+
+Add an `AGENTS.md` file at the repository root. `plastic project new` refuses to register a
+repository without one. A line or two describing the project is enough.
+
+Commit everything on `main`. A scratch `HOME` has no Git identity, so set one for this
+repository first, with your own name and email:
+
+```sh
+git init -b main
+git config user.name "Your Name"
+git config user.email "you@example.com"
+git add .
+git commit -m "chore: greeter"
+```
+
+## 2. Register the project
+
+**Plastic.** From inside the repository, run:
+
+```sh
+plastic project new greeter --path "$PWD"
+plastic project links
+```
+
+`project new` creates the project store at `~/.plastic/stores/greeter/` and records the
+repository path in `~/.plastic/projects.yml`. Every later command run inside this repository
+resolves to the `greeter` store. From anywhere else, add `--project greeter`.
+
+## 3. Create the intent (What)
+
+**Plastic.** Run:
+
+```sh
+plastic intent new "Let Greeter.greet take an optional greeting word" --slug custom-greeting
+```
+
+The output names the new intent directory and the next step:
+
+```text
+/home/you/.plastic/stores/greeter/store/1--custom-greeting
+next: plastic intent spec 1 --project greeter
+because: a new intent has no specification yet
+```
+
+The directory holds the intent file `1--custom-greeting.md`, placeholder files `spec.md`,
+`plan.md`, `checklist.md`, and `outcome.md`, and empty `actions/` and `resources/` folders.
+The intent is listed under `## Active` in `~/.plastic/stores/greeter/INDEX.md`.
+
+## 4. Record the rulings (Why)
+
+**Plastic.** Run `plastic intent spec 1`. It prints the intent's state screen and the rules the
+speccing conversation follows: one question at a time, two or three approaches with a
+recommendation, and every ruling recorded the moment it lands.
+
+**You and your agent** hold that conversation. When a ruling lands, record it:
+
+```sh
+plastic intent rule 1 "Keep the default greeting Hello so existing callers are unchanged"
+```
+
+The command prints one `appended:` line. The ruling is appended to the intent file's
+`## Insights` section, stamped with the time, the `Why` stage, and the `human` author, followed
+by the ruling text.
+
+`intent rule` writes only to `## Insights`. If you keep a `### Decisions` list in the intent
+file, write it yourself.
+
+## 5. Write the spec, the plan, and the checklist (How)
+
+**You or your agent** write three files in the intent directory. No command writes them. Each
+file replaces the placeholder that `intent new` created.
+
+`spec.md` states the accepted scope:
+
+```markdown
+# Spec: Optional greeting word
+
+## Problem
+`Greeter.greet` always says "Hello". Callers cannot choose another greeting.
+
+## Goals
+- `Greeter.greet("Ada", greeting: "Hi")` returns "Hi, Ada!".
+
+## Non-Goals
+- Translation.
+
+## Approach
+Add a keyword argument with the default "Hello".
+
+## Decisions
+- The default stays "Hello", so existing callers are unchanged.
+
+## Acceptance Criteria
+- [ ] The new test passes and the old test still passes.
+```
+
+`plan.md` follows `templates/plan.md`: a `## Goal`, the `## Steps`, and `## Notes`.
+`checklist.md` follows `templates/checklist.md`, with one checkbox for each piece of work:
+
+```markdown
+# Checklist: Optional greeting word
+
+## In Progress
+- [ ] Add a failing test for the greeting keyword
+- [ ] Add the greeting keyword to Greeter.greet
+
+## Completed
+(move items here when done)
+```
+
+**Plastic.** `plastic intent show 1` now reads the checklist and points at execution:
+
+```text
+| S1 | open | Add a failing test for the greeting keyword |
+| S2 | open | Add the greeting keyword to Greeter.greet |
+next: plastic intent step 1 --project greeter
+because: the checklist has unfinished work
+```
+
+Until `spec.md` is written, the same screen points back at `plastic intent spec 1`. Until
+`plan.md` and `checklist.md` are written, it says so in the `because:` line.
+
+## 6. Do the work (Exec)
+
+**Plastic.** `plastic intent step 1` prints the next unchecked item. On a checklist intent, it
+does not run anything:
+
+```text
+work       Add a failing test for the greeting keyword
+checklist  /home/you/.plastic/stores/greeter/store/1--custom-greeting/checklist.md
+
+next: none
+because: perform this checklist item, record its verification, then run plastic intent show 1 --project greeter
+```
+
+**You or your agent** do the item on a branch. The branch name `plastic/1--custom-greeting`
+matches the name `plastic auto take` would provision, so the close can find it:
+
+```sh
+git switch -c plastic/1--custom-greeting
+```
+
+Add the new test to `test/greeter_test.rb`:
+
+```ruby
+def test_takes_a_greeting_word
+  assert_equal "Hi, Ada!", Greeter.greet("Ada", greeting: "Hi")
+end
+```
+
+Run the tests and watch the new one fail:
+
+```sh
+ruby -Ilib test/greeter_test.rb
+```
+
+```text
+ArgumentError: wrong number of arguments (given 2, expected 1)
+2 runs, 1 assertions, 0 failures, 1 errors, 0 skips
+```
+
+Commit the red test. Then tick the item in `checklist.md` in the intent directory: change
+`- [ ]` to `- [x]`.
+
+Run `plastic intent step 1` again for the second item. Change `lib/greeter.rb`:
+
+```ruby
+module Greeter
+  def self.greet(name, greeting: "Hello")
+    "#{greeting}, #{name}!"
+  end
+end
+```
+
+Run the tests again. Both pass:
+
+```text
+2 runs, 2 assertions, 0 failures, 0 errors, 0 skips
+```
+
+Commit, and tick the second item. `plastic intent show 1` now points at
+`plastic intent verify 1`, because every checklist item is complete.
+
+To keep the commit on the record, add a note to the savepoint. Replace `<sha>` with the commit
+hash:
+
+```sh
+plastic intent note 1 "<sha> greeting keyword, tests green" --kind Commit
+```
+
+## 7. Write the outcome and verify
+
+**You or your agent** replace the `outcome.md` placeholder in the intent directory. The shape
+follows `templates/outcome.md`. The `disposition` must match the close you plan, and each
+`## Delivered` row names one checklist step:
+
+```markdown
+---
+disposition: delivered
+---
+# Outcome: Let Greeter.greet take an optional greeting word
+
+## Summary
+Greeter.greet takes an optional greeting word; the default stays Hello.
+
+## Delivered
+| Row | What |
+| --- | --- |
+| S1 | A test for the greeting keyword |
+| S2 | The greeting keyword on Greeter.greet |
+
+## Verification
+- The new test passes and the old test still passes: `ruby -Ilib test/greeter_test.rb` printed 2 runs, 0 failures.
+
+## Needs you
+None
+
+## Follow-ups
+None
+```
+
+**Plastic.** Record what you verified as a report note:
+
+```sh
+plastic intent note 1 "Both greeter tests pass on the branch; outcome.md written" --kind Report
+```
+
+`--kind` takes `Review`, `Commit`, or `Report`. Without it, the note is a `Report`.
+
+Then run `plastic intent verify 1`. It runs the per-intent doctor check, the em-dash guard,
+and a diffstat of the code branch against `main`. Every check passes, and the command exits 0:
+
+```text
+doctor: pass
+em-dash guard: pass (0 violations)
+diffstat against main:
+ lib/greeter.rb       | 4 ++--
+ test/greeter_test.rb | 4 ++++
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+report lines:
+2026-09-23T11:50:28Z  Report  Both greeter tests pass on the branch; outcome.md written
+next: plastic intent end 1 --delivered --summary "TEXT" --project greeter
+because: a clean verify is what makes the close trustworthy
+```
+
+If a check fails, fix what it names and run `plastic intent verify 1` again. Do not close the
+intent while verify fails.
+
+## 8. Merge the code (Git)
+
+Plastic does not merge. Its delivered close refuses code that is not merged.
+
+**Plastic.** Try the close while the repository is still on the code branch:
+
+```sh
+plastic intent end 1 --delivered --summary "Greeter.greet takes an optional greeting word; the default stays Hello."
+```
+
+It exits 1 and writes nothing:
+
+```text
+end-intent: refusing a delivered close: the repo checkout /home/you/greeter is on the code branch plastic/1--custom-greeting itself, so the code is not merged anywhere. Check out the branch you release from, merge plastic/1--custom-greeting into it, then run the close again
+end-intent: nothing was merged, written, or released
+```
+
+**You.** Merge the branch and run the tests on `main`:
+
+```sh
+git switch main
+git merge --no-ff plastic/1--custom-greeting
+ruby -Ilib test/greeter_test.rb
+```
+
+## 9. Close the intent as delivered
+
+**Plastic.** Preview the close first:
+
+```sh
+plastic intent end 1 --delivered --summary "Greeter.greet takes an optional greeting word; the default stays Hello." --dry-run
+```
+
+The dry run lists what the close would do: move the `INDEX.md` entry to `## Completed`, append
+the terminal savepoint line, commit the store repository, and release the lock and the code
+worktree. It ends with:
+
+```text
+next: none
+because: the dry run wrote nothing and found nothing that would refuse the close
+```
+
+Run the same command without `--dry-run`. The close fills the records that are still
+placeholders from the record itself. Here that is the action file:
+
+```text
+end-intent: backfilled actions/ACTION_1.md from the record
+```
+
+`plastic intent show 1` now shows both steps done:
+
+```text
+next: none
+because: the intent is completed
+```
+
+`outcome.md` keeps what you wrote. The close writes the `--summary` text into the intent file's
+`## Outcome` section.
+
+## The same change in auto mode
+
+In auto mode, an agent team does steps 4 to 9. The commands below set up and inspect that
+run. They do not run the team; your harness does that.
+
+1. `plastic auto take ID` takes the delivery lock and provisions the code worktree at
+   `<repo>/.claude/worktrees/ID--slug` on branch `plastic/ID--slug`.
+
+   ```text
+   intent    2--shout
+   lock      acquired by auto-9184f6c4fa, auto mode
+   worktree  /home/you/greeter/.claude/worktrees/2--shout
+   ```
+
+   Run from inside a conversation session, `auto take` refuses with exit 3 unless you pass
+   `--allow-inline`. Exit 3 means the step belongs to the owner: stop and report it.
+
+2. `plastic auto brief ID` prints the preamble the dispatched agent reads first.
+3. `plastic auto lock status ID` shows who holds the lock and where the worktree is.
+4. `plastic auto report ID` prints the report contract and the review rules the lead follows.
+5. The close is the same `plastic intent end` as in step 9, with the same merge check.
+
+`plastic intent end ID --delivered` refuses an intent that nobody worked on. The spec, plan,
+checklist, and outcome are still placeholders, and the worktree has no changes. Close it with
+`--abandoned` instead:
+
+```sh
+plastic intent end 2 --abandoned --summary "Probe of the auto contract only."
+```
+
+The abandoned close also removes the code worktree.
+
+## Where to go next
+
+- `plastic help track-1-guided`: the same cycle for a graph intent, driven one node at a time.
+- `plastic help track-2-auto`: how the auto team walks the record.
+- `plastic help completion-and-done`: what the close checks and writes.
+- `plastic help locks-and-worktrees`: the delivery lock and the code worktree.