@erclx/canon 4.77.0 → 4.79.0

package/claude/skills/memory-capture/SKILL.md

@@ -26,7 +26,7 @@ Read in parallel, skipping any that do not exist:
 - `${CLAUDE_SKILL_DIR}/../../standards/memory.md`: the filename, frontmatter, body shape, and lifecycle every entry follows
 - `CLAUDE.md`: the project's write location and any rule it states over the folder
 - `.canon/memory/index.md`: existing index, to avoid duplicates
-- `.claude/context/index.md`: the domain catalog Step 3 routes against
+- `canon/context/index.md`: the domain catalog Step 3 routes against, read under `.claude/` instead in a project the surface move has not reached
 - `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting applied to memory file bodies
 - The `write-human` skill: voice, rhythm, and sentence construction applied to memory file bodies
 
@@ -40,16 +40,16 @@ Scan the whole session rather than its last exchange. A rule the user stated ear
 
 Only a **project** candidate is routable. Feedback, user, and reference describe how to work or who to ask rather than how a domain behaves, and no context entry owns them.
 
-For each project candidate, match its subject against `.claude/context/index.md`. The test is a named entry, not a judgment about fit: the fact names a surface that already has an entry in the catalog. Route it to that entry.
+For each project candidate, match its subject against `canon/context/index.md`. The test is a named entry, not a judgment about fit: the fact names a surface that already has an entry in the catalog. Route it to that entry.
 
 Fail closed. A project candidate matching no entry stays a memory file, and so does one matching two entries where neither is clearly the owner. The residue is what the folder is for, and a fact filed under the wrong entry is worse than one in memory because a context entry is a surface sessions trust.
 
-Do not edit a context entry here. `docs-fold` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `.claude/context/index.md`, flat or the nested `index.md`, since that heading is what tells `docs-fold`'s routed-facts fold which file to open. An append is a whole-file operation the shell does directly, so send it as a plain single `Bash` command carrying a heredoc:
+Do not edit a context entry here. `docs-fold` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `canon/context/index.md`, flat or the nested `index.md`, since that heading is what tells `docs-fold`'s routed-facts fold which file to open. An append is a whole-file operation the shell does directly, so send it as a plain single `Bash` command carrying a heredoc:
 
 A flat domain takes:
 
 ```markdown
-## .claude/context/<domain>.md
+## canon/context/<domain>.md
 
 <the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
 ```
@@ -57,7 +57,7 @@ A flat domain takes:
 A domain split into a folder takes its own generated index instead:
 
 ```markdown
-## .claude/context/<domain>/index.md
+## canon/context/<domain>/index.md
 
 <the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
 ```
@@ -90,7 +90,7 @@ Run `canon records validate memory` when the writes are done and fix what it nam
 
 Respond with one line per fact routed, written, or updated:
 
-- `➡️ Routed: <fact subject> → .claude/context/<domain>.md` for a flat entry, or `→ .claude/context/<domain>/index.md` for a nested one, matching the heading the routing file carries
+- `➡️ Routed: <fact subject> → canon/context/<domain>.md` for a flat entry, or `→ canon/context/<domain>/index.md` for a nested one, matching the heading the routing file carries
 - `✅ Wrote: .canon/memory/<file> (<type>)`
 - `✏️ Updated: .canon/memory/<file> (<type>)`
 

package/claude/skills/memory-review/SKILL.md

@@ -65,7 +65,7 @@ For each in-scope entry (see Scope), pick one action:
 - **Promote to `CLAUDE.md`**: the rule is cross-domain behavior or a design principle applied across the whole project.
 - **Promote to a skill body**: the rule fires only when editing a specific path-scoped domain. Name the target skill.
 - **Promote to a standards file**: the rule is an authoring reference that belongs in the project's own standards folder as `<domain>.md`.
-- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `.claude/context/index.md`. Append it to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, in the format `memory-capture` writes, and tell the user to run `/docs-fold` from a branch. Do not edit the context entry here.
+- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `canon/context/index.md`. Append it to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, in the format `memory-capture` writes, and tell the user to run `/docs-fold` from a branch. Do not edit the context entry here.
 - **Hand off to governance**: the rule is coding-standards class (typescript, testing, naming, error-handling, performance, logging, concurrency, planning). Do not author the rule file inline. Never edit the synced `.claude/rules/` copies of toolkit rules, because `canon gov sync` overwrites them. Stop at handoff.
   - In the toolkit repo, point the user at `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
   - In a target project, point the user at the `create-rule` skill, which scaffolds a project-local rule under `.claude/rules/`.

package/claude/skills/migration-claude-md/REQUIREMENT.md

@@ -11,7 +11,7 @@ Without this skill, a session asked to slim `CLAUDE.md` deletes sections it judg
 
 Three more failures share a cause. The session has no baseline for what belongs in `CLAUDE.md`, so it reads toolkit-seeded always-load behavior as bloat and proposes moving it, and the next seed sync puts it back. A section carrying a rule and a narrative together gets sorted whole into one bucket, which loses half of it either way. And a target that already exists gets written over, since a proposal blind to the folder cannot tell a create from a collision.
 
-The skill also writes into `.claude/context/`, a folder `migration-context` moves files into. A proposal drafted before those moves land cannot see the entries they create, so a move that should have resolved to an append reads as a create.
+The skill also writes into `canon/context/`, a folder `migration-context` moves files into. A proposal drafted before those moves land cannot see the entries they create, so a move that should have resolved to an append reads as a create.
 
 ## Must
 
@@ -35,6 +35,6 @@ The skill also writes into `.claude/context/`, a folder `migration-context` move
 
 ## Out of scope
 
