@erclx/canon 4.109.0 → 4.111.0

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

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

package/claude/skills/{canon-feedback-file → canon-feedback}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: canon-feedback-file
-description: Why a toolkit defect is reported from session context alone, and what shipping through the CLI replaces
+name: canon-feedback
+description: Why a toolkit defect is reported from session context alone, and what opening an issue through the CLI replaces
 ---
 
-# Canon feedback file requirement
+# Canon feedback requirement
 
 ## Gap
 
@@ -18,8 +18,9 @@ The last failure is the session's own effort. Asked to report, a session starts
 - Build the report from what the session already holds
 - Name the surface and its type, since the toolkit routes on that rather than on the symptom
 - Write the stated fallback for a field the session cannot fill, so an empty field reads as absent rather than as unreported
-- Ship through the CLI so the report lands without a copy-paste, and print the returned path on its own line
-- Offer the durable route for a report worth keeping across sessions and machines
+- Open a GitHub issue on the toolkit repo through the CLI so the report lands where triage reads it, and print the returned URL on its own line
+- Say which file and which reason when the issue call fails and the report falls back to a local folder, since a silent fallback leaves it where nothing reads it
+- Hold a report the operator marks sensitive, since the issue is public
 - Fall back to printing the block when the CLI is absent, so the report still exists
 
 ## Must not
@@ -36,5 +37,5 @@ The last failure is the session's own effort. Asked to report, a session starts
 
 - Fixing the defect, which happens in the toolkit repository against its own source
 - Draining the queue this fills: `canon-feedback-triage`
-- Filing an issue against the current project: `git-issue`
+- Filing an issue against the current project, which `git-issue` does and this skill cannot delegate to, since that skill targets the current repository
 - Complaints about tooling the toolkit does not own

package/claude/skills/{canon-feedback-file → canon-feedback}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: canon-feedback-file
-description: Format a paste-back report about something broken, missing, or off in canon and write it directly to the toolkit's `.canon/feedback/` folder via `canon feedback`. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
+name: canon-feedback
+description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback --github`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
 ---
 
-# Canon feedback file
+# Canon feedback
 
-Format a `## Toolkit feedback` block from the current session, then ship it to the toolkit repo without manual copy-paste.
+Format a `## Toolkit feedback` block from the current session, then open it as a GitHub issue labeled `feedback` on the toolkit repo. `canon-feedback-triage` reads that queue.
 
 ## Guards
 
@@ -69,9 +69,9 @@ Detect whether `canon` is on PATH:
 command -v canon >/dev/null 2>&1
 ```
 
-Before either pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block. `.canon/review/` is gitignored, so no hook reaches either write, and this scan is the only gate. The banned-character half runs on both branches, including the local write. The phase-label half applies only on the `--github` branch, where the block reaches a remote.
+The destination is a public GitHub issue on the toolkit repo, so the report leaves the machine. Hold it and ask when the operator has marked it sensitive, and never send it on a guess.
 
-Local scratch only writes from a toolkit checkout, since `canon feedback` resolves the destination against the toolkit's own `.claude/` folder and a target project never carries one. Pipe the block to `canon feedback --github` first.
+Before the pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block, phase-label half included. Nothing else checks what reaches the remote, so this scan is the only gate.
 
 ```bash
 cat <<'EOF' | canon feedback --github
@@ -81,19 +81,9 @@ cat <<'EOF' | canon feedback --github
 EOF
 ```
 
-The CLI opens a GitHub issue on the toolkit repo and prints the issue URL. It needs `gh` authenticated, and falls back to local scratch with the reason on stderr when the call produces no URL and the session holds a toolkit checkout to fall back onto.
+The CLI opens a GitHub issue labeled `feedback` on the toolkit repo and prints the issue URL, which this skill reports back on its own line. It needs `gh` authenticated. `git-issue` is not the route, since it files on the current repository and this report belongs on the toolkit's.
 
-From a toolkit checkout, plain `canon feedback` reaches the same destination without opening an issue:
-
-```bash
-cat <<'EOF' | canon feedback
-## Toolkit feedback
-
-...
-EOF
-```
-
-It writes to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the absolute path on stdout. Report the printed path back to the user on its own line, in the form the project's instruction file sets under `## Output`.
+From a toolkit checkout, a call that produces no URL falls back to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the reason on stderr. Say so in the same reply, naming the file and the reason, since a silent fallback leaves the report where nothing reads it. A target project has no such folder, so a failed call there prints the block in chat.
 
 If `canon` is not on PATH, fall back: print the block in chat and tell the user `📋 Copy the block above into a toolkit-repo session.`
 
