@zalom/plastic 1.14.0 → 2.0.0-alpha.1

package/skills/intent-continuing/SKILL.md

@@ -1,103 +1,145 @@
 ---
 name: plastic-intent-continuing
 description: >-
-  Use when a specific intent is named to resume, by id or by description, or on `continuing
-  --intent {id}`. Reads that intent's savepoint ledger and hands off to plastic-intent-starting.
-  The general "continue" / new-session triggers belong to the plastic-continuing router, not
-  here, so a bare "continue" does not settle on this skill directly. Boot (health check, core
-  context, version, statusline) is owned by the SessionStart hook, not this skill. Does not
-  drive work autonomously (that is plastic-auto).
+  The front door for resuming work. Use when the user says "continue", "resume", "pick up
+  where we left off", "where was I", "what should I work on", names a specific intent to
+  resume (by id or description, or `--intent {id}`), or names a roadmap or delivery batch to
+  resume (`--roadmap {slug}`, "where is the roadmap", "where did that batch land"). Presents
+  state and resumes at the last delivered station; it never asks auto or guided, never boots
+  (the SessionStart hook owns boot), and never drives work autonomously (plastic-auto does).
+  Absorbs the former continuing, project-continuing, and roadmap-continuing skills and the
+  read half of the former intent-starting skill (intent 304).
 user-invocable: true
 ---
 