-- Relocating `docs/` files, which `migration-context` proposes into this same `.claude/context/` folder. Run that skill first when both apply, so Step 3 reads a folder its moves have already populated.
+- Relocating `docs/` files, which `migration-context` proposes into this same `canon/context/` folder. Run that skill first when both apply, so Step 3 reads a folder its moves have already populated.
 - Scaffolding the rule files it proposes, which `create-rule` does with the numbering and frontmatter
-- Regenerating `.claude/context/index.md`, which `canon indexes regen` does once the user has applied the moves
+- Regenerating `canon/context/index.md`, which `canon indexes regen` does once the user has applied the moves

package/claude/skills/migration-claude-md/SKILL.md

@@ -7,7 +7,9 @@ description: Classifies each section of a target project's bloated `CLAUDE.md` i
 
 Rebalance a large `CLAUDE.md` so only always-load behavior stays in it, path-scoped behavior becomes a rule, and domain narrative becomes a context entry. Every move is a proposal the user applies by hand.
 
-Run `migration-context` first when both apply. Its moves populate `.claude/context/`, and Step 3 has to read the folder those moves left so an existing entry resolves to an append rather than blocking the move that should have created it.
+Run `migration-context` first when both apply. Its moves populate `canon/context/`, and Step 3 has to read the folder those moves left so an existing entry resolves to an append rather than blocking the move that should have created it.
+
+A project the surface move has not reached keeps its context folder under `.claude/` rather than `canon/`. Read and propose entries into whichever root already carries the folder, and propose `canon/` only when neither does, since a new `canon/` folder would hide every entry the old one holds.
 
 ## Guards
 
@@ -20,7 +22,7 @@ Run these in parallel from `pwd`:
 
 - Read `CLAUDE.md`
 - `ls .claude/rules/ 2>/dev/null`: existing rule subdirs and numbers for placement
-- `ls .claude/context/ 2>/dev/null`: existing context entries for conflict checks
+- `ls canon/context/ 2>/dev/null`: existing context entries for conflict checks
 - `canon claude seeds list --json 2>/dev/null`: the base seed set. Read the `CLAUDE.md` entry's `content` as the always-load baseline. Skip this input when `canon` is not installed.
 
 ## Step 2: classify each section
@@ -37,7 +39,7 @@ Split `CLAUDE.md` by `##` heading. Score each section against this order:
 For each section proposed for a move:
 
 - Path-scoped: propose `.claude/rules/<subdir>/<n>-<slug>.md` with a `paths:` glob. Pick the subdir and a free number the way `create-rule` does. If `.claude/rules/<subdir>/` already holds a rule on the topic, mark as "conflict" and skip.
-- Domain narrative: propose `.claude/context/<domain>.md`. If the entry already exists, flat or as a same-named `.claude/context/<domain>/` folder, propose appending to the file that owns it rather than creating a duplicate flat entry beside a domain already split.
+- Domain narrative: propose `canon/context/<domain>.md`. If the entry already exists, flat or as a same-named `canon/context/<domain>/` folder, propose appending to the file that owns it rather than creating a duplicate flat entry beside a domain already split.
 
 ## Step 4: output
 
@@ -54,8 +56,8 @@ Print one grouped proposal block. Omit empty groups.
 
 ## Extract to a context entry
 
-- `## <heading>` → `.claude/context/<domain>.md` (<reason>)
-- `## <heading>` → `.claude/context/<domain>/<sub-area>.md`, appending to the domain's existing sibling file (<reason>)
+- `## <heading>` → `canon/context/<domain>.md` (<reason>)
+- `## <heading>` → `canon/context/<domain>/<sub-area>.md`, appending to the domain's existing sibling file (<reason>)
 
 ## Needs manual split
 

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

@@ -11,7 +11,7 @@ Without this skill, a session judges a `docs/` file agent-facing, moves it, and
 
 Three more failures share a cause. The skill reads a folder two other surfaces also write, and a proposal blind to them destroys work.
 
-A seed-derived `development.md` moved out of `docs/` comes back on the next seed sync. A move onto an existing `.claude/context/` filename overwrites the entry sitting there. A proposal drafted while `migration-claude-md` is proposing entries into the same folder cannot see those targets, and running the two in the wrong order turns a legitimate move into a skipped conflict.
+A seed-derived `development.md` moved out of `docs/` comes back on the next seed sync. A move onto an existing `canon/context/` filename overwrites the entry sitting there. A proposal drafted while `migration-claude-md` is proposing entries into the same folder cannot see those targets, and running the two in the wrong order turns a legitimate move into a skipped conflict.
 
 ## Must
 
@@ -32,5 +32,5 @@ A seed-derived `development.md` moved out of `docs/` comes back on the next seed
 
 ## Out of scope
 
-- Classifying `CLAUDE.md` sections, which `migration-claude-md` proposes into this same `.claude/context/` folder. Run this skill first when both apply, so that skill's append-or-create check reads a folder the moves have already populated.
-- Regenerating `.claude/context/index.md`, which `canon indexes regen` does once the user has applied the moves
+- Classifying `CLAUDE.md` sections, which `migration-claude-md` proposes into this same `canon/context/` folder. Run this skill first when both apply, so that skill's append-or-create check reads a folder the moves have already populated.
+- Regenerating `canon/context/index.md`, which `canon indexes regen` does once the user has applied the moves

package/claude/skills/migration-context/SKILL.md

@@ -1,11 +1,13 @@
 ---
 name: migration-context
-description: Classifies markdown files in a target project's `docs/` folder and proposes `git mv` commands to relocate agent-flavored content to `.claude/context/`. Use when asked to "migrate docs to context", "move docs to context", "split docs", or to align an existing project with the three-tier context model. Do NOT auto-execute moves or rewrite inbound links. Proposal only.
+description: Classifies markdown files in a target project's `docs/` folder and proposes `git mv` commands to relocate agent-flavored content to `canon/context/`. Use when asked to "migrate docs to context", "move docs to context", "split docs", or to align an existing project with the three-tier context model. Do NOT auto-execute moves or rewrite inbound links. Proposal only.
 ---
 
 # Claude context migrate
 
