@erclx/canon 5.31.0 → 5.33.0

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
@@ -96,7 +96,7 @@ target project on the fly.
 
 On the `gov` phase, stop and present four options rather than picking:
 
-1. Author a new rule in the toolkit at `governance/rules/<domain>/<num>-<name>.md` following `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, commit, then re-run install. Take this route when the toolkit should ship the rule to every project.
+1. Author a new rule in the toolkit at `governance/rules/<domain>/<num>-<name>.md` following `${CLAUDE_SKILL_DIR}/../create-rule/references/rule.md`, commit, then re-run install. Take this route when the toolkit should ship the rule to every project.
 2. Invoke `create-rule`, which scaffolds the file into the target project at a non-colliding number. Take this route when the rule is specific to this project and no sync should ever overwrite it.
 3. Install the matching non-`<tech>` rules and skip the tech-specific layer.
 4. Abort.

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

@@ -1,6 +1,6 @@
 ---
 name: task-board
-description: Why creating and archiving a task file is one skill, the origin invariant enforceable only at creation, and why archiving routes through the command the merge hook calls
+description: Why creating and declining a task file is one skill, the origin invariant enforceable only at creation, and why settling a shipped task belongs elsewhere
 ---
 
 # Task board requirement
@@ -9,8 +9,6 @@ description: Why creating and archiving a task file is one skill, the origin inv
 
 Without this skill, a task file gets a filename and frontmatter invented on the spot, so the board sorts wrong and the regenerated index reads fields that are not there. A task arrives with no origin, which is either lost context or work nobody decided to do, and by the time anyone notices there is no way to recover which it was. The phase label gets derived from a version file rather than from what the board already means, and a single-digit phase sorts after a double-digit one because nobody padded it. A label picked off the live board alone repeats one the archive already spent, since the archive holds most of what has ever been allocated and a board-only scan cannot see it.
 
-Archiving fails in two ways that both lose work. Moving the file, editing the ordering file, and regenerating the index as three separate acts drifts from the one command the merge hook calls, so the attended and unattended paths stop agreeing. And an all-`[x]` task gets archived while its pull request is still open, because marking outcomes happens on the branch as the first step of shipping. The board is gitignored, so nothing restores a task archived early.
-
 Placing a row without checking for another writer collides the same way. Two sessions filing work at once can claim one phase label twice or land two rows beside each other unread, since neither reads the board before writing it.
 
 ## Must
@@ -20,29 +18,26 @@ Placing a row without checking for another writer collides the same way. Two ses
 - Require an origin at creation, because that is the only moment the invariant is enforceable
 - Claim the phase label with `canon tasks next-label --claim` rather than reading or proposing one by hand
 - Check the roster for a live orchestrator before writing a row, and hand off rather than write when one is found
-- Confirm the work reached the default branch before archiving
-- Run the archive command and route on the reason it refuses, since each reason has one resolution
+- Run the decline command and route on the reason it refuses, since each reason has one resolution
 - Report an origin that carries no task, as a list rather than a prompt
 
 ## Must not
 
-- Mark an outcome complete or archive a plan
+- Mark an outcome complete, archive a task, or move a plan
 - Hand-edit the index or the ordering file, or move the task file directly
 - Write a pull request line at creation, when any number is a guess at someone else's work
-- Archive around a refusal
-- Split the legacy single-file archive into per-task files nobody wrote
+- Decline around a refusal
 - Claim a label or write a task file for a session holding the worker role, since that role reports a row upward and the controlling session places it
 - Fall through to a direct write when no orchestrator is found and this session's own name starts with `worker-` or `planner-`, since those role bodies ban the write with no exception
 
 ## Guards
 
 - No task board at the main root: stop
-- The request fits neither creating nor archiving: stop rather than picking one
-- Work not yet on the default branch: stop, because the board has no history to restore from
+- The request fits neither creating nor declining: stop rather than picking one
 - No origin given and none offered: stop
 
 ## Out of scope
 
-- Editing the contents of a task that already exists, which `context-fold` owns along with marking outcomes and sweeping plans
+- Marking a shipped task's outcomes and archiving it, which `task-complete` owns, with the `post-merge` hook running the unattended archive
 - Deciding what the task should argue. This owns the file's existence and its shape, not its content.
-- Relocating a plan, which one skill owns so two do not relocate it differently
+- Relocating a plan, which `canon tasks archive` owns so two movers do not relocate it differently

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

@@ -1,22 +1,22 @@
 ---
 name: task-board
-description: Creates a task file in `.canon/tasks/` with the filename, phase label, and frontmatter the standard requires, and archives a shipped one out of the folder. Use when asked to "add a task", "create a task", "queue this", "put this on the board", "archive that task", or "close out a shipped task". Do NOT use to mark an outcome `[x]`. That is `context-fold`.
+description: Creates a task file in `.canon/tasks/` with the filename, phase label, and frontmatter the standard requires, and declines one decided against. Use when asked to "add a task", "create a task", "queue this", "put this on the board", or "decline that task". Do NOT use to mark an outcome `[x]` or to archive a shipped task. That is `task-complete`.
 metadata:
   family: decide
 ---
 
 # Task board
 
-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.
+Owns the two operations that decide a task: bringing its file into existence, and declining one decided against. `task-complete` settles a task once its work exists, marking outcomes `[x]` and archiving a shipped one. Do not mark outcomes or archive here, and do not move a plan by hand.
 
-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
 
 - Resolve the board at the main worktree root, not `pwd`. Run `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside a git repo. Every read and write below resolves against that root. The board is gitignored scratch shared across worktrees, so a linked worktree writing to its own `pwd` creates a second board nothing else reads.
