@erclx/canon 5.30.0 → 5.32.0

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

@@ -9,22 +9,21 @@ description: Why resuming reads the handoff before the board, reads an index bef
 
 Without this skill, a session picking up old work reconstructs state from the git log, which records what shipped and not what is queued, so finished work reads as pending and the actual next item goes unmentioned. The alternative failure is worse for a different reason. A session that reads every task file and every plan to be thorough spends the context the work needs before the work starts, and the summary arrives in a session with no room left to act on it.
 
-A compaction keeps conclusions and drops the reasoning that produced them, and the previous session can write that reasoning to a handoff before it goes. A resume that reads the board, the plans, and the memory index alone walks past that file, so the one artifact written to survive the compaction reaches nobody and the next session re-derives what it holds.
+A compaction keeps conclusions and drops the reasoning that produced them, and the previous session can write that reasoning to a handoff before it goes. A resume that reads the board and the plans alone walks past that file, so the one artifact written to survive the compaction reaches nobody and the next session re-derives what it holds.
 
 The task index is a folder catalog rather than a task filter, so it carries a row for the ordering file and one for every handoff on the board. A session reporting each row as a backlog item queues work nobody filed, and the count grows with every session that ever wrote a handoff.
 
 From a linked worktree the shared scratch folders resolve against the worktree rather than the main root, where they are empty. That reports no tracked work on a repository carrying a full backlog, and the report is indistinguishable from the true empty case.
 
-A resume is a read, and a session that treats it as a cleanup pass offers to archive finished entries or refresh a memory it decided was stale. Both change tracked state on the strength of a summary the user has not confirmed yet.
+A resume is a read, and a session that treats it as a cleanup pass offers to archive finished entries or rewrite a plan it decided was stale. Both change tracked state on the strength of a summary the user has not confirmed yet.
 
 ## Must
 
 - Read the newest handoff before the board, and report what it carries attributed to its writer
-- Resolve the handoff, plans, memory, and tasks folders at the main worktree root
+- Resolve the handoff, plans, and tasks folders at the main worktree root
 - Read the task index before any individual task file, and open only the task files the summary needs
 - Drop the board siblings from the index before reporting it as the backlog, since the catalog filters nothing and carries a row per handoff
 - Preserve the index's order in the report, since the order is the priority
-- Surface only the memory entries that inform the top item
 - Close with one recommendation naming the first item and whether a plan backs it
 
 ## Must not
@@ -33,11 +32,10 @@ A resume is a read, and a session that treats it as a cleanup pass offers to arc
 - Report the absence of a handoff, which is the common case and would train a reader to skip the line on the run where one exists
 - Restate a handoff's counts, sizes, or costs as current. Each was true when written.
 - Offer to remove, archive, or reorder an entry. Resume reports and does not mutate.
-- Update memory, which changes when a recorded fact becomes wrong rather than on a resume
 
 ## Guards
 
-- All four surfaces absent or empty reports no tracked work and stops, rather than inventing a next step from the repository
+- Every surface absent or empty reports no tracked work and stops, rather than inventing a next step from the repository
 - A handoff found beside an empty board recommends what the handoff leaves open, since the guard passes on the handoff alone and the recommendation has no backlog item to name
 
 ## Out of scope

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

@@ -9,18 +9,16 @@ metadata:
 
 ## Step 1: read tracked work
 
-Resolve `.canon/plans/`, `.canon/memory/`, `.canon/compact/`, and `.canon/tasks/` at the main worktree root the way `session-worktree` does.
+Resolve `.canon/plans/`, `.canon/compact/`, and `.canon/tasks/` at the main worktree root the way `session-worktree` does.
 
 Read these in parallel, skipping any that do not exist:
 
-- the newest `.canon/compact/*.md`, then the newest `.canon/tasks/session-*.md`: the handoff a previous session wrote before a compaction. The first is the note `session-compact` writes, and the second is the board-side map per `${CLAUDE_SKILL_DIR}/../../standards/session.md`, which stays readable. Whichever exists leads the report rather than the reads, and both lead it when both exist.
+- the newest `.canon/compact/*.md`, then the newest `.canon/tasks/session-*.md`: the handoff a previous session wrote before a compaction. The first is the note `session-compact` writes, and the second is the board-side map per `${CLAUDE_SKILL_DIR}/../session-map/references/session.md`, which stays readable. Whichever exists leads the report rather than the reads, and both lead it when both exist.
 - `.canon/tasks/index.md`: the folder catalog. Read this before any individual task file, and take the task list from it by dropping the `index`, `priority`, `backlog`, and `session-` rows, which are siblings rather than tasks.
 - `.canon/plans/*.md`: execution detail for in-progress tasks
 
 Then read only the task files the summary needs, typically the top one. Do not read the whole folder.
 
-Once the top task is known, grep `.canon/memory/index.md` for two or three terms from its title and read at most three of the entries whose rows match. Never read the index whole, since a grown pen's index runs to hundreds of rows and the report shows three at most. With no top task, or no row matching, read no memory entry and say nothing about it.
-
 Most projects carry no handoff. Say nothing about its absence, since a line reporting it every run trains a reader to skip the line on the run where a handoff exists.
 
 If the handoff, task, and plan surfaces are all absent or empty, stop: `✅ No tracked work found. Start a new task.`
