@zalom/plastic 1.14.0 → 2.0.0-alpha.1

package/skills/conventions/references/gates-and-enforcement.md

@@ -1,53 +0,0 @@
-# Gates and Enforcement
-
-This chapter holds the escape-and-logging depth for each transition gate.
-
-#### Hook and skill naming and ownership
-
-The `plastic-` prefix is reserved for both surfaces: hooks `HookRegistry` registers and skills
-Plastic ships. A user-owned hook or skill must never take it: the installer purges Plastic's
-registrations from the agent's hook config on every update, matching by registry launcher name
-(current plus `RETIRED_HOOK_NAMES`), and doctor reports every violation it can find. On disk,
-`hooks_no_orphans` reports an unregistered `plastic-*` launcher file the registry does not know.
-In the live config, `hooks_entries_owned` (Claude) and `codex_hooks_entries_owned` (Codex)
-report a config entry that is neither a current registration nor recognizably ours, and,
-separately, a current registration whose launcher file is missing from disk. For skills,
-`stray_skills` reports a `plastic-*` skill directory the manifest does not track. Renaming or
-removing a hook from `events` means adding its old name to `RETIRED_HOOK_NAMES` in the same
-change, or every existing install keeps a dead registration.
-
-#### The gates by name
-
-Each gate guards one thing. `scripts/lib/hook_registry.rb` is the single source of truth for
-registration. On the edit path (Write, Edit, NotebookEdit, and MCP structural edits) five
-gates run inside one dispatcher process per write, in this fixed order with the first deny
-winning:
-
-- **savepoint-pre** appends the `started` savepoint ledger line before a write into an intent
-  directory; it records and never denies.
-- **lock-gate** arbitrates ownership and claims: it admits only the intent's lock owner or a
-  registered delegate to write into an active intent directory, and every deny names the
-  resolving `plastic-lock` command.
-- **code-gate** denies a code edit before How is delivered and a code edit outside the
-  provisioned worktree (stage rule or worktree rule, first match wins). It carries the audited
-  `# plastic-ok` escape described under bash-gate.
-- **links-gate** is the write-time belt for the `## Links` contract: hand-written links lines
-  that do not project from the `sources`/`chain` frontmatter are denied.
-- **create-gate** validates the proposed intent file at What write-time (Write, Edit, and MCP
-  edits), so a malformed or incomplete intent never lands.
-
-Alongside the edit-path dispatcher the registry defines:
-
-- **bash-gate** (on the Bash matcher) intercepts a write attempted through a bash or interpreter
-  one-liner (a heredoc, a `>` redirect, a `ruby -e` or `python -c` write), so the same rules
-  apply whether an edit goes through the Write tool or a shell. A trailing `# plastic-ok`
-  comment is an auditable escape that lets a deliberate command through, and every use is
-  logged to `~/.plastic/.cache/gate-escapes.log`. The code gate (Write and Edit) carries the
-  identical audited `# plastic-ok` escape, logged to the same file. The escape does not extend
-  to `NotebookEdit` or MCP structural edits: they are still gated, just without an escape hatch.
-- **gate-check** (PostToolUse on Write and Edit) enforces lifecycle stage order (spec.md before
-  plan.md, the plan triplet before the checklist, all checklist items before outcome.md).
-- **future-intent-check** (UserPromptSubmit) surfaces parked future intents whose keywords match
-  the user's message; like the other prompt-time hooks (continue, auto-arm, power-tools) it
-  informs and never denies.
-

package/skills/conventions/references/tiers-and-dispatch.md