-- A new task file is a main-root write, so it goes out as a heredoc. Archiving already runs through `canon tasks archive`, which resolves the root in-process. Marking an outcome shipped is `context-fold` and runs through `canon tasks outcome`. Resolve that root and route the write the way `session-worktree` states.
+- A new task file is a main-root write, so it goes out as a heredoc. Declining already runs through `canon tasks decline`, which resolves the root in-process. Resolve that root and route the write the way `session-worktree` states.
 - If `.canon/tasks/` does not exist at that root, stop: `❌ No .canon/tasks/ board. Run canon claude init to set it up.`
-- Route on the request rather than on a flag. Creating names work that does not exist yet, archiving names a task file already shipped, and declining names one decided against. If the request fits none of the three, stop: `❌ Ambiguous. Say whether to create a task, archive one, or decline one.`
+- Route on the request rather than on a flag. Creating names work that does not exist yet, and declining names a task file decided against. A request to archive a shipped task or mark its outcomes belongs to `task-complete`, so name it and stop. If the request fits neither, stop: `❌ Ambiguous. Say whether to create a task or decline one.`
 - Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter after a write. Do not run the regen command directly, except after a shell write from a linked worktree: the hook matches `Write|Edit|MultiEdit` and nothing fires on `Bash`, so that one case regenerates explicitly with `canon indexes regen --no-stage --root <main-root> <main-root>/.canon/tasks/index.md`.
 
 ## Create
@@ -39,11 +39,11 @@ The guard sits ahead of Step 2 because `--claim` reserves a label on disk, so a
 
 Run `canon tasks next-label --claim --json` and take its `label` field. The verb reads the live board and its `archive/` sibling together, so the label it returns accounts for what the board alone no longer shows, and `--claim` reserves it under `.canon/ordinal-locks/` so a second session filing at the same moment gets the next one. Branch on the record's `reason` rather than the exit: `label-contended` means re-run the claim, and a usage error from an unknown `--claim` means the installed binary predates the flag, so report the verb as unavailable rather than falling back to a bare read, which reopens the race.
 
-Do not derive the label from a version file. `${CLAUDE_SKILL_DIR}/../../standards/versioning.md` permits free renumbering, so the verb's two folders are the only surface that knows what a label currently means.
+Do not derive the label from a version file. `${CLAUDE_SKILL_DIR}/../git-commit/references/versioning.md` permits free renumbering, so the verb's two folders are the only surface that knows what a label currently means.
 
 ### 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.
 