-# Continuing (intent route)
-
-`plastic-intent-continuing` is the intent route of `plastic-continuing`. It resumes ONE
-specific intent by its savepoint ledger, then hands off to `plastic-intent-starting`. It does
-NOT land on a dashboard and does NOT execute work autonomously (that is `plastic-auto`); both
-of those are other routes' jobs.
-
-**Boot is not this skill's job.** The `hook-session-start` hook already runs by construction on
-every session start: it runs the core health check (`doctor --core`), primes `PLASTIC.md` +
-store/project state, and prints the `Plastic Core loaded - v{version}` banner. The
-`plastic-statusline` hook sets the statusline. So by the time this skill runs, core is loaded
-and healthy (or the banner already warned otherwise). This skill picks up from there and
-resumes the named intent. This is the seam future continue-flags build on (see [[39]]).
-
-## When to Use
-- A specific intent is named to resume, by id or by description
-- `continuing --intent {id}`
-
-## Determine Store
-
-1. **Global store** - `~/.plastic/INDEX.md` exists → global mode.
-2. **Local store** - a project store under `~/.plastic/projects/{slug}/` whose registered
-   path (in `~/.plastic/projects.yml`) matches the current working directory → project mode.
-   The SessionStart hook already detects this; here you only need the slug to scope the
-   named intent's store.
-3. If neither exists → announce "No Plastic store found. Run /plastic-install."
-
-## Conditional Ledger-Resume
-
-Fires ONLY when the user explicitly asks to continue a SPECIFIC intent, or an agent is
-instructed to continue one. It is not part of every boot.
-
-QMD-first (when available): when the user names the intent by description rather than id, before
-scanning the store with grep/Read run `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to
-surface the candidate intent, then open the authoritative intent file for the hit you resume. The
-command is a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
-
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract behind the resume below. This path resolves relative to this skill's own
-installed directory.
-
-For that intent's directory:
-
-1. **Read `savepoint.md` FIRST (intent 81).** It is a deterministic, append-only ledger
-   (one line per event, newest at the bottom): `{utc-iso8601}  {Stage}  {milestone}`. Classify
-   the state from the **last line** alone, then verify ONLY that line's artifact. The bookends
-   are fixed: first line `What  created`, last line either a cycle position or
-   `Done  delivered|abandoned`.
-
-   | Last line | State | Verify only |
-   |---|---|---|
-   | `What  {id}--{slug}.md` | born / parked | intent file exists |
-   | `Why  started` | Why entered, no spec yet | spec.md not yet real; continue Why |
-   | `Why  spec.md created` | Why done | spec.md present; continue to How |
-   | `How  started` / `How  plan.md created` | How in progress | plan.md; continue How |
-   | `How  checklist.md created` / `Exec  started` | ready for / in Exec | plan.md + checklist.md present; continue Exec |
-   | `Exec  outcome.md created` | Exec done | outcome.md present; ready to complete |
-   | `Done  delivered` / `Done  abandoned` | terminal | do NOT cycle-resume; INDEX is authoritative |
-
-2. **Verify the stage file.** Confirm only the last line's artifact exists and is non-empty
-   (ledger `How  plan.md created` → `plan.md` must be present and non-empty). Do not re-probe
-   every lifecycle file.
-3. **Drift handling.** If the ledger's last line disagrees with files-on-disk, rebuild the
-   ledger from filesystem state and note the correction. A rebuilt ledger is the file-landing
-   skeleton (no `started`/`Done` lines), which still pins cycle position:
+# Continuing: the front door for resuming work
+
+One skill with three routes. It reads state and presents it; the work itself continues in
+whatever mode the session is in (direct by default, `plastic-auto` when the owner says auto).
+There is no lock to take and no mode to ask here: locks exist only for auto teams, and the
+mode is the owner's word, not a question this skill puts.
+
+**Boot is not this skill's job.** `hook-session-start` runs on every session start: the core
+health check (`doctor --core`), `PLASTIC.md` and store or project state, the
+`Plastic Core loaded - v{version}` banner. By the time this skill runs, core is loaded and
+healthy or the banner already warned.
+
+## Route
+
+| Args or context | Route |
+|---|---|
+| `--intent {id}`, or the user names one specific intent to resume (by id or description) | Intent route (below) |
+| `--roadmap {slug}`, or the user asks to continue or resume a roadmap or delivery batch | Roadmap route (below) |
+| bare "continue", "resume", "what should I work on", or no target (the default) | Project route (below) |
+
+State the chosen route in one line before doing anything ("Landing on the project board: no
+specific intent or roadmap named.").
+
+## Determine store
+
+1. A project store under `~/.plastic/projects/{slug}/` whose registered path in
+   `~/.plastic/projects.yml` matches the working directory means project mode; the
+   SessionStart hook already detected this, the slug scopes the reads below.
+2. Otherwise the global store, `~/.plastic/store/`.
+3. Neither exists: announce "No Plastic store found. Run /plastic-install." and stop.
+
+## Project route: land on the board
+
+Land on the Markdown board through the `plastic-dashboard` skill; rendering belongs there.
+Run the data payload and fill the matching template:
+- project loaded: `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
+- otherwise (the global fallback): `ruby ~/.plastic/scripts/dashboard.rb continue --data`
+
+Fill the template from `plastic-dashboard`'s `templates/` and present the filled Markdown in
+your reply, every time: tool-call stdout and hook context are invisible to the user. Read
+`references/board-fill.md` for the fill mechanics and the store-health line when filling the
+board. The board load runs the scoped store check (`doctor --store <scope>`); its result
+arrives in the payload as `store_health` and is shown as one line of data, never a blocker.
+
+Priority order on the board: active intents first, then project context (governing plus
+tactical intents in a registered project), then stale future intents for triage, then fresh
+future intents as next work. A future intent older than `stale_threshold_days` (default 3) is
+surfaced for triage without action: activate, abandon, or leave. Activating moves it to
+`## Active` in `INDEX.md` and auto-commits. The board's ranked next-work order is computed by
+`dashboard.rb`; cite the rule names only (Effort, Value, Flags, Override, Caps) and read
+`plastic-dashboard`'s `references/classification.md` for their definitions.
+
+When the tier root (the directory holding `INDEX.md`) has a mid-flight roadmap
+(`ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <root>/roadmaps` reports a `state`
+other than `none`), say so in one line and offer the roadmap route; the board still presents
+project state and stops.
+
+Then stop: "here is the state, what next?". Do not start executing work. When the user names
+an intent, take the intent route.
+
+## Intent route: resume one intent from its ledger
+
+QMD-first when the intent is named by description: run
+`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to find the candidate, then open the
+authoritative intent file. The command is a no-op when QMD is absent; fall back to
+`INDEX.md`.
+
+If the intent is terminal (`## Completed` or `## Abandoned` in `INDEX.md`): report only.
+Summarize its `outcome.md` and ask what is next; never reopen it.
+
+For a live intent's directory:
+
+1. **Read `savepoint.md` first.** It is a deterministic, append-only ledger, one line per
+   event, newest at the bottom: `{utc-iso8601}  {Stage}  {milestone}`. Classify the station
+   from the last line alone (the table in `references/boarding-matrix.md`, read when
+   classifying), then verify only that line's artifact is real (sentinel-aware:
+   `Savepoint.stage_file_present?`). Do not re-probe every lifecycle file.
+2. **Drift.** When the last line disagrees with the files on disk, rebuild the ledger from
+   disk and note the correction. A rebuilt ledger is the file-landing skeleton, which still
+   pins the station:
    ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'
