@erclx/canon 5.11.0 → 5.12.0

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.11.0",
+  "version": "5.12.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

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

@@ -21,6 +21,7 @@ Review is the step that varies most. It gets skipped on a diff that needed one,
 - 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
 - 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
 - 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
 

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

@@ -6,7 +6,7 @@ disable-model-invocation: true
 
 # Auto ship
 
-Chain the post-plan pipeline in a single run. Every step 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, review output on disk, plan still linked.
 
 ## Guards
 
@@ -95,11 +95,7 @@ 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`.
-
-If `ui-checklist` produces a checklist, stop: `❌ UI requires visual verification. Checklist at .canon/tmp/handoff/ui-checklist/<slug>.md, which reaches the pull request once /git-ship runs. Verify manually, then run /git-ship.`
-
-If there is nothing to verify visually and nothing shipping untested, continue.
+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
 
@@ -149,10 +145,11 @@ Emit the Output block on the wake after `git-ship`'s background CI watch exits o
 
 ## Output
 
-Respond with up to five lines:
+Respond with up to six 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/>
@@ -161,7 +158,7 @@ Respond with up to five lines:
 
 `<state>` is whatever the Step 8 read returned, being `draft` or `ready, unsupervised`, rather than the state the undo asked for.
 
-Omit the second line if there were no minor findings, and the third if nothing routed. Omit the fourth if `memory-capture` wrote no memory file this session, and the fifth 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. 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.
 
 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/failure-recovery.md

@@ -20,7 +20,6 @@ Every stop point leaves recoverable state. The user resumes manually from the ap
 | 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`                                                                                                        |
-| UI checklist                               | Verify visually, 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                                                                                                         |

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

@@ -0,0 +1,21 @@
+---
+title: UI checklist counts
+description: What auto-ship Step 5 holds when ui-checklist produces a checklist, so the closing block can name the unchecked visual boxes after git-pr has removed the file
+---
+
+# Hold the checklist counts
+
+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.
+
+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.
+
+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.
+
+When `ui-checklist` reports nothing to verify visually, it writes no file, Step 5 holds no count, and the Output block carries no boxes line.

package/claude/skills/git-pr/references/evidence.md

@@ -1,6 +1,6 @@
 ---
 title: Rendered-surface evidence
-description: How git-pr finds the UI checklist and the local server, posts the evidence comparison or the checklist alone, and adds the preview address, for a change that touches a rendered surface
+description: How git-pr finds the UI checklist and the local server, posts the evidence comparison or the checklist alone as the fallback for a git refusal, and adds the preview address, for a change that touches a rendered surface
 ---
 
 # Rendered-surface evidence
@@ -13,7 +13,7 @@ The rendered-surface step of `git-pr`, reached after the final command printed t
 
 When it exists, scan it against `${CLAUDE_SKILL_DIR}/../../standards/publish.md` before either step posts it, the same as the pull request body in the skill's pre-publish scan.
 
-Where it lands is decided by the evidence step below rather than here, since a checklist reads next to the screenshots it annotates and posting it on its own is the fallback for a branch that changed no screenshot.
+Where it lands is decided by the evidence step below rather than here, since a checklist reads next to the screenshots it annotates and posting it on its own is the fallback for a refused render.
 
 ## Find the local server
 
@@ -31,7 +31,7 @@ The verb reads the listening sockets on this machine, keeps those whose process
 
 Pass `--local` to the evidence step only on an `ok` here. The binary answering `ok` is the one carrying the flag, so a binary lacking the verb never meets a flag it would reject.
 
-With both `--checklist` and `--local`, a diff carrying no evidence image still renders `ok`, with the link opening a comment the checklist closes, so a reviewer gets both in one place. A local link with neither an evidence image nor a checklist still reports `no-evidence`, which keeps a branch that changed no rendered surface from getting a comment holding a link and nothing else.
+With a checklist, a diff carrying no evidence image still renders `ok`, and a local link rides in the same comment above the checklist, so a reviewer gets both in one place. A local link with neither an evidence image nor a checklist still reports `no-evidence`, which keeps a branch that changed no rendered surface from getting a comment holding a link and nothing else.
 
 A seeded workflow replaces the line with a note once the pull request closes, so the link does not outlive the branch it points at.
 
