@erclx/canon 4.126.0 → 5.1.0

package/docs/agents/tasks.md

@@ -60,6 +60,8 @@ canon tasks pull-request 673 --plan worktree-scratch-routing --json
 
 A plan is matched on the token both spellings share, so `worktree-scratch-routing`, `feature-worktree-scratch-routing`, and `.canon/plans/feature-worktree-scratch-routing.md` all select the same task. The `action` field reports `added`, `appended`, `corrected`, or `unchanged`, which makes a rerun against the same number safe.
 
+Run from a branch other than `main` or `master`, the verb also drops that branch from the task's `Pending branch:` line, along with every name its reflog says it was renamed from, and removes the line once it is empty. The renamed names matter because `git-ship` renames a nonconforming branch after `context-fold` wrote the marker. It does so on an `unchanged` run too, so a rerun repairs a marker left behind. The `pending` field lists the branches still on the line after the write.
+
 Exit codes: `0` recorded, `1` refused. The `reason` field carries `no-board`, `no-match`, or `ambiguous`. `git-pr` skips silently on those three, because each is a case where a guessed write would archive the wrong task once the branch merges.
 
 A malformed argument refuses as `bad-input` instead, which sits outside that set on purpose. `git-pr` derives the number by slicing whatever `gh pr create` printed, so a non-numeric value is reachable, and folding it into the swallowed set would lose the number with nothing reporting it.
@@ -82,6 +84,8 @@ canon tasks outcome --plan worktree-scratch-routing --close 2 --json
 
 An outcome already closed comes back under `alreadyClosed` rather than refusing, so a rerun against the same positions changes nothing. A position past the end of the list refuses as `out-of-range`, since a caller counting wrong should hear about it rather than mark a neighbor.
 
+A close that ticks at least one box from a branch other than `main` or `master` names that branch on a `Pending branch:` line, read from `git branch --show-current` in the working directory. The line holds the task against `canon tasks archive --pull-request` until `canon tasks pull-request` records that branch's own number. A detached HEAD, a trunk checkout, or a failed git read writes no line and refuses nothing. The `pending` field lists the branches on the line after the write.
+
 Positions skip fenced blocks. A checkbox inside a sample a task displays is not an outcome the task claims, and counting one would shift every position after it. `canon tasks archive` reads the list through the same walker, so the two verbs cannot disagree about which checkboxes are outcomes.
 
 Exit codes: `0` closed, `1` refused. The `reason` field adds `no-outcomes`, `out-of-range`, and `bad-input` to the three above.

package/docs/target/index.md

@@ -10,7 +10,7 @@ Scaffold, sync, and migrate a toolkit-managed project, with worked setups for th
 
 ## Agent surface
 
-- [Target migrations](target-migrations.md): One-time moves a project scaffolded under an older toolkit runs before its next sync
-- [Target projects](target-projects.md): Scaffold, add domains later, and sync upstream drift in a toolkit-managed project
-- [Target scenarios](target-scenarios.md): Worked setups for a markdown-heavy project, a web application, and a monorepo
-- [Target sync](target-sync.md): Check what drifted in a toolkit-managed project and pull it in, per domain or all at once
+- [Target migrations](migrations.md): One-time moves a project scaffolded under an older toolkit runs before its next sync
+- [Target projects](projects.md): Scaffold, add domains later, and sync upstream drift in a toolkit-managed project
+- [Target scenarios](scenarios.md): Worked setups for a markdown-heavy project, a web application, and a monorepo
+- [Target sync](sync.md): Check what drifted in a toolkit-managed project and pull it in, per domain or all at once

package/docs/target/{target-migrations.md → migrations.md}

@@ -6,7 +6,7 @@ category: Agent surface
 
 # Target migrations
 
-Each section below is a move a project runs once, when it was scaffolded before the change the section names. Run `canon upgrade` first, so the verb doing the move is the current one. For the recurring sync that follows, see [target sync](target-sync.md).
+Each section below is a move a project runs once, when it was scaffolded before the change the section names. Run `canon upgrade` first, so the verb doing the move is the current one. For the recurring sync that follows, see [target sync](sync.md).
 
 ## Move the records first, once
 
@@ -91,3 +91,19 @@ canon migrate surface-roots --write --json
 The first line reports the plan and the second applies it, moving each surface with `git mv` so its history follows and repointing every tracked citation of one in the same run. See `canon docs agents` for the full file list rather than reading it here.
 
 Neither `canon sync --check` nor any other command notices a surface still sitting at `.claude/`, so running this is on you rather than on a prompt from the toolkit.
+
+## Delete the retired snippets, once
+
+The toolkit retired snippets, deleting the catalog, the `canon snippets` verb, and the `create-snippet` skill. A project scaffolded while the domain still installed may hold a `.claude/snippets/` folder, which nothing reads any more. Find it with the reverse walk:
+
+```bash
+canon sync --check . --json | jq '.reverse'
+```
+
+The walk checks both `.claude/snippets` and a root `snippets/`, since a toolkit old enough installed at the project root. Act on each entry by its verdict, whichever path it sits at:
+
+- `dropped` is the toolkit's copy, unchanged, and deleting the folder is safe
+- `unattributed` holds files the toolkit shipped under those names with content it never published, which is usually a copy the project edited, so read what changed before deleting anything
+- `project` is content the project wrote under the same name, which the retirement does not reach, so leave it alone
+
+The walk reads the toolkit's own history, so it needs a cloned toolkit. Installed from the registry it reports `historyUnavailable` and names nothing, so check for `.claude/snippets/` and a root `snippets/` by hand there, and treat what you find as `unattributed`.