+   ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'
    ```
-4. **Derive the next step:**
-   - First unchecked item in `checklist.md` if it exists, else
-   - "advance to the next lifecycle stage" (e.g. ledger shows Why/spec.md → next is How).
-   - The newest `## Insights` entry supplies human-readable context (Insights are
-     append-only, newest at the bottom).
-5. **Announce, then hand off to `plastic-intent-starting`:**
+3. **Read the hand-off.** When `resources/handoff--*.md` exists, its newest file is the prior
+   session's own account of where things stand; read it after the ledger, never instead of it.
+4. **Derive the next step:** the first unchecked item in `checklist.md` when it exists, else
+   the next thing the station needs (see the matrix). The newest `## Insights` entry supplies
+   the human-readable context; an entry marked `(autonomous)` means an auto team was
+   delivering it, so say so and offer to hand back to `plastic-auto`.
+5. **Announce, then continue at that station:**
    ```
    Resuming intent [ID] - [name]
-   Store: [global | project:<slug> | local]
-   Stage: [from ledger last line]
-   Next step: [first unchecked checklist item | advance to <stage>]
-   Context: [newest ## Insights entry]
-   Drift: [none | ledger rebuilt from filesystem]
+   Store: [global | project:<slug>]
+   Station: [from the ledger's last line]
+   Next step: [first unchecked checklist item | what the station needs]
+   Context: [newest ## Insights entry | hand-off summary]
+   Drift: [none | ledger rebuilt from disk]
    ```
-   Hand off to `plastic-intent-starting`: it takes the lock, boards at this station, and is
-   where the single "auto or guided?" ask for the intent route lives, asked there exactly
-   once and never duplicated here. Its auto branch is the one that hands off to `plastic-auto`;
-   this skill never hands to `plastic-auto` directly.
+   Then continue the work in the session's current mode. In auto mode the running team
+   already holds the delivery lock; if a lock is held by a session that is gone, the
+   `plastic-doctor` skill's lock section repairs or reclaims it.
+
+## Roadmap route: resume the mid-flight roadmap
+
+1. Resolve the tier root (project or global) and run the shared reader in which mode:
+   ```bash
+   ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <root>/roadmaps --which
+   ```
+   Read `state` and the winning `roadmap`. A `tie` lists `tie_candidates` to present side by
+   side and let the user pick; never pick silently. The reader ranks liveness the way
+   `references/liveness-ranking.md` describes (read it when a ranking needs explaining): a
+   `delivering` or `blocked` entry wins, else the newest ledger or `## Log` timestamp.
+   `roadmaps/<slug>.savepoint.md` is a derived signal read here, never a status field;
+   `INDEX.md` stays the sole status writer.
+2. **Present state:** the roadmap's `## Goal`, the current batch with each entry's mirrored
+   status, the ledger's newest line beside the newest `## Log` line. Read
+   `../plastic-conventions/references/roadmaps.md` for the file format and the status-mirror
+   rule when a roadmap file needs interpreting.
+3. Then continue with the next dispatchable entry in the session's mode: direct work on it,
+   or `plastic-auto` when the owner says auto. The coordinator that drives a batch appends
+   to `roadmaps/<slug>.savepoint.md` at its dispatch, merge, park, and handoff points with
+   `ruby ~/.plastic/scripts/roadmap-savepoint append`; this skill only reads it.
 
 ## References
 
-- Read `references/context-management.md` for the save/continue protocol and for
-  debugging the resume flow.
+| Trigger | Read |
+|---|---|
+| Filling the board on the project route | `references/board-fill.md` |
+| Classifying the station from the ledger's last line | `references/boarding-matrix.md` |
+| Explaining why one roadmap ranked above another | `references/liveness-ranking.md` |
+| Saving or restoring context across a long session, or debugging a resume | `references/context-management.md` |

