@zalom/plastic 1.0.3 → 1.1.1

package/skills/{research → intent-researching}/evals/evals.json

@@ -1,5 +1,5 @@
 {
-  "skill_name": "plastic-research",
+  "skill_name": "plastic-intent-researching",
   "notes": "Intent 66a. Spec for the QMD-first step before researching (reuse prior intents/reports before grep/Read or web search). Runner is intent 76; spec only.",
   "evals": [
     {

package/skills/{savepoint → intent-savepoint}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic-savepoint
+name: plastic-intent-savepoint
 description: Use when verifying or repairing an intent's savepoint ledger, when the user says "save" or "savepoint", or when a PreCompact hook fires. The ledger is written automatically by the gate hook at each lifecycle boundary; this skill only reads, verifies, and rebuilds it.
 user-invocable: false
 ---
@@ -42,6 +42,18 @@ Read the active store's `INDEX.md` and extract intents under `## Active`.
 - Confirm the **last line's stage** matches the stage derived from files-on-disk
   (`Bridge.derive_stage`). If they disagree, or the file is missing/empty, the ledger has
   drifted.
+- Run `Bridge.savepoint_phantom_lines(intent_dir)` (pure, disk-only, no bridge or session
+  resolution; intent 134). It flags a line disk evidence contradicts: a file-landing milestone
+  whose file is absent or still a sentinel placeholder, a duplicate `(stage, milestone)` pair, or
+  a state line (`How  started` / `Exec  started`) whose stage prerequisites are absent. If it
+  returns any lines:
+  - **LIVE intent (INDEX `## Active`):** rebuild via step 3 below.
+  - **INDEX `## Completed`/`## Abandoned` intent:** REPORT the phantom lines and STOP. Do not
+    rewrite. Completed intents are immutable. A repair is available only under an explicit human
+    grant, following the 124a precedent: rebuild the file-landing skeleton (step 3), then
+    re-append the terminal `Done  <disposition>` bookend with the disposition read from
+    `outcome.md`'s `disposition:` frontmatter and the timestamp recovered from the merge commit or
+    the file's mtime, never invented.
 
 ### 3. Rebuild on drift
 Reconstruct from the filesystem rather than hand-editing:

package/skills/intent-speccing/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: plastic-intent-speccing
+description: >
+  Consolidate the enriched Why (`## Context`, `### Decisions`, `## Insights`) into `spec.md`
+  through a deterministic, judgment-free numbered sequence. Use when the user types the command
+  to turn the brainstorm into a spec, asks to "write the spec", "spec this intent", "consolidate
+  into spec.md", or the active intent is at Why with enough Decisions on record to close it out.
+  Also fires on an indirect request that never names spec.md, such as "turn what we just
+  discussed into the contract the planner builds from." Distinct from `plastic-intent-brainstorming`
+  (the exploration that produces the enriched Why, upstream of this skill) and
+  `plastic-intent-planning` (turns an existing spec.md into plan.md for How, downstream of this
+  skill).
+user-invocable: true
+---
+
+# Intent Speccing
+
+Consolidate the enriched Why into `spec.md` through eight fixed steps, one action per step. The
+next action is never a judgment call: when a section cannot be filled from what is on record,
+step 5 is to stop and ask, never invent.
+
+## Precondition
+
+Run only when the active intent is at Why (its `## Intent` and enriched `## Context` plus
+`### Decisions` exist, `spec.md` does not yet exist or is being redone) and the user has asked to
+consolidate that Why into the spec. If no intent is active, or the active intent is not at Why,
+report that and stop; do not guess which intent is meant.
+
+## The 8-step sequence
+
+| Step | Action |
+|---|---|
+| 1 | Confirm the precondition above. |
+| 2 | Read inputs in fixed order and build a ruling ledger: (a) `## Context` and `### Decisions`; (b) `## Insights` newest-last, so a later ruling supersedes an earlier conflicting one; (c) `resources/discovery--<slug>.md`; (d) any other `resources/*.md`. |
+| 3 | Decide the tier: adopt the brainstorming `Tier:` recommendation from Decisions or Insights; otherwise apply the PLASTIC.md tiers rubric (S = single mechanism or file cluster, M = one subsystem, L = cross-cutting or novel design). |
+| 4 | Fill the template section by section, all 8 sections in template order. Read `references/per-section-fill-rules.md` now, filling the template is the trigger. Write the tier as the literal top line above `# Spec:`. Encode every ruling into its matching section, later supersedes earlier on conflict. A collapsed single-line S/M section is complete and valid; do not pad it. |
+| 5 | Gap rule: if any section cannot be filled from the ledger built in step 2, STOP and ask the user for the missing ruling. Never invent scope to fill a gap. |
+| 6 | State the gate position (below) so the user knows what happens next. |
+| 7 | Self-verify against the checklist. Read `references/self-verify-checklist.md` now, verifying before presenting is the trigger. Fix any failing check, then re-verify from the top. |
+| 8 | Present `spec.md` for the user-review gate, then hand off to `plastic-intent-planning` for How. |
+
+## Gate position (step 6)
+
+The Why stage's deliverable is `spec.md`; the gate is satisfied the moment a complete, real
+`spec.md` exists (this is the gates-by-name framing: gate-check enforces spec.md before plan.md,
+not the Transition Gates table row). Writing `plan.md` is what opens the code gate for Exec, and
+writing `plan.md` is not this skill's job, that is `plastic-intent-planning`. State this to the user
+at step 6 so the handoff at step 8 is expected, not a surprise.
+
+## Tier stamp (step 3, convention only)
+
+Write `Tier: S|M|L` as the literal first line of the file, above the `# Spec:` heading. This line
+is convention-only: the orchestrator and the planner read it, no gate and no doctor check
+validates it.
+
+## Completion report
+
+State, in this order: which file was written (`spec.md`, new or rewritten), the stamped `Tier:`
+value, the count of Acceptance Criteria produced (the surface the planner will cover), which
+`## Insights` rulings superseded an earlier Decision (if any) and where each landed, and the
+handoff target (`plastic-intent-planning`). If step 5 stopped for a missing ruling, report that
+instead: which section, what is missing, and the question put to the user.
+
+## References
+
+| Trigger | Read |
+|---|---|
+| Filling the template (step 4) | `references/per-section-fill-rules.md` |
+| Self-verifying before presenting (step 7) | `references/self-verify-checklist.md` |

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

@@ -0,0 +1,126 @@
+{
+  "skill_name": "plastic-intent-speccing",
+  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the intent-starting evals.json convention.",
+  "evals": [
+    {
+      "id": 1,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "The active intent is at Why with Context and Decisions recorded. Consolidate the enriched Why into spec.md.",
+      "expected_output": "Activates plastic-intent-speccing (the user-typed Why-to-How consolidation command).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-intent-speccing",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "Turn what we just discussed into the contract the planner builds from.",
+      "expected_output": "Activates plastic-intent-speccing; an indirect trigger that names neither the skill nor spec.md.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-intent-speccing",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "Brainstorm this intent.",
+      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-brainstorming (exploration that produces the enriched Why, upstream of speccing).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-intent-speccing",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "Write the plan.",
+      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-planning (turns an existing spec.md into plan.md for How, downstream of speccing).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-intent-speccing",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Intent Y is at Why: Context describes the problem and goal, and 5 Decisions are recorded resolving scope, approach, and one rejected alternative. Consolidate into spec.md.",
+      "expected_output": "Produces spec.md with Tier: S|M|L as the literal top line above the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "Tier line is literally the first line of the file; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 6,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Intent Z has Decisions recording D4: ship the setting as a CLI flag. A later Insights entry, timestamped after D4, reads: superseding ruling, ship as a config-file setting instead of a CLI flag, per user correction. Consolidate into spec.md.",
+      "expected_output": "The produced spec Approach and Decisions sections encode the LATER ruling (config-file setting); the superseded earlier Decision (CLI flag) does not stand as the shipped design in any section. The Decisions section notes that the later Insight supersedes D4.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "Approach and Decisions state the config-file setting, not the CLI flag; no section still asserts the CLI-flag path as the shipped design",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 7,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "Intent W is at Why. Context says the team wants error handling that is more resilient, but no Decision or Insight states which specific mechanism (retry, circuit breaker, or fallback) was chosen. Consolidate into spec.md.",
+      "expected_output": "Stops at step 5 (the gap rule) instead of inventing an Approach; asks the user which error-handling mechanism was decided, naming the missing ruling and the section it blocks.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "no invented Approach or Decisions content fills the gap; the agent asks for the missing ruling instead of guessing a default mechanism",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 8,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "Intent V has Decisions recording 3 rejected alternatives, each with a one-line reason it lost. Consolidate into spec.md.",
+      "expected_output": "Alternatives Considered renders as a table (Alternative, Not chosen because), not the bullet-dash form shown in the template; the produced spec file contains no em-dashes or en-dashes anywhere in the file.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "Alternatives Considered is a two-column table with one row per rejected alternative; a full-file dash-glyph scan of the produced spec file finds none",
+          "result": "expect-pass"
+        }
+      ]
+    }
+  ]
+}

package/skills/intent-speccing/references/per-section-fill-rules.md

@@ -0,0 +1,92 @@
+# Per-Section Fill Rules
+
+The single shared method for turning the enriched Why into `spec.md`. Both
+`plastic-intent-speccing` (guided) and the `plastic-spec-specialist` agent (auto) point here;
+neither restates these rules. One fill rule per template section, in template order.
+
+Read the ruling ledger first (built in step 2 of the SKILL.md sequence): `## Context` plus
+`### Decisions`, then `## Insights` newest-last (a later ruling supersedes an earlier
+conflicting one), then `resources/discovery--<slug>.md`, then any other `resources/*.md`.
+Every rule below names which part of that ledger feeds the section.
+
+## 1. Problem
+
+Source: the intent's `## Intent` line plus the problem narrative in `## Context`.
+
+State the problem as a problem, not a solution: what is broken, missing, or costly today, for
+whom. Do not describe the fix here, that belongs in Approach. If `## Insights` records a later
+reframe of the problem (a scope correction, a retargeted root cause), the later framing wins.
+
+## 2. Goals
+
+Source: explicit goal statements in `## Context`, plus any `### Decisions` entry that commits to
+delivering a specific outcome.
+
+One bullet per goal, each a concrete, observable outcome the delivery must reach. Encode every
+Decision that commits to an outcome as its own bullet, do not compress two Decisions into one
+vague goal. A single-line collapsed Goals section (S/M tier) is complete if it names every
+outcome; do not pad it with restated Problem text.
+
+## 3. Non-Goals
+
+Source: `### Decisions` entries that name something explicitly out of scope, and `## Insights`
+rulings that narrowed scope after the initial brainstorm.
+
+One bullet per excluded item, each naming what is out and, briefly, why (a sibling intent owns
+it, a scope-reframe ruling cut it, it is a future intent). If a later Insight narrows scope
+further than an earlier Decision, the Insight's narrower boundary is the one recorded.
+
+## 4. Approach
+
+Source: every `### Decisions` entry that describes HOW, resolved into one coherent narrative.
+
+Write prose, not a decision list. Synthesize the chosen path so it reads as one design: what
+gets built, in what shape, and how the pieces fit. Every Decision that shapes the approach must
+be traceable to a sentence here, but do not restate each Decision by its Dn label, that
+enumeration belongs in the Decisions section. Use a table only where the Approach itself compares
+options inline (rare; usually that comparison belongs in Alternatives Considered instead).
+
+## 5. Alternatives Considered
+
+Source: `### Decisions` entries and `## Insights` rulings that name a rejected path and the
+reason it lost.
+
+Render as a table, not the template's bullet-dash form, so the reason column stays uniform and
+free of dash-glyph punctuation:
+
+| Alternative | Not chosen because |
+|---|---|
+| <rejected path> | <the ruling's stated reason, paraphrased> |
+
+One row per rejected alternative. If two Decisions reject variants of the same alternative, merge
+them into one row rather than duplicating it. Never use an em-dash or en-dash in the reason
+column; write "because" or a colon instead.
+
+## 6. Decisions
+
+Source: `### Decisions` verbatim, in the order recorded, one entry per Decision.
+
+One bullet per decision, each keeping its `Dn` label and its ruling in paraphrase or verbatim.
+Do not drop a decision because it seems minor: every Decision must appear here even if its effect
+on the shipped Approach or Goals is small. When `## Insights` records a later ruling that
+supersedes an earlier Decision, add or amend the bullet to state the later ruling and note which
+earlier Decision it supersedes.
+
+## 7. Acceptance Criteria
+
+Source: any criteria named directly in `### Decisions` or `## Insights`, plus one inferred
+criterion per Goal that has no explicit criterion on record.
+
+One checkbox bullet per criterion, each concretely checkable: a fact a reviewer can confirm true
+or false by inspection, a command, or a file, never a vague quality judgment. Every Goal must map
+to at least one criterion. A criterion that cannot be checked without more interpretation is not
+done, rewrite it or ask (the gap rule, SKILL.md step 5).
+
+## 8. Open Questions
+
+Source: any question raised during Why that has no matching Decision or Insight resolving it.
+
+List each unresolved question as its own bullet. If every question raised during Why has a
+resolving Decision or Insight, write `None` and, directly under it, one line per resolved
+question naming which Decision or Insight resolved it (so a reader can audit the resolution
+instead of taking "None" on faith).

package/skills/intent-speccing/references/self-verify-checklist.md

@@ -0,0 +1,38 @@
+# Self-Verify Checklist
+
+Run this before presenting spec.md (SKILL.md step 7). Ten checks: the four points of
+brainstorming's proven Spec Self-Review, merged with the six binding output checks this skill
+adds. Fix any failing check, then re-verify from the top; do not present a spec that fails one of
+these.
+
+## Brainstorming's four Spec Self-Review points
+
+1. **Placeholder scan.** Any "TBD", "TODO", incomplete section, or vague requirement left in the
+   draft? Fix it before moving on.
+2. **Internal consistency.** Do any two sections contradict each other? Does the Approach
+   actually match what Goals and Acceptance Criteria describe?
+3. **Scope check.** Is this spec focused enough for a single implementation plan, or does the
+   Problem actually describe more than one independent piece of work that needs decomposing
+   first?
+4. **Ambiguity check.** Could any requirement be read two different ways? If so, pick one
+   reading and rewrite the line so only that reading survives.
+
+## The six binding output checks
+
+5. **No template placeholder text remains.** No literal `<intent name>`, `<alternative>`, `...`,
+   sample bracket text, or other template filler from `templates/spec.md` survives anywhere in
+   the artifact.
+6. **Tier stamp is the top line.** `Tier: S|M|L` is the literal first line of the file, above the
+   `# Spec:` heading, not folded into a section body.
+7. **All 8 sections present, in template order.** Problem, Goals, Non-Goals, Approach,
+   Alternatives Considered, Decisions, Acceptance Criteria, Open Questions, each present once, in
+   that order, none merged into another.
+8. **Every `## Insights` ruling is traceable to a spec line.** Walk the Insights log entry by
+   entry: each one lands in some section of the spec. Where two rulings conflict, the later one
+   (further down the log) is the one that landed, and the earlier one does not silently persist
+   in a different section.
+9. **Acceptance criteria are concretely checkable.** Each Acceptance Criteria bullet reads as a
+   fact a reviewer can confirm true or false by inspection, a command, or a named file, not a
+   quality judgment a reviewer would have to interpret.
+10. **No em-dashes or en-dashes anywhere in the artifact.** Scan the full file; replace any dash
+    glyph with a comma, period, parenthesis, or colon.

package/skills/intent-starting/SKILL.md

@@ -57,7 +57,7 @@ enforces it: without a held lock, mutating writes to this active intent's dir ar
 4. **Dispatch What-stage discovery (under the lock).** Right after arming, when the intent
    was just activated in step 1 (on a resume that already has
    `resources/discovery--<slug>.md`, skip: discovery runs once per intent, at activation
-   only), dispatch the `plastic-intent-discovery` agent (see the `plastic-intent-discovery`
+   only), dispatch the `plastic-intent-discovery` agent (see the `plastic-intent-discovering`
    skill), now that this session owns the lock, deposit authorized as the owner session. Resolve its
    model explicitly and pass it at dispatch time (belt-and-braces): `read-config
    agents.models.plastic-intent-discovery --project <repo>`. The agent runs QMD discovery
@@ -88,7 +88,7 @@ that message, never delete a lock file by hand.
 Read `savepoint.md` and classify from the **last line** alone, then verify ONLY that line's
 artifact is real (sentinel-aware via `Bridge.stage_file_present?`). On drift (the last line
 disagrees with files on disk), rebuild the ledger from disk and note the correction. Do not
-inline the rebuild; the `plastic-savepoint` skill owns it:
+inline the rebuild; the `plastic-intent-savepoint` skill owns it:
 ```bash
 ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'
 ```

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

@@ -40,7 +40,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "continue",
-      "expected_output": "Does NOT activate plastic-intent-starting; bare 'continue' is plastic-continuing (no specific intent named).",
+      "expected_output": "Does NOT activate plastic-intent-starting; bare 'continue' is plastic-continuing (the router, no specific intent named).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-starting", "result": "expect-pass" }
@@ -51,7 +51,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "create a new intent for the uploader retry policy",
-      "expected_output": "Does NOT activate plastic-intent-starting; activates plastic-creating-intent.",
+      "expected_output": "Does NOT activate plastic-intent-starting; activates plastic-intent-creating.",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-starting", "result": "expect-pass" }