-Run this skill before `migration-claude-md` when both apply. That skill proposes entries into the same `.claude/context/` folder, and an entry landing there first makes the corresponding move here read as a conflict and get skipped, which loses the richer `docs/` file.
+Run this skill before `migration-claude-md` when both apply. That skill proposes entries into the same `canon/context/` folder, and an entry landing there first makes the corresponding move here read as a conflict and get skipped, which loses the richer `docs/` file.
+
+A project the surface move has not reached keeps its context folder under `.claude/` rather than `canon/`. Read and propose moves into whichever root already carries the folder, and propose `canon/` only when neither does, since a new `canon/` folder would hide every entry the old one holds.
 
 ## Guards
 
@@ -19,7 +21,7 @@ Run these in parallel from `pwd`:
 
 - `ls docs/*.md 2>/dev/null`: list flat markdown files
 - `ls docs/*/ 2>/dev/null`: detect subfolders for the manual-review note
-- `ls .claude/context/ 2>/dev/null`: detect already-migrated content for conflict checks
+- `ls canon/context/ 2>/dev/null`: detect already-migrated content for conflict checks
 - `canon claude seeds list --json 2>/dev/null`: get the canonical seed list to identify seed-derived files
 
 Read each discovered `docs/*.md` file in parallel.
@@ -44,7 +46,7 @@ For each file, score against this rule order:
 
 For every file proposed for a move:
 
-- If `.claude/context/<filename>` already exists, or a same-named folder exists at `.claude/context/` with `<filename>`'s `.md` extension dropped, mark as "conflict" and skip the move. A folder of the same name is still a collision, since the domain already lives there split into siblings.
+- If `canon/context/<filename>` already exists, or a same-named folder exists at `canon/context/` with `<filename>`'s `.md` extension dropped, mark as "conflict" and skip the move. A folder of the same name is still a collision, since the domain already lives there split into siblings.
 - Run `git grep -n "docs/<filename>"` (or grep equivalent) to list inbound references in `CLAUDE.md`, `README.md`, and other markdown. Report each as a TODO line. Do not rewrite.
 
 ## Step 4: output
@@ -52,9 +54,9 @@ For every file proposed for a move:
 Print one grouped proposal block. Omit empty groups.
 
 ```markdown
-## Move to .claude/context/
+## Move to canon/context/
 
-- docs/<file>.md → .claude/context/<file>.md (<one-line reason>)
+- docs/<file>.md → canon/context/<file>.md (<one-line reason>)
 
 ## Keep in docs/
 
@@ -70,7 +72,7 @@ Print one grouped proposal block. Omit empty groups.
 
 ## Conflicts
 
-- docs/<file>.md → .claude/context/<file>.md already exists. Skipping.
+- docs/<file>.md → canon/context/<file>.md already exists. Skipping.
 
 ## Subfolders (manual review)
 
@@ -78,7 +80,7 @@ Print one grouped proposal block. Omit empty groups.
 
 ## Suggested git mv commands
 
-git mv docs/<file>.md .claude/context/<file>.md
+git mv docs/<file>.md canon/context/<file>.md
 
 ## Inbound links to fix after moves
 
@@ -87,7 +89,7 @@ git mv docs/<file>.md .claude/context/<file>.md
 
 ## Reminder
 
-Run canon indexes regen to update .claude/context/index.md.
+Run canon indexes regen to update canon/context/index.md.
 ```
 
 If every file classified as "Keep in docs/", output: `✅ All docs/ content is human-facing. No moves proposed.`

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

@@ -16,14 +16,14 @@ description: Plans a feature by reading the project's Claude setup and scanning
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
-- `.claude/REQUIREMENTS.md`: feature scope and non-goals
-- `.claude/ARCHITECTURE.md`: decisions already made
+- `canon/REQUIREMENTS.md`: feature scope and non-goals
+- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: current scope and status, then any task file the feature relates to
 
 Also read these when the feature touches code or UI. Skip them for prose, docs, catalog, or config-only changes:
 
-- `.claude/DESIGN.md`: tokens, typography, spacing, and component rules
-- `.claude/wireframes/index.md` + the surface files relevant to the feature: intended UI layout and behavior. Read `index.md` first, then follow only the links the feature actually touches, each a flat `.claude/wireframes/<surface>.md` or a grouped surface's own `.claude/wireframes/<surface>/index.md` and the siblings it lists. Do not read the whole folder speculatively.
+- `canon/DESIGN.md`: tokens, typography, spacing, and component rules
+- `canon/wireframes/index.md` + the surface files relevant to the feature: intended UI layout and behavior. Read `index.md` first, then follow only the links the feature actually touches, each a flat `canon/wireframes/<surface>.md` or a grouped surface's own `canon/wireframes/<surface>/index.md` and the siblings it lists. Do not read the whole folder speculatively.
 
 When the plan adds or revises a surface, the wireframe file follows `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md`.
 

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

@@ -60,8 +60,8 @@ Detect the mode from the folder. Do not ask which one to run.
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
-- `.claude/REQUIREMENTS.md`: scope and non-goals
-- `.claude/ARCHITECTURE.md`: decisions already made
+- `canon/REQUIREMENTS.md`: scope and non-goals
+- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: what is already tracked, and what a prior track concluded. Open a task file only when its entry looks related.
 
 Then read only what a live question needs. Do not read entire directories speculatively. Where a folder carries an `index.md`, read it first and load only the files it points at.

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

