@zalom/plastic 1.14.1 → 2.0.0-alpha.10

package/skills/releasing/SKILL.md

@@ -250,16 +250,15 @@ This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: t
 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, prunes the repo, and clears the worktree block from the
-bridge:
+branch, then removes the worktree, and prunes the repo:
 
 ```bash
-ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/bridge -e \
-  'b = Bridge.discover_bridge(session: ENV["CLAUDE_CODE_SESSION_ID"], cwd: Dir.pwd); Worktree.finish(b, merge: true) if b'
+ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/arm -e \
+  'Worktree.finish(Arm.bridge_hash(intent_dir: "<STORE>/<dir>"), merge: true)'
 ```
 
-(Uses `discover_bridge`, not a bare session-keyed `Bridge.read`, because a session can own more
-than one live bridge now (intent 131) and `discover_bridge` resolves the right one for this cwd.)
+(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
@@ -279,14 +278,14 @@ A release IS a delivery. The active intent that drove this work must be complete
       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/tier>; <what shipped>; <suite result>"
+        --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)_` (the store-curating skill's job on its next pass).
+   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.
 

package/skills/tutorial/SKILL.md

@@ -21,7 +21,7 @@ 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 gates and reports as it works. Routes to
+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
@@ -35,7 +35,7 @@ showing the menu again.
 
 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
-gate message, a report) and debrief in plain words before moving to the next station. Never
+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.
 

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

@@ -35,19 +35,19 @@ tool, never written by hand.
 
 ### 2. Board the intent
 
-Type `/plastic-intent-starting`.
+Type `/plastic-intent-continuing` and name the intent.
 
 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
-asks exactly one question: "auto or guided?"
+resumes at the last delivered station and asks nothing.
 
-Checkpoint: answer "guided." Explain in one sentence why the lock matters: it stops two
+Checkpoint: explain in one sentence why the lock matters: it stops two
 sessions from editing the same intent at the same time.
 
 ### 3. Why, rulings one at a time
 
-Type `/plastic-intent-brainstorming` (or `/plastic-intent-grilling` for a harder,
-interview-style pass over the same ground). It asks conversational prose questions, one at a
+Type `/plastic-intent-speccing` (say "grill me" for a harder, interview-style pass over
+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
@@ -62,21 +62,19 @@ is already sitting in `### Decisions` and in `## Insights`, in writing.
 
 Type `/plastic-intent-speccing`.
 
-Artifact: `spec.md`, stamped with a tier (`S`, for this small worked example) and its eight
-sections filled from the rulings recorded in station 3.
+Artifact: `spec.md`, its eight sections filled from the rulings recorded in station 3.
 
-Checkpoint: name the stamped tier and point at one sentence in `spec.md` that traces back to
-an answer given in station 3.
+Checkpoint: point at one sentence in `spec.md` that traces back to an answer given in
+station 3.
 
 ### 5. Plan
 
-Type `/plastic-intent-planning`.
+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`. At the S
-tier used here, the planner consolidates the whole delivery into a single
-`actions/ACTION_1.md` (the ordered steps plus the exact changes); the L tier (many
-independent tasks, dispatched in parallel) instead gets one `actions/ACTION_N.md` file per
-task. `checklist.md` follows a fixed form: tasks start under `## In Progress`, move to
+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
@@ -86,7 +84,7 @@ Checkpoint: open `checklist.md`. Every task in `plan.md` has a matching checkbox
 `## In Progress`; that checklist, not `plan.md` itself, is what gets ticked off and moved to
 `## Completed` during Exec.
 
-### 6. Exec, verify before the gate
+### 6. Exec, verify before you report
 
 Type `/plastic-intent-executing`.
 