package/docs/target/{target-projects.md → projects.md}

@@ -104,8 +104,6 @@ Run `canon tooling list --json` and `canon gov list --json` to see the current c
 
 No standard is written into the project. Each governance rule's authority line names `canon standards <name>`, which answers from the corpus inside the CLI's own package, and every toolkit skill names the copy in its own plugin root. `canon markdown audit` needs no standard at all, its ban set and checkpoints shipping with the package as data.
 
-No snippet is written into the project either. `claude/snippets` in the plugin cache symlinks to the toolkit's own `snippets/`, so a session reaches one at its `@` reference with no install step, the same live resolution `claude/standards` gives a rule's authority line.
-
 `governance` and `wiki` are skippable:
 
 - `--skip governance`: leave `.claude/rules/` empty, so no coding standard loads on a file match. The preview names any `--add` rules the skip drops, and the run prints the `canon gov install <stack> <path>` command to add rules afterward, carrying those extras so one paste restores what the skip declined.
@@ -121,22 +119,22 @@ When a new need appears after scaffold, install the one domain without re-runnin
 - Project-specific rule the toolkit does not ship: invoke `canon:create-rule`. It scaffolds a rule into `.claude/rules/project/` with a non-colliding number, and `canon gov sync` leaves it untouched. A rule placed under `.claude/rules/canon/` instead is deleted on the next sync, since that folder belongs to the toolkit.
 - Index.md system for a markdown-heavy folder that emerged: invoke `canon:target-setup indexes`
 
-Standards and snippets are not on that list, and there is nothing to add for either. Neither installs into a project, by default or by flag, so a session reads a standard with `canon standards <name>` and a snippet through its `@` reference off the live plugin symlink, both resolving against the toolkit rather than a project copy. A project holding a `.claude/standards/` or `.claude/snippets/` folder from an older toolkit is carrying a stale artifact nothing reads, and deleting it is safe.
+Standards are not on that list, and there is nothing to add for them. They install into no project, by default or by flag, so a session reads one with `canon standards <name>`, resolving against the toolkit rather than a project copy. A project holding a `.claude/standards/` folder from an older toolkit is carrying a stale artifact nothing reads, and deleting it is safe. The toolkit retired snippets entirely, and [target migrations](migrations.md) covers the `.claude/snippets/` folder an older one left behind.
 
 Per-domain mechanics live in the corresponding `docs/<domain>.md`. The skill body in `claude/skills/<skill>/SKILL.md` covers detection and preview.
 
 ## Sync upstream drift
 
-When the toolkit updates, a target pulls changes per domain. A project scaffolded before a layout move runs the one-time moves in [target migrations](target-migrations.md) first. [Target sync](target-sync.md) then covers reading what drifted, the catch-all and targeted entry points, verifying a sync in the sandbox, and running one from an agent session.
+When the toolkit updates, a target pulls changes per domain. A project scaffolded before a layout move runs the one-time moves in [target migrations](migrations.md) first. [Target sync](sync.md) then covers reading what drifted, the catch-all and targeted entry points, verifying a sync in the sandbox, and running one from an agent session.
 
 ## Scenarios
 
-[Target scenarios](target-scenarios.md) walks a markdown-heavy project, a web application, and a monorepo with several language roots from the first session through ongoing maintenance.
+[Target scenarios](scenarios.md) walks a markdown-heavy project, a web application, and a monorepo with several language roots from the first session through ongoing maintenance.
 
 ## Related
 
 - [agents](../agents/index.md): CLI flags, exit codes, and JSON output shapes
-- [target migrations](target-migrations.md), [target sync](target-sync.md), [target scenarios](target-scenarios.md): the one-time moves, the recurring sync, and worked setups
+- [target migrations](migrations.md), [target sync](sync.md), [target scenarios](scenarios.md): the one-time moves, the recurring sync, and worked setups
 - [AI workflow](../workflow/ai-workflow.md): feature-development loop inside a toolkit-managed project
-- [tooling](../../canon/context/tooling/index.md), [governance](../../canon/context/governance/index.md), [claude plugin](../../canon/context/claude-plugin/index.md), [indexes](../../canon/context/indexes.md), [snippets](../../canon/context/snippets.md), [standards](../../canon/context/standards/index.md): per-domain mechanics
+- [tooling](../../canon/context/tooling/index.md), [governance](../../canon/context/governance/index.md), [claude plugin](../../canon/context/claude-plugin/index.md), [indexes](../../canon/context/context-model/indexes.md), [standards](../../canon/context/standards/index.md): per-domain mechanics
 - [sandbox](../../canon/context/sandbox/index.md): scenario catalog for verifying domain flows

package/docs/target/{target-scenarios.md → scenarios.md}

@@ -6,7 +6,7 @@ category: Agent surface
 
 # Target scenarios
 
-Three worked setups, each from the first session through ongoing maintenance. [Target projects](target-projects.md) carries the lifecycle they walk.
+Three worked setups, each from the first session through ongoing maintenance. [Target projects](projects.md) carries the lifecycle they walk.
 
 ## Markdown-heavy project
 