@@ -49,8 +49,8 @@ With no match, derive a kebab-case slug named for the subject rather than the ac
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
-- `.claude/REQUIREMENTS.md`: scope and non-goals
-- `.claude/ARCHITECTURE.md`: decisions already made
+- `canon/REQUIREMENTS.md`: scope and non-goals
+- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: what is already tracked. Open a task file whose entry looks related to an item.
 
 Then read only what a live item needs. Do not read entire directories speculatively. Where a folder carries an `index.md`, read it first and load only the files it points at.

package/claude/skills/project-commands/SKILL.md

@@ -11,7 +11,7 @@ The value is the stop. A launch that continues into log inspection, browser chec
 
 ## Guards
 
-- Resolve the entry before anything else. Take the flat `development.md` under `.claude/context/` when it exists, and `.claude/context/development/overview.md` when the domain outgrew one file and split into a folder, which is where the `## Scripts` table lands in a split. Test both paths, then read one. If neither resolves, stop with the line below and let the user decide.
+- Resolve the entry before anything else. Take the flat `development.md` under `canon/context/` when it exists, and `canon/context/development/overview.md` when the domain outgrew one file and split into a folder, which is where the `## Scripts` table lands in a split. Test both paths, then read one. If neither resolves, stop with the line below and let the user decide.
 - If the entry documents no command matching the request, stop and list what it does document. Do not infer a command from a filename or a framework.
 - If the resolved command has an effect that outlives the process and stopping it does not undo, print it for the user to run and stop. Deploying, publishing, releasing, migrating, and resetting are the common shapes, and the test is the effect rather than the name. A script called `infra:apply` or `promote` qualifies.
 
@@ -20,7 +20,7 @@ Do not read another file to reconstruct an entry that did not resolve, because a
 The stop names the flat path in both cases, since a project carrying neither has no entry to point at and the flat one is where a project without a split keeps it:
 
 ```plaintext
-❌ No .claude/context/development.md. This project has no documented dev loop.
+❌ No canon/context/development.md. This project has no documented dev loop.
 ```
 
 ## Step 1: read the entry

package/claude/skills/review-branch/SKILL.md

@@ -28,8 +28,8 @@ The base equalling HEAD is a usable baseline rather than the second case it used
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: project type, conventions, and commands
-- `.claude/REQUIREMENTS.md`: feature scope and non-goals
-- `.claude/ARCHITECTURE.md`: technical design decisions
+- `canon/REQUIREMENTS.md`: feature scope and non-goals
+- `canon/ARCHITECTURE.md`: technical design decisions
 
 Coding standards from `.claude/rules/` are auto-loaded by Claude Code. Always-on rules apply every session. Path-scoped rules apply to files matching their `paths:` glob.
 
@@ -68,7 +68,7 @@ Review the full diff and changed file contents for:
 5. Violations of rules from `.claude/rules/` that apply to the changed files
 6. When the diff touches a file this project ships to a target holding none of its own history: a repository-relative path, a phase label naming a gitignored board, a same-repository pull request or commit reference, or a layout, stack, or config-path claim true of this checkout but stated as if it were general
 
-Use `CLAUDE.md`, `.claude/REQUIREMENTS.md`, `.claude/ARCHITECTURE.md`, and the auto-loaded `.claude/rules/` as project context to inform what is intentional vs problematic. Do not fix, rewrite, or suggest refactors outside the scope of a finding.
+Use `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`, and the auto-loaded `.claude/rules/` as project context to inform what is intentional vs problematic. Do not fix, rewrite, or suggest refactors outside the scope of a finding.
 
 ### High-signal filter
 

package/claude/skills/review-pr/SKILL.md

@@ -44,8 +44,8 @@ Then resolve the PR: `gh pr view --json number,headRefName,headRefOid,title,body
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: project type, conventions, and commands
-- `.claude/REQUIREMENTS.md`: feature scope and non-goals
-- `.claude/ARCHITECTURE.md`: technical design decisions
+- `canon/REQUIREMENTS.md`: feature scope and non-goals
+- `canon/ARCHITECTURE.md`: technical design decisions
 - `.canon/tasks/priority.md`: where this feature sits on the board and what each neighboring row waits on. Resolve this one at the main worktree root the way `session-worktree` does, since the board is gitignored and a linked worktree holds no copy of it
 - `.canon/plans/feature-<slug>.md` for the branch, when present: the intent the PR should satisfy
 

package/claude/skills/role-orchestrator/SKILL.md

@@ -194,7 +194,7 @@ The capture row states a standing debt rather than a per-run result. Running cap
 
 That block is the detail. Lead the reply with the three slots under Every later turn above, so the human reads what they own before the evidence for it.
 
-Treat a task that edits `.claude/context/` entries wholesale as conflicting with every other task, because the root instruction file requires each task to update its own domain entry as it lands.
+Treat a task that edits `canon/context/` entries wholesale as conflicting with every other task, because the root instruction file requires each task to update its own domain entry as it lands.
 
 Do not promote a task to fill the queue when nothing qualifies. A thin queue is a real answer and it beats a plan nobody needed.
 

package/claude/skills/role-planner/SKILL.md

@@ -32,7 +32,7 @@ Each item below is something a plan needed and a launch string did not carry.
 
 - The task file, and its `## Findings` before deciding anything. A row can carry its own disproof under a title that still states the original claim, which is how one trial nearly planned against a premise the file had already recorded as dead.
 - The source files themselves, opened rather than summarized. Never a count quoted from the task file, which was wrong or stale in ten places across four plans.