package/skills/project-continuing/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: plastic-project-continuing
+description: >-
+  Use when the user wants to land on the project board, asks "what should I work on" in this
+  project, or wants active intents plus the most-valuable next work surfaced. This is the
+  default route of plastic-continuing for a bare "continue" with no specific intent or roadmap
+  named. It presents state and stops without asking how to proceed - that single mode question
+  lives in plastic-intent-starting, once the user names a specific intent to work.
+user-invocable: true
+---
+
+# Project Continuing - land on the board
+
+`plastic-project-continuing` is the project route of `plastic-continuing`. It lands on the
+Markdown board, presents active work and the most-valuable next work, and stops. It does not
+resume a specific intent by ledger (that is `plastic-intent-continuing`) and it asks nothing.
+
+## Continue (present the board)
+
+Land on the Markdown board via the `plastic-dashboard` skill. Rendering belongs there, not
+here - run the data payload and fill + present the matching template:
+- Project loaded -> `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
+- Otherwise (no project loaded, the global fallback) -> `ruby ~/.plastic/scripts/dashboard.rb continue --data`
+
+Fill the matching template from `plastic-dashboard`'s `templates/` and **present the filled
+Markdown in your reply** (every time, 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. `hook-continue` also emits a one-line `systemMessage` summary as a
+hook-owned fallback; treat it as a floor only, never as a substitute for presenting the full
+board here. See `plastic-dashboard` for the fill mechanics (`references/board-fill.md` has the
+scoped detail).
+
+The board load runs the scoped store check on every load (`doctor --store <scope>`): the
+global board runs `--store global` and a project board runs `--store <slug>`. The result
+arrives in the payload as `store_health`; surface it as a one-line store-health note. It is
+non-fatal (a warn or fail is shown as data, it does not block continuing).
+
+## Priority Order
+
+1. **Active intents first** - surface work in progress.
+2. **Project context** - if in a registered project, show governing + tactical intents.
+3. **Stale future intents** - surface for triage (see below).
+4. **Fresh future intents** - offer as next work.
+
+## Stale Future Intents
+
+If a future intent's `created` date is older than the configured `stale_threshold_days`
+(default 3), surface it for triage without taking action:
+
+```
+Stale future intents (no action taken):
+
+- [ID - name] (X days old)
+  a) Activate - start working on it now
+  b) Abandon - mark as abandoned
+  c) Defer to agent: implement | research | ideate
+  d) Auto - go fully autonomous (invokes plastic-auto)
+```
+
+When the user activates a future intent, move it to `## Active` in INDEX.md and auto-commit.
+
+**Defer to agent: research.** Selecting `research` is a real dispatch, not a label. Resolve
+`plastic-future-intent-researcher`'s model via `read-config agents.models.<basename> --project
+<repo>` (project override, then global, then the shipped tier default) rather than relying on
+bare frontmatter, which also honors a sanctioned `agents.models.<name>` override if one is
+configured. Dispatch the agent (Agent tool, `subagent_type: "plastic-future-intent-researcher"`)
+on the selected stale future intent, passing the resolved model explicitly. The agent writes its
+findings into that intent's `## Context` (see `agents/plastic-future-intent-researcher.md`); it
+does not itself dispatch further sub-agents. Once it returns, re-present the stale-future-intent
+triage so the user can act on the fresh findings now on record.
+
+## Deciding rules
+
+The board's ranked next-work order is deterministic, computed by `dashboard.rb`; this skill
+never re-derives it. Cite the rule NAMES only when explaining a ranking or disposition: Effort,
+Value, Flags, Override, Caps. Read `plastic-dashboard`'s `references/classification.md` for the
+definitions; do not restate or copy them here.
+
+## Then stop
+
+Present "here is the state, what next?" and wait. Offer active intents first, then future
+intents. Do not start executing work. The only follow-up from here:
+- User/agent names a specific intent to continue -> hand to `plastic-intent-continuing`
+  (which reads the ledger and, in turn, hands to `plastic-intent-starting` for the single
+  auto-or-guided ask).
+
+## Coordination
+
+Intent 149 has landed: the dashboard is demoted to prose (no Value x Effort grid). This skill
+was built against the live INDEX.md-parsing `--data` path (147, the DB cutover, has not
+landed). Its rule-name citations (`classification.md`, cited by name, not logic) and the
+`dashboard.rb project <slug> --data` -> `dashboard-project.md` path still resolve.
+
+Intent 148 landed: roadmaps are the primary planning surface. When the tier has a mid-flight
+roadmap (`ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <tier>/roadmaps` reports a `state`
+other than `none`), the roadmap route (`plastic-roadmap-continuing`) is the live surface for
+"what to work next", and `plastic-continuing` routes there. This board still presents project
+state and stops, asking nothing (unchanged): it does not itself dispatch, re-rank, or resume a
+roadmap. The global store and any project with no roadmap report `none`, so this board stays the
+default route for them.
+
+## References
+
+- `references/board-fill.md` - the template-fill mechanics and store-health surfacing detail.