package/docs/target/{target-sync.md → sync.md}

@@ -6,7 +6,7 @@ category: Agent surface
 
 # Target sync
 
-When the toolkit updates, a target project pulls changes per domain. There is one catch-all and several targeted entry points. A project scaffolded before a layout move runs the one-time moves in [target migrations](target-migrations.md) first.
+When the toolkit updates, a target project pulls changes per domain. There is one catch-all and several targeted entry points. A project scaffolded before a layout move runs the one-time moves in [target migrations](migrations.md) first.
 
 ## Check first
 
@@ -30,7 +30,7 @@ A project that has never synced under a toolkit new enough to write a stamp fall
 
 Further causes sit outside the per-domain scan, each naming something that walk cannot see. A seed the project edited is reported under `seeds` and reconciled with `canon:seed-sync`, since no sync command touches a seed. A file a newer seed folder replaced is reported under `superseded`, such as `.claude/TASKS.md` against the `.canon/tasks/` that now ships, and nothing moves it because the content is the project's own. A domain sitting at the root layout with nothing under `.claude/` is reported under `unmigrated`, and no command moves it either. The project moves the content itself.
 
-`unmigrated` currently names no domain, since standards and snippets are the two the toolkit ever installed at the project root and both closed their install channel. A target still holding a root `standards/` or `snippets/` folder from an older toolkit is carrying its own authoring surface now, not an unfinished install, and nothing proposes moving either.
+`unmigrated` currently names no domain, since standards and snippets are the two the toolkit ever installed at the project root, standards closed its install channel, and snippets retired outright. A target still holding a root `standards/` folder from an older toolkit is carrying its own authoring surface now, not an unfinished install, and nothing proposes moving it. A leftover `.claude/snippets/` reports under `reverse` below instead.
 
 ### Rules you never received
 
@@ -56,6 +56,8 @@ Each entry carries a verdict, since a dropped folder and one the project wrote a
 - `unattributed` means the toolkit shipped that path and the content matches no version it published
 - `project` means the folder only shares a retired name
 
+A `.claude/snippets/` folder an older toolkit installed is the case this walk exists for, since the toolkit retired the domain and deleted its `snippets/` root. It reports as `dropped`, and [target migrations](migrations.md) says what to do with it.
+
 Nothing acts on any of them, and the verdict is what makes the list safe to read.
 
 Add `--json` for the machine-readable report, and `--exit-code` to fail a CI job when a target falls behind. Files the project authored itself never count toward that exit code, and neither do superseded artifacts, seed drift, tooling, or anything the reverse walk reports, since each names content the project is expected to edit or place itself. An unmigrated domain does count, because running the relocation closes it.

package/docs/workflow/ai-workflow.md

@@ -36,7 +36,7 @@ canon/
 
 A project scaffolded before the move keeps its records under `.claude/`, and every command reads either root. `canon migrate records` moves one project across and repoints what cites it, and `canon migrate record-tree` follows it to reach the citations inside the records themselves, which the first verb passes over because it enumerates through git. A project scaffolded before the surface move keeps its context, decisions, wireframes, and loose documents under `.claude/` the same way, and `canon migrate surface-roots` moves those to `canon/` with the history following each file.
 
-Three tiers of context load with different cost: always-loaded (root `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`), path-scoped lazy (`.claude/rules/<scope>.md` with `paths:` glob), and on-demand lookup (`canon/context/<domain>.md`, or `canon/context/<domain>/` once a domain outgrows one file, discovered via `canon/context/index.md`). See [the context model](../../canon/context/context-model.md) for the full picture.
+Three tiers of context load with different cost: always-loaded (root `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`), path-scoped lazy (`.claude/rules/<scope>.md` with `paths:` glob), and on-demand lookup (`canon/context/<domain>.md`, or `canon/context/<domain>/` once a domain outgrows one file, discovered via `canon/context/index.md`). See [the context model](../../canon/context/context-model/overview.md) for the full picture.
 
 Run `canon init` to seed the `.claude/` directory, a root `CLAUDE.md` file, and `.claude/rules/` in one pass. `canon init` chains claude init and governance install. Claude Code auto-loads every file in `.claude/rules/` at session start, applying always-on rules unconditionally and path-scoped rules to files matching their `paths:` glob.
 
@@ -44,7 +44,7 @@ Run `canon init` to seed the `.claude/` directory, a root `CLAUDE.md` file, and
 
 ### Bootstrap a new project
 
-See [target projects](../target/target-projects.md) for the scaffold decision, core domains and skips, and the full lifecycle across scaffold, add-a-domain-later, and upstream sync.
+See [target projects](../target/projects.md) for the scaffold decision, core domains and skips, and the full lifecycle across scaffold, add-a-domain-later, and upstream sync.
 
 ### New feature
 
@@ -95,7 +95,7 @@ For features on a mature stack, chain the post-plan pipeline in one session. App
 
 Review findings split by origin before severity is read. One the branch inherited stops the chain, and one the run itself caused is repaired in place at any severity, bounded at a single pass. Origin is causation rather than authorship, so staleness the run induced in a file it never opened counts as its own and the plan's file list bounds what it builds rather than what it may repair.
 
