@zalom/plastic 1.0.2 → 1.1.0

package/scripts/{versions.rb → rollback.rb}

@@ -2,20 +2,24 @@
 # encoding: UTF-8
 # frozen_string_literal: true
 
-# Plastic — `versions` verb. Runs via `npx @zalom/plastic versions` (bin/plastic.js) or directly.
-# Usage: ruby scripts/versions.rb [--downgrade [--version <v>] | --upgrade] [--help]
+# Plastic — `rollback` verb. Runs via `npx @zalom/plastic rollback` (bin/plastic.js) or directly.
+# Usage: ruby scripts/rollback.rb [--version <v> [--downgrade | --upgrade]] [--help]
 #
 # Local time-machine over the append-only versions.json ledger. Navigates ONLY versions you
 # have actually run (the ledger), never npm's full list — fetching brand-new versions is
 # `update`'s job. Lets you roll back to a known-good build after a bad release.
-#   - no flag                  print the ledger table (and offer to continue a rollback)
-#   - --downgrade              step back one version in your history
-#   - --downgrade --version V  jump to a specific previously-run version
-#   - --upgrade                step forward one version (after a rollback)
+#   - no flag                        read-only: print the version-history table, never switch
+#   - --version V                    switch to a specific previously-run version (direction derived)
+#   - --downgrade --version V        synonym of --version V (direction flag is descriptive only)
+#   - --upgrade --version V          synonym of --version V (direction flag is descriptive only)
+#   - --downgrade / --upgrade alone  no target given: error, no switch
+#
+# Switching always requires an explicit --version V. A rollback tool whose job is safety
+# during a bad release must never switch versions without a named target.
 
 require_relative "lib/installer_core"
 
-class Versions < InstallerCore
+class Rollback < InstallerCore
   PKG = "@zalom/plastic"
 
   def cli(argv = ARGV)
@@ -32,31 +36,24 @@ class Versions < InstallerCore
 
     timeline = version_timeline(ledger)
     current = installed_version || timeline.last
+    explicit = flag_value(argv, "--version")
 
-    if argv.include?("--downgrade")
-      explicit = flag_value(argv, "--version")
-      target = explicit || step_target(timeline, current, :back)
-      return no_target("No earlier version in your history.") unless target
-      unless timeline.include?(target)
-        warn "#{target} is not in your version history. Choose one of: #{timeline.join(", ")}"
+    if explicit
+      unless timeline.include?(explicit)
+        warn "#{explicit} is not in your version history. Choose one of: #{timeline.join(", ")}"
         return 1
       end
-      return switch_to(target, current)
-    elsif argv.include?("--upgrade")
-      target = step_target(timeline, current, :forward)
-      return no_target("No later version in your history. Use `update` for new releases.") unless target
-      return switch_to(target, current)
+      return switch_to(explicit, current)
     end
 
-    # No flag: show the table, and detect an in-progress rollback.
-    print_table(ledger, current)
-    if ledger.last && ledger.last["action"] == "downgrade"
-      prev = step_target(timeline, current, :back)
-      if prev && $stdin.tty?
-        print "\nYou recently rolled back. Go back further to #{prev}? [y/N]: "
-        return switch_to(prev, current) if ($stdin.gets&.strip || "").downcase.start_with?("y")
-      end
+    if argv.include?("--downgrade") || argv.include?("--upgrade")
+      warn "An explicit target is required: pass --version <v>. Run `rollback` with no " \
+           "flags to see your version history and pick a target."
+      return 1
     end
+
+    # No flags at all: read-only. Print the table and stop; never switch, never prompt.
+    print_table(ledger, current)
     0
   end
 
@@ -93,11 +90,6 @@ class Versions < InstallerCore
     argv[i + 1]
   end
 
-  def no_target(msg)
-    puts msg
-    0
-  end
-
   def switch_to(target, current)
     action = action_for(target, current)
     puts "#{action == "downgrade" ? "\u{23ea}" : "\u{23e9}"}  #{current} \u{2192} #{target} (#{action})"
@@ -119,23 +111,23 @@ class Versions < InstallerCore
   def show_help
     puts <<~HELP
 