package/skills/project-continuing/evals/evals.json

@@ -0,0 +1,100 @@
+{
+  "skill_name": "plastic-project-continuing",
+  "notes": "Intent 158a1. New project route, absorbing intent-continuing's Continue/Priority Order/Stale Future Intents sections (move, not duplicate). Scopes: description triggering (1-3) and behavior/convention compliance (4-10), the latter checked against SKILL.md.",
+  "results": {
+    "triggering": { "cases": 3, "passed": 3, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 7, "passed": 7, "evidence": "convention checks against skills/project-continuing/SKILL.md after the 158a1 extraction; id 10 (intent 170) added for the research-dispatch wiring of plastic-future-intent-researcher" }
+  },
+  "evals": [
+    {
+      "id": 1, "scope": "triggering", "set": "train",
+      "prompt": "what should I work on in this project",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 2, "scope": "triggering", "set": "train",
+      "prompt": "land me on the project board",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 3, "scope": "triggering", "set": "validation",
+      "prompt": "continue",
+      "expected_output": "Bare 'continue' with no specific intent or roadmap named reaches plastic-project-continuing via plastic-continuing's default route.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 4, "scope": "behavior", "set": "train",
+      "prompt": "Is dashboard selection project-aware?",
+      "expected_output": "Project loaded -> `dashboard.rb project <slug> --data` -> fills dashboard-project.md; otherwise -> `dashboard.rb continue --data`. Skill only invokes, does not render.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the board)' section", "result": "pass" }
+      ]
+    },
+    {
+      "id": 5, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill cite the classification rules by name instead of copying the logic?",
+      "expected_output": "SKILL.md's 'Deciding rules' section names Effort/Value/Flags/Override/Caps and points to plastic-dashboard's references/classification.md; it does not restate the rule definitions.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "rule names cited, no copied Effort/Value/Flags/Override/Caps definitions", "observed": "present in 'Deciding rules'", "result": "pass" }
+      ]
+    },
+    {
+      "id": 6, "scope": "behavior", "set": "train",
+      "prompt": "Does the project route ask 'auto or guided?' before stopping?",
+      "expected_output": "No. The project route presents state then stops; it asks nothing. The single ask lives in plastic-intent-starting once a specific intent is named.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "no 'auto or guided' ask anywhere in SKILL.md", "observed": "absent", "result": "pass" }
+      ]
+    },
+    {
+      "id": 7, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill present the board before stopping?",
+      "expected_output": "The filled Markdown board is presented in the reply (non-optional), then a 'Then stop' section waits for the user.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "presentation is mandatory and precedes the 'Then stop' wait", "observed": "present", "result": "pass" }
+      ]
+    },
+    {
+      "id": 8, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill carry the intent-149 coordination note?",
+      "expected_output": "A 'Coordination' section records that intent 149 has landed (dashboard demoted to prose, no Value x Effort grid) and confirms the rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'149' present with the landed coordination note", "observed": "present: 'Intent 149 has landed' with confirmed rule-name citations and dashboard.rb path", "result": "pass" }
+      ]
+    },
+    {
+      "id": 9, "scope": "behavior", "set": "validation",
+      "prompt": "Are Priority Order and Stale Future Intents present here and only here (not in intent-continuing)?",
+      "expected_output": "Both sections are present verbatim in this skill; they no longer exist in skills/intent-continuing/SKILL.md.",
+      "files": ["skills/project-continuing/SKILL.md", "skills/intent-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'## Priority Order' and '## Stale Future Intents' present here, absent from intent-continuing", "observed": "present here, absent there", "result": "pass" }
+      ]
+    },
+    {
+      "id": 10, "scope": "behavior", "set": "validation",
+      "prompt": "In the stale-future-intent triage, the user picks option c) Defer to agent: research. What happens?",
+      "expected_output": "A real dispatch, not a label: plastic-future-intent-researcher's model is resolved via `read-config agents.models.<basename> --project <repo>` (never bare frontmatter, sanctioned-override-aware), the agent is dispatched via the Agent tool on the selected stale future intent and writes its findings into that intent's `## Context`, then the skill re-presents the stale-future-intent triage.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "the 'Defer to agent: research' paragraph under Stale Future Intents resolves the model via read-config (not bare frontmatter), dispatches plastic-future-intent-researcher via the Agent tool, and re-presents the triage after the agent returns", "observed": "'Defer to agent: research.' paragraph present: resolves via read-config agents.models.<basename> --project <repo>, dispatches subagent_type plastic-future-intent-researcher, findings land in ## Context, then re-presents the triage", "result": "pass" }
+      ]
+    }
+  ]
+}

