@erclx/canon 4.126.0 → 5.1.0

package/README.md

@@ -64,7 +64,6 @@ Each domain has a canonical source in this repo and a thin install or sync CLI o
 | Plugin skills  | Skills that plan a feature, review a diff, sync the planning docs, and run the ship chain                                | Loaded live from the plugin, never copied                       |
 | Governance     | Coding and authoring rules that load into a Claude session when a matching path is edited                                | Installed per project by `canon gov install`, refreshed by sync |
 | Standards      | Authoring conventions for commits, branches, plans, tasks, and markdown                                                  | Opened by name, read by name with `canon standards <name>`      |
-| Snippets       | Reusable prompts fired by `@` reference                                                                                  | Resolved live from the plugin                                   |
 | Tooling stacks | Golden configs, seeds, and a reference per framework                                                                     | Laid down by `canon init`, reconciled by `canon tooling sync`   |
 | Design system  | Ships a `DESIGN.md` token format, a skill that drafts one from an existing project or from scratch, and a render command | `canon design render`                                           |
 | Slides         | A `SLIDES.md` source format with a layout catalog                                                                        | `canon slides render` writes PowerPoint                         |
@@ -96,7 +95,7 @@ Working with an agent rather than reading this yourself? It loads `CLAUDE.md` at
 - [AI workflow](docs/workflow/ai-workflow.md): feature-development loop inside a toolkit-managed project
 - [Operating model](docs/workflow/operating-model.md): orchestrator, planner, and worker roles for building across parallel sessions
 - [Visual design workflow](docs/workflow/visual-design-workflow.md): tiered guide for design and wireframe authoring
-- [Target projects](docs/target/target-projects.md): scaffold, add a domain later, sync upstream drift
+- [Target projects](docs/target/projects.md): scaffold, add a domain later, sync upstream drift
 - [Agents](docs/agents/index.md): CLI flags, exit codes, and JSON output shapes
 - [Docs index](docs/index.md): every reference doc in this repo
 
@@ -150,9 +149,9 @@ canon init
 
 `canon init` installs base tooling configs, Claude seeds, and governance rules in one pass, and scaffolds a `.claude/wiki/` stub for your project's own reference pages. Governance defaults to the `base` stack, so a bare init lands the coding and doc-authoring rules in `.claude/rules/`. Each rule names the standard it answers to and reads it with `canon standards <name>`, so no corpus is copied into your project.
 
-Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. A snippet resolves the same way, reached at its `@` reference through the plugin's live `claude/snippets` symlink rather than a copy. Run `canon tooling list --json` to see the catalog.
+Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. Run `canon tooling list --json` to see the catalog.
 
-For the full journey from scaffold through adding a domain later to syncing upstream drift, see [target projects](docs/target/target-projects.md).
+For the full journey from scaffold through adding a domain later to syncing upstream drift, see [target projects](docs/target/projects.md).
 
 ### Internal narrative
 
@@ -161,11 +160,10 @@ Each domain carries an entry written for someone maintaining the toolkit rather
 - [Claude Code plugin](canon/context/claude-plugin/index.md)
 - [Governance rules](canon/context/governance/index.md)
 - [Standards](canon/context/standards/index.md)
-- [Snippets](canon/context/snippets.md)
 - [Tooling stacks](canon/context/tooling/index.md)
 - [Design system](canon/context/design/index.md)
-- [Slides](canon/context/slides.md)
-- [Transcripts](canon/context/transcripts.md)
+- [Slides](canon/context/features/slides.md)
+- [Transcripts](canon/context/features/transcripts.md)
 - [Sandbox](canon/context/sandbox/index.md)
 
 ## Contributing

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "4.126.0",
+  "version": "5.1.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/auto-ship/references/verb-absent.md

@@ -24,7 +24,6 @@ Behavior paths carry two spellings, the one a surface authors at and the one it
 - `claude/skills/` and `.claude/skills/`
 - `governance/rules/` and `.claude/rules/`
 - `standards/`, which is the authoring root and reaches a reader by resolution rather than by an install, so it carries no `.claude/` spelling
-- `snippets/`, which reaches a session through the `claude/snippets` symlink rather than an install, so it carries no `.claude/` spelling either
 - `internal/` and `tooling/`, which hold the stack references and the seed documents a target is handed
 - `CLAUDE.md` at the repository root, named as a file because a path prefix reaches nothing that sits in no folder
 

package/claude/skills/canon-feedback/REQUIREMENT.md

@@ -9,7 +9,7 @@ description: Why a toolkit defect is reported from session context alone, and wh
 
 Without this skill, a toolkit defect noticed inside a target project dies with the session. The user is told to mention it in the toolkit repository later, which means retyping a report they no longer have the context to write, so the defect is either reported badly or not at all.
 
-The report itself fails two ways. A block printed in chat needs a copy-paste into another repository, and a step that manual is skipped under any time pressure. A report that names no surface cannot be routed, because the toolkit acts on a plugin skill, a snippet, a CLI command, and a seed through different paths, and the difference is not recoverable from the symptom.
+The report itself fails two ways. A block printed in chat needs a copy-paste into another repository, and a step that manual is skipped under any time pressure. A report that names no surface cannot be routed, because the toolkit acts on a plugin skill, a CLI command, and a seed through different paths, and the difference is not recoverable from the symptom.
 
 The last failure is the session's own effort. Asked to report, a session starts diagnosing instead, searching the toolkit and reading its surfaces to find the cause. That spends the context the report was meant to capture cheaply, and it produces a diagnosis from a project that cannot see the toolkit's current source.
 

package/claude/skills/canon-feedback/SKILL.md

@@ -10,7 +10,7 @@ Format a `## Toolkit feedback` block from the current session, then open it as a
 ## Guards
 
 - If nothing in session context points to a toolkit issue, stop: `❌ No toolkit issue in session context. Describe what broke, then re-invoke.`
