@zalom/plastic 2.0.0-alpha.8 → 2.0.1

package/skills/dashboard/references/classification.md

@@ -1,22 +0,0 @@
-# How Classification Works (Deterministic)
-
-The script (`dashboard.rb`) computes Effort/Value/Flags/Override/Caps deterministically;
-the agent never re-derives them. Read this to explain or debug a ranking or disposition.
-
-- **Effort** — small for `research`/`exploration`/`bugfix`, for already-scoped intents
-  (plan/checklist exists), or a **branch id** (folgezettel depth ≥ 2, e.g. `4a`, `12b3`); big
-  otherwise. A root id (a bare number) is always depth 1, so it is never demoted by this rule.
-- **Value → high** when any of: explicit `value: high`; a human-authored **root** intent; or
-  an intent that is a `source` of ≥1 other intent (it has spawned follow-on work). A purely
-  relational `chain` entry alone is **not** a value signal (intent 68) — else low.
-- **Flags** — `unblocked` only when a **future** intent has **all** its `sources` done AND at
-  least one source's completion date is strictly later than the intent's own `created` date (a
-  genuine wait, not a birth-time default); `in-progress` only when the savepoint ledger shows
-  real post-birth activity, not just the creation stamp; `stale` only on future intents past
-  the staleness threshold. All three kept low-noise by design.
-- **Override** — a `value: high|low` frontmatter field always wins (pre-stamped data, never
-  model judgment at render time).
-- **Caps**: the next-work list and the project board's `active`/`future` lists are capped at
-  8 entries plus a trailing "+N more" line; each entry's text is truncated to 120 characters
-  with a trailing ellipsis. Applies to the Markdown board only (the ASCII renderer has its own
-  separate `CELL_CAP`).

package/skills/dashboard/templates/dashboard-global.md