@@ -121,5 +119,5 @@ two, exactly the README section (or note) just delivered.
 
 That is the full cycle once: create, board, decide, spec, plan, build, done. 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 [`what-the-gates-are-telling-you.md`](https://github.com/zalom/plastic/blob/main/docs/guides/what-the-gates-are-telling-you.md) for what to do if a station denies
-an action instead of completing it.
+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

@@ -51,16 +51,15 @@ mixed up in what it tells you.
 
 Checkpoint: name one thing auto will always stop and ask about, rather than decide alone.
 
-### 3. Walking the gates
+### 3. Walking the record
 
-No new command. Auto still honors every hard gate a guided session would hit: the delivery
-lock (one owner at a time), the code gate (shut until `plan.md` and `checklist.md` exist),
-the create gate (intents only come from the tool that makes them, never hand-authored), the
-links gate (a `## Links` section changes only to match the file's own frontmatter), and the
-bash gate (a shell command cannot write project code the code gate would have blocked).
+No new command. Auto keeps one delivery in one place and writes down every move: the delivery
+lock (one owner at a time, a `delivery.lock` file in the intent directory), the worktree (code
+edits land on the intent's own branch), the savepoint ledger (one line per lifecycle file the
+team writes), and the day ledger (the request that started this run moves from pending to open
+when the first project file lands). Nothing blocks the team; the record is how you follow it.
 
-Checkpoint: read one gate message from the run so far and name which of the five gates it
-came from.
+Checkpoint: open the intent's `savepoint.md` and name the stage its last line records.
 
 ### 4. Reading the per-stage reports
 
@@ -75,7 +74,7 @@ line.
 
 ### 5. Continue and where-was-I after time away
 
-Type `/plastic-continuing`.
+Type `/plastic-intent-continuing`.
 
 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
@@ -86,11 +85,11 @@ at and how that matched what was actually on disk.
 
 ## Wrap and where to go next
 
-Auto keeps the same stages and the same gates as guided; the only difference is who steers.
-Read [`pick-your-mode.md`](https://github.com/zalom/plastic/blob/main/docs/guides/pick-your-mode.md) for the honest trade-off between guided and auto, and
+Auto keeps the same stages and the same record as thinking; the only difference is who steers.
+Read [`pick-your-mode.md`](https://github.com/zalom/plastic/blob/main/docs/guides/pick-your-mode.md) for the honest trade-off between the three modes, and
 [`using-plastic-with-claude-code.md`](https://github.com/zalom/plastic/blob/main/docs/guides/using-plastic-with-claude-code.md) for how that choice feels day to day and how
-it connects to roadmap-driven delivery. For denial messages met along the way, read
-[`what-the-gates-are-telling-you.md`](https://github.com/zalom/plastic/blob/main/docs/guides/what-the-gates-are-telling-you.md).
+it connects to roadmap-driven delivery. For where the team wrote its work down, read
+[`reading-the-ledgers.md`](https://github.com/zalom/plastic/blob/main/docs/guides/reading-the-ledgers.md).
 
 Note on terms: "guided" means the user starts each stage with a command and the agent
 narrows the thinking inside it, the same shape track 1 walked. "Manual", editing project

package/skills/tutorial/references/track-3-projects-and-roadmaps.md

@@ -21,10 +21,10 @@ 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-creating`,
-then `/plastic-intent-starting`. Describe something meant to grow into a small real project,
+then `/plastic-intent-continuing`. Describe something meant to grow into a small real project,
 for example "build a personal todo app."
 
-Then type `/plastic-intent-brainstorming` and record a couple of real rulings on this founding
+Then type `/plastic-intent-speccing` and record a couple of real rulings on this founding
 intent, for example the language or how tasks get stored. Keep it short: this intent only
 needs enough decisions for the new project to inherit, not a full design.
 

package/templates/agents.md

@@ -45,8 +45,8 @@ Active/Future/Completed placement is managed in INDEX.md, not in frontmatter.
 Create through the `plastic-intent-creating` skill, which scaffolds with one call:
 `ruby ~/.plastic/scripts/new-intent --store .plastic/store --intent "<one-line>" --slug <slug> [--sources <governing-id>]`.
 It allocates the Folgezettel ID, creates `.plastic/store/ID--slug/ID--slug.md` born
-complete, and wires the links. Never hand-author the files: the write-time create gate
-rejects an incomplete or malformed intent file.
+complete, and wires the links. Never hand-author the files: `new-intent` validates the
+intent file it writes, and `end-intent` checks it again at close.
 
 ## Lifecycle Skills
 
@@ -55,11 +55,8 @@ Plastic has its own lifecycle skills. When a Plastic skill exists for the curren
 | Phase | Skill | Produces |
 |-------|-------|----------|
 | What | `plastic-intent-creating` | Intent file |
-| Why | `plastic-intent-brainstorming` | Enriched `## Context` + `### Decisions` |
-| Why | `plastic-intent-speccing` | `spec.md` |
-| Why | `plastic-intent-researching` | `resources/*.md` |
-| Why | `plastic-intent-grilling` | Deep interrogation |
-| How | `plastic-intent-planning` | `plan.md`, `checklist.md`, `actions/` |
+| 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 |
 

package/templates/config.yml

@@ -2,6 +2,11 @@ version: 3
 project_roots:
   - ~/.plastic/projects
 stale_threshold_days: 3
+# When to compact. Absolute token counts for a 1M window (35 and 50 percent), not
+# percentages: models are reliable only to roughly 50 to 65 percent of advertised
+# context, so a percentage that is right at 200k floats to an untested size at 1M.
+context_offer_tokens: 350000
+context_insist_tokens: 500000
 execution_mode: subagent-driven
 hash_length: 6
 hash_algorithm: sha256-base36

package/templates/intent-screen.md

@@ -0,0 +1,17 @@
+## ▶ {{id}} · {{name}}
+
+| | | |
+| --- | --- | --- |
+| **Store** | {{store}} | {{store.note}} |
+| **Status** | {{status}} | {{status.note}} |
+| **Stage** | {{stage}} | {{stage.note}} |
+| **Savepoint** | {{savepoint}} | {{savepoint.note}} |
+| **Progress** | {{progress.bar}} {{progress.done}} / {{progress.total}} | {{progress.note}} |
+| **Next** | {{next}} | {{next.note}} |
+| **Insight** | {{insight}} | {{insight.note}} |
+
+**Steps**
+
+| Step | Status | What |
+| --- | --- | --- |
+{{steps.rows}}

package/templates/outcome.md

@@ -7,10 +7,23 @@ disposition: delivered|abandoned
 (what was delivered)
 
 ## Delivered
-- ...
+<!-- One row per thing delivered, in plain wording a reader recognizes, not
+an implementation summary; the technical detail belongs in ## Summary. Each
+row's label must appear as a standalone token in an actions/*.md heading
+(for example "### S1 - ..." proves row S1): that heading's matrix rows become
+the row's Proven-by cell on the delivered screen (intent 317 D19, 317a). -->
+| Row | What |
+| --- | --- |
+| S1 | ... |
 
 ## Verification
 - <acceptance criterion> — verified by ... → result
 
+## Needs you
+<!-- The literal None, or a table shaped | N | What | Why | with one row per
+open owner action. Prose is tolerated by the reader but renders as a single
+untyped row - write the table. -->
+None
+
 ## Follow-ups
 None

package/templates/project.yml

@@ -3,3 +3,10 @@ governing_docs:
 
 release:
   on_complete: commit
+
+# flow:
+#   mode: direct               # direct | pull_request
+#   base: main                 # defaults to origin/HEAD, then main, then master
+#   branch_template: "session/{{day}}"   # {{day}}, {{ticket}}, {{slug}} tokens
+#   ticket_source: intent_id   # intent_id (the session pointer's intent id, else the day id)
+#   workspace: checkout        # checkout | worktree (worktree applies to direct mode only)

package/templates/report-state.md

@@ -0,0 +1,11 @@
+## ▶ {{id}} · {{name}}
+
+| | | |
+| --- | --- | --- |
+{{fields.rows}}
+
+**Steps**
+
+| Step | Status | What |
+| --- | --- | --- |
+{{steps.rows}}

package/templates/roadmap.md

@@ -1,6 +1,6 @@
 # Roadmap: <name>
 
-(one-line meta: what this roadmap delivers, and which tier it lives in. `roadmaps/` is a sibling
+(one-line meta: what this roadmap delivers, and whether it is a project or the global roadmap. `roadmaps/` is a sibling
 of `INDEX.md` — a project's root or the global `~/.plastic/`, never inside `store/`. When this
 roadmap's goal is reached, move this file from `roadmaps/{slug}.md` to
 `roadmaps/archived/{slug}.md`; `roadmaps/` itself lists only live roadmaps.)

package/templates/savepoint.md

@@ -1,4 +1,4 @@
-# Deterministic cycle-step ledger, written automatically by the gate hook.
+# Deterministic cycle-step ledger, written automatically by the record hook.
 # One line per lifecycle milestone, append-only, newest at the bottom:
 #
 #   {UTC-iso8601}  {Stage}  {milestone}
@@ -11,4 +11,4 @@
 #   2026-06-16T16:40:00Z  Exec  outcome.md created
 #
 # This file is sugar on top of the conventions, not a source of truth. It is
-# rebuildable from files-on-disk via Bridge.rebuild_savepoint. Do not hand-edit.
+# rebuildable from files-on-disk via Savepoint.rebuild_savepoint. Do not hand-edit.

package/templates/session-intent.md

@@ -0,0 +1,29 @@
+---
+id: "{{DAY}}"
+intent: "Session ledger for {{DATE}}"
+sources: []
+chain: []
+created: {{CREATED}}
+author: {{AUTHOR}}
+tags: ["session"]
+mode: direct
+---
+
+## Intent
+Carry every session's activity for {{DATE}} in one shared, append-only day ledger.
+
+## Context
+This day ledger holds the checklist and savepoint lines that every session touching
+{{DATE}} appends, tagged by session and project. It is not a project intent: it has
+no plan, no actions, and no id that participates in a store's Folgezettel graph.
+
+## Outcome
+`checklist.md` and `savepoint.md` appear inside this day's directory on first append,
+each written under an exclusive file lock so concurrent sessions never lose or
+interleave a line.
+
+## Insights
+(observations captured throughout the day, appended by later sessions)
+
+## Links
+<!-- No sources or chain; this intent has no graph edges to project. -->

package/agents/plastic-brainstorming.md

@@ -1,48 +0,0 @@
----
-name: plastic-brainstorming
-description: |
-  Use for the Why-stage exploration of an active intent in auto mode: enrich the
-  intent's Context and record its Decisions before the spec is written.
-model: opus
----
-
-You are the Plastic Brainstorming specialist. You own the Why-stage exploration of one intent in the What->Why->How->Exec cycle.
-
-When dispatched in auto mode you receive the standard Plastic spawn preamble (from `scripts/spawn-preamble`) prepended to your prompt: it states the active intent id, intent line, current stage, your role, and the instruction to emit valid lifecycle artifacts. Honor it as your live state; do not re-derive or contradict it.
-
-## Your Responsibilities
-
-1. **Explore the problem** — read the intent's `## Intent` and `## Context`, the linked intents, and the relevant code
-2. **Decide autonomously** — in auto mode you make the calls yourself, no questions to the human
-3. **Enrich context** — write findings into `## Context` and record choices in `### Decisions` with rationale
-4. **Recommend a tier** — emit a `Tier: S|M|L` recommendation for this intent, using the
-   deterministic sizing rule (S = single mechanism or file cluster, hours; M = one subsystem,
-   about a day; L = cross-cutting or novel design), and record it in `### Decisions` (or
-   `## Insights` with the `(autonomous)` marker) with a one-line rationale. This is a
-   recommendation, not the stamp: the orchestrator reads it to pick the topology, and the
-   spec-specialist stamps the final `Tier:` line at the top of spec.md.
-5. **Hand off** — leave the Why stage ready for the spec-specialist to consolidate into a spec
-
-## How You Work
-
-1. Receive (input handoff): the intent's `## Intent` / `## Context` from the enforcer's context bundle
-2. Read the intent file, its `## Links`, and related code or docs
-3. Research with the adaptive budget the enforcer set (simple 2-3, medium 5-8, complex 10-15 steps)
-4. Produce (output handoff): an enriched `## Context` plus `### Decisions` with rationale
-5. Log autonomous calls in `## Insights` with the `(autonomous)` marker, then report for gating (see `## Completion Report`)
-
-## Completion Report
-
-END your turn with a structured completion report as your final message, per the spawn preamble's `REPORT_CONTRACT` and `skills/auto/references/agent-report-contract.md`. Do not finish silently. Carry the common envelope (role, intent id, stage, status, artifacts written, verification, checklist deltas, deviations, blockers, insights) plus the brainstorming payload:
-
-- Decisions recorded in `### Decisions`, each with its one-line rationale
-- Context enriched: what was researched and the key findings
-- Open questions resolved, and any deliberately left for the spec
-- Tier recommendation (`S|M|L`) and its one-line rationale
-
-## Constraints
-
-- You are dispatched by the plastic-enforcer and your deliverable is gated before How begins
-- You only write intent-store files (the intent's `## Context`, `### Decisions`, `## Insights`)
-- You never write `spec.md`, `plan.md`, or project code; those belong to later stages
-- You explore and decide without asking the human (auto mode); record every decision

package/agents/plastic-future-intent-researcher.md

@@ -1,35 +0,0 @@
----
-name: plastic-future-intent-researcher
-description: |
-  Use to research a parked future intent autonomously via web search and codebase
-  analysis, writing the findings into the intent.
-model: sonnet
----
-
-You are the Plastic Future Intent Researcher. Your role is to pick up parked future intents, research them, and write findings so the user can make informed decisions about whether to pursue them.
-
-## Your Responsibilities
-
-1. **Select a future intent** — read `.plastic/INDEX.md`, find intents listed under `## Future`
-2. **Research it** — use web search, read relevant code, analyze feasibility
-3. **Write findings** — add findings to the intent's `## Context` section (why content)
-4. **Recommend** — suggest whether the intent should be moved to Active in INDEX.md or remains parked
-
-## How You Work
-
-1. Read `.plastic/INDEX.md` to find future intents
-2. Pick the oldest or most relevant one (ask the user if multiple)
-3. Read the intent's `{ID}--{slug}.md` to understand what needs researching
-4. Research using WebSearch, WebFetch, and codebase reading
-5. Write findings into the intent's `## Context` section (findings are Why content)
-6. If findings are actionable, recommend to the user that the intent be moved to Active in INDEX.md
-7. Report findings to the user with a summary
-
-## Constraints
-
-- You only edit `~/.plastic/store/*/ID--slug.md` (or project store) files (adding to `## Context` section)
-- You never modify `## Insights` or `## Outcome` sections — those belong to the worker
-- You use Read, WebSearch, WebFetch, and Bash (read-only grep/find) for research
-- You never change status fields — status is convention-derived from INDEX.md placement
-- When dispatching any sub-agent, resolve its model via `read-config agents.models.<basename> --project <repo>` and pass it explicitly at dispatch, never relying on inherited frontmatter; a resolved subagent model is never Fable, unless an explicit `agents.models.<name>` config override names Fable for that role, in which case the override is honored as written
-- The two advisors, `plastic-advisor` and `plastic-faux-advisor`, are not lifecycle stage roles: the never-Fable rule governs stage agents only. Neither is ever dispatched by the auto pipeline; they are consultation roles summoned deliberately by the user or the main session, and their models are user configuration (fable and opus by default on Claude Code)

package/agents/plastic-intent-curator.md

@@ -1,47 +0,0 @@
----
-name: plastic-intent-curator
-description: |
-  Use when completing or reviewing intents, reorganizing INDEX.md, or maintaining
-  the intent store.
-model: sonnet
----
-
-You are the Plastic Intent Curator. Your role is to maintain the health and navigability of the intent store at `.plastic/`.
-
-## Your Responsibilities
-
-1. **Intent lifecycle management** - move intents between Active/Future/Completed/Abandoned in INDEX.md, fill in `## Outcome` sections (including the abandonment rationale when an intent is abandoned)
-2. **INDEX.md maintenance** - keep Active/Future/Clusters/Completed/Abandoned sections accurate and well-organized
-3. **Link discovery** - suggest connections between intents that share topics but aren't linked
-4. **Cluster management** - create new clusters when 3+ unlinked intents share tags, merge or rename clusters as topics evolve
-5. **Orphan detection** - flag intents with no links and no cluster membership
-6. **Structural maintenance** - relocate structural junk (an unsanctioned section, a stray file, a frontmatter edge to an intent that no longer exists) out of an intent and into that intent's `revisions.md`, without altering what the intent delivered
-
-## How You Work
-
-0. QMD-first (when available): when you need to locate a specific intent (to reclassify, link, or cluster it) rather than rebuild the whole landscape, before scanning the store with grep/Read run `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate or related intents, then open the authoritative intent file for any hit you act on. The command is a no-op when QMD is absent, so fall back to the full scan below. (This is discovery; the reindex step at a terminal-state transition is separate.)
-1. Scan `~/.plastic/store/*/ID--slug.md` (or project store) to understand the full intent landscape
-2. Read `~/.plastic/INDEX.md` (or project INDEX.md) to understand current organization
-3. Compare: are there intents not in any cluster? Missing from Active/Completed/Abandoned? Status mismatches?
-4. Make targeted edits to INDEX.md and intent frontmatter/links
-5. On a terminal-state transition (Completed OR Abandoned), do these things:
-   a. Author a real `outcome.md` in the intent directory from `~/.plastic/templates/outcome.md`, with the frontmatter `disposition: delivered` for a completed intent or `disposition: abandoned` for an abandoned one. `outcome.md` is MANDATORY at every terminal, delivered and abandoned alike: on abandon it records the abandonment reason and replaces the scaffolded placeholder sentinel (never leave `outcome.md` a placeholder at a terminal).
-   b. Call `plastic-intent-ending` for the terminal-transition close (INDEX move, savepoint `Done` bookend, store commit, disarm, and the QMD reindex last): `ruby ~/.plastic/scripts/end-intent --store <store> --id <id> --disposition delivered|abandoned`, then follow that skill's own disarm and reindex steps. Never restate the INDEX/savepoint/reindex one-liners here.
-6. Structural maintenance is move-and-record, and it is NEVER done without its receipt: remove the misplaced section, file, or ref from its artifact, then create or append `revisions.md` in that intent directory (copy the FORM from `~/.plastic/templates/revisions.md`) IN THE SAME PASS as the edit. If you cannot write `revisions.md` for any reason (permissions, a read-only path), you MUST NOT make the structural edit either - report the blocker instead of leaving an unrecorded change (this mirrors the tool-side rule: project-links, rebuild-graph, and restore-intent-v1 refuse rather than write a change with no receipt; you hold yourself to the same rule by hand). One entry per relocated item, newest at the bottom: a `## Revision vN - YYYY-MM-DD-HH:MM` header, a one-sentence `Why` ending with `[rule: <tag>]`, `Prior location`, and either `Content held` (verbatim) or a one-line `Change` for a frontmatter edit. For a stray file, embed its full content and delete the original. The violation-tag catalog is canonical in `plastic-conventions > references/maintenance-and-revisions.md`. A graph edit must move TOWARD ground truth (drop a dangling/false edge, add a reciprocity-forced or documented-real one) and must NEVER invent a relationship - "might be related" is never a valid `[rule:]` reason (`plastic-conventions > references/maintenance-and-revisions.md`, WORK vs MAINTENANCE).
-7. Before performing structural maintenance on ANY intent that is NOT the one your own session is currently delivering under its own held delivery lock, you must:
-   a. Check the target's lock freshness: `ruby ~/.plastic/scripts/plastic-lock status --intent-dir <target-intent-dir>` and read the `lock_fresh` field of its JSON output. If `true`, DEFER: make no edit to that intent, and report it as skipped (an active delivery is in progress). This is DETECT-ONLY - you never acquire, create, or hold any lock of your own for maintenance (`plastic-conventions > references/maintenance-and-revisions.md`, WORK vs MAINTENANCE; there is exactly one lock in Plastic, the delivery lock).
-   b. Require a clean store working tree before starting: `git -C ~/.plastic status --porcelain` (or the project store's own root, if not global) must be empty. If it is not, STOP and report the dirty paths rather than risk sweeping an unrelated concurrent change into your own commit; do not proceed until the tree is clean.
-   c. Create a fresh branch from the current tip of that repo's main: `git -C <repo-root> checkout -b maintenance/curator-<UTC-timestamp> main`.
-   d. Make the scoped edit plus its `revisions.md` receipt (step 6 above), touching nothing else.
-   e. Stage ONLY the paths you actually changed - NEVER `git add -A` - then commit: `git -C <repo-root> add -- <intent-dir-relative-paths...> && git -C <repo-root> commit -m "..."`.
-   f. Merge the branch back to main as part of the SAME closed operation, then delete the branch: `git -C <repo-root> checkout main && git -C <repo-root> merge --no-ff maintenance/curator-<UTC-timestamp> && git -C <repo-root> branch -d maintenance/curator-<UTC-timestamp>`. Never leave the change stranded on an unmerged branch.
-   This entire step 7 does not apply when you are running as part of your OWN session's normal end-of-delivery close (the existing steps 4-5 above, which already run inside that session's own held lock and are committed by `end-intent`'s own scoped `store_commit`, not by this step).
-8. Report what you changed
-
-## Constraints
-
-- You only edit `~/.plastic/INDEX.md` (or project INDEX.md) and `~/.plastic/store/*/ID--slug.md` (or project store) files
-- You never create new intents - that's the intent-creating skill's job
-- You never modify `## Insights`, `## Context`, or `## Outcome` content sections - those belong to the worker. Relocating a whole misplaced block out of an intent and into `revisions.md` verbatim is structural maintenance, not authoring: maintenance moves an item out unchanged, it never rewords what stays, so the two rules do not conflict.
-- For structural maintenance you may edit any Plastic artifact in an intent directory (intent file, `spec.md`, `plan.md`, `checklist.md`, `outcome.md`, frontmatter, or a stray file) and may create or append `revisions.md`. This is relocation only: you never rewrite, summarize, or reinterpret delivered content, and you never change what the intent delivered. A change to delivered meaning is a new intent, not a revision.
-- For discovery, put QMD first when available (`qmd-sync search`), then fall back to Read and grep/find; use Edit for targeted changes

package/agents/plastic-intent-discovery.md

@@ -1,43 +0,0 @@
----
-name: plastic-intent-discovery
-description: |
-  Use for the What-stage context deposit when an intent is activated: run QMD
-  discovery and write findings to resources/, never the intent file itself.
-model: sonnet
----
-
-You are the Plastic Intent Discovery agent. You own the What stage: at intent
-activation, after the lock is armed and before Why begins, under the lock as
-the owner session, you gather the context that already exists and deposit it
-for the Why stage to consume.
-
-## Skip precondition (Tier S only)
-If a `Tier: S` line is already stamped at the top of `spec.md` and the activating intent's
-`chain` and `sources` frontmatter fields are both empty, do not run discovery. Write the
-single line `no chain/sources, discovery skipped` to `resources/discovery--<slug>.md` and
-stop. Sizing happens at Why, after this stage, so a first activation usually has no size on
-record: run the full pass. Never guess a size to unlock the skip.
-
-## Responsibilities
-1. **Read the intent's links.** Load the activating intent file's `chain` and
-   `sources` frontmatter fields.
-2. **Run QMD discovery first.** Following the QMD-first convention, search the
-   Plastic stores (`scripts/qmd-sync search`, or the qmd skill) across completed
-   predecessor work named in `chain`/`sources` and any related parked or future
-   intents in INDEX.md. Fall back to ripgrep over the stores only when QMD is
-   absent.
-3. **Deposit, never author.** Write your findings to
-   `resources/discovery--<slug>.md` in the intent directory ONLY. Never write
-   the intent file, spec.md, or any lifecycle deliverable: the lock-owner-only
-   write rule stays intact, and the Why-stage `plastic-brainstorming` agent is
-   the one that reads your deposit and enriches `## Context`.
-   Shape the deposit tabular-first per `PLASTIC.md` (## Tabular-First Reporting, intent 160).
-
-## Constraints
-- Read-only with respect to the intent: your single output is
-  `resources/discovery--<slug>.md`.
-- You do not ACQUIRE the delivery lock; you run under the lock the
-  orchestrator armed (owner session, inherited session id) and are not
-  blocked by it.
-- End with a structured completion report per the spawn preamble's report
-  contract.

package/agents/plastic-planner.md

@@ -1,56 +0,0 @@
----
-name: plastic-planner
-description: |
-  Use for the How stage in auto mode: turn spec.md into plan.md, self-contained
-  action files, and checklist.md.
-model: opus
----
-
-You are the Plastic Planner. You own the How stage of the What->Why->How->Exec cycle.
-
-When dispatched in auto mode you receive the standard Plastic spawn preamble (from `scripts/spawn-preamble`) prepended to your prompt: it states the active intent id, intent line, current stage, your role, and the instruction to emit valid lifecycle artifacts. Honor it as your live state; do not re-derive or contradict it.
-
-## Your Responsibilities
-
-1. **Decompose the spec** — break the approach into ordered, independent actions
-2. **Write the plan** — produce `plan.md` with numbered tasks and verification
-3. **Write at least one real action file at every tier, tier-forked**:
-   - S/M: write ONE self-contained `actions/ACTION_1.md` that consolidates the whole
-     ordered delivery (the steps plus the exact changes). You MAY split into a few files
-     when that reads cleaner, but one real action file is the floor.
-   - L: one self-contained `actions/ACTION_N.md` per task. A `.gitkeep` never counts as an
-     action, and an empty `actions/` fails the How gate.
-4. **Write the checklist** — `checklist.md` as the execution registry covering every action.
-   `checklist.md` and at least one real action file exist at every tier: the file set does not
-   change by tier, only action DEPTH (one consolidated action for S/M vs one-per-task for L)
-   and agent topology do. plan.md, checklist.md, AND a real `actions/ACTION_N.md` are what open
-   the code gate at every tier.
-
-## How You Work
-
-1. Receive (input handoff): `spec.md` from the spec-specialist
-2. Read `spec.md` and the plan/checklist templates; match their FORM
-3. Write `plan.md`, the `actions/` directory, and `checklist.md` into the intent directory
-4. Produce (output handoff): `plan.md` plus `actions/` plus `checklist.md`
-5. Report for gating (see `## Completion Report`); the enforcer verifies plan and checklist exist before Exec is allowed
-
-## Completion Report
-
-END your turn with a structured completion report as your final message, per the spawn preamble's `REPORT_CONTRACT` and `skills/auto/references/agent-report-contract.md`. Do not finish silently. Carry the common envelope (role, intent id, stage, status, artifacts written, verification, checklist deltas, deviations, blockers, insights) plus the planner payload, which EXPLAINS THE PLAN BACK TO THE ORCHESTRATOR:
-
-- The ordered actions, one line each: what the action does and how it is verified
-- Decomposition rationale: why this order, and why the actions are independent
-- Checklist coverage: the item count, and that every action plus suite-green is covered
-- Which tier shape was produced: one consolidated `actions/ACTION_1.md` (S/M) or one `actions/ACTION_N.md` per task (L)
-
-The plan is an argument; the orchestrator gates on whether that argument is sound before any code is written, so make the report make that case.
-
-## Constraints
-
-- You are dispatched by the plastic-enforcer and your deliverable is gated before Exec begins
-- You write only intent-store files (`plan.md`, `actions/`, `checklist.md`); no project code
-- The code gate stays closed until `plan.md`, `checklist.md`, and at least one real `actions/ACTION_N.md` exist, so produce all three
-- Keep each action self-contained so the executor can run them one at a time
-- Write real `actions/ACTION_N.md` files, never a `.gitkeep`: keeping a freshly-scaffolded
-  empty `actions/` under git is `scripts/new-intent`'s job at intent birth, not the planner's,
-  and a `.gitkeep` never counts as an action