@zalom/plastic 2.0.0-alpha.9 → 2.0.2

package/skills/auto/evals/evals.json

@@ -1,255 +0,0 @@
-{
-  "skill_name": "plastic-auto",
-  "notes": "Intent 27. Scopes: description triggering (1-8) and behavior/output quality (9). Assertions written after observing Step-3 runs (one clean subagent router per case). Intent 63 added cases 10-11 (auto-mode enforcer-led team spin-up and solo fallback).",
-  "results": {
-    "triggering": {
-      "cases": 8,
-      "passed": 8,
-      "pass_at_1": 1.0,
-      "run": "2026-06-10, one subagent per case"
-    },
-    "behavior": {
-      "cases": 1,
-      "passed": 1,
-      "evidence": "dogfood: intent 27 itself delivered via auto produced spec->plan->checklist before any code edit; code-gate unit test proves pre-How project-code edits are blocked"
-    }
-  },
-  "evals": [
-    {
-      "id": 1,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "auto",
-      "expected_output": "Activates plastic-auto (the bare 'auto' keyword is the documented trigger).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-auto",
-          "observed": "plastic-auto",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "take it from here and deliver intent 27 end to end",
-      "expected_output": "Activates plastic-auto (autonomous delivery of an active intent).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-auto",
-          "observed": "plastic-auto",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "go fully autonomous on the active intent, don't ask me questions",
-      "expected_output": "Activates plastic-auto.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-auto",
-          "observed": "plastic-auto",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "deliver this intent for me",
-      "expected_output": "Activates plastic-auto.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-auto",
-          "observed": "plastic-auto",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "set up a hook to automatically format the file on every save",
-      "expected_output": "Does NOT activate plastic-auto. Near-miss: shares 'auto*' but is a settings/hooks task (update-config).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-auto",
-          "observed": "update-config",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 6,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "deliver the built package to the dist directory",
-      "expected_output": "Does NOT activate plastic-auto. Near-miss: shares 'deliver' but is a build/file task.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-auto",
-          "observed": "none",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 7,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "create a new intent for the dashboard idea",
-      "expected_output": "Does NOT activate plastic-auto; activates plastic-intent-creating.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-intent-creating",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 8,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "what's the status of my active intents?",
-      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing query.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-intent-continuing",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 9,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Active intent X exists with only a '## Intent' section. Deliver it in auto mode.",
-      "expected_output": "Arms the lifecycle gate first, then produces spec.md (Why), then plan.md + actions/ + checklist.md (How), and edits NO project code before plan.md + checklist.md exist. Disarms on completion.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "spec.md written before plan.md before any project-code edit",
-          "observed": "dogfood run of intent 27 followed this order",
-          "result": "pass"
-        },
-        {
-          "type": "code",
-          "check": "code-gate blocks project-code Edit/Write while pre-How (test/code_gate_test.rb)",
-          "observed": "test green",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 10,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Active intent X exists. Deliver it in auto mode on a harness that supports subagents.",
-      "expected_output": "Spins up one enforcer-led team per intent (plastic-enforcer, executor, an on-request reviewer). The enforcer IS the orchestrator: it writes spec.md, the action files, and checklist.md itself, dispatches one executor for the consolidated action on one branch, and dispatches an independent reviewer subagent at the final gate only.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "enforcer writes Why and How itself; one executor dispatched; independent reviewer only at final gate",
-          "observed": "dogfood: intents 60-62 delivered by exactly this enforcer-led team on a shared branch",
-          "result": "pass"
-        },
-        {
-          "type": "code",
-          "check": "agents/plastic-*.md role files ship and install into the harness agent dir, manifest-tracked (test/install_packaging_test.rb)",
-          "observed": "test green",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 11,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Active intent X exists. Deliver it in auto mode on a harness with no subagent dispatch.",
-      "expected_output": "Falls back to a single agent walking the full What, Why, How, Exec cycle itself, preserving current behavior. The enforcer gate discipline still applies (arm the gate first, no project-code edits before plan.md + checklist.md exist).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "solo agent walks the full cycle when subagent dispatch is unavailable; gate discipline preserved",
-          "observed": "SKILL.md Team Spin-Up documents the solo fallback explicitly",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 12,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "A power-tool is present (qmd on PATH, or a .serena marker / serena on PATH). A substantive prompt arrives in auto mode.",
-      "expected_output": "The agent prefers the present tool because PLASTIC.md (loaded at session start) recommends QMD for intents and Enola, or Serena when Enola is absent, for code navigation. No hook appends a per-prompt line: the power-tools hook was removed in 2.0 (intent 309).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "PLASTIC.md carries the recommendation (doctrine_305_test) and PowerTools presence probes still back doctor's readiness checks (power_tools_test.rb)",
-          "observed": "doctrine_305_test test_plastic_md_carries_the_power_tools_mandate_as_a_recommendation; power_tools_test.rb presence probes",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 13,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Neither qmd nor serena is present (no qmd on PATH, no .serena marker, no serena on PATH). A substantive prompt arrives.",
-      "expected_output": "Detect-then-degrade: PLASTIC.md's recommendation applies only when a tool is present, so nothing is required to install and no per-prompt line appears (there is no hook to emit one since intent 309).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "PowerTools.mandate returns nil when neither tool is present",
-          "observed": "power_tools_test.rb test_mandate_neither_is_nil",
-          "result": "pass"
-        }
-      ]
-    },
-    {
-      "id": 14,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "QMD is present. In auto mode the user says: deliver the work on the uploader retry policy (no intent id given).",
-      "expected_output": "Before scanning the store with grep/Read to find the matching intent, runs `ruby ~/.plastic/scripts/qmd-sync search \"uploader retry policy\"` to surface the candidate intent, then opens the authoritative intent file for the hit it takes over. This discovery step is distinct from the completion-time reindex step. No-op fallback to INDEX.md / file scan when QMD is absent.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "qmd-sync search is run before grep/Read during discovery; authoritative file opened for the hit; reindex step stays separate",
-          "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/auto/references/end-tail.md

@@ -1,66 +0,0 @@
-# End-Tail Mechanics: Arm.disarm and the Ordering
-
-Deep mechanics behind two spots in `SKILL.md`: how `plastic-lock arm` resolves a session id
-when it takes an intent, and why the End-tail steps in Completion (release the worktree, clear
-the lock, reset the pointer, reindex) run in that exact order. The `/tmp` bridge JSON these
-steps once also purged was removed in 2.0 (intent 307); `scripts/lib/arm.rb` is what remains.
-
-## Table of Contents
-
-- [Session resolution](#session-resolution)
-- [Disarm ordering and worktree cleanup rationale](#disarm-ordering-and-worktree-cleanup-rationale)
-- [QMD reindex ordering rationale](#qmd-reindex-ordering-rationale)
-
-## Session resolution
-
-`Arm.resolve_session` picks the first non-empty of: the explicit id (`--session`, or the hook
-stdin `session_id` when a caller has it), the `CLAUDE_CODE_SESSION_ID` the CLI read, then a
-deterministic derived key (a hash of the store and the intent id). It never returns nil, so
-the arm verb works even when every session variable is empty; a session-less arm and a later
-session-less close resolve to the same key.
-
-Arming acquires the durable `delivery.lock` in the intent dir, keyed by that resolved session
-and stamped with `run_mode`. Ownership is session-keyed, not process-keyed, so the arm command
-exiting is fine by construction: the lock stays yours for every later tool call in this
-session, and the record hook refreshes its lease on every write you make. The same call writes
-the intent id into the session pointer (`~/.plastic/store/.tmp/<session>/current`), which is
-why the capture and record hooks stop treating your prompts as day-ledger items for the rest
-of the delivery.
-
-## Disarm ordering and worktree cleanup rationale
-
-`Arm.disarm` runs the ordered End tail: it releases the worktree first, then clears the
-intent's `delivery.lock` as its recorded owner, and only then resets the session pointer to
-today's day id (when it still names this intent). The worktree goes first so a released lock
-never points at a checkout another session could claim; the pointer goes last so the record
-hook keeps heartbeating the lock until the lock is gone.
-
-**Mechanized since intent 188.** `scripts/end-intent` performs this disarm itself, as its own
-step 5, after steps 1-4 (outcome/INDEX/savepoint/commit) commit. A pre-flight lock guard
-refuses on a live foreign session (exit 4) and reclaims a stale foreign lock automatically
-(audited to savepoint.md); a dirty code worktree refuses before removal (exit 5,
-`--discard-worktree-changes` overrides deliberately); and the durable lock file is checked
-again after disarm, never merely trusted (exit 3 if it is somehow still present).
-
-**Worktree cleanup (mandatory, intent 73c3).** `end-intent`'s step 5 calls `Arm.disarm` by
-default, which calls `Worktree.release` on the block `Arm.worktree_block` derives from
-`projects.yml` and the intent id, removing the intent's code worktree under
-`<repo>/.claude/worktrees/{id}--{slug}` and pruning the repo. This is the plain remove path:
-the disarm route does NOT merge, so use it only when no release merges the branch (the branch
-survives and can be reclaimed).
-
-When the work is being shipped through a release, do NOT rely on this plain remove.
-`skills/releasing/SKILL.md` runs its worktree-merge step BEFORE its `end-intent` call, merging
-the intent's code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE
-the worktree is removed, via `Worktree.finish(Arm.bridge_hash(intent_dir: ...), merge: true)`
-(merge-then-remove), so the integrated work is not lost. By the time `end-intent`'s own step 5
-runs afterward, the worktree is already gone (a harmless no-op) and only the delivery lock and
-the pointer are left to clear. Never leave an orphaned worktree, and run `git worktree prune`
-if you hit a stale reference.
-
-## QMD reindex ordering rationale
-
-Completion is the lifecycle event that keeps the search index fresh. `<store-root>` is the
-store that holds this intent (the global store or the project store). The reindex is the LAST
-End-tail step, run after the disarm, so the index never references a lock that is about to
-disappear.

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

@@ -1,78 +0,0 @@
-# Human Report Contract (the three report screens, intent 317)
-
-D15: the prose EM-to-CTO briefing this doc used to define is retired. The orchestrator now
-prints one of three report screens, filled from the record by `scripts/report-screen`, never
-written by eye:
-
-- **`report-screen state <intent_dir> [--changed "<text>"]`** - the mid-delivery report. One
-  intent's field table (Store, Status, Stage, Savepoint, Progress, Next, Insight) plus a
-  `Changed` row naming what caused the print, and its Steps table.
-- **`report-screen state --all <store_root>`** - the roster across every in-delivery intent,
-  most recently changed first, then one collapsed block (Stage, Next, Changed, first three
-  open steps) per intent.
-- **`report-screen delivered <intent_dir>`** - the post-delivery report, printed once at close:
-  Asked, Delivered (with a Proven-by column), Evidence, Needs you.
-- **`report-screen delay <intent_dir>`** - printed only on request ("why did X take so long"):
-  the delivery as a timeline plus the derived `Where the time went` line.
-
-## The five triggers for `state`
-
-Print `state` (one intent, or `--all` for the roster) on any of these; a checklist tick alone,
-an executor's intermediate commit, or an agent going idle is NOT one of them:
-
-| Trigger | Scope |
-|---|---|
-| A savepoint line lands (a stage boundary: Why, How, Exec started, outcome written, Done) | that intent |
-| A review verdict returns (plan review or post-execution review), naming what it changed | that intent |
-| A blocker or needs-input is logged | that intent |
-| A merge or a release lands | that intent |
-| The owner asks ("where are we", "state of X", "continue X") | all in delivery, or the one named |
-
-`delivered` prints exactly once, at Completion. `delay` prints only when the owner asks why a
-delivery took long.
-
-Every verb prints the same plain Markdown on every harness (owner ruling 2026-08-31); where a
-harness can paint it (Claude Code, through 316a's message-display hook), it substitutes a
-painted rendering of that same output, never a different one, and no skill or script branches
-on harness name to decide.
-
-## Depth for small work
-
-For small work in auto mode, only the How-boundary `state` screen prints mid-flight (its
-`Changed` row names what the What and Why steps did, since there is no separate briefing per
-stage any more). Larger work prints `state` at every trigger in the table above. This is a
-depth cut, not a different report: the screen's shape never changes, only how often it fires.
-A delivery still ends with `outcome.md` plus one `delivered` screen.
-
-## One report per audience
-
-A delivery produces exactly two artifacts: `outcome.md` (authored by `plastic-intent-ending`)
-and one `delivered` screen at the End stage. No stage or skill restates a delivery already
-written to `outcome.md`; point at it instead. Skills do not open with a banner that names the
-skill or restates the intent id and name the owner just typed. Announce only what the reader
-cannot already know: an error, a result, a choice with its reason, or a handoff.
-
-## Boundary vs intent 74
-
-Intent 74's report contract (`references/agent-report-contract.md`) is the INTERNAL,
-machine-checked handoff from a dispatched specialist back to the orchestrator: a structured
-envelope plus a per-role payload. This contract is the OUTWARD screen shown to the owner.
-Different direction, different audience, different form. The orchestrator reads the intent 74
-report and reflects it into the record (savepoint, outcome.md) that `report-screen` then
-renders. The two never merge.
-
-## Brevity: point, don't repeat
-
-Surface rules are owned by the `writing-style` skill. This contract does not restate them. Its
-job is naming which screen prints when, not the wording inside it - `report-screen` derives
-every cell from the record (D14), so there is no prose left to style here.
-
-## Emission: guided vs auto
-
-In guided mode, `state` prints at each stage boundary and the human decides before the next
-stage starts.
-
-In auto mode, `state` prints at every trigger for larger work; for small work only the How
-boundary prints (see `## Depth for small work` above). The orchestrator takes the go-ahead
-itself and moves on, except at the existing hard stops (destructive action without a safe
-alternative, project-path confirm).

package/skills/conventions/SKILL.md

@@ -1,29 +0,0 @@
----
-name: plastic-conventions
-description: >
-  Chapters of Plastic doctrine used by more than one skill: the knowledge graph,
-  lifecycle and savepoints, locks and
-  worktrees, completion, maintenance, and roadmaps. Read a chapter when its trigger
-  applies to the work in front of you.
-user-invocable: false
----
-
-# Plastic Conventions
-
-The chapters below hold Plastic doctrine that more than one skill needs. Core always-on
-conventions stay in `~/.plastic/PLASTIC.md`, which is injected at session start. Read a chapter
-when the trigger in the second column applies to the work in front of you.
-
-| Chapter | Read it when |
-|---|---|
-| `references/knowledge-graph.md` | when creating, linking, curating, or indexing intents and you need the sources-vs-chain doctrine, the tiers of influence, the `## Links` projection, or branch-vs-root directory semantics |
-| `references/lifecycle-and-savepoints.md` | when running a lifecycle stage or a savepoint and you need the subagent report-home contract for how an insight reaches the intent |
-| `references/locks-and-worktrees.md` | before taking or releasing a delivery lock, and when working with claims, worktrees, solo mode, or the station ledger |
-| `references/completion-and-done.md` | when ending an intent, for what "intent done" means and the End-stage tail |
-| `references/maintenance-and-revisions.md` | before any structural maintenance edit, for WORK vs MAINTENANCE, the `revisions.md` move-and-record contract, the violation-tag catalog, and the context-economy measurement buckets |
-| `references/roadmaps.md` | when creating, ordering, closing, or consuming a roadmap, for the file format and the status-mirror rule |
-
-Other skills read these chapters directly at
-`../plastic-conventions/references/<chapter>.md`, resolved relative to their own installed
-directory. All three harnesses install skills flat into one shared skills root through the same
-`install_skills_flat` call, so that path is harness-independent.

package/skills/conventions/references/completion-and-done.md

@@ -1,43 +0,0 @@
-# Completion and Done
-
-This chapter holds what "intent done" means and the End-stage tail.
-
-#### What "intent done" means (intent 93)
-
-Done is one law with three signals, and they must agree. INDEX `## Completed` /
-`## Abandoned` is the single canonical terminal marker: it is the store-wide ledger a fresh
-session reads first, so it wins on any conflict. `outcome.md` is the "deliverable exists"
-signal, and the savepoint `Done delivered|abandoned` line is the audit echo. All three must
-agree; when they disagree, INDEX is authoritative and `doctor` flags the mismatch (the
-`done_signals` check: `outcome.md` real but still under `## Active`, or terminal without a
-real `outcome.md`, or a terminal intent whose savepoint carries no `Done` line).
-
-`outcome.md` is mandatory at every terminal transition, delivered and abandoned alike. It
-self-declares its disposition through a `disposition: delivered|abandoned` frontmatter
-header. The delivered path authors it with the result; the abandoned path authors it with
-the abandonment reason and no longer leaves the scaffolded placeholder sentinel in place.
-
-The canonical End tail runs in this order, and the QMD reindex is always LAST, after the
-purge: `outcome.md -> INDEX terminal -> savepoint Done -> commit -> disarm (Worktree.release
--> Lock.release -> purge) -> QMD reindex`. Running the reindex last keeps the index from
-ever referencing a bridge or lock that disarm is about to remove.
-
-`scripts/end-intent` performs this order's disarm step (verify the code worktree is clean,
-then merge/remove worktrees, then clear the lock) as its own step 5, mechanically, since
-intent 188: a session no longer needs a separate one-liner for it, and the script's own
-exit code (0) is the single fact a caller needs that the intent is closed AND its delivery
-lock is gone. A pre-flight lock guard runs before anything is written (refuses a live
-foreign session, reclaims a stale one with an audit line), and a dirty code worktree
-refuses before removal rather than force-discarding uncommitted changes.
-
-The post-done access window is lock-bounded: `[INDEX terminal -> Lock.release]`. Through it
-the completing session keeps full read and write access to the terminal directory and no
-purge can fire (108's lock-held keep-guard keeps the bridge while `delivery.lock` exists).
-Once the lock is released the window closes: the bridge becomes purge-eligible and the
-directory is frozen. A crash mid-tail is recovered by stale-lock reclaim plus finishing the
-tail; `doctor` surfaces this as a "stalled completion" (terminal in INDEX but the lock is
-still present or stale). Finishing the tail is FINISHING a completion, never a reactivation:
-a done intent is never moved back to `## Active`.
-
-One report per audience: a delivery produces `outcome.md` plus one EM-to-CTO owner report, and
-no other step restates either (see `skills/auto/references/human-report-contract.md`).

package/skills/dashboard/SKILL.md

@@ -1,169 +0,0 @@
----
-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 the intent store(s) as Markdown prose, the global board as a narrative of work done, each project board as a short summary plus its most-valuable next work, and emits a machine-readable queue that auto mode consumes.
-user-invocable: false
----
-
-# Dashboard — Plastic Work Cockpit
-
-A deterministic overview of the intent store(s). It answers three questions at a glance:
-**where we are** (recently worked), **where we go next** (the most-valuable next work), and
-**how to conduct it** (a disposition per intent). The human-facing surface is **Markdown**,
-because the user's UI renders Markdown natively but collapses raw tool-call stdout.
-
-The script does all the data work. The agent fills a Markdown template from the script's
-payload with near-zero reasoning and **presents the filled board in its reply**. Same store
-state → byte-identical payload, regardless of model. Do NOT hand-summarize intents.
-
-## When to Use
-
-- User invokes `/plastic-dashboard`
-- User asks "where are we", "what's next", "what should I work on", "show me the intents"
-- `plastic-intent-continuing` lands on the board on a bare resume
-- `plastic-auto` reads `--json` to choose the next dispatchable intent
-
-## Procedure (the Markdown board — default human surface)
-
-### Step 1 — Get the data payload
-
-```bash
-ruby ~/.plastic/scripts/dashboard.rb [continue|project <slug>] --data
-```
-
-- `continue` (default) → the **global** board payload (`mode: "global"`).
-- `project <slug>` → that **project** board payload (`mode: "project"`).
-
-The payload is read-only JSON. Global-board fields: `date`, `store_health`, `summary`,
-`next_work`, `next_total`, `next_shown`, `counts`, `projects`, `project_totals`, `footer`.
-Project-board fields: `slug`, `store_health`, `description`, `summary`, `counts`, `active`,
-`active_total`, `active_shown`, `next_work`, `next_total`, `next_shown`, `footer`. `summary`
-and `footer` are finished prose strings (2-3 sentences and one line respectively), built in
-`dashboard.rb` and substituted verbatim, exactly like `{{date}}`/`{{description}}` already
-are - never re-worded or re-derived by the skill. Each list carries cell-ready fields for
-its table: `next_work` rows are
-`{id, intent, scope, lifecycle, value, disposition, flags, what, flags_label, line}`;
-`active` rows carry
-`{id, intent, created, bullet, scope, what, stage, worker, activity, line}`. The `what`,
-`scope`, `worker`, `activity`, and `flags_label` cell fields arrive pipe-escaped and
-whitespace-normalized.
-
-Each board load runs the scoped store check (`doctor --store <scope>`): the global board runs
-`--store global` and a project board runs `--store <slug>`. The result rides in the payload as
-`store_health` (`{scope, status, summary, failing_checks}`). Surface it as a one-line
-store-health note on the board (for example `store health: pass (3/3)` or
-`store health: warn (orphaned_intents)`). It is non-fatal: a warn or fail is shown as data and
-never blocks the board.
-
-### Step 2 — Fill the matching template
-
-Templates live in this skill's `templates/` directory:
-`~/.claude/skills/plastic-dashboard/templates/dashboard-global.md` and
-`dashboard-project.md`.
-
-Fill mechanically, no rewriting, no re-sorting:
-- `{{a.b.count}}` → the integer (e.g. `counts.active` = that count).
-- `{{<list>.rows}}` → the two intent lists (`active`, `next_work`) render as **Markdown table
-  rows**. The template hard-codes each table's header and separator; this placeholder becomes
-  one data row per list entry, joined with real newlines, in that table's fixed column order
-  (below). Drop each cell from the named payload field **verbatim**: cells arrive pre-escaped
-  and whitespace-normalized from the script (pipes escaped as `\|`), so never re-escape,
-  re-truncate, or reword them. Never emit `<br>`.
-  - `next_work` → `| {id} | {what} | {value} | {disposition} | {flags_label} |`
-  - `active` → `| {id} | {what} | {stage} | {worker} | {activity} |`
-  Empty list → one full-width row with `_(none)_` in the Id column and every other cell blank,
-  matching that table's column count (e.g. `| _(none)_ | | | | |` for the 5-column next_work
-  table, `| _(none)_ | | | |` for the 5-column active table). Neither list carries an overflow
-  "+N more" row anymore (D5, intent 202): the true pool size rides on the payload as
-  `active_total`/`next_total` (shown counts as `active_shown`/`next_shown`), and `{{footer}}`
-  states it in prose instead.
-- `{{projects.lines}}` (global board only) → the project rollup stays **prose**, one line per
-  project (not a table):
-  `- **{slug}**: {description}, active {active}, done {done}, future {future}, last accessed {last_accessed_at[0,10]}`.
-- Scalars (`{{date}}`, `{{slug}}`, `{{summary}}`, `{{footer}}`) → substitute verbatim. `summary`
-  and `footer` are finished prose built in `dashboard.rb`; do not rewrite, shorten, or
-  re-derive them from the counts - that is exactly the non-determinism D5 rules out.
-
-### Paging (conversational, D4)
-
-The board shows a short page by default (Active capped at 3, Next-work at 5). When the
-user asks for "more" or "all", re-invoke Step 1 with an explicit flag and re-fill the
-template with the new payload - nothing is persisted to disk, the offset lives only in the
-chat turn:
-- "all" → add `--all` (lifts both caps to unbounded; the footer then shows equal shown/total).
-- "more" → add `--limit-active N`/`--limit-next N` with a larger `N` for whichever list the
-  user is paging.
-
-For a real, own-terminal pager instead, point the owner at `--plain`:
-`ruby ~/.plastic/scripts/dashboard.rb project <slug> --plain | less` (or `continue --plain`
-for the global board). `--plain` prints the full, uncapped board as plain text with no
-Markdown table syntax; it is a separate CLI mode from `--data`, not something this skill
-fills a template from.
-
-### Step 3 — Present it (mandatory, every invocation)
-
-**Paste the filled Markdown into your reply.** This is non-optional: if the reply does not
-contain the filled Markdown, the user sees nothing — tool-call stdout and hook
-`additionalContext` are both invisible to them. Never describe the board instead of showing
-it, and never assume a hook already showed it for you.
-
-`hook-continue` also emits a one-line `systemMessage` summary (counts, and the next big thing
-when there is one) as a hook-owned fallback, independent of the agent's reply. Treat that line
-as a floor only, not a substitute for this step: it carries no matrix, no recently-worked
-section, and no entry-flow prompt. Presenting the full board here remains mandatory regardless
-of whether the summary line fired. This stays a soft, agent-followed mechanism — there is no
-stronger enforcement for a full multi-section Markdown document in this harness today.
-
-### Step 4 — Entry flow (the board is the menu)
-
-QMD-first (when available): when the user navigates by describing an intent rather than giving its
-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. The command is
-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-intent-creating`).
-- On a **project** board, the user replies with an **intent id**, or **"global"** to return.
-
-## Auto-mode contract (`--json`)
-
-`plastic-auto` consumes a separate machine-readable manifest (unchanged):
-
-```bash
-ruby ~/.plastic/scripts/dashboard.rb [continue|project <slug>|all] --json
-```
-
-```json
-{ "generated_for": "auto-mode", "scope": "<scope|all>",
-  "next_big_thing": "<id|null>",
-  "dispatchable_queue": [ {"id","scope","disposition","type","value","effort","flags","rank"} ],
-  "human_only": ["<id>", "..."] }
-```
-
-Work `dispatchable_queue` in `rank` order (`defer`/`research`); leave `human_only` for the user.
-
-## Text modes (terminal / legacy)
-
-`dashboard.rb [continue|project <slug>|all]` with no flag still prints the ASCII cockpit for
-a raw terminal. The Markdown board (`--data` + template) is the surface for the chat UI.
-
-## How classification works (deterministic)
-
-The script computes Effort/Value/Flags/Override/Caps; the agent never re-derives them.
-To explain or debug a ranking or disposition, read `references/classification.md`.
-
-## Eval
-
-The eval is the payload + golden snapshots: run the engine against the fixture store and
-assert the `--data` payload shape/sorting/classification and the byte-identical `--json` +
-text goldens in [`test/fixtures/dashboard/`](https://github.com/zalom/plastic/tree/main/test/fixtures/dashboard). See [`dashboard_test.rb`](https://github.com/zalom/plastic/blob/main/test/dashboard_test.rb). Drift without an
-intentional change means the skill is broken.
-
-## Notes
-
-- The two intent lists (active, next work) render as Markdown tables; the prose summary,
-  footer, counts, and the project rollup stay prose (intent 202). No Value x Effort grid
-  returns. Never emit `<br>`.
-- Clusters (Zettelkasten grouping in INDEX.md) are intentionally not rendered.
-- Additive: changes no core lifecycle, gate, or cycle logic.