@erclx/canon 5.30.0 → 5.32.0

package/docs/agents/upstream.md

@@ -0,0 +1,94 @@
+---
+title: Upstream
+description: The fetch, catalog, due, and advance verbs that read Claude Code releases against the toolkit, the cursor record, and each refusal reason
+---
+
+# Upstream
+
+`canon upstream` reads the Claude Code release feed from a stored cursor and lists canon's own mechanisms beside it, so a triage can match a release line to something canon does. The verbs ship in the published CLI as `canon gate` and `canon sandbox` do, and only this repository has the skill that drives them. A target has no use for them.
+
+Run them as `bun src/cli.ts upstream ...` from this repository's root. The global `canon` resolves to the installed package, which lacks the verbs until a release ships them.
+
+## Verbs
+
+| Verb                                | Behavior                                                                     |
+| ----------------------------------- | ---------------------------------------------------------------------------- |
+| `fetch [--since <version>]`         | List the release lines since the cursor, with the mechanical noise dropped   |
+| `catalog`                           | List the skills, verbs, hooks, and gate stages the tree holds, one line each |
+| `due`                               | Say whether a digest is due, from the cursor and the installed version       |
+| `advance <version> --intake <slug>` | Move the cursor to a version, and store the current `llms.txt` beside it     |
+
+Every verb takes `--root <path>` for the repository to read and `--json` for a record on stdout. `fetch` and `catalog` write nothing, and `due` writes only its day cache. `advance` is the only writer of the cursor, and the digest skill runs it after the findings are filed, so a run that dies midway reads the same range next time.
+
+## fetch
+
+```bash
+bun src/cli.ts upstream fetch --json
+bun src/cli.ts upstream fetch --since 2.1.256 --json
+```
+
+The range runs from the cursor, or from `--since` when given, to the newest release. The walk stops at the first release whose version is not newer than the cursor, so a cursor naming a version the feed never carried still bounds the range, and a range crossing a page boundary is read whole.
+
+A line survives when it opens with `Added`, `Changed`, `Removed`, `Improved`, or `Deprecated` and carries none of the dropped surfaces: `[VSCode]`, `[Claude Tag]`, `[Code Review]`, `Windows:`, `Self-hosted`, the apps gateway, managed settings, OpenTelemetry, Bedrock, Vertex, and screen reader. A nested bullet and a `*` bullet are read as well as a `-` one.
+
+Without `--json`, stdout carries one `version<TAB>text` row per line. With it, stdout carries one record:
+
+| Field      | Holds                                                                      |
+| ---------- | -------------------------------------------------------------------------- |
+| `from`     | The cursor version the range starts after                                  |
+| `to`       | The newest release version, or `from` when nothing is newer                |
+| `releases` | How many releases the range spans                                          |
+| `lines`    | Each kept line as `version`, `date`, `text`, and `identifiers`             |
+| `llms`     | `added` and `removed` lines of `llms.txt` against the stored copy, or null |
+
+An identifier is a backticked name on a `Changed`, `Removed`, or `Deprecated` line that holds a dash, a slash, a dot, or a capital. It carries up to three tracked files naming it, and one with no hit is left out. `llms` is null when the page could not be fetched, and every line reads as added until `advance` has stored a first copy.
+
+The request sends `GH_TOKEN` or `GITHUB_TOKEN` when either is set. Unauthenticated, GitHub allows 60 requests an hour, and a range takes about three.
+
+## catalog
+
+Prints a heading per section and a line per entry. With `--json` it prints one record whose fields are `skills`, `internalSkills`, `verbs`, `hooks`, `gate`, and `gaps`, each entry as `name` and `text`. A skill folder with no `SKILL.md` or no description appears in `gaps` rather than dropping out. A hook's text is the first comment line after its shebang.
+
+## due
+
+```bash
+bun src/cli.ts upstream due --json
+```
+
+Answers whether a digest is worth running now. It exits 0 whether or not one is due, so branch on the record rather than the exit. The installed version comes from `claude --version`, and the cursor from the main worktree root.
+
+| Reason            | `due`   | Meaning                                                                    |
+| ----------------- | ------- | -------------------------------------------------------------------------- |
+| `no-cursor`       | `true`  | No digest has been run, so a first run is prompted                         |
+| `week`            | `true`  | The cursor is seven or more days old and the install is ahead of it        |
+| `vocabulary`      | `true`  | An `Added` line in the gap names a plugin, skill, hook, worktree, or so on |
+| `current`         | `false` | The install is at or below the cursor, as after a downgrade                |
+| `recent`          | `false` | The cursor is under a week old and no line in the gap matches              |
+| `unknown-version` | `false` | `claude --version` could not be read                                       |
+
+The record is `due`, `reason`, `releases`, `installed`, and `cursor`. `releases` counts the releases in the gap and is `null` when the feed was not read, so a `week` result can arrive without a count.
+
+The gap is read from GitHub only when the install is ahead of the cursor, and the result is cached for a day under the scratch folder at `.canon/tmp/upstream-due/check.json`. A failed read is cached too, so a rate limit hit by one session is not retried by the next. Nothing here moves the cursor.
+
+The `.claude/hooks/upstream-due.sh` hook runs the verb at an attended session start and shows the operator one line when it is due. It stays silent in a background session, on a resume, a clear, or a compaction, and on any failure.
+
+## advance
+
+Writes `cursor.json` and the fetched `llms.txt` under the upstream record folder at the main worktree root, each through a temp file and a rename. `--no-llms` keeps the stored `llms.txt` and fetches nothing. The record is `version`, `intake`, `advanced`, and `llms`, which reads `stored` when a fresh copy was written and `kept` when the stored one stayed, whether by `--no-llms` or because the fetch failed.
+
+The cursor file holds `version`, `date`, and `intake`. The folder is a backed record folder, so `canon records push` carries it.
+
+## Refusals
+
+A refusal exits 1, prints the reason on stderr, and with `--json` adds `reason` and `message` to stdout. Branch on `reason`.
+
+| Reason              | Verb      | Meaning                                                             |
+| ------------------- | --------- | ------------------------------------------------------------------- |
+| `no-cursor`         | `fetch`   | No cursor is stored and no `--since` was given. Pass the flag.      |
+| `bad-since`         | `fetch`   | `--since` is not a dotted version                                   |
+| `cursor-missing`    | `fetch`   | Every release the feed returned is newer than the cursor            |
+| `rate-limited`      | `fetch`   | GitHub refused the request. Set `GH_TOKEN` or `GITHUB_TOKEN`.       |
+| `network`           | `fetch`   | The feed could not be reached                                       |
+| `http`              | `fetch`   | GitHub answered with an error status                                |
+| `invalid-version`   | `advance` | The version is not a dotted number                                  |
+| `older-than-cursor` | `advance` | The version is older than the stored cursor, which never moves back |