-- If the surface type is ambiguous (snippet vs. plugin skill vs. CLI vs. seed), ask one line before formatting.
+- If the surface type is ambiguous (plugin skill vs. CLI vs. seed), ask one line before formatting.
 - Do not probe the project, list files, grep, or read toolkit surfaces. Use only what the session already contains.
 
 ## Step 1: build the block
@@ -18,7 +18,7 @@ Format a `## Toolkit feedback` block from the current session, then open it as a
 From the conversation so far, identify:
 
 - Target project name or kind, never its full path. The path names a folder on one machine and says nothing a triage session can route on, where the project's own name does. Name a private project by its kind instead, such as `a Next.js app`, since the report leaves the machine.
-- Toolkit surface and its type (plugin skill, snippet, tooling config, governance rule, seed, or CLI). The type leads the `### Surface` field, ahead of the first comma, because the CLI picks the issue's domain labels from that text alone.
+- Toolkit surface and its type (plugin skill, tooling config, governance rule, seed, or CLI). The type leads the `### Surface` field, ahead of the first comma, because the CLI picks the issue's domain labels from that text alone.
 - Specific toolkit file or name when the session cites one
 - Observed behavior
 - Expected behavior, or `unclear`

package/claude/skills/canon-operator/REQUIREMENT.md

@@ -9,7 +9,7 @@ description: Why the toolkit has one front door, what orienting on live catalogs
 
 Without this skill, using the toolkit means knowing which skill to pick, and the user who most needs it is the one who cannot. A plain-language intent has no obvious owner among a dozen setup and sync skills, so the session guesses a command instead of resolving one, and a wrong guess installs into a project rather than reporting a mismatch.
 
-Two failures come from acting on memory. A session that names a stack, rule, or snippet from what it remembers rather than from the live catalog runs against an entry that has been renamed or removed. And a session that edits a managed file by hand produces a change the next sync overwrites, which reads as the toolkit undoing work rather than as the edit having been made in the wrong place.
+Two failures come from acting on memory. A session that names a stack or rule from what it remembers rather than from the live catalog runs against an entry that has been renamed or removed. And a session that edits a managed file by hand produces a change the next sync overwrites, which reads as the toolkit undoing work rather than as the edit having been made in the wrong place.
 
 The third failure is duplication. A front door that answers everything itself reimplements first-time detection and seed diffing inline, badly, beside the skills that already do both. The value of a router is that it stops at the handoff.
 
@@ -23,7 +23,7 @@ The last failure is a section no route reaches. `## Route` maps an intent or a d
 
 - Orient on the toolkit's own docs and the live catalogs before acting
 - Map the stated intent to one lifecycle phase, then either run the simplest command that satisfies it or hand off
-- Resolve every stack, rule, snippet, and standard name from a catalog at runtime
+- Resolve every stack, rule, and standard name from a catalog at runtime
 - Run the CLI non-interactively and report the command run, what changed, and the full path of anything written
 - Read the overwrite contract from the body before any install or sync, and name each surface it lists as overwritten before running one
 - Read the reverse walk beside the forward sections, so a folder the toolkit stopped shipping reaches the user

package/claude/skills/canon-operator/SKILL.md

@@ -14,9 +14,9 @@ Run these from the target project root, in parallel, before acting:
 
 - `canon docs list`: the index of toolkit reference docs
 - `canon docs agents`: the CLI command catalog and invocation contract
-- `canon docs target-projects`: the scaffold, add-a-domain, and sync lifecycle
+- `canon docs projects`: the scaffold, add-a-domain, and sync lifecycle
 
-Load a domain doc with `canon docs <topic>` only when the intent touches that domain. Read the live catalog for any domain you act on with `canon <domain> list --json`. Never hardcode stack, rule, snippet, or standards names.
+Load a domain doc with `canon docs <topic>` only when the intent touches that domain. Read the live catalog for any domain you act on with `canon <domain> list --json`. Never hardcode stack, rule, or standards names.
 
 ## Diagnose
 
@@ -50,7 +50,7 @@ The two can name different rows, and a reply answers both rather than picking on
 - Governance rules for the project stack: hand off to `target-setup`, which installs them alone on its `gov` phase
 - Bootstrap the `index.md` system: hand off to `target-setup`, which bootstraps it on its `indexes` phase
 - Seed or standards drift in `CLAUDE.md` or `.claude/` preambles: hand off to `seed-sync`
-- Install one snippet, standard, or rule: run the domain `install` command
+- Install one rule: run the domain `install` command
 - Sync one domain or every installed domain: run `canon <domain> sync` or `canon sync`
 - Fix only the ignore entries of the installed stack: run `canon tooling inject --gitignore <stack>`
 - Measure a surface without changing it: offer the audits under `### Audits`

package/claude/skills/codebase-layout/REQUIREMENT.md

@@ -20,6 +20,7 @@ Sharpening the rules does not reach the decision. Both were loaded and neither w
 - State the split trigger as a second role entering a folder, with a file count only as a prompt to look
 - State colocation with the one consumer and promotion on the second, and imports flowing from shared toward features toward the app entry
 - Require a one-clause placement reason on every new path the plan names
+- State that a file is named for what it covers inside its folder, never repeating the folder's name as its stem or its prefix, since a name placed beside its neighbor copies the neighbor's prefix along with its folder
 - Hold the stack-neutral core in the body and defer category specifics to a reference loaded only when a new path falls in that category
 - Record the external layouts adopted and declined with the reason for each, so a later session extends the position instead of re-deriving it
 - Fire on a direct question about placement as well, such as where a file goes or whether a flat folder should split, since a session outside any plan still places files

package/claude/skills/codebase-layout/SKILL.md

