@erclx/canon 5.31.0 → 5.33.0

package/docs/workflow/skill-map-on-request.md

@@ -10,33 +10,30 @@ These two groups hold the skills no single moment in a project's life calls for,
 
 ## Generate an artifact on demand
 
-| Skill                     | When to use                                                                                                                                    |
-| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                                               |
-| `canon:create-skill`      | For a new `SKILL.md`                                                                                                                           |
-| `canon:create-standard`   | For a new authoring convention                                                                                                                 |
-| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wireframe surface, wiki reference page, or `README.md`, drafted against the standard for its kind |
-| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                                      |
-| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                                     |
-| `canon:bash-cli-script`   | For a small non-interactive shell wrapper, stopping at 100 lines in favor of TypeScript on Bun                                                 |
-| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                                             |
-| `canon:draft-slides`      | For a deck, drawn as HTML slides in its own folder and rendered to editable PowerPoint                                                         |
-| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                                                  |
-| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                                   |
-| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                                    |
+| Skill                     | When to use                                                                                                                 |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                            |
+| `canon:create-skill`      | For a new `SKILL.md`                                                                                                        |
+| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wiki reference page, or `README.md`, drafted against the standard for its kind |
+| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                   |
+| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                  |
+| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                          |
+| `canon:draft-slides`      | For a deck, drawn as HTML slides in its own folder and rendered to editable PowerPoint                                      |
+| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                               |
+| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                |
+| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                 |
 
 ## Answer a question at any point
 
-| Skill                       | When to use                                                                                                                                                            |
-| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `canon:canon-cli`           | Before running an unfamiliar verb, a sync, or an install, to learn which command to run, which reference doc covers it, or what it overwrites, merges, or leaves alone |
-| `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                                                               |
-| `canon:read-frames`         | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right                                       |
-| `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
-| `canon:markdown-craft`      | Before a substantial markdown edit, for the format and structure rules and the audit that follows                                                                      |
-| `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                                                      |
-| `canon:restate-plainly`     | When an answer or a document has to be read again in plain words                                                                                                       |
+| Skill                       | When to use                                                                                                                      |
+| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `canon:canon-cli`           | To pick the `canon` verb that does a job, or before a sync or migrate, to learn which verbs can lose the project's edits         |
+| `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                         |
+| `canon:read-frames`         | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right |
+| `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                       |
+| `canon:markdown-craft`      | Before a substantial markdown edit, for the format and structure rules and the audit that follows                                |
+| `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                |
 
 Every row answers a question rather than marking a point in a project's life, so filing one under a phase on the [skill map](skill-map.md) would send a reader to the wrong group.
 
-A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:teach-workspace` to promote sorts each durable page by who owns its subject, sending an Anthropic-owned subject to the wiki, an internal one to the matching context entry, and everything else, subject-neutral material included, to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:context-fold` folds in from a branch. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.
+A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:teach-workspace` to promote sorts each durable page by who owns its subject, sending an Anthropic-owned subject to the wiki, an internal one to the matching context entry, and everything else, subject-neutral material included, to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:teach-workspace` folds in from a branch in its fold mode. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.

package/docs/workflow/skill-map.md

@@ -14,14 +14,10 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 
 ## Set up a project
 
-| Skill                  | When to use                                                                                                 |
-| ---------------------- | ----------------------------------------------------------------------------------------------------------- |
-| `canon:target-setup`   | On a fresh scaffold, to detect the stack and run the install chain, or to reach one phase of it alone       |
-| `canon:canon-operator` | On a project that already exists, to read what it carries before an install is picked                       |
-| `canon:sketch-design`  | Before `design-extract`'s greenfield path, to trace a design direction from reference images or URLs        |
-| `canon:design-extract` | Before the first UI feature, to draft `canon/DESIGN.md`                                                     |
-| `canon:deploy-app`     | Once a project is ready to publish, to set up its Cloudflare or Vercel deploy and stop for token and domain |
-| `canon:repo-metadata`  | When the GitHub About text, homepage, or topics may have drifted, to reconcile them against the README      |
+| Skill                | When to use                                                                                                 |
+| -------------------- | ----------------------------------------------------------------------------------------------------------- |
+| `canon:target-setup` | On a fresh scaffold, to detect the stack and run the install chain, or to reach one phase of it alone       |
+| `canon:deploy-app`   | Once a project is ready to publish, to set up its Cloudflare or Vercel deploy and stop for token and domain |
 
 ## Decide what to build
 