-      plastic versions — manage and roll back your local Plastic versions
+      plastic rollback — read installed and available versions, and switch on request
 
       Usage:
-        npx @zalom/plastic versions [options]
+        npx @zalom/plastic rollback [options]
 
       Options:
-        (none)                  Show the version-history table
-        --downgrade             Roll back one version in your history
-        --downgrade --version V Roll back to a specific previously-run version
-        --upgrade               Step forward one version in your history
-        -h, --help              Show this help
+        (none)                    Show the version-history table (read-only, no switch)
+        --version V                Switch to version V (direction derived automatically)
+        --downgrade --version V    Synonym of --version V
+        --upgrade --version V      Synonym of --version V
+        -h, --help                 Show this help
 
-      Navigates only versions you have already run (the append-only ledger). To move to a
-      brand-new release, use `update`.
+      Switching always requires an explicit --version V. Navigates only versions you have
+      already run (the append-only ledger). To move to a brand-new release, use `update`.
 
     HELP
   end
 end
 
-exit(Versions.new(package_root: ENV["PLASTIC_PACKAGE_ROOT"] || File.expand_path("..", __dir__)).cli(ARGV)) if $PROGRAM_NAME == __FILE__
+exit(Rollback.new(package_root: ENV["PLASTIC_PACKAGE_ROOT"] || File.expand_path("..", __dir__)).cli(ARGV)) if $PROGRAM_NAME == __FILE__

package/scripts/update.rb

@@ -164,7 +164,7 @@ class Update < InstallerCore
       Behaviour:
         No flag advances to the next version on your current channel. Switching toward a
         more stable channel is frictionless; switching toward bleeding edge is confirmed.
-        Use `versions` to roll back to a previously-installed version.
+        Use `rollback` to roll back to a previously-installed version.
 
     HELP
   end

package/skills/_active-intent-gate.md

@@ -13,7 +13,7 @@ Before proceeding, resolve the active intent:
    - Look under `## Active` for intent entries
    - If exactly one active intent → use it
    - If multiple active intents → ask user which one
-   - If no active intent → refuse: "No active intent. Create one first with /plastic-creating-intent"
+   - If no active intent → refuse: "No active intent. Create one first with /plastic-intent-creating"
 
 3. **Resolve paths:**
    - Intent directory: `{store}/store/{id}--{slug}/`

package/skills/_decision-tables.md

@@ -0,0 +1,50 @@
+## Numbered Decision Tables
+
+The shared procedure for collecting owner rulings during any stage (Why, How, Exec).
+Any stage skill that needs the owner to choose between options or rule on a batch of
+open questions follows this procedure instead of improvising its own format.
+
+Read this when a stage skill's own text says to.
+
+### The procedure
+
+1. **Collect the candidate decisions.** Gather every open question or option set that
+   needs an owner ruling right now. Do not present them one at a time across separate
+   messages; batch them into a single collection first.
+
+2. **Present exactly ONE table.** Its first column is the row number. One decision per
+   row. Add a recommendation column stating the agent's recommended choice and a short
+   reason. Example shape:
+
+   | # | Decision | Recommendation |
+   |---|---|---|
+   | 1 | Ship the setting as a CLI flag or a config file? | Config file: survives across invocations |
+   | 2 | Retry, circuit breaker, or fallback for the flaky call? | Retry: matches existing error handling elsewhere in this module |
+
+3. **Let the owner rule by row number.** The owner responds with a ruling per row
+   number (e.g. "1: config file, 2: retry"). Do not require prose paragraphs back; a
+   row-number ruling is enough.
+
+4. **Persist each ruling immediately, one at a time.** For every ruling, before moving
+   to the next row, run:
+
+   ```
+   ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage <stage> --author human
+   ```
+
+   Never batch rulings into a single call and never wait until all rows are ruled to
+   start persisting. `<stage>` is the current stage (Why, How, or Exec). If a ruling
+   supersedes an earlier one already on record, append a second insight that names the
+   superseded decision and states plainly that this ruling supersedes it. Both insights
+   stay on record; the later one wins.
+
+5. **Write the full ruling set to a rulings file.** After the last row is ruled and
+   persisted, write the complete table plus every ruling to
+   `{intent_dir}/resources/rulings--<slug>.md` so the full set is readable in one place
+   alongside the per-row insights.
+
+### Why one table, not a chip per row
+
+A single table lets the owner rule on everything in one pass and reference row numbers
+in their reply. Multiple small prompts force the owner to context-switch per decision
+and make later replies ambiguous about which decision they answer.