@@ -23,6 +23,12 @@ Skip it when every path the work names already exists.
 - Name a folder for what it holds for a reader, being a feature, a route, or a role, over its technical kind alone. `checkout/` tells a reader what is inside where `helpers/` does not.
 - Never create a bucket named `misc`, `common`, `utils`, or `helpers` on its own. Qualify it by what it serves, or place the file with its consumer.
 
+## Name a file for what it covers inside its folder
+
+- Never repeat the folder's name as a file's whole stem or as its prefix. `billing/invoice.md` says what `billing/billing-invoice.md` says with one word fewer in every path that cites it.
+- Drop the prefix when a file moves into a subfolder that now states it, and retarget every citation of the old path in the same change.
+- Read the stem as the basename up to its first dot, so `checkout/checkout.test.ts` repeats its folder as much as `checkout/checkout.md` does.
+
 ## Split before the file lands
 
 - Split a folder when the new file brings a second role into it, before the file lands rather than in a later refactor. The split that touched 98 files would have touched a handful when the folder held eleven.

package/claude/skills/create-rule/REQUIREMENT.md

@@ -42,4 +42,4 @@ The subdir gets picked by feel, so a UI copy rule lands in the always-on folder
 - Editing a rule that already exists
 - Toolkit source rules, which are authored in the toolkit rather than in a target
 - Installing the rules the toolkit ships, which the governance setup path owns
-- A standard, which `create-standard` owns, and a snippet, which `create-snippet` owns
+- A standard, which `create-standard` owns

package/claude/skills/create-standard/REQUIREMENT.md

@@ -24,12 +24,10 @@ A standard written and left there is the third. The index entry and the context
 ## Must not
 
 - Work the standard's shape or frontmatter from memory
-- Write a snippet, which carries no frontmatter and answers to a different authoring contract
 - Write into `.claude/standards/`, which no repository generates and no resolver reads
 
 ## Out of scope
 
 - Editing a standard that already exists
-- A snippet, which `create-snippet` owns
 - A path-scoped coding rule, which `create-rule` owns
 - Reading a standard the toolkit ships, which `canon standards <name>` owns

package/claude/skills/decision-escalate/REQUIREMENT.md

@@ -15,7 +15,7 @@ A body written around a named tool fails a third way. A session on a surface car
 
 The opposite failure is the one that ships silently. A session that takes a preference decision itself produces work the operator did not ask for and never learns a choice was made, because nothing in the output says a fork was passed.
 
-`CLAUDE.md` states both branches of the rule, sending an ordinary judgment call to a pick with the tradeoff in one sentence and a preference-deciding call to the operator. The first branch has the toolkit's `snippets/decision-help.md` behind it, which installs into a project that took snippets as `.claude/snippets/decision-help.md`. The second branch now states how a question is shaped and where it is put, so this skill inherits both and adds only what a batch needs on top of one question.
+`CLAUDE.md` states both branches of the rule, sending an ordinary judgment call to a pick with the tradeoff in one sentence and a preference-deciding call to the operator. The second branch now states how a question is shaped and where it is put, so this skill inherits both and adds only what a batch needs on top of one question.
 
 ## Must
 
@@ -40,6 +40,5 @@ The opposite failure is the one that ships silently. A session that takes a pref
 ## Out of scope
 
 - Making the ordinary judgment call, which is a pick plus a one-sentence tradeoff and needs no surface
-- The chat-side pick with no repository behind it, which the toolkit's `snippets/decision-help.md` covers and reaches a different reader
 - Writing the decision into a plan, task, or architecture record, which each owning standard governs and this skill only routes to
 - Deciding when to fire. The skill is user-invoked through `disable-model-invocation`, so escalating is the operator's call rather than a description match.

package/claude/skills/draft-context/REQUIREMENT.md

@@ -34,4 +34,4 @@ Without this skill, a session documenting a domain that has no context entry yet
 - Refreshing an existing `canon/context/<domain>.md` entry against a diff: `context-fold`
 - Drafting a `canon/wireframes/<surface>.md` file: `draft-wireframes`
 - Drafting a `docs/*.md` page: `draft-docs`
-- Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`
+- Drafting a standard or a governance rule: `create-standard`, `create-rule`

package/claude/skills/draft-docs/REQUIREMENT.md

@@ -32,4 +32,4 @@ Without this skill, a session drafting documentation for a surface that has no p
 
 - Rewriting or syncing an existing `docs/*.md` section against a diff since main: `docs-sync`
 - The context entries, requirements, architecture, wireframes, and task board: `context-fold`
-- Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`
+- Drafting a standard or a governance rule: `create-standard`, `create-rule`

package/claude/skills/draft-wireframes/REQUIREMENT.md

@@ -34,5 +34,5 @@ Without this skill, a session drafting a wireframe for a surface with no file ye
 - Stubbing a surface a diff touched, or reporting drift in an existing wireframe against a diff: `claude/skills/context-fold/references/wireframe-sweep.md`
 - Drafting a `canon/context/<domain>.md` entry: `draft-context`
 - Drafting a `docs/*.md` page: `draft-docs`
-- Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`
+- Drafting a standard or a governance rule: `create-standard`, `create-rule`
 - Building or wiring an actual tier-1 or tier-2 rendering pipeline: the visual design workflow's own tier guidance, out of reach of a hand-drafting skill

package/claude/skills/git-pr/references/task-number.md

@@ -21,6 +21,8 @@ The verb resolves the board at the main worktree root in-process, adds `Pull req
 
 The correction reaches only a line that does not read as a list of `#NNN` entries. A line that does takes the new number appended rather than replaced, reported as `appended`, so a task shipped in slices keeps every pull request.
 
+The same write drops this branch from the task's `Pending branch:` line, which `canon tasks outcome` wrote when the branch ticked an outcome, so this step is what lets the merge-time archive close the task.
+
 Skip this silently when the record is `ok: false` and `reason` is `no-board`, `no-match`, or `ambiguous`. Those are the three cases a guessed write would compound: no board, no task naming the plan, or more than one. One pull request names one task, and a wrong match archives the wrong task unattended once the branch merges. Report any other refusal rather than swallowing it.
 
 The number is what lets the merge close the task. Every merge on `main` is a squash carrying it in the subject, so the number survives where a branch name does not, and `post-merge` reads it back to call `canon tasks archive`. Writing it here rather than at worktree time is what makes it a pull request number rather than a branch the squash discards.

package/claude/skills/plan-intake/SKILL.md

@@ -73,7 +73,7 @@ Two heading levels is the right depth. A third means the cluster should have bee
 
 Write every item in the standard's item format, in the cluster file its fix belongs to. Close each item with a verdict and an empty operator slot, and never fill that slot or read an empty one as agreement.
 
-Where an item's call is the operator's, pair it with a suggestion rather than a bare question. The toolkit's `decision-help` snippet writes the same shape for chat use, and the standard's item format is the whole spec.
+Where an item's call is the operator's, pair it with a suggestion rather than a bare question. The standard's item format is the whole spec.
 
 ## Step 6: write the index
 

package/claude/skills/target-setup/REQUIREMENT.md

@@ -27,7 +27,7 @@ two copies could disagree with nothing comparing them.
 
 ## Must
 
-- Read the toolkit catalogs before resolving, and hardcode no stack, rule, or snippet name
+- Read the toolkit catalogs before resolving, and hardcode no stack or rule name
 - Preview the resolved arguments and the exact commands before the first write
 - Mark a fallback resolution as a fallback in the preview, where it can still be declined
 - Run every phase without a TTY, and carry an argument for each prompt a phase would otherwise open
@@ -41,7 +41,7 @@ two copies could disagree with nothing comparing them.
 - Generate a config the tooling stack ships as a golden file
 - Install Claude Code plugins, which provision a machine rather than a project
 - Fail an unattended scaffold on a server start, which is flaky enough to be a depth the operator asks for
-- Survive as a skill nothing invokes but a person typing its name. `canon-operator` hands first-time scaffold here and the target-projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
+- Survive as a skill nothing invokes but a person typing its name. `canon-operator` hands first-time scaffold here and the target projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
 
 ## Guards
 

package/claude/skills/target-setup/SKILL.md

@@ -10,7 +10,7 @@ arguments, previews the chain, runs `canon init`, then verifies what landed and
 bootstraps the `index.md` system over the project's own documentation folders.
 
 The CLI holds the install logic. This skill resolves, previews, and routes. It
-reimplements no verb and hardcodes no stack, rule, or snippet name.
+reimplements no verb and hardcodes no stack or rule name.
 
 ## Phases
 

package/claude/skills/target-setup/references/detect.md

@@ -11,7 +11,7 @@ they install rather than in how they read the project.
 
 ## Read the catalogs
 
-Run in parallel. Never hardcode stack, rule, snippet, or standards names. The
+Run in parallel. Never hardcode stack, rule, or standards names. The
 catalog is the source of truth.
 
 Run from the target project's current directory. Do not cd into the toolkit

package/claude/skills/target-setup/references/indexes.md

@@ -21,13 +21,9 @@ before scanning.
 ## Scan
 
 Walk the project root for folders containing three or more sibling `*.md` files.
-Prune `.git`, `node_modules`, `.claude`, `snippets`, anything matched by
+Prune `.git`, `node_modules`, `.claude`, anything matched by
 `.gitignore`, and any folder that already contains an `index.md`.
 
-Skip `.claude/snippets/`. Snippets are invoked by reference (`@snippet-name`)
-rather than browsed, so they need neither `index.md` nor per-file frontmatter.
-Adding them creates noise that targets keep reporting.
-
 For each candidate, capture:
 
 - Folder path relative to project root

package/claude/skills/task-board/references/archive.md

@@ -42,6 +42,7 @@ Each reason has one resolution and none of them is to archive around it:
 - `open-outcomes`: the named outcomes are unmarked or genuinely open. Run `context-fold` when the work shipped and nothing marked it. Leave the task on the board when the outcome is real. When the work is being abandoned, cut it by striking the body, `- ~~<outcome>~~ <why>`, whatever the checkbox holds, so the board records what was dropped rather than meeting this refusal a second time.
 - `ambiguous`: two tasks name one pull request, which is the misfile `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` rules out. Resolve the citation by hand, since no sweep repairs it.
 - `earlier-slice`: the number is listed on the task but is not the last, so a later slice is still to merge. Leave the task on the board. Its last slice's merge archives it.
+- `pending-branch`: a branch named in `detail` ticked an outcome before its own pull request number was recorded. Leave the task live, since that branch's merge archives it once `git-pr` records the number. When the operator decides a named branch was abandoned, archive by stem, which is the one case for it.
 - `no-match`: the stem or number names nothing on the board. Check the name against the listed stems.
 - `bad-input`: the command line was wrong rather than the board. Read the message, fix the arguments, and run it again. Nothing on the board needs repair, which is what separates this from the two above.
 

package/docs/agents/commands.md

@@ -20,7 +20,6 @@ One row per top-level command, in the order `canon --help` prints them. A domain
 | `canon targets <verb>`      | Report the projects this toolkit installed into                                 |
 | `canon gov <verb>`          | Install and sync governance rules, and audit the tree against them              |
 | `canon standards <verb>`    | List, audit, or print a standard by name                                        |
-| `canon snippets <verb>`     | List or scaffold prompt snippets                                                |
 | `canon tooling <verb>`      | Sync, diff, and verify tooling stacks                                           |
 | `canon claude <verb>`       | Install the Claude workflow and audit both skill corpora                        |
 | `canon wiki <verb>`         | Scaffold the wiki pages                                                         |
@@ -61,7 +60,7 @@ A port already in use is the ordinary case rather than a refusal, so it walks fo
 
 A request naming a directory is redirected to its trailing-slash form rather than answered in place. A browser resolves a relative asset against the last slash of the URL it is on, so answering `/lesson` directly leaves the page asking for `/course.css` instead of `/lesson/course.css`, and it renders unstyled through the server that exists to prevent exactly that.
 
-Containment is tested after symlinks are followed rather than on the path as written, and the test sits immediately before the read rather than beside the request that produced it. Resolving a request lexically clears a link pointing outside the served root, and this repository is a live instance of that shape, since `claude/standards` and `claude/snippets` are links out of `claude/`. Position is what makes the property hold: a directory request appends its index after the request path has been checked, so a check placed earlier leaves that index untested. `--index` answers a directory holding no `index.html` with a listing read per request, where the default stays a 404. Every entry the listing names takes the same containment test a request for it would, so a link out of the root is absent rather than greyed, and dotfiles are hidden. With no `--entry` and no root `index.html`, the printed link is `/` and `entryExists` reads true. An `--entry` that escapes the root refuses with `no-entry` before a port is taken, because `url` is the field a caller hands to a reader.
+Containment is tested after symlinks are followed rather than on the path as written, and the test sits immediately before the read rather than beside the request that produced it. Resolving a request lexically clears a link pointing outside the served root, and this repository is a live instance of that shape, since `claude/standards` is a link out of `claude/`. Position is what makes the property hold: a directory request appends its index after the request path has been checked, so a check placed earlier leaves that index untested. `--index` answers a directory holding no `index.html` with a listing read per request, where the default stays a 404. Every entry the listing names takes the same containment test a request for it would, so a link out of the root is absent rather than greyed, and dotfiles are hidden. With no `--entry` and no root `index.html`, the printed link is `/` and `entryExists` reads true. An `--entry` that escapes the root refuses with `no-entry` before a port is taken, because `url` is the field a caller hands to a reader.
 
 `canon demo` is the second browser command and the one that ships, since its purpose is running in a target rather than regenerating what this repository commits. It needs a browser binary the package does not carry, installed once with `bunx playwright install chromium`.
 
@@ -85,7 +84,6 @@ Each domain exposes a consistent shape where applicable: `list`, `install`, `syn
 - `targets`, in `targets.md`: `list`, `pulls`
 - `gov`, in `install-and-sync.md`: `list`, `install`, `sync`, `build`, `regen`, `test-order`, `counts`, `superseded`, `citations`, `restated`
 - `standards`, in `standards-audit.md`: `list`, `audit`, `<name>`
-- `snippets`, in `install-and-sync.md`: `list`, `create`
 - `tooling`, in `install-and-sync.md`: `list`, `sync`, `diff`, `reference`, `create`, `verify`, `inject`, `prune-gitignore`
 - `claude`, in `skills-audit.md`: `init`, `sync`, `setup`, `routing`, `plugin-update`, `seeds list`, `skills list`, `skills audit`, `skills drift`, `skills reach`, `skills rank`
 - `wiki`, in `scripting.md`: `init`

package/docs/agents/counts.md

@@ -22,12 +22,11 @@ Under `--json` the record holds stdout alone and the frame still renders on stde
 
 ## The catalogs it reads
 
-A closed set of six, each with a filesystem reader behind it rather than every list command this CLI ships:
+A closed set of five, each with a filesystem reader behind it rather than every list command this CLI ships:
 
 - `skills`: shipped plugin skills, a folder per `claude/skills/*/SKILL.md`
 - `rules`: authored governance rules, a file per `governance/rules/**/*.md`
 - `standards`: the authoring corpus at `standards/`
-- `snippets`: distinct entries across every `snippets/` category, matching what `regen-hero.sh` counts
 - `commands`: top-level `canon` commands, read off `src/cli.ts`'s registration imports
 - `audits`: the registered set in `src/audits/catalog.ts`, this entry included
 

package/docs/agents/docs.md

@@ -16,7 +16,7 @@ A domain too large for one file splits into `<domain>/` with a generated `index.
 
 A sub-area file resolves by its bare name too, so `canon docs operating-model` reaches `docs/workflow/operating-model.md`. Three spellings are tried in order, being a sibling file, a folder of that name, then a sub-area file one level down, and each spelling is tried across both roots before the next one runs. A sibling file therefore wins over a folder of the same name, and both win over a sub-area file. Reading the folder last is what keeps the sub-area spelling from changing any name that resolved before it existed.
 
