@erclx/canon 5.30.0 → 5.32.0

package/README.md

@@ -99,7 +99,7 @@ Working with an agent rather than reading this yourself? It loads `CLAUDE.md` at
 - [Operating model](docs/workflow/operating-model.md): orchestrator, planner, and worker roles for building across parallel sessions
 - [Skill map](docs/workflow/skill-map.md): plugin skills grouped by the moment a project meets them
 - [Skill map on request](docs/workflow/skill-map-on-request.md): plugin skills that serve a request rather than a moment
-- [Visual design workflow](docs/workflow/visual-design-workflow.md): tiered guide for design and wireframe authoring
+- [Visual design workflow](docs/workflow/visual-design-workflow.md): tiered guide for design authoring
 - [Target projects](docs/target/projects.md): scaffold, add a domain later, sync upstream drift
 - [Agents](docs/agents/index.md): CLI flags, exit codes, and JSON output shapes
 - [Docs index](docs/index.md): every reference doc in this repo

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

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
-  "version": "5.30.0",
+  "version": "5.32.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/api-design/references/adopted.md

@@ -29,7 +29,7 @@ From `addyosmani/agent-skills@2686b620`, [`skills/api-and-interface-design/SKILL
 
 **Idempotency.** A stored key honored on retry, an atomic claim under a unique constraint, a reused key with a different body failing loudly, and retention past the longest retry. Adopted as four rules, keeping the reused-key rule, which is the one most often left out.
 
-**Excuses, red flags, and a closing checklist.** The same source's skill anatomy, adopted toolkit-wide through `${CLAUDE_SKILL_DIR}/../../standards/skill-practice.md`. Each excuse row here rebuts a reason a session gives when it is about to break a caller, such as "nobody depends on that field".
+**Excuses, red flags, and a closing checklist.** The same source's skill anatomy, adopted toolkit-wide through `${CLAUDE_SKILL_DIR}/../create-skill/references/skill-practice.md`. Each excuse row here rebuts a reason a session gives when it is about to break a caller, such as "nobody depends on that field".
 
 ## Declined
 

package/claude/skills/auto-ship/REQUIREMENT.md

@@ -9,20 +9,15 @@ description: What the post-plan pipeline is for, the gaps it closes, and why eve
 
 Without this skill, the run from an approved plan to an open pull request is a conversation. A session implements, then asks what comes next, and the answer varies by session. A run that halts leaves no stated resume point, so the user reconstructs how far it got from the working tree.
 
-Review is the step that varies most. It gets skipped on a diff that needed one, or spent on prose already gated by a hook. A file-extension test cannot separate the two, since a skill body and a documentation page are both markdown, so a branch changing what an agent does takes the skip a documentation branch earned.
-
 ## Must
 
 - Take the approved plan for the branch as the scope, and implement only what it describes
 - Load `build-in-slices` before implementing, so the build reaches history as tested slices rather than one uncommitted pass
 - Give every step a stop condition, and leave the code on the branch and the receipts on disk at each one
-- Classify the changed-file list by path as well as by extension, so informational prose skips a code review with no signal on it and executable prose still reaches one
-- Check the branch's committed history for a test-order violation between verify and review, and report any finding without gating on it, matching the verb's own contract
-- Split findings by origin, stopping on a critical or should-fix one the branch inherited and repairing one this run caused
-- Own the review receipt's lifetime, since this chain writes it, cites it in its own closing block, and is the only body that can read whether the step keeping it is still using it
+- Check the branch's committed history for a test-order violation between verify and ship, and report any finding without gating on it, matching the verb's own contract
 - Delegate the ship sequence to `git-ship` rather than restating it, and name only what this chain adds to it
 - Open the pull request as a draft before the continuous integration watch begins, since a pull request marked after it is mergeable for the length of the run
-- Continue past a produced UI checklist rather than stopping on it, and report its unchecked boxes in the closing block, since the draft mark already holds the merge and a stop there skipped review on the resumed path
+- Continue past a produced UI checklist rather than stopping on it, and report its unchecked boxes in the closing block, since the draft mark already holds the merge
 - Prove the draft target's head is the current branch and its state is open before marking it, and stop with nothing marked on a mismatch, since the number is retyped between steps and a draft mark on a release pull request holds that release
 - Name the recovery for the stop it took, since the value of stopping is that the user knows where to resume
 
@@ -30,14 +25,9 @@ Review is the step that varies most. It gets skipped on a diff that needed one,
 
 - Expand past the plan, refactor a neighbor, or touch a file outside it without reason
 - Loop on a failed verify. One fix attempt against the reported errors, then stop.
-- Fix an inherited review finding or a failing check. Both stops are deliberate, since a green pull request reached by auto-fix hides what broke.
-- Loop on a self-introduced finding. One repair pass, then stop, which is the bound a failed verify already carries.
-- Read the plan's file list as the boundary on a repair. It scopes what the run builds, and a finding this run caused is in reach wherever it landed.
+- Fix a failing check. The stop is deliberate, since a green pull request reached by auto-fix hides what broke.
 - Restate the ship sequence. Two copies of one order drift with nothing comparing them, which is what the merge into `git-ship` closed.
 - Skip that skill's own verify for repeating this chain's. The gate exists for the resumed run, and a chain that suppresses it leaves the resumed run reaching nothing.
-- Run the memory Apply phase. Promoting an entry changes how the agent operates and ships as its own change.
-- Read an empty changed-file list as prose-only. It satisfies that test vacuously and would route the branch past review instead of through it.
-- Read a markdown extension as evidence the change only informs. A skill body, a governance rule, and a standard are behavior written in prose.
 - Stop the chain or rewrite a commit over a test-order finding. The verb reports and never gates, and a commit already in history is a different act from the work this run is building.
 
 ## Guards
@@ -45,11 +35,9 @@ Review is the step that varies most. It gets skipped on a diff that needed one,
 - Detached HEAD: stop, no slug resolves
 - No approved plan at the branch-derived plan path: stop, name the branch the slug came from, and say the invocation carried no argument, so a plan or a task path may be passed
 - Uncommitted changes unrelated to the plan: stop
-- No diff baseline against main: stop
-- Empty changed-file list: stop, and never advise removing the output from `.gitignore` to get past it
 
 ## Out of scope
 
 - Writing the plan, which `plan-feature` owns. This chain starts from one already approved.
 - The behavior of each step, owned by the skill invoked. This skill owns the order and the stop conditions.
-- The ship sequence and the resume path after a stop, both of which `git-ship` owns. That skill is the tail of this chain, invoked at Step 8 rather than copied into it, so the overlap is one body reached two ways rather than two bodies stating one order.
+- The ship sequence and the resume path after a stop, both of which `git-ship` owns. That skill is the tail of this chain, invoked at Step 6 rather than copied into it, so the overlap is one body reached two ways rather than two bodies stating one order.

package/claude/skills/auto-ship/SKILL.md

@@ -1,36 +1,21 @@
 ---
 name: auto-ship
-description: Chains implement → verify → review → ship after a feature plan is approved. Reads the plan the caller names, the plan a named task points at, or the plan for the current branch when none is named, runs the full pipeline in one session, and stops on any failure or non-minor review finding. Use when asked to "autoship", "ship this feature end to end", or "run the chain". Do NOT auto-trigger. Requires an approved plan file.
-disable-model-invocation: true
+description: Chains implement → verify → ship after a feature plan is approved. Reads the plan the caller names, the plan a named task points at, or the plan for the current branch when none is named, runs the full pipeline in one session, and stops on any failure. Use when asked to "autoship", "ship this feature end to end", or "run the chain". Do NOT auto-trigger. Requires an approved plan file.
 metadata:
   family: build
 ---
 
 # Auto ship
 
-Chain the post-plan pipeline in a single run. Every step but the UI checklist has a stop condition. State is always recoverable on stop: code lives on the branch, review output on disk, plan still linked.
+Chain the post-plan pipeline in a single run. Every step but the UI checklist has a stop condition. State is always recoverable on stop: code lives on the branch, plan still linked.
 
 ## Guards
 
-- All `.canon/plans/` and `.canon/review/` reads resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
-- Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. This skill takes the stop rather than the `latest` fallback, since it commits and opens a pull request. If empty, stop: `❌ Detached HEAD. Checkout the feature branch first.` This slug is provisional. It is superseded once `session-worktree` runs, whether at Step 0 or before this chain began. Every later step keys its output on the slug that run resolves, being the worktree, the review receipt, and the branch, regardless of which plan Step 1 reads.
+- All `.canon/plans/` reads resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
+- Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. This skill takes the stop rather than the `latest` fallback, since it commits and opens a pull request. If empty, stop: `❌ Detached HEAD. Checkout the feature branch first.` This slug is provisional. It is superseded once `session-worktree` runs, whether at Step 0 or before this chain began. Every later step keys its output on the slug that run resolves, being the worktree and the branch, regardless of which plan Step 1 reads.
 - Resolve `<plan>` in Step 1, ahead of any other read.
 - If the working tree has uncommitted changes unrelated to the plan, stop: `❌ Uncommitted changes outside the plan. Commit or stash before autoshipping.`
 
-## Diff baseline
-
-Step 6 classifies the changed-file list to decide whether review runs. Resolve the base ref once:
-
-```bash
-git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null
-```
-
-Prefer `origin/main` over local `main`, since a local `main` trailing the remote pulls other people's merged commits into the list.
-
-The baseline is unusable when no merge base resolves against either ref. Stop: `❌ No diff baseline against main. Fetch origin, then re-run autoship.`
-
-The base equalling HEAD stays usable, since nothing need be committed before Step 8. The classifier diffs the base against the working tree, so every slice Step 2 already committed stays in the changed set. Do not port the read-only siblings' `base == HEAD` stop into this skill.
-
 ## Step 0: take the role, then enter a worktree
 
 Invoke `canon:role-worker` first, whatever the worktree state. That skill states the boundaries, the lifetime, and the channel obligations of a session building one branch under one plan, and a dispatched worker reaches the role here and nowhere else. Report it rather than proceeding silently when `canon:role-worker` does not resolve.
@@ -49,7 +34,7 @@ When the invocation argument is a plan path or a bare slug, name the worktree fr
 
 Resolve `<plan>` in this order, stopping at the first match:
 
-1. **Caller-supplied task.** The invocation carried a path under `.canon/tasks/`. If it does not resolve to a file, stop: `❌ No task at <path>. Path was supplied, not derived, so check it and re-run.` Read that task's first `Plan:` line and take what it names as `<plan>`, per `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`, reading `${CLAUDE_SKILL_DIR}/references/tier-failures.md` first for how the pointer resolves and the four stops it can take.
+1. **Caller-supplied task.** The invocation carried a path under `.canon/tasks/`. If it does not resolve to a file, stop: `❌ No task at <path>. Path was supplied, not derived, so check it and re-run.` Read that task's first `Plan:` line and take what it names as `<plan>`, per `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`, reading `${CLAUDE_SKILL_DIR}/references/tier-failures.md` first for how the pointer resolves and the four stops it can take.
 2. **Caller-supplied plan.** The invocation carried something else. Accept it as a plan path or a bare slug, in the same position `session-worktree` tier 0 accepts its name. A bare slug resolves to `.canon/plans/feature-<slug>.md`, and a path is taken as given from the main worktree root. If it does not resolve to a file, stop: `❌ No plan at <path>. Path was supplied, not derived, so check it and re-run.`
 3. **Derived.** `.canon/plans/feature-<slug>.md`, from the `<slug>` the Guards derived. If it does not exist, stop: `❌ No approved plan at .canon/plans/feature-<slug>.md, where <slug> was derived from the current branch, <branch>. The invocation carried no argument, so pass a plan or a task path, or run /plan-feature first.`
 
@@ -61,11 +46,11 @@ Tier 1 stops on a `Plan:` line linking several plans, on a task carrying none, a
 
 Test the shape of whatever `<plan>` resolved to before reading it as one, after all three tiers, since a file resolving under any tier can still be the wrong document.
 
-Check for a `**Files to touch:**` or `## Files to touch` marker per `${CLAUDE_SKILL_DIR}/../../standards/plan.md`, the one section every plan carries structurally and a task never does, where `## Outcomes` and `## Findings` are the task's own. If neither form is present, stop: `❌ <path> carries no plan sections. A plan lives at .canon/plans/feature-<slug>.md, and a task reaches one through its Plan: line only from .canon/tasks/. Point autoship at either and re-run.`
+Check for a `**Files to touch:**` or `## Files to touch` marker per `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`, the one section every plan carries structurally and a task never does, where `## Outcomes` and `## Findings` are the task's own. If neither form is present, stop: `❌ <path> carries no plan sections. A plan lives at .canon/plans/feature-<slug>.md, and a task reaches one through its Plan: line only from .canon/tasks/. Point autoship at either and re-run.`
 
 Read `<plan>` at the main worktree root. This file is the scope for this run.
 
-Its sections and its answer contract are fixed by `${CLAUDE_SKILL_DIR}/../../standards/plan.md`. A blank `- Answer:` accepts the `- Suggested:` line above it, so an unanswered question is a decision this run executes rather than a reason to stop. When this run decides against that suggestion, rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement, leaving the `- Answer:` slot blank, and put the same deviation in one line under the open task's `## Findings`, per `${CLAUDE_SKILL_DIR}/../../standards/plan.md`.
+Its sections and its answer contract are fixed by `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`. A blank `- Answer:` accepts the `- Suggested:` line above it, so an unanswered question is a decision this run executes rather than a reason to stop. When this run decides against that suggestion, rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement, leaving the `- Answer:` slot blank, and put the same deviation in one line under the open task's `## Findings`, per `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`.
 
 ## Step 2: implement
 
@@ -97,37 +82,11 @@ Never read a missing subcommand as clean. Read `${CLAUDE_SKILL_DIR}/references/v
 
 ## Step 5: UI checklist (conditional)
 
-If the diff touches UI files (JSX, TSX, Vue, Svelte, HTML, or CSS under `src/`), invoke `canon:ui-checklist`, then continue to Step 6 whatever it returns, in every run. The Step 8 draft mark holds the merge, so a stop here protects nothing. When it produces a checklist, read `${CLAUDE_SKILL_DIR}/references/ui-checklist.md` for the counts to hold before `git-pr` removes the file.
-
-## Step 6: review
-
-Classify the diff first. Take the union of `git diff --name-only <base>` and `git ls-files --others --exclude-standard`, resolving `<base>` per Diff baseline, then hand that set to the verb rather than reading it against the list below yourself:
-
-```bash
-canon autoship classify --json <path>...
-```
-
-The verb reads names only and touches git not at all. Branch on the record's `decision` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero.
-
-- `skip`. Every path reads as prose and none states agent behavior. Skip review entirely and continue to Step 8.
-- `review`. Invoke `canon:review-branch`. The record names the `file` that decided it and the `test` it failed, `extension` for a path that is not prose and `behavior-path` for prose that states what an agent does.
-- `refused`, carrying reason `no-changes`. The changed set was empty, so take the stop below.
-
-Say in the run whether the verb or the written fallback decided.
-
-An empty list stops the chain rather than reading as prose-only, which it satisfies vacuously: `❌ No changed files to classify. Re-run when the plan has yet to produce its output. When the output is gitignored by design, autoship cannot ship it, so take the work out of the chain.` Never advise removing the output from `.gitignore`, which trades a stopped run for scratch committed into the repository.
-
-### When the verb is absent
-
-Never read an absent subcommand as a skip, since failing open would ship every branch unreviewed. Read `${CLAUDE_SKILL_DIR}/references/verb-absent.md` on meeting one, which carries the written test and the behavior paths it reads.
-
-## Step 7: evaluate findings
-
-Skip this step when Step 6 skipped review. Otherwise read `${CLAUDE_SKILL_DIR}/references/review-findings.md` before opening the review receipt. It carries how every finding splits by origin, which ones this run repairs and which stop the chain, and the one-pass bound on the repair.
+If the diff touches UI files (JSX, TSX, Vue, Svelte, HTML, or CSS under `src/`), invoke `canon:ui-checklist`, then continue to Step 6 whatever it returns, in every run. The Step 6 draft mark holds the merge, so a stop here protects nothing. When it produces a checklist, read `${CLAUDE_SKILL_DIR}/references/ui-checklist.md` for the counts to hold before `git-pr` removes the file.
 
-## Step 8: ship
+## Step 6: ship
 
-Invoke `canon:git-ship`. That body owns the sequence, being the verify gate, memory capture, both doc syncs, staging, the commit grouping, the branch rename, the pull request, and the CI watch, along with the reason each step sits where it does. Read the order there and never here.
+Invoke `canon:git-ship`. That body owns the sequence, being the verify gate, both doc syncs, staging, the commit grouping, the branch rename, the pull request, and the CI watch, along with the reason each step sits where it does. Read the order there and never here.
 
 One thing this chain adds. Mark the pull request as a draft as soon as `git-ship`'s pull request step returns, ahead of its CI watch, naming the number that step returned rather than one resolved by branch. Read `${CLAUDE_SKILL_DIR}/references/draft-mark.md` on reaching that point for the one command that proves the target, marks it, and reads the flag back. A `false` read stops the chain, and never re-issue the mark on it.
 
@@ -137,20 +96,16 @@ Emit the Output block on the wake after `git-ship`'s background CI watch exits o
 
 ## Output
 
-Respond with up to six lines:
+Respond with up to two lines:
 
 ```plaintext
 ✅ Autoshipped (<state>): <PR url>
 🖼️ <N> visual boxes unchecked (<M> taste), owed on the evidence comment of <PR url> to the operator, or to the UI reviewer for the boxes a driver can run
-<N minor findings kept in .canon/review/branch-<slug>.md>
-<N facts routed to context entries>
-<N memories captured in .canon/memory/>
-<the review line memory-capture returned>
 ```
 
-`<state>` is whatever the Step 8 read returned, being `draft` or `ready, unsupervised`, rather than the state the mark asked for.
+`<state>` is whatever the Step 6 read returned, being `draft` or `ready, unsupervised`, rather than the state the mark asked for.
 
-Fill the second line from the counts Step 5 held, and omit it when no checklist was produced. Omit the third line if there were no minor findings, and the fourth if nothing routed. Omit the fifth if `memory-capture` wrote no memory file this session, and the sixth if it returned no review line. Pass that line through verbatim, since a dispatched worker's controller relays it to the operator.
+Fill the second line from the counts Step 5 held, and omit it when no checklist was produced.
 
 This block replaces the one `git-ship` closes on rather than following it, since emitting both reports one run twice and buries the state under a `✅ Shipped` that does not name it.
 

package/claude/skills/auto-ship/references/draft-mark.md

@@ -1,11 +1,11 @@
 ---
 title: Draft mark
-description: The one command auto-ship Step 8 runs as git-ship's pull request step returns, which proves the target is this branch's open pull request, marks it a draft, and reads the flag back
+description: The one command auto-ship Step 6 runs as git-ship's pull request step returns, which proves the target is this branch's open pull request, marks it a draft, and reads the flag back
 ---
 
 # Mark the pull request a draft
 
-Step 8 of `auto-ship`. The session reads this file as `git-ship`'s pull request step returns, ahead of its CI watch.
+Step 6 of `auto-ship`. The session reads this file as `git-ship`'s pull request step returns, ahead of its CI watch.
 
 Run the mark as one command, where the shell proves the target before the mark and reads the flag back after it:
 

package/claude/skills/auto-ship/references/failure-recovery.md

@@ -1,6 +1,6 @@
 ---
 title: Failure recovery
-description: The step an operator resumes from after each auto-ship stop point, since every stop leaves the code on the branch, the review on disk, and the plan linked
+description: The step an operator resumes from after each auto-ship stop point, since every stop leaves the code on the branch and the plan linked
 ---
 
 # Failure recovery
@@ -16,11 +16,7 @@ Every stop point leaves recoverable state. The user resumes manually from the ap
 | Task points at an archived plan            | The work already shipped. Reopen the task against a live plan, or pass that plan's path directly.                                               |
 | Task's `Plan:` pointer resolves to nothing | Repoint the task's `Plan:` line at the plan that exists, then re-run                                                                            |
 | Resolved file carries no plan shape        | Point autoship at a plan under `.canon/plans/feature-<slug>.md` or at a task under `.canon/tasks/`, then re-run                                 |
-| No diff baseline                           | Fetch origin so a merge base resolves against `main`, then re-run autoship                                                                      |
-| Empty changed-file list                    | Re-run once the plan produces tracked output. Ship gitignored output outside the chain, never by tracking it.                                   |
 | Branch collision on worktree entry         | `session-worktree` Step 5 found `<slug>` already as a local branch. Resolve manually (rename or delete the stale branch), then re-run autoship. |
 | Verify fails                               | Read logs, fix manually, run `/git-ship`                                                                                                        |
-| Inherited review findings                  | Fix findings, run `/git-ship`                                                                                                                   |
-| Self-introduced finding survived           | Read the receipt for what the one repair pass left open, fix it, run `/git-ship`                                                                |
 | git-ship fails                             | Inspect hook or remote error, run again                                                                                                         |
 | Draft target is not this branch's          | Nothing was marked. Read the number and `head=` from `git-pr`'s output, confirm they match, then run the mark by hand                           |

package/claude/skills/auto-ship/references/tier-failures.md

@@ -24,6 +24,6 @@ Tier 1 stops on four failures, and each names a different repair:
 - The pointer resolves into a plans archive. Stop: `❌ <path> points at an archived plan, which describes work that already shipped. Reopen the task against a live plan, or pass that plan directly.` Test the resolved path rather than the task's outcomes or its `Pull request:` line, since a stale board gets its ticks wrong and the standard fixes where a shipped pointer lands.
 - The pointer resolves to no file. Stop: `❌ <path> points at <target>, which does not exist. The citation is stale, so repoint the task or pass the plan path directly.`
 
-An archive is `.canon/plans/archive/` and also the two older spellings `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` leaves in place for a project that archived plans before the folder nested, written from a task as `../plans-archive/` and `../.tmp/plans-archive/`. Test all three, since a shipped pointer in a project nobody migrated lands on the older two. Run the archive test ahead of the existence test, so a pointer into an archive that no longer holds the file still refuses as shipped work rather than as a stale citation.
+An archive is `.canon/plans/archive/` and also the two older spellings `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md` leaves in place for a project that archived plans before the folder nested, written from a task as `../plans-archive/` and `../.tmp/plans-archive/`. Test all three, since a shipped pointer in a project nobody migrated lands on the older two. Run the archive test ahead of the existence test, so a pointer into an archive that no longer holds the file still refuses as shipped work rather than as a stale citation.
 
 Each tier fails for a different reason and says so. A supplied path resolving to nothing is a typo, a derived path resolving to nothing is a plan nobody wrote, and a task pointer resolving to nothing is a stale citation the board should have caught.

package/claude/skills/auto-ship/references/ui-checklist.md

@@ -7,14 +7,14 @@ description: What auto-ship Step 5 holds when ui-checklist produces a checklist,
 
 Step 5 of `auto-ship`. The session reads this file when `ui-checklist` has produced a checklist.
 
-The chain continues to Step 6 here in every run, dispatched or hand-run, since the skill cannot tell the two apart and the draft mark at Step 8 holds the merge either way. A stop here used to leave nothing committed, and resuming at `/git-ship` skipped the review at Step 6.
+The chain continues to Step 6 here in every run, dispatched or hand-run, since the skill cannot tell the two apart and the draft mark at Step 6 holds the merge either way.
 
 Count two things in `.canon/tmp/handoff/ui-checklist/<slug>.md` at the main worktree root:
 
 - `<N>`, the `- [ ]` lines
 - `<M>`, how many of those end in `(taste)`
 
-Hold both until the Output block. `git-pr` removes the file once it posts the evidence comment, so a count taken after Step 8 reads nothing.
+Hold both until the Output block. `git-pr` removes the file once it posts the evidence comment, so a count taken after Step 6 reads nothing.
 
 The Output block's second line takes both counts. When every box is a taste box, `<N>` and `<M>` match and the boxes are owed to the operator alone, since a driver reports a taste box as needing a person's eyes rather than passing it, so say the operator and drop the UI reviewer clause.
 

package/claude/skills/auto-ship/references/verb-absent.md

@@ -1,36 +1,12 @@
 ---
 title: Verbs absent from an older binary
-description: What auto-ship Steps 4 and 6 do when the installed canon binary carries no test-order or autoship classify subcommand, including the written review test and its behavior paths
+description: What auto-ship Step 4 does when the installed canon binary carries no test-order subcommand
 ---
 
 # When the verb is absent
 
-Steps 4 and 6 of `auto-ship`. The session reads this file when the installed binary answers either step's verb with a missing subcommand, since each verb ships with the CLI and this body ships with the plugin.
+Step 4 of `auto-ship`. The session reads this file when the installed binary answers the test-order verb with a missing subcommand, since the verb ships with the CLI and this body ships with the plugin.
 
 ## Step 4: test order
 
-The verb ships with the CLI and this body ships with the plugin, matching Step 6's own fallback for the classify verb. Report that the check did not run rather than reading a missing subcommand as clean, and continue to Step 5.
-
-## Step 6: review
-
-The verb ships with the CLI and this body ships with the plugin, so a target holding an older binary meets a missing subcommand. Apply the written test by hand there, and say the fallback decided it.
-
-Never read an absent subcommand as a skip. Failing open is the exact defect the verb closes, and a shell that answers `command not found` reaching a body that skips on anything other than a `skip` record would ship every branch unreviewed.
-
-The skip needs both tests to pass: every changed file matches `*.md` or `*.txt`, and no changed file sits under a behavior path. On a pass, skip review entirely and continue to Step 8. Otherwise invoke `canon:review-branch`.
-
-Behavior paths carry two spellings, the one a surface authors at and the one it reaches a session at, so the rule reads the same in a toolkit and in a project that consumed one:
-
-- `claude/skills/` and `.claude/skills/`
-- `governance/rules/` and `.claude/rules/`
-- `standards/`, which is the authoring root and reaches a reader by resolution rather than by an install, so it carries no `.claude/` spelling
-- `internal/` and `tooling/`, which hold the stack references and the seed documents a target is handed
-- `CLAUDE.md` at the repository root, named as a file because a path prefix reaches nothing that sits in no folder
-
-Markdown under one of them states what an agent does, so a change there is a behavior change wearing a prose extension. Everything outside them is informational, which keeps `docs/`, `README.md`, and `CHANGELOG.md` skipping without naming them. One behavior file sends the whole branch to review, since documentation shipped beside a behavior change does not cancel it.
-
-Informational prose is already gated by `docs-sync`, `canon markdown audit`, and pre-push hooks. Running a code-style review on it burns tokens with no signal.
-
-The list covers this toolkit's authoring layout and the layout it installs, which is not every layout. A project keeping executable prose where neither spelling reaches adds the path, and until it does every branch touching it skips review silently.
-
-The verb reads the same set from `src/autoship/paths.ts`, so a path added here belongs there too and a path added there belongs here. Two copies is what the fallback costs, and it stands until a release retires the written half.
+Report that the check did not run rather than reading a missing subcommand as clean, and continue to Step 5.

package/claude/skills/backlog-triage/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 A backlog only grows while nothing can decline a row. This pass reads every row against the current tree, files one verdict per row for the operator, and later applies what they approved.
 
-The record is an ordinary intake folder at `.canon/intake/<nn>-backlog-triage/`. Read `${CLAUDE_SKILL_DIR}/../../standards/intake.md` before writing any file in it, since it holds the item format, the frontmatter, the index shape, and the answer contract this skill is bound by. Read `${CLAUDE_SKILL_DIR}/../../standards/board.md` and `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` before applying, since the first holds the backlog and the ordering file and the second holds the `Declined:` line.
+The record is an ordinary intake folder at `.canon/intake/<nn>-backlog-triage/`. Read `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` before writing any file in it, since it holds the item format, the frontmatter, the index shape, and the answer contract this skill is bound by. Read `${CLAUDE_SKILL_DIR}/../task-board/references/board.md` and `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md` before applying, since the first holds the backlog and the ordering file and the second holds the `Declined:` line.
 
 ## Guards
 

package/claude/skills/build-in-slices/REQUIREMENT.md

@@ -23,7 +23,7 @@ The ship chain assumed the work arrives uncommitted. `git-ship` ran `git-stage`
 
 ## Must not
 
-- Restate the scope floors `565-behavior` already carries for every session
+- Restate the scope floors of minimal edits and no unrequested features, which a scope call the skill makes already holds
 - Carry simplicity or abstraction rules, which `code-craft` owns
 - Name a feature flag pattern, since the slices of one branch merge as one pull request rather than reaching trunk one at a time
 - Name a framework, a test runner, or a line-count threshold, none of which holds across stacks

package/claude/skills/build-in-slices/references/adopted.md

@@ -30,7 +30,7 @@ External sources were read and filtered rather than imported. This file is the r
 
 **Rule 0, simplicity first, and the abstraction red flags.** Declined because `code-craft` owns when an abstraction earns its place and when to write the plainest code that passes. Restating it here would put two owners on one rule.
 
-**The rest of its scope section.** Declined because `565-behavior` already carries the scope floors every session loads, being minimal edits, no unrequested features, and edits limited to what the user named. Only the noticed list was new.
+**The rest of its scope section.** Declined as a scope call this skill makes: its slices already keep to the plan, and minimal edits, no unrequested features, and edits limited to what the user named restate that in different words. Only the noticed list was new.
 
 **Rule 3, feature flags for incomplete features.** Declined because the slices of one branch merge together as one pull request rather than reaching trunk one at a time, so nothing incomplete is exposed between them.
 

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

@@ -15,9 +15,7 @@ The inverse failure is quieter. A session that assumes a sync will pick up a cha
 
 Being reachable is a separate problem from being right. This is a pure reference whose moment happens inside another skill's run, so nothing brings it up unless a body names it. Three sibling requirement files named it and routed nothing, because Claude Code loads `SKILL.md` as the entry and never opens the sibling. A route lives in a body or it does not exist, and a fourth requirement mention would repeat the same defect.
 
-The two bodies now carrying an inline pointer are `seed-sync` and `canon-operator`, each at the point it runs or prints an overwriting command.
-
-A third gap sits beside the first two, aimed at a different question. `canon --help` lists every top-level verb and `canon docs` emits the toolkit's own reference corpus, but no reference skill pointed a session at either. The one skill that does, `canon-operator`, is user-invoked only and reaches them as a side effect of its own orientation step. A session guessing at a verb's name, or restating what a doc already answers, is the same missing-fact failure the overwrite gap names.
+A third gap sits beside the first two, aimed at a different question. `canon --help` lists every top-level verb and `canon docs` emits the toolkit's own reference corpus, but no reference skill pointed a session at either. No skill does now. A session guessing at a verb's name, or restating what a doc already answers, is the same missing-fact failure the overwrite gap names.
 
 ## Must
 
@@ -39,7 +37,7 @@ A third gap sits beside the first two, aimed at a different question. `canon --h
 
 ## Out of scope
 
-- Executing the sync, which the user runs or `canon-operator` routes
-- Reconciling a customized seed section by section: `seed-sync`
+- Executing the sync, which the user runs
+- Reconciling a customized seed section by section, which an operator does by hand
 - Deciding which stack, rule, or standard a project should install, which the setup skills resolve from live catalogs
-- Diagnosing what a project is behind on, or executing the fix: `canon-operator`
+- Diagnosing what a project is behind on: `target-check`

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

@@ -42,11 +42,11 @@ No list of those paths ships in this body, since a copy would go stale on a diff
 - An interactive run still prompts. `--write` skips the prompt, and `--check` refuses to write even with a TTY.
 - Seeds are user-owned. Dictionary `.txt` files merge and sort. Other seeds are copy-once, so re-seeding a structured file means deleting it and syncing again.
 - No command writes a standard into a project. A `.claude/standards/` folder from an older toolkit is inert, and deleting it costs nothing.
-- For section-level customizations of a seed doc, use the `seed-sync` skill, not `canon ... sync`. It diffs per section and preserves edits.
+- For section-level customizations of a seed doc, merge by hand against the toolkit copy, not through `canon ... sync`.
 
 ## CLAUDE.md
 
-- `CLAUDE.md` is a copy-once seed. No `canon` sync command ever updates it. Reconcile it with the `seed-sync` skill, which diffs the preamble and each section and preserves customizations by default.
+- `CLAUDE.md` is a copy-once seed. No `canon` sync command ever updates it. Merge it by hand against the toolkit copy, keeping the project's customizations.
 
 ## Source of truth
 

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

@@ -19,7 +19,7 @@ The last failure is the session's own effort. Asked to report, a session starts
 - Name the surface and its type, since the toolkit routes on that rather than on the symptom
 - Write the stated fallback for a field the session cannot fill, so an empty field reads as absent rather than as unreported
 - Open a GitHub issue on the toolkit repo through the CLI so the report lands where triage reads it, and print the returned URL on its own line
-- Say which file and which reason when the issue call fails and the report falls back to a local folder, since a silent fallback leaves it where nothing reads it
+- Surface the block and the reason when the issue call fails, since a failure that prints nothing leaves the report where nothing reads it
 - Hold a report the operator marks sensitive, since the issue is public
 - Fall back to printing the block when the CLI is absent, so the report still exists
 

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

@@ -1,6 +1,6 @@
 ---
 name: canon-feedback
-description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback --github`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
+description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
 metadata:
   family: upkeep
 ---
@@ -76,7 +76,7 @@ The destination is a public GitHub issue on the toolkit repo, so the report leav
 Before the pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block, phase-label half included. Nothing else checks what reaches the remote, so this scan is the only gate.
 
 ```bash
-cat <<'EOF' | canon feedback --github
+cat <<'EOF' | canon feedback
 ## Toolkit feedback
 
 ...
@@ -85,20 +85,17 @@ EOF
 
 The CLI opens a GitHub issue on the toolkit repo, labeled `feedback` and each domain label the surface type names, such as `skills` for a plugin skill, and prints the issue URL, which this skill reports back on its own line. It needs `gh` authenticated. `git-issue` is not the route, since it files on the current repository and this report belongs on the toolkit's.
 
-From a toolkit checkout, a call that produces no URL falls back to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the reason on stderr. Say so in the same reply, naming the file and the reason, since a silent fallback leaves the report where nothing reads it. A target project has no such folder, so a failed call there prints the block in chat.
+Read the outcome off stdout, never off the exit code, since a shell wrapper can flatten it. Stdout takes one of three shapes:
+
+- A line opening with `https://` is the filed issue. Report the URL.
+- A block opening with `## Toolkit feedback` is a failed call. The reason is on stderr, so show the block in chat with it and `📋 Paste this into an issue at https://github.com/erclx/canon/issues/new`.
+- Empty stdout is a refusal. Step 3 says how to repair it from stderr.
 
 If `canon` is not on PATH, fall back: print the block in chat and tell the user `📋 Copy the block above into a toolkit-repo session.`
 
 ## Step 3: read what the CLI said back
 
-The command exits 1 and writes nothing on a report it refuses, so a non-zero run is a block to repair rather than a report that shipped. Two refusals reach this step:
-
-- A named missing field. Add that heading with a real value or its stated fallback, then re-run. Do not report the defect as filed.
-- `gh` absent or its call failed. The stderr names which, since installing `gh` and fixing an authenticated call are different repairs. Fall back to printing the block in chat.
-
-A `--github` run from a toolkit checkout whose GitHub call fails warns and writes local scratch instead, which is a report filed on the other route rather than a failure.
-
-## Notes
+A report that was not filed reads one of two ways on stdout, and stderr carries the reason in both:
 
-- `canon feedback` resolves the toolkit root from the running `canon` binary's source location. If multiple toolkit clones exist on the machine, the first `canon` on PATH wins.
-- The local folder is a fallback for a failed issue call, and nothing reads it on a schedule. The issue is the durable record.
+- Empty stdout, with a named missing field on stderr. Add that heading with a real value or its stated fallback, then re-run. Do not report the defect as filed.
+- The block on stdout, with `gh` absent or its call failed on stderr. The stderr names which, since installing `gh` and fixing an authenticated call are different repairs. Show the block in chat with the reason and the paste line from Step 2.

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

@@ -1,32 +1,30 @@
 ---
 name: canon-feedback-triage
-description: Why the feedback queue is read from GitHub rather than local scratch, and why triage routes instead of implementing
+description: Why the feedback queue is read from GitHub rather than local scratch, and why triage files measured items instead of routing or implementing
 ---
 
 # Canon feedback triage requirement
 
 ## Gap
 
-Without this skill, the feedback queue fills and nothing drains it. Reports arrive from projects the toolkit never sees, and a queue nobody reads on a schedule is the same as no queue. The local review folder looks like the right place to read, and it is the wrong one, because that content is per-machine session scratch that any cleanup removes.
+Without this skill, the feedback queue fills and nothing drains it. Reports arrive from projects the toolkit never sees, and a queue nobody reads on a schedule is the same as no queue. A local folder looks like the right place to read, and it is the wrong one, because that content is per-machine session scratch that any cleanup removes.
 
-Triage fails three ways once it starts. Unrelated issues get batched into one branch, so review has to judge several unconnected changes at once and can approve none of them cleanly. An issue needing a plan gets implemented inline from a paragraph of description, which skips the step where scope is argued. And an issue whose report contradicts itself gets a guess rather than a question, so the fix addresses a defect nobody confirmed.
-
-The queue also fails to drain even when the work ships. A fix merged with no link back leaves its issue open, and the next triage re-reads work already done.
+Triage fails three ways once it starts. An issue gets routed straight to a fix from a paragraph of description, which skips the step where scope is argued and the operator's call. An issue whose report contradicts itself gets a guess rather than a question, so the fix addresses a defect nobody confirmed. And the same issue gets filed twice, because two passes cannot see that the board already carries it.
 
 ## Must
 
 - Read the durable queue rather than local session scratch
-- Classify each issue in a fixed order and stop at the first match, stating the class and its one-line reason before routing
-- Route to the skills that own planning, branch naming, and the pull request body rather than restating them
-- Keep one issue to one branch and one pull request
-- Link a fix to its issue so merge closes it, and preserve that link when the body is regenerated
-- Ask on the issue when the report is unreadable, then move on rather than blocking the batch
+- File one measured item per open issue into an intake folder, headed so an answer finds its issue
+- File every open issue the board does not already carry, and name each skipped issue with its carrier
+- Measure each claim against the tree rather than carrying the issue's figures forward
+- Claim the folder through the CLI rather than picking an ordinal by hand
 
 ## Must not
 
-- Batch unrelated fixes into one branch
-- Implement a plan-worthy issue, which stops at the plan handed back to the user
-- Close an issue whose pull request has yet to merge
+- Post to the remote, whether a comment, a close, or a label
+- Implement a fix or write a plan, which the answered item routes to
+- Fill an answer slot, or read an empty one as agreement
+- Write outside the folder it claimed
 
 ## Guards
 
@@ -36,5 +34,6 @@ The queue also fails to drain even when the work ships. A fix merged with no lin
 ## Out of scope
 
 - Filing new feedback: `canon-feedback`
-- Writing the plan a plan-worthy issue needs: `plan-feature`
+- Answering the filed items: `plan-intake-answer`
+- Writing the plan a plan-worthy item needs: `plan-feature`
 - Triage of issues carrying any other label, which surface here by design only under the feedback label