package/docs/target/migrations.md

@@ -64,6 +64,12 @@ Twenty-five plugin skills dropped their `claude-` prefix for two-word names, so
 
 The same sweep carries the merge of the five per-kind document drafters into `draft-doc`, so a citation of any one of them lands on `canon:draft-doc`.
 
+Fourteen skills, one verb, and one rule were retired without a rename, so the sweep has nothing to map them to and leaves a citation of one as it stands. `design-extract` and `sketch-design` are replaced by `canon:canvas`, which carries a picked direction into `canon/DESIGN.md`. `review-branch`, `seed-sync`, `restate-plainly`, `bash-cli-script`, `canon-operator`, `canon-rollout`, `create-standard`, `markdown-propose`, `memory-review`, `project-commands`, `repo-metadata`, and `ux-walkthrough` have no successor. `canon repo metadata` went with `repo-metadata`, and `canon autoship` went with `review-branch`, whose review step it served. The `120-bash` rule left the `base` stack, so `canon gov sync` removes its installed copy. Replace each citation by hand, or delete the sentence naming a skill that has no successor. <!-- canon-keep-retired -->
+
+The memory system retired the same way. `memory-capture`, the `603-memory` rule, and the `memory` standard have no successor, and a citation of any one is replaced by hand or deleted. Ship chains no longer capture a session's lessons, so a lesson goes to the context entry that owns the fact, or to a task's findings. The `canon records` memory kind stays, so a project can still validate, back up, and migrate a folder it holds. <!-- canon-keep-retired -->
+
+An installed target keeps its `.canon/memory/` folder and the memory arms of its seeded `records-index.sh` and `standards-audit.sh` hooks, since `canon claude sync` writes only a seed a target lacks. Both are inert: nothing writes the folder, and the hooks match no file. `canon gov sync` removes the installed `603-memory` rule and the generated `memory` standard rule.
+
 Two of those files run rather than sit there. `.husky/post-merge` runs the `canon hooks post-merge` verb, so a stale copy of the hook calls a binary that may lack it, and `.claude/hooks/pr-create-log.sh` hands a session a message naming a skill, so a stale copy tells someone to invoke something that no longer exists. A copy older than `git-pr`'s move to REST also matches only `gh pr create`, so it stays silent on every pull request `git-pr` opens. A rule under `.claude/rules/canon/core/` names skills too, though a rule is read rather than run.
 
 Resync what the toolkit owns, then sweep what the project wrote:
@@ -109,3 +115,21 @@ The walk checks both `.claude/snippets` and a root `snippets/`, since a toolkit
 - `project` is content the project wrote under the same name, which the retirement does not reach, so leave it alone
 
 The walk reads the toolkit's own history, so it needs a cloned toolkit. Installed from the registry it reports `historyUnavailable` and names nothing, so check for `.claude/snippets/` and a root `snippets/` by hand there, and treat what you find as `unattributed`.
+
+## Keep or delete the wireframes folder, your call
+
+The toolkit retired the wireframes record. Its standard, its generated rule, its seeded folder, and the `@canon/wireframes/index.md` import in the seed `CLAUDE.md` no longer ship, and no skill reads or writes `canon/wireframes/` any more. The canvas holds visual direction instead.
+
+A project scaffolded earlier keeps what it already holds, and nothing deletes it:
+
+- `canon/wireframes/` stays yours, unaudited and unreferenced by any skill. Keep it as plain notes or delete it.
+- The `@canon/wireframes/index.md` line in your `CLAUDE.md` stays until you remove it, since `canon claude sync` reports the seed `CLAUDE.md` rather than rewriting a file you own. Delete the line when you delete the folder, because an import of a missing file reads as a broken pointer.
+- `.claude/rules/canon/standards/wireframes.md` leaves on the next `canon gov sync`, which deletes a held copy of a rule the toolkit no longer ships.
+
+A `## States` table under `canon/wireframes/` is no longer checked against evidence folders, so `canon context audit --gate` passes without reading the folder.
+
+## Move decisions out of a held architecture record, once
+
+The toolkit stopped seeding a `canon/ARCHITECTURE.md`, stopped gating its caps, and retired the `architecture` standard and the rule generated from it. A project scaffolded earlier may hold the file and import it from `CLAUDE.md`. Both stay, since the record is project prose now and nothing syncs or deletes it. `canon gov sync` removes the generated rule, and `canon context audit` no longer reports the record or its caps.
+
+Decide what to do with the file yourself, since where a decision belongs takes judgment no sync has. A decision about how one domain is built goes to the `canon/context/` entry of the domain it constrains, under that entry's `## Decisions`. Once the file is empty, delete it and its `@canon/ARCHITECTURE.md` line in `CLAUDE.md`.

package/docs/target/projects.md