-Review is skipped when the diff is prose that only informs: every changed file matches `*.md` or `*.txt`, and none sits under a behavior path. Behavior paths cover skills and rules in both the authoring and the installed spelling, so the list matches whether a repository authors those surfaces or consumed them from the toolkit. Standards, snippets, `internal/`, and `tooling/` carry the authoring spelling alone, since none of the four reaches a session through a `.claude/` copy, and root `CLAUDE.md` is named as a file because a path prefix reaches nothing sitting in no folder.
+Review is skipped when the diff is prose that only informs: every changed file matches `*.md` or `*.txt`, and none sits under a behavior path. Behavior paths cover skills and rules in both the authoring and the installed spelling, so the list matches whether a repository authors those surfaces or consumed them from the toolkit. Standards, `internal/`, and `tooling/` carry the authoring spelling alone, since none of the three reaches a session through a `.claude/` copy, and root `CLAUDE.md` is named as a file because a path prefix reaches nothing sitting in no folder.
 
 Markdown under one states what an agent does, so a branch touching it reaches review while `docs/` and `wiki/` still skip and stay gated by `docs-sync`, `standards-audit`, and pre-push hooks.
 
@@ -146,7 +146,3 @@ verify fails  → Session 1 (it has implementation context)
 design fails  → new Claude chat session (planning problem)
 review finds  → Session 2 (fix alongside review, before ship)
 ```
-
-## Snippets
-
-For the full list of snippets that complement this workflow, see `canon/context/snippets.md`.

package/docs/workflow/operating-model.md

@@ -12,7 +12,7 @@ cross-feature call and reviews. Planning runs there or in a session of its own.
 Cold worker sessions build. The human launches workers and merges.
 
 This page covers the roles and the loop. For the worktree mechanism (isolation, merge
-order, port collisions), see [Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md).
+order, port collisions), see [Claude Code and git worktrees](../../wiki/claude/worktrees.md).
 
 ## Four roles
 
@@ -226,11 +226,11 @@ A dev server, an end-to-end run, and a screenshot run alongside each other on a
 web stack, since every worktree derives its own port. Singleton resources (one
 local model server, one GPU) still serialize, as does any port a stack fixes by
 hand. See
-[Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md) for merge order and the
+[Claude Code and git worktrees](../../wiki/claude/worktrees.md) for merge order and the
 port-collision detail.
 
 ## Related
 
-- [Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md) for the isolation and fan-out mechanics
-- [Claude Code subagents](../../wiki/claude/claude-subagents.md) for in-session parallelism without worktrees
+- [Claude Code and git worktrees](../../wiki/claude/worktrees.md) for the isolation and fan-out mechanics
+- [Claude Code subagents](../../wiki/claude/subagents.md) for in-session parallelism without worktrees
 - `canon/context/claude-plugin/skill-strategy/overview.md` for how the skills in the loop are categorized

package/docs/workflow/parallel-features.md

@@ -32,7 +32,7 @@ A constraint naming a track in flight carries the same problem past the handoff,
 
 ## Records at the main root
 
-`.canon/plans/`, `.canon/review/`, and `.canon/memory/` all resolve at the main worktree root, so artifacts created in any session are visible from any sibling worktree. A session inside a worktree reads them directly, since the file-editing tools refuse a main-root path but `Read` resolves normally. It writes a whole file through the shell and makes a change inside an existing file through a `canon` verb, which resolves the main root in-process. See [Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md) for the full rule and the domain-level fan-out guidance.
+`.canon/plans/`, `.canon/review/`, and `.canon/memory/` all resolve at the main worktree root, so artifacts created in any session are visible from any sibling worktree. A session inside a worktree reads them directly, since the file-editing tools refuse a main-root path but `Read` resolves normally. It writes a whole file through the shell and makes a change inside an existing file through a `canon` verb, which resolves the main root in-process. See [Claude Code and git worktrees](../../wiki/claude/worktrees.md) for the full rule and the domain-level fan-out guidance.
 
 The plan's shape is fixed by `standards/plan.md`: the section list, the filename, the lifecycle, and the contract its questions keep. Every question carries a `- Suggested:` line and an empty `- Answer:` slot, and a blank answer accepts the suggestion at execution time. That default is what makes a plan decision-ready in one pass, and it is the opposite of the contract an intake folder keeps, where an empty slot means nobody reached the item.
 

package/docs/workflow/skill-map.md

@@ -6,7 +6,7 @@ category: Workflow
 
 # Skill map
 
-Groups run in the order a project meets them, so a reader at a known point scans to that group and reads across. The set reconciles the scenarios in [AI workflow](ai-workflow.md) with the lifecycle [target projects](../target/target-projects.md) describes, rather than inventing a third vocabulary beside those two, so a group name matches neither source exactly and every moment either one names has a group. Each row says when to reach for the skill. What it does is the skill's own description.
+Groups run in the order a project meets them, so a reader at a known point scans to that group and reads across. The set reconciles the scenarios in [AI workflow](ai-workflow.md) with the lifecycle [target projects](../target/projects.md) describes, rather than inventing a third vocabulary beside those two, so a group name matches neither source exactly and every moment either one names has a group. Each row says when to reach for the skill. What it does is the skill's own description.
 
 This page is the corpus the coverage claim is measured against: every name `canon claude skills list --names` reports takes exactly one row here. A skill serving two moments sits at the earlier one, and a mention on any other page is prose rather than routing.
 
@@ -115,7 +115,6 @@ This page is the corpus the coverage claim is measured against: every name `cano
 | ------------------------- | ----------------------------------------------------------------------------------------------------------------- |
 | `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                  |
 | `canon:create-skill`      | For a new `SKILL.md`                                                                                              |
-| `canon:create-snippet`    | For a reusable prompt                                                                                             |
 | `canon:create-standard`   | For a new authoring convention                                                                                    |
 | `canon:draft-docs`        | For a brand-new `docs/*.md` page, drafted against `standards/docs.md`                                             |
 | `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task         |

package/docs/workflow/visual-design-workflow.md

@@ -8,9 +8,9 @@ category: Workflow
 
 Three tiers cover the range from prose-only design docs to a fully graphical design source of truth. Pick one per project based on how UI-heavy the work is, whether stakeholders review visuals, and whether a designer is involved. Tiers stack, so moving up does not invalidate work done at a lower tier.
 
-The tier framework sits alongside [Claude Design](../../wiki/claude/claude-design.md), the one catalog page in this range. Stitch, Excalidraw, and the surrounding MCP and skill ecosystem are named inline below rather than catalogued separately. This page decides when to reach for what.
+The tier framework sits alongside [Claude Design](../../wiki/claude/design.md), the one catalog page in this range. Stitch, Excalidraw, and the surrounding MCP and skill ecosystem are named inline below rather than catalogued separately. This page decides when to reach for what.
 
-Two tools anchor tier 1 and tier 2. Stitch is the agent-addressable default through its MCP server at `stitch.googleapis.com/mcp`, with a free tier of 400 daily credits that covers daily iteration. [Claude Design](../../wiki/claude/claude-design.md), released 2026-04-17 and priced inside Claude subscriptions, is the ceiling tool reserved for codebase extraction and the richly annotated handoff bundle. Each covers a different job, they are not swappable.
+Two tools anchor tier 1 and tier 2. Stitch is the agent-addressable default through its MCP server at `stitch.googleapis.com/mcp`, with a free tier of 400 daily credits that covers daily iteration. [Claude Design](../../wiki/claude/design.md), released 2026-04-17 and priced inside Claude subscriptions, is the ceiling tool reserved for codebase extraction and the richly annotated handoff bundle. Each covers a different job, they are not swappable.
 
 ## Tier 0: prose only
 
@@ -74,7 +74,7 @@ Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in the
 - Excalidraw canvas server on localhost plus the community [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw) MCP shim, for projects that need an agent to draw, read back, and revise a canvas. MIT-licensed, plaintext JSON scene format. `describe_scene` and `get_canvas_screenshot` let the agent verify its own layout before claiming it is correct.
 - Playwright MCP ([`microsoft/playwright-mcp`](https://github.com/microsoft/playwright-mcp)) for browser-side verification, driven off the accessibility tree rather than screenshots.
 - Chrome DevTools MCP ([`ChromeDevTools/chrome-devtools-mcp`](https://github.com/ChromeDevTools/chrome-devtools-mcp)) for live frontend debugging: performance traces, network inspection, and DOM and CSS inspection.
-- Claude Design as the ceiling option for codebase extraction or polished handoff bundles. See [Claude Design](../../wiki/claude/claude-design.md).
+- Claude Design as the ceiling option for codebase extraction or polished handoff bundles. See [Claude Design](../../wiki/claude/design.md).
 
 ### Skills
 
@@ -111,7 +111,7 @@ Design happens in a graphical tool. `canon/DESIGN.md` either regenerates from th
 ### Tools
 
 - Figma desktop app with the official [Figma Dev Mode MCP](https://www.figma.com/blog/introducing-claude-code-to-figma/) for teams with a dedicated designer already on Figma. Bidirectional sync and Code to Canvas capture of a running Claude Code UI into editable Figma frames.
-- Claude Design with its Claude Code handoff bundle for teams without an existing Figma investment and for solo founders or PMs driving design themselves. One-way handoff, no bidirectional sync. See [Claude Design](../../wiki/claude/claude-design.md).
+- Claude Design with its Claude Code handoff bundle for teams without an existing Figma investment and for solo founders or PMs driving design themselves. One-way handoff, no bidirectional sync. See [Claude Design](../../wiki/claude/design.md).
 - Stitch via MCP as a low-cost complement to either, used for bulk screen generation driven by Claude Code.
 - Playwright and Chrome DevTools MCPs as in tier 1
 
@@ -149,7 +149,7 @@ Resist over-tiering early. Moving up is cheap because tiers stack. Moving down m
 
 ## References
 
-- [Claude Design](../../wiki/claude/claude-design.md): first-party hosted design product and handoff bundle
+- [Claude Design](../../wiki/claude/design.md): first-party hosted design product and handoff bundle
 - `canon/context/claude-plugin/skill-strategy/overview.md`: how to decide between workflow and domain-knowledge skills
 - [`microsoft/playwright-mcp`](https://github.com/microsoft/playwright-mcp): browser automation MCP used in tier 1 and tier 2
 - [`ChromeDevTools/chrome-devtools-mcp`](https://github.com/ChromeDevTools/chrome-devtools-mcp): live frontend debugging MCP used in tier 1 and tier 2

package/docs/workflow/zshrc-aliases.md

@@ -68,7 +68,7 @@ Use `clp` in any other repository where you want the toolkit skills available. W
 
 Use `cls` or `clps` to save Opus usage on routine sessions. Switch mid-session with `/model` to avoid restarting.
 
-Use `clw <name>` for features that will take more than one session. A worktree isolates the branch, the transcripts, and the `/resume` history. See [Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md) for fan-out rules.
+Use `clw <name>` for features that will take more than one session. A worktree isolates the branch, the transcripts, and the `/resume` history. See [Claude Code and git worktrees](../../wiki/claude/worktrees.md) for fan-out rules.
 
 Use `clc` to resume the last session without a picker. Use `clr` when you have several sessions and need to pick by name or recency. Reach for `clpc` over `clc` wherever the resumed session needs the plugin, inside the toolkit repository as well as outside it, since neither resume re-runs discovery.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.126.0",
+  "version": "5.1.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {
@@ -11,7 +11,6 @@
     "src",
     "scripts",
     "standards",
-    "snippets",
     "governance",
     "tooling",
     "claude",

package/scripts/core/check-plugin-boundary.sh

@@ -24,7 +24,7 @@ if ! command -v realpath >/dev/null 2>&1; then
   exit 1
 fi
 
-# The plugin reaches `standards/` and `snippets/` through symlinks, which an
+# The plugin reaches `standards/` through a symlink, which an
 # installer dereferences with no code in the path to filter. Walking the plugin
 # tree with symlinks followed is what an install actually copies, so resolving
 # each file and rejecting anything under `internal/` asserts the boundary at the

package/scripts/core/install-check.sh

@@ -88,10 +88,9 @@ log_step "Assert scaffold"
 # catches a failed domain, and the gate stays green while the target is
 # missing everything that domain provides.
 #
-# Standards and snippets name no path because neither corpus installs into a
-# target. A scaffold reads a standard through `canon standards <name>` and a
-# snippet through the plugin's live `claude/snippets` symlink, both resolving
-# against the toolkit rather than a copy this gate could assert on. The two
+# Standards name no path because that corpus never installs into a target. A
+# scaffold reads a standard through `canon standards <name>`, resolving against
+# the toolkit rather than a copy this gate could assert on. The two
 # rule paths stand for the `claude` and `canon` groups `base` takes whole.
 for path in "CLAUDE.md" ".claude/wiki/index.md" ".claude" "canon/context/index.md" "canon/wireframes/index.md" ".canon/diagrams/index.md" \
   ".prettierrc" ".editorconfig" ".lintstagedrc" ".husky/pre-commit" ".github/workflows/verify.yml" "scripts/verify.sh" \

package/scripts/core/regen-hero.sh

@@ -94,10 +94,9 @@ COUNTS_JSON="$(catalog gov counts || true)"
 SKILLS_JSON="$(catalog claude skills list)"
 GOV_JSON="$(catalog gov list)"
 STANDARDS_JSON="$(catalog standards list)"
-SNIPPETS_JSON="$(catalog snippets list)"
 TOOLING_JSON="$(catalog tooling list)"
 
-for payload in "$COUNTS_JSON" "$SKILLS_JSON" "$GOV_JSON" "$STANDARDS_JSON" "$SNIPPETS_JSON" "$TOOLING_JSON"; do
+for payload in "$COUNTS_JSON" "$SKILLS_JSON" "$GOV_JSON" "$STANDARDS_JSON" "$TOOLING_JSON"; do
   if [ -z "$payload" ]; then
     echo "regen-hero: a catalog returned nothing, refusing to write a zeroed hero" >&2
     exit 1
@@ -115,7 +114,6 @@ printf '%s' "$COUNTS_JSON" >"$PAYLOAD_DIR/counts.json"
 printf '%s' "$SKILLS_JSON" >"$PAYLOAD_DIR/skills.json"
 printf '%s' "$GOV_JSON" >"$PAYLOAD_DIR/gov.json"
 printf '%s' "$STANDARDS_JSON" >"$PAYLOAD_DIR/standards.json"
-printf '%s' "$SNIPPETS_JSON" >"$PAYLOAD_DIR/snippets.json"
 printf '%s' "$TOOLING_JSON" >"$PAYLOAD_DIR/tooling.json"
 printf '%s' "$TOKEN_CSS" >"$PAYLOAD_DIR/tokens.css"
 
@@ -141,7 +139,6 @@ const COUNTS_JSON = payload("counts")
 const SKILLS_JSON = payload("skills")
 const GOV_JSON = payload("gov")
 const STANDARDS_JSON = payload("standards")
-const SNIPPETS_JSON = payload("snippets")
 const TOOLING_JSON = payload("tooling")
 
 const listed = Number(LISTED)
@@ -157,9 +154,6 @@ const rules = gov.rules.map(slug)
 const stacked = new Set(gov.stacks.flatMap((stack) => stack.rules))
 const deliveredRules = gov.rules.filter((entry) => stacked.has(entry.name)).map(slug)
 const standards = JSON.parse(STANDARDS_JSON).standards.map((entry) => entry.name)
-const snippets = new Set(
-  JSON.parse(SNIPPETS_JSON).categories.flatMap((category) => category.entries),
-)
 const toolingStacks = JSON.parse(TOOLING_JSON).stacks
 const commandCount = JSON.parse(COUNTS_JSON).catalogs.commands
 if (!commandCount) {
@@ -247,7 +241,7 @@ const remaining = (names) => String(Math.max(0, names.length - listed))
 // frame claiming the domain has nothing in it.
 for (const [label, list] of [
   ["skills", skills], ["rules", rules], ["standards", standards],
-  ["snippets", [...snippets]], ["tooling stacks", toolingStacks], ["gov stacks", gov.stacks],
+  ["tooling stacks", toolingStacks], ["gov stacks", gov.stacks],
   ["stack-delivered rules", deliveredRules],
 ]) {
   if (list.length === 0) {
@@ -354,7 +348,6 @@ const values = {
   SKILL_COUNT: String(skills.length),
   RULE_COUNT: String(rules.length),
   STANDARD_COUNT: String(standards.length),
-  SNIPPET_COUNT: String(snippets.size),
   GOV_STACK_COUNT: String(gov.stacks.length),
   TOOLING_STACK_COUNT: String(toolingStacks.length),
   COMMAND_COUNT: String(commandCount),

package/src/autoship/paths.ts

@@ -16,10 +16,9 @@
  *
  * Most carry two spellings, the one a surface authors at and the one it reaches
  * a session at, so the rule reads the same in this toolkit and in a project
- * that consumed one. `standards/` and `snippets/` carry one apiece: neither
- * installs into a project, reaching a reader by resolution and through the
- * `claude/snippets` symlink respectively, so no `.claude/` spelling exists to
- * name.
+ * that consumed one. `standards/` carries one: it never installs into a
+ * project, reaching a reader by resolution, so no `.claude/` spelling exists
+ * to name.
  */
 export const BEHAVIOR_PREFIXES = [
   'claude/skills/',
@@ -27,7 +26,6 @@ export const BEHAVIOR_PREFIXES = [
   'governance/rules/',
   '.claude/rules/',
   'standards/',
-  'snippets/',
   'internal/',
   'tooling/',
 ] as const

package/src/claude/cases/authoring.ts

@@ -1,7 +1,7 @@
 import type { SkillCase } from '@/claude/skills-rank'
 
 /**
- * Script, skill, snippet, standard, and doc authoring, plus the two prose
+ * Script, skill, standard, and doc authoring, plus the two prose
  * skills that revise rather than generate.
  */
 export const AUTHORING_CASES: readonly SkillCase[] = [
@@ -24,10 +24,6 @@ export const AUTHORING_CASES: readonly SkillCase[] = [
     prompt: 'Scaffold a brand-new SKILL.md for this capability.',
     expect: 'create-skill',
   },
-  {
-    prompt: 'I need a new reusable prompt snippet added to the corpus.',
-    expect: 'create-snippet',
-  },
   {
     prompt: 'Write a fresh authoring convention as a new standard file.',
     expect: 'create-standard',

package/src/claude/skills-reach.ts

@@ -7,7 +7,7 @@ import { SURFACE_ROOTS } from '@/surface-root'
  * The authoring roots this repository owns and no install channel delivers.
  *
  * Every entry is a folder a target never holds under that spelling. Standards
- * and snippets install nowhere and are reached through the plugin corpus,
+ * install nowhere and are reached through the plugin corpus,
  * rules install under `.claude/rules/`, and the rest are this repository's
  * own source, docs, and catalogs.
  *
@@ -28,7 +28,6 @@ const AUTHORING_ROOTS = [
   'docs/agents/',
   'governance/',
   'internal/',
-  'snippets/',
   'standards/',
   'tooling/',
   'wiki/',

package/src/cli.ts

@@ -6,7 +6,6 @@ import { register as sandbox } from '@/commands/sandbox'
 import { register as sync } from '@/commands/sync'
 import { register as gov } from '@/commands/gov'
 import { register as standards } from '@/commands/standards'
-import { register as snippets } from '@/commands/snippets'
 import { register as tooling } from '@/commands/tooling'
 import { register as claude } from '@/commands/claude'
 import { register as wiki } from '@/commands/wiki'
@@ -67,7 +66,6 @@ sandbox(program)
 sync(program)
 gov(program)
 standards(program)
-snippets(program)
 tooling(program)
 claude(program)
 wiki(program)

package/src/commands/feedback-format.ts

@@ -98,7 +98,6 @@ const DOMAIN_LABELS: readonly { pattern: RegExp; label: string }[] = [
   { pattern: /\b(?:cli)s?\b/, label: 'cli' },
   { pattern: /\b(?:tooling|seeds?)\b/, label: 'tooling' },
   { pattern: /\b(?:governance)s?\b/, label: 'governance' },
-  { pattern: /\bsnippets?\b/, label: 'snippets' },
 ]
 
 /**

package/src/commands/gov.ts

@@ -27,7 +27,7 @@ import {
   type RestatedRefusal,
   type RestatedReport,
   readRestated,
-  RULES_REL as RESTATED_RULES_REL,
+  PROJECT_SKILLS_REL,
   SEED_REL,
   SHIPPED_SKILLS_REL,
 } from '@/gov/restated'
@@ -123,7 +123,7 @@ interface CountsOptions {
 /** What a reader does about each way the sweep produced no reading. */
 const RESTATED_REFUSALS: Record<RestatedRefusal, string> = {
   'no-instructions': `No ${INSTRUCTIONS_REL} here, or it carries no bullet, so there is no instruction corpus to sweep.`,
-  'no-surfaces': `None of ${SEED_REL}, ${SHIPPED_SKILLS_REL}/, or ${RESTATED_RULES_REL}/ is here, so no further surface exists to match against.`,
+  'no-surfaces': `None of ${SEED_REL}, ${SHIPPED_SKILLS_REL}/, ${PROJECT_SKILLS_REL}/, ${RULE_DIRS.join('/, or ')}/ is here, so no further surface exists to match against.`,
 }
 
 const COUNTS_REFUSALS: Record<CountsRefusal, string> = {
@@ -275,8 +275,8 @@ export function register(program: Command): void {
         'members a closed catalog holds, then compares the stated figure',
         'against what the tree actually counts.',
         '',
-        'Catalogs read: skills, governance rules, standards, snippets, CLI',
-        'commands, and audit ids. Closed rather than derived, so widening the',
+        'Catalogs read: skills, governance rules, standards, CLI commands,',
+        'and audit ids. Closed rather than derived, so widening the',
         'set is a deliberate change rather than a side effect of a new list',
         'command shipping elsewhere.',
         '',
@@ -469,8 +469,9 @@ export function register(program: Command): void {
       [
         '',
         `Matches every bullet in ${INSTRUCTIONS_REL} and every rule under`,
-        `${RESTATED_RULES_REL}/ against ${SEED_REL}, every`,
-        `${SHIPPED_SKILLS_REL}/*/SKILL.md body, and every other rule. Matching is`,
+        `${RULE_DIRS.join('/ and ')}/ against ${SEED_REL},`,
+        `every ${SHIPPED_SKILLS_REL}/*/SKILL.md and ${PROJECT_SKILLS_REL}/*/SKILL.md body,`,
+        'and every other rule. Matching is',
         'recall-first, keyed on distinctive tokens two statements share rather',
         'than on a phrase they spell the same way, because the case this exists',
         'for was one rule written three different ways.',
@@ -564,7 +565,7 @@ function reportRestated(
   // also says how wide the corpus behind it was.
   logStep('Corpus')
   logInfo(
-    `${report.corpus.instructions} always-loaded instruction(s) and ${report.corpus.rules} rule file(s) against ${report.corpus.candidates} statement(s) from the seed, ${report.corpus.bodies} shipped body/bodies, and every rule again, in ${root}`,
+    `${report.corpus.instructions} always-loaded instruction(s) and ${report.corpus.rules} rule file(s) against ${report.corpus.candidates} statement(s) from the seed, ${report.corpus.bodies} skill body/bodies, and every rule again, in ${root}`,
   )
   logInfo(
     `matched on ${report.matcher.anchors} weighted anchor(s), dropping any token in more than ${report.matcher.common} statements`,

package/src/commands/labels.ts

@@ -25,7 +25,7 @@ interface ScanOptions {
 
 /** What a reader does about each way `checkTitleFormat` graded a title as broken. */
 const TITLE_FORMAT_MESSAGES: Record<TitleFormatIssue, string> = {
-  structure: 'does not match <type>(<scope>): <subject>',
+  structure: 'does not match <type>(<scope>)[!]: <subject>',
   'casing-type': 'the type is not lowercase',
   'casing-scope': 'the scope is not lowercase',
   'casing-subject': 'the first word of the subject is not lowercase',
@@ -153,7 +153,7 @@ export function register(program: Command): void {
         'forcing a new dependency.',
         '',
         "It also grades the title alone against standards/pr.md's ## Title",
-        'section: the `<type>(<scope>): <subject>` structure, lowercase casing',
+        'section: the `<type>(<scope>)[!]: <subject>` structure, lowercase casing',
         'for the type, the scope, and the first subject word, and a 72-',
         'character length cap. A scan given no title, whether from a review',
         'or from a bare --body or --body-file invocation, skips this check',
@@ -374,7 +374,7 @@ async function runScan(opts: ScanOptions): Promise<number> {
     logInfo('the scan carries no title, so there is no format to grade')
   } else if (titleFormat.conforms) {
     logInfo(
-      'the title matches <type>(<scope>): <subject> and its casing and length rules',
+      'the title matches <type>(<scope>)[!]: <subject> and its casing and length rules',
     )
   } else {
     logWarn(

package/src/commands/markdown.ts

@@ -108,14 +108,14 @@ export function register(program: Command): void {
         'out of a standards file, so a project that installed no standards is',
         'measured the same as one that did. markdown.md still states every rule',
         'for a reader. No folder has to resolve and no index.md has',
-        'to exist, so .claude/rules/, governance/, and snippets/ are in reach.',
+        'to exist, so .claude/rules/ and governance/ are in reach.',
         '',
         'Examples:',
         '  canon markdown audit',
         '  canon markdown audit --json',
         '  canon markdown audit .claude/rules governance',
         '  canon markdown audit docs/agents/commands.md',
-        "  canon markdown audit 'snippets/**/*.md'",
+        "  canon markdown audit 'standards/**/*.md'",
         '',
       ].join('\n'),
     )