@zalom/plastic 2.0.0-alpha.27 → 2.0.0-alpha.29

package/skills/doctor/SKILL.md

@@ -1,305 +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), the global store's own conventions/done-signals content, and the `display`
-category (intent 331e): `display_hook_registered` (also runs at `--core`), `display_hook_paints`
-(replays the shipped display fixture through the installed MessageDisplay hook and expects a
-painted screen back, a pass when a known defeater like `NO_COLOR` is active, never a fail),
-`display_not_defeated` (warns per active defeater and always names the undetectable verbose
-transcript view), and `display_surfaces_documented` (the harness-adapters doc still names every
-surface class). **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) |
-| "Re-run the Plastic installer to repair the hook registration ... (plastic-install --repair)" (`display_hook_registered`) | Run `npx -y @zalom/plastic@<channel> install --reinstall --claude` (the `plastic-install` skill's repair mode), then re-run doctor |
-
-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
-includes 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 merged
-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 is delivering 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 merged 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       -> "Completion 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.

package/skills/feedback/SKILL.md

@@ -1,98 +0,0 @@
----
-name: plastic-feedback
-description: Use when the user hits a Plastic quirk, bug, or feature idea in a project and wants to report it back to the Plastic project. Builds a sanitized report file and a prefilled GitHub issue URL the user reviews and submits. Only the user sends.
-disable-model-invocation: true
-user-invocable: true
----
-
-# Plastic Feedback
-
-Turn a described Plastic problem into a local report file and a prefilled GitHub
-issue URL. The script does the mechanics (redaction, naming, URL building); the
-user alone opens the URL and submits it. This skill has no send step, by design.
-
-Because `disable-model-invocation` hides this skill's description from your own
-context, you cannot discover it by browsing available skills mid-task. If the
-user hits a Plastic quirk, bug, or missing feature, offer to run
-`/plastic-feedback` yourself; do not wait for the user to ask for it by name.
-
-## Procedure
-
-### 1. Gather the narrative
-
-Ask the user for:
-- What happened (the observed behavior).
-- The root cause, if they already know it.
-- The expected behavior.
-
-Keep it to about one page. Do not pad it with speculation; a short, accurate
-report beats a long, padded one.
-
-### 2. Obfuscate before it leaves this session
-
-Before filling the template, strip anything that identifies the user's project
-or its content:
-- Remove project names, directory paths, and file names specific to the user's
-  codebase.
-- Turn any Plastic intent names into their bare numeric or slug ids (drop the
-  descriptive title if it leaks project context).
-- Keep only Plastic's own operational content: what Plastic did, what it should
-  have done, which command or hook was involved.
-
-Read `references/transport-and-privacy.md` before filling the template, for the
-full obfuscation checklist and the reasoning behind it.
-
-### 3. Fill the report template
-
-Read `report.md` from this skill's directory (`~/.plastic/skills/feedback/report.md`
-at runtime, or the plugin source `skills/feedback/report.md` during development).
-Fill every placeholder except `{{plastic_version}}`, which the script fills.
-Assemble the final markdown body from the filled template.
-
-### 4. Run the script
-
-```bash
-ruby ~/.plastic/scripts/feedback-report --title "<short title>"
-```
-
-Pipe the filled body on STDIN. Parse the JSON on stdout:
-
-| Key | Meaning |
-|---|---|
-| `report_path` | Local file the full, uncapped report was written to |
-| `url` | Prefilled GitHub new-issue URL |
-| `encoded_url_bytes` | Byte length of the encoded URL |
-| `truncated` | Whether the URL body is a capped page-one, not the full report |
-| `page_break_note` | The end-marker text appended when `truncated` is true, else null |
-
-The script only ever writes a local file and prints a URL. It has no network
-call, no token, and no way to open a browser or submit anything on its own.
-
-### 5. Present the result
-
-Show the user:
-- The local file path (`report_path`).
-- A short preview of the report.
-- The URL.
-
-If `truncated` is true, tell the user plainly: the URL carries page one of the
-report, and the full report is in the local file at `report_path`. They can
-paste more from the local file into the opened issue if they want.
-
-Then tell them, in these words or close to them: open the URL, review it, drag
-a screenshot onto the form if they have one, and submit it under their own
-GitHub account. Or, if they would rather edit first, copy the local file
-contents into a new issue themselves.
-
-### 6. Never submit
-
-State plainly that this skill has no send step: it never posts to GitHub, never
-runs `gh issue create`, and never opens a browser on the user's behalf. The user
-is the only one who can submit the report.
-
-## Gotchas
-
-- If the described report is long, the script may hand back `truncated: true`.
-  This is expected, not an error: the local file always holds the full text.
-- Do not try to route around the missing send step (no `gh` call, no API POST).
-  The absence of a send path is the point of this skill, not a gap to fill.