@@ -90,10 +90,6 @@ Report rather than prompt. A track can be opened long after its task would have
 
 Say the origins were read even when nothing comes back, which is the ordinary result. A step going silent on a clean pass is indistinguishable from one that never ran.
 
-## Archive
-
-Read `${CLAUDE_SKILL_DIR}/references/archive.md` when the request names a shipped task to archive. It carries the check that the work reached `main`, the `canon tasks archive` call, the route for each refusal, and the prose to clear afterwards. Never move the file, edit `priority.md`, or regenerate the index by hand, since the command owns all three.
-
 ## Decline
 
 Read `${CLAUDE_SKILL_DIR}/references/decline.md` when the request names a task decided against. It carries gathering the reason, the `canon tasks decline` call, the route for each refusal, and the prose to clear afterwards. Never move the file, edit `priority.md` or `backlog.md`, or regenerate the index by hand, since the command owns all three.
@@ -124,12 +120,4 @@ Create:
 
 Drop either block when it carries no rows. When both are empty, which is the ordinary result, replace them with one line naming what was read: `Read <n> tracks, <n> dumps, and <n> open issues. Nothing unlinked.`
 
-Archive, reporting the paths the command returned:
-
-```plaintext
-📦 Archived: .canon/tasks/archive/vXX.Y-<slug>.md
-
-<ordering and index disposition in one line>
-```
-
 A refusal reports the reason and the resolution the mode's reference routes it to under its Step 3, on one line each.

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
 
@@ -49,13 +54,13 @@ One file per task is what keeps the board safe under parallel sessions. Two sess
 
 Siblings sit in the folder without being tasks, and each earns its place by being governed somewhere. `index.md`, `priority.md`, and `backlog.md` are governed by `board.md`. Every `session-` file is a pre-compaction handoff governed by `session.md`, and each is optional: a project whose sessions never approach a compaction carries none. Anything filtering the folder to tasks skips all of them, so a name outside the set is a task whatever it holds.
 
-The `task-board` skill creates and archives task files, and the archive carries the task's plan with it. `context-fold` marks outcomes `[x]` in an existing file. Neither does the other's job.
+The `task-board` skill creates and declines task files. The `task-complete` skill marks outcomes `[x]` in an existing file and archives a shipped one, and the archive carries the task's plan with it. Neither does the other's job.
 
 ## Filenames
 
 `vXX.Y-<slug>.md`, where the version is the phase label zero-padded to two digits and the slug is kebab-case.
 
-Padding is load-bearing. Index entries sort by filename and nothing else, so a bare `v9.0` sorts after `v15.0` and the catalog reads out of board order. `standards/versioning.md` governs the label itself and permits free renumbering, so expect the occasional rename. Nothing points at a task filename, since a `Plan:` line runs from task to plan rather than the reverse. <!-- canon-allow-reference: illustrates the padding rule's own sort collision, not a citation of a real task -->
+Padding is load-bearing. Index entries sort by filename and nothing else, so a bare `v9.0` sorts after `v15.0` and the catalog reads out of board order. `${CLAUDE_SKILL_DIR}/../git-commit/references/versioning.md` governs the label itself and permits free renumbering, so expect the occasional rename. Nothing points at a task filename, since a `Plan:` line runs from task to plan rather than the reverse. <!-- canon-allow-reference: illustrates the padding rule's own sort collision, not a citation of a real task -->
 
 ## Frontmatter
 
@@ -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/task-complete/REQUIREMENT.md