package/skills/auto/SKILL.md

@@ -1,14 +1,15 @@
 ---
 name: plastic-auto
 description: >-
-  Autonomous intent delivery — agent takes over How and Exec. Use when user says
+  Autonomous intent delivery - agent takes over How and Exec. Use when user says
   "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes
   and user confirms autonomous execution. Requires an active intent in INDEX.md.
+user-invocable: true
 ---
 
-# Auto — Autonomous Intent Delivery
+# Auto - Autonomous Intent Delivery
 
-Announce: "Taking over intent [ID] — [name] for autonomous delivery."
+Announce: "Taking over intent [ID] - [name] for autonomous delivery."
 
 **Advisory (not a gate).** At auto-mode start, recommend once that the user run this
 orchestrating main session on the best available thinking model (Fable, Opus, or whatever
@@ -18,7 +19,7 @@ subagents keep their pinned tier and never resolve to Fable.
 
 ## Precondition
 
-An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-creating-intent."
+An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-intent-creating."
 
 If multiple active intents exist, ask the user which one to deliver (this is the only question auto asks).
 
@@ -30,8 +31,8 @@ next dispatchable intent:
 ruby ~/.plastic/scripts/dashboard.rb all --json
 ```
 
-Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions —
-safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user — those
+Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions -
+safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user - those
 are `drive`/`triage` items the human should lead. See the `plastic-dashboard` skill.
 
 QMD-first (when available): when the user describes the work to deliver rather than naming an
@@ -64,7 +65,7 @@ and artifact depth to that size. Extended walkthrough: `references/tiers.md`.
 
 ## Arm the Lifecycle Gate (do this FIRST)
 
-Immediately after selecting the intent — before any other work — arm auto mode. This
+Immediately after selecting the intent - before any other work - arm auto mode. This
 writes the session bridge that makes the code-edit gate live, so project code cannot be
 edited before the plan exists (the gate applies to YOU, the orchestrator):
 
@@ -87,7 +88,7 @@ Honor the cycle: What → Why (spec.md) → How (plan.md + actions/ + checklist.
 
 ## Flags
 
-- `--skip-permissions` — bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
+- `--skip-permissions` - bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
 
 ## Team Spin-Up
 
@@ -103,7 +104,7 @@ Roster (one role per cycle stage):
 - **plastic-executor** (code + checklist + `## Insights`)
 - **plastic-enforcer** (orchestrates + gates; that is YOU)
 
-Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-executing-plan`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
+Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-intent-executing`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
 
 Spawn preamble (live-state injection): before dispatching any specialist, run `scripts/spawn-preamble <intent_dir> --role <role>` and PREPEND its output to that specialist's prompt. The preamble is a deterministic, filesystem-only snapshot of the active intent (id, intent line, current stage, and the provisioned code worktree path when one exists on disk) plus the honoring instruction, so every spawned agent boots with accurate live state instead of guessing. This is the authoritative L2 mechanism for harnesses whose sub-agents do not inherit a top-level session event (see `docs/reference/harness-adapters.md`).
 
@@ -167,15 +168,15 @@ this is worth doing, or proceed).
 When entering at Why stage:
 
 1. Read existing `## Context` and `### Decisions` from the intent file
-2. Assess gaps — what decisions are missing? What context is incomplete?
-3. Self-directed research — read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
-4. Adaptive budget — assess complexity and set your own research budget:
+2. Assess gaps - what decisions are missing? What context is incomplete?
+3. Self-directed research - read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
+4. Adaptive budget - assess complexity and set your own research budget:
    - Simple (config change, small feature): 2-3 research steps
    - Medium (new feature, integration): 5-8 research steps
    - Complex (new project, architecture): 10-15 research steps