@@ -33,8 +29,8 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 | `canon:plan-groundwork`    | When the state is unmeasured and more than one approach is live                   |
 | `canon:decision-escalate`  | When open decisions turn on your preference and want batching into one set        |
 | `canon:draft-and-pick`     | When the call is taste and wants several candidates rendered side by side         |
-| `canon:canvas`             | When a direction should be drawn as frames the operator can see, select, and edit |
-| `canon:task-board`         | When a decided item needs a file on the board, or a shipped one needs archiving   |
+| `canon:canvas-board`       | When a direction should be drawn as frames the operator can see, select, and edit |
+| `canon:task-board`         | When a decided item needs a file on the board, or one is decided against          |
 | `canon:plan-feature`       | When the approach is settled and the next step is a plan                          |
 | `canon:codebase-layout`    | When a plan or change adds a file and you need to decide which folder holds it    |
 
@@ -43,8 +39,7 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 | Skill                         | When to use                                                                                                |
 | ----------------------------- | ---------------------------------------------------------------------------------------------------------- |
 | `canon:session-worktree`      | At the plan-to-execute boundary, to get an isolated tree and branch, or to route a refused main-root write |
-| `canon:auto-ship`             | After plan approval, to chain implement, verify, review, draft PR                                          |
-| `canon:project-commands`      | When the project's own command needs running                                                               |
+| `canon:auto-ship`             | After plan approval, to chain implement, verify, draft PR                                                  |
 | `canon:test-first`            | Before implementing a planned change, to run its test red, green, then refactor                            |
 | `canon:test-craft`            | When writing or changing any test, to pick its layer and filter what it asserts                            |
 | `canon:build-in-slices`       | While building a plan, to commit each tested slice and note out-of-scope defects rather than fix them      |
@@ -60,28 +55,24 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 
 ## Check the work before it leaves the branch
 
-| Skill                    | When to use                                                                             |
-| ------------------------ | --------------------------------------------------------------------------------------- |
-| `canon:review-branch`    | On the local branch diff, before anything is pushed                                     |
-| `canon:document-health`  | When the documents themselves have to answer for length, placement, and staleness       |
-| `canon:markdown-propose` | When a markdown claim needs rewriting and the change should wait for an answer per file |
-| `canon:ux-audit`         | To read UI source for missing states, edge cases, and inconsistencies                   |
-| `canon:ux-measure`       | To start the interface and measure paint, processor, and layout cost                    |
-| `canon:ux-walkthrough`   | To run a multi-finding inspection pass over a running app with the operator             |
+| Skill                   | When to use                                                                       |
+| ----------------------- | --------------------------------------------------------------------------------- |
+| `canon:document-health` | When the documents themselves have to answer for length, placement, and staleness |
+| `canon:ux-audit`        | To read UI source for missing states, edge cases, and inconsistencies             |
+| `canon:ux-measure`      | To start the interface and measure paint, processor, and layout cost              |
 
 ## Ship it
 
-| Skill                  | When to use                                                                           |
-| ---------------------- | ------------------------------------------------------------------------------------- |
-| `canon:git-ship`       | To run the whole post-feature chain from the verify gate through open PR              |
-| `canon:memory-capture` | First skill in that chain, to route what the session learned to the surface owning it |
-| `canon:context-fold`   | When decisions diverged from the plan, or a shipped task needs its outcomes marked    |
-| `canon:docs-sync`      | When a change since main left `README.md` or `docs/` stale                            |
-| `canon:git-stage`      | When the staged set spans several concerns and wants one commit each                  |
-| `canon:git-commit`     | When the staged set is one concern, or was staged hunk by hand                        |
-| `canon:git-branch`     | When a branch name needs generating or renaming to conventional form                  |
-| `canon:git-pr`         | When a pull request needs a title and body written from the diff                      |
-| `canon:memory-review`  | When the pen has grown, to propose where each entry belongs                           |
+| Skill                 | When to use                                                                                     |
+| --------------------- | ----------------------------------------------------------------------------------------------- |
+| `canon:git-ship`      | To run the whole post-feature chain from the verify gate through open PR                        |
+| `canon:context-fold`  | When decisions diverged from the plan, or the diff left a context entry stale                   |
+| `canon:task-complete` | After the fold, to mark the outcomes the diff shipped, or to archive a task the merge hook left |
+| `canon:docs-sync`     | When a change since main left `README.md` or `docs/` stale                                      |
+| `canon:git-stage`     | When the staged set spans several concerns and wants one commit each                            |
+| `canon:git-commit`    | When the staged set is one concern, or was staged hunk by hand                                  |
+| `canon:git-branch`    | When a branch name needs generating or renaming to conventional form                            |
+| `canon:git-pr`        | When a pull request needs a title and body written from the diff                                |
 
 ## After the pull request opens
 