@@ -43,13 +43,13 @@ Run the verb once against the number the skill's final command printed. Pass `--
 canon pr evidence <number> --checklist <main-root>/.canon/tmp/handoff/ui-checklist/<slug>.md --local <url> --json
 ```
 
-One call answers both questions because a checklist does not decide `no-evidence`. The verb reports `no-evidence` on a diff carrying no evidence image whether or not a checklist came with it, so the branch below reads the same `reason` it would have read without the flag, and the checklist is folded in only on the path that has a comparison to fold it into. The local link is the one exception, stated in the step above.
+One call answers both questions because a checklist decides `no-evidence`. The verb renders `ok` on a diff carrying a checklist and no evidence image, with a marked body holding the checklist, so the checklist always lands in the one comment a later call finds and edits. Without a checklist, a diff carrying no evidence image reports `no-evidence`.
 
 Pass `--checklist` only for a file that exists. The verb refuses as `unreadable-checklist` on a path it cannot read or one holding nothing, which is a caller bug rather than a transient failure, so stop and repair the path rather than posting a body with the checklist silently dropped.
 
 Read `reason` on the record rather than the exit code.
 
-- `no-evidence`: nothing changed under an `evidence/` segment, so there is no comparison to post and no body was rendered. Say nothing about the evidence and fall through to the checklist step below.
+- `no-evidence`: nothing changed under an `evidence/` segment and no checklist was passed, so no body was rendered. Say nothing about the evidence and move on.
 - `ok`: write `body` to `.canon/tmp/pr/evidence/body-<number>.md` at the main worktree root (resolved the way `session-worktree` does), then post or update the comment:
 
 ```bash
