@erclx/canon 5.67.0 → 5.69.0

package/CHANGELOG.md

@@ -1,5 +1,36 @@
 # Changelog
 
+## [5.69.0](https://github.com/erclx/canon/compare/v5.68.0...v5.69.0) (2026-10-26)
+
+
+### Features
+
+* **app-drive:** keep pasted images as evidence and cite them in plans ([#2757](https://github.com/erclx/canon/issues/2757)) ([89939db](https://github.com/erclx/canon/commit/89939db9be70811f96613a294947efcac2c0ed91))
+* **claude:** retire the plan-ready skill ([#2760](https://github.com/erclx/canon/issues/2760)) ([808806d](https://github.com/erclx/canon/commit/808806d494dee9ae93ef348b1a48e5b50f777871))
+* **governance:** run slow commands in the background by default ([#2762](https://github.com/erclx/canon/issues/2762)) ([ffb86f3](https://github.com/erclx/canon/commit/ffb86f334d9cbd829a329d2576095416f45f0e8f))
+* **gov:** record why each core rule bullet exists in a ledger ([#2769](https://github.com/erclx/canon/issues/2769)) ([f8d4058](https://github.com/erclx/canon/commit/f8d40585f244a58afba0c34a576d52b39e2b93e0))
+* **skills:** draft pick rounds in the board record folder by default ([#2768](https://github.com/erclx/canon/issues/2768)) ([a3cc12a](https://github.com/erclx/canon/commit/a3cc12a80d6a6da60e205be5842f346f81dbe72f))
+* **skills:** draft pick rounds on the design board the project names ([#2759](https://github.com/erclx/canon/issues/2759)) ([6eff8ce](https://github.com/erclx/canon/commit/6eff8ce998e3007e5a2847934c6af4a6b49fba89))
+* **skills:** let a drive session plan the rows its intake produced ([#2758](https://github.com/erclx/canon/issues/2758)) ([0dd775d](https://github.com/erclx/canon/commit/0dd775d3507b094bad9f0c808516b3c288b4b500))
+* **tasks:** wait in the background for a row to become launchable ([#2764](https://github.com/erclx/canon/issues/2764)) ([b45a23a](https://github.com/erclx/canon/commit/b45a23af5301fadd8598afb4d8559c06d7b91354))
+
+
+### Bug Fixes
+
+* **take:** let a take request raise its stepped frame stall limit ([#2771](https://github.com/erclx/canon/issues/2771)) ([140aec3](https://github.com/erclx/canon/commit/140aec340b3e43c12bc67bd74fc96155661bd92b))
+
+## [5.68.0](https://github.com/erclx/canon/compare/v5.67.0...v5.68.0) (2026-10-26)
+
+
+### Features
+
+* **pr:** fold evidence captures whose pixels match their base ([#2749](https://github.com/erclx/canon/issues/2749)) ([cb6bed5](https://github.com/erclx/canon/commit/cb6bed5e5357c777f8f08a0d1c01478efbbe2190))
+* **pr:** name painted paths a pull request changed with no capture ([#2748](https://github.com/erclx/canon/issues/2748)) ([7a167e7](https://github.com/erclx/canon/commit/7a167e7d108474d917db96933a84f336459da5ed))
+* **pr:** show each evidence head at full width with its base folded ([#2745](https://github.com/erclx/canon/issues/2745)) ([1fc207e](https://github.com/erclx/canon/commit/1fc207e3cefa3d9c1a0f2151d7d03867f98090df))
+* **records:** give each video its own record folder ([#2741](https://github.com/erclx/canon/issues/2741)) ([bebc159](https://github.com/erclx/canon/commit/bebc159adfa234728390eadd1e43f09514d20fd0))
+* **take:** post a pointer-drawn reel of a pull request's interactions ([#2742](https://github.com/erclx/canon/issues/2742)) ([84960ab](https://github.com/erclx/canon/commit/84960ab08a7b5dbef11641e931bf045eae3e1829))
+* **take:** write each beat's closing frame as still.jpg ([#2740](https://github.com/erclx/canon/issues/2740)) ([0dca9e8](https://github.com/erclx/canon/commit/0dca9e81a2443faf77148caa8e8721388cfd4ae1))
+
 ## [5.67.0](https://github.com/erclx/canon/compare/v5.66.0...v5.67.0) (2026-10-26)
 
 

package/README.md

@@ -75,7 +75,7 @@ Each domain has a canonical source in this repo and a thin install or sync CLI o
 | Transcripts    | A YouTube transcript with metadata frontmatter                                                        | `canon transcripts <url>` writes it into any repo               |
 | Sandbox        | Scenario scaffolds that provision an isolated project state for verifying each domain flow            | `canon sandbox`                                                 |
 
-The design board lives outside canon in [Frameboard](https://www.npmjs.com/package/frameboard), which `canon:pick-by-eye` drives for each round of candidates.
+The design board lives outside canon in [Frameboard](https://www.npmjs.com/package/frameboard), which `canon:design-pick` drives for each round of candidates.
 
 ### How domains reach you
 

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

package/claude/skills/app-drive/REQUIREMENT.md

@@ -15,8 +15,8 @@ Nothing ties the drive to what the app is for, so a goal goes untried and nobody
 
 - The drive runs from a copy outside the project, and the copy is gone when the drive closes
 - Every requirements goal is driven per persona, or marked not driven with its reason
-- Every finding names its source and its severity, and carries its evidence inside the intake folder
-- The drive files one intake folder, each finding sorted as a bug, a requirements conflict, or a taste call
+- Every finding names its source and its severity, and carries its evidence inside the intake folder, as does every image the operator pastes during the drive
+- The drive files one intake folder, each finding sorted as a bug, a requirements conflict, or a taste call, and a session staying to plan its rows answers it before any row is promoted
 - `canon intake drive-check` fails a drive that skipped a goal, touched the checkout, or left evidence outside the folder
 
 ## Must not
@@ -28,8 +28,8 @@ Nothing ties the drive to what the app is for, so a goal goes untried and nobody
 
 ## Out of scope
 
-- Reading source for roughness, which `ux-audit` owns
+- Reading source for roughness, which `ui-audit` owns
 - Driving one pull request's checklist, which `review-ui` owns
-- Measuring paint and layout cost, which `ux-measure` owns
-- Picking between a now frame and a fix frame, which `pick-by-eye` owns
+- Measuring paint and layout cost, which `ui-measure` owns
+- Picking between a now frame and a fix frame, which `design-pick` owns
 - Messaging the controller and ending the session, which `role-planner` owns

package/claude/skills/app-drive/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: app-drive
-description: Drives a throwaway copy of a built app with the operator, tries every requirements goal per persona, re-checks the last drive's findings, measures each operator ask, sorts each finding as a bug, a requirements conflict, or a taste call, and files the lot as an intake folder that `canon intake drive-check` holds. Use when asked to "drive the app", "kick the tires", "run an app drive", or "drive the build with me", typically after a release or a wave and before planning the next. Do NOT use to read source for UI roughness, which is `ux-audit`, to drive one pull request's checklist, which is `review-ui`, to measure paint or layout cost, which is `ux-measure`, or to fix anything the drive finds.
+description: Drives a throwaway copy of a built app with the operator, tries every requirements goal per persona, re-checks the last drive's findings, measures each operator ask, sorts each finding as a bug, a requirements conflict, or a taste call, and files the lot as an intake folder that `canon intake drive-check` holds. Use when asked to "drive the app", "kick the tires", "run an app drive", or "drive the build with me", typically after a release or a wave and before planning the next. Do NOT use to read source for UI roughness, which is `ui-audit`, to drive one pull request's checklist, which is `review-ui`, to measure paint or layout cost, which is `ui-measure`, or to fix anything the drive finds.
 metadata:
   family: check
 ---
@@ -61,6 +61,7 @@ A drive reaches the app the way its personas do, through the page or through the
 Append each finding to the drive log as it happens, never batched at the end, since a compaction drops what chat alone holds.
 
 - Move each frame a finding cites from scratch into the intake folder's `evidence/`, and cite it by that path
+- Copy each image the operator pastes into `evidence/` in the turn its message arrives, under its finding's number, or under a `ref-` prefix when no finding cites it yet
 - Keep the measured number beside the claim in the log, never only in chat
 - Write `drive.json` into the intake folder in the shape `drive-record.md` sets, with one entry per goal
 
@@ -70,7 +71,7 @@ Give every finding one kind, and keep the severity it was logged with.
 
 - **Bug.** The app breaks a goal or its own contract. It becomes an item whose fix a worker can build, with the repro and the evidence path. `systematic-debugging` owns finding its cause.
 - **Requirements conflict.** The app does what the record says and the operator wants otherwise, or the record contradicts itself. The item carries the drafted diff as text, and the operator decides.
-- **Taste.** The call is settled by looking. The item carries a now frame and a fix frame for a `pick-by-eye` pass, written to the config's `proposals` folder.
+- **Taste.** The call is settled by looking. The item carries a now frame and a fix frame for a `design-pick` pass, written to the config's `proposals` folder.
 
 ## Step 5: file
 
@@ -90,6 +91,15 @@ Close only on the operator's word, while the app stays up for as long as they ke
 4. Run `canon records validate intake <slug>` and fix each `structure` entry it names.
 5. Hand the operator the text of `canon/config/app-drive.toml` built from Step 1's answers, when the project carried none. Never write it, since a tracked file is the operator's or a worker's.
 
+### Planning the drive's rows
+
+Run this tail only when the operator, staying after the close, asks this session to plan the drive's rows. The session holds measurements and calls the intake records only as outcomes, so a drive the operator leaves at the close ends there.
+
+1. Answer the intake's `You:` slots with `plan-intake-answer` before any row is promoted from it.
+2. Send the controller the ready list, naming no item whose `You:` slot is still open, and say this session is planning those rows, so it holds a cold planner for each.
+3. Wait for the controller to file the rows and name each back. Plan only a row named to this session, and write no task file.
+4. Plan each named row under `plan-feature`, then link it with `canon tasks plan-link` and announce it per `role-planner` before starting the next.
+
 ## Output
 
 Emit the full relative path of every file written, the drive-check `reason`, and the routing counts.
@@ -100,7 +110,7 @@ Emit the full relative path of every file written, the drive-check `reason`, and
 **Drive:** <N> goals across <P> personas, <F> findings (<B> bugs, <R> requirements conflicts, <T> taste)
 **Check:** drive-check clean, worktree removed
 
-Next: /plan-intake-answer to answer the You: slots from here, then /task-board to promote what is ready
+Next: /plan-intake-answer to answer the You: slots from here, then /task-board to promote what is ready, or ask this session to plan the rows per Planning the drive's rows
 ```
 
 ## What this delegates
@@ -108,5 +118,5 @@ Next: /plan-intake-answer to answer the You: slots from here, then /task-board t
 - The controller messages, the talk clause, and the session's end: `role-planner`
 - The intake folder's shape and its routing test: `plan-intake`
 - The cause of a bug: `systematic-debugging`
-- The pick between a now frame and a fix frame: `pick-by-eye`
+- The pick between a now frame and a fix frame: `design-pick`
 - The voice of every recorded passage: `write-human`

package/claude/skills/app-drive/references/drive-record.md

@@ -20,6 +20,17 @@ Write the log to `evidence/drive-log.md` inside the intake folder, one line per
 - `<result>` carries the number read off the page or the app when the claim has one, such as `scrollWidth 436 against clientWidth 320`
 - A goal tried and passed takes a line too, as `[pass] [goal]`, so the next drive can tell a goal checked from one skipped
 
+### Operator images
+
+Operator images count as evidence on arrival. One showing a finding takes that finding's number and is cited from that finding's line, while one no finding cites yet is a reference shot with a log line of its own.
+
+```plaintext
+- ref-<nn>. [operator] <what the image shows>. Evidence: evidence/ref-<nn>-<name>.png
+```
+
+- `ref-<nn>` numbers reference shots apart from findings, so a later finding citing one keeps the path it already has
+- Keep the pasted file's own extension when it is not a PNG
+
 ## Severity
 
 Each finding takes one level, judged by what the persona loses.
@@ -52,7 +63,7 @@ Write it to the intake folder root before the close. `canon intake drive-check`
 
 - `goals` holds one entry per `## Goals` bullet, with the bullet's text. A bold label and a trailing period may stay or go, since the check strips both.
 - `status` is `driven` or `not-driven`, and a `not-driven` entry carries the `reason` the goal could not be reached
-- `evidence` lists every frame a finding cites, each a path under `evidence/` relative to the intake folder
+- `evidence` lists every frame a finding cites and every image the operator pasted, reference shots included, each a path under `evidence/` relative to the intake folder
 - `worktree` is the throwaway worktree's path, which the check fails on while it still exists
 
 ### What the check fails

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

@@ -48,9 +48,9 @@ Each verb here has a skill that owns the job. Load the skill rather than driving
 | Render an HTML source to a PNG               | `canon capture`     | `canon:design-identity`     |
 | Serve a directory and print the link         | `canon serve`       | none                        |
 | Report one computed property across routes   | `canon inventory`   | `canon:target-check`        |
-| Walk a page through interactions and measure | `canon drive`       | `canon:ux-measure`          |
+| Walk a page through interactions and measure | `canon drive`       | `canon:ui-measure`          |
 | Drive the pinned agent browser               | `canon browser`     | `canon:review-ui`           |
-| Film a web app with a click log and camera   | `canon take`        | `canon:ui-record`           |
+| Film a web app with a click log and camera   | `canon take`        | `canon:ui-film`             |
 | Fetch a YouTube transcript                   | `canon transcripts` | `canon:youtube-transcripts` |
 
 The design board is Frameboard, a separate CLI outside canon, so a board job runs a `frameboard` verb rather than a `canon` one.

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

@@ -29,6 +29,6 @@ Asked to report, a session also starts diagnosing, which spends the context the
 ## Out of scope
 
 - Fixing the defect, which happens in the toolkit repository against its own source
-- Draining the queue this fills, which `canon-feedback-triage` owns
+- Draining the queue this fills, which the toolkit's maintainers do in its own repository
 - Filing an issue against the current project, which `git-issue` owns
 - Complaints about tooling the toolkit does not own

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

@@ -7,7 +7,7 @@ metadata:
 
 # Canon feedback
 
-Format a `## Toolkit feedback` block from the current session, then open it as a GitHub issue on the toolkit repo, labeled `feedback` plus the domain label its surface type names. `canon-feedback-triage` reads that queue.
+Format a `## Toolkit feedback` block from the current session, then open it as a GitHub issue on the toolkit repo, labeled `feedback` plus the domain label its surface type names. The toolkit's maintainers triage that queue.
 
 ## Guards
 

package/claude/skills/design-identity/REQUIREMENT.md

@@ -15,7 +15,7 @@ A session building this alone restates the render-and-pick loop from scratch, wh
 
 - The icon size sequence and the write folder come from the project's own head, manifest, or static-asset convention before a stated default, and the run names which one decided
 - Every arm is drafted inside the card frame, so one pick settles the mark's shape and its composition together
-- The render, hand-off, pick, and loop follow `pick-by-eye` rather than a copy of it
+- The render, hand-off, pick, and loop follow `design-pick` rather than a copy of it
 - The final mark lands as its own SVG source, not only baked into a raster
 - Every final size and the card render in one capture call, each landing at its literal target size
 
@@ -23,12 +23,12 @@ A session building this alone restates the render-and-pick loop from scratch, wh
 
 - Draft a mark the operator did not ask for, or mutate an existing logo file, which is a plain edit
 - Add a logo section to the design document's fixed section set, which its parser reads as a fixed key set
-- Modify `pick-by-eye` or `canon capture`, which this skill composes
+- Modify `design-pick` or `canon capture`, which this skill composes
 - Be taken as reached by more than an operator typing its name, which a later review reads back rather than assumes
 
 ## Out of scope
 
-- The render, hand-off, pick, and loop mechanics, which `pick-by-eye` owns
+- The render, hand-off, pick, and loop mechanics, which `design-pick` owns
 - Carrying a picked direction into the design document, which `design-record` owns
-- Auditing an implemented UI against its tokens, which `ux-audit` owns
+- Auditing an implemented UI against its tokens, which `ui-audit` owns
 - Wiring the produced files into the project's head or manifest, which the operator owns

package/claude/skills/design-identity/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-identity
-description: Drafts a project's logo mark through pick-by-eye's render-and-pick loop, then composes the picked mark into an icon sequence and a 1200x630 social card. Use when asked to "make a logo", "design a logo mark", "create a favicon", "build the icon set", "generate a social card", "make an og:image", or "draft the logo and social card together". Do NOT use to mutate an existing logo file directly, which is a plain edit, or to record the mark's construction rules in DESIGN.md, which is out of scope.
+description: Drafts a project's logo mark through design-pick's render-and-pick loop, then composes the picked mark into an icon sequence and a 1200x630 social card. Use when asked to "make a logo", "design a logo mark", "create a favicon", "build the icon set", "generate a social card", "make an og:image", or "draft the logo and social card together". Do NOT use to mutate an existing logo file directly, which is a plain edit, or to record the mark's construction rules in DESIGN.md, which is out of scope.
 metadata:
   family: generate
 ---
@@ -60,7 +60,7 @@ Announce which tier decided, naming the tier rather than the path alone, so the
 
 ## Step 4: name the decision and the arms
 
-Follow `${CLAUDE_SKILL_DIR}/../pick-by-eye/SKILL.md` Step 1, with the decision fixed rather than derived: "the project's logo mark and its composition into the social card." Vary the mark's shape or style across arms, keeping the card's type and layout fixed, per that skill's one-property rule.
+Follow `${CLAUDE_SKILL_DIR}/../design-pick/SKILL.md` Step 1, with the decision fixed rather than derived: "the project's logo mark and its composition into the social card." Vary the mark's shape or style across arms, keeping the card's type and layout fixed, per that skill's one-property rule.
 
 - Draft each arm inside the 1200x630 card frame, mark and type together, and add it with `frameboard frame add <page>/arm-<id> --width 1200 --height 630`, so one pick settles shape and composition
 - Arm 0 is the current mark when the Step 3 folder already holds a logo file (`favicon.svg`, `favicon.ico`, `logo.svg`, or similar). Arms start at 1 otherwise.
@@ -68,13 +68,13 @@ Follow `${CLAUDE_SKILL_DIR}/../pick-by-eye/SKILL.md` Step 1, with the decision f
 
 ## Step 5: draft, render, pick, and loop
 
-Follow `${CLAUDE_SKILL_DIR}/../pick-by-eye/SKILL.md` Steps 2 through 5 against the arms from Step 4: draft the arms as frames on a Frameboard page, render and hand off, take the pick, and loop on it.
+Follow `${CLAUDE_SKILL_DIR}/../design-pick/SKILL.md` Steps 2 through 5 against the arms from Step 4: draft the arms as frames on a Frameboard page, render and hand off, take the pick, and loop on it.
 
-The final icon and card renders below are not arms, so they stay off the board. Call the folder they render from `<dest>`, being `.canon/tmp/<slug>/` under the slug `pick-by-eye` Step 1 derived, which is where this project puts every temporary write.
+The final icon and card renders below are not arms, so they stay off the board. Call the folder they render from `<dest>`, being `.canon/tmp/<slug>/` under the slug `design-pick` Step 1 derived, which is where this project puts every temporary write.
 
 ## Step 6: finalize the mark and the icons
 
-This step and Step 7 replace `pick-by-eye`'s own Step 6 items 1 and 2, since the pick here produces several final files rather than one applied surface. Its archive capture, its page delete, and its server stop still run, after Step 7.
+This step and Step 7 replace `design-pick`'s own Step 6 items 1 and 2, since the pick here produces several final files rather than one applied surface. Its archive capture, its page delete, and its server stop still run, after Step 7.
 
 1. Extract the picked arm's `.mark` markup as the final vector source. Write it to `<write-folder>/favicon.svg`.
 2. Under `<dest>/render/`, write one `icon-<w>x<h>.html` page per Step 2 size, carrying the picked `.mark` markup in an element with the shared class `.render`.
@@ -112,7 +112,7 @@ It takes its own call because Step 6's batch is already captured by the time thi
 
 ### Closing the scratch folder and the board
 
-Delete `<dest>` once both captures land, then close the board through `pick-by-eye` Step 6 items 3 to 8, which archive every arm and delete the pages the run added. The route is not a leftover variant, since it holds the arm the operator picked.
+Delete `<dest>` once both captures land, then close the board through `design-pick` Step 6 items 3 to 8, which archive every arm and delete the pages the run added. The route is not a leftover variant, since it holds the arm the operator picked.
 
 A project whose card was generated before this route existed keeps its PNG. Say so rather than regenerating it, since the pick loop spends attention on a file nobody complained about, and the next real edit picks up the route.
 
@@ -132,7 +132,7 @@ Card source: <the route, captured through the card server|a scratch page, since
 
 Cite these rather than restating them.
 
-- `pick-by-eye` owns Steps 1 through 5 of the render-and-pick loop, cited above
+- `design-pick` owns Steps 1 through 5 of the render-and-pick loop, cited above
 - `canon:design-record` carries a picked direction into `canon/DESIGN.md`. This skill only reads it.
 - `canon capture` owns the render mechanics, its font refusal, its fixed 2x scale, and its reported dimensions. It reads an `http(s)://` source, where `--out` names the PNG.
 - The `astro` tooling stack owns the card route's scaffold, its second config, and the exclusion check, read with `canon tooling reference astro`. This skill writes into the route and never reshapes it.

package/claude/skills/{pick-by-eye → design-pick}/REQUIREMENT.md

@@ -1,15 +1,15 @@
 ---
-name: pick-by-eye
+name: design-pick
 description: Why a decision settled by looking needs its own surface, and where its boundary against the planning, audit, measurement, and recording skills falls
 ---
 
-# Pick by eye requirement
+# Design pick requirement
 
 ## Gap
 
 Without this skill, a session facing a decision settled by looking describes the options in prose or ships one answer to a taste call. The operator never sees what they chose between. A drafted set varies several properties or the wrong layer, sits in the real surface, and mixes themes and widths, so no pick names what decided it.
 
-The evidence fails as well. Arms get reported without being rendered or judged, a driver finding reads as a verdict, and the pick question arrives with no address to look at. Renders land in scratch, each round overwrites the last, and the losing arms vanish with the run's pages.
+The evidence fails as well. Arms get reported unrendered or unjudged, a driver finding reads as a verdict, and the pick question arrives with no address to look at. Renders land in scratch, each round overwrites the last, and the losing arms vanish with the run's pages. Rounds drafted off the synced board need redrawing.
 
 ## Must
 
@@ -17,7 +17,7 @@ The evidence fails as well. Arms get reported without being rendered or judged,
 - Each round is one Frameboard page of frames at their judged widths, themed by the board toggle and captured once as a composite, with the link ahead of the first pick question
 - Every arm is rendered and judged against a stated bar before handover, and a missing browser or a board that will not start is reported as a refusal
 - The pick comes through the structured question surface with the recommendation first and every option's cost, and the winner lands in one change
-- Every round stays openable on its own page until the pick, and the picked round's arms are captured into the citing record at the main root before the run's pages go
+- Rounds sit on the board the design config names, each openable until the pick, and the picked arms are archived at the main root before the run's pages go
 
 ## Must not
 
@@ -30,6 +30,6 @@ The evidence fails as well. Arms get reported without being rendered or judged,
 ## Out of scope
 
 - Planning the work once the answer is settled, which `plan-feature` owns
-- Finding roughness by reading source, which `ux-audit` owns
-- Measuring what a running interface costs to paint, which `ux-measure` owns
+- Finding roughness by reading source, which `ui-audit` owns
+- Measuring what a running interface costs to paint, which `ui-measure` owns
 - Listing what to look at on a change already made, which `ui-checklist` owns

package/claude/skills/{pick-by-eye → design-pick}/SKILL.md

@@ -1,15 +1,15 @@
 ---
-name: pick-by-eye
-description: Drafts several candidates for a decision judged by looking, lays them out side by side as frames on one Frameboard page, hands the operator the address, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, or to write what to look at on a change already made, which is `ui-checklist`.
+name: design-pick
+description: Drafts several candidates for a decision judged by looking, lays them out side by side as frames on one Frameboard page, hands the operator the address, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ui-audit`, to measure what a running interface costs to paint, which is `ui-measure`, or to write what to look at on a change already made, which is `ui-checklist`.
 metadata:
   family: decide
 ---
 
-# Pick by eye
+# Design pick
 
 Some decisions are settled by looking rather than by reasoning, and no draft is wrong until one is picked. Every step here puts several candidates in front of the operator and keeps the real surface untouched until they have chosen.
 
-The candidates live on a Frameboard board at `.canon/canvas/`, in a project named `picks` so rounds never mix with an operator's project. Read `${CLAUDE_SKILL_DIR}/references/board.md` before the first `frameboard` verb, for the flags every verb carries and how a selection resolves.
+The candidates live on the Frameboard board the project names, in a project of their own so rounds never mix with the operator's frames. Read `${CLAUDE_SKILL_DIR}/references/board.md` before the first `frameboard` verb, for how `<board>` and `<project>` resolve, the flags every verb carries, and how a selection resolves.
 
 ## Guards
 
@@ -34,7 +34,7 @@ Inside a live `plan-groundwork` track, renders land in the track's own `evidence
 Every arm of a round sits as one frame on one board page, side by side. The operator judges that page, never a set of separate images compared from memory.
 
 1. Start the board the way `references/board.md` states, unless this run already has. Note whether this run started the server, read off `reused`, since Step 6 ends only a server this run started.
-2. Read `frameboard list --root <board> --json` with no `--project`, so it lists every project. Run `frameboard project add picks --root <board> --json` when it lists no `picks`.
+2. Read `frameboard list --root <board> --json` with no `--project`, so it lists every project. Run `frameboard project add <project> --root <board> --json` when it lists no `<project>`.
 3. Add the round's page with `frameboard page add <page>` and record its `ref` on the run's list of pages. A `name-taken` refusal means the name is somebody else's, so take the next free suffix.
 4. Add each arm with `frameboard frame add <page>/arm-<id> --width <px> --height <px> --x <px> --y <px>`, placing the frames in one row in arm order. Step 6's archive keys on the `arm-<id>` names.
 5. Write each arm's whole document to the `path` the add verb reported. From a linked worktree, take the heredoc route `session-worktree` gives for a main-root write.
@@ -72,7 +72,7 @@ Vary one property across the arms, since a pick cannot say which of three differ
 Render the page and look at what came back before handing anything over:
 
 ```bash
-frameboard capture --page <page> --composite --root <board> --project picks --json
+frameboard capture --page <page> --composite --root <board> --project <project> --json
 ```
 
 - Point `--out` at `evidence/<slug>/renders/` inside a live track, and leave the board's default elsewhere. Step 6 archives the picked round alone.
@@ -118,15 +118,23 @@ Read the selection when the answer points at the board, such as "the selected on
 2. Close out any document stating the decision as open, in the same change, naming the winner and the arms that stayed defensible. Skip this where nothing stated the decision.
 3. Hand the winning frame's ref to `canon:design-record`, which lands it in the project's design record. Report it rather than proceeding silently when that skill does not resolve.
 4. Capture the picked round's frames with `frameboard capture --page <page> --out <canon-dir>`, keeping the losing arms as a revert record. Report each image's `path` off the record.
-5. Resolve `<canon-dir>` as `.canon/` against the main worktree root, since shared session scratch resolves there. Frameboard appends the project and page, so the archive lands at `.canon/picks/<page>/`.
-6. Delete every page on the run's list with `frameboard page delete <page>`. Touch no page the run did not add, whatever its name, and never remove a page folder by hand.
+5. Resolve `<canon-dir>` as `.canon/` against the main worktree root, where shared session scratch resolves. Frameboard appends the project and page, so the archive lands at `.canon/<project>/<page>/`.
+6. Delete every page on the run's list with `frameboard page delete <page>`, except a picked page on a named board. Touch no page the run did not add, and never remove a page folder by hand.
 7. End the serve command if this run started it, since Frameboard carries no stop verb. Leave a server the operator started running.
 8. Leave the renders in a live track's `evidence/<slug>/renders/`, since `plan-groundwork` treats evidence as durable.
-9. Report each page whose delete is refused, naming its `ref` and the `error.code`. The pick is applied either way.
+9. Report each page or frame whose delete is refused, naming its `ref` and the `error.code`. The pick is applied either way.
 10. Report every surface that changed, each on its own line, name the winning arm by its id and its cost, and report the archive path.
 
 The picked round is the final one unless Step 4 resolved a revert. Archiving any other page lets item 6 delete the winning arm with nothing kept, and a variant left on the board is a second design nobody maintains.
 
+### On a named board
+
+A board `canon/config/design.toml` names is the one the project's design sync reads, and once `design-record` lands the pick, the sync's mapping points at the winning frame. Deleting that page leaves a later redraw nothing to read.
+
+- Keep the picked round's page and its winning frame
+- Delete each losing arm on it with `frameboard frame delete <page>/arm-<id>`, after item 4's capture has archived it
+- Delete every other page on the run's list as item 6 states
+
 ## Reading a measurement
 
 A capture proves appearance and a measurement proves a relationship, so reach for the second whenever the claim is a number, such as a contrast ratio, a column width, or a tap target. `canon drive` runs the probes and ships the failure modes each one carries.
@@ -142,7 +150,7 @@ A capture proves appearance and a measurement proves a relationship, so reach fo
 Cite these rather than restating them. A step reimplemented here rots against the skill that owns it.
 
 - `plan-feature` plans the work once the pick is made, and declares the pull request boundary that plan carries
-- `design-record` lands the winning frame in the reference folder and its values in the design document, and runs before item 6 deletes the page its sync reads
+- `design-record` lands the winning frame in the reference folder and its values in the design document, and runs before item 4's capture and item 6's deletes, which keep the picked page on named boards
 - `design-taste` carries the layer catalog, the ordering, grey-boxing, and the defaults an arm should reach past
 - `write-human` carries the voice for any copy an arm puts in front of a reader
 

package/claude/skills/{pick-by-eye → design-pick}/references/board.md

@@ -1,12 +1,18 @@
 # The Frameboard board
 
-Read before the first `frameboard` verb a `pick-by-eye` run sends. It carries where the board sits, how the verbs are reached, how the server starts, and how a selection resolves to an answer.
+Read before the first `frameboard` verb a `design-pick` run sends. It carries where the board sits, how the verbs are reached, how the server starts, and how a selection resolves to an answer.
 
 ## Reaching the board
 
-Resolve `<board>` as `.canon/canvas/` against the main worktree root, the way `session-worktree` resolves it, since a linked worktree holds no copy of the gitignored folder.
+Resolve `<board>` and `<project>` from the `board` and `project` keys of `canon/config/design.toml`, read at the main worktree root per `${CLAUDE_SKILL_DIR}/references/design-config.md`. A missing file or key falls back to `.canon/board/` and `picks`.
 
-- Pass `--root <board> --project picks --json` to every verb unless the step says otherwise, so no verb relies on the only-project default
+- Stop before starting a board when `<board>` came from that fallback, `.canon/board/` is absent, and `.canon/canvas/` exists
+- Report `❌ The board is still at .canon/canvas/. Run canon migrate record-layout --write, then re-run.` on that stop
+- A board started there drafts on an empty page set and leaves the migration a standing collision
+
+Resolve `<board>` against the main worktree root, the way `session-worktree` resolves it, since a linked worktree holds no copy of the gitignored folder.
+
+- Pass `--root <board> --project <project> --json` to every verb unless the step says otherwise, so no verb relies on the only-project default
 - Where `frameboard` is not on PATH, run every verb as `bunx -y frameboard@0.6 <verb>`. Say so once and keep that form for the run.
 - The pin holds the minor, since record shapes move across a pre-1.0 minor
 
@@ -30,13 +36,13 @@ frameboard serve --root <board> --no-open --tokens <stylesheet> --json
 
 Read `frameboard selection --root <board> --json` when the operator's answer points at the board, such as "the selected one". Resolve it against the record's `project` and `page` as well as its `frames`, since every round reuses the `arm-<id>` names.
 
-| Selection                                                     | Reading                                                  |
-| ------------------------------------------------------------- | -------------------------------------------------------- |
-| One frame in `frames`, on the current round's page in `picks` | The pick                                                 |
-| One frame in `frames`, on an earlier round's page             | A revert, so name the round back before acting           |
-| An `element` inside a picked frame                            | A correction the loop carries by its `index` and `hash`  |
-| Several entries in `frames`                                   | Ask which one rather than taking the first               |
-| Empty `frames`, another project, or a page the run never made | No answer, so ask again rather than guess                |
-| `tabs: 0`, or a `server-not-running` refusal                  | No board is open, so hand the address over and ask again |
+| Selection                                                         | Reading                                                  |
+| ----------------------------------------------------------------- | -------------------------------------------------------- |
+| One frame in `frames`, on the current round's page in `<project>` | The pick                                                 |
+| One frame in `frames`, on an earlier round's page                 | A revert, so name the round back before acting           |
+| An `element` inside a picked frame                                | A correction the loop carries by its `index` and `hash`  |
+| Several entries in `frames`                                       | Ask which one rather than taking the first               |
+| Empty `frames`, another project, or a page the run never made     | No answer, so ask again rather than guess                |
+| `tabs: 0`, or a `server-not-running` refusal                      | No board is open, so hand the address over and ask again |
 
 Pass the element's `hash` to `frameboard edit --hash` with its `index`. A frame rewritten since the operator picked refuses with `stale-address` rather than landing on another element, so ask for the pick again on that refusal.

package/claude/skills/design-pick/references/design-config.md

@@ -0,0 +1,33 @@
+---
+title: Design config
+description: The canon/config/design.toml keys board and project, their defaults, and how a design-pick run resolves the board it drafts on
+---
+
+# Design config
+
+Read before the first `frameboard` verb a `design-pick` run sends. A project names the Frameboard board its design sync reads in `canon/config/design.toml` at the main worktree root, and the run reads that file and never writes it.
+
+```toml
+board = ".canon/board"
+project = "picks"
+```
+
+## Keys
+
+| Key       | Holds                                                   | Default         |
+| --------- | ------------------------------------------------------- | --------------- |
+| `board`   | The board folder a round drafts on, under the main root | `.canon/board/` |
+| `project` | The Frameboard project a round's pages go in            | `picks`         |
+
+Each key falls back on its own, so a file naming `board` alone moves the board and keeps the project at `picks`.
+
+- Resolve `board` against the main worktree root even when the run sits in a linked worktree, since the board folder is gitignored and a linked worktree holds no copy of it
+- Leave `project` at `picks` on a named board unless the operator wants otherwise, so rounds sit on the board the sync reads and stay apart from the accepted frames
+- Stop on a file that does not parse or a key that is not a string, naming the file's path. Falling back there would draft the round where the sync never looks.
+- The archive lands at `.canon/<project>/<page>/`, so it follows `project`. Stop on a `project` naming a `.canon/` folder another record owns, such as `plans` or `tasks`.
+
+## When the file is absent
+
+The run drafts on `.canon/board/` in `picks`, the folder Frameboard keeps its design board in, and asks nothing.
+
+Set the file when the project's design sync reads a board other than `.canon/board/`. A round drafted there lands through `design-record` without a redraw, and Step 6 of the skill body keeps the winning page for the sync's mapping.

package/claude/skills/design-record/REQUIREMENT.md

@@ -24,10 +24,10 @@ Each project invents its own grouping, and its index restates the file tree rath
 - Write, copy, or delete a reference file by hand, or capture frames in place of a missing sync
 - Land a candidate the operator has not picked
 - Restate when a pick lands against the build, which the design-reference rule states
-- Be reached only by the author typing its name, since a pick from `pick-by-eye` should hand off to it
+- Be reached only by the author typing its name, since a pick from `design-pick` should hand off to it
 
 ## Out of scope
 
-- Drafting candidates and taking the pick, which `pick-by-eye` owns
+- Drafting candidates and taking the pick, which `design-pick` owns
 - Drawing, selecting, and capturing frames on a board, which Frameboard owns
 - Judging whether a design is good, which `design-taste` owns

package/claude/skills/design-record/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-record
-description: Keeps the project's design record, being the design document at `canon/DESIGN.md` and the reference folder at `canon/design/` holding the accepted frames a build matches. Sets the folder up, lands a picked design through the project's design sync, keeps the index, redraws or retires a reference when its surface changes, and carries a pick's values into the stylesheet and its intent into the design document. Use whenever a picked frame or design moves into `canon/design/` or `canon/DESIGN.md`, before running the project's design sync or editing the index, including when asked to "land it in the design references", "add a design reference", "land this pick", "set up canon/design", "update the design index", "redraw the reference for X", "remove the reference for X", or "update DESIGN.md". Do NOT use to draft candidates or take a pick, which is `pick-by-eye`, to draw frames on a board, which is Frameboard, or to judge a design, which is `design-taste`.
+description: Keeps the project's design record, being the design document at `canon/DESIGN.md` and the reference folder at `canon/design/` holding the accepted frames a build matches. Sets the folder up, lands a picked design through the project's design sync, keeps the index, redraws or retires a reference when its surface changes, and carries a pick's values into the stylesheet and its intent into the design document. Use whenever a picked frame or design moves into `canon/design/` or `canon/DESIGN.md`, before running the project's design sync or editing the index, including when asked to "land it in the design references", "add a design reference", "land this pick", "set up canon/design", "update the design index", "redraw the reference for X", "remove the reference for X", or "update DESIGN.md". Do NOT use to draft candidates or take a pick, which is `design-pick`, to draw frames on a board, which is Frameboard, or to judge a design, which is `design-taste`.
 metadata:
   family: ship
 ---

package/claude/skills/design-taste/REQUIREMENT.md

@@ -25,12 +25,12 @@ The output has no standard of quality either. A model with no stated direction d
 - Admit a rule an unguided model already gets right, another surface owns, a threshold settles, or no single line could violate
 - Restate the correctness floor or the banned characters, or trade accessibility and the state set against an aesthetic preference
 - Express intensity as a numeric scale, or claim a round follows these rules when nothing measures it
-- Be reached only by an author typing its name, since `pick-by-eye`'s declared read is the intended caller
+- Be reached only by an author typing its name, since `design-pick`'s declared read is the intended caller
 
 ## Out of scope
 
 - Accessibility, keyboard interaction, state coverage, forms, and rendered copy, which `ui-craft` owns
 - The focus ring's floors, which `ui-craft` owns, though its weight is this skill's
-- The candidate loop and the pick, which `pick-by-eye` owns
+- The candidate loop and the pick, which `design-pick` owns
 - The shape of the project's design document, which `design-record`'s design reference governs
 - Prose on the surface being designed, which `write-human` and `markdown-craft` own

package/claude/skills/design-taste/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-taste
-description: Carries the layer model that decides which design decision settles first, the rules that keep a surface coherent across sections, and the catalog of defaults a model reaches for when nothing states a direction. Use when drafting or judging an interface, a page, or any rendered surface, when output reads generic or templated, when redesigning something that already exists, or when asked to "make this look designed", "why does this look like AI made it", "give it taste", "what layer is this decision at", or "grey-box this first". Do NOT use for accessibility, forms, or state coverage, which `ui-craft` carries, for the shape of the project's design document, which `design.md` governs, or to run the candidate loop, which is `pick-by-eye`.
+description: Carries the layer model that decides which design decision settles first, the rules that keep a surface coherent across sections, and the catalog of defaults a model reaches for when nothing states a direction. Use when drafting or judging an interface, a page, or any rendered surface, when output reads generic or templated, when redesigning something that already exists, or when asked to "make this look designed", "why does this look like AI made it", "give it taste", "what layer is this decision at", or "grey-box this first". Do NOT use for accessibility, forms, or state coverage, which `ui-craft` carries, for the shape of the project's design document, which `design.md` governs, or to run the candidate loop, which is `design-pick`.
 metadata:
   family: build
 ---
@@ -157,8 +157,8 @@ Run `${CLAUDE_SKILL_DIR}/references/preflight.md` against the output. It is the
 
 Five neighbors own the rest.
 
-- The candidate loop, the arm set, the render, and the pick: `pick-by-eye`
+- The candidate loop, the arm set, the render, and the pick: `design-pick`
 - The shape of the project's design document and where its values live: `${CLAUDE_SKILL_DIR}/../design-record/references/design.md`
 - The folder holding the accepted designs and how a reference lands in it: `${CLAUDE_SKILL_DIR}/../design-record/references/folder.md`
-- Reading source for roughness: `ux-audit`. Measuring what a running interface costs to paint: `ux-measure`
+- Reading source for roughness: `ui-audit`. Measuring what a running interface costs to paint: `ui-measure`
 - Prose on the surface being designed: the `write-human` skill

package/claude/skills/design-taste/references/preflight.md

@@ -101,5 +101,5 @@ Every word on the surface states what is true of it.
 
 ## Handover
 
-- [ ] The weakest thing on the surface is named out loud, per `pick-by-eye` Step 3, and fixed where naming it would embarrass the work
+- [ ] The weakest thing on the surface is named out loud, per `design-pick` Step 3, and fixed where naming it would embarrass the work
 - [ ] The floor the `ui-craft` skill carries has been applied, not assumed

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

@@ -28,5 +28,5 @@ Prose bans hold on files the hook watches and not on text leaving through `gh`,
 ## Out of scope
 
 - Reporting a toolkit defect from a target project, which `canon-feedback` owns
-- Triaging issues already filed, which `canon-feedback-triage` owns
+- Triaging the toolkit's feedback issues, which its maintainers do in its own repository
 - Opening a pull request, which `git-pr` owns

package/claude/skills/git-issue/references/issue.md

@@ -97,7 +97,7 @@ Fix the feedback CLI so it applies the `feedback` label.
 
 ## Details
 
-`canon feedback` opens an issue with no label, so `canon-feedback-triage` never lists it.
+`canon feedback` opens an issue with no label, so the toolkit's triage never lists it.
 
 ## Context
 

package/claude/skills/plan-feature/SKILL.md

@@ -85,7 +85,7 @@ Every `- Suggested:` line takes senior judgment, picking the best option in one
 
 - Suggest a real default when best practice, the codebase, or prior context points to one
 - Before `## Files to touch`, load `canon:codebase-layout` for a new path (its reason) and `canon:api-design` for a changed verb, flag, output, record shape, or endpoint. Report either if missing.
-- Fill `## Design references` with the `canon/design/<surface>/` folder for each surface a UI file in `## Files to touch` renders, and write `None identified.` in a project with no folder
+- Fill `## Design references` with the `canon/design/<surface>/` folder per rendered surface, or `None identified.`, and `## Reference images` with each untracked image that shaped the plan
 - Write `## Verification` as one bullet per outcome naming the test or command that proves it, with a grep bullet per `## Verbatim` block of settled wording
 - Write `## Review focus` as the inputs or states that would break the change, carrying the risk you understood to the executor and the reviewer