@@ -113,7 +104,5 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 | Skill                         | When to use                                                                            |
 | ----------------------------- | -------------------------------------------------------------------------------------- |
 | `canon:target-check`          | In a target project, to report per domain what it holds against what the toolkit ships |
-| `canon:seed-sync`             | After a toolkit update, to reconcile installed seeds without losing customizations     |
 | `canon:canon-feedback`        | When something in the toolkit is broken, missing, or off, to open an issue on it       |
-| `canon:canon-feedback-triage` | In the toolkit repo, to work through the open feedback issues                          |
-| `canon:canon-rollout`         | In the toolkit repo, to take one change out to every consuming project at once         |
+| `canon:canon-feedback-triage` | In the toolkit repo, to file the open feedback issues into an intake folder            |

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

@@ -1,6 +1,6 @@
 ---
 title: Visual design workflow
-description: Tiered guide for design and wireframe authoring with Claude Code
+description: Tiered guide for design authoring with Claude Code
 category: Workflow
 ---
 
@@ -14,17 +14,17 @@ The tier framework sits alongside [Claude Design](../../wiki/claude/design.md),
 
 ## Tier 0: prose only
 
-The default. `canon/DESIGN.md` holds visual intent as token tables for color, typography, spacing, and borders, with one Personality paragraph and at most three one-line rules a section, motion and iconography included. `.claude/WIREFRAMES.md` holds each surface's regions and states.
+The default. `canon/DESIGN.md` holds visual intent as token tables for color, typography, spacing, and borders, with one Personality paragraph and at most three one-line rules a section, motion and iconography included.
 
-Claude Code reads both and writes the implementation. Works for CLI tools, internal dashboards, admin panels, and backend-focused projects.
+Claude Code reads it and writes the implementation. Works for CLI tools, internal dashboards, admin panels, and backend-focused projects.
 
 ### Seed shape
 
-The toolkit seed in `tooling/claude/seeds/canon/DESIGN.md` ships a token-table template with a starting set of roles, and `standards/design.md` carries the same tables under `## Template` with placeholder rows. The column headers are what the renderer parses, so they stay verbatim in either, while the rows and values are the project's own.
+The toolkit seed in `tooling/claude/seeds/canon/DESIGN.md` ships a token-table template with a starting set of roles, and `claude/skills/canvas-board/references/design.md` carries the same tables under `## Template` with placeholder rows. The column headers are what the renderer parses, so they stay verbatim in either, while the rows and values are the project's own.
 
-The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `canon/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design/index.md`.
+`canon design render` writes an HTML plus CSS preview to `.canon/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design/index.md`.
 
-A project wanting a neutral starting point to override runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying an achromatic token set as custom properties and two components built on them. Greys run from near-black to near-white and the accent is monochrome, so the only palette the project renders is one it writes itself. That file is toolkit-owned and `canon design sync` refreshes it, so a project overrides a value in `.claude/design/project/` instead, which sync never touches. Nothing arrives without that install, and the two channels are independent: a record drafted by the extract skill is the project's own, and the installed stylesheet is the toolkit's.
+A project wanting a neutral starting point to override runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying an achromatic token set as custom properties and two components built on them. Greys run from near-black to near-white and the accent is monochrome, so the only palette the project renders is one it writes itself. That file is toolkit-owned and `canon design sync` refreshes it, so a project overrides a value in `.claude/design/project/` instead, which sync never touches. Nothing arrives without that install, and the two channels are independent: a record the project wrote is its own, and the installed stylesheet is the toolkit's.
 
 A cell no source anchors ends in `? verify`, and the preview shows that marker beside the value rather than folding it in, so a swatch and a font sample stay built from the value alone. A confidence line above the sections names how many cells are anchored against how many are tagged, which is what tells a reader whether they are looking at a record of the code or a proposal about it. It reads the columns a source could anchor and leaves out the row names, so the ratio is not diluted by cells no tag could ever reach. The proposal path tags nearly all of them, so that count reads low on day one by design.
 