@@ -1,135 +0,0 @@
-# Tiers and Dispatch
-
-This chapter holds tier depth beyond the S/M/L definition, the agent-model and dispatch mechanics, and the auto-mode human reporting contract.
-
-Speed comes from two levers only: artifact content depth and agent topology. The
-same-structure invariant holds: same file set, stage order, gates, and savepoint ledger at
-every tier and in both modes.
-
-S/M collapse the topology (one thinker agent writes spec.md then plan.md plus
-checklist.md plus at least one real action file in one context, consolidated into a single
-actions/ACTION_1.md at S/M and one file per task at L; a sonnet executor implements). L
-keeps the full team.
-
-Never cut at any tier: the independent reviewer, outcome.md as truth of delivery, the
-delivery lock, worktree isolation, intent creation via skill, INDEX as status truth, the
-QMD reindex at End.
-
-Guided mode is unchanged: full-depth artifacts, the human at every gate.
-
-Every lifecycle stage has exactly one dispatchable background agent, plus the enforcer that
-orchestrates them: see PLASTIC.md's Agent Models and Dispatch table for the stage-to-agent
-mapping (What, Why, How, Exec, Done).
-
-Final-gate code review stays an ad-hoc subagent the enforcer dispatches at the final gate, not
-a standing role.
-
-**The advisor: two consultation agents, never injected (intent 185).** Neither is a stage
-role: never in PLASTIC.md's Agent Models and Dispatch table, never dispatched by the auto
-pipeline, and neither ever touches a user's own session. `plastic-advisor` is the real advisor, ships `model: fable`,
-expensive, billed through usage credits. `plastic-faux-advisor` is the imitation advisor, ships
-`model: opus`, an ordinary model carrying the Operating Manual's reasoning discipline inlined
-in its own body (not injected into anything), so it reasons the same disciplined way at a
-fraction of the cost. The `plastic-agent-advisor` skill is the one front door: it teaches when
-consulting is worth the money (from the Advisor Protocol: buy one-way doors, plans, adversarial
-review, deadlocks, ranking; never buy what a tool can answer, code volume, or confirmation of a
-decision already made), routes to the configured agent, and can set the config on request. The
-user or the main session states a TIER (S, M, or L) and an EFFORT line in the brief; shipped
-effort is `xhigh` for `plastic-advisor` and `max` for `plastic-faux-advisor`.
-
-Config is harness-scoped, keys matching `InstallerCore::DEFAULT_AGENTS` exactly (`claude`,
-`codex`, `hermes`, never `claude_code`): `advisor.enabled` (false skips installing both agents and the
-skill), `advisor.claude.default` (which agent the skill routes to; an agent NAME never a model
-name, so it can point at a locally registered agent, and the only advisor routing key the
-installer writes). Each agent's actual model is a plain `agents.models.claude.<name>`
-override, the SAME harness-scoped mechanism every other agent uses, resolved through
-`InstallerCore#agent_model_overrides(harness:)`; there is no separate advisor-model key.
-`agents.models` is harness-scoped from this release (`agents.models.claude.*`,
-`agents.models.codex.*`), with the pre-existing flat form (`agents.models.<name>: value`)
-still honored as the claude harness and nested winning over flat. This closes a real latent
-bug: previously the same override map fed both the Claude frontmatter rewrite and the Codex
-TOML generator, so a literal Claude model id could leak into a Codex config; a model named
-under `claude` is now never emitted to `codex`. Install asks which advisor is the default
-(Claude Code only), with a plain description of each: Faux Fable (recommended, cheaper,
-available on any plan) or Fable 5 (the frontier model, billed through credits). Update asks
-the same question once when the key is unset, then never again. Claude-only for this release:
-the owner has not evaluated the Codex reasoning-model ecosystem long enough to judge it, so
-`generate_codex_agents` skips both agents by name, tracked at intent 186, not a permanent
-exclusion.
-
-**Auto-mode entry.** `plastic-auto` is the entry skill for autonomous delivery: it takes over How
-and Exec, spins up the stage-agent team named in PLASTIC.md's Agent Models and Dispatch table,
-and works the dashboard's dispatchable queue. The dashboard's
-`--data` output splits intents into a `dispatchable_queue` (work an agent can pick up) and
-`human_only` (intents that need a person); auto mode consumes the former.
-
-**Model contract.** Every agent in `agents/*.md` pins an explicit Claude Code model alias in
-its own frontmatter: `opus`, `sonnet`, or `haiku`. Never `inherit`, never Fable by default,
-unless an explicit `agents.models.<name>` config override names Fable for that role, in which
-case the override is honored as written. The two advisors, `plastic-advisor` and
-`plastic-faux-advisor`, are not lifecycle stage roles: the never-Fable rule governs stage
-agents only. Neither is ever dispatched by the auto pipeline; they are consultation roles
-summoned deliberately by the user or the main session, and their models are user configuration
-(fable and opus by default on Claude Code). Aliases track "latest
-per tier" so no Plastic release is required to advance a tier. The tier by role:
-`plastic-enforcer`, `plastic-brainstorming`, `plastic-planner` are `opus`;
-`plastic-spec-specialist`, `plastic-executor`, `plastic-intent-curator`,
-`plastic-future-intent-researcher`, `plastic-intent-discovery` are `sonnet`.
-
-**Config and installer mechanism.** `agents.models.<basename>` in a project's
-`<dir>/.plastic_store/config.yml` or the global `~/.plastic/config.yml` overrides one agent's
-tier. Precedence is project, then global, then the shipped default, matching every other
-`read-config` key. The installer applies the resolved override to each agent file's `model:`
-line at copy time (install, update, and repair, across every harness target). With no override
-configured, the shipped frontmatter passes through unchanged.
-
-**Dispatch-time contract.** Frontmatter is primary, and Claude Code reads it at dispatch, but
-because that read is a harness implementation detail rather than a contract Plastic controls,
-every dispatch site also resolves the target agent's model through the config chain
-(`read-config agents.models.<basename> --project <repo>`) and passes it explicitly at dispatch,
-belt-and-braces on top of the frontmatter pin.
-
-**Cross-harness portability.** The dispatch and model-tier contract above is harness-facing. The
-adapter layer that maps Plastic's hooks and model aliases onto each supported agent runtime
-(Claude, Codex, Hermes) is the cross-harness portability layer; see
-[`harness-adapters.md`](https://github.com/zalom/plastic/blob/main/docs/reference/harness-adapters.md) for the adapter contract.
-
-**Spawn preamble (intent 152).** `scripts/spawn-preamble` emits a live-state block purely from
-filesystem state: the active intent, stage, role/cycle-step, the honor instruction, and the
-report contract. When the intent's code worktree is resolvable and exists on disk, it also
-appends the worktree's absolute path plus a verbatim instruction to `cd` there directly, for
-harnesses whose `EnterWorktree` cannot discover a nested repo from a non-repo launch directory.
-Output is byte-identical when no worktree resolves.
-
-**Orchestrator advisory.** At auto-mode start, the orchestrator recommends once that the user
-run the main session on the best available thinking model (Fable, Opus, or whatever supersedes
-them). This is advisory only: it changes no behavior and blocks nothing if ignored, and it
-concerns the human's main session, never a dispatched subagent. The two advisors,
-`plastic-advisor` and `plastic-faux-advisor`, are not lifecycle stage roles: the never-Fable
-rule governs stage agents only. Neither is ever dispatched by the auto pipeline; they are
-consultation roles summoned deliberately by the user or the main session, and their models are
-user configuration (fable and opus by default on Claude Code).
-
-**`plastic-intent-discovery`.** The What-stage agent. It fires at intent activation, after the
-delivery lock is armed and before Why begins, running under that lock as the owner session (it
-does not acquire the lock itself and is not blocked by it): it reads the intent's
-`chain`/`sources` frontmatter, runs QMD-first discovery over completed predecessor work and
-related parked or future intents, and deposits findings to `resources/discovery--<slug>.md` in
-the intent directory ONLY. It never writes the intent file, `spec.md`, or any other lifecycle
-deliverable; the Why-stage `plastic-brainstorming` agent reads its deposit and enriches
-`## Context`.
-
-`savepoint.md`: a deterministic, append-only ledger of cycle-step milestones (one line per
-lifecycle boundary, newest at the bottom), written automatically by the gate hook. It is
-sugar on top of the conventions, not a source of truth: state is always derivable from
-files-on-disk, and the ledger is rebuildable. It exists so a resuming agent reads the cycle's
-succession at a glance (last line = where we are).
-
-### Auto-Mode Human Reporting (intent 92)
-
-In auto mode the orchestrator briefs the human at every lifecycle stage boundary in a fixed,
-impact-first shape (the EM-to-CTO report contract): State, then Risk, then Call. This is the
-depth at M and L; at S the briefing fires once, at How. It leads with
-what changed and why it matters, names one risk, and leaves the decision to the human. Wording
-rules for the briefing, and for authored prose such as specs, outcomes, READMEs, and release
-notes, are owned by the `writing-style` skill, not by this contract.

package/skills/doctor/references/gates-stuck-detection.md

@@ -1,43 +0,0 @@
-# Gate Enforcement and Stuck Detection
-
-## Bridge File Pattern
-
-`/tmp/plastic-{session}.json` is the hot cache; the filesystem is the authority.
-SessionStart rebuilds the bridge file from the filesystem — the bridge is always disposable.
-
-## Gate Taxonomy
-
-| Gate type | Purpose |
-|---|---|
-| **Pre-flight** | Prerequisites exist? |
-| **Revision** | New info invalidated prior work? |
-| **Escalation** | Blocked items surface to user |
-| **Abort** | Inconsistent state detected |
-
-## Full Gate Enforcement
-
-| Gate | Blocked action | Required prerequisite |
-|---|---|---|
-| Pre-flight | Cannot write `plan.md` | `spec.md` must exist |
-| Pre-flight | Cannot create `actions/` | `spec.md` must exist |
-| Pre-flight | Cannot write `outcome.md` | `checklist.md` must exist with all items checked |
-| Revision | Cannot proceed to Exec | Context changed after spec.md — re-derive spec |
-| Abort | Cannot complete intent | `outcome.md` exists but checklist has unchecked items |
-
-Hard blocking — hooks exit with code 2 when gates fail.
-
-## Stuck Detection
-
-No automatic stuck detector ships today: no threshold fires, and nothing forces a savepoint
-or escalates on its own. What exists is recorded data, and reading it is the diagnosing
-agent's judgment:
-
-- `build.gate_failures` in the bridge file: `scripts/hook-gate-check` increments it on every
-  blocked write and resets it to 0 on a passing one. Nothing reads the counter back; a high
-  value is a signal for you, not a trigger for the system.
-- `build.last_activity` in the bridge file: updated on passing writes. There are no
-  inactivity timers, and context pressure is not tracked anywhere.
-
-When diagnosing, treat repeated denies of the same gate with no station progress (compare
-the savepoint ledger) as stuck: stop, read the deny reason, and route through the resolving
-command it names.

package/skills/intent-brainstorming/SKILL.md

@@ -1,118 +0,0 @@
----
-name: plastic-intent-brainstorming
-description: "Explore intent requirements and design before implementation, through conversational prose questions asked one at a time (no multiple-choice chips), persisting each owner ruling immediately as an insight. Produces the enriched Why (Context and Decisions) in the active intent directory; hands off to /plastic-intent-speccing for spec.md."
-user-invocable: true
----
-
-# Brainstorming Ideas Into Designs
-
-Help turn ideas into fully formed designs through natural collaborative dialogue.
-
-Start by understanding the current project context, then ask questions one at a time, in prose, to refine the idea. Once you understand what you're building, present the design and collect the owner's rulings on it. This skill's product is the enriched Why, not spec.md.
-
-<HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has ruled on it. This applies to EVERY project regardless of perceived simplicity.
-</HARD-GATE>
-
-## Active Intent Gate
-
-Before proceeding, resolve the active intent:
-
-1. **Detect store:** Read `~/.plastic/projects.yml`, match CWD against registered project paths. If match → project store at `~/.plastic/projects/{slug}/store/`. If no match → global store at `~/.plastic/store/`.
-2. **Find active intent:** Read `INDEX.md` from the detected store. Look under `## Active`. If exactly one → use it. If multiple → ask which. If none → refuse: "No active intent. Create one first with /plastic-intent-creating"
-3. **Resolve intent directory:** `{store}/store/{id}--{slug}/`
-
-All artifacts go to the intent directory. Never write to external paths.
-
-## Anti-Pattern: "This Is Too Simple To Need A Design"
-
-Every project goes through this process. A todo list, a single-function utility, a config change: all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get a ruling.
-
-## Checklist
-
-You MUST create a task for each of these items and complete them in order:
-
-1. **Explore project context**: check files, docs, recent commits, read active intent
-2. **Grill in prose**: ask conversational prose questions, one at a time, no multiple-choice chips; understand purpose/constraints/success criteria
-3. **Propose 2-3 approaches**: with trade-offs and your recommendation
-4. **Present design**: in sections scaled to their complexity, get a ruling after each section
-5. **Collect rulings**: for each owner ruling, immediately persist it (see Collect rulings below); never batch
-6. **Hand off to /plastic-intent-speccing**: the enriched Why is done; do not author spec.md here
-
-## Process Flow
-
-The Checklist above states the ordered flow (steps 1-6). For the same flow as a
-diagram, read `references/design-principles.md`.
-
-**The terminal state is the handoff below.** Do NOT invoke any implementation skill and do NOT write spec.md. Brainstorming's product is the enriched Why.
-
-## The Process
-
-**Understanding the idea:**
-- QMD-first (when available): before scanning the store with grep/Read for prior decisions, specs, or outcomes, run `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate, prior, or related intents, then open the authoritative intent file for any hit you act on. The command is a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
-- Check out the current project state first (files, docs, recent commits)
-- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
-- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own Why → spec → plan → implementation cycle.
-- For appropriately-scoped projects, ask questions one at a time, in prose, to refine the idea
-- Ask conversational prose questions, not multiple-choice chips. A short menu of named options is fine when the choice is genuinely enumerable, but phrase it as a sentence, not a bulleted picker.
-- Only one question per message - if a topic needs more exploration, break it into multiple questions
-- Focus on understanding: purpose, constraints, success criteria
-
-**Exploring approaches:**
-- Propose 2-3 different approaches with trade-offs
-- Present options conversationally with your recommendation and reasoning
-- Lead with your recommended option and explain why
-
-**Presenting the design:**
-- Once you believe you understand what you're building, present the design
-- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
-- Ask after each section whether it looks right so far
-- Cover: architecture, components, data flow, error handling, testing
-- Be ready to go back and clarify if something doesn't make sense
-
-**Design for isolation and clarity, and working in existing codebases:** before
-proposing a design, read `references/design-principles.md` for unit-boundary
-guidance (what makes a good interface, when a file has grown too large) and
-existing-codebase guidance (follow established patterns, fold in targeted
-improvements without unrelated refactoring).
-
-## Collect rulings
-
-Each owner ruling triggers one immediate persist call, never a batch. The moment the
-owner rules on a question or a design section, before moving to the next one, run:
-
-```
-ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage Why --author human
-```
-
-When a later ruling conflicts with an earlier one already on record, append a new
-insight that names the superseded ruling and states plainly that this one supersedes
-it. Both insights stay on record; the later one wins.
-
-When presenting a batch of design options or rulings for the owner to choose, read
-`~/.plastic/_decision-tables.md` and follow the numbered-table procedure.
-
-## Handoff
-
-Why exploration complete. The enriched Why is captured (Context, Decisions, one
-insight per ruling). Invoke /plastic-intent-speccing to consolidate it into spec.md.
-Do not author spec.md here.
-
-## Gate position
-
-- **Before:** an active intent exists with the lock armed.
-- **Produces:** the enriched Why (`## Context`, `### Decisions`, one `## Insights` entry per ruling).
-- **Next:** /plastic-intent-speccing consolidates the enriched Why into spec.md.
-
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract this handoff relies on. This path resolves relative to this skill's own
-installed directory.
-
-## Key Principles
-
-- **One question at a time** - Don't overwhelm with multiple questions
-- **Prose, not chips** - Ask conversational prose questions; skip multiple-choice menus
-- **YAGNI ruthlessly** - Remove unnecessary features from all designs
-- **Explore alternatives** - Always propose 2-3 approaches before settling
-- **Incremental validation** - Present design, collect a ruling before moving on
-- **Be flexible** - Go back and clarify when something doesn't make sense

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

@@ -1,67 +0,0 @@
-{
-  "skill_name": "plastic-intent-brainstorming",
-  "notes": "Intent 66a. Spec for the QMD-first step in the Why/explore-context phase (surface prior decisions/specs/outcomes before grep/Read). Runner is intent 76; spec only. Intent 164 extended this file with the prose-grilling, conflict-supersession, and handoff-to-speccing scenarios; evals 2-4 are pending a real observed run per the plastic-evaluating-skills convention.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "QMD is present. Brainstorming the active intent during the Why phase, the agent needs prior decisions and specs on caching.",
-      "expected_output": "In the explore-project-context (Why) step, before scanning the store with grep/Read, runs `ruby ~/.plastic/scripts/qmd-sync search \"caching decisions\"` to surface prior decisions, specs, or outcomes, then opens the authoritative intent file for any hit it acts on. No-op fallback to INDEX.md / file scan when QMD is absent.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "qmd-sync search is run during Why before grep/Read; authoritative file opened for any hit",
-          "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"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "During Why exploration for intent X, the owner first rules that a setting ships as a CLI flag. Later in the same session, after more discussion, the owner rules that it should ship as a config-file setting instead, explicitly reversing the earlier call.",
-      "expected_output": "The skill persists BOTH rulings as separate insight-append calls with --stage Why: one for the CLI-flag ruling when it was made, and a second for the config-file ruling that names the CLI-flag ruling as superseded and states that this ruling supersedes it. Neither call is skipped, merged, or batched.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "two separate `ruby ~/.plastic/scripts/insight-append {intent_dir} \"<ruling text>\" --stage Why --author human` calls are made, one per ruling, immediately as each ruling lands; the second insight names the superseded CLI-flag ruling and states supersession",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Brainstorming a new intent about notification delivery, the agent needs to learn the owner's preferred channel (email, push, or SMS).",
-      "expected_output": "The agent asks a single conversational prose question about the preferred channel, one at a time, phrased as a sentence rather than a bulleted or lettered multiple-choice menu.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "the question is prose, not a chip/lettered multiple-choice menu; only one question is asked per message",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Design for intent Y is presented and the owner has ruled on every open section.",
-      "expected_output": "The skill states the enriched Why is captured (Context, Decisions, one insight per ruling) and invokes /plastic-intent-speccing as the handoff. It does not write spec.md itself.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "no spec.md write action is taken by this skill; the terminal message names /plastic-intent-speccing and states spec.md is not authored here",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}

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

@@ -1,145 +0,0 @@
-{
-  "skill_name": "plastic-intent-continuing",
-  "notes": "Intent 158a1: slimmed to the specific-intent resume route of plastic-continuing (D8, extract not duplicate). Bare 'continue' now belongs to the router; triggering evals 1-4 were recast so this skill's positives always name a specific intent, and eval 4 asserts bare 'continue' does NOT settle here directly. Behavior eval 11 (dashboard selection) was removed, relocated to plastic-project-continuing's evals. Behavior eval 15 is new: the terminal handoff goes to plastic-intent-starting, not directly to plastic-auto. Scopes: description triggering (1-8) and behavior/convention compliance of the ledger-resume skill (9-15).",
-  "results": {
-    "triggering": { "cases": 8, "passed": 8, "run": "2026-07-10, one subagent per case" },
-    "behavior": { "cases": 7, "passed": 7, "evidence": "convention checks against skills/intent-continuing/SKILL.md after the 158a1 extraction" }
-  },
-  "evals": [
-    {
-      "id": 1, "scope": "triggering", "set": "train",
-      "prompt": "continue intent 4a",
-      "expected_output": "Activates plastic-intent-continuing (a specific intent named by id).",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
-      ]
-    },
-    {
-      "id": 2, "scope": "triggering", "set": "train",
-      "prompt": "resume the statusline-coloring intent",
-      "expected_output": "Activates plastic-intent-continuing (a specific intent named by description).",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
-      ]
-    },
-    {
-      "id": 3, "scope": "triggering", "set": "validation",
-      "prompt": "continuing --intent 96",
-      "expected_output": "Activates plastic-intent-continuing (the --intent form).",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
-      ]
-    },
-    {
-      "id": 4, "scope": "triggering", "set": "train",
-      "prompt": "continue",
-      "expected_output": "Does NOT settle on plastic-intent-continuing directly. Bare 'continue' with no specific intent named belongs to the plastic-continuing router, which defaults to plastic-project-continuing.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "plastic-continuing", "result": "pass" }
-      ]
-    },
-    {
-      "id": 5, "scope": "triggering", "set": "train",
-      "prompt": "continue delivering this intent autonomously, don't ask me",
-      "expected_output": "Does NOT settle on plastic-intent-continuing for execution. Shares 'continue' but the autonomous-delivery intent routes to plastic-auto.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-auto", "observed": "plastic-auto", "result": "pass" }
-      ]
-    },
-    {
-      "id": 6, "scope": "triggering", "set": "validation",
-      "prompt": "continue the for-loop to the next iteration in this function",
-      "expected_output": "Does NOT activate plastic-intent-continuing. Near-miss: shares 'continue' but is a code-editing task.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "none", "result": "pass" }
-      ]
-    },
-    {
-      "id": 7, "scope": "triggering", "set": "train",
-      "prompt": "resume the paused background download",
-      "expected_output": "Does NOT activate plastic-intent-continuing. Near-miss: shares 'resume' but is unrelated to Plastic sessions.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "none", "result": "pass" }
-      ]
-    },
-    {
-      "id": 8, "scope": "triggering", "set": "validation",
-      "prompt": "what's the dashboard look like right now",
-      "expected_output": "Does NOT activate plastic-intent-continuing directly; an overview request without a specific intent named is a dashboard/project-board task.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "plastic-dashboard", "result": "pass" }
-      ]
-    },
-    {
-      "id": 9, "scope": "behavior", "set": "train",
-      "prompt": "Does the skill defer boot to the SessionStart hook rather than running it itself?",
-      "expected_output": "SKILL.md states boot (health check, core context, version banner, statusline) is owned by hook-session-start / plastic-statusline, not this skill.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "SKILL.md says boot is owned by the SessionStart hook and the skill does not run it", "observed": "'Boot is not this skill's job.' paragraph naming hook-session-start and plastic-statusline", "result": "pass" }
-      ]
-    },
-    {
-      "id": 10, "scope": "behavior", "set": "train",
-      "prompt": "Does the skill avoid running doctor / setting the statusline itself?",
-      "expected_output": "SKILL.md does NOT instruct running doctor.rb --core or setting the statusline; it attributes those to the hooks.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "no in-skill boot step invokes doctor.rb --core or sets the statusline; both are attributed to hooks", "observed": "doctor --core and statusline mentioned only as hook-owned in the 'Boot is not this skill's job' note", "result": "pass" }
-      ]
-    },
-    {
-      "id": 11, "scope": "behavior", "set": "validation",
-      "prompt": "Is ledger-resume conditional and ledger-driven?",
-      "expected_output": "Resume fires only when a specific intent is named; reads savepoint.md last line as stage, verifies the stage file, rebuilds on drift, derives next step from first unchecked checklist item.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "Conditional Ledger-Resume section reads last ledger line, verifies stage file, calls rebuild_savepoint on drift, uses first unchecked checklist item", "observed": "all four present in 'Conditional Ledger-Resume'", "result": "pass" }
-      ]
-    },
-    {
-      "id": 12, "scope": "behavior", "set": "validation",
-      "prompt": "Are the stale prose-savepoint fields gone?",
-      "expected_output": "No 'In progress' / 'Blockers' fields read from a prose savepoint remain; the ledger model is used instead.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "no prose-savepoint announce template (In progress / Blockers from prose)", "observed": "absent; announce uses Stage/Next step/Context/Drift derived from ledger + checklist", "result": "pass" }
-      ]
-    },
-    {
-      "id": 13, "scope": "behavior", "set": "validation",
-      "prompt": "Is the 'Determine Store' local-store gap filled?",
-      "expected_output": "Step 2 of Determine Store describes local/project-store detection (no empty step).",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "Determine Store step 2 documents local/project store detection via projects.yml + CWD match", "observed": "filled", "result": "pass" }
-      ]
-    },
-    {
-      "id": 14, "scope": "behavior", "set": "validation",
-      "prompt": "QMD is present. The user says: continue the work on the statusline coloring (names the intent by description, not id).",
-      "expected_output": "Before scanning the store with grep/Read to locate the named intent, runs `ruby ~/.plastic/scripts/qmd-sync search \"statusline coloring\"` to surface the candidate intent, then opens the authoritative intent file for the hit it resumes. No-op fallback to INDEX.md / file scan when QMD is absent.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "human", "check": "qmd-sync search is run before grep/Read when the intent is named by description; authoritative file opened for the hit", "observed": "Conditional Ledger-Resume 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" }
-      ]
-    },
-    {
-      "id": 15, "scope": "behavior", "set": "train",
-      "prompt": "Does the ledger-resume's terminal handoff go to plastic-intent-starting or directly to plastic-auto?",
-      "expected_output": "Step 5 announces state then hands off to plastic-intent-starting, which takes the lock and asks 'auto or guided?' exactly once; plastic-intent-starting's own auto branch is the one that hands to plastic-auto. This skill never hands to plastic-auto directly.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "step 5 hands off to plastic-intent-starting, not plastic-auto; the single ask is attributed to plastic-intent-starting", "observed": "present in 'Conditional Ledger-Resume' step 5", "result": "pass" }
-      ]
-    }
-  ]
-}