package/skills/feedback/references/transport-and-privacy.md

@@ -1,65 +0,0 @@
-# Transport and Privacy
-
-Read this before filling `report.md` and before presenting the URL to the user.
-
-## Obfuscation checklist (do this before filling the template)
-
-Run through this list on the narrative gathered from the user, before it goes
-into `report.md`:
-
-- Strip project names. Refer to "the project" or "a consumer project", never
-  the user's actual project name.
-- Strip file paths and directory names specific to the user's codebase.
-- Turn Plastic intent names into their bare ids. Drop the descriptive title if
-  it names project content (an intent title like "Fix the checkout flow" leaks
-  what the user is building; "intent 42" does not).
-- Keep only Plastic's own operational content: which command, hook, or skill
-  ran, what it did, what it should have done instead.
-- Before presenting the URL, re-read the filled report once and confirm none
-  of the above slipped back in.
-
-## Mechanical redaction (what the script also strips)
-
-`scripts/lib/feedback_report.rb` redacts these patterns to `[REDACTED]` before
-the report ever touches disk, as a second, mechanical layer under the
-obfuscation above:
-
-| Secret kind | Pattern shape |
-|---|---|
-| GitHub tokens | `ghp_`, `gho_`, `ghs_`, `ghr_`, `ghu_`, `github_pat_` prefixes |
-| Anthropic/OpenAI keys | `sk-ant-...`, `sk-...` |
-| AWS access key id | `AKIA...` |
-| Bearer tokens | `Bearer <token>` |
-| Slack tokens | `xoxb-`, `xoxa-`, `xoxp-`, `xoxr-`, `xoxs-` prefixes |
-| Google API keys | `AIza...` |
-| PEM private key blocks | `-----BEGIN ... PRIVATE KEY----- ... -----END ... PRIVATE KEY-----` |
-| Key/value assignments | `api_key = ...`, `secret: ...`, `token = ...`, `password: ...` (value only) |
-
-Treat this list as a safety net, not the primary defense. The mechanical
-patterns catch a specific, known shape; the obfuscation pass above is what
-catches project-identifying context a regex cannot recognize.
-
-## Why a prefilled URL, and not something else
-
-The report is sent by opening a prefilled `https://github.com/zalom/plastic/issues/new`
-URL in the user's own browser. Submission happens in an authenticated session
-that belongs to the user, not to the agent or the script. Nothing in this
-skill or in `feedback-report` can complete that submission on its own: there
-is no send method, no token, and no network call anywhere in the code path.
-
-Other transports were considered and rejected:
-
-- **`gh issue create`**: the CLI can send on its own; only `--web` is
-  browser-submitted, and the plain form cannot be guaranteed not to send
-  directly. It also assumes `gh` auth, which a consumer-project user may not
-  have.
-- **An API POST with a token**: the agent could send it, and the token itself
-  becomes a credential worth stealing.
-- **An anonymous POST endpoint**: still agent-reachable, with no built-in spam
-  resistance, and it needs server infrastructure this project does not run.
-- **Email or `git send-email`**: the CLI sends the message, review is opt-in
-  rather than forced, and it needs a working mail transport most machines do
-  not have configured.
-
-Only the prefilled-URL approach makes "the agent cannot send" a structural
-fact instead of a rule the agent could break by taking a shortcut.

package/skills/feedback/report.md

@@ -1,36 +0,0 @@
-# Plastic feedback: {{title}}
-
-<!-- =======================================================================
-  AGENT INSTRUCTIONS -- How to fill this template
-  =========================================================================
-  1. Replace every {{placeholder}} below with real content gathered from the
-     user, except {{plastic_version}}: leave that token exactly as written,
-     the feedback-report script fills it from the installed VERSION file.
-  2. Obfuscate first (see references/transport-and-privacy.md): strip project
-     names, file paths, and anything else that identifies the user's
-     codebase. Keep only Plastic's own operational content.
-  3. Keep the report to about one page. Use tables or short lists where they
-     make the report clearer than prose.
-  4. Delete this entire HTML comment block before piping the body into
-     feedback-report. It is fill instructions only, not report content.
-  ======================================================================= -->
-
-## Environment
-
-| Field | Value |
-|---|---|
-| Plastic version | {{plastic_version}} |
-| Agent | {{agent_name}} |
-| OS | {{os}} |
-
-## What happened
-
-{{what_happened}}
-
-## Root cause (if known)
-
-{{root_cause_or_not_known}}
-
-## Expected behavior
-
-{{expected_behavior}}