@@ -109,4 +99,4 @@ A `--github` run from a toolkit checkout whose GitHub call fails warns and write
 ## Notes
 
 - `canon feedback` resolves the toolkit root from the running `canon` binary's source location. If multiple toolkit clones exist on the machine, the first `canon` on PATH wins.
-- The destination `.canon/review/` is gitignored in the toolkit repo. Feedback lives as session scratch for the next toolkit-side triage, not as a durable archive.
+- The local folder is a fallback for a failed issue call, and nothing reads it on a schedule. The issue is the durable record.

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

@@ -35,6 +35,6 @@ The queue also fails to drain even when the work ships. A fix merged with no lin
 
 ## Out of scope
 
-- Filing new feedback: `canon-feedback-file`
+- Filing new feedback: `canon-feedback`
 - Writing the plan a plan-worthy issue needs: `plan-feature`
 - Triage of issues carrying any other label, which surface here by design only under the feedback label

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

@@ -1,6 +1,6 @@
 ---
 name: canon-feedback-triage
-description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback-file`), or for general GitHub issue triage unrelated to toolkit feedback.
+description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback`), or for general GitHub issue triage unrelated to toolkit feedback.
 ---
 
 # Canon feedback triage

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

@@ -26,8 +26,8 @@ The last failure is a section no route reaches. `## Route` maps an intent or a d
 - Resolve every stack, rule, snippet, and standard name from a catalog at runtime
 - Run the CLI non-interactively and report the command run, what changed, and the full path of anything written
 - Read the overwrite contract from the body before any install or sync, and name each surface it lists as overwritten before running one
-- Read the reverse walk beside the forward sections, so a folder the toolkit stopped shipping and a migration with a live case both reach the user
-- Hand off a named migration to the skill the report names, and name an unmigrated domain's root and install path for the user to move themselves when no skill covers it
+- Read the reverse walk beside the forward sections, so a folder the toolkit stopped shipping reaches the user
+- Name an unmigrated domain's root and install path for the user to move themselves, since no skill covers the move
 - Route a measurement intent to the audit offers from the route table itself, rather than leaving the section reachable only by reading past the table
 - Rank a lifecycle row against the audit offers where the route table itself states it, so a session acting on the lifecycle row reads the ranking without opening the section being ranked
 - Offer every audit whose surface the target carries, and offer none whose surface it lacks

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

@@ -25,10 +25,10 @@ Run `canon sync --check . --json` before routing. It reports what a target is be
 Read seven fields off the report and carry each to `## Route`:
 
 - `unmigrated`: a domain sitting at the root layout with nothing under `.claude/`. The most urgent finding, because that domain reports no drift of its own while being entirely behind
-- `superseded`: a file a newer seed folder replaced. No command moves it, since the content is the project's own, so this routes to the skill that proposes the split rather than ending at the report
+- `superseded`: a file a newer seed folder replaced. No command moves it, since the content is the project's own, so this routes to `canon:target-check` for the full per-domain reading rather than ending at the report
 - `seeds`: entries are `matching`, `stale`, `drifted`, or `missing`. Anything but `matching` needs the seed handoff
 - `domains[].entries`: per-file `stale`, `customized`, `stranded`, and `orphaned` as before
-- `reverse`: what the target holds that no live catalog claims. `unclaimed` lists folders at roots the toolkit stopped shipping, each with an `attribution` of `dropped`, `unattributed`, or `project`. Act on the first two and leave `project` alone, which history proved the project owns. `migrations` names a proposal-only skill with a live case here and the `reason` it was measured from
+- `reverse`: what the target holds that no live catalog claims. `unclaimed` lists folders at roots the toolkit stopped shipping, each with an `attribution` of `dropped`, `unattributed`, or `project`. Act on the first two and leave `project` alone, which history proved the project owns
 - `historyUnavailable` on a domain, on `seeds`, or on `reverse`: nothing could be dated, so treat every difference as unverified and say so rather than reporting a file as untouched. It is set on `reverse` when the toolkit itself ships without history, which is the registry-install case, so the walk found nothing rather than finding a clean target
 - `tooling`: read `measured` first. Every count under it is zero when it is false, which is an absence of measurement rather than a measured zero. Past that, `chain` names the stacks the install resolved, nearest first, and `counts.gitignore` counts the managed ignore entries the target is missing.
 