-5. Make decisions — pick best option, document in `## Context > ### Decisions` with rationale
+5. Make decisions - pick best option, document in `## Context > ### Decisions` with rationale
 6. Log all autonomous decisions in `## Insights` with `(autonomous)` marker: "Decision: chose X because Y (autonomous)"
-7. Write `spec.md` — consolidated specification
+7. Write `spec.md` - consolidated specification
 8. Notify user (Why briefing): brief per `references/human-report-contract.md`
    (State: the approach chosen, one line; Risk: the main trade-off; Call: the one decision
    needed, approve or pick an option).
@@ -190,9 +191,9 @@ intent birth and persists at every tier; only writing `ACTION_N.md` files into i
 only (S/M leave the directory empty).
 
 1. If `superpowers:writing-plans` is available as a skill, delegate plan creation to it. Tell it the plan saves to the active intent's directory (not `docs/superpowers/plans/`).
-2. Otherwise, write `plan.md` directly — implementation plan with numbered tasks
-3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) — L only
-4. Write `checklist.md` — execution registry with checkboxes covering all actions
+2. Otherwise, write `plan.md` directly - implementation plan with numbered tasks
+3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) - L only
+4. Write `checklist.md` - execution registry with checkboxes covering all actions
 5. Notify user (How briefing): brief per `references/human-report-contract.md`
    (State: the plan shape, task count and what it builds; Risk: the riskiest task or
    dependency; Call: approve the plan to build).
@@ -204,9 +205,9 @@ Then proceed to Exec.
 If the plan calls for creating a new project (the intent is an implementation intent that needs a new codebase):
 
 1. Determine project path from `~/.plastic/config.yml` `project_roots` or from intent context
-2. **Confirm path with user** — this is the ONE human interaction during auto delivery:
+2. **Confirm path with user** - this is the ONE human interaction during auto delivery:
    > "Creating project `<slug>` at `<path>`. Confirm path, or provide alternative."
-3. Invoke `plastic-creating-project` skill
+3. Invoke `plastic-project-creating` skill
 4. The global intent is now Completed (creating-project handles this)
 5. The tactical mirror in the project store becomes the active intent
 6. Continue execution from the project directory using the tactical intent