@@ -35,14 +35,11 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
 
 ### Skills
 
-- `canon:sketch-design` to trace a design direction from reference images or URLs, before `design-extract`'s greenfield path proposes from a personality paragraph alone
-- `canon:design-extract` to draft `canon/DESIGN.md`, from existing project signals or from requirements alone on day one
 - `canon:ui-checklist` for what a reviewer has to look at after UI changes, and what ships without a test
 - `canon:ux-audit` for UX gap detection on existing surfaces
 - `canon:ux-measure` for what a running surface costs to paint, read against published thresholds
-- `canon:draft-and-pick` for a call settled by looking, drafting several candidates onto one page and taking your pick
-- `canon:canvas` for a direction worked out over several turns, drawn as HTML frames you drag, select, and restyle in the browser while the session reads your changes back. Only the pick moves into `canon/DESIGN.md`, since the canvas folder is gitignored
-- `canon:ux-walkthrough` for a multi-finding inspection pass over a running app with the operator, drafting arms from the app's own markup and recording each pick for a builder
+- `canon:draft-and-pick` for a call settled by looking, drafting several candidates as frames on the canvas and taking your pick
+- `canon:canvas-board` for a direction worked out over several turns, drawn as HTML frames you drag, select, and restyle in the browser while the session reads your changes back. Only the pick moves into `canon/DESIGN.md`, since the canvas folder is gitignored
 - `canon:draft-identity` to draft a project's logo mark and compose it into an icon sequence and a social card, through `draft-and-pick`'s own render-and-pick loop. On an Astro project holding the card route scaffold, the card lands as a route the project keeps and is captured through a running server, so it reads the project's real stylesheet rather than typed copies of every color. Everywhere else it ships as a PNG and the run says so.
 - Anthropic's `frontend-design` plugin optional for light visual steering
 
@@ -55,16 +52,16 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
 
 ## Tier 1: visual companion
 
-ASCII and prose stay as source of truth. Add a visual render as a feedback surface for the agent and for human review.
+Prose stays as source of truth. Add a visual render as a feedback surface for the agent and for human review.
 
-- Excalidraw handles agent-driven wireframes when the round-trip canvas loop matters
+- Excalidraw handles agent-drawn layouts when the round-trip canvas loop matters
 - Claude Design joins only when codebase extraction or the annotated handoff bundle is worth the ceiling cost
 
 Both produce derived artifacts, so human edits are review annotations rather than source changes.
 
 ### Seed shape
 
-Same as tier 0 with one addition. `WIREFRAMES.md` opts into Excalidraw rendering via a top-of-file marker like `<!-- excalidraw: WIREFRAMES.excalidraw -->`. `DESIGN.md` stays human-maintained.
+Same as tier 0. `DESIGN.md` stays human-maintained.
 
 Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in its own format. These are separate files from the toolkit's `canon/DESIGN.md` and are not synced with it. Treat impeccable's pair as its own source of truth for its commands, and the toolkit's `canon/DESIGN.md` as the source other toolkit skills read.
 
@@ -91,7 +88,7 @@ Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in its
 
 The two tools solve non-overlapping halves of the visual companion problem.
 
-Excalidraw gives the agent a canvas it can read back over MCP. Output is agent-facing and persists as a JSON file in the repo. Pick it when Claude Code needs to iterate on wireframes autonomously, not when a human needs polished review artifacts.
+Excalidraw gives the agent a canvas it can read back over MCP. Output is agent-facing and persists as a JSON file in the repo. Pick it when Claude Code needs to iterate on layouts autonomously, not when a human needs polished review artifacts.
 
 Claude Design reads the raw codebase without prose curation and produces a polished handoff bundle with chat history. Weekly quota makes it expensive, so reserve it for the extraction pass or the final handoff moment, not daily iteration.
 