@@ -0,0 +1,47 @@
+---
+name: task-complete
+description: Why marking shipped outcomes and archiving a shipped task sit in one skill, why the diff decides completion alone, and why the ship chain marks but never archives
+---
+
+# Task complete requirement
+
+## Gap
+
+Without this skill, the board describes the scope a branch opened with. An outcome the diff shipped stays unchecked, so the board reports finished work as open and the next session re-plans it. When marking rode inside the context fold, it kept a ten-step skill running on every ship for a write that had nothing to do with the context entries, and a session reading the fold's name never learned that it also wrote the board.
+
+Archiving fails in two ways that both lose work. Moving the file, editing the ordering file, and regenerating the index as three separate acts drifts from the one command the merge hook calls, so the attended and unattended paths stop agreeing. And an all-`[x]` task gets archived while its pull request is still open, because marking happens on the branch as a ship-chain step. The board is gitignored, so nothing restores a task archived early.
+
+Review receipts pile up the same way. A branch report is read once by the session addressing it, and nothing but an operator asking ever collected one whose branch was gone, so the folder grew per shipped branch and never shrank.
+
+## Must
+
+- Take completion from the diff, since completion is a fact about the repository rather than about the conversation
+- Match an outcome on the behavior it names, never on a filename or a commit subject
+- Leave an outcome unchecked when the diff is ambiguous. An unmarked shipped outcome costs one manual edit and a wrongly marked one hides work that never happened.
+- Close outcomes through `canon tasks outcome` and branch on the record's `ok` and `reason` rather than the exit
+- Resolve the board at the main worktree root, since a linked worktree reading `pwd` finds no board
+- Sweep a branch review report whose branch no longer exists, and leave the current branch's receipt alone, since its branch is still live
+- Confirm the work reached the default branch before archiving
+- Run the archive command and route on the reason it refuses, since each reason has one resolution
+
+## Must not
+
+- Infer a new task from the diff. Only outcomes already on the board get marked.
+- Touch a task file the diff does not relate to
+- Archive from the ship chain. The pull request has not merged there, and the `post-merge` hook archives through the same command once it does.
+- Hand-edit the index or the ordering file, or move a task file or a plan directly
+- Archive around a refusal
+- Split the legacy single-file archive into per-task files nobody wrote
+- Widen what the marking step reads into a write when the baseline is unusable
+
+## Guards
+
+- No task board at the main root: Mark reports one skip line and returns, since the ship chain runs it on every project, and Archive stops naming the command that sets one up
+- Work not yet on the default branch when archiving: stop, because the board has no history to restore from
+
+## Out of scope
+
+- Creating or declining a task, which `task-board` owns
+- The context entries, which `context-fold` owns
+- The unattended archive at merge, which the `post-merge` hook runs through `canon tasks archive`
+- Regenerating the task index, owned by a hook

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