@@ -35,17 +33,13 @@ Output these sections, omitting the first when no handoff was found:
 
 **Active plans:** one line per file in `.canon/plans/`, linking each to its task file in `.canon/tasks/`. Say "None" if empty.
 
-**Relevant context:** the memory entries Step 1 matched to the top backlog item, three at most. Skip if none matched.
-
 ## Step 3: recommend
 
 End with one line: `Start with: <first Up next item>` and note whether it has a linked plan.
 
 When the board is empty and a handoff was found, name what the handoff leaves open instead: `Start with: <the open thread the handoff names>`. A recommendation slot filled with nothing reads as a failed run, and a handoff on an empty board is the shape a session leaves when it was reasoning rather than shipping.
 
-Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../../standards/plan-lifecycle.md`.
-
-Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `canon/context/`, which `memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
+Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan-lifecycle.md`.
 
 ## Writing the next one
 

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

@@ -1,6 +1,6 @@
 ---
 name: session-worktree
-description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/plan-feature`. Also use when an `Edit` or `Write` to a main-root file such as a plan, a task, or a memory entry was refused for session isolation. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
+description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/plan-feature`. Also use when an `Edit` or `Write` to a main-root file such as a plan, a task, or a review report was refused for session isolation. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
 metadata:
   family: build
 ---

package/claude/skills/session-worktree/references/main-root-writes.md

@@ -3,7 +3,7 @@ title: Main-root write routing
 description: Which tools the isolation refusal covers, the route each kind of main-root write takes, the fallback when a heredoc is refused, and the index cost a shell write carries
 ---
 
-Shared session scratch, being `.canon/plans/`, `.canon/review/`, `.canon/memory/`, and `.canon/tasks/`, lives at the main worktree root. Resolve that root with the first `worktree` entry of `git worktree list --porcelain`, falling back to `pwd` outside a git repository.
+Shared session scratch, being `.canon/plans/`, `.canon/review/`, and `.canon/tasks/`, lives at the main worktree root. Resolve that root with the first `worktree` entry of `git worktree list --porcelain`, falling back to `pwd` outside a git repository.
 
 ## The refusal
 
@@ -21,4 +21,4 @@ Shared session scratch, being `.canon/plans/`, `.canon/review/`, `.canon/memory/
 
 ## The index cost
 
-A shell write skips every `PostToolUse` hook, since those match `Write|Edit|MultiEdit` and never fire on `Bash`. That costs nothing on `.canon/plans/` and `.canon/review/`, which no hook indexes, and costs the generated `index.md` on `.canon/tasks/` and `.canon/memory/`. Regenerate positionally after a shell write there, by an explicit `canon indexes regen` call, unless the verb that made the write already calls it, as `canon tasks archive` does.
+A shell write skips every `PostToolUse` hook, since those match `Write|Edit|MultiEdit` and never fire on `Bash`. That costs nothing on `.canon/plans/` and `.canon/review/`, which no hook indexes, and costs the generated `index.md` on `.canon/tasks/`. Regenerate positionally after a shell write there, by an explicit `canon indexes regen` call, unless the verb that made the write already calls it, as `canon tasks archive` does.

package/claude/skills/systematic-debugging/REQUIREMENT.md

@@ -51,5 +51,4 @@ A stated phase is also one a session can talk itself out of. The reasons it give
 ## Out of scope
 
 - A typo fix and a cause already agreed on, where the phases cost more than they return
-- Reviewing a change for defects it has not yet exhibited: `review-branch`
 - Deciding whether the architecture should change, which the three-attempt stop hands to the user rather than answering

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

@@ -7,7 +7,7 @@ description: What the target check is for, the gap it closes, and the repairing
 
 ## Gap
 
-Without this skill, a session landing in a target project decides for itself what to look at. `canon-rollout` dispatches a worker into each target and gets a pull request out, and nothing told that worker what a target holds against what the toolkit ships, so a wave is only as good as whatever each session happened to examine. Four hand-driven repairs across two waves examined four different sets of surfaces and none of them read the same domain twice.
+Without this skill, a session landing in a target project decides for itself what to look at. An orchestrator dispatches a worker into each target and gets a pull request out, and nothing told that worker what a target holds against what the toolkit ships, so a wave is only as good as whatever each session happened to examine. Four hand-driven repairs across two waves examined four different sets of surfaces and none of them read the same domain twice.
 
 The second half of the gap is silence. A session that runs a verb the target's binary does not carry, or reads a report key that is absent, has no instruction telling it apart from a clean answer, so an unexamined domain reaches the reader as a domain that passed.
 
@@ -32,11 +32,11 @@ The second half of the gap is silence. A session that runs a verb the target's b
 
 - `canon` absent from the path: stop, since no domain can be read
 - No `.claude/` at the working root: stop and name the scaffold command, since nothing is installed to check