@@ -43,8 +43,7 @@ Map the stated intent, or what `## Diagnose` found, to one lifecycle phase, then
 The two can name different rows, and a reply answers both rather than picking one. Run or hand off what the finding names, then answer the intent in the same reply. A measurement intent therefore reaches the audit offers below even on a target whose diagnostic found scaffold work, which is the case a session leaving from the scaffold row would otherwise never read.
 
 - A domain in `unmigrated`: name it, the root path, and the install path. No command moves it, so the user runs the relocation themselves
-- An entry in `migrations`: hand off to the skill its `skill` field names, spelled as the report spells it. Both of them propose without writing, so the handoff is where this stops
-- Anything in `superseded`: name which files and what replaced them, then hand off to `migration-superseded`. Both skills propose, so neither moves nor deletes the file
+- Anything in `superseded`: name which files and what replaced them, then hand off to `canon:target-check`, which reports and never moves or deletes the file
 - A folder in `unclaimed`: name it and the attribution it carries. No command moves it and the content may be the project's own, so the decision is the user's
 
 - First-time scaffold of a fresh project: hand off to `target-setup`

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

@@ -0,0 +1,42 @@
+---
+name: draft-wiki
+description: Why a brand-new wiki reference page needs both placement tests, a catalog collision check, and a sourced read before anything is written
+---
+
+# Wiki draft requirement
+
+## Gap
+
+Without this skill, a session asked for a wiki page writes one from training knowledge, which is the single thing the wiki standard forbids outright, and nothing in the resulting file shows that it happened. It also files the page by where the request came from rather than by who owns the subject, so material about the project itself lands in the wiki and material about a third-party tool acquires a folder the standard never sanctioned.
+
+The standard can state all of this and still be read by nothing, which is the condition this skill was written into in the toolkit. A page written under that condition conforms by the author's memory rather than by a read, and it ships looking identical to one that was checked.
+
+## Must
+
+- Read the wiki standard before drafting, since the placement tests and the sourcing rule are the two things a session gets wrong from memory
+- Run both placement tests and refuse on either, since a page passing one and failing the other is still non-conforming
+- Check the subject against the catalog by title and description, not by slug alone, since a subject can be covered under a name the slug does not guess
+- Build the draft on a fetched read and stop when the fetch fails, since a page written from recall is indistinguishable from a checked one once it ships
+- Confirm the path, the source, and the content with the user before writing, since the standard forbids writing a wiki file unasked
+- Name the folder by resolving what the standard states rather than by carrying a path in the body, since the body ships to projects whose layout this repository does not set
+
+## Must not
+
+- Widen the folder split to admit a subject the second placement test rejects. That is a change to the standard, argued there.
+- Edit or refresh a page that already exists. A collision refuses toward editing the existing page rather than drafting a second one.
+- Substitute recall for a failed fetch, even for a subject the session believes it knows.
+
+## Guards
+
+- No subject given: stop and ask what subject the page should cover.
+- The wiki root does not resolve: say so and ask before creating it, since a project holding no wiki has never taken the placement rule.
+- The slug already resolves to a page: stop and point at editing that page.
+- The catalog already covers the subject under a different name: stop the same way, checked against the titles and descriptions the Collision step already reads.
+
+## Out of scope
+
+- Editing or refreshing a wiki page that already exists: a plain edit against the same standard
+- Drafting a `docs/*.md` page: `draft-docs`
+- Drafting a `canon/context/<domain>.md` entry: `draft-context`
+- Voice, rhythm, and sentence construction in the drafted page: the `write-human` skill
+- Punctuation, headings, and word choice in the drafted page: the markdown standard