@@ -61,27 +61,25 @@ The chain is:
 - The `verify` phase runs the installed `package.json` scripts (lint, typecheck, check, test, build) and reports pass or fail
 - The `indexes` phase bootstraps the `index.md` system over the project's own documentation folders, confirming candidate folders with the operator rather than running unattended
 
-The chain stops at the project edge. `repo-metadata` and `git-commit` also ship, reaching a remote and the project's history respectively, and neither runs as part of it. The chain serves a fresh scaffold and names a destination for the three states it does not. An existing project goes to `canon:canon-operator`, which reads what the project already carries before naming a per-domain command. An install wanting the Claude layer without the tooling chain runs `canon claude init` for the seed docs and then `canon:target-setup indexes` for the index system. A language the toolkit ships no stack for is the one of the three the chain still runs for, on `base`, with the fallback marked in the preview so it can be declined there.
+The chain stops at the project edge. `git-commit` also ships, reaching the project's history, and does not run as part of it. The chain serves a fresh scaffold and names a destination for the three states it does not. An existing project goes to `canon:target-check`, which reports what the project already carries against what the toolkit ships before anything is repaired. An install wanting the Claude layer without the tooling chain runs `canon claude init` for the seed docs and then `canon:target-setup indexes` for the index system. A language the toolkit ships no stack for is the one of the three the chain still runs for, on `base`, with the fallback marked in the preview so it can be declined there.
 
 Run `canon:target-setup verify deep` by hand once the default depth passes, for the heavier server smoke, end-to-end, and screenshot pass, since the same flakiness reasons that keep those stages out of the default depth keep them out of this unattended chain too.
 
-Keep the `## Scripts` table in `canon/context/development.md` current as scripts are added. Base tooling seeds that entry with the commands it installs, and each stack reference extends the table. `project-commands` reads it to start the app or run a check on request, so a command missing from the table cannot be run that way. A project whose entry outgrew one file and split into `canon/context/development/` keeps the table in `overview.md`, which is where the skill looks next. <!-- audit-ignore-citations: canon/context/development.md -->
+Keep the `## Scripts` table in `canon/context/development.md` current as scripts are added. Base tooling seeds that entry with the commands it installs, and each stack reference extends the table. A session reads it to start the app or run a check on request, so a command missing from the table cannot be found that way. A project whose entry outgrew one file and split into `canon/context/development/` keeps the table in `overview.md`, which is where the skill looks next. <!-- audit-ignore-citations: canon/context/development.md -->
 
 ### From scaffold to first feature
 
 Scaffold installs tooling and seeds. It does not fill the planning docs or the design system. Complete those before the first feature session:
 
-1. Fill `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md`. The seed provides the files, the scope and decisions are yours to write. Each seed states its own caps, 12 decisions of at most 150 words and 6 risk bullets for the architecture record and 600 words for the requirements, and `canon context audit` gates on them. Edit a number in the record to loosen it.
-2. For a UI project, invoke `canon:design-extract` to draft `canon/DESIGN.md`. With no UI code yet it takes the greenfield path and proposes tokens from the requirements and a `## Personality` section. Skip for non-UI projects.
-3. Optionally invoke `canon:draft-figure` naming an architecture view, such as system context or components, and the document it belongs in. It draws the view from the architecture and the requirements and renders it to verify the layout, which downloads the Mermaid CLI on first use and takes about 15 seconds.
+1. Fill `canon/REQUIREMENTS.md`. The seed asks for the problem in one line, then goals and non-goals, and the scope is yours to write. The seed states its own cap of 600 words, and `canon context audit` gates on it. Edit the number in the record to loosen it. A decision about how the project is built goes in the `canon/context/` entry of the domain it constrains.
+2. For a UI project, write `canon/DESIGN.md` from the seed template, or work the direction out with `canon:canvas` and carry the pick in. Skip for non-UI projects.
+3. Optionally invoke `canon:draft-figure` naming an architecture view, such as system context or components, and the document it belongs in. It draws the view from the context index, the folder layout, and the requirements and renders it to verify the layout, which downloads the Mermaid CLI on first use and takes about 15 seconds.
 4. Start the feature loop. See [AI workflow](../workflow/ai-workflow.md) for the per-feature sequence.
 
 A machine without a renderer still gets the figure and is told which check was skipped.
 
 Nothing watches a figure once it is drawn. Run `canon:draft-figure` again when the code a view is drawn from moves.
 
-`canon/ARCHITECTURE.md` is watched where a figure is not. `canon:context-fold` anchors a decision it amends to the paths that decision cites, and reports an anchored decision whose cited path the branch touched.
-
 ### Stack decision
 
 The default path is `base`. `canon init` on `base` installs base tooling configs, Claude seeds, and the `canon`, `claude`, `tooling`, and `writing` governance rule groups, and scaffolds an empty `.claude/wiki/`. Most projects need nothing more.

package/docs/target/scenarios.md

@@ -17,7 +17,7 @@ claude
 
 In the session, invoke `canon:target-setup`. The skill detects no framework and resolves tooling to `base` and governance to `base`. The preview marks both stacks as fallbacks, since neither came from a match, then the chain runs `canon init`.
 
-Ongoing: run `canon sync --check .` to see what has drifted, then invoke `canon:seed-sync` for seed drift or `canon sync .` for a catch-all refresh.
+Ongoing: run `canon sync --check .` to see what has drifted, then merge seed drift by hand against the toolkit copy, or run `canon sync .` for a catch-all refresh.
 
 ## Web application
 
@@ -31,7 +31,7 @@ Invoke `canon:target-setup`. The skill reads `package.json` and the Vite config,
 Ongoing maintenance:
 
 - What has drifted: `canon sync --check .`