package/skills/intent-continuing/references/boarding-matrix.md

@@ -0,0 +1,34 @@
+# Boarding matrix: which station a resume lands at
+
+The station is derived from `savepoint.md`'s last line plus the real artifacts on disk.
+Classify from the last line alone, then verify only that line's artifact is real
+(sentinel-aware). On drift, rebuild the ledger from disk and note it.
+
+| savepoint last line | latest delivered | lands at | continue with |
+|---|---|---|---|
+| `What  {id}--{slug}.md` (born) | What | **Why** | the thinking conversation (`plastic-intent-speccing`) or direct work |
+| `Why  started` (spec still sentinel) | What | **Why** | continue the conversation; rulings land as insights |
+| `Why  spec.md created` | Why | **How** | the action files, `plan.md`, `checklist.md` |
+| `How  started` / `How  plan.md created` | (How in progress) | **How** | finish `plan.md` and `checklist.md` |
+| `How  checklist.md created` / `Exec  started` | How | **Exec** | do the work, tick the checklist |
+| `Exec  outcome.md created` | Exec | **ready to complete** | the ending procedure (`plastic-intent-ending`) |
+| `Done  delivered` / `Done  abandoned` | terminal | **report only** | immutable; ask what is next |
+
+## Per-station behaviour (what "continue" means)
+
+- **Why**: continue the conversation, or run the work directly when the request is already
+  clear; every ruling is recorded as it lands.
+- **How**: write or finish the action files, `plan.md`, and `checklist.md`.
+- **Exec**: verify what is delivered, then continue (or restart) the delivery or research.
+  The first unchecked `checklist.md` item is the next step; the newest `## Insights` entry
+  supplies the context.
+- **ready to complete**: `outcome.md` is real; run the ending procedure.
+- **Done**: terminal. Report the outcome, ask what is next. Never reopen; `INDEX.md` is
+  authoritative.
+
+## Notes
+
+- A Plastic 1.x ledger may carry a `Tier  <letter>` line under the `Why  spec.md created` line
+  (the intent tier was removed in 2.0, intent 304). It is inert: skip it when classifying.
+- An `## Insights` entry marked `(autonomous)` means an auto team was delivering the intent;
+  say so and offer to hand back to `plastic-auto`.

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

@@ -20,9 +20,9 @@ step looks stale):
 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 has drifted: rebuild it rather than hand-editing:
-   `ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'`
+   `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-project-continuing`; this file no longer duplicates it.
+`plastic-intent-continuing`; this file no longer duplicates it.

package/skills/intent-creating/SKILL.md

@@ -12,7 +12,7 @@ user-invocable: true
 - User explicitly says "new intent" or "create intent"
 - An agent discovers work needed during implementation
 
-## Determine Tier
+## 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/`.
 
@@ -79,7 +79,7 @@ rule and the tool.
 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