-A bare name carried by two folders resolves to neither. Eight context folders hold an `overview.md`, so `canon docs overview` names the available topics and exits 1 rather than answering with whichever folder sorts first.
+The sub-area spelling keeps the root order too. The first root whose folders carry the name answers, so `canon docs indexes` reaches `docs/agents/indexes.md` even though a context folder holds an entry of the same name. A bare name carried by two folders of that one root resolves to neither, which names the available topics and exits 1 rather than answering with whichever folder sorts first.
 
 `canon docs list` stops at the folder where `canon docs <topic>` goes on to name each file inside it. The listing is the downstream catalog rather than the index of what a name reaches, so a sub-area file appears there only where it declares a target-facing `category` of its own, and no sub-area file of the context root appears at all. A name that resolves and does not list is the divergence the toolkit-internal topics already carry.
 

package/docs/agents/drift-surfaces.md

@@ -61,10 +61,12 @@ root reports zero entries for that domain and reads as clean, which is the most
 misleading state the report can produce.
 
 The field currently names no domain. Standards and snippets are the two the
-toolkit ever installed at a project root, and both closed their install channel,
-so a project still holding a root `standards/` or `snippets/` folder is carrying
-its own authoring surface rather than an unfinished install. Nothing proposes
-moving either, and no command relocates the content. Move it yourself.
+toolkit ever installed at a project root. Standards closed its install channel
+and snippets retired outright, so a project still holding a root `standards/`
+folder is carrying its own authoring surface rather than an unfinished install.
+Nothing proposes moving it, and no command relocates the content. Move it
+yourself. A leftover `snippets/` folder reports under the reverse walk instead,
+where `docs/target/sync.md` says what to do with it.
 
 ## Rules the target never received
 