package/claude/skills/draft-wiki/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: draft-wiki
+description: Drafts a brand-new wiki reference page for a subject owned outside this repository, against the wiki standard. Checks the two placement tests and the catalog for a collision, sources the subject from its owner rather than from training knowledge, confirms with the user, then writes. Use when asked to "write a wiki page for X", "add a wiki reference for X", "document X in the wiki", or "create a reference page for X" where no page covers the subject yet. Do NOT use to edit or refresh a page that already exists, which is a plain edit against the same standard. Do NOT use for a subject this repository owns, which is `draft-docs` or `draft-context`.
+---
+
+# Wiki draft
+
+Drafts one brand-new wiki reference page end to end: read the standard, settle placement, check the catalog for a collision, source the subject from its owner, confirm the draft with the user, then write.
+
+Read these files in parallel:
+
+- `${CLAUDE_SKILL_DIR}/../../standards/wiki.md`: the two placement tests, the frontmatter contract, the naming convention, the sourcing rule, and the page template
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- The `write-human` skill: voice, rhythm, and sentence construction for all generated text
+
+The standard's `## Placement` section names the folder a page lands in and the vendor subfolder under it. Resolve both from the project root and call them `<wiki-root>` and `<vendor>` below, so the body states the rule once and the standard stays the one owner of the path.
+
+## Guards
+
+- If no subject is given, stop: `❌ No subject given. Name the subject this page should cover.`
+- If `<wiki-root>` does not resolve, say so and ask whether to create it before drafting. A project carrying no such folder has never taken the standard's placement rule, so creating it is a decision rather than a step.
+
+## Placement
+
+The standard sets two tests and a page has to pass both. Run them before drafting anything, since a page failing either is non-conforming however well it is written.
+
+- **Owned outside this repository.** A subject describing how this repository works fails. Refuse and route it: `❌ <subject> is owned by this project, so it belongs in the docs surface, a context entry, or a skill body. Use draft-docs or draft-context.`
+- **Owned by the vendor the folder split covers.** The standard names one owner and one subfolder. A third-party tool or a vendor-neutral concept fails, however reference-like it reads. Refuse and route it: `❌ <subject> is outside the wiki's folder split. Route it to the docs surface or a skill body rather than adding a second folder for it.`
+
+Do not widen the split to admit a subject. Adding a sibling folder is a change to the standard, argued there, rather than a placement this skill takes on its own.
+
+## Collision
+
+- Derive the page slug per the standard's `## Naming` section and check whether `<wiki-root>/<vendor>/<slug>.md` already exists. If it does, stop: `❌ <path> already covers this subject. Edit that page against the standard instead of drafting a second one.`
+- Read `<wiki-root>/<vendor>/index.md` and check every title and description it lists against the subject. The slug check above only catches an exact filename collision, and a subject already covered under a different name still resolves here at no extra cost, since this read already runs.
+- Stop the same way on a match: `❌ <path> already covers this subject under a different name. Edit that page instead.`
+
+## Source
+
+The standard forbids working from training knowledge, so the draft is built on a read rather than on recall.
+
+- Fetch current information through the `claude-code-guide` agent for any subject that agent covers. Its answer is the source the page is written from.
+- Reach a subject the agent does not cover through the owner's own published documentation.
+- Say the fetch failed and stop rather than substituting recall. A page sourced from memory is the failure the rule exists to prevent, and it ships looking identical to one that was checked.
+- Close the intro with the `Source:` sentence the standard requires, linking the canonical page where one exists and naming the owner alone where the subject has no single URL.
+- Stamp the read date on a source revised without notice, as `read <date>`. A claim traced to an undated read cannot be checked against what was actually read.
+
+## Draft
+
+- Draft `title` and `description` frontmatter against the standard's contract, then the intro paragraph closing on `Source:`, then the reference sections.
+- Draft against the standard's template and keep its ordering.
+- Write what the fetch returned rather than what the subject is assumed to do.
+- Answer one question per section and stop. A reader arrives to settle something specific rather than to read the page through.
+- Mark a claim the fetch left unsettled rather than smoothing over it. An unmarked gap reads as a checked fact.
+
+## Confirm
+
+- Show the resolved path, the source the page was built from, and the full drafted content before writing.
+- Confirm all three with the user. This skill waits for that answer rather than treating the tool permission dialog as the gate, since the standard states outright that a wiki file is not written unasked.
+
+## Write
+
+- Write the file at the confirmed path.
+- Run `canon markdown audit <path>`.
+- Run `canon indexes regen <wiki-root>/<vendor>`, naming the folder the page landed in rather than the root above it. The verb rewrites the `index.md` sitting in the folder it is given and does not walk down, so regenerating at the root leaves the vendor catalog untouched and the new page missing from the one the Collision step reads. A page absent there is invisible to the next run, which then drafts a second page on the same subject.
+
+## Response format
+
+### Preview
+
+**Subject:** `<subject>`
+**Placement:** `<path>`
+**Source:** `<owner, and the read it came from>`
+
+```markdown
+<drafted frontmatter and body>
+```
+
+### After confirmation
+
+```plaintext
+✅ Drafted: <path>
+```

package/claude/skills/git-issue/REQUIREMENT.md