@@ -147,4 +144,4 @@ Resist over-tiering early. Moving up is cheap because tiers stack. Moving down m
 - `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
-- [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw): community MCP server behind the tier 1 wireframe companion
+- [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw): community MCP server behind the tier 1 visual companion

package/governance/renames.toml

@@ -13,53 +13,23 @@
 # resolves A only while both links stay. A key must name no live rule and every
 # chain must end on one, which `src/gov/renames.test.ts` checks against this
 # file.
-#
-# A numbered rule replaced by the rule `canon gov regen` generates from its
-# standard is a rename too: the generated rule keeps every glob and bullet, so
-# the pair is one-to-one identity under the standard's name.
 [renamed]
 "015-output" = "566-output"
 "035-tasks" = "602-tasks"
-"045-memory" = "603-memory"
 "055-scratch" = "604-scratch"
 "085-worktrees" = "605-worktrees"
 "087-git" = "606-git"
 "510-context" = "610-context"
 "511-indexes" = "611-indexes"
-"520-wireframes" = "620-wireframes"
-"530-requirements" = "630-requirements"
-"540-architecture" = "640-architecture"
-"550-design" = "650-design"
 "555-tasks" = "655-tasks"
-"556-groundwork" = "656-groundwork"
-"557-intake" = "657-intake"
 "558-plan" = "658-plan"
-"559-memory" = "659-memory"
-"561-teach" = "661-teach"
-"562-session" = "662-session"
-"563-ready" = "663-ready"
 "501-markdown" = "801-markdown"
-"580-readme" = "880-readme"
-"591-standard-authoring" = "891-standard-authoring"
 "065-spelling" = "765-spelling"
 "075-dependencies" = "775-dependencies"
 "080-config-comments" = "780-config-comments"
 "090-code-comments" = "790-code-comments"
 "658-plan" = "plan"
 "610-context" = "context"
-"620-wireframes" = "wireframes"
-"630-requirements" = "requirements"
-"640-architecture" = "architecture"
-"650-design" = "design"
 "655-tasks" = "tasks"
-"656-groundwork" = "groundwork"
-"657-intake" = "intake"
-"659-memory" = "memory"
-"661-teach" = "teach"
-"662-session" = "session"
-"663-ready" = "ready"
 "570-skill" = "skill"
-"590-rule-authoring" = "rule"
 "801-markdown" = "markdown"
-"880-readme" = "readme"
-"891-standard-authoring" = "standard"

package/governance/rules/canon/605-worktrees.md

@@ -10,5 +10,5 @@ description: Enter a linked worktree for implementation, resolve shared session
 
 ## Shared session scratch
 
-- Shared session scratch (`.canon/plans/`, `.canon/review/`, `.canon/memory/`, `.canon/tasks/`) lives at the main worktree root, not inside a linked worktree. From a linked worktree, resolve these paths against the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. Fall back to `pwd` if not a git repo.
+- Shared session scratch (`.canon/plans/`, `.canon/review/`, `.canon/tasks/`) lives at the main worktree root, not inside a linked worktree. From a linked worktree, resolve these paths against the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. Fall back to `pwd` if not a git repo.
 - From a linked worktree, or from a background session that entered none, `Edit` and `Write` refuse a main-root path and redirect to a worktree copy no later session reads. Never take that redirect. Route the write the way the `session-worktree` skill states, and report it rather than proceeding silently when that skill does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.

package/governance/rules/canon/context.md

@@ -0,0 +1,13 @@
+---
+description: Route edits under canon/context/ to the context-fold skill for the entry shape, and keep each entry conforming to the work in its domain
+paths:
+  - 'canon/context/**'
+---
+
+# Context standards
+
+## Context entries
+
+- Load the `canon:context-fold` skill before a hand edit under `canon/context/`. It carries the entry shape and the content rules for a domain entry. Report it rather than proceeding silently when the skill does not resolve.
+- Before non-trivial work in a domain, read its `canon/context/<domain>/` entry. Use `canon/context/index.md` to find it.
+- Leave the entry conforming when work in its domain changes what it describes.

package/governance/rules/{standards → canon}/plan.md

@@ -1,19 +1,18 @@
 ---
-# Generated by `canon gov regen` from standards/plan.md. Edit that frontmatter, not this file.
-description: Filename and slug, the required sections, and the suggested-and-answer contract for a feature plan
+description: Route edits under .canon/plans/ to the plan-feature skill for the plan's sections, the answer contract, and its lifecycle
 paths:
   - '.canon/plans/**'
 ---
 
 # Plan standards
 
-## Authority
+## Plan files
 
-- Follow the plan standard for filename and slug, the required sections, and the suggested-and-answer contract for a feature plan. It is the single source. Read it with `canon standards plan`.
+- Load the `canon:plan-feature` skill before a hand edit under `.canon/plans/`. It carries the filename and slug, the required sections, and the suggested-and-answer contract for a feature plan. Report it rather than proceeding silently when the skill does not resolve.
 - Never fill an `- Answer:` slot on behalf of the person who owns it. A blank slot accepts the suggestion at execution time.
 - Never ship a question without a `- Suggested:` line. Write `- Suggested: needs your call, <why>` where the answer turns on preference.
 - Rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement when execution deviates from an unanswered question, leaving the slot blank. Put the same deviation in one line under the open task's `## Findings`.
 - Fetch the source a decision rests on and quote the passage under `**Sources:**`, or mark the entry `unverified`. Never cite an outside source from recall.
 - Move a shipped plan to `.canon/plans/archive/`. Never delete one.
 - Amend a plan in place when a decision changes. Do not append a second passage narrating the change.