@@ -214,7 +215,7 @@ If the plan calls for creating a new project (the intent is an implementation in
 ## Exec Phase
 
 1. If `superpowers:subagent-driven-development` or `superpowers:executing-plans` is available, delegate execution to it
-2. Otherwise invoke `plastic-executing-plan`
+2. Otherwise invoke `plastic-intent-executing`
 3. Execute actions from checklist sequentially
 4. Check off items in `checklist.md` as completed
 5. Append observations to `## Insights` with `(autonomous)` marker
@@ -223,7 +224,7 @@ If the plan calls for creating a new project (the intent is an implementation in
    (State: what got built and the test result; Risk: residual failures or deviations;
    Call: go to review, or done).
 
-## Permission Model — Safe-by-Default
+## Permission Model - Safe-by-Default
 
 The agent MUST prefer non-destructive routes:
 
@@ -231,7 +232,7 @@ The agent MUST prefer non-destructive routes:
 |---|---|
 | Drop table | Rename to `_deprecated_<table>`, flag for cleanup |
 | Delete files | Move to `.archive/` or backup branch |
-| Alter column | Additive migration — new column + backfill |
+| Alter column | Additive migration - new column + backfill |
 | Remove feature | Feature flag off, code stays until human confirms |
 | Database migration | Backup before migration, keep rollback path |
 
@@ -246,7 +247,7 @@ With `--skip-permissions`, the agent logs the action in Insights but proceeds wi
 
 ### Greenfield Exception
 
-During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices — DB engine, framework, gems, architecture.
+During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices - DB engine, framework, gems, architecture.
 
 ## Completion
 
@@ -257,55 +258,38 @@ During initial project creation, all decisions are non-destructive by definition
    and End tail in PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`).
 3. Write `## Outcome` summary in the intent file (1-2 sentences)
 4. **Release (if configured)**
-   1. Detect project — match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
+   1. Detect project - match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
    2. Read `~/.plastic/projects/{slug}/project.yml`. If the file doesn't exist or has no `release` key, skip to step 5.
    3. Based on `release.on_complete`:
-      - `commit` — git add + commit (same as default, proceed to step 5)
-      - `commit_and_push` — git add + commit + push
-      - `manual` — skip auto-commit, notify user: "Release configured as manual — commit when ready."
+      - `commit` - git add + commit (same as default, proceed to step 5)
+      - `commit_and_push` - git add + commit + push
+      - `manual` - skip auto-commit, notify user: "Release configured as manual - commit when ready."
    4. If `release.verify` is set, run the verify command (e.g. `bundle exec rake test`):
       - **Exit 0 (green):** proceed to sub-step 5
       - **Non-zero (red):** check `release.on_red`:
-        - `fix_and_retry` — attempt to fix the failure, re-run verify (max 2 retries)
-        - `stop` — write `savepoint.md` with current state, notify user: "Verify failed — savepoint written.", **STOP**
-        - `manual` — notify user: "Verify failed: [summary]. Resolve manually."
-   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic — delegate entirely.
+        - `fix_and_retry` - attempt to fix the failure, re-run verify (max 2 retries)
+        - `stop` - write `savepoint.md` with current state, notify user: "Verify failed - savepoint written.", **STOP**
+        - `manual` - notify user: "Verify failed: [summary]. Resolve manually."
+   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic - delegate entirely.
 5. Review `## Insights` for observations that should spawn future intents. If any:
-   - Create them (using `plastic-creating-intent` conventions)
+   - Create them (using `plastic-intent-creating` conventions)
    - Update `chain` in the current intent's frontmatter
-6. Move intent from `## Active` to `## Completed` in INDEX.md (with today's date). As the
-   closing act of the transfer, stamp the terminal ledger bookend (intent 81) so the savepoint's
-   last line records delivery:
+6. Run the mechanical close through `plastic-intent-ending`: it owns steps 1-6 of the Done
+   procedure (outcome/INDEX/savepoint/commit, disarm, and the QMD reindex last) as ONE
+   delegation, not five separate one-liners restated here. Run its backing script for the
+   outcome/INDEX/savepoint/commit core, passing `--index-note` with a rich Completed/
+   Abandoned entry description (mode/tier, what shipped or why abandoned, suite result):
    ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.append_terminal_savepoint("<intent_dir>", "delivered")'
+   ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
+     --index-note "<mode, tier>; <what shipped>; <suite result>"
    ```
-   (Use `"abandoned"` instead when the intent is being moved to `## Abandoned`.) Idempotent.
-7. Auto-commit: `cd <store-root> && git add . && git commit -m "feat: deliver intent <ID> — <name>"`
-8. Disarm the lifecycle gate (auto delivery is finished). Substitute the intent's own id for
-   `<ID>` (a session can be delivering more than one intent at once, intent 131, so disarm must
-   name which of the session's bridges to clear):
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.disarm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>")'
-   ```
-   Disarm runs the ordered End tail (release worktrees, then clear the `delivery.lock`,
-   then the bridge becomes purge-eligible) and performs the mandatory worktree cleanup
-   (intent 73c3): both per-intent worktrees are removed and both repos pruned. This is
-   the plain remove path (no merge); when the work ships through a release, the release
-   path merges the branch BEFORE the worktree is removed instead of relying on this step.
-   Never leave an orphaned worktree, and run `git worktree prune` if you hit a stale
-   reference. For the full ordering rationale and the release-vs-plain-disarm
-   distinction, read `references/end-tail.md`.
-9. QMD reindex LAST (canonical End tail), run only after disarm has released the
-   worktrees, cleared the `delivery.lock`, and purged the bridge. It runs in the
-   background so it never blocks the turn:
-   ```bash
-   ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async
-   ```
-   `<store-root>` is the store that holds this intent (the global store or the project
-   store); the command is a no-op when QMD is absent. For why the reindex must be last
-   (so the index never references a bridge or lock about to disappear), read
-   `references/end-tail.md`.
-10. Notify user (Done briefing): brief per `references/human-report-contract.md`
+   (Use `--disposition abandoned` when the intent is being moved to `## Abandoned`.) Then
+   follow `plastic-intent-ending`'s Step 5 (disarm: `Bridge.disarm_auto` on this auto/curator
+   path, the plain-remove branch) and Step 6 (QMD reindex, async, last) exactly as that skill
+   states them. Never leave an orphaned worktree; run `git worktree prune` on a stale
+   reference. If any of this ever needs to change, change `plastic-intent-ending`, not this
+   skill.
+7. Notify user (Done briefing): brief per `references/human-report-contract.md`
     (State: the delivered impact; Risk: residual risk; Call: the decision left to you, merge,
     release, or accept). See `outcome.md` for details.
 
@@ -314,7 +298,7 @@ During initial project creation, all decisions are non-destructive by definition
 If the agent gets stuck (can't resolve a gap, dependency is missing, tests fail persistently):
 1. Log the blocker in `## Insights`
 2. Write `savepoint.md` with current state
-3. Notify user: "Blocked on intent [ID] — [name]: [description]. Savepoint written."
+3. Notify user: "Blocked on intent [ID] - [name]: [description]. Savepoint written."
 4. **STOP.** Do not attempt workarounds that could leave the project in a broken state.
 
 ## References

package/skills/auto/evals/evals.json

@@ -116,13 +116,13 @@
       "scope": "triggering",
       "set": "train",
       "prompt": "create a new intent for the dashboard idea",
-      "expected_output": "Does NOT activate plastic-auto; activates plastic-creating-intent.",
+      "expected_output": "Does NOT activate plastic-auto; activates plastic-intent-creating.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-creating-intent",
+          "observed": "plastic-intent-creating",
           "result": "pass"
         }
       ]
@@ -132,13 +132,13 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "what's the status of my active intents?",
-      "expected_output": "Does NOT activate plastic-auto; this is a read/continuing/managing-index query.",
+      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing/store-indexing query.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-managing-index",
+          "observed": "plastic-store-indexing",
           "result": "pass"
         }
       ]