-- Seed drift: invoke `canon:seed-sync`
+- Seed drift: merge by hand against the toolkit copy
 - Catch-all sync: `canon sync .`
 - Governance rule refresh only: `canon gov sync .`
 - Layer a new rule on top, for example `260-shadcn` after adopting shadcn: `canon gov install react --add 260-shadcn .`

package/docs/target/sync.md

@@ -20,7 +20,7 @@ The report opens by naming the binary running it. The installed version reads ag
 
 ### Then the causes
 
-A `stale` file still matches what the toolkit installed, so the update is mechanical. A `customized` file carries local edits, so taking the upstream version is a decision and `canon:seed-sync` is the tool for it. A `stranded` file sits where an older toolkit installed it and the toolkit has since moved, which is a relocation the report names but no command runs. A `retired` rule is one under `.claude/rules/canon/` the toolkit no longer ships, and the next `canon gov sync` deletes it. A `renamed` rule is one the toolkit now ships under a new name, and the next sync installs the new name and deletes the old file.
+A `stale` file still matches what the toolkit installed, so the update is mechanical. A `customized` file carries local edits, so taking the upstream version is a decision made by hand against the toolkit copy. A `stranded` file sits where an older toolkit installed it and the toolkit has since moved, which is a relocation the report names but no command runs. A `retired` rule is one under `.claude/rules/canon/` the toolkit no longer ships, and the next `canon gov sync` deletes it. A `renamed` rule is one the toolkit now ships under a new name, and the next sync installs the new name and deletes the old file.
 
 That attribution comes from `canon/config/config.json`, which every install and sync now writes, falling back to `.claude/canon/config.json` for a target stamped before that move. A target stamped before that path shipped is read from the retired `.claude/canon.json` instead, reported rather than migrated. Governance records a hash per installed file, plus the stack `canon gov install` was given, and tooling records the stack chain it resolved instead of any file hash, since its install runs no per-file walk to attribute.
 
@@ -28,7 +28,7 @@ Each domain holds its own toolkit commit, so syncing governance today does not m
 
 A project that has never synced under a toolkit new enough to write a stamp falls back to the toolkit's own git history. Installed content matching any version that history published proves the file untouched, so it reports `stale` naming the commit it came from, and content matching no published version stays `drifted`. That fallback needs the toolkit as a git checkout. Installed from the registry it ships source without history, and the report says attribution was unavailable rather than reading every file as a local edit.
 
-Further causes sit outside the per-domain scan, each naming something that walk cannot see. A seed the project edited is reported under `seeds` and reconciled with `canon:seed-sync`, since no sync command touches a seed. A file a newer seed folder replaced is reported under `superseded`, such as `.claude/TASKS.md` against the `.canon/tasks/` that now ships, and nothing moves it because the content is the project's own. A domain sitting at the root layout with nothing under `.claude/` is reported under `unmigrated`, and no command moves it either. The project moves the content itself. A surface still at its `.claude/` spelling with nothing under `canon/`, such as `.claude/REQUIREMENTS.md`, is reported under `unmovedSurfaces`, since rules glob the `canon/` spelling alone, and `canon migrate surface-roots` moves it. <!-- canon-keep-surface-root -->
+Further causes sit outside the per-domain scan, each naming something that walk cannot see. A seed the project edited is reported under `seeds` and merged by hand, since no sync command touches a seed. A file a newer seed folder replaced is reported under `superseded`, such as `.claude/TASKS.md` against the `.canon/tasks/` that now ships, and nothing moves it because the content is the project's own. A domain sitting at the root layout with nothing under `.claude/` is reported under `unmigrated`, and no command moves it either. The project moves the content itself. A surface still at its `.claude/` spelling with nothing under `canon/`, such as `.claude/REQUIREMENTS.md`, is reported under `unmovedSurfaces`, since rules glob the `canon/` spelling alone, and `canon migrate surface-roots` moves it. <!-- canon-keep-surface-root -->
 
 `unmigrated` currently names no domain, since standards and snippets are the two the toolkit ever installed at the project root, standards closed its install channel, and snippets retired outright. A target still holding a root `standards/` folder from an older toolkit is carrying its own authoring surface now, not an unfinished install, and nothing proposes moving it. A leftover `.claude/snippets/` reports under `reverse` below instead.
 
@@ -76,7 +76,7 @@ Standards take no part in that run. Nothing installed them, so there is no copy
 
 ## Targeted
 
-- Claude seed docs such as `CLAUDE.md` and `canon/REQUIREMENTS.md`: invoke `canon:seed-sync`. The skill splits each file into a preamble (between the H1 and the first H2) plus one part per `##` section, then diffs part by part and proposes per-part edits. User customizations are preserved.
+- Claude seed docs such as `CLAUDE.md` and `canon/REQUIREMENTS.md`: merge by hand against the toolkit copy, section by section, keeping the project's customizations. A `stale` seed is safe to take whole.
 - Governance rules already installed: `canon gov sync <path>` diffs and applies, and never adds new rules. A rule your recorded stack lists reports as `missing` instead.
 - Tooling configs and seeds: `canon tooling <stack> <path>` overwrites golden configs and merges seeds
 - Reference docs for a stack: `canon tooling reference <stack>` reads and never writes, so there is nothing to sync

package/docs/workflow/ai-workflow.md

@@ -16,10 +16,8 @@ Project docs split across three roots at the project root. What the project auth
 
 ```plaintext
 canon/
-├── REQUIREMENTS.md  ← goals, non-goals, MVP scope
-├── ARCHITECTURE.md  ← technical design decisions
+├── REQUIREMENTS.md  ← problem, goals, non-goals
 ├── DESIGN.md        ← visual intent and token decisions (UI projects)
-├── wireframes/      ← regions, states, UI copy, and interaction rules (UI projects)
 └── context/         ← per-domain narrative loaded on demand via index.md
 
 .claude/
@@ -28,13 +26,12 @@ canon/
 .canon/
 ├── tasks/           ← one file per task with a generated index.md, local scratch
 ├── plans/           ← one plan per feature, archived inside itself once it ships
-├── memory/          ← durable session facts no context entry owns
 └── tmp/             ← deletable scratch, safe to remove without loss
 ```
 