-- Follow the plan lifecycle standard for when a plan is written, how it is amended, and its move to the archive. Read it with `canon standards plan-lifecycle`.
+- Follow the lifecycle the `canon:plan-feature` skill carries for when a plan is written, how it is amended, and its move to the archive.

package/governance/rules/canon/tasks.md

@@ -0,0 +1,18 @@
+---
+description: Route edits under .canon/tasks/ to the task-board skill for task shape, the board, and a declined task, and keep a session handoff apart from a task
+paths:
+  - '.canon/tasks/**'
+---
+
+# Tasks standards
+
+## Task files
+
+- Load the `canon:task-board` skill before a hand edit under `.canon/tasks/`. It carries the folder layout, filename convention, file format, origin lines, and archiving for a task file. Report it rather than proceeding silently when the skill does not resolve.
+- Follow the board shape the `canon:task-board` skill carries for `priority.md` and `backlog.md`, their readiness groups, and row order.
+- Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter.
+- Follow the decline shape the `canon:task-board` skill carries for a task decided against.
+
+## Session handoffs
+
+- Treat a `.canon/tasks/session-*.md` file as a handoff governed by the `canon:session-map` skill. It is not a task and carries neither `## Outcomes` nor `## Findings`.

package/governance/rules/claude/skill.md

@@ -0,0 +1,17 @@
+---
+description: Route edits to a skill body or its requirement to the create-skill skill for the shape, and hold the creation-time questions and the re-read rule
+paths:
+  - '.claude/skills/**/SKILL.md'
+  - 'claude/skills/**/SKILL.md'
+  - '.claude/skills/**/REQUIREMENT.md'
+  - 'claude/skills/**/REQUIREMENT.md'
+---
+
+# Skill standards
+
+## Skill files
+
+- Load the `canon:create-skill` skill before a hand edit to a `SKILL.md` or a `REQUIREMENT.md`. It carries the skill structure, the requirement shape, and the path rules for a skill body. Report it rather than proceeding silently when the skill does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.
+- Confirm `canon:create-skill`'s two creation-time questions are answered before a new `SKILL.md` lands, whether drafted by hand, by another skill, or by `canon:create-skill` itself. Carry the third question into the sibling `REQUIREMENT.md`'s `Must not` section as a review criterion rather than a gate.
+- Re-read a skill body this session edited before invoking that skill again in the same session.
+- Do not read a resolved file path in a held body as evidence the body is current.

package/governance/stacks/base.toml

@@ -5,7 +5,5 @@ extends = ""
 # session conduct and `.claude/` authoring rules, `tooling` the dev setup and
 # CI workflow rules, and `writing` the prose and document-shape rules. The
 # `code` group is left to the stacks that write code, so a docs or writing