package/skills/auto/references/agent-architecture.md

@@ -101,7 +101,7 @@ verifies state itself.
 ### Delegation
 
 The roles are thin handoff contracts, not a spawning engine. Dispatch and review run
-by default through Plastic's own engine, `plastic-executing-plan` (implementer plus
+by default through Plastic's own engine, `plastic-intent-executing` (implementer plus
 two-stage review, no external plugin). When `superpowers:subagent-driven-development`
 and `superpowers:dispatching-parallel-agents` are available, or the user asks for them,
 they delegate to those as an enhancement. The team model defines who hands what to whom
@@ -112,7 +112,7 @@ spawning.
 
 The default is always Plastic's native engine, so a user without superpowers still gets
 the full behavior. If the harness supports subagents but superpowers is absent, auto
-mode dispatches through `plastic-executing-plan`. If the harness has no subagent dispatch
+mode dispatches through `plastic-intent-executing`. If the harness has no subagent dispatch
 at all, auto mode falls back to a single agent walking the full What, Why, How, Exec
 cycle itself. The enforcer's gate discipline still applies in every case.
 

package/skills/auto/references/agent-report-contract.md

@@ -47,6 +47,9 @@ Every role report, whatever the stage, carries these fields:
 
 ## Per-role payload
 
+Multi-item payload fields (ordered actions, insights, checklist deltas) default to tables per
+`PLASTIC.md` (## Tabular-First Reporting, intent 160); single fields stay prose.
+
 Each role appends a payload that fulfils its place in the What, Why, How, Exec cycle (decision
 D2). The payload is what makes the report useful to the orchestrator beyond the envelope.
 

package/skills/dashboard/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: plastic-dashboard
 description: Use when the user wants an overview of intents, asks "where are we", "what's next", "what should I work on", "show the dashboard", or invokes /plastic-dashboard. Renders a deterministic Value×Effort work cockpit as Markdown across the global store and all projects, and emits a machine-readable queue that auto mode consumes.
+user-invocable: false
 ---
 
 # Dashboard — Plastic Work Cockpit
@@ -18,7 +19,7 @@ state → byte-identical payload, regardless of model. Do NOT hand-summarize int
 
 - User invokes `/plastic-dashboard`
 - User asks "where are we", "what's next", "what should I work on", "show me the intents"
-- `plastic-continuing` lands on the board on resume
+- `plastic-intent-continuing` lands on the board on resume
 - `plastic-auto` reads `--json` to choose the next dispatchable intent
 
 ## Procedure (the Markdown board — default human surface)
@@ -83,7 +84,7 @@ a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
 The board lists everything; the user navigates by free prose (no capped picker):
 - On the **global** board, the user replies with an **intent id** (work it), a **project
   name** (re-run `project <slug> --data` and present that board), or **"new"** (start a new
-  intent in global via `plastic-creating-intent`).
+  intent in global via `plastic-intent-creating`).
 - On a **project** board, the user replies with an **intent id**, or **"global"** to return.
 
 ## Auto-mode contract (`--json`)