-A project scaffolded before the move keeps its records under `.claude/`, and every command reads either root. `canon migrate records` moves one project across and repoints what cites it, and `canon migrate record-tree` follows it to reach the citations inside the records themselves, which the first verb passes over because it enumerates through git. A project scaffolded before the surface move keeps its context, wireframes, and loose documents under `.claude/` the same way, and `canon migrate surface-roots` moves those to `canon/` with the history following each file.
+A project scaffolded before the move keeps its records under `.claude/`, and every command reads either root. `canon migrate records` moves one project across and repoints what cites it, and `canon migrate record-tree` follows it to reach the citations inside the records themselves, which the first verb passes over because it enumerates through git. A project scaffolded before the surface move keeps its context and loose documents under `.claude/` the same way, and `canon migrate surface-roots` moves those to `canon/` with the history following each file.
 
-Three tiers of context load with different cost: always-loaded (root `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`), path-scoped lazy (`.claude/rules/<scope>.md` with `paths:` glob), and on-demand lookup (`canon/context/<domain>.md`, or `canon/context/<domain>/` once a domain outgrows one file, discovered via `canon/context/index.md`). See [the context model](../../canon/context/context-model/overview.md) for the full picture.
+Three tiers of context load with different cost: always-loaded (root `CLAUDE.md` and `canon/REQUIREMENTS.md`), path-scoped lazy (`.claude/rules/<scope>.md` with `paths:` glob), and on-demand lookup (`canon/context/<domain>.md`, or `canon/context/<domain>/` once a domain outgrows one file, discovered via `canon/context/index.md`). See [the context model](../../canon/context/context-model/overview.md) for the full picture.
 
 Run `canon init` to seed the `.claude/` directory, a root `CLAUDE.md` file, and `.claude/rules/` in one pass. `canon init` chains claude init and governance install. Claude Code auto-loads every file in `.claude/rules/` at session start, applying always-on rules unconditionally and path-scoped rules to files matching their `paths:` glob.
 
@@ -70,10 +67,8 @@ What a spike leaves behind splits on whether a later reader needs the file to ch
 
 #### Session 2
 
-Start a fresh Claude Code session. The diff is sufficient context for both review and ship.
+Start a fresh Claude Code session. The diff is sufficient context for ship.
 
-- Invoke `canon:review-branch` to review all changes since main and output a findings report
-- Fix any valid findings
 - Invoke `canon:git-ship` to run the project's verify commands, sync docs, commit by concern, rename branch, and open PR
 
 ### Parallel features
@@ -82,40 +77,14 @@ When features are independent, run them in parallel, one worktree and one sessio
 
 ### Autonomous ship
 
-For features on a mature stack, chain the post-plan pipeline in one session. Approve the plan, invoke `canon:auto-ship`, and the skill runs implement → verify → review → ship sequentially.
+For features on a mature stack, chain the post-plan pipeline in one session. Approve the plan, invoke `canon:auto-ship`, and the skill runs implement → verify → ship sequentially.
 
 - Use when the plan is tight and the stack has real verify commands and test coverage
-- Autoship stops on: verify failure after one fix attempt, an inherited review finding above minor, no diff baseline resolving against `main`, an empty changed-file list, or hook failure
+- Autoship stops on: verify failure after one fix attempt, or hook failure
 - A produced UI checklist does not stop it. The checklist rides to the draft pull request's evidence comment, and the closing block names how many visual boxes are still unchecked and who owes them
 - Every stop leaves recoverable state. Fix and resume with `/git-ship`
 - Skip autoship for auth, migrations, security-sensitive changes, or work where the plan itself is uncertain
 
-#### What reaches review
-
-Review findings split by origin before severity is read. One the branch inherited stops the chain, and one the run itself caused is repaired in place at any severity, bounded at a single pass. Origin is causation rather than authorship, so staleness the run induced in a file it never opened counts as its own and the plan's file list bounds what it builds rather than what it may repair.
-
-Review is skipped when the diff is prose that only informs: every changed file matches `*.md` or `*.txt`, and none sits under a behavior path. Behavior paths cover skills and rules in both the authoring and the installed spelling, so the list matches whether a repository authors those surfaces or consumed them from the toolkit. Standards, `internal/`, and `tooling/` carry the authoring spelling alone, since none of the three reaches a session through a `.claude/` copy, and root `CLAUDE.md` is named as a file because a path prefix reaches nothing sitting in no folder.
-
-Markdown under one states what an agent does, so a branch touching it reaches review while `docs/` and `wiki/` still skip and stay gated by `docs-sync`, `canon markdown audit`, and pre-push hooks.
-
-An empty changed-file list stops the chain rather than counting as prose-only. The filename test passes vacuously on an empty set, which routed a branch past review instead of through it.
-
-`canon autoship classify` answers that decision now, and the chain branches on the record it returns rather than on a session applying the list above. Three runs read past the list while it was prose, the last of them a driven arm that staged a file the list names and shipped a draft pull request with no review. The verb takes the names the chain already computed, so no second diff baseline resolves, and it names the file and the test that decided. [Review classification](../agents/review-classification.md) carries the record shape and the exit codes.
-
-The list stays written in the skill body as the fallback for a target whose installed CLI predates the verb, since the two ship at different speeds. That fallback is never a skip: failing open is the defect the verb closes, so an absent subcommand routes to review rather than past it.
-
-#### Memory in the chain
-
-`git-ship` runs its verify gate and then opens on `memory-capture`, which sends what the session learned to the surface that owns it. `autoship` reaches the same step by invoking that skill at its Step 8 rather than restating the order. A fact about a domain carrying an entry in `canon/context/index.md` is routed to that entry, and `context-fold` folds it in on the next step, so it ships in the same pull request. Anything no entry owns stays a file in `.canon/memory/`.
-
-Capture leads rather than trails because a routed fact edits a tracked file, which has to reach the branch before the commit steps run.
-
-The chain ends at capture, and review is run on its own. Capture closes with a line naming `/canon:memory-review` once `canon records stale memory` counts 25 or more entries due, and says nothing below that.
-
-Run `memory-review` standalone to curate the pen a batch at a time. Each pass takes the first 25 due entries in the order the stale verb reports, opening on those citing a path the tree no longer holds, and a named list overrides that order. An entry it retires moves to `.canon/memory/archive/` rather than being deleted, since a bulk pass has no undo. An entry it keeps is stamped with a `reviewed` date, which takes it out of the queue for 30 days.
-
-The receipt is collected once every item on it has been decided, and it survives untouched while any item is still pending. Whichever runs first takes it: Apply collects the receipt it has resolved, and `context-fold` scans the folder on every shipped branch for one an earlier session left behind. Before the file goes, each declined item is folded into the entry it was about, since a promotion survives in its target and in git while a decline is recorded nowhere else. `canon standards memory` states what a fold writes and which entry types take one.
-
 ### UI polish
 
 Verify the change manually in the browser. Invoke `canon:ui-checklist` if you need a written list of what to look at. For the fix itself, describe the change in Claude Code directly.