-- `CLAUDE.md` and `.claude/ARCHITECTURE.md`, for the decision and the alternative it was taken against rather than for the decision alone.
+- `CLAUDE.md` and `canon/ARCHITECTURE.md`, for the decision and the alternative it was taken against rather than for the decision alone.
 - The plan of any row this one is sequenced behind, including one already moved to `.canon/plans/archive/`. Reading a shipped plan produced the strongest constraint in the first trial and no brief asked for it.
 - `.canon/tasks/priority.md` for the row's Touches column and its stated blocker. That column is the file set the dispatch disjointness gate already reads.
 - `${CLAUDE_SKILL_DIR}/../../standards/plan.md` for the shape, then `canon records validate plans` and `canon markdown audit <the plan file>` on the file once it is written. Nothing else opens a plan, since `.canon/plans/` is gitignored and the audit's default path set is what git lists.

package/claude/skills/session-relay/REQUIREMENT.md

@@ -11,7 +11,7 @@ Without this skill, `role-worker` and `role-planner` state three and two message
 
 A standalone skill was proposed for the gap and declined the same day. It fired on no condition of its own, since nothing routes a session to a skill matching no request and reaching for no artifact, so a skill built to close the gap never closed it.
 
-The first draft of this plan closed the gap with a paragraph drafted inline, once inside `role-worker` and once inside `role-planner`. The operator overrode that call: two bodies carrying identical protocol text is the shared-surface case `.claude/ARCHITECTURE.md` already decided against duplicating, since a later fix reaching one copy and not the other diverges silently.
+The first draft of this plan closed the gap with a paragraph drafted inline, once inside `role-worker` and once inside `role-planner`. The operator overrode that call: two bodies carrying identical protocol text is the shared-surface case `canon/ARCHITECTURE.md` already decided against duplicating, since a later fix reaching one copy and not the other diverges silently.
 
 Neither attempt named who the relay is from. A message an operator relays by hand needs a sender as much as an addressee, and the standalone draft and the inline draft both composed a body and an addressee with no line stating whose turn produced it.
 

package/claude/skills/session-resume/SKILL.md

@@ -42,7 +42,7 @@ When the board is empty and a handoff was found, name what the handoff leaves op
 
 Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../../standards/plan.md`.
 
-Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `.claude/context/`, which `memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
+Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `canon/context/`, which `memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
 
 ## Writing the next one
 

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

@@ -26,7 +26,7 @@ Read these from the project root in parallel:
 
 - `package.json`: dependencies and devDependencies
 - Root config files: `astro.config.*`, `next.config.*`, `vite.config.*`, `tailwind.config.*`, `tsconfig.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
-- `.claude/REQUIREMENTS.md` and `.claude/ARCHITECTURE.md` if present
+- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
 - Directory structure via `ls -1` of the project root and `src/` if present
 
 ## Match

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