-`plastic-intent-linking` skill and `scripts/link-suggest`.
+`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

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

@@ -78,4 +78,4 @@ State is derived from what exists, not from what's declared.
 
 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: the write-time create gate blocks an incomplete or malformed intent file, and hand-authoring is the bypass this contract is designed to remove.
+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-ending/SKILL.md

@@ -24,7 +24,7 @@ installed directory.
 | # | Step | Who does it |
 |---|---|---|
 | 0 | Precondition check | You, before touching outcome.md |
-| 1 | outcome.md + intent-file `## Outcome` summary | `scripts/end-intent` |
+| 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` |
@@ -39,45 +39,36 @@ 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 gate is section-blind, not selective)
+### Step 0. Precondition (the record is what gets backfilled)
 
-`Bridge.check_gate` (scripts/lib/bridge.rb) is LIVE code already wired into
-the write-time hook. Its outcome.md rule is a blind scan of the WHOLE
-checklist.md: `content.scan(/^- \[ \]/)` counts every unchecked box, in
-every section, with no awareness of which section a box lives in. ANY
-unchecked box anywhere blocks the outcome.md write; there is no exemption
-for orchestrator-owned or completion-tracking items.
+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, so tick it at the moment you begin the close,
-   before authoring outcome.md. By the time outcome.md is written,
-   checklist.md must read 100 percent checked; there is no other way past
-   the gate.
+   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. The structure gate (intent 222) now enforces this: `scripts/end-intent`
-   refuses with exit 6 and names the exact unchecked box (or any other
-   structural gap: intent-file validity, lifecycle-artifact presence,
-   `## Links` projection). On a refusal, fix via the OWNING tool, never a
-   hand edit of the check's own output:
-   - checklist/outcome content - finish it yourself, the same as before.
-   - links projection - run
-     `ruby ~/.plastic/scripts/maintenance-run --tool project-links --intent <id> --apply`.
-   - a savepoint issue - advisory only (WARN, never blocks): run
-     `plastic-intent-savepoint` to rebuild via `Bridge.rebuild_savepoint` if
-     you want it clean, but it never refuses the close on its own.
-   Then re-run `scripts/end-intent`.
+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`
 
-First author outcome.md for real (never leave the scaffold placeholder in
-place): copy `templates/outcome.md`, set the frontmatter to
-`disposition: delivered` or `disposition: abandoned`, and fill `## Summary`,
-`## Delivered`, `## Verification`, `## Follow-ups`. On abandon, `## Summary`
-states the abandonment reason and the trail (see Pivot below). Also author
+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`. 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/tier, what shipped or why it was
+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.
 
@@ -91,9 +82,11 @@ ruby ~/.plastic/scripts/end-intent \
   --index-note "<rich Completed/Abandoned entry description>"
 ```
 
-This does all of steps 1-5 in order: guards outcome.md (a missing or
-still-placeholder file is caught by the structure gate first and exits 6; a
-wrong-disposition file exits 2; either way it authors nothing), stamps the
+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/
@@ -127,8 +120,7 @@ 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; 2 the outcome.md guard refusing (fix
-outcome.md and re-run, nothing was written); 3 steps 1-4 already committed
+`## 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
@@ -171,8 +163,7 @@ historical record of what was planned.
 
 ## Routing
 
-`plastic-releasing`, `plastic-auto`, `plastic-intent-executing`, the curator
-agent, `store-curating`, and `store-indexing` all delegate their mechanical
+`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

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

@@ -7,11 +7,11 @@
       "scope": "behavior",
       "set": "train",
       "prompt": "checklist.md has one unchecked non-completion item. Try to complete the intent.",