-- The working root is the toolkit itself: stop and name `canon-rollout`, since this skill reads what the toolkit installed into rather than the source
+- The working root is the toolkit itself: stop and ask the orchestrator for a worker per repository, since this skill reads what the toolkit installed into rather than the source
 
 ## Out of scope
 
 - Document health, which asks a content question rather than a structural one and takes its own surface
 - Repairing anything a section names. Each routes to the command or skill that owns it.
 - A target's own routes, which `canon inventory` reports as a listing rather than a verdict and which is a fact about the project rather than about what the toolkit ships
-- First-time scaffold, which is `target-setup`, and per-intent routing of a single toolkit operation, which is `canon-operator`
+- First-time scaffold, which is `target-setup`

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

@@ -15,7 +15,7 @@ Six domains carry the report. Five answer from a verb that already exists and th
 
 - `canon` absent from the path: stop. `❌ canon is not on PATH, so no domain can be read.`
 - No `.claude/` directory at the working root: stop. `❌ No .claude/ here, so nothing is installed to check. Run canon init first.`
-- A `claude/skills/` folder at the working root, with no leading dot: stop. `❌ This is the toolkit itself rather than a target. canon-rollout takes a change out to the targets.` A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into.
+- A `claude/skills/` folder at the working root, with no leading dot: stop. `❌ This is the toolkit itself rather than a target. Ask the orchestrator for a worker per repository to take a change out to the targets.` A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into.
 - Run every command under `CANON_NON_INTERACTIVE=1` and prompt at no point. Every caller in the near term is a worker a wave dispatched, with nobody present to answer, so the non-interactive path is the only path rather than a flag a caller remembers.
 - Branch on each record's own fields rather than on an exit status. An operator's shell profile may wrap `canon` in a function whose status comes from a trailing command, which reports every refusal as success.
 

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

@@ -77,7 +77,7 @@ Read `seeds.entries` off the report. Each entry is `matching`, `stale`, `drifted
 - Behind: anything else. Report `stale` and `missing` separately from `drifted`, which means the content matches no version the toolkit ever published, so the project wrote it.
 - Unread: `historyUnavailable` set on `seeds`, which leaves every difference unattributed. Say so rather than reporting a file as untouched.
 
-Routes to `seed-sync`, which proposes per-section edits without overwriting a customization. It is a proposal rather than a write, which is why a `drifted` `CLAUDE.md` routes there rather than to a sync.
+Report a `stale` seed as safe to take whole and a `drifted` one as a hand merge against the toolkit copy, since a sync command would overwrite the project's edits.
 
 A seed entry matching says the file's bytes match the shipped seed. It says nothing about whether the harness those files configure is wired, which is the next domain.
 

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

@@ -36,12 +36,12 @@ two copies could disagree with nothing comparing them.
 
 ## Must not
 
-- Guard against clobbering an existing project's configs, which routes to `canon-operator` instead
+- Guard against clobbering an existing project's configs, which `canon sync` covers on an existing project and `target-check` reports on
 - Author a rule or a stack in the target project on the fly
 - Generate a config the tooling stack ships as a golden file
 - Install Claude Code plugins, which provision a machine rather than a project
 - Fail an unattended scaffold on a server start, which is flaky enough to be a depth the operator asks for
-- Survive as a skill nothing invokes but a person typing its name. `canon-operator` hands first-time scaffold here and the target projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
+- Survive as a skill nothing invokes but a person typing its name. The target projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
 
 ## Guards
 
@@ -51,6 +51,6 @@ two copies could disagree with nothing comparing them.
 
 ## Out of scope
 
-- An existing project's per-domain drift, which `canon-operator` diagnoses and `target-check` reports
-- Reaching a remote or the project's history, which `repo-metadata` and `git-commit` own
+- An existing project's per-domain drift, which `target-check` reports
+- Reaching the project's history, which `git-commit` owns
 - Provisioning Claude Code plugins on a machine, which the `claude plugin` CLI does directly

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

@@ -1,6 +1,6 @@
 ---
 name: target-setup
-description: Gets a project onto the toolkit. Detects the stack, resolves per-domain arguments, previews the chain, runs `canon init`, then verifies at a stated depth and bootstraps the `index.md` system. Use when asked to "set up this project", "init this project", "bootstrap the toolkit", "install governance", "install gov rules", "set up indexes", "verify the scaffold", "run the smoke tests", or "one-shot install". Assumes the `canon` CLI is on PATH. Do NOT use on a project that already carries the toolkit, which is `canon-operator`, or to report per-domain drift without repairing it, which is `target-check`.
+description: Gets a project onto the toolkit. Detects the stack, resolves per-domain arguments, previews the chain, runs `canon init`, then verifies at a stated depth and bootstraps the `index.md` system. Use when asked to "set up this project", "init this project", "bootstrap the toolkit", "install governance", "install gov rules", "set up indexes", "verify the scaffold", "run the smoke tests", or "one-shot install". Assumes the `canon` CLI is on PATH. Do NOT use on a project that already carries the toolkit, or to report per-domain drift without repairing it, which is `target-check`.
 metadata:
   family: setup
 ---
@@ -50,14 +50,14 @@ else. Do not pause for a separate confirmation.
 ## Scope
 
 - This skill and `canon init` run once on a fresh scaffold, never on an existing project. They do not guard against clobbering existing configs. When tempted to add guards, mode switches, or an existing-project branch, stop. Extend the per-domain `canon <domain> install` or `canon sync` paths instead.
-- 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 here.
+- The chain stops at the project edge. `git-commit` also ships, reaching the project's history, and does not run here.
 - Claude Code plugins are a machine concern rather than a project one, so no phase here installs them. Install them with `claude plugin install <name> --scope user`, which applies in every project on the machine and is copied into none.
 
 ## Declined states
 
 Three states reach this skill that the chain does not serve. Name the destination for each, so the refusal routes rather than ends. The first two stop the chain outright and the third runs it on a default the person may not want.
 
-- **An existing project.** Stop and hand off to `canon-operator`. It reads what the target already carries before it names a command, which this chain never does, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
+- **An existing project.** Stop and hand off to `target-check`, which reports what the target already carries before anything is repaired. This chain never reads that, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
 - **An install wanting the `.claude/` folder alone.** Stop. Run `canon claude init` for the seed docs, then run the `indexes` phase over the project's own documentation folders. Neither needs the tooling sync the `install` phase runs.
 - **A language the toolkit carries no stack for.** The chain still runs, on `base`, with the fallback marked in the preview. A project that wants none of what `base` carries declines there and takes the `gov` phase, which is language-neutral and installs rules without the `base` development dependencies the tooling layer would drop on it. Say so at the preview rather than resolving it here, since the fallback is a working default and only the person can say whether it fits.
 

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

@@ -67,7 +67,7 @@ folder is a Go or PHP root rather than a JavaScript one.
 
 Read these once, from the repository root:
 
-- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
+- `canon/REQUIREMENTS.md` if present
 - Directory structure via `ls -1` of the project root and `src/` if present
 
 ## Resolve arguments

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

@@ -75,7 +75,7 @@ candidate list and stop rather than choosing on the operator's behalf.
 For each chosen folder, read every `*.md` sibling and draft frontmatter:
 
 - `title`: derived from the first H1. If absent, derive from the filename in sentence case.
-- `description`: one line summarizing the file's purpose, drawn from the first paragraph after the H1. Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` § Frontmatter descriptions for length and style.
+- `description`: one line summarizing the file's purpose, drawn from the first paragraph after the H1. Follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` § Frontmatter descriptions for length and style.
 
 Surface every drafted entry to the user grouped by file:
 