-# project loads no rule it can never apply. `standards` holds one rule per
-# standard routing its paths to it, generated by `canon gov regen` from each
-# standard's frontmatter rather than authored.
-rules = ["canon", "claude", "standards", "tooling", "writing", "120-bash"]
+# project loads no rule it can never apply.
+rules = ["canon", "claude", "tooling", "writing"]

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "5.31.0",
+  "version": "5.33.0",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
   "license": "MIT",
   "bin": {
@@ -26,9 +26,9 @@
   },
   "scripts": {
     "check:spell": "cspell '**' '.*/**' '.*' --no-progress --color --show-context",
-    "format": "prettier --write --log-level warn --ignore-path .gitignore --ignore-path .prettierignore . && shfmt --write --indent 2 scripts/ sandbox/ tooling/ claude/",
-    "check:format": "prettier --check --log-level warn --ignore-path .gitignore --ignore-path .prettierignore . && shfmt --diff --indent 2 scripts/ sandbox/ tooling/ claude/",
-    "check:shell": "find scripts sandbox tooling claude .claude/hooks -name '*.sh' -exec shellcheck --severity=warning {} + && find .husky -maxdepth 1 -type f -exec shellcheck --severity=warning --shell=sh {} +",
+    "format": "prettier --write --log-level warn --ignore-path .gitignore --ignore-path .prettierignore . && shfmt --write --indent 2 scripts/ tooling/ claude/",
+    "check:format": "prettier --check --log-level warn --ignore-path .gitignore --ignore-path .prettierignore . && shfmt --diff --indent 2 scripts/ tooling/ claude/",
+    "check:shell": "find scripts tooling claude .claude/hooks -name '*.sh' -exec shellcheck --severity=warning {} + && find .husky -maxdepth 1 -type f -exec shellcheck --severity=warning --shell=sh {} +",
     "check:types": "tsc --noEmit",
     "check:install": "./scripts/core/install-check.sh",
     "test": "bun --bun vitest run",

package/scripts/core/install-check.sh

@@ -55,10 +55,10 @@ open_timeline "Install verification"
 # nothing, so the excluded tree has to exist here before its absence below can
 # mean the publish left it out.
 log_step "Assert excluded path exists in source"
-if [ ! -f "$PROJECT_ROOT/sandbox/run.sh" ]; then
-  log_error "sandbox/run.sh is missing from the source tree, so the absence check below would pass on nothing"
+if [ ! -f "$PROJECT_ROOT/sandbox/exempt.toml" ]; then
+  log_error "sandbox/exempt.toml is missing from the source tree, so the absence check below would pass on nothing"
 fi
-log_info "Present: sandbox/run.sh"
+log_info "Present: sandbox/exempt.toml"
 
 log_step "Pack"
 TARBALL_PATH="$(cd "$PROJECT_ROOT" && bun pm pack --quiet --ignore-scripts --destination "$PACK_DIR" | tail -n 1)"
@@ -101,7 +101,7 @@ log_step "Assert scaffold"
 # 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" \
+for path in "CLAUDE.md" ".claude/wiki/index.md" ".claude" "canon/context/index.md" \
   ".prettierrc" ".editorconfig" ".lintstagedrc" ".husky/pre-commit" ".github/workflows/verify.yml" "scripts/verify.sh" \
   ".claude/rules/canon/claude/566-output.md" ".claude/rules/canon/canon/604-scratch.md"; do
   if [ ! -e "$TARGET_DIR/$path" ]; then

package/scripts/core/regen-web-previews.ts

@@ -43,7 +43,7 @@ console.log('regen-web-previews: wrote web/public/previews/design-tokens/')
  * chrome over a scratch copy holding this one workspace alone is what keeps
  * the jump menus from naming anything else.
  *
- * `.canon/teach/` is gitignored session scratch, per `standards/teach.md`, so
+ * `.canon/teach/` is gitignored session scratch, per `claude/skills/teach-workspace/references/teach.md`, so
  * it exists on the machine that authored the lesson and nowhere else,
  * including CI. `web/public/previews/teach-workspace/` is therefore the
  * durable copy: committed once the workspace exists, regenerated here as a