package/docs/agents/index.md

@@ -42,7 +42,7 @@ CLI catalog and invocation rules for agents, split by command domain. Start with
 - [Records stale](records-stale.md): Reading the memory pen as a review queue, what makes an entry due, how a cited path is read and resolved, the order entries come back in, and the exit codes and refusals
 - [Records validate](records-validate.md): Validating the session records and the standards corpus, the per-kind checks, which root each kind defaults to, the exit codes, and the refusal reasons
 - [Records](records.md): The two roots a record folder resolves at, migrating a record a frontmatter change orphaned, claiming the ordinal intake and groundwork share, reading each folder's size and growth, pruning stale scratch, and where validation, the memory review queue, and the private-remote backup are described
-- [Restated instructions](restated.md): Counting the instructions the always-loaded file and every path-scoped rule share with the seed, the shipped skill bodies, and each other, how a match is decided, the three classes, which surface a later edit starts from, and why the sweep reports rather than gates
+- [Restated instructions](restated.md): Counting the instructions the always-loaded file and every path-scoped rule share with the seed, the skill bodies, and each other, how a match is decided, the three classes, which surface a later edit starts from, and why the sweep reports rather than gates
 - [Review classification](review-classification.md): Deciding whether a changed set needs the review pass, the two tests it runs, why an empty set refuses rather than skipping, and the written fallback a target on an older binary falls back to
 - [Routing report](routing.md): Reading per CLAUDE.md section how many bullets name a path, what counts as naming one, when a rule counts as covering it, the two refusals, and why the verb reports rather than gates
 - [Rule citations](rule-citations.md): Resolving every path a governance rule cites and every frontmatter glob the internal corpus declares, the three forms a citation is written in, the shapes that look like citations and are not, the two classes where an absent path is correct, why the glob half reads one corpus, and why this one gates

package/docs/agents/indexes.md

@@ -48,4 +48,4 @@ Exit codes: `0` no errors, `1` root not a directory, or a folder failed frontmat
 
 A git-ignored indexed folder, such as `.canon/tasks/` or `.canon/memory/`, never appears in the output. `listIndexes` filters candidates through `git check-ignore` the same way `regen`'s whole-repo walk does, which is the right default for a documentation lookup since those rows are session scratch, but it is a gap against `regen`'s positional-path mode, which bypasses that filter for those two folders.
 
-For the system rationale, frontmatter contract, when to adopt, and bootstrap path, see `canon/context/indexes.md`.
+For the system rationale, frontmatter contract, when to adopt, and bootstrap path, see `canon/context/context-model/indexes.md`.

package/docs/agents/install-and-sync.md

@@ -76,12 +76,6 @@ installs into no project, so the domain has nothing in a target to reconcile.
 and then the corpus inside the package, and `canon standards list --json` carries
 the catalog.
 
-There is no `canon snippets sync` and no `canon snippets install` either, on the
-same ground: `claude/snippets` in the plugin cache symlinks live to the
-toolkit's own `snippets/`, so a session reaches one at its `@` reference with
-no copy to reconcile. `canon snippets list --json` carries the catalog and
-`canon snippets create` is the one verb left that still writes a file.
-
 ## Tooling diff and sync
 
 `canon tooling diff <stack> [target]` is the read-only comparison, and a session asking what differs reaches for it by default. It writes nothing and exits 1 when anything differs and 0 when nothing does, so it gates CI. `--json` adds the scan record on stdout with `ok: true`, and the frame goes to stderr. A refusal such as an unknown stack, an excluded stack, or a toolkit-root target still exits 1 and answers `{ ok: false, reason, message }`, so a caller branches on the record and reads a typo'd stack name as a refusal rather than as drift.
@@ -244,8 +238,7 @@ still prompts. `--skip` takes `wiki`, `governance`, and `records`, and warns
 without aborting on any other value. Records has nothing to run non-interactively,
 since the private backup repository does not exist yet at scaffold time, so its
 step only prints the one-time setup reminder and `--skip records` silences it.
-There is no `--standards` and no `--snippets`, since no run writes either corpus
-into the target.
+There is no `--standards`, since no run writes that corpus into the target.
 
 ## Unguarded tooling primitives
 

package/docs/agents/markdown-audit.md

@@ -5,14 +5,14 @@ description: Running the audit over any markdown path, where its bans and checkp
 
 # Markdown audit
 
-`canon markdown audit [path...]` reports any markdown file against the attribute standard `markdown.md`. An attribute standard governs a file rather than a folder, so this resolves no folder and requires no `index.md`, which is what puts `.claude/rules/`, `governance/`, and `snippets/` in reach. Folder-shaped findings stay in `canon context audit`, described in `context-audit.md`.
+`canon markdown audit [path...]` reports any markdown file against the attribute standard `markdown.md`. An attribute standard governs a file rather than a folder, so this resolves no folder and requires no `index.md`, which is what puts `.claude/rules/` and `governance/` in reach. Folder-shaped findings stay in `canon context audit`, described in `context-audit.md`.
 
 ```bash
 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'
 ```
 
 | Option   | Behavior                                                   |

package/docs/agents/restated.md

@@ -1,6 +1,6 @@
 ---
 title: Restated instructions
-description: Counting the instructions the always-loaded file and every path-scoped rule share with the seed, the shipped skill bodies, and each other, how a match is decided, the three classes, which surface a later edit starts from, and why the sweep reports rather than gates
+description: Counting the instructions the always-loaded file and every path-scoped rule share with the seed, the skill bodies, and each other, how a match is decided, the three classes, which surface a later edit starts from, and why the sweep reports rather than gates
 ---
 
 # Restated instructions