@@ -39,7 +39,7 @@ Read these from the project root in parallel, skipping any that do not exist:
 
 - `package.json`: `dependencies` and `devDependencies`
 - Root configs: `astro.config.*`, `next.config.*`, `vite.config.*`, `tailwind.config.*`, `tsconfig.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
-- `.claude/REQUIREMENTS.md` and `.claude/ARCHITECTURE.md` if present
+- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
 - Directory structure via `ls -1` of the project root and `src/` if present
 
 ## Resolve arguments

package/claude/skills/teach-workspace/references/promotion.md

@@ -14,16 +14,14 @@ A reference page that reads like a lesson is a lesson wearing the wrong extensio
 
 Sort by who owns the subject, which is the test the wiki already runs. The reader's activity decided the workspace and decides nothing here.
 
-| The page's subject                                             | Destination                                                                                                 |
-| -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| Owned by someone outside the project, such as a tool or vendor | the project's wiki                                                                                          |
-| How this project itself works, for the people who build it     | `.claude/context/<domain>.md`, or the domain's own nested `index.md` when it is already split into a folder |
-| Written for someone consuming what this project ships          | the project's public docs                                                                                   |
+| The page's subject                                                                                                   | Destination                                                                                               |
+| -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| Owned by Anthropic                                                                                                   | the project's wiki                                                                                        |
+| Owned by another tool or vendor, owned by no single vendor, or written for someone consuming what this project ships | the project's public docs                                                                                 |
+| How this project itself works, for the people who build it                                                           | `canon/context/<domain>.md`, or the domain's own nested `index.md` when it is already split into a folder |
 
 A page a reader cannot sort by that question is a page whose subject has not been settled. Say which two destinations it sits between and let the operator choose, rather than picking the nearer one.
 
-Within the wiki, place the page by the same owner test that decides the folder: a vendor's own subject, another tool's subject, and a subject no single vendor owns each take the folder the project's wiki index names for them.
-
 ## Where the wiki sits
 
 The folder has two spellings and a project carries whichever its scaffold wrote:

package/claude/skills/ux-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ux-audit
-description: Audits the current UI for incomplete, inconsistent, or confusing patterns. Reads DESIGN.md and .claude/wireframes/ for intent, scans UI files, and outputs observations grouped by surface. Use when asked "audit the UX", "audit the UI", "UX audit", or "find UI roughness". Do NOT use for new feature planning or code changes, and do NOT use to measure what a running interface costs to paint, which is `ux-measure`.
+description: Audits the current UI for incomplete, inconsistent, or confusing patterns. Reads DESIGN.md and canon/wireframes/ for intent, scans UI files, and outputs observations grouped by surface. Use when asked "audit the UX", "audit the UI", "UX audit", or "find UI roughness". Do NOT use for new feature planning or code changes, and do NOT use to measure what a running interface costs to paint, which is `ux-measure`.
 ---
 
 # UX audit
@@ -15,9 +15,9 @@ description: Audits the current UI for incomplete, inconsistent, or confusing pa
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: project type and conventions
-- `.claude/DESIGN.md`: visual intent, tokens, typography, spacing rules
-- `.claude/wireframes/index.md` + every `.claude/wireframes/<surface>.md`, each a flat file or a grouped surface's own `.claude/wireframes/<surface>/index.md` and the siblings it lists: intended UI layout, UI copy, interaction rules. Surfaces are loaded one file at a time during Step 3. Per `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md`, these carry layout and intent, not implementation detail.
-- `.claude/REQUIREMENTS.md`: feature scope and non-goals
+- `canon/DESIGN.md`: visual intent, tokens, typography, spacing rules
+- `canon/wireframes/index.md` + every `canon/wireframes/<surface>.md`, each a flat file or a grouped surface's own `canon/wireframes/<surface>/index.md` and the siblings it lists: intended UI layout, UI copy, interaction rules. Surfaces are loaded one file at a time during Step 3. Per `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md`, these carry layout and intent, not implementation detail.
+- `canon/REQUIREMENTS.md`: feature scope and non-goals
 - A committed capture beside the surface's own source, when the project has one. A rendered surface reads differently composed than it reads written, and a capture is the only artifact here that shows the composed result rather than the markup. Absent one, note that this audit reads source only, and keep going. This is a stated fallback, not a stop: a project with no capture yet, or a capture mid-rebuild, still gets a source-only audit rather than losing the skill entirely.
 
 ## Step 2: identify surfaces
@@ -33,7 +33,7 @@ For each surface, look for:
 3. **Inconsistencies**: spacing, tone of voice, interaction patterns, icon use, keyboard affordances
 4. **Roughness in daily use**: friction, redundant steps, unclear affordances, ambiguous labels
 
-Use `.claude/DESIGN.md` and the per-surface `.claude/wireframes/<surface>.md` files, each a flat file or a grouped surface's own `.claude/wireframes/<surface>/index.md` and the siblings it lists, as ground truth for intent. For each implementation surface, read the matching wireframe file before flagging drift. Observations only, no implementation suggestions or fixes.
+Use `canon/DESIGN.md` and the per-surface `canon/wireframes/<surface>.md` files, each a flat file or a grouped surface's own `canon/wireframes/<surface>/index.md` and the siblings it lists, as ground truth for intent. For each implementation surface, read the matching wireframe file before flagging drift. Observations only, no implementation suggestions or fixes.
 
 Where Step 1 found a committed capture for this surface, judge composed output (spacing, overlap, contrast, wrapping) against it rather than inferring layout from markup alone, which reports what the surface renders rather than what its source implies. Where none exists, judge from source alone and say so in that surface's findings, since a source-only read cannot see what only a render would show.
 

package/claude/skills/ux-measure/SKILL.md

@@ -17,7 +17,7 @@ Report numbers. A sentence about what the source looks like is what this exists
 Read these in parallel from the project root, skipping any that do not exist:
 
 - `package.json`: the `scripts` block naming a dev, preview, or start command
-- `.claude/context/development/`: the documented run commands and the port each serves
+- `canon/context/development/`: the documented run commands and the port each serves
 - `CLAUDE.md`: project type and conventions
 
 Prefer a production-shaped build (`preview`, `start`) over the dev server. A dev server ships unminified modules and reports a cost no user pays.

package/docs/agents/capture.md

@@ -11,6 +11,7 @@ description: Rendering HTML sources to PNG, what the command asserts about fonts
 canon capture --selector .window
 canon capture assets/captures/install.html --selector .window --out assets
 canon capture assets/captures --selector .window --out .canon/review/captures
+canon capture https://example.com --selector .window --out preview.png
 ```
 
 `--selector` is required and every example above passes it. The element a capture crops to belongs to the page, not to the command, so there is no value that could be right for an arbitrary project's markup. `.window` is what this repository's own five sources declare, and a project renders its own pages by naming whatever theirs declare.
@@ -29,10 +30,10 @@ Every render writes a stamp beside its PNG, `hero.png` next to `hero.stamp`, hol
 
 Neither digest is ever written by hand. A digest is what the gate compares, so a hand-set one asserts agreement the tool never checked, and the way to move it is a capture. The `source:` line above them is the one field a rename may correct in place, since nothing reads it and the alternative is a stamp naming a file that no longer exists. Renaming a frame is the case that comes up, and the correction is the same basename the next capture would have written anyway.
 
-| Option             | Behavior                                          |
-| ------------------ | ------------------------------------------------- |
-| `--out <dir>`      | Write every PNG here instead of beside its source |
-| `--selector <sel>` | Element to capture, required and never defaulted  |
+| Option             | Behavior                                                                                               |
+| ------------------ | ------------------------------------------------------------------------------------------------------ |
+| `--out <dir>`      | Write every PNG here instead of beside its source. For a URL source, names the destination PNG itself. |
+| `--selector <sel>` | Element to capture, required and never defaulted                                                       |
 
 ## What the command asserts
 
@@ -48,4 +49,4 @@ The command ships to targets, alongside `demo`, `inventory`, and `drive`. It was
 
 Shipping it also fixed what the exclusion was hiding. The render module imported the `@playwright/test` development dependency, which no published tarball carries. Every browser reference still sits behind a dynamic import, so a browser loads for this command rather than in front of every other one.
 
-`demo.md` and `driver.md` cover two of the other three browser commands. What separates this one is that a capture renders a single state from a file on disk, where the rest drive a running application.
+`demo.md` and `driver.md` cover two of the other three browser commands. What separates this one is that a capture renders a single state, from a file on disk or a named `http(s)://` URL, where the rest drive a running application.

package/docs/agents/commands.md

@@ -22,8 +22,8 @@ Full help: `canon <command> --help`. Behavior notes for the install and sync ver
 | `canon indexes regen`            | Regenerate `index.md` files from sibling frontmatter                                                                                                                                                                                                                                                                   |
 | `canon indexes list [path]`      | Flatten every folder index under a path into one `{path, title, description}` catalog (`--json`)                                                                                                                                                                                                                       |
 | `canon docs [topic]`             | Emit toolkit reference docs (`list`, or a topic by name)                                                                                                                                                                                                                                                               |