@@ -33,6 +33,6 @@ Without this skill, an issue takes the shape of whatever the session was saying.
 
 ## Out of scope
 
-- Reporting a toolkit defect from a target project, which `canon-feedback-file` owns. That path writes into the toolkit rather than the current repository.
+- Reporting a toolkit defect from a target project, which `canon-feedback` owns. That path opens an issue on the toolkit repository rather than the current one.
 - Triaging issues already filed, which `canon-feedback-triage` owns
 - Opening a pull request, which `git-pr` owns

package/claude/skills/git-issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: git-issue
-description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `canon-feedback-file`), or to open a pull request (that is `git-pr`).
+description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `canon-feedback`), or to open a pull request (that is `git-pr`).
 ---
 
 # Git issue

package/claude/skills/target-check/references/domains.md

@@ -25,7 +25,7 @@ Read three fields off the same report, then two verbs:
 
 - `unmigrated`: a domain still at the root layout with nothing under `.claude/`. The most urgent finding, because such a domain reports no drift of its own while being entirely behind.
 - `superseded`: a file a newer seed folder replaced. No command moves it, since the content is the project's own.
-- `reverse`: `unclaimed` names folders at roots the toolkit stopped shipping, each with an `attribution` of `dropped`, `unattributed`, or `project`. `migrations` names a proposal-only skill with a live case here and the `reason` behind it.
+- `reverse`: `unclaimed` names folders at roots the toolkit stopped shipping, each with an `attribution` of `dropped`, `unattributed`, or `project`.
 - `canon context audit --json`: required sections, entry length, citations, and index drift across the context folder.
 - `canon records validate <kind> --json`, once per record folder the target carries.
 
@@ -33,7 +33,7 @@ Read three fields off the same report, then two verbs:
 - Behind: any of those carrying an entry. Name the entry and its attribution.
 - Unread: `historyUnavailable` set on `reverse`, a `reverse` key the report does not carry at all, or either verb refusing. A missing `reverse` key is a binary predating the field rather than a target with nothing unclaimed.
 
-Routes by finding. `unmigrated` routes to a relocation the user runs, since no command moves it. `superseded` routes to `migration-superseded`. A `migrations` entry routes to the skill its `skill` field names, spelled as the report spells it. An `unclaimed` folder carrying `project` attribution routes nowhere, since history proved the project owns it.
+Routes by finding. `unmigrated` routes to a relocation the user runs, since no command moves it. `superseded` routes to a split the user makes, since no command moves the content and no skill proposes it. An `unclaimed` folder carrying `project` attribution routes nowhere, since history proved the project owns it.
 
 ## 3. Governance rules
 

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

@@ -256,11 +256,9 @@ seed tree rather than from a fixed set of filenames, so a folder added later is
 covered without a code change. Only an exact stem matches, which leaves a
 suffixed variant such as `TASKS-ARCHIVE.md` unreported.
 
-Route it to `migration-superseded`. That skill resolves the standard governing
-`replacedBy` from the `appliesTo` the standards catalog declares, reads the
-destination shape with `canon standards <name>`, and proposes the split without
-writing. Where a folder has no governing standard, the entry earns a named
-refusal rather than a shape nobody stated.
+No skill splits the file. The standard governing `replacedBy` is the one the
+`appliesTo` the standards catalog declares, and `canon standards <name>` reads
+its destination shape, so the split is the project's own to make.
 
 `unmigrated` names a domain sitting at the root layout an older toolkit installed
 to, with nothing at the path the current one reads. It carries `rootPath`,
@@ -350,7 +348,7 @@ check.
 `reverse` is the one section built by walking the target rather than the
 catalog. Every other surface enumerates toolkit-owned keys and asks whether the
 target matches, so a folder the toolkit deleted appears in none of them. It
-carries `unclaimed`, `migrations`, and `historyUnavailable`.
+carries `unclaimed` and `historyUnavailable`.
 
 `unclaimed` names a folder the target holds at a top-level path the toolkit once
 shipped and has since deleted. The candidate roots come from the toolkit's own
@@ -381,13 +379,6 @@ colliding on a retired name costs the walk no reads. The cost is that a file the
 toolkit shipped and the target renamed goes unmatched, the same limit the
 `unmigrated` count carries.
 
