@erclx/canon 5.52.0 → 5.54.0

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## [5.54.0](https://github.com/erclx/canon/compare/v5.53.0...v5.54.0) (2026-10-21)
+
+
+### Features
+
+* **canvas:** move the design board to Frameboard and retire the canvas ([#2593](https://github.com/erclx/canon/issues/2593)) ([19e0d4f](https://github.com/erclx/canon/commit/19e0d4f4c0022f02bdc94253a743ef757ec44bcc))
+* **ci:** prove canon on macOS with the stock bash ([#2591](https://github.com/erclx/canon/issues/2591)) ([0220169](https://github.com/erclx/canon/commit/0220169cf6f10fb45ff07ffba7fb58a708ade5e2))
+* **design:** retire the canvas-only design verbs and sync domain ([#2598](https://github.com/erclx/canon/issues/2598)) ([ed15567](https://github.com/erclx/canon/commit/ed1556768df49a015b8c9a921df41382e2d19e89))
+* **skills:** give teach-craft a cited source ledger ([#2592](https://github.com/erclx/canon/issues/2592)) ([d67d18c](https://github.com/erclx/canon/commit/d67d18ccf6de3a04963fc20c0ff0624ea7b479f4))
+
+## [5.53.0](https://github.com/erclx/canon/compare/v5.52.0...v5.53.0) (2026-10-21)
+
+
+### Features
+
+* **products:** drop teach, slides, and demo for a teach-craft skill ([#2588](https://github.com/erclx/canon/issues/2588)) ([bb1930f](https://github.com/erclx/canon/commit/bb1930fa8911ae637eddadbaabfa498e6e7f769d))
+
 ## [5.52.0](https://github.com/erclx/canon/compare/v5.51.0...v5.52.0) (2026-10-21)
 
 

package/README.md

@@ -66,17 +66,16 @@ Each domain has a canonical source in this repo and a thin install or sync CLI o
 
 ### Domain catalog
 
-| Domain         | What it is                                                                                                              | How it reaches you                                              |
-| -------------- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
-| Plugin skills  | Skills that plan a feature, review a diff, sync the planning docs, and run the ship chain                               | Loaded live from the plugin, never copied                       |
-| Governance     | Coding and authoring rules that load into a Claude session when a matching path is edited                               | Installed per project by `canon gov install`, refreshed by sync |
-| Tooling stacks | Golden configs, seeds, and a reference per framework                                                                    | Laid down by `canon init`, reconciled by `canon tooling sync`   |
-| Design system  | Ships a `DESIGN.md` intent format pointing at your stylesheet for values, a skill that drafts one, and a render command | `canon design render`                                           |
-| Slides         | A folder of HTML slides per deck, drawn in the project's tokens and rebuilt as editable shapes                          | `canon slides render` writes PowerPoint                         |
-| Teach          | Lessons, sources, and a glossary in one workspace, rendered to a small site                                             | `canon teach`                                                   |
-| Canvas         | Pages of HTML frames on a local pan and zoom surface, each frame drawn with the project's tokens                        | `canon canvas serve`                                            |
-| 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`                                                 |
+| Domain         | What it is                                                                                            | How it reaches you                                              |
+| -------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
+| Plugin skills  | Skills that plan a feature, review a diff, sync the planning docs, and run the ship chain             | Loaded live from the plugin, never copied                       |
+| Governance     | Coding and authoring rules that load into a Claude session when a matching path is edited             | Installed per project by `canon gov install`, refreshed by sync |
+| Tooling stacks | Golden configs, seeds, and a reference per framework                                                  | Laid down by `canon init`, reconciled by `canon tooling sync`   |
+| Design system  | Ships a `DESIGN.md` intent format pointing at your stylesheet for values, and a skill that drafts one | `canon:design-record` drafts it in your repo                    |
+| 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.
 
 ### How domains reach you
 
@@ -93,7 +92,7 @@ The workflow this toolkit ships is the workflow that built it. Several Claude Co
  <img src="demos/agent-view-light/demo.gif" alt="The canon landing page scrolling from the dispatch section to the branch graph, three workers and a planner on disjoint file sets with the pull request each opened">
 </picture>
 
-That recording is the landing page's own `dispatch` and `workers` sections, driven by `canon demo run` against a local build. The branch graph beside the pull request numbers is authored rather than read, because nothing on a build machine records which files four sessions held.
+That recording is the landing page's own `dispatch` and `workers` sections, driven through a browser against a local build. The branch graph beside the pull request numbers is authored rather than read, because nothing on a build machine records which files four sessions held.
 
 ## Documentation
 
@@ -182,7 +181,6 @@ Each domain carries an entry written for someone maintaining the toolkit rather
 - [Governance rules](canon/context/surfaces/governance.md)
 - [Tooling stacks](canon/context/surfaces/tooling.md)
 - [Design system](canon/context/features/design.md)
-- [Slides](canon/context/features/slides.md)
 - [Transcripts](canon/context/features/transcripts.md)
 - [Sandbox](canon/context/development/sandbox.md)
 

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

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

@@ -1,6 +1,6 @@
 ---
 name: canon-cli
-description: Routes a job to the `canon` verb that does it, and warns which verbs can lose a project's edits before one runs. Use when asked "which canon command does X", "is there a verb for X", "which command tells me if X", "will this overwrite my changes", or before running `canon sync`, `canon gov sync`, `canon tooling sync`, `canon design sync`, `canon migrate`, or `canon indexes regen`. Do NOT use to execute a verb, only to pick one and know what it costs.
+description: Routes a job to the `canon` verb that does it, and warns which verbs can lose a project's edits before one runs. Use when asked "which canon command does X", "is there a verb for X", "which command tells me if X", "will this overwrite my changes", or before running `canon sync`, `canon gov sync`, `canon tooling sync`, `canon migrate`, or `canon indexes regen`. Do NOT use to execute a verb, only to pick one and know what it costs.
 metadata:
   family: answer
 ---
@@ -45,15 +45,13 @@ Each verb here has a skill that owns the job. Load the skill rather than driving
 | Job                                          | Verb                | Skill                       |
 | -------------------------------------------- | ------------------- | --------------------------- |
 | Render the design system                     | `canon design`      | `canon:draw-figure`         |
-| Render a slide deck                          | `canon slides`      | `canon:make-deck`           |
 | Render an HTML source to a PNG               | `canon capture`     | `canon:design-identity`     |
 | Serve a directory and print the link         | `canon serve`       | none                        |
-| Record a running app                         | `canon demo`        | `canon:script-screencast`   |
 | Report one computed property across routes   | `canon inventory`   | `canon:target-check`        |
 | Walk a page through interactions and measure | `canon drive`       | `canon:ux-measure`          |
 | Fetch a YouTube transcript                   | `canon transcripts` | `canon:youtube-transcripts` |
-| Open a learning workspace                    | `canon teach`       | `canon:teach-workspace`     |
-| Work on the local canvas                     | `canon canvas`      | `canon:canvas-board`        |
+
+The design board is Frameboard, a separate CLI outside canon, so a board job runs a `frameboard` verb rather than a `canon` one.
 
 ## Session and ship
 
@@ -87,11 +85,10 @@ Read the doc each line names before running one of these. `canon docs install-an
 - `canon gov sync` replaces a rule you edited and deletes a rule the toolkit retired, edited or not.
 - `canon tooling sync --write` replaces every golden config a stack ships. Seeds are copy-once. Nothing writes without the flag. See `canon docs sync`.
 
-### Design, migrate, and indexes
+### Migrate and indexes
 
-Three more verbs rewrite files in place.
+Two more verbs rewrite files in place.
 
-- `canon design sync` replaces the shipped design files and leaves `.claude/design/project/` alone.
 - `canon migrate --write` rewrites files that cite a retired name or layout. It reports and writes nothing without the flag. See `canon docs migrate`.
 - `canon indexes regen` rewrites each generated `index.md` from the folder's current state, so a hand edit there is lost. See `canon docs indexes`.
 

package/claude/skills/context-fold/REQUIREMENT.md

@@ -29,7 +29,6 @@ The context entries describe the repository the session opened with. An entry ke
 ## Out of scope
 
 - Marking outcomes, sweeping receipts, and archiving a task, which `task-complete` owns
-- Landing a teach promotion page, which `teach-workspace` owns
 - Creating or declining a task file, which `task-board` owns
 - Public-facing docs, which `docs-sync` owns
 - Regenerating the context catalog, which a commit hook owns

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

@@ -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`, `canon capture`, or `canon design render`, which this skill composes
+- Modify `pick-by-eye` 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
-- Carrying a picked direction into the design document, which `canvas-board` owns
+- Carrying a picked direction into the design document, which `design-record` owns
 - Auditing an implemented UI against its tokens, which `ux-audit` owns
 - Wiring the produced files into the project's head or manifest, which the operator owns

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

@@ -62,15 +62,15 @@ Announce which tier decided, naming the tier rather than the path alone, so the
 
 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.
 
-- Draft each arm inside the full 1200x630 card frame, mark and type together, and add its canvas frame at `--width 1200 --height 630`, so one pick settles shape and composition
+- 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.
 - Structure every arm as a `.mark` element, the inline SVG alone, nested inside a `.card` element, the full composition, so Step 6 can address either
 
 ## 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 canvas page, render and hand off, take the pick, and loop on it.
+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.
 
-The final icon and card renders below are not arms, so they stay off the canvas. 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 `pick-by-eye` Step 1 derived, which is where this project puts every temporary write.
 
 ## Step 6: finalize the mark and the icons
 
@@ -110,9 +110,9 @@ canon capture <dest>/render/og-image.html --selector .render --out <write-folder
 
 It takes its own call because Step 6's batch is already captured by the time this step picks a path. Say that the card shipped as a PNG with no source, and that the project gains one when it grows a route to hold the composition.
 
-### Closing the scratch folder and the canvas
+### Closing the scratch folder and the board
 
-Delete `<dest>` once both captures land, then close the canvas 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 `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.
 
 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.
 
@@ -133,6 +133,6 @@ 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
-- `canon:canvas-board` carries a picked direction into `canon/DESIGN.md`. This skill only reads it.
+- `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/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 the picking or canvas skill should hand off to it
+- Be reached only by the author typing its name, since a pick from `pick-by-eye` should hand off to it
 
 ## Out of scope
 
 - Drafting candidates and taking the pick, which `pick-by-eye` owns
-- Drawing, selecting, and capturing frames on the canvas, which `canvas-board` 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 the canvas, which is `canvas-board`, 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 `pick-by-eye`, to draw frames on a board, which is Frameboard, or to judge a design, which is `design-taste`.
 metadata:
   family: ship
 ---
@@ -19,7 +19,7 @@ The document holds the rules and each role's intent, and the folder holds the pi
 ## Guards
 
 - Write no reference file by hand, whether a copy, an edit, or a delete. The project's design sync writes the frames, so a hand-written file drifts from the frame it claims to show.
-- Never land a candidate the operator has not picked. The folder holds accepted designs, and a draft lives on the canvas.
+- Never land a candidate the operator has not picked. The folder holds accepted designs, and a draft lives on the board.
 
 ## Step 1: read the record
 
@@ -66,10 +66,10 @@ Retire a reference in the change that removes its surface from the app.
 A pick that settles color, type, spacing, or radius changes the design document as well as the folder. Skip this step when the pick changed layout or structure alone, since the reference carries that.
 
 - Carry each value into the stylesheet the document's lead names, and its intent into the document's sections under `design.md`
-- A project with no stylesheet yet takes the values under `.claude/design/project/` after `canon design install`, and the lead names that path
+- A project with no stylesheet yet writes one of its own for the values, and the lead names its path
 - A values record names in its lead the module it renders from and the command that renders it. Edit that module and run that command, never the document.
 
-Never cite a canvas frame path from the document or the index. The canvas folder is gitignored, so the citation resolves on one machine alone.
+Never cite a board frame path from the document or the index. The board folder is gitignored, so the citation resolves on one machine alone.
 
 ## Output
 

package/claude/skills/design-record/references/folder.md

@@ -15,7 +15,7 @@ Does not govern:
 
 - The design document at `canon/DESIGN.md`, which `design.md` beside this file governs
 - When a pick lands and how a build is held to a reference, which the design-reference governance rule states
-- The canvas content format a frame is drawn in, which the canvas standard owns
+- The content format a frame is drawn in, which Frameboard owns and `frameboard docs --json` prints
 
 ## What a working folder looks like
 

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

@@ -31,5 +31,5 @@ The output has no standard of quality either. A model with no stated direction d
 
 - Accessibility, keyboard interaction, state coverage, forms, and rendered copy, which the `a11y`, `keyboard`, `ux-completeness`, `forms`, and `copy` rules own
 - The candidate loop and the pick, which `pick-by-eye` owns
-- The shape of the project's design document, which `canvas-board`'s design reference governs
+- 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/references/kinds.md

@@ -47,7 +47,6 @@ Documentation, articles, reference pages, learning material. The reader arrived
 ## Kinds this file does not cover
 
 - **Transactional flows** such as checkout, sign-up and settings are read as application UI. Their distinctive rules, state coverage and error recovery, sit in the `ui` governance rules.
-- **Presentation surfaces** such as slide decks are drafted by `make-deck`, which carries the deck's design rules. Take the layer ordering and the floor from the body and the rest from it.
 - **Terminal and text-mode surfaces** have no layout engine and their own color rules, stated where the writing surface is decided rather than here.
 
 A read naming any of the three above takes the body's rules and says it has no per-kind guidance, naming the surface that governs it. A read naming a kind this file does not list at all says so rather than borrowing the nearest section.

package/claude/skills/draw-figure/REQUIREMENT.md

@@ -7,13 +7,13 @@ description: Why a figure decides between Mermaid, an architecture view, and fre
 
 ## Gap
 
-Without this skill, a session asked for a figure takes the first path it thinks of. A graph gets SVG coordinates nobody checked against a render, and a subject that is not a graph gets forced through Mermaid. In a teach lesson the renderer cannot load the hand font, so labels clip, and a check reading the standalone image passes them.
+Without this skill, a session asked for a figure takes the first path it thinks of. A graph gets SVG coordinates nobody checked against a render, and a subject that is not a graph gets forced through Mermaid.
 
 Asked to refresh one architecture view, it redraws every view beside it. It judges the source and calls the figure verified, though a valid source can render a picture asserting something false. Mermaid's theme writes literal hex values, so the figure stops re-coloring when the page switches palette.
 
 ## Must
 
-- The figure clears the standard's earn-its-place bar, and its path follows whether the subject reduces to a graph, with a teach lesson drawn freehand whatever its shape
+- The figure clears the standard's earn-its-place bar, and its path follows whether the subject reduces to a graph
 - An architecture view is drawn from its named source signal in `flowchart` or `sequenceDiagram`, and only the view the request names changes
 - The Mermaid render uses the hand-drawn look and the figure font stack, with every literal color rewritten to the host's custom property
 - The render is read back against what the figure means to say, and a figure bound for a rendered page is verified by a capture inside that page
@@ -30,6 +30,5 @@ Asked to refresh one architecture view, it redraws every view beside it. It judg
 ## Out of scope
 
 - Mermaid's layout, budgets, and label rules inside the fence, which the mermaid standard owns
-- A UI screen mockup, and design tokens or the visual system, which `canvas-board` owns
-- Which lesson needs a figure and where it sits, which `teach-workspace` owns
+- A UI screen mockup, which belongs on a Frameboard board, and design tokens or the visual system, which `design-record` owns
 - Implementation detail behind an architecture view, which the context entry the caption points at owns

package/claude/skills/draw-figure/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: draw-figure
-description: Drafts one hand-drawn figure for a document, deciding whether the subject is Mermaid-shaped, an architecture view, or needs freehand SVG, then draws it. Renders the Mermaid path through Mermaid's own hand-drawn look, reads the render back, and fixes what it exposes. Wraps every path in the figure standard's caption, color, and accessibility rules. Use when asked to "draw a figure", "add a hand-drawn diagram", "draft a figure for this doc", "draw this relationship as a figure", "draw the architecture", "diagram the system", or "show the components". Do NOT use for a UI screen mockup, which is `canvas-board`.
+description: Drafts one hand-drawn figure for a document, deciding whether the subject is Mermaid-shaped, an architecture view, or needs freehand SVG, then draws it. Renders the Mermaid path through Mermaid's own hand-drawn look, reads the render back, and fixes what it exposes. Wraps every path in the figure standard's caption, color, and accessibility rules. Use when asked to "draw a figure", "add a hand-drawn diagram", "draft a figure for this doc", "draw this relationship as a figure", "draw the architecture", "diagram the system", or "show the components". Do NOT use for a UI screen mockup, which belongs on a Frameboard board.
 metadata:
   family: generate
 ---
@@ -30,12 +30,11 @@ Apply the standard's bar: a relationship, a boundary, a path, or a before-and-af
 
 Take the first that matches, and state which path was picked and why in one sentence:
 
-1. **A teach lesson**, a page in a learning workspace's `lessons/` folder: the hand-drawn path, any shape. The renderer cannot load the lesson's hand font, so Mermaid labels measure narrow and clip.
-2. **An architecture view**, meaning the request names system context, components, request flow, data pipeline, or deployment: the architecture set, then the Mermaid path.
-3. **Graph-shaped**, meaning the relationship, boundary, or path is already what a flowchart or sequence diagram expresses: the Mermaid path.
-4. **Anything else**, a spatial or physical arrangement no flowchart reduces to: the hand-drawn path.
+1. **An architecture view**, meaning the request names system context, components, request flow, data pipeline, or deployment: the architecture set, then the Mermaid path.
+2. **Graph-shaped**, meaning the relationship, boundary, or path is already what a flowchart or sequence diagram expresses: the Mermaid path.
+3. **Anything else**, a spatial or physical arrangement no flowchart reduces to: the hand-drawn path.
 
-The standard states this as a render-first policy rather than a ban on any tool-exported drawing, so outside a teach lesson a graph-shaped subject always routes through Mermaid even though that is itself an external renderer.
+The standard states this as a render-first policy rather than a ban on any tool-exported drawing, so a graph-shaped subject always routes through Mermaid even though that is itself an external renderer.
 
 ## Step 4: draw
 

package/claude/skills/draw-figure/references/figures.md

@@ -39,7 +39,6 @@ Route a graph-shaped subject, one whose relationship, boundary, or path a flowch
 
 - Reserve freehand inline SVG, plain shapes and lines authored in the markup, for a subject that is not graph-shaped
 - A figure that cannot express its subject through the deterministic path is a worse failure than an inconsistent hand-drawn one, so the hatch stays open
-- Draw a figure in a teach lesson freehand whatever its shape. Its hand font cannot load in the renderer, so Mermaid measures labels in a narrower fallback face and the page clips them.
 - State this as a render-first policy rather than a ban on a tool-exported drawing, since routing through Mermaid is itself running an external tool
 
 ## Wrapping and captioning

package/claude/skills/draw-figure/references/hand-drawn.md

@@ -5,7 +5,7 @@ description: Authoring a freehand SVG, its color and accessibility audit, and th
 
 # Hand-drawn path
 
-`draw-figure` reads this file when Step 3 routes a figure to a freehand drawing: a teach lesson whatever its subject, or a subject no flowchart reduces to.
+`draw-figure` reads this file when Step 3 routes a figure to a freehand drawing, for a subject no flowchart reduces to.
 
 ## Draw
 

package/claude/skills/pick-by-eye/REQUIREMENT.md

@@ -14,8 +14,8 @@ The evidence fails as well. Arms get reported without being rendered or judged,
 ## Must
 
 - Three to five arms, the shipping state among them, each carry an id, a label, and a cost, and vary only at a layer named from the `design-taste` catalog
-- Each round is one canvas page of frames at their judged widths, themed by the canvas 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 canvas that will not start is reported as a refusal
+- 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
 
@@ -24,8 +24,8 @@ The evidence fails as well. Arms get reported without being rendered or judged,
 - Take the pick where two arms are defensible and the difference is taste
 - Draft candidates for a decision the operator has not asked to make, or for a request that already names one answer
 - Write into the real surface before the pick is final
-- Restate the mechanics `canon canvas` and `canon drive` own, or read a drive finding as a gate over the arms
-- Delete a canvas page or stop a server the run did not start
+- Restate the mechanics Frameboard and `canon drive` own, or read a drive finding as a gate over the arms
+- Delete a board page or stop a server the run did not start, or remove a page by any route but a `frameboard` verb
 
 ## Out of scope
 
@@ -33,4 +33,3 @@ The evidence fails as well. Arms get reported without being rendered or judged,
 - Finding roughness by reading source, which `ux-audit` owns
 - Measuring what a running interface costs to paint, which `ux-measure` owns
 - Listing what to look at on a change already made, which `ui-checklist` owns
-- Scripting a recording of something already built, which `script-screencast` owns

package/claude/skills/pick-by-eye/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pick-by-eye
-description: Drafts several candidates for a decision judged by looking, lays them out side by side as frames on one canvas 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`, to write what to look at on a change already made, which is `ui-checklist`, or to script a recording, which is `script-screencast`.
+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`.
 metadata:
   family: decide
 ---
@@ -9,13 +9,14 @@ metadata:
 
 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 the local design canvas, the surface `canon:canvas-board` drives. Every verb below is `canon canvas`, and `${CLAUDE_SKILL_DIR}/../canvas-board/references/canvas.md` fixes the content format a frame takes. Read that reference before writing the first frame.
+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.
 
 ## Guards
 
 - If the request names one answer and asks for it to be built, stop: `❌ This names one answer, so there is nothing to pick between. Use /canon:plan-feature.`
 - If the decision has no visible form, stop: `❌ Nothing to look at. Drafting candidates needs a decision a render can show.`
 - Draft no candidate for a decision the operator has not asked to make, since options everywhere spend their attention rather than saving it
+- If neither `frameboard` nor `bunx` is on PATH, stop: `❌ Frameboard not found. Install frameboard or bun and re-run.`
 
 ## Step 1: name the decision and the arms
 
@@ -28,26 +29,24 @@ The candidates live on the local design canvas, the surface `canon:canvas-board`
 
 Inside a live `plan-groundwork` track, renders land in the track's own `evidence/<slug>/renders/`, since a candidate render is evidence its decision file cites. Everywhere else they land in session scratch.
 
-## Step 2: draft the arms as frames on one canvas page
+## Step 2: draft the arms as frames on one page
 
-Every arm of a round sits as one frame on one canvas page, side by side. The operator judges that page, never a set of separate images compared from memory.
+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 canvas the way `canon:canvas-board` Step 1 states, unless this run already has. Note whether this run started the server, since Step 6 stops only a server this run started.
-2. Add the round's page with `canon canvas page add <page> --json` and record it on the run's list of pages. A name `canvas list` already shows is somebody else's, so take the next free suffix.
-3. Add each arm with `canon canvas frame add <page> arm-<id> --width <px> --height <px> --json`. Step 6's archive keys on the `arm-<id>` names.
-4. Write each arm's whole document to the `path` the add verb reported. From a linked worktree, take the heredoc route `canon:canvas-board` Step 3 gives for a main-root write.
-5. Lay the frames out in one row, in arm order, with `canon canvas frame move <page> arm-<id> --x <px> --y <px> --json`.
+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`.
+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.
 
-The `canvas-board` start reads `canon canvas list --json`, serves with `canon canvas serve --json` in the background unless the operator named an address that answers, and checks the shell's body holds a `<script` tag. A refused serve or a blank shell stops the run with its `reason`, and no file stands in for a canvas.
-
-Set each frame's width to the one the arm is judged at. A frame renders at its own layout width on the canvas and in a capture alike, so a layout decision needs no device toolbar.
+Set each frame's width to the one the arm is judged at. A frame renders at its own layout width on the board and in a capture alike, so a layout decision needs no device toolbar.
 
 ### What every frame carries
 
-Each frame carries its own label and follows the canvas theme, so the set reads as one comparison.
+Each frame carries its own label and follows the board theme, so the set reads as one comparison.
 
 - Label each arm inside its frame with its id and its cost, since the composite capture draws no captions
-- Theme every arm off the `data-theme` attribute the canvas sets on each frame's root, so the theme toggle sets the whole set at once. A set spanning both themes cannot be compared.
+- Theme every arm off the `data-theme` attribute the board sets on each frame's root, so the theme toggle sets the whole set at once. A set spanning both themes cannot be compared.
 - Give no arm a script that stores a theme and reapplies it on load. It overwrites the toggle, and a fresh browser profile hides the fault.
 
 ### Default path and live app
@@ -55,8 +54,8 @@ Each frame carries its own label and follows the canvas theme, so the set reads
 A running app under decision takes the live-app branch, and every other decision takes the default path.
 
 - Live app: lift the rendered markup and link a copy of the built stylesheet rather than inlining, per `${CLAUDE_SKILL_DIR}/references/live-arms.md`
-- Default path: inline every style, script, and asset. A frame resolves nothing outside its own page folder, so a build step or network font silently drops out.
-- Default path: name a real font first in the stack, one the machine has or the frame embeds, such as the project's own family. A generic keyword such as `system-ui` resolves differently per machine.
+- Default path: inline every style, script, and asset. A frame resolves nothing outside its page folder and its project's `assets/`, so a build step or network font silently drops out.
+- Default path: name a real font first in the stack, one the board serves, the machine has, or the frame embeds. A generic keyword such as `system-ui` resolves differently per machine.
 
 The capture refuses a frame that would rewrap against a substitute font rather than ship a false comparison. A frame naming no font is refused on whatever the default resolves to.
 
@@ -73,18 +72,18 @@ 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
-canon canvas capture <page> --composite --json
+frameboard capture --page <page> --composite --root <board> --project picks --json
 ```
 
-- Point `--out` at `evidence/<slug>/renders/<page>.png` inside a live track, and leave the scratch default elsewhere. Step 6 archives the picked round alone.
-- Read the PNG's `path` off the record. The composite shows each frame in its default theme, so check the other theme on the live canvas.
-- A capture refusing on a font names the family it read. Take the repair `canon:canvas-board` Step 6 gives and capture again.
+- Point `--out` at `evidence/<slug>/renders/` inside a live track, and leave the board's default elsewhere. Step 6 archives the picked round alone.
+- Read each image's `path` off the record's `images`. The composite lands once per theme, so look at both.
+- A `font-missing` refusal names the family it read. Set that text's `font-family` to a named family the board serves or the machine has, never a generic keyword, and capture again.
 
-When `canon canvas capture` refuses for a missing browser binary, report it and name `bunx playwright install chromium` as the repair. Stop the canvas server if this run started it, then stop rather than describe an arm nobody has seen.
+When the capture refuses with `browser-not-found`, report it and name `bunx playwright install chromium` as the repair. End the serve command if this run started it, then stop rather than describe an arm nobody has seen.
 
 ### Handing over
 
-Hand over the address rather than a description. Emit the canvas link first on its own line, naming the page, then the PNG path on its own line.
+Hand over the address rather than a description. Emit the board link first on its own line, naming the page, then each PNG path on its own line.
 
 - A still answers how a thing looks and none of a hover, a scroll-linked position, or a pace, which the live frame does
 - Never report a visual result you have not looked at, since a claim about appearance with no render behind it is a guess
@@ -103,14 +102,7 @@ Put the choice to the operator through the structured question surface, since a
 
 Take no pick on the operator's behalf when two arms are both defensible and the difference is taste. That call is theirs, and a silent one is the failure this skill exists to prevent.
 
-Read `canon canvas selection --json` when the answer points at the canvas, such as "the selected one". Resolve it against the record's `page` as well as its `frame`, since every round reuses the `arm-<id>` names.
-
-| Selection                                                        | Reading                                        |
-| ---------------------------------------------------------------- | ---------------------------------------------- |
-| A frame on the current round's page                              | The pick                                       |
-| A frame on an earlier round's page                               | A revert, so name the round back before acting |
-| A fresh element inside a picked frame                            | A correction Step 5 carries by its `index`     |
-| `selection: null`, a page this run did not add, or `stale: true` | No answer, so ask again rather than guess      |
+Read the selection when the answer points at the board, such as "the selected one". `references/board.md` maps each record to a pick, a revert, a correction, or no answer.
 
 ## Step 5: loop on the pick
 
@@ -118,22 +110,22 @@ Read `canon canvas selection --json` when the answer points at the canvas, such
 2. Write fresh arms off the pick and return to Step 2 where the correction opens a new question. Revise the one arm's frame where it does not.
 3. Re-render, hand off again, and take the next answer.
 4. Repeat until the operator says it is right. A run stopping because the arms stopped differing has stopped early.
-5. Hold the real surface untouched across every iteration. Nothing outside the run's own canvas pages changes until the pick is final.
+5. Hold the real surface untouched across every iteration. Nothing outside the run's own board pages changes until the pick is final.
 
 ## Step 6: close
 
 1. Apply the winning arm to the real surface, in one change.
 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 to `canon:design-record` by its page and frame, 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 `canon canvas capture <page> --out <archive-dir> --json`. Each lands as `arm-<id>.png`, keeping the losing arms as a revert record.
-5. Resolve `<archive-dir>` as `.canon/picks/<slug>/` against the main worktree root, since shared session scratch resolves there rather than in a linked worktree.
-6. Delete every page folder on the run's list from under the `content` folder `canon canvas list --json` reports. Touch no page the run did not add, whatever its name.
-7. Stop the canvas server if this run started it, and leave one the operator started running.
+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.
+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 the path for the operator to remove. The pick is applied either way.
+9. Report each page 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 canvas is a second design nobody maintains.
+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.
 
 ## Reading a measurement
 
@@ -154,10 +146,11 @@ Cite these rather than restating them. A step reimplemented here rots against th
 - `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
 
-### Git and review
+### Git, review, and the board
 
-Commits, review, and the canvas mechanics each have an owner.
+Commits, review, and the board mechanics each have an owner.
 
 - `git-stage`, `git-pr`, and `git-followup` carry the commits and the pull request
 - `review-pr` and `review-address` run the review pass
-- `canon:canvas-board` carries the canvas start-and-check sequence, the main-root write route for a frame, and the selection and capture refusals
+- `session-worktree` carries the main-root write route for a frame written from a linked worktree
+- Frameboard carries the board itself, and `frameboard docs --json` prints its verbs, record shapes, content format, and refusals

package/claude/skills/pick-by-eye/references/board.md

@@ -0,0 +1,42 @@
+# 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.
+
+## 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.
+
+- Pass `--root <board> --project picks --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
+
+Run `frameboard docs --json` before writing the first frame. Its `contentFormat` fixes what a frame may hold and link, and its `exitCodes` name every refusal a verb can return.
+
+## Starting the board
+
+Serve in the background unless the operator named an address that answers, since the server runs until its command ends:
+
+```bash
+frameboard serve --root <board> --no-open --tokens <stylesheet> --json
+```
+
+- Take `<stylesheet>` from the lead of `canon/DESIGN.md`, which names it in a hand-written record
+- A lead naming a module, or no design document at all, means serving without `--tokens`. Say the frames render on the board's own tokens.
+- Read `url` and `reused` off the record rather than composing an address
+- `reused: true` means a server was already up, so this run did not start it and its close leaves it running
+- Report a refusal's `error.code` and stop, since no file stands in for a board
+
+## Reading the selection
+
+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 |
+
+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.