@@ -1,20 +0,0 @@
-# 🧩 Plastic · Global Board, {{date}}
-
-{{summary}}
-
-## Where we are
-
-{{counts.active}} intents active, {{counts.done}} done, {{counts.future}} queued for later.
-
-## Projects, active {{project_totals.active}}, done {{project_totals.done}}, future {{project_totals.future}}
-{{projects.lines}}
-
-## Most-valuable next work
-
-| Id | What | Value | Disposition | Flags |
-| --- | --- | --- | --- | --- |
-{{next_work.rows}}
-
-{{footer}}
-
-**What would you like to work on next?** (type an **intent id**, a **project name**, or anything **new** you'd like to start)

package/skills/dashboard/templates/dashboard-project.md

@@ -1,19 +0,0 @@
-# 📦 {{slug}} · Project Board, {{date}}
-
-{{summary}}
-
-**Active**
-
-| Id | What | Stage | Worker | Activity |
-| --- | --- | --- | --- | --- |
-{{active.rows}}
-
-**Most-valuable next work**
-
-| Id | What | Value | Disposition | Flags |
-| --- | --- | --- | --- | --- |
-{{next_work.rows}}
-
-{{footer}}
-
-**What would you like to work on next?** (type an **intent id**, or **global** to go back)

package/skills/direct/SKILL.md

@@ -1,66 +0,0 @@
----
-name: plastic-direct
-description: Use when a prompt asks for a change, a fix, an edit, a file, or an answer, and no thinking conversation is open on an intent. Judges whether the work is small enough to run right now, asks one clarifying question when one answer would settle it, or offers a thinking intent when it would not. Do not use for a prompt that says "auto" or "continue", a prompt asking to start a new intent, or a prompt inside an open thinking conversation, which belong to plastic-auto, plastic-intent-continuing, plastic-intent-creating, and plastic-intent-speccing.
-user-invocable: false
----
-
-# Direct mode
-
-Route the prompt in one read, then act. Direct work runs inline in this session, never through a
-dispatched agent, unless the user asks for agents.
-
-## 1. Estimate before you start
-
-Judge the prompt alone, before doing any of the work:
-
-1. Count the targets the prompt names, or that one grep finds.
-2. Require each change to be a named operation on a known target (rename this, add a check there,
-   delete that line), not an outcome ("clean it up", "make it faster").
-3. Budget about one minute per target and sum.
-4. At or under five minutes, run it now. Five minutes is an owner ruling, not a measured
-   threshold.
-5. A bounded sum above five minutes, offer a dedicated intent.
-6. An unknown target, or a change described only by its outcome, cannot be bounded. Ask one
-   question when one answer would supply the missing operation or target. Otherwise offer a
-   thinking intent. A target that only investigation can find is never settled by one
-   question.
-
-Tests or a build the prompt implies do not count against the budget. Verification is part of
-direct work, not a reason to leave direct mode.
-
-## 2. One question, then run
-
-A clarifying question is allowed in direct mode and does not by itself turn the request into a
-thinking intent. Ask one, then run. If the answer is still vague, offer a thinking intent rather
-than asking a second question or guessing.
-
-## 3. The routes
-
-| What the prompt looks like | Where it goes |
-|---|---|
-| Clear, and bounded at or under five minutes | Run it now, inline |
-| Clear, but the bounded estimate is above five minutes | Offer a dedicated intent, `plastic-intent-creating` |
-| Vague, and one answer would resolve it | Ask one clarifying question, then run |
-| Still vague after that one answer | Offer a thinking intent, `plastic-intent-speccing` |
-| Phrased as needing help rather than as an instruction | Offer grill plus a thinking conversation, `plastic-intent-speccing` |
-| Says "auto" explicitly | Hand off to `plastic-auto` |
-
-Read `references/request-signals.md` when a prompt sits on the boundary between two routes, for
-the 15 observable signals and the response each one selects.
-
-## 4. Record and verify
-
-- Verification in direct mode is the UI, the tests, or the user. There is no reviewer agent per
-  item.
-- Only a prompt that changes something on disk or produces an artifact becomes a checklist item.
-  A pure question is answered inline and recorded nowhere.
-- Direct work records into the day ledger that the per-session pointer names. Assume the pointer
-  exists. Never write it.
-
-## 5. What direct does not take
-
-The capture hook detects `auto` and `continue` before you read the prompt, so defer rather than
-keyword-match them yourself. `auto` goes to `plastic-auto`, and `continue` goes to
-`plastic-intent-continuing`. On `auto` with no registered intent, route through
-`plastic-intent-creating` first, because auto requires a registered intent. A prompt that arrives
-inside an open thinking conversation belongs to that conversation, not here.

package/skills/direct/references/request-signals.md

@@ -1,59 +0,0 @@
-# Request signals
-
-The table below is reproduced from
-`296--make-plastic-faster-small-work/resources/research--request-analysis.md`, the
-request-analysis research deposit of intent 296, with its source column renumbered against the
-eight-source list below. Read it when a prompt sits on the boundary between two routes. That
-deposit also carries seven worked examples, one per boundary, for a reader who wants them.
-
-## The signal table
-
-| Signal | What it looks like in a real prompt | Response it selects | Source or ruling |
-|---|---|---|---|
-| A concrete file and a concrete operation are named | "Rename `foo` to `bar` in `app/models/user.rb` and update its three callers." | execute now | D13, D14 |
-| The target is a single, already-known location | "Fix the typo in README.md line 12." | execute now | D14 |
-| The change is described only by its outcome, with no operation named | "Clean up the user model, it's gotten messy." | ask one clarifying question | Kamsties, "Understanding Ambiguity in Requirements Engineering" (source 5); D13 |
-| The prompt uses weak, hedging modal language ("might", "could", "maybe", "somewhere") | "This might need better error handling somewhere in the payment flow." | ask one clarifying question | "Automatic Detection of Ambiguous Terminology for Software Requirements" (weakness ambiguity, source 6); D13 |
-| The prompt admits several equally plausible readings with no cue that favors one | "Make the form better." (styling, validation, and accessibility are all live readings) | ask one clarifying question | "Knowing but Not Showing" (source 3); "Ask or Assume?" (source 1) |
-| One answer to the clarifying question fully resolves scope | User answers: "Just the null check on line 42, nothing else." | execute now | D10 |
-| The answer to the clarifying question is itself vague or open-ended | User answers: "I don't know, whatever seems right." | offer a thinking intent | D13; "Ask or Assume?" (source 1) |
-| The prompt is phrased as a request for help rather than an instruction | "I need help figuring out how to structure the billing refactor, not sure where to start." | offer a thinking intent | D13 |
-| The number of named or discoverable targets is small (roughly one to three) and each change is additive | "Update the copyright year in these three footer partials." | execute now | D14 |
-| The number of targets is large, or the work is described as spanning many files | "Migrate all 40 view partials to the new component library." | offer a thinking intent | D14 |
-| The target is not yet known and must be found by investigation before any edit is possible | "Something is causing the checkout page to be slow, find it and fix it." | offer a thinking intent | D14; sources 7 and 8 |
-| The action is destructive or hard to reverse and its scope is ambiguous | "Delete the old migrations directory." | ask one clarifying question | "Structured Uncertainty guided Clarification for LLM Agents" (source 4) |
-| The action is destructive but small, self-contained, and obviously scoped | "Delete the unused `tmp_debug.rb` file I just created." | execute now | D14 |
-| The request implies running tests or a build step the agent can run itself as part of verification | "Fix the failing test in user_test.rb." | execute now | D15 |
-| The prompt changes nothing on disk and produces no artifact | "What does the PaymentProcessor class do?" | execute now (answered inline; never admitted as a checklist item) | D17 |
-
-Row 8 uses the deposit's wording. Ruling D13 makes the help-needed route grill plus a
-thinking conversation, as `SKILL.md` section 3 states.
-
-## Rulings, not findings
-
-Four things in the table above are owner rulings with no literature behind them. Apply
-them, and know they are policy knobs the owner can turn, not measured results.
-
-- The five-minute total and the one-minute-per-target budget. Task-complexity research (sources 7
-  and 8) correlates target count and search depth with lower agent success, which supports
-  counting targets, but no source sets these numbers.
-- The one-question cap. The clarification research (sources 1, 2, and 4) treats question count as
-  a calibrated, cost-weighted choice that can be zero, one, or more. A hard cap of one is the
-  owner's choice.
-- "Auto" meaning auto mode. It is an interface convention, a keyword that names the mode instead
-  of asking for a judgement.
-- "Help needed" phrasing meaning grill plus a thinking conversation. It is a register cue
-  specific to how this owner phrases requests, not a general finding.
-
-## Sources
-
-1. "Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents." https://arxiv.org/abs/2603.26233
-2. "Learning to Ask: When LLM Agents Meet Unclear Instruction." EMNLP 2025. https://aclanthology.org/2025.emnlp-main.1104.pdf
-3. "Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions." https://arxiv.org/pdf/2605.25284
-4. "Structured Uncertainty guided Clarification for LLM Agents." https://openreview.net/forum?id=dc8ebScygC
-5. Kamsties, Erik. "Understanding Ambiguity in Requirements Engineering." https://link.springer.com/chapter/10.1007/3-540-28244-0_11
-6. "Automatic Detection of Ambiguous Terminology for Software Requirements." https://www.eecis.udel.edu/~yuewang/paper/nldb2013.pdf
-7. "An Approach for Systematic Decomposition of Complex LLM Tasks." https://arxiv.org/html/2510.07772v1
-8. "On the Importance of Task Complexity in Evaluating LLM-Based Multi-Agent Systems." https://arxiv.org/html/2510.04311
-
-All eight were accessed 2026-08-29. The D-numbers in the table are decisions in `296/spec.md`.

package/skills/doctor/SKILL.md

@@ -1,299 +0,0 @@
----
-name: plastic-doctor
-description: Use when diagnosing Plastic installation health, after updates, or when something seems broken. Runs checks and reports findings with fix options.
-user-invocable: true
----
-
-# Doctor: Plastic Health Check
-
-## Scopes
-
-Doctor has three scopes. Pick the right one for the situation:
-
-| Scope | Flag | When it runs | States |
-|-------|------|--------------|--------|
-| Core check | `--core` | SessionStart hook (automatic), also available on demand | Binary: pass or error |
-| Store check | `--store [global\|<slug>]` | Dashboard load, the project route of `plastic-intent-continuing` | Three-state: pass / warn / fail |
-| Full check | (no flag) | After every update (automatic), or `/plastic-doctor` | Three-state: pass / warn / fail |
-
-### `--core` (binary, operational-readiness only)
-
-Checks ONLY that Plastic is loaded and ready for work: agent registration (skills,
-subagents, hooks/harnesses present and registered), core files (manifest-backed
-presence/hash checks, excluding `agent_model_drift`, which is a non-boot
-config-honoring check, never run at core), manifest sync (global + agent manifest
-SHA256), every registered project's path resolving to a real, existing directory,
-and the global store being reachable (`INDEX.md` present; no orphan/ghost content
-scanning). Result is binary: exit 0 on pass, non-zero on error. It never produces
-warnings, and it never scans store content.
-
-It checks two install manifests as part of core files and manifest sync:
-
-- `~/.plastic/manifest.json` (global manifest, covers PLASTIC.md and global scripts)
-- `~/.claude/plastic/manifest.json` (agent-side manifest, covers agent scripts and hooks)
-
-Each manifest maps a file path to its SHA256.
-
-**On failure**, the report states this guided route, in order:
-
-1. Offer fixes in the `/plastic-doctor` conversation (the Fix all / Select individually /
-   Skip router from Steps 4-5 below); doctor itself only reports, and each chosen repair
-   is dispatched to the maintenance tool or skill that owns it.
-2. If that does not resolve it, roll back to the last known-good version via
-   `plastic-rollback` (restores from the local, append-only `versions.json` ledger of
-   versions actually run).
-3. Optionally report the issue via the feedback command (`scripts/feedback-report`,
-   backing the `plastic-feedback` skill), which composes a local report plus a
-   prefilled GitHub issue URL and never holds a credential or contacts GitHub
-   directly.
-
-### `--store [global|<slug>]`
-
-Checks the operations Plastic itself depends on in one store: QMD search reachability (scoped
-to that store's own collection; global uses `plastic-global`, a project slug uses
-`plastic-<slug>`), sources/chain resolution, cross-store resolution, INDEX parsing, links
-projection, done signals (including `backfilled_complete`: a terminal intent still missing a
-real spec.md, plan.md, or action file), and, for the global store only, the session ledger
-(`orphaned_session_tmp`: a `.tmp/<session>/` directory whose heartbeat is older than 24
-hours; `day_ledger_shape`: a `.sessions/` entry that is not a `YYYYMMDD` day directory with
-its `<day>.md`). A project slug also checks tool readiness (Serena, Enola): each is a pass whether
-present or absent, present naming it available, absent noting it as an optional integration
-never installed by doctor. Scope options:
-
-- No argument (`:all`): checks all stores (global and all project stores), QMD reachability
-  unscoped across every collection.
-- `global`: checks only the global store, QMD scoped to `plastic-global`, no tool-readiness
-  checks (code-navigation tools have no meaning against the global store).
-- A project slug (e.g. `--store plastic`): checks only that project's store, QMD scoped to
-  `plastic-<slug>`, plus Serena/Enola readiness for that project.
-
-Produces three-state results (pass / warn / fail) and is run per-scope at dashboard load time:
-the global board uses `--store global`, a project board uses `--store <slug>`. **This IS the
-load-time full project check** named by 219's doctrine: no separate mechanism exists or is
-needed, since a project slug's scan already carries every per-project finding scoped to that
-project alone.
-
-### Full doctor (no flag)
-
-Runs the install-wide surface: agent registration, core files (including config-honoring
-drift), manifest sync is core-only and not part of this run, deprecation checks, config-ask
-checks, install-integrity checks, skill-lint (advisory), QMD reachability (unscoped, every
-collection), and the global store's own conventions/done-signals content. **Never carries a
-per-project finding**; that is `--store <slug>`'s job (see above). This is what
-`/plastic-doctor` invokes, and it also runs automatically after every `plastic-update`
-(informational, does not block or revert the update).
-
-## When to Use
-
-- User invokes `/plastic-doctor` (full check)
-- After `plastic-update` completes (automatically, full check)
-- When hooks aren't firing, skills aren't loading, or something seems broken
-- When the user says "check plastic", "diagnose", "what's wrong with plastic"
-
-## Procedure
-
-### Step 1: Run the diagnostic script
-
-```bash
-ruby ~/.plastic/scripts/doctor.rb --agent claude
-```
-
-Replace `claude` with the current agent type if known (`codex`, `hermes`).
-
-Parse the JSON output from stdout. The script is read-only and never modifies
-files. Errors go to stderr.
-
-Exit codes indicate check results, not script failure:
-- `0`: all checks passed
-- `1`: warnings found
-- `2`: failures found
-
-All three exit codes mean the script ran successfully. Do not treat non-zero
-as an error.
-
-### Step 2: Determine overall status
-
-Read the `status` field from the JSON root:
-
-| Status | Meaning |
-|--------|---------|
-| `pass` | Everything is healthy |
-| `warn` | Warnings found but Plastic works normally |
-| `fail` | Blocking issues that prevent Plastic from operating |
-
-### Step 3: Fill the report template
-
-Read `report.md` from the same directory as this SKILL.md
-(`~/.plastic/skills/doctor/report.md` at runtime, or the plugin source
-`skills/doctor/report.md` during development).
-
-Group checks by category. For each category, list the checks with their
-status icon and message. If a check has `details`, list them as sub-items.
-
-Present the filled template to the user.
-
-### Step 4: Offer fixes (if applicable)
-
-If any checks have `fixable: true` AND status is not `pass`:
-
-1. Group fixable items by category
-2. Show what each fix would do (from `fix_hint`)
-3. Ask the user: **"Fix all / Select individually / Skip"**
-
-If no fixable issues exist, skip this step.
-
-This "Fix all / Select individually / Skip" prompt IS the router the spec calls
-`doctor --fix-all` (intent 197): doctor itself never mutates anything (see Step 5's table and
-"Important Notes" below); "Fix all" means "dispatch every fixable finding to the maintenance
-tool or skill that owns that class of repair," one row per fix_hint pattern.
-
-### Step 5: Apply fixes
-
-Use the `fix_hint` value to determine the correct action:
-
-| Fix hint pattern | Agent action |
-|---|---|
-| "chmod +x on the listed files" | Run `chmod +x` on each file listed in `details` |
-| "Create missing directory" | Run `mkdir -p` on the path |
-| "Create INDEX.md with required sections" | Write INDEX.md with the 5 sections: Active, Future, Clusters, Abandoned, Completed |
-| "Add missing entries to INDEX.md" | Add orphaned intents to the appropriate INDEX.md section |
-| "Remove stale references from INDEX.md" | Edit INDEX.md to remove ghost references |
-| "Inject the missing required frontmatter field(s)" | Edit the intent's `{ID}--{slug}.md` frontmatter to add the missing key (e.g. `chain: []`) without touching other keys |
-| "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (see Provisioning a project store below) to create the missing store |
-| "Re-run installer" | Run `npx -y @zalom/plastic@<channel> install --claude` (or `--codex`/`--hermes`/`--all` for that agent; channel: -alpha->@alpha, -beta->@beta, else @latest) |
-| "Run the Plastic installer to bootstrap the store" | Run `npx -y @zalom/plastic@<channel> install --claude` (or `--codex`/`--hermes`/`--all`; channel: -alpha->@alpha, -beta->@beta, else @latest) to restore the global store's plastic_home directory or INDEX.md |
-| "Relocate ... revisions.md ..." | Relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per plastic-conventions > references/maintenance-and-revisions.md. For a missing required section, restore or reproject it instead. |
-| "Write the missing documents from the record via `scaffold-intent backfill ...`" | Run `ruby ~/.plastic/scripts/scaffold-intent backfill --store <store> --id <id> --disposition <delivered\|abandoned>` for each listed intent; it fills only missing or placeholder files and never touches real content |
-| "Remove each listed .tmp/<session>/ directory after confirming that session is gone" | For each listed directory, confirm no live session uses it (a live session rewrites its heartbeat on every prompt and edit), then remove that directory by hand; never remove an unlisted one |
-| "For a day directory missing its <day>.md, run `file-session-intent --day <day> ...`" | Run `ruby ~/.plastic/scripts/file-session-intent --day <day> --carry-to <today> --store <store>` for the named day; rename or remove an entry that is not a `YYYYMMDD` day directory |
-| "Run scripts/project-links ... PRESERVES ... --drop-unbacked-links" | Run `ruby ~/.plastic/scripts/maintenance-run --tool project-links --intent <id> --apply` for the one flagged id (never run bare `project-links` against a real store outside the rare owner-approved batch exception, D2) |
-
-For fixes the agent cannot handle automatically, explain what the user needs
-to do manually. The `revisions.md` remedy is curator-applied (a move-and-record
-relocation, not a mechanical edit) and stays human-gated by the Step 4
-Fix / Select / Skip prompt.
-
-Read `../plastic-conventions/references/maintenance-and-revisions.md` for WORK versus
-MAINTENANCE, the `revisions.md` move-and-record contract, and the violation-tag catalog behind
-the `revisions.md` remedy above.
-
-### Step 6: Verify
-
-After applying fixes, re-run the diagnostic script:
-
-```bash
-ruby ~/.plastic/scripts/doctor.rb --agent claude
-```
-
-Show the updated results.
-
-- If all checks pass: announce success.
-- If issues remain: explain what is still wrong and what the user can do.
-
-## Post-Update Mode
-
-When invoked from `plastic-update` (not directly by the user):
-
-1. Run the diagnostic script as in Step 1.
-2. If all checks pass, show a single line: **"Health check: all clear."**
-3. If issues are found: show the full report (Steps 3-6).
-
-This keeps the update flow clean when nothing is wrong.
-
-## Important Notes
-
-- The script is **read-only**. It inspects but never modifies files.
-  All fixes are performed by the agent using standard tools.
-- The script outputs JSON to stdout. Any diagnostic errors go to stderr.
-- Non-zero exit codes mean "issues found", not "script crashed".
-  Always parse stdout regardless of exit code.
-
-## Doctor-Exclusions: Known-Exempt Findings
-
-Some `savepoint_operational` findings can never legitimately close (a terminal intent with no
-real `outcome.md` has no disposition to echo, and doctor never invents one), so each store
-carries a `doctor-exclusions` file, sibling to that store's `INDEX.md`, recording
-knowingly-exempt `(intent_id, rule)` pairs. Format: one `rule_name id id id` line per rule,
-blank lines and `#` comments ignored. v1 honors exactly one rule, `savepoint_operational`.
-
-**Reading the count.** When any exclusion applies, the `savepoint_operational` check's message
-folds in the count and the file's path, e.g. `"... (3 excluded via ~/.plastic/doctor-exclusions)"`.
-A malformed line in the file forces the check to `warn` with the parse error in `details`, even
-when zero real gaps remain, so a broken file is never silently permissive.
-
-**Both surfaces, one line.** A registration is honored by the store-wide `savepoint_operational`
-check and by the per-intent `doctor.rb --intent <id>` run, which reports the same missing
-`savepoint.md` under the check name `intent_savepoint_truthful`. Register the id once. The
-per-intent run honors it only for an intent that is terminal in `INDEX.md`, and never suppresses
-a phantom-savepoint-line finding.
-
-**Hand-editing.** The file is plain text; add a line (or append ids to an existing rule line) and
-save. No installer step, no reindex, and no `revisions.md` entry is required or written.
-
-**Populating it in bulk.** Run the maintenance tool, dry-run first:
-
-```bash
-ruby ~/.plastic/scripts/maintenance-run --tool register-exclusions
-```
-
-This computes every current `savepoint_operational` violation across all stores (or one store
-via `--store <key>`), through doctor's own finding function, and prints what it would register
-without writing anything. Review the output, then re-run with `--apply` to write the file(s) and
-land one scoped git commit. It unions with any existing hand-added ids (never drops one) and
-skips, rather than aborts on, any intent dir holding a fresh delivery lock.
-
-**Dead-row notice.** A registered row can go dead (gap repaired, id mistyped, or the intent
-directory gone). When any row is dead, the message adds a second suffix next to the exclusion
-count naming the count, the file, and the prune command - purely informational, status and exit
-code unchanged. Prune it the same way, dry-run first: register-exclusions --prune [--apply]. It
-removes exactly the dead rows through the same writer and commit, but holds back an id whose
-intent dir carries a fresh lock or has not gone terminal yet (nothing to suppress there yet),
-naming both as kept.
-
-## Locks (auto teams only)
-
-Locks exist for auto teams: a `delivery.lock` file in the intent directory names the owning
-session, and the `record` hook refreshes its mtime on every edit (the lease heartbeat; stale
-means older than the TTL). Direct work takes no lock. When a lock reads held by a session
-that is gone, when work resumes after a crash, reboot, or `/tmp` wipe, or when the user says
-"fix the lock", "who holds the lock", or "reclaim the lock", use the CLI (intent 304 folded
-the former locking skill here):
-
-| Verb | What it does | When |
-|---|---|---|
-| `who` | Owner, heartbeat, claims, delegates, from durable files only | Safe inspection; needs `--intent-dir` |
-| `status` | Lock file, freshness, the derived worktree, whether this session's pointer names the intent, claims | Always safe; run first |
-| `fix` | Idempotent repair from disk truth for this session; never touches a fresh foreign lock | Interrupted work, corrupt state, `/tmp` wiped |
-| `release` | The owner clears the lock | Ending or abandoning an auto delivery |
-| `reclaim` | Explicit takeover of a stale lock; appends an audit line to `savepoint.md` | The owner is gone and the lease expired |
-| `delegate` | The owner registers a subagent session, or marks it `finished` or `failed` | Auto-team orchestration |
-
-```
-ruby ~/.plastic/scripts/plastic-lock status --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock who --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock fix --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock reclaim --intent-dir <store>/<id>--<slug>
-```
-
-`fix` exits non-zero when another session holds a fresh lock: back off, `status` shows the
-owner. `reclaim` refuses a fresh lock; every takeover is audited. The lock file's mtime is the
-sole freshness truth. Never delete a lock file by hand. Read
-`../plastic-conventions/references/locks-and-worktrees.md` when a lock question goes beyond
-these verbs (claims, worktrees, the station ledger).
-
-## Provisioning a project store
-
-When a project is registered in `~/.plastic/projects.yml` but has no store on disk (doctor
-reports `project_store_dir`), provision it (intent 304 folded the former provisioning skill
-here). The slug is the project's key under `projects`; an unregistered slug exits non-zero and
-creates nothing, and this procedure never edits `projects.yml`.
-
-```bash
-ruby ~/.plastic/scripts/provision-project-store <slug>
-ruby ~/.plastic/scripts/qmd-sync register --store ~/.plastic/projects/<slug>/store
-```
-
-The provisioner is pure filesystem and idempotent: it creates
-`~/.plastic/projects/<slug>/store/` with `.gitkeep`, writes `INDEX.md` and `project.yml` only
-when missing, and never clobbers. The QMD registration is a separate, optional step that
-no-ops when QMD is absent. New projects are provisioned by `plastic-project-creating`, not here.

package/skills/doctor/report.md

@@ -1,102 +0,0 @@
-# Plastic Doctor Report
-
-<!-- =======================================================================
-  AGENT INSTRUCTIONS -- How to fill this template
-  =========================================================================
-  1. Run the doctor script. It outputs JSON with check results.
-  2. Replace every {{placeholder}} below with the corresponding JSON value.
-  3. For the category sections: the template shows ONE example section.
-     Repeat that pattern for each unique category in the checks array.
-     The scope determines which categories appear:
-       --core scope:      agent_registration, core_files (binary pass/error only)
-       --store scope:     global_store, conventions, project_stores
-       full (no flag):    all six categories below
-     The six known categories and their display names are:
-       global_store       -> "Global Store"
-       conventions        -> "Conventions"
-       agent_registration -> "Agent Registration"
-       core_files         -> "Core Files"
-       project_stores     -> "Project Stores"
-       deprecations       -> "Deprecations"
-       done_signals       -> "Done Signals"
-       session_ledger     -> "Session Ledger" (global store only)
-  4. For each check within a category, emit one line with the status icon
-     and the check message. If the check has non-empty details, list them
-     as indented sub-items.
-  5. The "Fixable Issues" section should ONLY appear if at least one check
-     has fixable=true AND status is not "pass". Omit the entire section
-     otherwise.
-  6. Status icons (plain text, no emoji):
-       pass -> [PASS]
-       warn -> [WARN]
-       fail -> [FAIL]
-  7. The overall status icon in the header uses the same mapping.
-  8. After filling, remove all HTML comments -- they are instructions only.
-  ======================================================================= -->
-
-## {{overall_status_icon}} Overall: {{status}} -- Plastic v{{version}}
-
-Checked at: {{timestamp}}
-
-### Summary
-
-{{pass}} passed, {{warn}} warnings, {{fail}} failed -- {{total}} checks total
-
----
-
-<!-- =====================================================================
-  CATEGORY SECTIONS
-  ======================================================================
-  Repeat the block below ONCE PER CATEGORY present in the checks array.
-  Group checks by their "category" field. Use the display name mapping
-  above for the heading. Within each category, list every check as a
-  single line: status icon + message. If a check has non-empty "details",
-  list each detail as an indented bullet beneath.
-
-  Example category section (for agent_registration with two checks):
-  ===================================================================== -->
-
-### Agent Registration
-
-- [PASS] Claude Code adapter registered
-- [FAIL] 2 hook scripts not executable
-  - ~/.claude/hooks/plastic-session-start
-  - ~/.claude/hooks/plastic-record
-
-<!-- =====================================================================
-  Repeat the above pattern for each category found in the checks array.
-  Only include categories that have at least one check.
-  Order categories as they appear in the checks array.
-  ===================================================================== -->
-
----
-
-<!-- =====================================================================
-  FIXABLE ISSUES SECTION
-  ======================================================================
-  Include this section ONLY if one or more checks have fixable=true AND
-  status is "warn" or "fail". If no fixable issues exist, omit everything
-  from the "Fixable Issues" heading through the end of the horizontal
-  rule that follows the table.
-
-  For each fixable check that is not "pass", emit one table row:
-    | status_icon | check_message | fix_hint |
-  ===================================================================== -->
-
-### Fixable Issues
-
-| Status | Issue | Fix |
-|--------|-------|-----|
-| [FAIL] | 2 hook scripts not executable | chmod +x on the listed files |
-
-<!-- =====================================================================
-  Repeat one row per fixable non-pass check.
-  ===================================================================== -->
-
----
-
-<!-- =====================================================================
-  FOOTER -- always include this line exactly as written.
-  ===================================================================== -->
-
-Doctor only reports; it never fixes anything itself. Ask me to fix these issues and I will offer Fix all / Select individually / Skip, then route each chosen repair through the tool that owns it.