@@ -0,0 +1,86 @@
+---
+name: task-complete
+description: Marks the outcomes a branch's diff shipped `[x]` on the task board, sweeps the review receipts whose branch is gone, and archives a shipped task by hand where the `post-merge` hook could not. Use when asked to "mark what shipped", "tick the outcomes", "close out a shipped task", or "archive that task", or as the ship-chain step after `context-fold`. Do NOT use to create or decline a task, which is `task-board`, or to update the context entries, which is `context-fold`.
+metadata:
+  family: ship
+---
+
+# Task complete
+
+Owns the two operations that settle a task once its work exists: marking the outcomes the diff shipped, and archiving a task whose work reached `main`. `task-board` brings a task into existence and declines one, and `context-fold` writes the context entries. Do not create a task here, and do not move a plan by hand: the archive carries it.
+
+## Guards
+
+- Resolve the board at the main worktree root, not `pwd`. Run `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside a git repo. The board is gitignored scratch shared across worktrees, so a linked worktree reading its own `pwd` finds no board at all.
+- If `.canon/tasks/` does not exist at that root, Mark has nothing to mark: report `⏭️ No .canon/tasks/ board, so no outcomes to mark.` and return, still running Step 4's receipt sweep, since `git-ship` invokes Mark on every ship and a project with no board is not a failed one. Archive stops instead: `❌ No .canon/tasks/ board. Run canon claude init to set it up.`
+- Route on the request rather than on a flag. A request naming a shipped task to archive, or a task file the `post-merge` hook left in place, takes Archive. Every other request takes Mark, which is what the ship chain invokes.
+- Never hand-edit `.canon/tasks/index.md`. A hook regenerates it.
+
+## Mark
+
+### Step 1: resolve the diff baseline
+
+Resolve the base ref once:
+
+```bash
+git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null
+```
+
+Take the union of `git diff --name-only <base> HEAD`, `git diff --name-only HEAD`, and `git ls-files --others --exclude-standard`. Read content with `git diff <base> HEAD` and `git diff HEAD`.
+
+Prefer `origin/main` over local `main`. On `main` itself the local ref resolves to HEAD, so every committed change drops out of the set and this step goes blind to the work it is meant to read.
+
+The baseline is unusable when no merge base resolves against either ref, or when the base came from local `main` and equals HEAD. On an unusable baseline, read `${CLAUDE_SKILL_DIR}/references/unusable-baseline.md` before Step 2 for what to read instead.
+
+### Step 2: match the diff against the board
+
+Read `.canon/tasks/index.md` at the main worktree root, pick the task files whose title or description relates to the changed paths, and read them.
+
+Path matching only chooses which files to open. Behavior decides each outcome. For each unchecked outcome, decide whether the diff shipped the behavior that outcome names.
+
+Completion is a fact about the repository rather than a fact about the conversation, so the diff decides it and the session does not.
+
+Keep the match conservative:
+
+- Mark only outcomes already written on the board. Never infer a new task from the diff.
+- Match on the behavior an outcome describes, not on filenames or commit subjects. The path match above only narrowed which task files to open.
+- Leave an outcome `[ ]` when the diff is ambiguous. An unmarked shipped outcome costs one manual edit, while a wrongly marked one hides work that never happened.
+- Do not touch task files the diff does not relate to.
+
+### Step 3: close the matched outcomes
+
+Mark each completed outcome `[x]` in the task's own file through `canon tasks outcome <stem> --close <n> --json`, repeating `--close` for each. Positions count every outcome checkbox in file order from 1, which the read above already gives. Do not move or archive the file, even when every outcome now reads `[x]`, since the pull request has not merged and the `post-merge` hook archives the task once it does.
+
+The verb resolves the board at the main worktree root in-process, which is the route `session-worktree` states for an edit inside an existing main-root file.
+
+Read `ok` and `reason` out of that record rather than the exit. An operator's shell profile may wrap `canon` in a function that runs the binary and then a second command and takes the second status, which flattens every non-zero exit to zero. A refusal arriving as success leaves the outcome unmarked while the chain moves on, so the board reports shipped work as open and the next session re-plans it.
+
+### Step 4: sweep consumed receipts
+
+Read `${CLAUDE_SKILL_DIR}/references/receipt-sweep.md` for which review receipts this run sweeps, which it keeps, and the output lines. Skip this step silently when nothing qualifies.
+
+## Archive
+
+Read `${CLAUDE_SKILL_DIR}/references/archive.md` when the request names a shipped task to archive. It carries the check that the work reached `main`, the `canon tasks archive` call, the route for each refusal, and the prose to clear afterwards. Never move the file, edit `priority.md`, or regenerate the index by hand, since the command owns all three.
+
+## Output
+
+Emit the full relative path from the project root for every file written or moved. A bare filename names a file the reader cannot open.
+
+Mark, one line per outcome closed, then the sweep lines Step 4 names:
+
+```plaintext
+✅ Marked: .canon/tasks/vXX.Y-<slug>.md, outcome <n>
+```
+
+When the diff closed nothing, output `✅ No outcomes shipped on this diff.` and nothing for Step 3. A refusal reports the record's `reason` on one line, naming the task.
+
+Archive, reporting the paths the command returned:
+
+```plaintext
+📦 Archived: .canon/tasks/archive/vXX.Y-<slug>.md
+
+<ordering and index disposition in one line>
+```
+
+A refusal reports the reason and the resolution `references/archive.md` routes it to under its Step 3, on one line each.

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

@@ -1,11 +1,11 @@
 ---
 title: Archive a shipped task
-description: How task-board confirms a task's work reached main, runs canon tasks archive, routes each refusal, and clears prose naming the archived task
+description: How task-complete confirms a task's work reached main, runs canon tasks archive, routes each refusal, and clears prose naming the archived task
 ---
 
 # Archive a shipped task
 
-The Archive mode of `task-board`. The session reads this file when the request names a task file already shipped.
+The Archive mode of `task-complete`. The session reads this file when the request names a task file already shipped.
 
 The `post-merge` git hook archives the task a merge closed, so a request arriving here is usually one the hook could not resolve on its own. Run the steps below against whatever the hook left in place.
 
@@ -13,7 +13,7 @@ Do not move the file, edit `priority.md`, or regenerate the index by hand. `cano
 
 ## Step 1: confirm the work reached main
 