@@ -25,10 +25,10 @@ Under `--json` the record holds stdout alone and the frame still renders on stde
 Four surfaces, and they are not read symmetrically. Every top-level bullet in `CLAUDE.md` and in every path-scoped rule is a subject, and every surface below is searched, rules included a second time:
 
 - `tooling/claude/seeds/CLAUDE.md`, read as bullets, since the seed carries the same shape as the file it is authored from
-- `claude/skills/*/SKILL.md`, read as every prose line and bullet, since the motivating case was stated in a body as a paragraph rather than a list item
-- `governance/rules/**/*.md`, the authoring root rather than the consumed copy under `.claude/rules/`, read as bullets the same way the seed is
+- `claude/skills/*/SKILL.md` and `.claude/skills/*/SKILL.md`, read as every prose line and bullet, since the motivating case was stated in a body as a paragraph rather than a list item. The second root holds the project's own skills, which are equally a place a rule gets restated
+- `governance/rules/**/*.md` and `internal/rules/**/*.md`, the authoring roots rather than the consumed copy under `.claude/rules/`, read as bullets the same way the seed is. Each record's `file` carries the root it was read from
 
-A rule reads as both a subject and a candidate, unlike the seed and the shipped bodies. A stack ships a whole rule folder, so a bullet duplicated between two rules reaches a target exactly as a bullet duplicated between the always-loaded file and a rule does, and neither shape is visible from one side alone. A candidate sharing its subject's file is skipped, since two bullets inside one rule sharing anchors are adjacent instructions on one topic rather than the same rule shipped twice, and a pair found from one direction is not reported again from the other.
+A rule reads as both a subject and a candidate, unlike the seed and the skill bodies. A stack ships a whole rule folder, so a bullet duplicated between two rules reaches a target exactly as a bullet duplicated between the always-loaded file and a rule does, and neither shape is visible from one side alone. A candidate sharing its subject's file is skipped, since two bullets inside one rule sharing anchors are adjacent instructions on one topic rather than the same rule shipped twice, and a pair found from one direction is not reported again from the other.
 
 Frontmatter, headings, tables, and fenced blocks are read past. A heading names a section instead of stating a rule, a fenced block is an example whose words belong to the prose around it, and a body's `description` restates that skill's own purpose, so sweeping it would match every subject naming its domain.
 
@@ -58,6 +58,8 @@ Polarity is read off the clause the anchors landed in, and off the densest such
 
 The marker also has to open its clause, because an instruction leads with its verb. `Never delete a task file` prohibits where `a fallback never fires` reports, and no test reading the marker anywhere in the clause tells those apart. What that costs is a prohibition written mid-clause, which now reads as description and lands the pair in the repetition class, so both surfaces still reach the report and only the label is weaker.
 
+One mid-clause shape still counts. A `no` opening a clause or a comma-set phrase directly on a code span prohibits, as in `pinned to major tags, no` followed by the pinned tag, since sitting on an identifier it names what is ruled out. The phrase boundary keeps description out: `returns no` then a code span puts the marker after a verb and reports what happens. `not` and `never` in the same position are left out, because admitting them turned agreeing pairs into false contradictions.
+
 A mirror that disagrees stays a finding. The exclusion reaches a repetition alone, because the two files on a declared pair are meant to agree.
 
 ## Which surface is authoritative
@@ -76,6 +78,6 @@ Exit codes are `0` when no instruction is restated outside a declared mirror, `1
 
 Nothing wires this into `bun run check` or into a hook. A restatement is legitimate more often than not, and gating a measure whose ordinary result is a finding is what teaches contributors to route around the stage. `canon gov test-order` and `canon labels audit` are the siblings.
 
-Both refusals are absences rather than breaks. A target holds none of the seed, a shipped skills tree, or a rules tree, so `canon audits run` reads `no-instructions` and `no-surfaces` as a corpus that is not there rather than a verb that failed.
+Both refusals are absences rather than breaks. A target may hold none of the seed, a skills tree, or a rules tree, so `canon audits run` reads `no-instructions` and `no-surfaces` as a corpus that is not there rather than a verb that failed.
 
 An exit code says nothing about a call made from a session, since a shell profile may wrap the binary in a function taking its status from a later command. Read the record's `counts` rather than the exit when a skill consumes this.

package/docs/agents/review-classification.md

@@ -40,11 +40,10 @@ Most carry two spellings, the one a surface authors at and the one it reaches a
 | Plugin skills     | `claude/skills/`, `.claude/skills/`   |
 | Governance rules  | `governance/rules/`, `.claude/rules/` |
 | Standards         | `standards/`                          |
-| Snippets          | `snippets/`                           |
 | Internal and seed | `internal/`, `tooling/`               |
 | Root instructions | `CLAUDE.md`                           |
 
-`standards/` and `snippets/` carry one spelling apiece. Neither installs into a project, reaching a reader by resolution and through the `claude/snippets` symlink respectively, so there is no consumed copy to name.
+`standards/` carries one spelling. It never installs into a project, reaching a reader by resolution, so there is no consumed copy to name.
 
 `CLAUDE.md` is matched as a whole path rather than as a prefix, because a prefix reaches nothing that sits in no folder. A nested `docs/CLAUDE.md` stays informational.
 

package/docs/agents/scripting.md

@@ -14,7 +14,6 @@ Use these to discover what's available instead of hardcoding names.
 | Command                           | Returns                                                          |
 | --------------------------------- | ---------------------------------------------------------------- |
 | `canon tooling list --json`       | Stacks, extends chain, dep and script counts                     |
-| `canon snippets list --json`      | Presets and categories with their slugs                          |
 | `canon standards list --json`     | Standards docs and the paths each governs                        |
 | `canon gov list --json`           | Governance stacks, rule sets, and unreferenced rules             |
 | `canon claude seeds list --json`  | Seed doc sources with content                                    |
@@ -25,8 +24,8 @@ Use these to discover what's available instead of hardcoding names.
 ### Catalog fields
 
 Every catalog serializes through `JSON.stringify`, so a name carrying a quote
-emits valid JSON. `canon tooling list` and `canon snippets list` previously built
-their output with `printf` and no escaping.
+emits valid JSON. `canon tooling list` previously built
+its output with `printf` and no escaping.
 
 `canon standards list` carries `appliesTo` per standard, the paths that standard's
 `## Scope` statement declares. It holds the backticked paths from the first