@@ -128,7 +97,7 @@ Verify the change manually in the browser. Invoke `canon:ui-checklist` if you ne
 
 ### Review
 
-Invoke `canon:review-branch` at the start of session 2. It reads all changed files and outputs a findings report. Fix valid findings before invoking `canon:git-ship`. If nothing is valid, skip directly to ship.
+Review runs on the pull request. An independent session invokes `canon:review-pr` once `canon:git-ship` has opened it, and the worker answers what it posts with `canon:review-address`.
 
 ### UI-heavy project
 

package/docs/workflow/index.md

@@ -17,5 +17,5 @@ How a person and their agents run a feature, from the design tier through the pa
 - [Parallel features](parallel-features.md): Run independent features in parallel worktrees, with the records and board every session shares
 - [Skill map on request](skill-map-on-request.md): When to reach for the plugin skills that serve a request rather than a moment in a project's life
 - [Skill map](skill-map.md): When to reach for each plugin skill, grouped by the moment a project meets it
-- [Visual design workflow](visual-design-workflow.md): Tiered guide for design and wireframe authoring with Claude Code
+- [Visual design workflow](visual-design-workflow.md): Tiered guide for design authoring with Claude Code
 - [Zshrc aliases for Claude Code](zshrc-aliases.md): Shell aliases that shorten common Claude Code invocations

package/docs/workflow/operating-model.md

@@ -82,17 +82,17 @@ PR. The merge stays a manual human gate. Reliability comes from the plan being
 complete enough that the cold session does not come back with questions, and
 from merging promptly so the next PR does not rot against a moving main.
 
-## Two review layers
+## The review layer
 
-The worker's self-review and the orchestrator's review are not the same pass run
-twice. They differ by vantage.
+The worker's chain carries no review step. The session that wrote the code is
+structurally blind to its own misreadings, because the same misreading wrote
+both the code and any review of it, so the first review a change gets is the
+orchestrator's.
 
-- Worker self-review, inside `auto-ship`: the session that wrote the code. Its job is "did I build the plan and does it pass?" Mechanical, and structurally blind to its own misreadings, because the same misreading wrote both the code and the review. This is the green gate that decides whether the PR opens.
+- Worker gate, inside `auto-ship`: the session that wrote the code. Its job is "did I build the plan and does it pass?" The verify commands and the test order read decide whether the PR opens, and the draft mark holds the merge.
 - Orchestrator review, via `review-pr`: a fresh session with cross-feature context (the board, a sibling PR in flight, a downstream contract). Its job is "is this right and does it fit?" It can question the plan itself. This is the merge gate.
 
-They collide only if the worker also runs a deep pass. Keep the worker's review
-light and let the orchestrator own the deep, independent one. The human read at
-merge is the final gate. No layer repeats another.
+The human read at merge is the final gate. No layer repeats another.
 
 The orchestrator's pass also reads the pull request body against itself, which is
 a vantage the worker never has. This repository squash-merges, so the body
@@ -190,7 +190,7 @@ coordination costs more than the change it was too small.
 
 Two tiers hold work at different altitudes.
 
-- Tasks (`.canon/tasks/`): the active few pulled into the current turn, one file each. Gitignored, high churn. Shape governed by `standards/tasks.md`. `priority.md` beside them carries execution order, and `backlog.md` carries what nobody is scheduling, both shaped by `standards/board.md`.
+- Tasks (`.canon/tasks/`): the active few pulled into the current turn, one file each. Gitignored, high churn. Shape governed by `canon standards tasks`. `priority.md` beside them carries execution order, and `backlog.md` carries what nobody is scheduling, both shaped by `canon standards board`.
 - Edits: a few lines, done immediately with no ceremony.
 
 Nothing above these sequences work into versions. Scope is stated in

package/docs/workflow/parallel-features.md

@@ -12,7 +12,7 @@ When features are independent, run them in parallel instead of sequentially. Use
 
 - Create a worktree per feature, then start a Claude Code session in each
 - Invoke `canon:plan-feature` in each session. Plans land at the main worktree root as `.canon/plans/feature-<slug>.md`, one per feature, no collisions. Small features stay in chat and skip the file.