-`context-fold` marks outcomes on the branch as step 1 of the ship chain, so an all-`[x]` task routinely describes a pull request that is still open. The command gates on the outcomes and cannot tell those two apart, which is what puts this check here:
+`task-complete` marks outcomes on the branch as step 2 of the ship chain, so an all-`[x]` task routinely describes a pull request that is still open. The command gates on the outcomes and cannot tell those two apart, which is what puts this check here:
 
 ```bash
 git fetch origin main --quiet && git log origin/main --oneline -20
@@ -39,8 +39,8 @@ 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.
+- `open-outcomes`: the named outcomes are unmarked or genuinely open. Run `task-complete` 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}/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/claude/skills/task-complete/references/receipt-sweep.md

@@ -0,0 +1,32 @@
+---
+title: Sweep consumed receipts
+description: How task-complete's marking step sweeps branch review reports whose branch is gone, and what it keeps and reports
+---
+
+# Sweep consumed receipts
+
+Step 4 of `task-complete`'s Mark mode, reached in order on every marking run.
+
+Sweep the review receipts a shipped branch left behind. Resolve all paths at the main worktree root, not the current worktree, the way `session-worktree` does.
+
+Every delete below is a plain `rm`, one per call, routed the way `session-worktree` states.
+
+Plans are not swept here. A plan is settled by the merge rather than by an outcome this run marked, and `canon tasks archive` moves it with the task the `post-merge` hook archives. Sweeping it from this step would read a closure Step 3 wrote moments earlier and move a plan the branch is still building from.
+
+## Reviews
+
+Leave the current branch's review receipt where it is. No skill writes one now, so one that exists is older and its branch is still live.
+
+The body that writes a receipt owns its lifetime. This skill sweeps on behalf of whatever called it and has no way to read whether a file is still in use, where the chain that wrote this one cites it in its own output and knows. What reaps it is the branch sweep below, one branch later, once the branch it names is gone.
+
+Sweep the branch reports this session never opened. List `.canon/review/branch-*.md`, run the slug transform in `${CLAUDE_SKILL_DIR}/../git-branch/references/slug.md` over every name `git branch --format='%(refname:short)'` prints, and delete a report whose slug matches none of them. Take the names from that format rather than from `git branch --list`, which marks the current branch with `* ` and a branch checked out in another worktree with `+ `, so a transform reading the marked lines as written turns a live branch into a slug nothing matches and sweeps a report a sibling worktree is still working from. A branch report is read once, by the session addressing it, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so a report outliving its branch is holding nothing. Skipping this leaves them accumulating for the life of the checkout, since a slug is unique per feature and no later branch ever looks for one.
+
+What that removes is a local-only review on a branch deleted before it opened a pull request. The sweep runs anyway rather than keeping every report against the one case, since nothing else ever clears them.
+
+Do not sweep `ux-audit-*.md` or `ux-measure-*.md` (standalone deliverables). Those sit at `.canon/review/` itself rather than under a producer folder, so the glob above never reaches them.
+
+Output one line per file swept:
+
+- `🧹 Deleted: <path>, branch gone` for a branch report whose branch no longer exists
+
+If nothing qualifies, skip this step silently.