@zalom/plastic 2.0.0-alpha.9 → 2.0.1

package/skills/intent-continuing/references/context-management.md

@@ -1,28 +0,0 @@
-# Context Management (Save, then resume-flow debugging)
-
-## Save Point
-Triggered by PreCompact hook or manually:
-1. Find active intent(s) from `~/.plastic/INDEX.md`
-2. Update active intent's `checklist.md` (check off completed items)
-3. Update active intent's `savepoint.md` (in-progress, next steps, blockers, discoveries)
-4. Add observations to `## Insights`
-5. Update INDEX.md
-6. Commit: `cd ~/.plastic && git add . && git commit -m "chore: savepoint - [intent name]"`
-7. Notify user to `/clear`
-
-## Debugging the resume flow
-
-When a resume looks wrong (the announced stage does not match what is on disk, or the next
-step looks stale):
-
-1. Read `savepoint.md`'s last line directly; that line alone is the source of truth for stage
-   (see `SKILL.md`'s `## Conditional Ledger-Resume` for the full state table).
-2. Confirm the artifact that line implies (`plan.md`, `checklist.md`, `outcome.md`, ...) is
-   present and non-empty on disk.
-3. If the two disagree, the ledger is stale: rebuild it rather than hand-editing:
-   `ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'`
-4. Re-read the rebuilt last line and re-derive the next step from `checklist.md`'s first
-   unchecked item.
-
-The general "land on the board / priority order / stale future intents" flow now lives in
-`plastic-intent-continuing`; this file no longer duplicates it.

package/skills/intent-continuing/references/liveness-ranking.md

@@ -1,57 +0,0 @@
-# Liveness Ranking (read time, no new field)
-
-Depth reference for "Find the mid-flight roadmap" in `SKILL.md`. This is the full algorithm the
-body summarizes. Since intent 148, this algorithm is IMPLEMENTED in
-`scripts/lib/roadmap_queue.rb` behind the `scripts/roadmap-next` CLI; it is no longer a by-eye
-procedure. This page documents what that reader does, and is the specification the reader
-satisfies.
-
-## Why read-time, not a stored field
-
-INDEX.md stays the sole writer of intent status; the roadmap file mirrors it (see
-`plastic-roadmap`'s `references/file-format.md`). Adding a "mid-flight" flag to the roadmap
-file or to INDEX.md would create a second thing to keep in sync for a question that is cheap to
-answer by reading what is already there. So liveness is computed fresh, every call, from the
-tier's live `roadmaps/*.md` files (excluding `roadmaps/archived/`), by `RoadmapQueue` (intent
-148) rather than by eye.
-
-## The algorithm
-
-1. **Enumerate.** List every `roadmaps/*.md` at the tier (project or global), skipping
-   `roadmaps/archived/`.
-2. **Delivering/blocked wins outright.** If any candidate roadmap has at least one grouping-section
-   entry (`## Batches`, or legacy `## Waves`) whose mirrored status token is `delivering` or
-   `blocked`, it is in flight right now.
-   That candidate wins the ranking immediately; skip the rest of the ranking for it.
-3. **Otherwise, newest `## Log` entry wins.** Among the remaining candidates (none have a
-   `delivering`/`blocked` entry), read each file's last `## Log` line (append-only, newest at
-   the bottom) and rank by that line's `YYYY-MM-DD HH:MM UTC` timestamp. The most recent wins.
-   When a candidate's paired `roadmaps/<slug>.savepoint.md` (intent 134) is present, its last
-   line is a cheaper, machine-timestamped read of the same fact (the ledger is derived from `##
-   Log`, so the two should already agree); reading it first is an optimization, not a second
-   source of truth, so a missing or stale ledger never blocks falling back to `## Log` itself.
-4. **Genuine tie -> present, do not silently pick.** If two or more candidates are equally live
-   (for example two roadmaps both idle with `## Log` entries on the same timestamp, or two both
-   showing `delivering` entries with no other signal to separate them), do not choose for the
-   user. Present both/all tied candidates' state side by side, then let the single "auto or
-   guided?" ask (asked once regardless of how many candidates were presented) double as the
-   resolution: the user's answer implicitly picks by naming which roadmap to continue, or the
-   agent asks a short one-line disambiguation immediately before that same single ask, never a
-   second separate prompt.
-
-## What this closes
-
-Before this skill existed, nothing resumed a mid-flight roadmap automatically. The `171`
-(consistency-dividend) roadmap handoff had to be resumed by hand: a free-prose "SESSION
-HANDOFF" note written into `171`'s own `## Insights`, because nothing read the grouping section
-(`## Batches`/legacy `## Waves`) + `## Log` and reconstructed where the batch stood. This ranking, now a deterministic reader
-rather than a by-eye judgment, is the mechanism that replaces that hand-carried note.
-
-## Grammar pointer (do not duplicate)
-
-The roadmap file's four sections, entry line shape, and status vocabulary
-(`queued|delivering|delivered|abandoned|blocked`) are owned by `plastic-roadmap`:
-`skills/roadmap/references/file-format.md` for the shape, and
-`skills/roadmap/references/operations.md#read--consume` for how a reader (human or
-coordinator) is meant to walk `## Batches` (or legacy `## Waves`) and `## Log`. This page assumes that grammar and adds
-only the liveness-ranking judgment on top of it.