package/skills/project-continuing/references/board-fill.md

@@ -0,0 +1,33 @@
+# Board Fill Mechanics
+
+Depth reference for the "Continue (present the board)" section of `SKILL.md`. The fill itself
+is mechanical; `plastic-dashboard` owns the rules, this page is a pointer plus the detail that
+would otherwise bloat the SKILL.md body.
+
+## Fill rules (owned by plastic-dashboard, summarized here for convenience)
+
+- `{{a.b.count}}` -> the integer (e.g. `counts.active` is that count).
+- `{{...lines}}` -> join the list's `.line` strings with real newlines (one per line). These
+  are ordinary prose lines; never add a `-` prefix, never emit `<br>`. An empty list renders
+  `_(none)_`.
+- `next_work.lines` -> the most-valuable next work, already ranked and capped.
+- `active.lines` / `future.lines` (project board) -> one line per intent, already formatted.
+- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) -> substitute verbatim.
+
+No re-sorting, no re-summarizing, no hand-written prose replacing a line the payload already
+supplies. Same store state produces a byte-identical payload regardless of model.
+
+## Store-health surfacing
+
+Every board load runs the scoped `doctor --store <scope>` check server-side (inside
+`dashboard.rb`, not this skill). The payload carries the result as `store_health` (`{scope,
+status, summary, failing_checks}`). Render it as a single line, for example `store health:
+pass (3/3)` or `store health: warn (orphaned_intents)`. A warn or fail is informational only;
+it never blocks presenting the board.
+
+## Project vs. global fallback
+
+The project route's default target is the project board. When no project is loaded (the rare
+case where this route is reached without a registered project in scope), fall back to the
+global board payload (`dashboard.rb continue --data`) rather than failing. This mirrors the
+router's D6 default: a bare "continue" always lands somewhere useful.