-      "expected_output": "Defers to the existing Bridge.check_gate hard gate rather than writing outcome.md; tells the user to finish the checklist item first instead of fighting the deny.",
+      "expected_output": "Ticks or finishes the item before calling scripts/end-intent, because an unchecked box is reported by the structure self-check and lands verbatim in the backfilled Follow-ups; never a refusal (the write-time gate was removed in 2.0, intents 302 and 308).",
       "files": [],
       "assertions": [
-        { "type": "human", "check": "SKILL.md Step 0 states the gate blocks outcome.md while unchecked non-completion items remain, and instructs finishing the checklist rather than attempting the write", "result": "expect-pass" },
-        { "type": "code", "check": "Bridge.check_gate(intent_dir, 'outcome.md') returns a non-nil block reason when checklist.md has an unchecked '- [ ]' item (scripts/lib/bridge.rb)", "result": "pass" }
+        { "type": "human", "check": "SKILL.md Step 0 states that nothing refuses the close, that an unchecked box is a reported gap landing in Follow-ups, and instructs finishing the checklist before the call", "result": "expect-pass" },
+        { "type": "code", "check": "scripts/end-intent exits 0 on an unchecked '- [ ]' item and prints 'structure check: intent_checklist_complete' (test/end_intent_test.rb)", "result": "pass" }
       ]
     },
     {
@@ -53,7 +53,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Start work on intent 87.",
-      "expected_output": "Does NOT activate plastic-intent-ending; this is a boarding request (plastic-intent-starting), the opposite end of the lifecycle from a close.",
+      "expected_output": "Does NOT activate plastic-intent-ending; this is a resume request (plastic-intent-continuing), the opposite end of the lifecycle from a close.",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-ending", "result": "expect-pass" }

package/skills/intent-executing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plastic-intent-executing
-description: Use when you have a written implementation plan to execute. Default mode is subagent-driven (at L a fresh subagent per task with two-stage review, at S and M one executor dispatch for the whole consolidated action). Fallback mode is inline execution for environments without subagent support. If superpowers:subagent-driven-development or superpowers:executing-plans are available, delegates to them.
+description: Use when you have a written implementation plan to execute. Default mode is subagent-driven (one executor dispatch for the whole consolidated action, tests first, reviewed by risk). Fallback mode is inline execution for environments without subagent support. If superpowers:subagent-driven-development or superpowers:executing-plans are available, delegates to them.
 user-invocable: true
 ---
 
@@ -8,7 +8,7 @@ user-invocable: true
 
 ## Overview
 
-Load plan from the active intent's `plan.md`, execute all tasks, review per the tier gate below, report when complete.
+Load plan from the active intent's `plan.md`, execute all tasks, review as below, report when complete.
 
 ## Step 0: Sync Worktree First
 
@@ -40,12 +40,9 @@ If `superpowers:subagent-driven-development` is available as a skill, delegate t
 - Superpowers skills respect "user preferences for plan/spec location"; Plastic IS that preference
 
 ### Subagent-Driven (Default)
-Dispatches subagents to do the work. The controller never implements. It dispatches, reviews, and tracks progress. How many dispatches it makes depends on the tier stamped at the top of `spec.md` (the `Tier:` line, the single authoritative record). `plan.md` carries a bold `**Tier:**` field copied from it, a convenience only:
+Dispatches subagents to do the work. The controller never implements. It dispatches, reviews, and tracks progress. One executor dispatch implements the whole consolidated action from `plan.md`, the action file's failure-mode matrix, and `checklist.md` in one pass, tests first: the matrix's tests are committed red before the code. Several independent action files are handed to the same executor in order; they are not a reason for a per-task review loop (removed in 2.0, intent 307).
 
-- **S or M:** one executor dispatch implements the whole consolidated action from `plan.md` plus `checklist.md` in one pass. There is no per-task implementer-then-two-reviewers loop.
-- **L:** a fresh subagent per task, and a two-stage review after each task: spec compliance first, then code quality.
-
-The final independent review in Step 3 runs at every tier. It is a separate agent with fresh context, and it is never the maker.
+The post-execution review in Step 3 runs by risk (the rule lives in the auto skill). When it runs, the reviewer is a separate agent with fresh context, never the maker. The plan itself is reviewed before code by the adversarial plan reviewer (`plan-reviewer-prompt.md`), dispatched by the lead at How.
 
 ### Inline (Fallback)
 Executes tasks sequentially in the current session. Use when subagents aren't available or user explicitly requests inline mode.
@@ -62,46 +59,15 @@ Run Step 0 (Sync Worktree First) before this step.
 
 ### Step 2: Execute Each Task
 
-Read the `Tier:` line stamped at the top of `spec.md` first (the authority), then follow the matching branch. `plan.md`'s bold `**Tier:**` field is a convenience copy of the same value, useful when `spec.md` is not already open.
-
-#### At S or M: one executor dispatch
-
-Dispatch ONE executor subagent and give it the whole delivery: every task's full text from `plan.md` (pasted in, never a file reference), the checklist items it must tick, the project context from CLAUDE.md, and the active intent context from `{ID}--{slug}.md`. In auto mode this is the `plastic-executor` agent; elsewhere use the `implementer-prompt.md` template. The executor implements the consolidated action in order, ticks each item as it lands (see `## Tick-as-you-land`), and drives the test suite green.
+Dispatch ONE executor subagent and give it the whole delivery: every task's full text from `plan.md` (pasted in, never a file reference), every action file with its failure-mode matrix, the checklist items it must tick, the project context from CLAUDE.md, the active intent context from `{ID}--{slug}.md`, and the worktree path. In auto mode this is the `plastic-executor` agent; elsewhere use the `implementer-prompt.md` template. The executor writes the matrix's tests and commits them red, implements the consolidated action in order, ticks each item as it lands (see `## Tick-as-you-land`), and drives the test suite green.
 
 Read its response by code:
-- DONE or DONE_WITH_CONCERNS → proceed to Step 3. Run no per-task spec review and no per-task quality review at these tiers; Step 3's final review covers the work.
+- DONE or DONE_WITH_CONCERNS → proceed to Step 3.
 - NEEDS_CONTEXT → provide the missing context, re-dispatch the executor.
 - BLOCKED → stop, report to the user, wait for resolution.
 
-#### At L: one subagent per task
-
-For each task sequentially (never parallel: conflict risk):
-
-**a. Dispatch implementer subagent**
-Use the Agent tool with the implementer prompt template. Include:
-- Full task text (pasted in, not file reference)
-- Project context from CLAUDE.md
-- Active intent context from `{ID}--{slug}.md`
-
-**b. Handle implementer response**
-- DONE → proceed to spec review
-- DONE_WITH_CONCERNS → note concerns, proceed to spec review
-- NEEDS_CONTEXT → provide missing context, re-dispatch
-- BLOCKED → stop, report to user, wait for resolution
-
-**c. Dispatch spec compliance reviewer**
-Use the Agent tool with spec-reviewer prompt. The reviewer reads actual code and compares against the task requirements. Pass/fail.
-- If fail: implementer fixes, spec reviewer re-reviews (loop until pass)
-
-**d. Dispatch code quality reviewer**
-Only after spec compliance passes. Reviews clean code, testing, architecture. Pass/fail.
-- If fail: implementer fixes, quality reviewer re-reviews (loop until pass)
-
-**e. Tick as it lands, then move to next**
-Follow `## Tick-as-you-land` below: move the task's checklist item to `## Completed` and add a `## Session Log` row in the same edit.
-
-### Step 3: Final Review
-After all tasks complete, dispatch a final reviewer for the entire implementation. This runs at every tier, S, M, and L. The reviewer is a separate agent with fresh context and is never the maker. At S and M this is the only review the work gets, so if it returns changes, re-dispatch the executor to fix them, then re-review.
+### Step 3: Review by Risk
+Apply the auto skill's risk rule to the executor's return and the diff: a matrix row no test could prove, a diff touching a hook, the lock, the worktree code, the installer, or a release file, a DONE_WITH_CONCERNS or a deviation from the matrix, or an owner-facing surface no test pins. When a rule fires, dispatch the post-execution reviewer with `code-quality-reviewer-prompt.md` (a separate agent with fresh context, never the maker); if it returns changes, re-dispatch the executor to fix them, then run the suite once more. When no rule fires, the green suite is the review.
 
 ### Step 4: Update Intent and Complete
 Capture observations in `## Insights`. When ALL checklist items are checked:
@@ -142,22 +108,19 @@ row (Date, Items Completed, Notes). Do not batch several tasks' worth of
 checklist updates into one later edit; tick the moment the task is verified,
 before moving to the next task.
 
-## Verify before every owner gate
+## Verify before every owner review
 
 Hard rule: before presenting any completed work to the owner, independently
 verify it. Grep or run the artifact the work just produced (the test suite,
 the changed file, the installed output) rather than restating the intended
 change. Never present an unverified claim to the owner. If verification
-fails, fix it before the gate, not after.
-
-Read `../plastic-conventions/references/gates-and-enforcement.md` for the transition-gate
-mechanics, the audited escape, and gate logging behind every owner gate named here.
+fails, fix it before the review, not after.
 
 ## Methods report (audits and sweeps)
 
 When the work is an audit or a sweep (checking many files or many instances of
 something rather than building one artifact), deposit a methods report to
-`{intent_dir}/resources/` before the gate: what was checked, how it was
+`{intent_dir}/resources/` before the review: what was checked, how it was
 checked, and what was found. This lets the owner review the method, not just
 the conclusion.
 
@@ -175,7 +138,7 @@ When presenting a batch of Exec decisions for the owner to rule, read
 `~/.plastic/_decision-tables.md` and follow the numbered-table procedure,
 persisting each ruling with `--stage Exec`.
 
-## Gate position
+## Position in the cycle
 
 - **Before:** `plan.md` and `checklist.md` exist; the worktree is armed.
 - **Produces:** code changes, a ticked checklist, and (for audits or sweeps) a methods report in `resources/`.