package/skills/intent-creating/SKILL.md

@@ -1,164 +0,0 @@
----
-name: plastic-intent-creating
-description: Use when new work begins, the user expresses a new goal, says "new intent", or no active intent exists for the current task. Creates intents in the global store (~/.plastic/store/) or in a project's store (~/.plastic/projects/{slug}/store/) depending on context.
-user-invocable: true
----
-
-# Creating an Intent
-
-## When to Use
-- User starts new work ("build X", "fix Y", "research Z")
-- No active intent matches the current task
-- User explicitly says "new intent" or "create intent"
-- An agent discovers work needed during implementation
-
-## Determine the store
-
-**Global intent** (strategic): created when working outside a registered project, or when the user expresses a high-level goal. Stored in `~/.plastic/store/`.
-
-**Project intent** (tactical): created when working inside a registered project directory. Stored in `~/.plastic/projects/{slug}/store/`. Automatically linked to the project's governing intent.
-
-### Detection logic:
-1. Read `~/.plastic/projects.yml`
-2. **CWD match:** Match CWD against registered project paths
-   - If CWD is inside a registered project → **project intent (tactical)**
-3. **Explicit mention:** User mentions an existing project by name ("add this to reddit-kb", "new intent for plastic")
-   - Look up project in `projects.yml` by slug
-   - If found → **project intent (tactical)** in that project's store at `~/.plastic/projects/{slug}/store/`
-   - Agent changes working directory to the project path for execution
-4. **No match:** CWD is not in a project AND no project mentioned
-   - → **global intent (strategic)** in `~/.plastic/store/`
-
-When creating a tactical intent in a project store:
-- Read the project's `AGENTS.md` for project context and decisions
-- Link back to the project's governing intent (from `projects.yml` `parent` field) via `sources` (the project genuinely is formed from its founding intent, a true formative edge, reciprocated on the founding intent's `chain`)
-- Add `[[global:<parent_ID>]]` backlink in `## Links`
-- The intent's Folgezettel ID is scoped to the project store (run `folgezettel-id` against the project's store at `~/.plastic/projects/{slug}/store/`)
-
-## Workflow
-
-### 1. Determine Store Location
-
-- **Global:** `~/.plastic/store/`
-- **Project:** `~/.plastic/projects/{slug}/store/`
-
-### 2. Check for a Duplicate or Predecessor (QMD-first)
-
-QMD-first (when available): before scanning the store with grep/Read, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate, prior, or duplicate
-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 existing INDEX.md / file scan. Do this before allocating
-the id so a near-duplicate can be reused and a true predecessor can be set in `--sources`.
-
-### 3. Decide Branch vs Root
-
-Decide this BEFORE scaffolding, because it sets whether you pass `--parent`.
-Having a "parent" in mind does NOT automatically mean branch. Choose by meaning:
-
-- **Branch (`14a`, `14b`)**: a sub-task, refinement, or direct continuation. It only
-  makes sense as part of the parent's work. Pass `--parent <parent_id>`.
-- **Root (`15`, `16`)**: an independent thought. Two cases, decided by ORIGIN:
-  - **Created from another intent** (it emerged from that intent's lifecycle): make it a
-    root and set `--sources <ascendant_id>`. `sources` is reserved for true created-from /
-    direct-ascendant provenance (D1).
-  - **Merely related to / inspired by another intent** (it did NOT come out of that
-    intent's lifecycle): carry NO `--sources`. Record the relation on the PREDECESSOR's
-    `chain` instead (the related-but-not-spawned rule); the `## Links` section follows
-    from that edge, you do not write it by hand.
-- **Rule of thumb:** if the intent could exist without its parent, make it a root; only set
-  `--sources` when it was genuinely created from / emerged from that intent's lifecycle.
-  Topic similarity alone is not a `sources` edge.
-
-When a branch intent exists because a late ruling arrived AFTER its parent was already
-completed (the owner's late-ruling rule), the parent is restored to v1 via
-`scripts/restore-intent-v1`, never by a hand-run `git checkout`/revert. See
-`plastic-conventions > references/maintenance-and-revisions.md`, WORK vs MAINTENANCE, for the
-rule and the tool.
-
-`## Links` is a DERIVED view of `sources`/`chain`. Never hand-write a `## Links` line; add the
-frontmatter edge and reproject. Links are decided by context influence (a `chain` edge has a high
-bar: the candidate's context must materially help deliver this intent), not by shared files or a
-similarity score. To gather candidates with their context and record an edge, use the
-`scripts/link-suggest` and `scripts/project-links`.
-
-Read `../plastic-conventions/references/knowledge-graph.md` for the full linking doctrine: the
-tiers of influence, sources versus chain, and how the `## Links` projection is derived. This path
-resolves relative to this skill's own installed directory.
-
-### 4. Determine Intent Properties
-
-Ask or infer from context:
-- **intent**: one-line description
-- **slug**: short hyphenated handle for the directory name
-- **author**: `human` | `claude-code` | other agent name
-- **sources**: the direct ascendant(s) this intent was created from / emerged from the
-  lifecycle of (formation, not topic similarity), e.g., `4a1`. For a project intent,
-  include the governing intent's id. A branch's structural parent is ALSO recorded in
-  `sources` (the ID carries it for the human/paper tree, `sources` carries it for
-  software), which `new-intent` does automatically (see `new-intent:126`).
-- **tags**: freeform list (use `project-<name>` for project membership)
-
-`chain` carries what this intent spawns AND related-but-not-spawned successors it leads to;
-it starts empty and is populated later. See
-[`how-plastic-sources-and-chains-intents.md`](https://github.com/zalom/plastic/blob/main/docs/concepts/how-plastic-sources-and-chains-intents.md) for the full model.
-Place the intent in `## Active` or `## Future` in INDEX.md (status is
-convention-derived, not a frontmatter field).
-
-### 5. Scaffold via new-intent (single call)
-
-Delegate id allocation, directory and file creation, the born-complete intent
-file, the sentinel placeholder lifecycle files, the reciprocal file links, and
-self-validation to one `new-intent` invocation. Do NOT hand-author any of these
-files.
-
-```bash
-ruby ~/.plastic/scripts/new-intent \
-  --store "<STORE>" --intent "<one-line>" --slug "<slug>" \
-  [--parent "<parent_id>"] [--author "<author>"] \
-  [--sources "id,id"] [--tags "project-<slug>,tag"]
-```
-
-`new-intent` allocates the Folgezettel id (root, or a branch of `--parent`),
-creates `<STORE>/<id>--<slug>/` plus `actions/` and `resources/`, renders the
-born-complete `<id>--<slug>.md` from the intent template, writes the sentinel
-placeholder `spec.md`/`plan.md`/`checklist.md`/`outcome.md` (each marked
-`<!-- plastic:placeholder -->` so no stage detector reads them as reached), wires
-the reciprocal `[[id]]` links, and self-validates (frontmatter plus the sanctioned
-`##` sections). It prints the created directory path and exits 0.
-
-It does NOT touch INDEX.md, git, or project creation: those stay in this skill
-(steps 6 to 9 below).
-
-If `new-intent` exits non-zero, read the stderr report and fix the inputs (slug,
-intent, sources). Do not commit or announce an intent that did not scaffold
-cleanly, and do not work around the failure by hand-writing the files.
-
-### 6. If Implementation Intent Spawns a Project
-
-When the user says "start building" or the plan calls for a new project, invoke the
-`plastic-project-creating` skill; it owns project directory creation, AGENTS.md
-population, projects.yml registration, store provisioning, and the auto-commit of
-both stores. Add `project-<slug>` to this intent's `tags` array either before
-invoking it or as part of that skill's handoff.
-
-### 7. Update INDEX.md
-
-- **Global intents:** update `~/.plastic/INDEX.md`
-- **Project intents:** no global INDEX.md change (tactical intents are project-scoped)
-
-Add to `## Active` (or `## Future`) and appropriate cluster.
-
-### 8. Auto-commit
-
-```bash
-cd <store-root> && git add . && git commit -m "feat: create intent ID - [name]"
-```
-
-### 9. Announce
-
-"Created intent ID - [name]. Placed in: [Active|Future]. Store: [global|project:<slug>|local]."
-
-## References
-
-- Read `references/lifecycle.md` for the full What→Why→How→Exec stage detail, filesystem-as-schema conventions, and creating-intent step-by-step
-- Read `references/wikilinks.md` for the wikilink syntax table when adding `## Links` to intents

package/skills/intent-creating/evals/evals.json

@@ -1,72 +0,0 @@
-{
-  "skill_name": "plastic-intent-creating",
-  "notes": "Intent 68. Scope: output-quality for the sources-vs-chain construction rules (D1/D2). Asserts the related-but-not-spawned case produces NO sources plus a predecessor chain link and a ## Links mirror, contrasted with the created-from case (true ascendant -> --sources set, reciprocal chain). The machine-checkable half lives in test/new_intent_test.rb (test_sources_path_gets_child_in_chain_frontmatter); this file documents the agent-facing scenario for skill evaluation and is NOT run by bin/test.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Create an intent for adding a retry policy to the uploader. It's related to intent 41 (the upload pipeline work) but it's independent: it did not come out of intent 41's lifecycle.",
-      "expected_output": "A new root intent is created with EMPTY sources (it was not created from 41). The relation is recorded on the PREDECESSOR: intent 41 gains the new intent's id in its frontmatter chain, and a [[<new-id>]] wikilink is added to intent 41's ## Links. The new intent is NOT given 41 in --sources (the related-but-not-spawned rule). No false symmetry: 41 keeps the new id on chain with no reciprocal sources.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "new intent sources is empty",
-          "observed": "sources: []",
-          "result": "pass"
-        },
-        {
-          "type": "code",
-          "check": "predecessor 41 chain includes new id",
-          "observed": "41.chain includes <new-id>",
-          "result": "pass"
-        },
-        {
-          "type": "code",
-          "check": "predecessor 41 ## Links has [[<new-id>]] mirror",
-          "observed": "[[<new-id>]] present in 41 ## Links",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Create an intent that is the direct continuation of intent 41: it emerged from intent 41's lifecycle and could not exist without it.",
-      "expected_output": "Because the new intent was genuinely CREATED FROM 41 (D1), it carries 41 in --sources (or branches from 41, which folds 41 into sources via the redundant-explicit rule). The reciprocal I1 backlink lands: intent 41's frontmatter chain gains the new intent's id. This is the created-from case, contrasted with the related-but-not-spawned case in eval 1.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "new intent sources includes 41",
-          "observed": "sources includes 41",
-          "result": "pass"
-        },
-        {
-          "type": "code",
-          "check": "predecessor 41 chain includes new id (I1 reciprocity)",
-          "observed": "41.chain includes <new-id>",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "QMD is present. The user says: create an intent to add retry to the uploader.",
-      "expected_output": "Before allocating the id / scaffolding, runs `ruby ~/.plastic/scripts/qmd-sync search \"add retry to the uploader\"` to surface a near-duplicate or true predecessor, then opens the authoritative intent file for any hit (reusing a near-duplicate or setting a real predecessor in --sources). No-op fallback to INDEX.md / file scan when QMD is absent.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "qmd-sync search is run before id allocation; authoritative file opened for any hit; informs reuse / --sources",
-          "observed": "SKILL.md (or agent file) carries the QMD-first step: run qmd-sync search before grep/Read, then open the authoritative file; no-op fallback when QMD is absent",
-          "result": "pass"
-        }
-      ]
-    }
-  ]
-}

package/skills/intent-creating/references/lifecycle.md

@@ -1,81 +0,0 @@
-# Building an Intent — Full Lifecycle Detail
-
-## What → `## Intent` section
-
-The desire. One paragraph. What the human or agent wants.
-This exists from the moment the intent is created.
-
-**Deliverable:** `{ID}--{slug}.md`
-
-## Why → `## Context` + `### Decisions` sections
-
-Why this intent exists. Grows over time through brainstorming and exploration.
-
-- **Context** — what we knew going in + what we decided along the way
-- **Decisions** — main premises derived from Context plus decisions from brainstorming/grilling
-- Decisions are Why-level: "status belongs on actions because multiple workstreams", not How-level: "use ACTION_N.md files"
-
-**Deliverable:** `spec.md` (consolidated specification from Context + Decisions + brainstorming)
-
-## How → Planning and preparation
-
-Research decisions, create the implementation plan, define actions.
-
-**Deliverable:** `plan.md` + `actions/` + `checklist.md` (execution registry with checkboxes covering all actions)
-
-## Exec → Execute actions
-
-Execute actions from the plan, track progress via checklist.
-
-**Deliverable:** `outcome.md` (detailed result). `## Outcome` in intent.md = short summary written as last step.
-
-## `## Insights` — Append-only work log
-
-Captured throughout ALL stages. One-liner bullet points.
-Never modified, only appended.
-
-Tracks: stage transitions, decisions, shifts, blocks, cancellations, material for future intents.
-This is how execution is tracked. When this intent completes, Insights
-is where to look for what comes next. New intents spawned from this one,
-plus related-but-not-spawned successors it leads to, appear in the `chain`
-field.
-
-## `## Links`
-
-The human-readable projection of the local knowledge graph, mirroring the
-frontmatter exactly. Each entry is `- [[id--slug|<target's full intent: text>]]`,
-a clickable `id--slug` wikilink target with the target intent's full `intent:`
-text as the label (cross-store targets render
-`- [[store:id--slug|<target's full intent: text>]]`). Ordering is mandatory: all
-`sources` first (top), then all `chain`, frontmatter order preserved within each
-group. Sources never appear at the end. No source/chain tags, no sub-grouping. An
-intent with empty `sources` and `chain` carries the empty-state comment. Counterpart
-to the frontmatter `sources` / `chain` edges, for Obsidian graph navigation.
-
-## Conventions — Filesystem as Schema
-
-State is derived from what exists, not from what's declared.
-
-| Convention | Signal |
-|---|---|
-| No `## Context` | Intent is fleeting (quick capture, non-actionable) |
-| `## Context` has content | Intent is permanent (developed, actionable) |
-| `## Outcome` has content | Intent is done |
-| `## Insights` has `(autonomous)` entries | Intent is/was being delivered autonomously |
-
-### Transitions
-
-- Fleeting → permanent: add `## Context` (one-way, also makes it actionable)
-- There is no separate "non-actionable → actionable" transition — permanence implies actionability
-- Even research intents are actionable: the research itself is the action, the conclusion is the outcome
-
-## Creating an Intent — Full Steps
-
-1. Determine the target store: `~/.plastic/store/` for global intents (default), `~/.plastic/projects/{slug}/store/` for project intents
-2. Decide branch vs root (this sets whether you pass `--parent`)
-3. Scaffold with one call: `ruby ~/.plastic/scripts/new-intent --store <store> --intent "<one-line>" --slug <slug> [--parent <id>] [--sources id,id] [--tags ...]`. This allocates the id, creates the directory plus `actions/` and `resources/`, renders the born-complete intent file (frontmatter plus `## Intent`, `## Context`, `## Outcome`, `## Insights`, `## Links`), writes the sentinel placeholder lifecycle files, wires the reciprocal links, and self-validates.
-4. Update the appropriate `INDEX.md` — add to Active section and appropriate cluster
-
-The intent file is born complete with all five sanctioned `##` sections; the lifecycle files (`spec.md`/`plan.md`/`checklist.md`/`outcome.md`) are sentinel placeholders that read as "stage not reached" until an agent fills them and deletes the `<!-- plastic:placeholder -->` first line.
-
-Always scaffold through `new-intent` (or this skill). Never hand-author intent files: `new-intent` validates the file it writes (`scripts/validate-intent`) and `end-intent` checks it again at close, and hand-authoring is the bypass this contract is designed to remove.

package/skills/intent-creating/references/wikilinks.md

@@ -1,8 +0,0 @@
-# Wikilink Conventions
-
-| Syntax | Meaning |
-|--------|---------|
-| `[[ID]]` | Link to intent in same store (e.g., `[[1a1]]`) |
-| `[[ID\|display text]]` | Link with human-readable label |
-| `[[global:ID]]` | Link to intent in `~/.plastic/store/` |
-| `[[project-slug:ID]]` | Link to intent in `~/.plastic/projects/{slug}/store/` |

package/skills/intent-ending/SKILL.md

@@ -1,176 +0,0 @@
----
-name: plastic-intent-ending
-description: >
-  Wrap, finish, close, or mark an intent Done, delivered or abandoned. Use
-  when completing or abandoning an intent, when a checklist reaches 100
-  percent and Exec is finished, or when asked to "wrap this up".
-user-invocable: true
----
-
-# Intent Ending
-
-The one procedure every terminal transition routes through. Auto mode, the
-curator path, and releasing all call this skill (or its backing script,
-`scripts/end-intent`) for the mechanical close instead of restating the same
-prose three times. `abandoned` is the SAME procedure as `delivered`, not a
-failure branch: only outcome.md content and the INDEX section differ.
-
-Read `../plastic-conventions/references/completion-and-done.md` for what "intent done" means and
-the End-stage tail behind the steps below. This path resolves relative to this skill's own
-installed directory.
-
-## The 8 steps (0-7)
-
-| # | Step | Who does it |
-|---|---|---|
-| 0 | Precondition check | You, before touching outcome.md |
-| 1 | backfill spec/plan/action/outcome from the record, self-check, intent-file `## Outcome` summary | `scripts/end-intent` |
-| 2 | INDEX.md terminal move (Active -> Completed/Abandoned) | `scripts/end-intent` |
-| 3 | savepoint `Done` bookend | `scripts/end-intent` |
-| 4 | store auto-commit | `scripts/end-intent` |
-| 5 | disarm (worktree + lock) | `scripts/end-intent` (intent 188) |
-| 6 | QMD reindex, async, LAST | You |
-| 7 | EM-to-CTO report | You |
-
-Steps 1-5 are ONE callable script call, not several separate one-liners: this
-is exactly what the failure mode this intent fixes looked like (releasing hand
-authored the close in prose and dropped the savepoint bookend for two real
-deliveries; separately, one session delivered four intents back to back and
-never ran the old step-5 one-liner at all, intent 188). Never restate
-outcome/INDEX/savepoint/disarm prose inline again; call `scripts/end-intent`.
-
-### Step 0. Precondition (the record is what gets backfilled)
-
-Nothing refuses the close any more (the 1.x write-time gate and `end-intent`'s
-exit-6 structure gate were retired in 2.0, intents 302 and 308). What you leave
-on disk is what the record becomes, so before the call:
-
-1. Read checklist.md. Tick every item as it is actually performed, including
-   an item that describes the close itself: running this very procedure IS
-   what that item describes. An unchecked box is not a refusal, it is a
-   reported gap that lands verbatim in the backfilled `## Follow-ups`.
-2. Confirm every acceptance criterion in spec.md is verifiable (tests pass,
-   or the manual check described in its HOW line was actually run).
-3. Decide what you have to say. A spec.md, plan.md, action file, or outcome.md
-   left as the scaffold placeholder is written from the record by
-   `scripts/end-intent` (the intent file's `## Intent`, `### Decisions`, and
-   `## Insights`, the checklist, the diff on the intent's own worktree). A
-   file you wrote, even under a still-present sentinel, is never touched.
-   Write outcome.md yourself when the summary deserves more than the
-   `--outcome-summary` line; otherwise let the backfill carry it.
-
-### Step 1-5. Run `scripts/end-intent`
-
-Author outcome.md yourself when it deserves prose: copy `templates/outcome.md`,
-set the frontmatter to `disposition: delivered` or `disposition: abandoned`, and
-fill `## Summary`, `## Delivered`, `## Verification`, `## Follow-ups`. `## Delivered` is a
-`| Row | What |` table: one row per thing delivered, in plain wording a reader
-recognizes, not a method name or an implementation summary (that detail
-belongs in `## Summary`). Each row's label must appear as a standalone token
-in an action-file heading (`### S1 - ...` proves row S1); that heading's
-matrix rows become the row's Proven-by cell on `report-screen delivered`'s
-post-delivery screen. `## Needs you` is the literal None or a
-`| N | What | Why |` table. On abandon, `## Summary` states the abandonment reason and the trail (see Pivot
-below). A placeholder outcome.md is backfilled from the record instead, with the
-close's disposition and the `--outcome-summary` line as its summary. Also author
-the rich INDEX entry note now (a short line in the store's existing
-Completed/Abandoned convention: mode, what shipped or why it was
-abandoned, suite result, merge/spawn notes); content authoring stays with
-you, `--index-note` only appends what you write.
-
-Then call the script once:
-
-```bash
-ruby ~/.plastic/scripts/end-intent \
-  --store <store_path> --id <intent_id> --disposition delivered|abandoned \
-  --session "$CLAUDE_CODE_SESSION_ID" \
-  --outcome-summary "<one-line ## Outcome summary for the intent file>" \
-  --index-note "<rich Completed/Abandoned entry description>"
-```
-
-This does all of steps 1-5 in order: backfills every missing or placeholder
-spec.md, plan.md, action file, and outcome.md from the record (never a file
-you wrote), runs doctor's per-intent structure check and the outcome guard as
-a self-check that reports on stderr and proceeds (an unchecked box, a
-malformed intent file, a wrong-disposition outcome.md you wrote), stamps the
-intent file's `## Outcome` section, moves the INDEX.md
-line from `## Active` to `## Completed` or `## Abandoned` (dated today,
-idempotent, accepting either a real em dash or a plain hyphen as the id/
-title separator on read while always emitting the real em dash on write)
-with the `--index-note` text appended after the date so the entry stays
-rich, appends the savepoint `Done` bookend, commits the store repo, and
-disarms (releases the code worktree and clears `delivery.lock`, verified
-against the durable lock file on disk, never merely trusted). Omit
-`--index-note` for a thin id+date entry, add `--no-commit` when a separate
-commit step already covers the store (this never skips disarm), and
-`--dry-run` to preview steps 1-5 with no writes.
-
-A pre-flight lock guard runs before anything is written: it resolves the
-calling session (`--session`, else `CLAUDE_CODE_SESSION_ID`, else the
-existing lock's own recorded owner, else a no-op) and checks it against any
-existing `delivery.lock`. A live foreign session refuses the whole run
-(exit 4, nothing written); a stale foreign lock is reclaimed automatically
-(audited to savepoint.md) and the run proceeds as the new owner. Before
-removing the worktree, step 5 also refuses on an unexpectedly dirty code
-worktree (exit 5, naming the worktree path) rather than force-discarding
-uncommitted changes; pass `--discard-worktree-changes` only when you mean
-to override that deliberately.
-
-On the auto mode / curator path (no release), this single call performs the
-FULL disarm (plain worktree remove, since the branch survives for later
-reclaim). On a release-shipped path, `skills/releasing/SKILL.md` merges and
-removes the worktree FIRST (its own step 8, merge-then-remove) before ever
-calling this script, so by the time this call's step 5 runs, the worktree is
-already gone (a harmless no-op) and only the lock is left to clear,
-correctly, for the first time on that path (D7).
-
-Exit codes: 0 success (the intent is closed AND its delivery lock is gone);
-1 a usage or resolution failure, OR an INDEX id that resolves to neither
-`## Active` nor the terminal section; 3 steps 1-4 already committed
-but disarm could not verify the lock is gone afterward (run `/plastic-doctor
-check the lock status`); 4 a live foreign session holds the lock (back off);
-5 the code worktree is dirty (commit/stash first, or pass
-`--discard-worktree-changes` deliberately).
-
-### Step 6. QMD reindex, LAST
-
-Only after step 5 has released the worktrees and cleared the lock, so the
-index never references state about to disappear:
-
-```bash
-ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async
-```
-
-No-op when QMD is absent. Runs in the background so it never blocks the
-turn.
-
-### Step 7. EM-to-CTO report
-
-Brief the human like an engineering manager to a CTO: impact and risk first,
-in plain language, the decision left to them (merge, release, or accept).
-See `outcome.md` for the details; do not restate it verbatim.
-
-## Abandoned is the same procedure
-
-`disposition: abandoned` runs the identical steps 0-7. The only differences
-are outcome.md content (Summary states why this was abandoned, not what was
-delivered) and the INDEX target section (`## Abandoned` instead of
-`## Completed`). Never branch the mechanical steps by disposition; the
-script already does that internally.
-
-## Mid-flight pivot
-
-When the work that shipped differs from what spec.md or plan.md originally
-called for, do not retcon those documents. Record the decision once in
-`## Insights`, then let outcome.md carry the truth of what actually
-happened, including the abandoned trail when part of the work was dropped
-mid-flight. outcome.md is truth of delivery; spec and plan stay the
-historical record of what was planned.
-
-## Routing
-
-`plastic-releasing`, `plastic-auto`, and `plastic-intent-executing` all delegate their mechanical
-close to this skill (or call `scripts/end-intent` directly for steps 1-5).
-None of them restate the outcome/INDEX/savepoint/disarm prose inline any
-more; if you find one that does, that surface has drifted and should route
-here instead.