-| `canon design render`            | Render `.claude/DESIGN.md` tokens to HTML and CSS                                                                                                                                                                                                                                                                      |
-| `canon design regen`             | Rewrite this repository's `.claude/DESIGN.md` and `src/design/base.css` from `src/design/tokens.ts`                                                                                                                                                                                                                    |
+| `canon design render`            | Render `canon/DESIGN.md` tokens to HTML and CSS                                                                                                                                                                                                                                                                        |
+| `canon design regen`             | Rewrite this repository's `canon/DESIGN.md` and `src/design/base.css` from `src/design/tokens.ts`                                                                                                                                                                                                                      |
 | `canon design board`             | Generate a static page set indexing tokens, surfaces, wireframes, past candidates, and components, against the toolkit checkout like `regen` (`--out`)                                                                                                                                                                 |
 | `canon design css`               | Emit the design tokens and components as CSS on stdout (`--no-components` for properties alone)                                                                                                                                                                                                                        |
 | `canon design install`           | Install the base stylesheet into a project at `.claude/design/base.css`                                                                                                                                                                                                                                                |
@@ -56,6 +56,7 @@ Full help: `canon <command> --help`. Behavior notes for the install and sync ver
 | `canon migrate rename`           | Rewrite every unprotected `aitk` token to `canon` and move the paths that carry the name, reporting the plan without `--write` (`--scope`, `--json`)                                                                                                                                                                   |
 | `canon migrate skill-names`      | Move the prefixed skill folders onto their two-word names and rewrite every citation, reporting the plan without `--write` (`--root`, `--json`)                                                                                                                                                                        |
 | `canon migrate records`          | Move the gitignored session records to `.canon/` and repoint every tracked citation, reporting the plan without `--write` (`--root`, `--json`)                                                                                                                                                                         |
+| `canon migrate surface-roots`    | Move the tracked surfaces (`context/`, `wireframes/`, and the three loose documents) from `.claude/` to `canon/` with `git mv` and repoint every tracked citation, reporting the plan without `--write` (`--root`, `--json`)                                                                                           |
 | `canon migrate record-tree`      | Repoint the old-root citations inside the records themselves, scoped to the live folders and reporting every line without `--write` (`--root`, `--json`)                                                                                                                                                               |
 | `canon migrate rule-layout`      | Move a target's installed rules from the flat `.claude/rules/<subdir>/` layout to `.claude/rules/canon/<subdir>/`, reporting the plan without `--write` (`--root`, `--json`)                                                                                                                                           |
 | `canon migrate scratch-evidence` | Move a folder under `.tmp/` that a durable record cites as evidence to `.canon/review/evidence/`, repointing every citation live or archived, reporting the plan without `--write` (`--root`, `--json`)                                                                                                                |
@@ -94,7 +95,7 @@ Full help: `canon <command> --help`. Behavior notes for the install and sync ver
 | `canon gate run`                 | Run every stage that guards a branch here, scoping shell, types, and tests to the changed set (`--all`, `--no-write`, `--nested`, `--json`)                                                                                                                                                                            |
 | `canon inventory [subject]`      | Walk every route a project declares and group its elements by the property each computes, as a listing rather than a gate (`--json`)                                                                                                                                                                                   |
 | `canon drive <url> <run>`        | Walk a page through named interactions and measure each state it reaches, reporting findings rather than gating (`--json`)                                                                                                                                                                                             |
-| `canon capture [source]`         | Render HTML sources to PNG and prove the font each one declares resolved (`--selector` required, `--out`)                                                                                                                                                                                                              |
+| `canon capture [source]`         | Render an HTML source or an `http(s)://` URL to PNG and prove the font each one declares resolved (`--selector` required, `--out`)                                                                                                                                                                                     |
 | `canon serve [dir]`              | Serve a directory on the loopback interface and print the link that opens it, running until interrupted (`--port`, `--entry`, `--json`)                                                                                                                                                                                |
 | `canon upgrade`                  | Reinstall the CLI globally with the package manager the install path names (`--json`)                                                                                                                                                                                                                                  |
 
@@ -166,6 +167,10 @@ Common patterns:
 
 A record folder already present at the destination is a refusal rather than a merge, and a line carrying `canon-keep-record-root`, or the nearest non-blank line below it, keeps the old spelling for prose that dates a decision. The records themselves are never swept: everything under `.canon/` and every `.claude/` record folder is passed over and reported as a count on its own line, which is what keeps the run that follows the ignore collapse touching the same files as one before it. Running it twice rewrites nothing, which is the check that the exclusions, the markers, and that skip all fired.
 
+`migrate surface-roots` moves the tracked surfaces from `.claude/` to `canon/`: `context/`, `wireframes/`, `ARCHITECTURE.md`, `REQUIREMENTS.md`, and `DESIGN.md`. Every path is tracked, so each file moves with `git mv` and its history follows it, and every tracked citation of one is rewritten in the same run. `.claude/canon/`, `rules/`, `skills/`, `hooks/`, and `settings.json` stay where Claude Code reads them. It reports until `--write` is passed, and a destination already present under `canon/` refuses the whole plan rather than splitting a surface across both roots.
+
+A line carrying `canon-keep-surface-root`, or the nearest non-blank line above it, keeps the old spelling. A rule's frontmatter `paths:` glob, a citation shaped like a path into another repository, and one inside a dated paragraph are reported by file and line and left alone. Running it twice rewrites nothing, which is the idempotence check. A project that never runs it keeps resolving each surface under `.claude/`, since every reader takes whichever root holds the entry.
+
 `migrate record-tree` is what reaches the records the sweep above passes over, and the two share no scope. That one enumerates through git, so it sees every tracked file and none of the records, which are gitignored by construction. This one walks `.canon/` itself and is scoped to the folders a session still follows a path into: `diagrams`, `memory`, `plans`, `proposals`, `review`, `tasks`, and `teach`, each minus its own `archive/` subtree. A closed groundwork or intake trail, the scratch folder, and the backup history are reported as counts and never rewritten, because a path inside a closed trail sits in a sentence about work that already ended. Run it after the move, since there is no new root to walk before one.
 
 Every citation in scope is reported with its file, its line number, and the line text. The record tree is untracked, so a wrong rewrite has no git undo, and that report is what a reader judges before passing `--write`. Marking a line that has to keep the old spelling uses the same `canon-keep-record-root` comment, and a second run rewriting nothing is the idempotence check.