@@ -68,7 +68,7 @@ Any other `reason` is one of the mirrored git refusals (`gh-missing`, `gh-failed
 
 ## Post the UI checklist alone
 
-Run this step only when the evidence step above did not carry the checklist, meaning it reported `no-evidence` or one of the git refusals, and a checklist file exists. A local link sends the checklist through the evidence step instead, so this step runs on a branch with no evidence image only when the local step found no server. Post it as its own comment on `<number>`:
+Run this step only as the fallback, when the evidence step above reported one of the git refusals and a checklist file exists, since every other branch with a checklist rendered `ok` and carried it. The comment this posts carries no marker, so a later `canon pr evidence` call reports no `checklist` for it. Post it as its own comment on `<number>`:
 
 ```bash
 gh pr comment <number> --body-file <main-root>/.canon/tmp/handoff/ui-checklist/<slug>.md
@@ -92,7 +92,7 @@ Deleting the file is what makes the later re-render safe. `git-followup` re-runs
 
 ## Post the preview address
 
-Run this step only when the evidence step above returned `ok` or a checklist was posted, by either step. Either one means the pull request changes a rendered surface, and a reviewer holding a checklist with no screenshots needs the live page most. Otherwise skip it silently.
+Run this step only when the evidence step above returned `ok` or a checklist was posted by the fallback. Either one means the pull request changes a rendered surface, and a reviewer holding a checklist with no screenshots needs the live page most. Otherwise skip it silently.
 
 The evidence comment is already posted, so the reviewer has the screenshots while the deploy runs. Mint the preview against the same `<number>`:
 

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

@@ -9,7 +9,7 @@ description: What the ship chain is for, the gaps it closes, and why it does not
 
 Without this skill, the post-feature sequence runs from memory. Doc sync gets skipped, so the pull request ships with planning docs describing the previous scope, or it runs after staging has already closed and its output never reaches a commit. Chaining by hand is also where a session narrates between steps, which turns one flow into a conversation and invites a decision at every boundary.
 
-The sequence also reaches the remote on work nothing re-checked. This skill is the resume point `auto-ship` names at four of its stop points, including the one a failed verify takes, so the fix the user makes by hand after that stop is pushed with no suite run against it. Every branch shipped so far passed that verify on its first attempt, which is why the path has produced no instance rather than being closed.
+The sequence also reaches the remote on work nothing re-checked. This skill is the resume point `auto-ship` names at three of its stop points, including the one a failed verify takes, so the fix the user makes by hand after that stop is pushed with no suite run against it. Every branch shipped so far passed that verify on its first attempt, which is why the path has produced no instance rather than being closed.
 
 ## Must
 

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

@@ -15,7 +15,7 @@ Run the verify commands `CLAUDE.md` names (lint, typecheck, tests) before the se
 
 When `CLAUDE.md` names no verify command, say so on one line and continue. A project with no suite is not a project with a failing one.
 
-Verify runs ahead of the sync skills so a stop leaves the tree exactly as the user left it. Re-running a suite the caller already ran costs one command, and the path it closes is the one that has no other guard: `auto-ship` verifies at its own Step 3 and then hands four of its stop points straight back here, so a fix made by hand after one of those stops otherwise reaches the remote with nothing re-run.
+Verify runs ahead of the sync skills so a stop leaves the tree exactly as the user left it. Re-running a suite the caller already ran costs one command, and the path it closes is the one that has no other guard: `auto-ship` verifies at its own Step 3 and then hands three of its stop points straight back here, so a fix made by hand after one of those stops otherwise reaches the remote with nothing re-run.
 
 ## Pre-check
 

package/claude/skills/review-craft/references/ui.md

@@ -45,7 +45,7 @@ Take the sha from the row, so the base and head sides are exactly what the comme
 
 Open at most 12 images per pass, filled in this order:
 
-1. Every image a ticked checklist box or the `Seen at:` line names
+1. Every image a ticked checklist box names
 2. The head side of each state at its narrowest and widest captured width, in one theme
 3. The base side, only for a state whose head image looks wrong or whose diff was meant to change appearance
 
@@ -65,7 +65,6 @@ The `## What to look at` block between the `pr-checklist` markers is the author'
 
 - Test each ticked box against an opened image showing the state and width it names. Flag a box whose image contradicts it, quoting the box.
 - A ticked box no image covers is untested rather than confirmed, and the finding says so.
-- Read the `**Widths:**` block's `Seen at:` line against the widths the images carry.
 - Test only the rows the current comment shows. A box ticked on an earlier head can describe images the comment no longer carries.
 - Leave unchecked boxes to the procedure's own read of the description.
 

package/claude/skills/review-pr/SKILL.md

@@ -73,7 +73,7 @@ Read each test file the branch added or changed against the final filter in `can
 
 Then read the description's `## Testing` section, which is the one part of a pull request body this session is positioned to falsify. The branch author cannot see what a sibling branch drove the same day, and the arm list is what settles the claim rather than the diff.
 
-Test every unchecked box against the testing discipline in `${CLAUDE_SKILL_DIR}/../../standards/pr.md`, which reserves an unchecked box for a capability the agent lacks. Raise the box when it names no human at all, when the human it names is a live agent session, or when it names a person for a step the repository ships a harness for, `scripts/sandbox/run.sh` and `scripts/eval/run.sh` being the two. Cost alone is not an answer, since authorizing a spend is the operator's and performing the run is not. A refusal the author actually met is an answer, and it names which one.
+Test every unchecked box against the testing discipline in `${CLAUDE_SKILL_DIR}/../../standards/pr.md`, which reserves an unchecked box for a capability the agent lacks. Raise the box when it names no human at all, when the human it names is a live agent session, or when it names a person for a step the repository ships a harness for, such as `scripts/sandbox/run.sh`. Cost alone is not an answer, since authorizing a spend is the operator's and performing the run is not. A refusal the author actually met is an answer, and it names which one.
 
 Test every ticked box too, bounded to one naming a file or a command. Confirm what it names still exists at `<headRefOid>`, `git show <headRefOid>:<path>` for a file or `git grep <command> <headRefOid>` for a command, rather than re-running what it claims. A box naming neither stays untested, since nothing here can confirm a claim carrying no artifact. A box ticked before a later commit removed or replaced what it names is a `should-fix` finding on the body itself, filed under a `**PR body**` block ahead of the file blocks, since what it corrupts is the merge record rather than a file in the diff.
 

package/claude/skills/ui-checklist/SKILL.md

@@ -34,30 +34,13 @@ Group visual items by feature area. Use `- [ ]` checkbox syntax, and write each
 Write each box so a session driving the running app can run it without guessing:
 
 - **Route.** Name where the box is driven, as a path or the control that reaches it. A box naming no route is driven from the address the driver opens, so a single-page app with no routing needs no invented path. Write "from the page the app opens on" when a state is reached by a sequence rather than a URL.
-- **Width.** Name the width a box is driven at only when the change can make it differ by width, the same test the widths block below uses for omission. A box about copy or color renders the same everywhere, so leave the width off rather than inventing one.
+- **Width.** Name the width a box is driven at only when the change can make it differ by width, such as layout, spacing, or anything responsive. A box about copy, color, or a state that renders the same everywhere leaves the width off rather than inventing one.
 - **Verb.** Open on an action a driver performs, such as "scroll to", "click", "resize to", or "tab to". Never open on "read" or "look at", which name no action.
 - **Taste.** End the line with `(taste)` when the result is a judgment of look or feel rather than a fact a driver can observe. A driver reports such a box as needing a person's eyes instead of passing it.
 - **Setup.** A box needing a state the page does not open in states the setup inline. When a hosted preview cannot reach that state, such as a stopped service or a seeded record, end the line with `(local only)` instead.
 
 The checkbox stays `- [ ]` followed by the action and the result, since the evidence comment carries ticked boxes forward by that shape.
 
-## The widths block
-
-A screenshot shows one width, so a reviewer cannot tell from the picture alone whether any other width was looked at. When a change touches layout, spacing, or anything responsive, put this block above the visual items, since it frames what the screenshots beside it can support:
-
-```markdown
-**Widths:**
-
-Seen at: <the widths the reviewer looked at>
-Not seen at: <the widths nobody looked at, or "none">
-```
-
-Leave both lines for the reviewer to complete. This session cannot verify a width, so the block asks what was seen and never asserts coverage. Fix no width list in the block, since which widths matter belongs to the project.
-
-Keep the `Not seen at:` line even when the answer is "none", so an omission reads as a claim rather than a gap.
-
-Omit the block when the change cannot differ by width, such as copy, color, or a state that renders the same everywhere, the way the missing-test heading is omitted below.
-
 ## The missing-test list
 
 Name every automatable change this branch ships with no test, one per line, with the layer `test-craft` would place it at. Do not write the test and do not read the project's test config to write one against.

package/docs/agents/gate.md

@@ -5,7 +5,7 @@ description: Running the gate this repository verifies a branch with, what the s
 
 # Merge gate
 
-`canon gate run` runs every stage that guards a branch here, in order, stopping at the first stage that finds a fact. `bun run check` and `bun run check:ci` resolve to it, and `scripts/core/update.sh` calls it with `--nested` after a dependency update.
+`canon gate run` runs every stage that guards a branch here, in order, stopping at the first stage that finds a fact. `bun run check` and `bun run check:ci` resolve to it, and the `update` package script runs `bun run check` after a dependency update.
 
 ```bash
 canon gate run

package/docs/agents/hooks.md

@@ -16,6 +16,8 @@ canon hooks post-merge --root "$root"
 | --------------- | ---------------------------------------------------------------------------------------------------- |
 | `--root <path>` | Main worktree root holding the board and the records, resolved from `git worktree list` when omitted |
 
+The base stack ships the same call as its `.husky/post-merge`, behind the same board guard and upgrade bootstrap, so a target that syncs it runs these five steps.
+
 Exit codes: `0` on every path, since a hook failing aborts nothing useful. Lines go to stderr, and stdout stays empty. An ordinary merge prints nothing.
 
 ## The steps

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

@@ -139,8 +139,8 @@ since a target has no rule source of its own that ships nowhere.
 
 It takes `--root <path>` and defaults to the toolkit root, prints nothing on success, and
 reports the reason on stderr with exit 1 when the record names a stack or rule
-that does not resolve. `scripts/core/regen-claude-copies.sh` calls it, and the
-Consumed copies stage of `bun run check` asserts the result is committed.
+that does not resolve. The Consumed copies stage of `bun run check` calls it and
+asserts the result is committed.
 
 ## Whole-project sync
 

package/docs/agents/pr-evidence.md

@@ -46,19 +46,19 @@ image or marks the case new.
 
 `reason` on the record is what a caller branches on, not the exit code:
 
-| Reason                 | What it means                                                                 |
-| ---------------------- | ----------------------------------------------------------------------------- |
-| `ok`                   | A body was rendered. `commentId` is set when a marked comment already exists. |
-| `no-evidence`          | Nothing in the diff carries an `evidence/` segment. An ordinary silent no-op. |
-| `unreadable-checklist` | `--checklist` named a path that could not be read, or one holding nothing.    |
-| `gh-missing`           | `gh` is not on the path, so no pull request could be resolved.                |
-| `gh-failed`            | `gh` could not answer for this repository or branch, or read its comments.    |
-| `no-branch`            | The pull request carries no head branch name.                                 |
-| `no-object-head`       | The pull request object reported no head commit.                              |
-| `no-base`              | GitHub reported no merge base for the pull request.                           |
-| `unreadable-changes`   | GitHub could not list what the pull request changed.                          |
-| `would-empty`          | The render holds no cases and the marked comment holds some. No body.         |
-| `check-writes`         | `--check` was passed with `--preview`, `--local`, or `--checklist`.           |
+| Reason                 | What it means                                                                           |
+| ---------------------- | --------------------------------------------------------------------------------------- |
+| `ok`                   | A body was rendered. `commentId` is set when a marked comment already exists.           |
+| `no-evidence`          | No `evidence/` segment in the diff and no `--checklist` or `--preview`. A silent no-op. |
+| `unreadable-checklist` | `--checklist` named a path that could not be read, or one holding nothing.              |
+| `gh-missing`           | `gh` is not on the path, so no pull request could be resolved.                          |
+| `gh-failed`            | `gh` could not answer for this repository or branch, or read its comments.              |
+| `no-branch`            | The pull request carries no head branch name.                                           |
+| `no-object-head`       | The pull request object reported no head commit.                                        |
+| `no-base`              | GitHub reported no merge base for the pull request.                                     |
+| `unreadable-changes`   | GitHub could not list what the pull request changed.                                    |
+| `would-empty`          | The render holds no cases and the marked comment holds some. No body.                   |
+| `check-writes`         | `--check` was passed with `--preview`, `--local`, or `--checklist`.                     |
 
 `no-evidence` is not a refusal a caller reports. A project on a stack that
 carries no evidence path, such as `base` or `python`, hits this reason on
@@ -76,8 +76,9 @@ shows a reviewer, each field present only when that comment holds it:
 
 These come from the comment already posted, never from the flags the call
 passed, so a skill driving a review reads which address and which checklist a
-reviewer has without parsing the comment itself. A checklist posted on its own
-carries no marker, so the record reports none of the three for it. Reading
+reviewer has without parsing the comment itself. A checklist posted raw, which
+only the fallback for a refused render does now, carries no marker, so the
+record reports none of the three for it. Reading
 them means the thread is read before the `no-evidence` answer too, so an
 unreadable thread refuses as `gh-failed` on both reasons rather than
 reporting the fields absent.
@@ -156,11 +157,11 @@ already holds, the same way the preview address is carried. That is what keeps
 already ticked, since `git-pr` deletes the handoff once the first post reports
 success and no later call has a file to pass.
 
-The option does not decide `no-evidence` alone. A branch with a checklist and
-no changed evidence image still reports `no-evidence`, and the caller posts the
-checklist on its own, which is what it did before this option existed. A
-checklist passed together with `--local` is the exception, covered below. A path
-that cannot be read, or one holding nothing, refuses as
+The option decides `no-evidence` on its own. A branch with a checklist and no
+changed evidence image renders `ok` with a marked body holding the checklist,
+so the checklist always lands in the one comment a later call finds and edits.
+The raw post survives only as the caller's fallback when the render is refused.
+A path that cannot be read, or one holding nothing, refuses as
 `unreadable-checklist` rather than rendering without it: the caller deletes the
 handoff once a post succeeds, so a silently dropped checklist is the only copy
 gone.
@@ -175,8 +176,8 @@ the local address the marked comment already holds, the same as the other two.
 
 The option does not turn `no-evidence` into `ok` on its own. A branch with a
 dev server running and no rendered change would otherwise get a comment holding
-a link and nothing else. Together with `--checklist` it does, so the link and
-the checklist land in one comment rather than the checklist going out alone.
+a link and nothing else. Together with `--checklist` the link and the
+checklist land in one comment.
 `canon docs pr-local` covers where the address comes from and how the line is
 removed at close.
 
@@ -214,9 +215,9 @@ those ask a read to write.
 
 The thread cannot separate a skipped preview step from a failed one. A pull
 request whose deploy run failed or timed out reads as owing a preview, and the
-session that ran it holds the cause. A checklist posted on its own carries no
-marker, so a branch with a checklist and no evidence image never reads as
-owing a preview, though `git-pr` runs the preview step for it. The deploy
+session that ran it holds the cause. A checklist-only branch posts a marked
+comment, so it reads as owing a preview once that comment exists and a deploy
+workflow resolves. The deploy
 workflow is read from the checkout rather than the pull request's head, so a
 pull request that adds or removes its own deploy workflow reads against trunk's.
 

package/docs/agents/tasks-validate.md

@@ -17,7 +17,7 @@ Seven checks run. Collisions reaches one half of the `## Run now` test the board
 | Check      | What it reports                                                                                                         |
 | ---------- | ----------------------------------------------------------------------------------------------------------------------- |
 | Shape      | A row whose cell count disagrees with its table's header, or one stranded behind a table a blank line already closed    |
-| Plan       | A row whose plan citation disagrees with its group or its task file, or a task whose `Plan:` line links several plans   |
+| Plan       | A row whose plan citation disagrees with its group or its task file, or a task whose `Plan:` line lists one plan twice  |
 | Mapping    | A row or backlog line naming no task file                                                                               |
 | Grouping   | A task carrying a row in more than one readiness group, or on both surfaces                                             |
 | Ordering   | A `## Needs a plan` row whose stated position disagrees with where it actually sits, or which states no position at all |
@@ -26,11 +26,11 @@ Seven checks run. Collisions reaches one half of the `## Run now` test the board
 
 Shape runs before any other check reads a row, since a row failing it carries no dependable fields for the rest to check. A blank or prose line closes the table above it, so the walk treats the next pipe line as a fresh header candidate rather than as a continuation. That candidate counts as a header only when the line behind it is a separator carrying the same cell count, and one that fails is `row-untabled`, stranded behind a table that already closed. Cell count still has to match the header on every row that clears that test, and a row whose count disagrees is `row-misshapen`, the shape a dropped pipe or a merged column produces.
 
-The Plan check reads the row and the task file both, because the two are written by different hands and only the task's own `Plan:` line reaches the archive. A row carrying a plan whose task states none is `plan-uncited`, and a pair naming two different plans is `plan-mismatched`. Both sides resolve against the board and against the project root before they compare, so a row writing `../plans/x.md` and a task writing `.canon/plans/x.md` name one file rather than two.
+The Plan check reads the row and the task file both, because the two are written by different hands and only the task's own `Plan:` line reaches the archive. A row carrying a plan whose task states none is `plan-uncited`, and a pair where the row's plan is none of the task's links is `plan-mismatched`. Both sides resolve against the board and against the project root before they compare, so a row writing `../plans/x.md` and a task writing `.canon/plans/x.md` name one file rather than two.
 
 The other two groups have no Plan column, so the same check reads the task file's own `Plan:` line against what the group name claims. A `## Needs a plan` row whose task cites a plan that sits live on disk is `plan-parked`, since the group says no such plan exists and the row is either misplaced or its plan is stale and belongs in the archive. An `## Up next` row whose task cites no live plan is `plan-absent`, since that group says one is written. A plan already archived, or a cited path with no file behind it, reads as not live on both sides. A row whose task file is gone is left to `task-unresolved`. An `## Up next` row with nothing left to build, waiting on an act only a person can take, reports `plan-absent` once its plan archives while the task stays live. That report is expected, since the check reads the task file and not the `Waiting on` prose, so a row in that state moves to `## Needs a plan` or closes.
 
-A task whose `Plan:` line links more than one plan is `plan-several` in every group, and it replaces the `plan-uncited` or `plan-absent` report the line would otherwise draw. The line is there, so saying it is missing would send the reader looking for the wrong fault. The line breaks the one-plan-per-task rule the tasks standard states instead, and `plan-mismatched` does not fit either, since that kind means the row and the task disagree while here the task alone is at fault. The message lists every plan the line links, and the fix is to split the task or drop the extra links.
+A `Plan:` line linking several distinct plans is the shape a sliced task carries, so the checks read the whole line rather than reporting it. A `## Run now` row passes when its plan is any one of the links, and a parked row is judged on whether any link is live: `## Up next` needs one, and `## Needs a plan` reports `plan-parked` when one is. The check adds no sliced marker, so an unsliced task given a second link by hand reads as sliced. `plan-several` now means a line listing one plan twice, compared by the file each link resolves to, so `../plans/x.md` beside `.canon/plans/x.md` counts. It is reported in every group and replaces the `plan-uncited` or `plan-absent` report the line would otherwise draw. The message lists the links, and the fix is to drop the repeat.
 
 Mapping spans two surfaces, because a task sits on `priority.md` when it would plausibly be planned soon and on `backlog.md` otherwise. A row or a backlog line naming no task file is `task-unresolved`, and a file both surfaces name is `row-duplicated` for the reason a task in two groups is: it claims two things about itself and only one can hold. A task file neither surface names is `unplaced` rather than a finding, since that is the normal state between a session filing it and a live orchestrator placing it on the board. One check across both is what lets a task move between them without the move reading as a dropped file.
 

package/docs/target/migrations.md

@@ -62,7 +62,7 @@ The first line reports the plan and the second applies it, relocating each rule
 
 Twenty-five plugin skills dropped their `claude-` prefix for two-word names, so `canon:claude-docs` answers as `canon:context-fold` and `canon:claude-tasks` as `canon:task-board`. A project that installed governance or tooling before that release holds files naming the old ones, and the plugin answers to none of them. A later release renamed `docs-fold` to `context-fold`, since the skill folds a session into the context entries and the task board rather than into `docs/`, and the same sweep carries a project across that rename too. <!-- canon-keep-retired -->
 
-Two of those files run rather than sit there. `.husky/post-merge` prints a command for a person to type, and `.claude/hooks/pr-create-log.sh` hands a session a message naming a skill, so a stale copy tells someone to invoke something that no longer exists. A rule under `.claude/rules/canon/core/` names skills too, though a rule is read rather than run.
+Two of those files run rather than sit there. `.husky/post-merge` runs the `canon hooks post-merge` verb, so a stale copy of the hook calls a binary that may lack it, and `.claude/hooks/pr-create-log.sh` hands a session a message naming a skill, so a stale copy tells someone to invoke something that no longer exists. A rule under `.claude/rules/canon/core/` names skills too, though a rule is read rather than run.
 
 Resync what the toolkit owns, then sweep what the project wrote:
 

package/docs/workflow/ai-workflow.md

@@ -87,7 +87,8 @@ When features are independent, run them in parallel, one worktree and one sessio
 For features on a mature stack, chain the post-plan pipeline in one session. Approve the plan, invoke `canon:auto-ship`, and the skill runs implement → verify → review → ship sequentially.
 
 - Use when the plan is tight and the stack has real verify commands and test coverage
-- Autoship stops on: verify failure after one fix attempt, UI manual checklist non-empty, an inherited review finding above minor, no diff baseline resolving against `main`, an empty changed-file list, or hook failure
+- Autoship stops on: verify failure after one fix attempt, an inherited review finding above minor, no diff baseline resolving against `main`, an empty changed-file list, or hook failure
+- A produced UI checklist does not stop it. The checklist rides to the draft pull request's evidence comment, and the closing block names how many visual boxes are still unchecked and who owes them
 - Every stop leaves recoverable state. Fix and resume with `/git-ship`
 - Skip autoship for auth, migrations, security-sensitive changes, or work where the plan itself is uncertain
 

package/docs/workflow/parallel-features.md

@@ -70,8 +70,8 @@ Past that shape, it checks what a surviving row claims against what the tree hol
 
 Archiving a task carries its plan with it, in the same act. The merge is what settles a plan, and the hook below reaches the archive with nobody watching, so a second call after it would be a second failure point leaving the task archived and the plan live. A task whose plan a sibling still cites archives on its own and leaves the plan live, since moving it on the first task to close strands every other pointer at a path that has gone.
 
-Nothing chained that archive until the `post-merge` git hook landed. Every earlier step fires from `canon:auto-ship` or `canon:git-ship`, both of which finish while the pull request is still open, so a task archived there would close for work that may be abandoned. The board is gitignored, which rules out reading it from anywhere but the machine that pulled. The hook names the board's archive candidates and stays silent otherwise, including on a project with no board.
+Nothing chained that archive until the `post-merge` git hook landed. Every earlier step fires from `canon:auto-ship` or `canon:git-ship`, both of which finish while the pull request is still open, so a task archived there would close for work that may be abandoned. The board is gitignored, which rules out reading it from anywhere but the machine that pulled. The hook archives the task a merged pull request closed, through the same verb the base stack ships to every target, and does nothing on a project with no board.
 
-Candidates rather than closed tasks, because outcomes are marked on the branch. A task can read all `[x]` while its pull request is still open, so `canon:task-board` confirms the work reached `main` before it moves anything, and the hook's own output says that check is still owed. A companion `post-rewrite` hook carries the same announcement for anyone pulling with rebase, which fires that event instead of `post-merge`.
+The archive gates on a pull request number the merge carried and a closed task, because outcomes are marked on the branch and a task can read all `[x]` while its pull request is still open, so `canon:task-board` still confirms the work reached `main` when a person archives by hand. A companion `post-rewrite` hook carries the same steps for anyone pulling with rebase, which fires that event instead of `post-merge`.
 
-It announces and moves nothing, so `canon:task-board` stays the only writer. A shell-side archive would change a gitignored board with no diff to review and no session watching, and `index.md` regenerates from a session hook that a shell `mv` never fires. Both hooks ship with the `base` tooling stack, so a target project running this workflow gets the same trigger.
+The hook archives through `canon tasks archive`, which carries the refusals above, so a task whose pull request has not merged stays where it is. Both hooks ship with the `base` tooling stack, so a target project running this workflow gets the same trigger, and `CANON_SKIP_RECLAIM`, `CANON_SKIP_UPGRADE`, and `CANON_SKIP_PLUGIN_UPDATE` turn off the three steps that act on the machine.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "5.11.0",
+  "version": "5.12.0",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
   "license": "MIT",
   "bin": {
@@ -36,9 +36,8 @@
     "prepare": "husky",
     "check": "bun src/cli.ts gate run",
     "check:ci": "bun src/cli.ts gate run --all --no-write",
-    "update": "./scripts/core/update.sh",
-    "clean": "./scripts/core/clean.sh",
-    "snapshot": "./scripts/core/snapshot.sh",
+    "update": "bun update --interactive && bun run check",
+    "clean": "rm -rf node_modules && bun pm cache rm && bun install",
     "bootstrap": "./scripts/core/bootstrap.sh",
     "canon:sandbox": "canon sandbox",
     "canon:sandbox:reset": "canon sandbox reset",

package/scripts/lib/sandbox-path.sh

@@ -7,7 +7,7 @@
 # both carry the rule sending shared session scratch to the main worktree root,
 # and nothing decides which root wins. A session picking the toolkit writes its
 # output where no manifest reads it, so the run reports success while the verdict
-# reports no writes at all. `scripts/eval/run.sh` keeps its fixture outside the
+# reports no writes at all. The retired eval runner kept its fixture outside the
 # repository for the same reason.
 #
 # Mints a short random per-run identifier the first time it is asked for, then

package/src/commands/pr.ts

@@ -466,17 +466,17 @@ export function register(program: Command): void {
         '--checklist closes the body with a visual checklist, below the',
         'comparison it annotates. A checklist the marked comment already',
         'carries is read back and carried forward the same way the preview',
-        'address is, which keeps a re-render from wiping ticked boxes. It does',
-        'not decide no-evidence: a branch with a checklist and no evidence',
-        'image still reports no-evidence, and the caller posts the checklist',
-        'on its own.',
+        'address is, which keeps a re-render from wiping ticked boxes. It',
+        'turns no-evidence into ok: a branch with a checklist and no evidence',
+        'image renders a marked body holding the checklist, so a later call',
+        'finds and edits that comment.',
         '',
         '--local adds a **Local preview:** line under the hosted preview line,',
         'or opens the body with it when there is none, and is carried forward',
         'the same way. It does not by itself turn no-evidence into ok, so a',
         'branch with a server running and nothing to show posts no link-only',
-        'comment. Together with --checklist it does, so the checklist and the',
-        'link land in one comment.',
+        'comment. Together with --checklist the link and the checklist land in',
+        'one comment.',
         '',
         'Both reasons carry what the marked comment already posted, each field',
         'present only when that comment holds it:',
@@ -484,9 +484,10 @@ export function register(program: Command): void {
         '  local      the **Local preview:** address under it',
         '  checklist  the checklist between its delimiters, ticks included',
         'These come from the comment already posted, never from the flags this',
-        'call passed. A checklist posted on its own carries no marker, so the',
-        'record reports none of the three for it. An unread thread refuses as',
-        'gh-failed on both reasons rather than reporting the fields absent.',
+        'call passed. A checklist the caller posted raw after a refused render',
+        'carries no marker, so the record reports none of the three for it. An',
+        'unread thread refuses as gh-failed on both reasons rather than',
+        'reporting the fields absent.',
         '',
         '--check reads the same changed set and thread, renders no body, and',
         'reports what the ship chain still owes the pull request:',
@@ -1605,14 +1606,15 @@ async function runEvidence(
     return refuseWith('no-base', EVIDENCE_REFUSALS['no-base'], emitJson, root)
   }
 
-  // A local address rides on a checklist or a hosted preview and never opens
-  // a comment alone, so a docs-only branch with a server up posts nothing.
-  const hasChecklistAndLocal =
-    suppliedChecklist !== undefined && opts.local !== undefined
+  // A checklist opens a comment on its own, so it always lands in the marked
+  // comment a later call edits. A local address rides on a checklist or a
+  // hosted preview and never opens one alone, so a docs-only branch with a
+  // server up posts nothing.
+  const hasChecklist = suppliedChecklist !== undefined
   if (
     grouped.kind === 'refused' &&
     opts.preview === undefined &&
-    !hasChecklistAndLocal
+    !hasChecklist
   ) {
     logStep('Skipped')
     logInfo(

package/src/gate/stages.ts

@@ -163,7 +163,11 @@ export const STAGES: readonly Stage[] = [
     id: 'indexes',
     label: 'Indexes',
     checks: [
-      script('regen-indexes.sh', 'Index regen failed'),
+      {
+        kind: 'cli',
+        argv: ['indexes', 'regen'],
+        failure: 'Index regen failed',
+      },
       {
         kind: 'drift',
         pathspec: '*index.md',
@@ -177,7 +181,11 @@ export const STAGES: readonly Stage[] = [
     id: 'consumed-copies',
     label: 'Consumed copies',
     checks: [
-      script('regen-claude-copies.sh', 'Consumed-copy regen failed'),
+      {
+        kind: 'cli',
+        argv: ['gov', 'regen'],
+        failure: 'Consumed-copy regen failed',
+      },
       {
         kind: 'drift',
         pathspec: '.claude/rules',