package/skills/intent-discovering/SKILL.md

@@ -1,56 +0,0 @@
----
-name: plastic-intent-discovering
-description: >-
-  What-stage context deposit at intent activation: run QMD discovery over the
-  intent's chain/sources and related parked intents, and write findings to
-  resources/discovery--<slug>.md for the Why stage to consume. Use when an intent
-  is activated (moved from Future to Active), after the lock is armed, under it,
-  and before Why begins. Never writes the intent file itself.
-user-invocable: false
----
-
-# Intent Discovery — What-stage context deposit
-
-Runs once, at intent activation, after the lock is armed and before Why. It gathers what is
-already known so Why does not start cold, and deposits it as a resource the
-Why-stage brainstorming agent reads.
-
-## When it fires
-Inside `plastic-intent-starting`, right after the bridge is armed, under the
-lock. Dispatched as the `plastic-intent-discovery` background agent.
-
-**Precondition for skipping: a size of S already on record, and no graph edges.** Read the
-activating intent's `chain` and `sources` frontmatter fields first. When a `Tier: S` line is
-already stamped at the top of `spec.md` AND both fields are empty, the pass does not run:
-write the single line `no chain/sources, discovery skipped` to
-`resources/discovery--<slug>.md` and stop there. Sizing happens at Why, which is after this
-stage, so a first activation usually has no size yet and the full pass runs. Never guess a
-size to unlock the skip. At M or L, or when either field is filled, run the full pass below.
-
-## What it does
-1. **Read the intent's links.** Load the activating intent file's `chain` and
-   `sources` frontmatter fields. If both are empty and a size of S is already on record, apply
-   the skip above and stop.
-2. **QMD-first discovery.** Search the Plastic stores with
-   `scripts/qmd-sync search "<terms>"` (or the `qmd` skill), scoped to the
-   relevant `plastic-*` collections, across completed predecessor work named in
-   `chain`/`sources` and any related parked/future intents in INDEX.md. Fall back
-   to ripgrep over the stores only when QMD is absent.
-3. **Deposit, never author.** Write findings to
-   `resources/discovery--<slug>.md` in the intent directory ONLY. Do not write
-   the intent file, spec.md, or any lifecycle deliverable. The lock-owner-only
-   write rule stays intact; the Why-stage `plastic-brainstorming` agent reads the
-   deposit and enriches `## Context`.
-   Shape the deposit tabular-first per `PLASTIC.md` (## Tabular-First Reporting, intent 160).
-
-## Stage coverage
-This is the What-stage agent in the one-agent-per-stage table (What:
-intent-discovery, Why: brainstorming + spec-specialist, How: planner, Exec:
-executor, Done: intent-curator).
-
-## Boundaries
-- Single output: `resources/discovery--<slug>.md`.
-- Does not ACQUIRE the delivery lock itself; it runs under the lock the
-  orchestrator armed, as the owner session (inherited session id), and is not
-  blocked by it.
-- Advisory input to Why, not a gate.