-- Implement, verify, and review each feature independently. `review-branch` writes a per-branch report at the main worktree root (`review/branch-<slug>.md`), and `ui-checklist` writes a per-branch checklist handoff there too (`tmp/handoff/ui-checklist/<slug>.md`) that `git-pr` posts to the pull request and removes, so parallel sessions do not overwrite each other. The slug is the branch name with any leading type segment dropped, so `feat/jwt-expiration` and the plan at `feature-jwt-expiration.md` meet on one name
+- Implement, verify, and review each feature independently. `ui-checklist` writes a per-branch checklist handoff there too (`tmp/handoff/ui-checklist/<slug>.md`) that `git-pr` posts to the pull request and removes, so parallel sessions do not overwrite each other. The slug is the branch name with any leading type segment dropped, so `feat/jwt-expiration` and the plan at `feature-jwt-expiration.md` meet on one name
 - Ship each worktree separately with `canon:git-ship`
 - For full autonomy per worktree, invoke `canon:auto-ship` instead of the manual chain. Approve the plan, walk away, come back to a pull request the chain marked as a draft and then read the flag back on. The mark says the work has had no review yet, and it holds no window, since readying a pull request to merge lifts it directly, an act reserved to the operator or to the controlling session that closed the review.
 
@@ -32,9 +32,9 @@ A constraint naming a track in flight carries the same problem past the handoff,
 
 ## Records at the main root
 
-`.canon/plans/`, `.canon/review/`, and `.canon/memory/` all resolve at the main worktree root, so artifacts created in any session are visible from any sibling worktree. A session inside a worktree reads them directly, since the file-editing tools refuse a main-root path but `Read` resolves normally. It writes a whole file through the shell and makes a change inside an existing file through a `canon` verb, which resolves the main root in-process. See [Claude Code and git worktrees](../../wiki/claude/worktrees.md) for why the tool refuses the write, and the fan-out section below for the domain-level guidance.
+`.canon/plans/` and `.canon/review/` both resolve at the main worktree root, so artifacts created in any session are visible from any sibling worktree. A session inside a worktree reads them directly, since the file-editing tools refuse a main-root path but `Read` resolves normally. It writes a whole file through the shell and makes a change inside an existing file through a `canon` verb, which resolves the main root in-process. See [Claude Code and git worktrees](../../wiki/claude/worktrees.md) for why the tool refuses the write, and the fan-out section below for the domain-level guidance.
 
-The plan's shape is fixed by `standards/plan.md`: the section list, the filename, and the contract its questions keep. Its lifecycle, from the session that writes it to the archive, is `standards/plan-lifecycle.md`. Every question carries a `- Suggested:` line and an empty `- Answer:` slot, and a blank answer accepts the suggestion at execution time. That default is what makes a plan decision-ready in one pass, and it is the opposite of the contract an intake folder keeps, where an empty slot means nobody reached the item.
+The plan's shape is fixed by `claude/skills/plan-feature/references/plan.md`: the section list, the filename, and the contract its questions keep. Its lifecycle, from the session that writes it to the archive, is `claude/skills/plan-feature/references/plan-lifecycle.md`. Every question carries a `- Suggested:` line and an empty `- Answer:` slot, and a blank answer accepts the suggestion at execution time. That default is what makes a plan decision-ready in one pass, and it is the opposite of the contract an intake folder keeps, where an empty slot means nobody reached the item.
 
 An execution that picks other than the suggestion rewrites the `- Suggested:` line as `overridden at execution to <pick>,` followed by the measurement that moved it, and leaves the slot blank. That fixed phrase is how a reader of the archived plan tells an override from a suggestion the execution accepted, since an authored suggestion often carries a number of its own. The same deviation takes one line in the open task's `## Findings`, which is the register that survives the plan being archived. A deviation from a question somebody already answered goes back to whoever answered it instead, since a filled slot is a decision already made.
 
@@ -42,7 +42,7 @@ An execution that picks other than the suggestion rewrites the `- Suggested:` li
 
 `canon records push` carries these folders off the disk they live on, and `canon records pull` brings them back. Every top-level entry under `.canon/` is backed except `tmp`, `ordinal-locks`, and `.records.git`, so a folder added later enters the payload on its own rather than waiting on a name written into a list. Push names each folder it carries the first time it sees it, which is what keeps a stray folder visible instead of silently entering the payload. It refuses the whole push, naming each path, when a new or changed file is over 25 MB or carries a credential `canon secrets scan` would report. The history lives in a second git directory at `.canon/.records.git` with `.canon/` as its work tree, so every path a task file cites stays where it is.
 
-A person points it at a private repository once and both verbs refuse until they have, and `push` refuses when that origin is also a remote of the project, since the payload is the memory pen and the groundwork trails. `.husky/post-merge` runs the push after its archive loop, on every merge rather than only on one that closed a task. See [records push](../agents/records-push.md) for the refusal table.
+A person points it at a private repository once and both verbs refuse until they have, and `push` refuses when that origin is also a remote of the project, since the payload is the task board and the groundwork trails. `.husky/post-merge` runs the push after its archive loop, on every merge rather than only on one that closed a task. See [records push](../agents/records-push.md) for the refusal table.
 
 `canon records size` reports what each of these folders holds, heaviest first, along with `.canon/tmp`. Each row carries the file count, the bytes, how many files were written in the last 7 and 30 days, and the dates of the least and most recently written one. Nothing fails on a number, because a record folder has no correct size. What the verb replaces is a reading somebody had to remember to take: the memory pen went from 44 entries to 236 between two counts made by hand a fortnight apart, and nothing reported the rate in between.
 
@@ -52,9 +52,9 @@ A person points it at a private repository once and both verbs refuse until they
 
 A plan that ships is archived, never deleted. `canon tasks archive` moves it to `.canon/plans/archive/` alongside the task it belonged to and retargets that task's `Plan:` line at the new location, so a completed task still leads to the reasoning behind it. An archive sits inside the record folder it archives rather than beside it, so one ignore entry and one backed-folder entry cover a record and everything it has retired. The folder is gitignored, which is why a deleted plan had no recovery path. A plan cited by more than one task stays put until the last of them closes, since moving it early would strand every other pointer.
 