package/skills/doctor/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: plastic-doctor
 description: Use when diagnosing Plastic installation health, after updates, or when something seems broken. Runs checks and reports findings with fix options.
+user-invocable: true
 ---
 
 # Doctor: Plastic Health Check
@@ -12,7 +13,7 @@ Doctor has three scopes. Pick the right one for the situation:
 | Scope | Flag | When it runs | States |
 |-------|------|--------------|--------|
 | Core check | `--core` | SessionStart hook (automatic), also available on demand | Binary: pass or error |
-| Store check | `--store [global\|<slug>]` | Dashboard load, `plastic-continuing` | Three-state: pass / warn / fail |
+| Store check | `--store [global\|<slug>]` | Dashboard load, `plastic-intent-continuing` | Three-state: pass / warn / fail |
 | Full check | (no flag) | After every update (automatic), or `/plastic-doctor` | Three-state: pass / warn / fail |
 
 ### `--core` (binary, manifest-backed)
@@ -117,9 +118,9 @@ Use the `fix_hint` value to determine the correct action:
 | "Add missing entries to INDEX.md" | Add orphaned intents to the appropriate INDEX.md section |
 | "Remove stale references from INDEX.md" | Edit INDEX.md to remove ghost references |
 | "Inject the missing required frontmatter field(s)" | Edit the intent's `{ID}--{slug}.md` frontmatter to add the missing key (e.g. `chain: []`) without touching other keys |
-| "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-add-project-store` skill) to create the missing store |
+| "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-store-provisioning` skill) to create the missing store |
 | "Re-run installer" | Run `npx -y @zalom/plastic@<channel> install --agent <agent>` (channel: -alpha->@alpha, -beta->@beta, else @latest) |
-| "Dispatch plastic-intent-curator ... revisions.md ..." | Invoke the `plastic-intent-curator` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
+| "Dispatch plastic-store-curating ... revisions.md ..." | Invoke the `plastic-store-curating` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
 
 For fixes the agent cannot handle automatically, explain what the user needs
 to do manually. The `revisions.md` remedy is curator-applied (a move-and-record

package/skills/humanizer/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: plastic-humanizer
 description: Use to clean authored prose so it reads human and clutter-free. Removes AI tells and slop from a document, spec, outcome, README, report, or release note. Use when the user says "humanize", "de-slop", "remove the AI tells", or "clean up the wording". For documents, not for every chat reply, and not for code.
+user-invocable: true
 ---
 
 # Humanizer

package/skills/install/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: plastic-install
-description: Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. Accepts channel flags (--alpha, --beta, --latest) to select release channel. First install defaults to --beta; reinstalls match the already-installed channel. Global install is recommended: it creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.
+description: 'Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. Accepts channel flags (--alpha, --beta, --latest) to select release channel. First install defaults to --beta; reinstalls match the already-installed channel. Global install is recommended: it creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.'
+user-invocable: true
 ---
 
 # Install Plastic