-`migrations` names a proposal-only skill with a live case in this target. It
-fires on a `CLAUDE.md` past 250 lines for `migration-claude-md`, and on a `docs/` folder
-holding markdown with no populated `canon/context/` for `migration-context`.
-Each entry carries the skill name and the measurement behind it, so a consumer
-can check the proposal before running it. Without the field both skills are
-documented and unreachable from any report.
-
 #### What counts toward the gate
 
 `unmigrated` counts toward `--exit-code`, since running the relocation closes it.

package/docs/agents/teach.md

@@ -133,7 +133,7 @@ It reports three things. `lesson` is the numbered path the lesson takes, derived
 
 A lesson written against this record carries its chrome as four empty marker pairs rather than hand-composed markup: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. `canon teach nav`, below, fills them from what the workspace holds on disk.
 
-`canon teach stylesheet <topic>` writes the one file every lesson in the workspace embeds, seeded from the design source so a workspace renders in the system every other surface does. It refuses to overwrite, reporting `written` as false where the workspace already carries one, and `--force` takes the seed back over it. Each workspace used to carry a hand-authored palette, which is how the course styling forked once per workspace, so a lesson adds its own rules under the seed and reaches a value through its custom property rather than restating the hex.
+`canon teach stylesheet <topic>` writes the pair every lesson in the workspace renders through, seeded from the design source so a workspace renders in the system every other surface does. The two halves are written on different terms. `assets/base.css` holds the generated design layer and is rewritten on every run, which is the only way a change to the shared chrome reaches a workspace that already exists. `assets/course.css` is the half a workspace owns, so it refuses to overwrite, reporting `written` as false where the workspace already carries one, and `--force` takes the seed back over it. Each workspace used to carry a hand-authored palette, which is how the course styling forked once per workspace, so a lesson adds its own rules under the seed and reaches a value through its custom property rather than restating the hex.
 
 Each `quiz` entry carries `order`, the authored option indices in presentation order where index `0` is the correct answer, and `answer`, the one-based position that answer lands in. Both travel together because a caller deriving the position itself is a caller that can derive it wrongly.
 
@@ -172,10 +172,12 @@ canon teach nav regular-expressions --json
 
 With no topic it rewrites every workspace. The teach-root listing is always rewritten regardless, since it reports on every workspace and a scoped run leaving it stale would be a second kind of drift this verb exists to end.
 
-A lesson carries its chrome as four marker pairs the authoring skill writes empty: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. This verb splices each one from the current workspace state, embedding the shared stylesheet, rebuilding the breadcrumb and jump menus, the prev/next footer nav, and the behavior scripts, and leaves the authored `<h1>`, lede, body, and quiz between the header and the footnav untouched.
+A lesson carries its chrome as four marker pairs the authoring skill writes empty: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. This verb splices each one from the current workspace state, embedding the shared stylesheet and the script that settles the course panel before the page paints, rebuilding the course sidebar, the breadcrumb and jump menus, the prev/next footer nav, and the behavior scripts, and leaves the authored `<h1>`, lede, body, and quiz between the header and the footnav untouched.
 
 A workspace carrying no `course.css` gets its stylesheet pair seeded first, so the contents page it links is never unstyled, and an existing `course.css` is never overwritten. The embedded copy drops the seed's `@import` line, which resolved against the lesson's own folder and never loaded anything.
 
+That seeding fires on the absent file alone, so a workspace already holding a `course.css` has neither half rewritten here and its lessons go on embedding the sheet they were built against. A change to the shared chrome therefore takes `canon teach stylesheet <topic>` per workspace first, which rewrites `assets/base.css`, and then this verb to embed the result. Running this one alone renders every lesson missing whatever the change added, and nothing reports it.
+
 A lesson missing one of the four marker pairs is refused by name rather than rewritten, and every other lesson in the run still rewrites. The record's `skipped` list carries the refused files and which marker each is missing.
 
 The `style` region carries the quiz stepper after the workspace stylesheet, for every lesson but the one shape named three paragraphs down, so it wins the cascade at equal specificity and reaches a workspace seeded before it existed. The stepper is CSS over the radio inputs a quiz is written from: it hides every question that follows one holding no checked input, and hides a question's feedback until that question does. The general sibling combinator is what keeps that from depending on the markup contract holding, since it selects the same questions as the adjacent one for a quiz written correctly and goes on gating when anything sits between two of them, where the adjacent one matches nothing and shows them all at once. Gating there rather than in a script is what keeps a later stem from answering an earlier question with nothing to bind, and the whole block sits inside `@supports selector(:has(*))`, so an engine without `:has()` renders every question rather than a stepper showing nothing. Feedback there follows the workspace stylesheet, shown by one that says nothing about `.fb` and hidden by one grown under the retired script.