package/docs/agents/skills-reach.md

@@ -23,7 +23,7 @@ canon claude skills reach ~/repos/my-project
 
 ## The defect it reads for
 
-A plugin skill installs into a project and the toolkit's own tree is not there. A body naming `canon/context/transcripts.md` resolves for a session running in this repository and sends every other reader to nothing, and no stage asked the question until this one. The shape is wider than one folder: a seed naming a standard with no route and a machine-readable field naming a toolkit-only path are the same claim, true here and false in a target.
+A plugin skill installs into a project and the toolkit's own tree is not there. A body naming `canon/context/features/transcripts.md` resolves for a session running in this repository and sends every other reader to nothing, and no stage asked the question until this one. The shape is wider than one folder: a seed naming a standard with no route and a machine-readable field naming a toolkit-only path are the same claim, true here and false in a target.
 
 ## What counts as a citation
 
@@ -39,7 +39,7 @@ A path the toolkit does not hold is dropped rather than reported. The measure as
 
 ## The ownership key
 
-A cited path counts when it sits under an authoring root no install channel delivers. Standards and snippets install nowhere and are read through the plugin corpus, governance rules install under `.claude/rules/`, and the rest is this repository's own source, catalogs, and contract pages.
+A cited path counts when it sits under an authoring root no install channel delivers. Standards install nowhere and are read through the plugin corpus, governance rules install under `.claude/rules/`, and the rest is this repository's own source, catalogs, and contract pages.
 
 `src/`, `scripts/`, and bare `docs/` are deliberately outside the list. A body naming one of those is describing the reader's own tree, so listing them reports a correct citation on every run and buries the finding under the pass.
 
@@ -52,7 +52,7 @@ A path a seed installs is disowned twice, under its own name and under the folde
 A correct citation and a defective one are the same string, and the sentence around it is the difference. A citation counts as decided when its line names the toolkit as the owner, matching the bodies that already spell it that way. The repair for a finding is to say whose copy the path is, never to delete the citation, since the paths name real documents a reader wants.
 
 ```markdown
-Read `canon/context/indexes.md` from the toolkit if context on the system is needed.
+Read `canon/context/context-model/indexes.md` from the toolkit if context on the system is needed.
 ```
 
 A line mentioning the toolkit for an unrelated reason exempts a citation on it. That is the accepted cost of a word over a notation every future body would have to learn.

package/docs/agents/state-scoped-risk.md

@@ -24,7 +24,7 @@ canon secrets scan ../my-app
 
 The corpus is the package's own `files` field rather than a list the check keeps. That field is the single statement of which trees leave this repository, so a second list beside it would answer the same question and drift. It also carries the negations the publish already makes, which is what puts the sandbox tree, the eval tree, and every test file out of scope by the rule that keeps them out of the tarball rather than by an exclusion this check invented.
 
-The plugin reaches a target by a different route, loading live from `claude/` rather than from a tarball. That folder is a `files` entry too, and its `standards` and `snippets` symlinks resolve into trees the field lists in their own right, so both routes land inside the same corpus.
+The plugin reaches a target by a different route, loading live from `claude/` rather than from a tarball. That folder is a `files` entry too, and its `standards` symlink resolves into a tree the field lists in its own right, so both routes land inside the same corpus.
 
 Three root files are read whether or not the field names them, being `package.json`, the readme, and the license, since npm packs those on every publish. A negation still removes one, because a field that excludes a file outranks the default that included it.
 

package/docs/agents/tasks-archive.md

@@ -22,7 +22,7 @@ canon tasks archive --pull-request 673 --json
 | `--json`             | Emit a machine-readable record on stdout                     |
 | `--root <path>`      | Board root, defaulting to the main worktree                  |
 
-Exit codes: `0` archived, `1` refused. Every gate is a refusal rather than a warning, because `.husky/post-merge` calls this with nobody watching. The `reason` field carries which gate fired: `no-board`, `no-match`, `ambiguous`, `no-outcomes`, `open-outcomes`, `earlier-slice`, or `bad-input`. `earlier-slice` fires when `--pull-request` names a number that is not the last on the task's `Pull request:` line, since outcomes are ticked at ship time and only the last slice's merge closes the task.
+Exit codes: `0` archived, `1` refused. Every gate is a refusal rather than a warning, because `.husky/post-merge` calls this with nobody watching. The `reason` field carries which gate fired: `no-board`, `no-match`, `ambiguous`, `no-outcomes`, `open-outcomes`, `earlier-slice`, `pending-branch`, or `bad-input`. `earlier-slice` fires when `--pull-request` names a number that is not the last on the task's `Pull request:` line, since outcomes are ticked at ship time and only the last slice's merge closes the task. `pending-branch` fires when `--pull-request` meets a `Pending branch:` line, since a branch that ticked an outcome before `git-pr` recorded its number means the last number listed is not yet the last slice. The `detail` array names each pending branch. Selecting by stem skips both checks.
 
 An outcome whose body is struck reads as cut rather than open or closed, whatever its checkbox holds: `- ~~<outcome>~~ <why>`. A task carrying only cut outcomes archives, since the gate refuses `no-outcomes` only when both the closed and the cut counts are zero. The success record carries `closed` and `cut` as counts, so a reader tells a shipped task from an abandoned one without opening the file.