-A branch review report takes the other route and is swept rather than archived. `review-branch` writes it flat into `.canon/review/` as `branch-<slug>.md`, the session addressing it reads it once, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so `context-fold` deletes any report whose branch is gone. The body that writes a report owns how long it lives, which leaves the shipping branch's own report on disk through the run that cites it and collects it a branch later. What that loses is a local-only review on a branch that never opened a pull request, which is why the report says so where a reader meets it.
+An older branch review report takes the other route and is swept rather than archived. It sits flat in `.canon/review/` as `branch-<slug>.md`, the session addressing it read it once, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so `context-fold` deletes any report whose branch is gone. The body that writes a report owns how long it lives, which leaves the shipping branch's own report on disk through the run that cites it and collects it a branch later. What that loses is a local-only review on a branch that never opened a pull request, which is why the report says so where a reader meets it.
 
-`canon:context-fold` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Architecture and design stay session-sourced, because a diff cannot carry a judgment, and an architecture write further needs a folded plan naming the slot decision. The requirements record is never folded. A direction change gets one report line naming `canon:document-health`, which reviews that record only when asked.
+`canon:context-fold` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Decisions and design stay session-sourced, because a diff cannot carry a judgment. The requirements record is never folded. A direction change gets one report line naming `canon:document-health`, which reviews that record only when asked.
 
 ## Shipping a fan-out
 
@@ -81,7 +81,7 @@ Land any in-flight edit to a hotspot on `main` before fanning out where you can.
 
 `.canon/tasks/` is gitignored and resolves at the main worktree root, so every session shares one board. One file per task is what keeps concurrent sessions from overwriting each other, since a gitignored board has no history to recover a lost write from. Its `index.md` is generated by a hook rather than by `bun run check`, because the whole-repo index walk skips gitignored folders.
 
-`.canon/memory/` carries the same arrangement, its own hook regenerating `index.md` from each entry's `title`, `description`, and `category`. A hand-maintained `priority.md` sits beside it carrying execution order and what each task is waiting on, which the alphabetical index cannot express.
+A hand-maintained `priority.md` sits beside the index carrying execution order and what each task is waiting on, which the alphabetical index cannot express.
 
 `canon tasks validate` reads a row against its own table before it reads anything the row claims. A blank or prose line closes the table above it, so a row stranded there is checked against the line behind it rather than parsed as a continuation, and a row that clears that test still has its cell count checked against its header. A `## Needs a plan` row that states its own position, searched for `<ordinal> here` or the bare word `last` anywhere in the cell rather than at its start, is checked against where it actually sits, which is what catches a gap, a duplicate, and a sequence starting somewhere other than first alike.
 

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

@@ -10,32 +10,29 @@ These two groups hold the skills no single moment in a project's life calls for,
 
 ## Generate an artifact on demand
 
-| Skill                     | When to use                                                                                                                                    |
-| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                                               |
-| `canon:create-skill`      | For a new `SKILL.md`                                                                                                                           |
-| `canon:create-standard`   | For a new authoring convention                                                                                                                 |
-| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wireframe surface, wiki reference page, or `README.md`, drafted against the standard for its kind |
-| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                                      |
-| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                                     |
-| `canon:bash-cli-script`   | For a small non-interactive shell wrapper, stopping at 100 lines in favor of TypeScript on Bun                                                 |
-| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                                             |
-| `canon:draft-slides`      | For a deck, drawn as HTML slides in its own folder and rendered to editable PowerPoint                                                         |
-| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                                                  |
-| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                                   |
-| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                                    |
+| Skill                     | When to use                                                                                                                 |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| `canon:create-rule`       | For a project-specific governance rule the toolkit does not ship                                                            |
+| `canon:create-skill`      | For a new `SKILL.md`                                                                                                        |
+| `canon:draft-doc`         | For a brand-new `docs/` page, context entry, wiki reference page, or `README.md`, drafted against the standard for its kind |
+| `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                   |
+| `canon:draft-figure`      | For a hand-drawn figure or an architecture view inside an existing doc, drafted in Mermaid or freehand SVG                  |
+| `canon:ci-workflow`       | For a GitHub Actions workflow file                                                                                          |
+| `canon:draft-slides`      | For a deck, drawn as HTML slides in its own folder and rendered to editable PowerPoint                                      |
+| `canon:draft-screencast`  | For a recording script with beats and defaults already seeded                                                               |
+| `canon:record-screencast` | For recording a screencast draft, then composing the take into a finished mp4 when the draft asks for a wrap                |
+| `canon:draft-identity`    | For a project's logo mark and its social card, drafted through `draft-and-pick`'s pick loop                                 |
 
 ## Answer a question at any point
 
 | Skill                       | When to use                                                                                                                                                            |
 | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `canon:canon-cli`           | Before running an unfamiliar verb, a sync, or an install, to learn which command to run, which reference doc covers it, or what it overwrites, merges, or leaves alone |
-| `canon:index-lookup`        | To find where a topic is documented across the tracked `index.md` catalogs                                                                                             |
 | `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                                                               |
 | `canon:read-frames`         | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right                                       |
 | `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
+| `canon:markdown-craft`      | Before a substantial markdown edit, for the format and structure rules and the audit that follows                                                                      |
 | `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                                                      |
-| `canon:restate-plainly`     | When an answer or a document has to be read again in plain words                                                                                                       |
 
 Every row answers a question rather than marking a point in a project's life, so filing one under a phase on the [skill map](skill-map.md) would send a reader to the wrong group.
 

package/docs/workflow/skill-map.md

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