package/docs/agents/context-audit-checks.md

@@ -33,7 +33,7 @@ It reports and never gates, which is the split the citation check already draws.
 
 ## Length
 
-Length quotes its checkpoint from `standards/context.md`: roughly 150 rendered lines for an entry, applied to each of the 60 entries the audit measures, 51 of them under `.claude/context/` and 9 diagram files beside them. It counts rendered lines rather than source lines, wrapping each line at 80 columns and summing the heights.
+Length quotes its checkpoint from `standards/context.md`: roughly 150 rendered lines for an entry, applied to each of the 60 entries the audit measures, 51 of them under `canon/context/` and 9 diagram files beside them. It counts rendered lines rather than source lines, wrapping each line at 80 columns and summing the heights.
 
 A line is wrapped at the width it renders at, so a link counts as its anchor text and a backticked path counts whole, which parts the rendered count from a source count wherever an entry cites a path in backticks rather than as a link. Entries here are authored one line per bullet, so a block of fifteen paragraph-bullets occupies fifteen source lines and renders past sixty, which source counting cannot see.
 
@@ -89,7 +89,7 @@ The JSON record carries the findings per entry as `entries[].narration` and the
 
 ## The architecture record
 
-Two findings read `.claude/ARCHITECTURE.md` rather than a folder, and only the first is a fact.
+Two findings read `canon/ARCHITECTURE.md` rather than a folder, and only the first is a fact.
 
 The length check compares the record against the ceiling it derives for itself, and only a record that states its own allowances has one. No standard sets a length rule for this document, so the numbers belong to whichever record declares them. The check reads a frame allowance and an allowance per decision out of the record's own prose and puts the ceiling at the frame plus the allowance times the decision count. The JSON record carries what it read as `architecture.allowances` and the reading as `architecture.lines` against `architecture.ceiling`.
 
@@ -105,7 +105,7 @@ The report gates nothing. Deciding whether a sentence states a claim is a judgme
 
 ## Which folders each check reaches
 
-The provenance, required-section, and narration checks cover `.claude/context/` alone, the reference-form check covers the split folders inside it, and length and the table finding reach every audited folder.
+The provenance, required-section, and narration checks cover `canon/context/` alone, the reference-form check covers the split folders inside it, and length and the table finding reach every audited folder.
 
 What narrows the three is stated in `standards/context.md`, which opens its scope by handing diagrams and wireframes to `diagrams.md` and `wireframes.md`, and the sibling standards do not restate it. A marker reported in a diagram entry would cite a rule that entry's own standard routes elsewhere, and a diagram entry carries a heading per kind rather than a run of bullets deciding anything. The split is between kinds of rule rather than kinds of folder, and what decides it is which tier states the rule rather than what the check measures.
 

package/docs/agents/context-audit.md

@@ -5,7 +5,7 @@ description: Running the audit, its flags and folder scope, the exit codes, the
 
 # Context audit
 
-`canon context audit [path]` reports the structural state of the folders following the index-plus-entry contract, meaning a generated `index.md` beside entries carrying frontmatter, and it measures `.claude/ARCHITECTURE.md` beside them. It reads and reports. Fixing what it finds is separate work. What each finding means is in `context-audit-checks.md`.
+`canon context audit [path]` reports the structural state of the folders following the index-plus-entry contract, meaning a generated `index.md` beside entries carrying frontmatter, and it measures `canon/ARCHITECTURE.md` beside them. It reads and reports. Fixing what it finds is separate work. What each finding means is in `context-audit-checks.md`.
 
 Findings stated over every markdown file rather than over a context entry are measured by `canon markdown audit`, described in `markdown-audit.md`. That command resolves no folder, so it reaches trees this one refuses.
 
@@ -72,7 +72,7 @@ The exemption exists because the section check has a false-positive class. A sta
 
 The citation check resolves every path into an audited folder that appears anywhere in the repository, and it is the half wired into `bun run check`. A stale reference has a silent failure mode: the session opens nothing and carries on.
 
-Three exclusions keep it from firing on prose about paths. Fenced blocks are skipped in markdown, which covers a standard displaying a path as an example. Fixture and harness trees are skipped by location, covering sandbox scenarios that describe their own scratch tree, the eval harness naming its target project, and `*.test.ts`. A path into a folder the project does not carry is skipped, so a skill directing a reader to `.claude/wireframes/index.md` stays valid in a project that has wireframes and silent in one that does not.
+Three exclusions keep it from firing on prose about paths. Fenced blocks are skipped in markdown, which covers a standard displaying a path as an example. Fixture and harness trees are skipped by location, covering sandbox scenarios that describe their own scratch tree, the eval harness naming its target project, and `*.test.ts`. A path into a folder the project does not carry is skipped, so a skill directing a reader to `canon/wireframes/index.md` stays valid in a project that has wireframes and silent in one that does not.
 
 Two cases remain, and no syntax separates either from a real reference. One is a sentence naming a hypothetical entry to show the shape of a name. The other is a line instructing a target project about its own tree, which resolves against the target rather than against this repository and passes here only while the two layouts agree. Splitting a seeded domain into a folder ends that agreement and turns every such line red at once.