package/claude/skills/task-board/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 Owns the two operations that bring a task file into existence and take it out of the folder. `context-fold` edits the contents of a task that already exists, marking outcomes `[x]`. Do not mark outcomes here, and do not move a plan by hand: the archive carries it.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` before writing any file. It holds the filename convention, the frontmatter contract, and the file format. Do not work them from memory.
+Read `${CLAUDE_SKILL_DIR}/references/tasks.md` before writing any file. It holds the filename convention, the frontmatter contract, and the file format. Do not work them from memory.
 
 ## Guards
 
@@ -43,7 +43,7 @@ Do not derive the label from a version file. `${CLAUDE_SKILL_DIR}/../../standard
 
 ### Step 3: write the file
 
-Write `.canon/tasks/vXX.Y-<slug>.md` under the claimed label, reading the file first if a session ever stubbed it, following the format in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
+Write `.canon/tasks/vXX.Y-<slug>.md` under the claimed label, reading the file first if a session ever stubbed it, following the format in `${CLAUDE_SKILL_DIR}/references/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
 
 Write `Plan:`, `Groundwork:`, and `Intake:` as markdown links relative to `.canon/tasks/`, as in `Plan: [feature-<slug>](../plans/feature-<slug>.md)`. Leave `Issue:` a bare `#NNN`. A task written in the older bare-path form still parses, so it costs the board a clickable line rather than an archive, but it leaves the board in two shapes for every reader after.
 
@@ -55,7 +55,7 @@ Write it immediately. Claude Code's tool permission dialog is the confirmation g
 
 A task file with no row is a dropped task, so name the surface it lands on in the same pass that creates it. A task that would plausibly be planned within the next few waves takes a row under `## Needs a plan` in `.canon/tasks/priority.md`, positioned by where it sits against the rows already there, with the reason for that position in its `Waiting on` cell. Anything else takes a line in `.canon/tasks/backlog.md`, which is unordered and where in the file it goes means nothing.
 
-The test and both file shapes are in `${CLAUDE_SKILL_DIR}/../../standards/board.md`.
+The test and both file shapes are in `${CLAUDE_SKILL_DIR}/references/board.md`.
 
 Check the roster for a live orchestrator before writing either file. Read `canon sessions list --self --json` for this session's own `sessionId` and `name`, then read `canon sessions list --json` and match a row whose `repository` matches this session's own, whose `sessionId` differs from it, and whose `name` starts with `orchestrator-`. That is the convention every hand-launched controller on this machine currently uses, and it excludes every `worker-` and `planner-` session cleanly. Treat a refusal from either call the same as a roster read that failed.
 
@@ -71,7 +71,7 @@ Scan for work that has been decided and would otherwise be forgotten. Three orig
 
 List `.canon/groundwork/` and run `gh issue list --state open` when a remote is configured, then grep the board for each track name and issue number. Report any with no task, one line each.
 
-Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../../standards/intake.md` fixes. Then grep `.canon/tasks/`, `.canon/tasks/archive/`, and `.canon/tasks/declined/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and either shipped or declined, so a check reading the board by itself reports every settled folder as abandoned.
+Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` fixes. Then grep `.canon/tasks/`, `.canon/tasks/archive/`, and `.canon/tasks/declined/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and either shipped or declined, so a check reading the board by itself reports every settled folder as abandoned.
 
 A dump is the stronger case for this scan rather than the weaker one. A track holds one question and stays visible, while a dump holds dozens of items whose verdicts were reached and then left with nothing carrying them forward.
 

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

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

package/{standards → claude/skills/task-board/references}/board.md

@@ -7,6 +7,15 @@ description: Readiness groups, row cells, and ordering for priority.md, the unor
 
 Applies to `.canon/tasks/priority.md`, `.canon/tasks/backlog.md`, and `.canon/tasks/index.md`, the three files beside the tasks that say which one runs next. Update `priority.md` when a task is filed, planned, dispatched, or blocked, and `backlog.md` whenever the board is swept.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working board looks like](#what-a-working-board-looks-like)
+- [The files](#the-files)
+- [Ordering](#ordering)
+- [The backlog](#the-backlog)
+- [Validation](#validation)
+
 ## Scope
 
 Governs the board files under `.canon/tasks/`: the readiness groups and their columns in `priority.md`, row order and the reason each row states, the backlog beside it, and the generated index.

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

@@ -7,7 +7,7 @@ description: How task-board gathers the reason a task is decided against, runs c
 
 The Decline mode of `task-board`. The session reads this file when the request names a task decided against.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/tasks-decline.md` first. It holds the declined folder, the `Declined:` line, and what the move does to a plan and a board row.
+Read `${CLAUDE_SKILL_DIR}/references/tasks-decline.md` first. It holds the declined folder, the `Declined:` line, and what the move does to a plan and a board row.
 
 A task decided against carries no `post-merge` hook of its own, so every decline request arrives here directly rather than through work the hook already did.
 

package/{standards → claude/skills/task-board/references}/tasks.md

@@ -1,12 +1,6 @@
 ---
 title: Tasks reference
 description: Folder layout, filename convention, file format, origin lines, and archiving for task files under .canon/tasks/
-paths:
-  - '.canon/tasks/**'
-rule:
-  - 'Follow the board standard for `priority.md` and `backlog.md`, their readiness groups, and row order. Read it with `canon standards board`.'
-  - 'Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter.'
-  - 'Follow the task decline standard for a task decided against. Read it with `canon standards tasks-decline`.'
 ---
 
 # Tasks reference
@@ -17,6 +11,18 @@ Update when a task starts, completes, or changes scope. When to open a task at a
 
 The folder is gitignored. Board state changes when work ships rather than when a branch is written, so committing it would put a claim about the future into the diff of an unrelated pull request. The git log records what shipped.
 
+## Contents
+
+- [Scope](#scope)
+- [Layout](#layout)
+- [Filenames](#filenames)
+- [Frontmatter](#frontmatter)
+- [File format](#file-format)
+- [Origin](#origin)
+- [What goes in](#what-goes-in)
+- [What does not go in](#what-does-not-go-in)
+- [Archiving](#archiving)
+
 ## Scope
 
 Governs the task files under `.canon/tasks/`: folder layout, filenames, frontmatter, file format, origin lines, and archiving.
@@ -27,7 +33,6 @@ Does not govern:
 - Execution order, readiness groups, the backlog, and the generated index beside the tasks: `board.md`
 - The plan file a task cites, its sections, and its answer contract: `plan.md`
 - Phase-label format and which surfaces a label may appear on: `versioning.md`
-- Architectural reasoning that outlives a task: `architecture.md`
 - The pre-compaction handoff sitting in the folder, its filename and its sections: `session.md`
 - When a project opens a task at all, which is project policy rather than a shape rule
 
@@ -154,7 +159,7 @@ The line is what lets a merge close its own task. `canon tasks archive --pull-re
 
 - Class names, file paths, function names, or prop names in any entry or title
 - Code-level steps or implementation detail. Behavioral specifics are fine.
-- Architectural reasoning that outlives the task. A finding explains why this task is shaped as it is. A decision the system keeps after the task closes belongs in `canon/ARCHITECTURE.md`.
+- Architectural reasoning that outlives the task. A finding explains why this task is shaped as it is. A decision the system keeps after the task closes belongs in the context entry of the domain it constrains.
 - Narrative of the session that produced the task. A finding states what constrains the task, so what was probed, what it cost, and who decided belongs in the groundwork folder the `Groundwork:` line names. A task with no groundwork folder cuts the narrative rather than relocating it, since the board is not the fallback destination for it.
 - "In progress" or "Blocked" headings. Note status inline on the outcome instead.
 - Sequencing rationale or which version is active. Why this task is planned before its neighbors goes on its row in `priority.md`, in the cell that already carries what it is waiting on. Rationale wider than one row has no home at all, so cut it rather than filing it here.

package/claude/skills/teach-workspace/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 Run a learning workspace on one subject across sessions. The workspace holds what the learner has been through, so a session weeks later resumes from the folder rather than from the conversation.
 
-The shape of the workspace is fixed by `${CLAUDE_SKILL_DIR}/../../standards/teach.md`. Read it before writing anything into the folder. The glossary answers to `${CLAUDE_SKILL_DIR}/../../standards/glossary.md` wherever it lands. The pedagogy sits in `${CLAUDE_SKILL_DIR}/references/pedagogy.md`, the lesson craft and its build in `${CLAUDE_SKILL_DIR}/references/lesson-craft.md` and `lesson-build.md`, the record's revisit schedule in `revisit.md`, and the promotion routing in `${CLAUDE_SKILL_DIR}/references/promotion.md`.
+The shape of the workspace is fixed by `${CLAUDE_SKILL_DIR}/references/teach.md`. Read it before writing anything into the folder. The glossary answers to `${CLAUDE_SKILL_DIR}/references/glossary.md` wherever it lands. The pedagogy sits in `${CLAUDE_SKILL_DIR}/references/pedagogy.md`, the lesson craft and its build in `${CLAUDE_SKILL_DIR}/references/lesson-craft.md` and `lesson-build.md`, the record's revisit schedule in `revisit.md`, and the promotion routing in `${CLAUDE_SKILL_DIR}/references/promotion.md`.
 
 ## Guards
 

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

@@ -7,7 +7,7 @@ description: How teach-workspace Step 5 writes a learning record's Revisit secti
 
 Part of Step 5 of `teach-workspace`. The session reads this file once the record's lessons, retrievals, and wrong answers are written, before restating the mission's success lines.
 
-Then write `## Revisit`, one bullet per item, in the shape `${CLAUDE_SKILL_DIR}/../../standards/teach.md` fixes:
+Then write `## Revisit`, one bullet per item, in the shape `${CLAUDE_SKILL_DIR}/references/teach.md` fixes:
 
 ```markdown
 ## Revisit

package/{standards → claude/skills/teach-workspace/references}/teach.md

@@ -1,11 +1,6 @@
 ---
 title: Teach reference
 description: Workspace layout, ordinal naming, frontmatter, and the mission and learning-record formats for a learning workspace
-paths:
-  - '.canon/teach/**'
-rule:
-  - 'Follow the glossary standard for the glossary every workspace carries at its root. It is the single source for the entry shape, the ordering, and which terms the file carries. Read it with `canon standards glossary`.'
-  - 'Report it rather than proceeding silently when that file does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.'
 ---
 
 # Teach reference
@@ -14,6 +9,23 @@ Applies to a learning workspace at `.canon/teach/<nn>-<topic>/`. One workspace h
 
 The folder is gitignored. Its markdown half is written in a format the authoring gates read, so a page promoted out of it later needs no conversion.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working workspace looks like](#what-a-working-workspace-looks-like)
+- [Folder name](#folder-name)
+- [Layout](#layout)
+- [Frontmatter](#frontmatter)
+- [File naming](#file-naming)
+- [MISSION.md](#missionmd)
+- [Learning records](#learning-records)
+- [Revisit](#revisit)
+- [GLOSSARY.md](#glossarymd)
+- [RESOURCES.md](#resourcesmd)
+- [Conventions](#conventions)
+- [Anti-patterns](#anti-patterns)
+- [Template](#template)
+
 ## Scope
 
 Governs a learning workspace under `.canon/teach/<nn>-<topic>/`: folder layout, ordinal naming, frontmatter, and the mission and learning-record formats.

package/claude/skills/test-first/REQUIREMENT.md

@@ -33,7 +33,7 @@ Without this skill, a session implementing a planned change writes the test afte
 
 - Choosing the layer a test belongs at and judging whether it is a good test: `canon:test-craft`, loaded at step 1 rather than restated here
 - Finding the cause of an unexplained failure: `canon:systematic-debugging`
-- Confirming visual output after a change lands: `567-planning.md` states the order and `ui-checklist` writes the list to confirm against
+- Confirming visual output after a change lands: `ui-checklist` writes the list to confirm against
 - Shaping the function, class, or module the implementation writes: `canon:code-craft`, loaded at step 4 rather than restated here
 - Committing the behavior as a slice and ordering the slices of a larger build: `canon:build-in-slices`
 - The mechanical audit of whether an implementation reached history ahead of its test: `canon gov test-order`, invoked from `auto-ship`

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

@@ -13,7 +13,7 @@ The pass slides into fixing what it finds, and then the audit and the change lan
 
 ## Must
 
-- Read the design system and the per-surface wireframes as ground truth for intent before flagging any drift
+- Read the design system as ground truth for intent before flagging any drift, where the project carries one
 - Group findings by surface, since a surface is what a person opens and fixes
 - Cover missing feedback states, unhandled edge cases, inconsistencies, and friction in daily use
 - Write the full report to the branch-derived path at the main worktree root, overwriting
@@ -36,5 +36,5 @@ The pass slides into fixing what it finds, and then the audit and the change lan
 - Fixing what it found, which is a separate change with its own review
 - Feature planning, which `plan-feature` owns
 - Verifying one specific change, which `ui-checklist` owns
-- Defining the intent it audits against, which `design-extract` and the wireframes own
+- Defining the intent it audits against, which the design document owns
 - Measuring what a running interface costs to paint, block, or shift, which `ux-measure` owns. Contrast stays here rather than going with it, being computable from two color values this skill already reads off the token table.

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

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

package/claude/skills/write-human/REQUIREMENT.md

@@ -44,6 +44,5 @@ Importing that catalog wholesale fails on a different measurement. External mate
 - The banned characters, which `markdown.md` states for a reader and `canon markdown audit` gates from package data
 - Spelling, which a project's spell checker enforces
 - Markdown mechanics, being headings, lists, code spans, punctuation, and file references
-- Restating text that already exists in plainer words, which `restate-plainly` owns on a different trigger, since a restatement is asked for by name and this arrives on a glob match. The rules here still govern how that restatement reads, and that body cites this one rather than carrying a copy.
 - What voice a given surface declares, which belongs to the standard governing that surface
 - Measuring whether finished output followed these rules, which needs a check this skill does not carry

package/claude/skills/write-human/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: write-human
-description: Carries the voice, word choice, rhythm, sentence construction, and information density rules a banned-character scan cannot express, plus the catalog of machine tells that survive a clean ban scan. Use when writing or revising prose a person will read, when a passage reads flat or uniform, or when asked to "make this read like a person", "fix the cadence", "this reads like AI wrote it", "vary the sentences", or "tighten this without gutting it". Do NOT use for banned characters, which `markdown.md` states and `canon markdown audit` gates, and do NOT use to restate text that already exists in plainer words, which is `restate-plainly`, whose body loads these rules from here.
+description: Carries the voice, word choice, rhythm, sentence construction, and information density rules a banned-character scan cannot express, plus the catalog of machine tells that survive a clean ban scan. Use when writing or revising prose a person will read, when a passage reads flat or uniform, or when asked to "make this read like a person", "fix the cadence", "this reads like AI wrote it", "vary the sentences", or "tighten this without gutting it". Do NOT use for banned characters, which `markdown.md` states and `canon markdown audit` gates.
 metadata:
   family: answer
 ---
@@ -11,7 +11,7 @@ Write prose that reads as though a person wrote it. A ban list subtracts words a
 
 Load this before drafting a passage rather than after. A revision pass recovers the words and never recovers the structure the draft already settled.
 
-The banned characters sit in `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`. They stay in force here. This skill adds to them and never restates them, since `canon markdown audit` reads them from the package and a second copy would drift. The word guidance under `## Voice` is the one copy of that list, and no command reads it.
+The banned characters sit in `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`. They stay in force here. This skill adds to them and never restates them, since `canon markdown audit` reads them from the package and a second copy would drift. The word guidance under `## Voice` is the one copy of that list, and no command reads it.
 
 ## What yields and what does not
 

package/docs/agents/audits.md

@@ -30,7 +30,7 @@ The verbs walk separate trees and share no state, so they run together. Measured
 
 Eighteen of the twenty-one read a tree on this disk, the one added by `restated.md` and the one added by `census.md` among them, since the first reads four such trees against each other and the second counts every file in one. The two added by `state-scoped-risk.md` read committed state rather than an arriving change, which is the gap every review surface here leaves by construction, and the one added by `label-coverage.md` reads a branch range against a map the project declares.
 
-The placement entry runs `canon context classify sweep` pinned to `--backend off`, so it reads the regex layer alone whatever classifier setting the project resolves. A count that moves with whichever model a machine runs is not comparable across clones, and the model layer turned a sub-second read into one measured at about 17 minutes over this repository's context and wireframe sections on the authoring machine. It retains one tally per verdict, `keep`, `rewrite`, and `move`, and gates on nothing, since each verdict is a judgment. `document-health` is the surface that reads the same sections with the model.
+The placement entry runs `canon context classify sweep` pinned to `--backend off`, so it reads the regex layer alone whatever classifier setting the project resolves. A count that moves with whichever model a machine runs is not comparable across clones, and the model layer turned a sub-second read into one measured at about 17 minutes over this repository's context sections on the authoring machine. It retains one tally per verdict, `keep`, `rewrite`, and `move`, and gates on nothing, since each verdict is a judgment. `document-health` is the surface that reads the same sections with the model.
 
 Each is invoked as the CLI the caller is running rather than as a global `canon`. A globally installed binary resolves to the main checkout no matter which worktree is executing, so the aggregate would measure a tree the branch never touched and report a pass over it.
 

package/docs/agents/canvas.md

@@ -5,7 +5,7 @@ description: The canvas server, its content format, and the verbs that list, arr
 
 # Canvas
 
-`canon canvas` serves a local canvas of pages and HTML frames and gives an agent the verbs the operator's mouse has. A page is a folder under `.canon/canvas/`, a frame is one HTML file in it, and `layout.json` beside them holds each frame's box. `standards/canvas.md` fixes that content format, and the `canvas` skill carries the procedure a session follows to drive the canvas.
+`canon canvas` serves a local canvas of pages and HTML frames and gives an agent the verbs the operator's mouse has. A page is a folder under `.canon/canvas/`, a frame is one HTML file in it, and `layout.json` beside them holds each frame's box. `claude/skills/canvas/references/canvas.md` fixes that content format, and the `canvas` skill carries the procedure a session follows to drive the canvas.
 
 ## Serve
 

package/docs/agents/commands.md

@@ -42,9 +42,8 @@ One row per top-level command, in the order `canon --help` prints them. A domain
 | `canon sessions <verb>`     | Resolve live sessions to worktree and branch, and move one between machines                |
 | `canon worktrees <verb>`    | Report and remove worktrees whose pull request merged                                      |
 | `canon hooks <verb>`        | Run the steps a git hook drives                                                            |
-| `canon autoship <verb>`     | Decide whether a changed set needs the review pass                                         |
 | `canon pr <verb>`           | Read a pull request's diff, head, checks, and review, and post its evidence                |
-| `canon feedback`            | Write toolkit feedback from stdin, or open an issue with `--github`                        |
+| `canon feedback`            | Open a GitHub issue from toolkit feedback on stdin, or print the block on failure          |
 | `canon audits <verb>`       | Run every audit as one set under one verdict against the recorded baseline                 |
 | `canon gate <verb>`         | Run every stage that guards a branch here                                                  |
 | `canon secrets <verb>`      | Report credential-shaped values in the tree the package ships                              |
@@ -53,8 +52,8 @@ One row per top-level command, in the order `canon --help` prints them. A domain
 | `canon comments <verb>`     | Measure comment density by language and kind, with a trend from git                        |
 | `canon context <verb>`      | Report context folder health, and classify changed or stale sections                       |
 | `canon markdown <verb>`     | Fail markdown on a banned character or a dead link, and report its structure               |
-| `canon repo <verb>`         | Propose and apply the remote's description, homepage, and topics                           |
 | `canon census [path]`       | Report tracked file count, extensions, and a line total skipping binaries                  |
+| `canon upstream <verb>`     | Read Claude Code releases from a cursor, and list the toolkit's own mechanisms             |
 
 `canon serve` drives no browser, which is what separates it from the four that do. All four ship now that `capture` does, so the line between them is the engine rather than the package. A generated page loses its script to an editor preview and to a `file://` open, so the link is the delivery rather than a convenience, and every generated surface here reaches a reader through one. A teach lesson's stylesheet is embedded rather than linked, so only its script still needs a server. It binds `127.0.0.1` and never a wildcard, because what it is pointed at is routinely a gitignored record tree. It sends `cache-control: no-store`, since a preview exists to be edited and reloaded and a cached stylesheet reads as a fix that did not work.
 
@@ -104,7 +103,6 @@ Each domain exposes a consistent shape where applicable: `list`, `install`, `syn
 - `sessions`, in `sessions.md`: `list`, `export`, `import`
 - `worktrees`, in `worktrees.md`: `list`, `reclaim`
 - `hooks`, in `hooks.md`: `post-merge`
-- `autoship`, in `review-classification.md`: `classify`
 - `pr`, in `pr-reads.md`: `key-changes`, `head`, `checks`, `review-state`, `evidence`, `preview`, `local`, `frames`
 - `audits`, in `audits.md`: `run`, `list`
 - `gate`, in `gate.md`: `run`
@@ -114,7 +112,6 @@ Each domain exposes a consistent shape where applicable: `list`, `install`, `syn
 - `comments`, in `comments.md`: `scan`
 - `context`, in `context-audit.md`: `audit`, `classify diff`, `classify sweep`, `classifier show`, `classifier set`
 - `markdown`, in `markdown-audit.md`: `audit`
-- `repo`, described below: `metadata propose`, `metadata apply`
 
 Common patterns:
 
@@ -133,7 +130,6 @@ Subcommands no other page describes:
 - A deck folder's `deck.json` and the faces it embeds, its per-slide `<body>` attributes, transitions and entrances, speaker notes, and charts are described in `slides.md`.
 - `canvas`, with its verbs, content format, and write routes, is described in `canvas.md`.
 - `labels scan` fails a pull request or a posted review whose title, body, or review comment carries a phase label, a label a code span quotes, a gitignored record path, a session link, a title word no dictionary holds, or a title breaking `standards/pr.md`'s format, casing, or length rule (`--event`, `--body-file`, `--json`).
-- `repo metadata propose` compares a description, homepage, and topic set computed from the README and `package.json` against what the remote carries, writing nothing, and `repo metadata apply` writes an explicitly supplied set through `gh repo edit` (`--description`, `--homepage`, `--topics`).
 
 ## Version skew
 
@@ -150,7 +146,7 @@ the JSON record rather than on the exit, since an offline machine has to read as
 unmeasured rather than as a failing check.
 
 `canon upgrade --json` carries one further state, `pending`, that the skew report
-does not. It means the checkout at the working directory holds a release npm does
-not serve yet, so there is nothing to install. The record names that version in
-`checkout` beside `latest`, exits 0, and its `message` starts `CLI stays at`. A
-directory outside any canon checkout never reads `pending`.
+does not: the working directory's checkout holds a release npm does not serve
+yet, so there is nothing to install. The record names it in `checkout` beside
+`latest`, exits 0, and its `message` starts `CLI stays at`. Outside a canon
+checkout it never reads `pending`.