package/docs/target-projects.md

@@ -261,8 +261,6 @@ Each entry carries a verdict, since a dropped folder and one the project wrote a
 
 Nothing acts on any of them, and the verdict is what makes the list safe to read.
 
-The same field names a proposal-only skill with a live case here under `migrations`, which is how `canon:migration-claude-md` and `canon:migration-context` become reachable. Each entry carries the measurement behind the proposal rather than the proposal alone.
-
 Add `--json` for the machine-readable report, and `--exit-code` to fail a CI job when a target falls behind. Files the project authored itself never count toward that exit code, and neither do superseded artifacts, seed drift, tooling, or anything the reverse walk reports, since each names content the project is expected to edit or place itself. An unmigrated domain does count, because running the relocation closes it.
 
 Tooling reports under a section of its own, and `measured` there says whether the target ever recorded a chain. One that never ran a tooling sync reports unmeasured rather than clean, which is what separates tooling nobody has looked at from tooling that is current. A workspace root records nothing either way, since each package resolves its own chain.

package/docs/workflow/ai-workflow.md

@@ -285,17 +285,13 @@ This section is the corpus the coverage claim is measured against: every name `c
 
 ### Keep the project current with the toolkit
 
-| 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:migration-claude-md`      | When `CLAUDE.md` grew past what always-load context should carry                       |
-| `canon:migration-context`        | When `docs/` holds agent-flavored files belonging in `canon/context/`                  |
-| `canon:migration-superseded`     | When a drift report names a `.claude/` file a folder has replaced                      |
-| `canon:migration-standards-drop` | When the project still holds an installed `.claude/standards/` tree                    |
-| `canon:canon-feedback-file`      | When something in the toolkit is broken, missing, or off                               |
-| `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         |
+| 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         |
 
 ### Generate an artifact on demand
 
@@ -309,6 +305,7 @@ This section is the corpus the coverage claim is measured against: every name `c
 | `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                           |
 | `canon:draft-context`     | For a brand-new `canon/context/<domain>.md` entry, drafted against `standards/context.md`                                           |
 | `canon:draft-wireframes`  | For a brand-new `canon/wireframes/<surface>.md` file, drafted against `standards/wireframes.md`                                     |
+| `canon:draft-wiki`        | For a brand-new wiki reference page on a subject owned outside the project, drafted against `standards/wiki.md`                     |
 | `canon:draft-figure`      | For a hand-drawn figure inside an existing doc, drafted against `standards/figures.md` and rendered through Mermaid or freehand SVG |
 | `canon:draft-readme`      | For a project's `README.md`, drafted against `standards/readme.md`                                                                  |
 | `canon:bash-script`       | For an interactive, human-facing shell tool                                                                                         |

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.109.0",
+  "version": "4.111.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/scripts/core/capture-home.sh

@@ -0,0 +1,59 @@
+#!/usr/bin/env bash
+# Builds the landing page, captures it, and stages the frames over
+# assets/evidence/home, the baseline `canon pr evidence` compares against.
+#
+# Two workflows call it. pr-visual-checks.yml stages the frames into the runner
+# tree to diff them against the baseline, and refresh-capture-frames.yml stages
+# them to commit as the new baseline. Both need the same frames, so one script
+# keeps the two from drifting apart.
+#
+# `tooling/web/configs/e2e/screenshot.ts` is reused as is. This checkout has no
+# web/package.json, so the preview server and the cases run against the
+# root-level scripts rather than through screenshot.sh, which assumes a
+# per-project `bun run build`/`bun run preview` pair.
+set -e
+set -o pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+PROJECT_ROOT="${PROJECT_ROOT:-$(cd "$SCRIPT_DIR/../.." && pwd)}"
+
+PORT=4321
+BASE_URL="http://localhost:$PORT"
+BASELINE="$PROJECT_ROOT/assets/evidence/home"
+
+cd "$PROJECT_ROOT"
+
+bun run web:build
+
+bun run web:preview &
+PREVIEW_PID=$!
+trap 'kill "$PREVIEW_PID" 2>/dev/null || true' EXIT
+
+for _ in $(seq 1 40); do
+  curl -sSf "$BASE_URL/" >/dev/null 2>&1 && break
+  sleep 0.25
+done
+curl -sSf "$BASE_URL/" >/dev/null 2>&1 || {
+  echo "Preview server not responding on port $PORT after 10s." >&2
+  exit 1
+}
+
+(cd web && SCREENSHOT_BASE_URL="$BASE_URL" bun ../tooling/web/configs/e2e/screenshot.ts)
+
+# The committed tree is cleared first rather than copied over. A copy only adds
+# and overwrites, so a section dropped from the case list would leave its
+# frames in place and a diff would see no change. Clearing first shows that
+# section as a deletion.
+rm -rf "$BASELINE"
+mkdir -p "$BASELINE"
+cp -R web/screenshots/localhost/home/. "$BASELINE/"
+
+# The sweep holds all four widths and this repository commits two, 320 and
+# 1280. The case list is the place to change if that set moves.
+find "$BASELINE" \( -name '768--*.png' -o -name '1536--*.png' \) -delete
+
+# The shared golden config names the case that emulates nothing `default`, and
+# this repository's baseline names that frame `light`.
+find "$BASELINE" -name '*--default.png' -execdir sh -c 'mv "$1" "${1%--default.png}--light.png"' _ {} \;
+
+echo "capture-home: staged frames in assets/evidence/home"

package/src/claude/cases/authoring.ts

@@ -61,6 +61,11 @@ export const AUTHORING_CASES: readonly SkillCase[] = [
       'Draft a wireframe for the settings panel, nothing under canon/wireframes covers that surface yet.',
     expect: 'draft-wireframes',
   },
+  {
+    prompt:
+      'Write a wiki reference page for Claude Code output styles, no page covers that subject yet.',
+    expect: 'draft-wiki',
+  },
   {
     prompt: 'Say what that dense answer actually means in plain terms.',
     expect: 'restate-plainly',

package/src/claude/cases/setup.ts

@@ -1,9 +1,8 @@
 import type { SkillCase } from '@/claude/skills-rank'
 
 /**
- * `target-setup`, `migration-*`, `canon-*`, and `create-rule`: scaffolding,
- * proposal-only migrations, and the toolkit's own reference and feedback
- * surfaces.
+ * `target-setup`, `canon-*`, and `create-rule`: scaffolding and the
+ * toolkit's own reference and feedback surfaces.
  *
  * The five `target-setup` cases are one skill read through five entry phrasings
  * rather than five rows that collapsed to a duplicate. Each names a different
@@ -36,26 +35,6 @@ export const SETUP_CASES: readonly SkillCase[] = [
       'Check that the dev server actually starts and the end-to-end suite passes against the scaffold.',
     expect: 'target-setup',
   },
-  {
-    prompt:
-      'This CLAUDE.md file has grown huge, break it apart into the tiered context model.',
-    expect: 'migration-claude-md',
-  },
-  {
-    prompt:
-      'Move the agent-flavored docs out of the docs folder and into context.',
-    expect: 'migration-context',
-  },
-  {
-    prompt:
-      'This file was replaced by a folder, help me split its content into it.',
-    expect: 'migration-superseded',
-  },
-  {
-    prompt:
-      'This project still carries a copy of the standards folder, get rid of it and point everything at the CLI.',
-    expect: 'migration-standards-drop',
-  },
   {
     prompt:
       "Before I run this sync, tell me exactly what it's going to overwrite.",
@@ -64,7 +43,7 @@ export const SETUP_CASES: readonly SkillCase[] = [
   {
     prompt:
       'Something about the toolkit itself is broken, write it up and send it back to the maintainers.',
-    expect: 'canon-feedback-file',
+    expect: 'canon-feedback',
   },
   {
     prompt:

package/src/commands/sync.ts

@@ -189,7 +189,6 @@ function renderCheck(report: CheckReport): void {
   }
 
   renderUnclaimed(report)
-  renderMigrations(report)
 
   outro()
   // Scanned domains only. Tooling renders a section on every managed target, so
@@ -334,21 +333,6 @@ function describeUnclaimed(entry: UnclaimedFolder): string {
   return `${counted}, content published at ${entry.since.slice(0, 7)}`
 }
 
-/**
- * The proposal-only skills no other field reaches.
- */
-function renderMigrations(report: CheckReport): void {
-  const { migrations } = report.reverse
-  if (migrations.length === 0) return
-
-  logStep('Migrations with a case here')
-
-  for (const candidate of migrations) {
-    logWarn(candidate.reason)
-    logInfo(`Run /canon:${candidate.skill} for a proposal.`)
-  }
-}
-
 async function runSync(target: string): Promise<number> {
   intro('canon sync')