@erclx/canon 5.30.0 → 5.32.0

package/claude/skills/draft-figure/references/architecture-set.md

@@ -5,7 +5,7 @@ description: The five architecture views with each one's question, source signal
 
 # Architecture set
 
-`draft-figure` reads this file when the request names an architecture view. It shapes the subject, then the figure goes through `${CLAUDE_SKILL_DIR}/references/mermaid.md` like any other graph-shaped figure. The destination stays the one the user named.
+`draft-figure` reads this file when the request names an architecture view. It shapes the subject, then the figure goes through `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` like any other graph-shaped figure. The destination stays the one the user named.
 
 ## The five views
 
@@ -14,7 +14,7 @@ Draw the view the request names. Each answers one question and is drawn from one
 | View           | Question it answers                                     | Source signal                                     | Diagram type                         |
 | -------------- | ------------------------------------------------------- | ------------------------------------------------- | ------------------------------------ |
 | System context | Who uses the system, what it talks to, where it ends    | `canon/REQUIREMENTS.md`                           | `flowchart TB`                       |
-| Components     | The layered structure inside the boundary               | `canon/ARCHITECTURE.md`                           | `flowchart TB` with `subgraph` lanes |
+| Components     | The layered structure inside the boundary               | `canon/context/index.md` and the folder layout    | `flowchart TB` with `subgraph` lanes |
 | Request flow   | A request lifecycle, an agent loop, or an actor handoff | the entry point and its handlers                  | `sequenceDiagram`                    |
 | Data pipeline  | Retrieval, ranking, queues, or ETL                      | the pipeline's modules                            | `flowchart TB`                       |
 | Deployment     | Hosts, services, and infrastructure config              | deploy config, compose files, infrastructure code | `flowchart TB`                       |
@@ -25,8 +25,8 @@ Stay inside `flowchart` and `sequenceDiagram`. C4, state, ER, and class diagrams
 
 ## Sources
 
-- Read `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`, `CLAUDE.md`, and the language manifest (`package.json`, `pyproject.toml`, `Cargo.toml`) when present, plus the top-level folder layout through `ls`. Do not recurse speculatively.
-- When neither planning file exists and no folder structure names a boundary, stop: `❌ No source signal for <view>. Add canon/ARCHITECTURE.md or run inside a project folder.`
+- Read `canon/REQUIREMENTS.md`, `canon/context/index.md`, `CLAUDE.md`, and the language manifest (`package.json`, `pyproject.toml`, `Cargo.toml`) when present, plus the top-level folder layout through `ls`. Do not recurse speculatively.
+- When neither planning file exists and no folder structure names a boundary, stop: `❌ No source signal for <view>. Add canon/REQUIREMENTS.md or run inside a project folder.`
 - When the view came from a code scan rather than planning prose, open the caption with `Source: code.` and add `Fidelity is lower than prose-driven figures. Verify against the project's intent.`
 
 ## Caption and prose

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

@@ -26,6 +26,6 @@ canon capture <destination> --selector figure --out .canon/tmp/figures/
 - Fix a clipped label, a misaligned shape, or an arrow that misses its target in the destination and capture again. Stop after two correction passes.
 - When the capture fails, keep the figure and name the skipped check in the output.
 
-A Mermaid figure bound for a rendered page takes this same capture, since its standalone PNG is measured in the renderer's own fonts and can read clean while the page clips it. A clipped group title there takes the scoped overflow style `${CLAUDE_SKILL_DIR}/references/mermaid.md` states.
+A Mermaid figure bound for a rendered page takes this same capture, since its standalone PNG is measured in the renderer's own fonts and can read clean while the page clips it. A clipped group title there takes the scoped overflow style `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` states.
 
 A markdown destination has no page to load, so the read of the markup, or of the standalone render on the Mermaid path, is the whole check there.

package/claude/skills/draft-figure/references/mermaid-path.md

@@ -0,0 +1,55 @@
+---
+title: Mermaid path
+description: The hand-drawn render config, the SVG and PNG pair, the hex rewrite, the scoped overflow fallback, the label check, and the PNG read-back with its two-pass stop, read by draft-figure once a figure routes through Mermaid
+---
+
+# Mermaid path
+
+`draft-figure` reads this file when Step 3 routes a figure through Mermaid, whether the subject is graph-shaped or an architecture view the architecture set already shaped.
+
+## Draft the fence
+
+- Draft the fence against `${CLAUDE_SKILL_DIR}/references/mermaid.md` for direction, node and edge budgets, `accTitle` and `accDescr`, and quoted labels. Do not work the layout or the budgets from memory.
+- Read every node and subgraph label against the banned characters `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` lists. The audit hook skips every line inside a fence, so a label carrying a banned character passes silently while the same character in the caption is caught. Reading the labels is the only gate they have. A colon works as a replacement inside a label.
+
+## Render
+
+Render with the hand-drawn look and the figure font stack, writing scratch files under `.canon/tmp/figures/`:
+
+```bash
+mkdir -p .canon/tmp/figures
+cat <<'EOF' >.canon/tmp/figures/<slug>.json
+{"look": "handDrawn", "themeVariables": {"fontFamily": "Virgil, Excalifont, cursive"}}
+EOF
+bunx -y @mermaid-js/mermaid-cli -i .canon/tmp/figures/<slug>.mmd -o .canon/tmp/figures/<slug>.svg -c .canon/tmp/figures/<slug>.json
+bunx -y @mermaid-js/mermaid-cli -i .canon/tmp/figures/<slug>.mmd -o .canon/tmp/figures/<slug>.png -c .canon/tmp/figures/<slug>.json
+```
+
+Render both formats in one pass. The SVG is what ships inside the `<figure>`, and the PNG is what the read-back below judges, since an SVG's markup carries no recoverable spatial meaning.
+
+Use `bunx` when bun is available, falling back to `npx -y @mermaid-js/mermaid-cli ...` otherwise.
+
+Before the first render in a project, say what is about to block:
+
+```plaintext
+Rendering to verify layout. The first run downloads the Mermaid CLI and takes about 15 seconds.
+```
+
+## Rewrite the colors
+
+Rewrite every stroke, fill, and text color the renderer wrote as a literal hex value into the custom property the host stylesheet defines, per the color rule in `${CLAUDE_SKILL_DIR}/../../standards/figures.md`. Mermaid's own theme has no notion of a custom property, so this is a source edit made to the rendered SVG, not a config option.
+
+## Clipped titles
+
+- Expect a group title or a long label to clip once the destination shows it in the hand font, since the renderer sized its box in a fallback face.
+- When the in-page check shows a clipped title, add a `<style>` inside the SVG, scoped to that SVG's own id, that sets `overflow: visible` on the clipped label's `foreignObject` and centers the label within it, so the wider text spills past both edges evenly. The style hides the mismatch for a title and does nothing for a node label crowding its box, which takes a shorter label instead.
+
+## Fonts
+
+Check whether the project ran `canon design css --figures`. The figure and figcaption styling ships unconditionally either way, but that flag alone embeds the Virgil and Excalifont font files. Without it, the figure falls back to the browser's own generic `cursive` face rather than the intended hand-drawn font, and the output names that gap when the flag was not passed.
+
+## Read the render back
+
+- Read the rendered PNG and judge it against what the figure means to say, applying the verification properties in the mermaid standard. A source satisfying every rule there can still render as a picture asserting something false, so the image is what gets judged.
+- Fix the Mermaid source and re-render on a defect. Stop after two correction passes. When a defect survives, keep the figure and name the defect in the output rather than reporting a false verification.
+- When the render fails for any reason, no browser engine, no network, no package manager, continue to the confirm step and name the skipped check. A missing renderer degrades the loop rather than failing it.

package/claude/skills/draft-figure/references/mermaid.md

@@ -1,55 +1,64 @@
 ---
-title: Mermaid path
-description: The hand-drawn render config, the SVG and PNG pair, the hex rewrite, the scoped overflow fallback, the label check, and the PNG read-back with its two-pass stop, read by draft-figure once a figure routes through Mermaid
+title: Mermaid reference
+description: Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram
 ---
 
-# Mermaid path
+# Mermaid reference
 
-`draft-figure` reads this file when Step 3 routes a figure through Mermaid, whether the subject is graph-shaped or an architecture view the architecture set already shaped.
+Applies to every Mermaid fence, wherever it is written. A fence sits inside a document some other standard shapes, so this file reaches the drawing and stops at the fence markers.
 
-## Draft the fence
+## Scope
 
-- Draft the fence against `${CLAUDE_SKILL_DIR}/../../standards/mermaid.md` for direction, node and edge budgets, `accTitle` and `accDescr`, and quoted labels. Do not work the layout or the budgets from memory.
-- Read every node and subgraph label against the banned characters `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` lists. The audit hook skips every line inside a fence, so a label carrying a banned character passes silently while the same character in the caption is caught. Reading the labels is the only gate they have. A colon works as a replacement inside a label.
+Governs the Mermaid attribute wherever a fence is written, naming no path because an attribute standard governs a drawing rather than a document type: direction and layout, node and edge budgets, the accessibility fields, how punctuation reaches a label, and how a rendered diagram is verified. It carries no template, since a fence has no document shape of its own and sits inside one another standard sets.
 
-## Render
+Does not govern:
 
-Render with the hand-drawn look and the figure font stack, writing scratch files under `.canon/tmp/figures/`:
+- Which architecture view a figure draws and what question it answers: the `draft-figure` skill's architecture set
+- Language, word choice, punctuation, and formatting in the prose around a fence: `markdown.md`
+- Voice, rhythm, and sentence construction in that prose: the `write-human` skill
+- The mechanism behind any component a diagram draws: `context.md`
 
-```bash
-mkdir -p .canon/tmp/figures
-cat <<'EOF' >.canon/tmp/figures/<slug>.json
-{"look": "handDrawn", "themeVariables": {"fontFamily": "Virgil, Excalifont, cursive"}}
-EOF
-bunx -y @mermaid-js/mermaid-cli -i .canon/tmp/figures/<slug>.mmd -o .canon/tmp/figures/<slug>.svg -c .canon/tmp/figures/<slug>.json
-bunx -y @mermaid-js/mermaid-cli -i .canon/tmp/figures/<slug>.mmd -o .canon/tmp/figures/<slug>.png -c .canon/tmp/figures/<slug>.json
-```
+## What a working diagram looks like
 
-Render both formats in one pass. The SVG is what ships inside the `<figure>`, and the PNG is what the read-back below judges, since an SVG's markup carries no recoverable spatial meaning.
+A diagram works when a reviewer holding the rendered image, and nothing else, answers yes four times:
 
-Use `bunx` when bun is available, falling back to `npx -y @mermaid-js/mermaid-cli ...` otherwise.
+- Did the declared direction hold?
+- Is every row of siblings free of a sequential reading the system does not have?
+- Is every convergence free of a crossing edge bundle?
+- Is it taller than wide, outside a sequence diagram?
 
-Before the first render in a project, say what is about to block:
+A diagram failing these is non-conforming even when it satisfies every shape rule below. The rules are the means. These four questions are the test.
 
-```plaintext
-Rendering to verify layout. The first run downloads the Mermaid CLI and takes about 15 seconds.
-```
+## Layout
 
-## Rewrite the colors
+- Declare `flowchart TB` by default. Mermaid ignores a subgraph's direction whenever that subgraph links outward, and an architecture diagram links across its subgraphs as the normal case, so top-bottom is a declaration rather than a guarantee.
+- Restructure a diagram that renders diagonal or left-to-right. Repeating the direction keyword does not fix it.
+- Render a context, component, or pipeline diagram taller than wide. A `sequenceDiagram` is wide by construction and is exempt.
+- Do not let independent nodes render in a row. A row of siblings reads as a sequential chain and asserts a pipeline the system does not have.
+- Do not converge many edges on one node from one side. A crossing bundle is unreadable whatever it encodes.
+- Keep node labels short. Three or four words max. Detail goes in the paragraph below the diagram.
+- Use `<br/>` for a second short line on a node when the label is two ideas, never for a sentence.
+- Subgraphs are for grouping unrelated lanes such as offline versus online or browser versus server. Do not subgraph a single linear flow.
 
-Rewrite every stroke, fill, and text color the renderer wrote as a literal hex value into the custom property the host stylesheet defines, per the color rule in `${CLAUDE_SKILL_DIR}/../../standards/figures.md`. Mermaid's own theme has no notion of a custom property, so this is a source edit made to the rendered SVG, not a config option.
+## Budgets
 
-## Clipped titles
+- Hold a diagram to roughly 5 to 10 nodes. Split it past 15.
+- Watch edge count harder than node count. It binds first, and a diagram whose edges outnumber its nodes is already too dense to read.
+- Treat a diagram that cannot be described in one sentence as two diagrams.
+- Warn rather than refuse on a budget, and name the split that would fix it. These numbers come from published Mermaid practice rather than from a measurement against a corpus, so a hard refusal on them will be wrong sometimes and unarguable when it is.
 
-- Expect a group title or a long label to clip once the destination shows it in the hand font, since the renderer sized its box in a fallback face.
-- When the in-page check shows a clipped title, add a `<style>` inside the SVG, scoped to that SVG's own id, that sets `overflow: visible` on the clipped label's `foreignObject` and centers the label within it, so the wider text spills past both edges evenly. The style hides the mismatch for a title and does nothing for a node label crowding its box, which takes a shorter label instead.
+## Labels
 
-## Fonts
+- Apply the punctuation bans in `markdown.md` to node and subgraph labels. A label is not prose, so a check scoped to prose does not reach it, and reading the labels before shipping is the only gate they have.
+- Treat the prose around a fence and the text inside it as two surfaces. The paragraphs are prose and follow `markdown.md` and the `write-human` skill. The fenced block is not, which is why a check scoped to prose is the wrong thing to rely on for what sits inside it.
 
-Check whether the project ran `canon design css --figures`. The figure and figcaption styling ships unconditionally either way, but that flag alone embeds the Virgil and Excalifont font files. Without it, the figure falls back to the browser's own generic `cursive` face rather than the intended hand-drawn font, and the output names that gap when the flag was not passed.
+## Accessibility
 
-## Read the render back
+- Give every diagram `accTitle` and `accDescr`. `accTitle` names what the diagram answers. `accDescr` states the structure in one sentence for a reader who cannot see the render.
 
-- Read the rendered PNG and judge it against what the figure means to say, applying the verification properties in the mermaid standard. A source satisfying every rule there can still render as a picture asserting something false, so the image is what gets judged.
-- Fix the Mermaid source and re-render on a defect. Stop after two correction passes. When a defect survives, keep the figure and name the defect in the output rather than reporting a false verification.
-- When the render fails for any reason, no browser engine, no network, no package manager, continue to the confirm step and name the skipped check. A missing renderer degrades the loop rather than failing it.
+## Verification
+
+- Judge a diagram from its rendered image, not from its source. Direction, sibling rows, and edge bundles are visible only in the output.
+- Render to PNG. An SVG export reads back as markup with no recoverable spatial meaning.
+- Apply the four questions above as a reviewer, against the same render the author judged.
+- State which verification was skipped when no renderer is available. A diagram written without a render is still shippable, and one reported as verified without a render is not.

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

@@ -24,7 +24,7 @@ A session building this without a shared loop restates `draft-and-pick`'s render
 
 - Restate `draft-and-pick`'s render, hand-off, pick, or loop mechanics
 - Add a `## Logo` section to `standards/design.md`'s fixed section set. `src/design/parse.ts` reads a fixed key set, and no outcome behind this skill asks for a schema change.
-- Modify `draft-and-pick`, `design-extract`, `canon capture`, or `canon design render`. This skill composes all four and extending any of them is a separate change.
+- Modify `draft-and-pick`, `canon capture`, or `canon design render`. This skill composes all three and extending any of them is a separate change.
 - Assume this skill's own invocation frequency needs no check. Whether anything reaches for it beyond an operator typing its name has no answer at creation time, so a review pass some months in should read that back rather than take it on faith.
 
 ## Guards

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

@@ -18,7 +18,7 @@ One identity rendered twice: the same mark sized down to an icon sequence and co
 
 Read these in parallel, skipping any that do not exist:
 
-- `canon/DESIGN.md`: the `## Personality`, `## Color`, and `## Typography` sections, the same three cells `design-extract` Step 2 sources from
+- `canon/DESIGN.md`: the `## Personality`, `## Color`, and `## Typography` sections
 - `canon/REQUIREMENTS.md`: the `## Personality` paragraph, when `canon/DESIGN.md` carries none
 - `CLAUDE.md`: the project's stated voice, when neither file above carries a personality signal
 
@@ -61,17 +61,19 @@ Announce which tier decided, naming the tier rather than the path alone. On tier
 
 ## Step 4: name the decision and the arms
 
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-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 already inside the full 1200x630 card frame, mark and type together, so the pick settles the shape and the composition in one choice. Arm 0 is the current mark when the folder from Step 3 already holds a logo file (`favicon.svg`, `favicon.ico`, `logo.svg`, or similar). Arms start at 1 otherwise.
+Follow `${CLAUDE_SKILL_DIR}/../draft-and-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 already inside the full 1200x630 card frame, mark and type together, and add its canvas frame at `--width 1200 --height 630`, so the pick settles the shape and the composition in one choice. Arm 0 is the current mark when the folder from Step 3 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 without re-deriving them.
 
 ## Step 5: draft, render, pick, and loop
 
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Steps 2 through 5 against the arms from Step 4: author the page, render and hand off, take the pick, and loop on it.
+Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/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.
+
+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 `draft-and-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 `draft-and-pick`'s own Step 6, since the pick here produces several final files rather than one applied surface.
+This step and Step 7 replace `draft-and-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. Give every page's captured element the shared class `.render`, so one capture call renders the whole batch regardless of the size spread. `canon capture` opens every page at a fixed 2x device scale factor and screenshots the element at that scale, so declare each `.render` element at half its target dimension, `<w>/2` by `<h>/2`, to land the captured PNG on the literal target size rather than double it. Declare no font on them, since each holds the mark alone and `canon capture` skips the font check on an element with no text. A generic family such as `system-ui` would be refused if text ever sat inside one.
@@ -135,9 +137,9 @@ canon capture <dest>/render/og-image.html --selector .render --out <write-folder
 
 It takes its own call rather than riding Step 6's batch, since Step 6 runs before this step chooses a path and the batch is already captured by the time the choice is made. 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
+### Closing the scratch folder and the canvas
 
-Delete `<dest>` per `draft-and-pick`'s own scratch-folder rule. The route is not a leftover variant that rule forbids: a variant is one of several candidates none of which was chosen, and the route holds the arm the operator picked. The losing arms are what that rule is about, and they are already archived and deleted by the step it belongs to.
+Delete `<dest>` once both captures land, then close the canvas through `draft-and-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 that close forbids: a variant is one of several candidates none of which was chosen, and the route 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 re-running the pick loop spends an operator's attention on a file nobody complained about, and the next real edit to the card picks up the route.
 
@@ -158,6 +160,6 @@ Card source: <the route, captured through the card server|a scratch page, since
 Cite these rather than restating them.
 
 - `draft-and-pick` owns Steps 1 through 5 of the render-and-pick loop, cited above
-- `design-extract` owns building `canon/DESIGN.md`. This skill only reads it.
+- `canon:canvas` 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 factor, and its reported dimensions. It already reads an `http(s)://` source, where `--out` names the destination PNG rather than a directory, so the route capture needs nothing added to it.
 - 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/draft-ready/REQUIREMENT.md

@@ -51,4 +51,4 @@ Without this skill, a session holding finished files that hands them to a worker
 - `role-worker` copies the folder into a worktree and ships it. This stops once the three artifacts exist.
 - `task-board` creates a task file for a row with no ready folder. This writes the row it needs beside the folder and calls the same verbs.
 - `git-ship` ships a branch, and a ready folder never reaches one.
-- `standards/ready.md` owns the folder's shape and lifecycle, and this skill owns the procedure that produces it, the way `write-human` and `800-prose` split.
+- `references/ready.md` owns the folder's shape and lifecycle, and this skill owns the procedure that produces it, the way `write-human` and the `markdown` rule split.

package/claude/skills/draft-ready/SKILL.md

@@ -11,9 +11,9 @@ A warm session that has already written a change hands the exact text to the wor
 
 Read these in parallel before writing:
 
-- `${CLAUDE_SKILL_DIR}/../../standards/ready.md`: the folder layout, the overview frontmatter, the mirrored tree, and the thin-plan contract
-- `${CLAUDE_SKILL_DIR}/../../standards/plan.md`: the plan's sections and its answer contract
-- `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`: the task file's shape and origin lines
+- `${CLAUDE_SKILL_DIR}/references/ready.md`: the folder layout, the overview frontmatter, the mirrored tree, and the thin-plan contract
+- `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`: the plan's sections and its answer contract
+- `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`: the task file's shape and origin lines
 - `${CLAUDE_SKILL_DIR}/references/assembly.md`: the overview and thin-plan templates and the destination match check
 
 ## Guards
@@ -61,7 +61,7 @@ install -D -m 0644 <source> <main-root>/.canon/ready/<nn>-<slug>/<destination pa
 
 ## Step 5: write the thin plan
 
-Write `<main-root>/.canon/plans/feature-<slug>.md` from the template, by heredoc, per `${CLAUDE_SKILL_DIR}/../../standards/plan.md`.
+Write `<main-root>/.canon/plans/feature-<slug>.md` from the template, by heredoc, per `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`.
 
 - List every Step 1 destination under `**Files to touch:**`, each with one clause on why it changes, pointing at the folder's copy rather than restating it.
 - Add a `**Constraints:**` line naming the ready folder as the verbatim source for those paths.
@@ -71,7 +71,7 @@ Run the match check in `${CLAUDE_SKILL_DIR}/references/assembly.md` before going
 
 ## Step 6: write the task
 
-Write `<main-root>/.canon/tasks/<label>-<slug>.md` by heredoc, from the label Step 2 claimed, without calling the verb again, since a second call would claim a different label. Its frontmatter, H1, and `## Outcomes` follow `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Write a `Ready:` line beside the `Plan:` line pointing at the folder, then point the task at the plan through the verb:
+Write `<main-root>/.canon/tasks/<label>-<slug>.md` by heredoc, from the label Step 2 claimed, without calling the verb again, since a second call would claim a different label. Its frontmatter, H1, and `## Outcomes` follow `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`. Write a `Ready:` line beside the `Plan:` line pointing at the folder, then point the task at the plan through the verb:
 
 ```bash
 canon tasks plan-link <task-stem> .canon/plans/feature-<slug>.md --json
@@ -79,7 +79,7 @@ canon tasks plan-link <task-stem> .canon/plans/feature-<slug>.md --json
 
 Branch on the record rather than on the exit. The `Ready:` line orients a worker reading the task, and `canon tasks archive` reads it to move the folder on ship.
 
-A task file with no row is a dropped task, so place the row in the same pass. The plan exists, so the row takes `## Run now`, per the tests in `${CLAUDE_SKILL_DIR}/../../standards/board.md`. A path `canon tasks plan-reach` reports as claimed is a shared file rather than a hold. Name each one and its holder wherever the row is reported below, so whoever controls the board decides whether a contract, a relocation, or a sweep moves the row to `## Up next`.
+A task file with no row is a dropped task, so place the row in the same pass. The plan exists, so the row takes `## Run now`, per the tests in `${CLAUDE_SKILL_DIR}/../task-board/references/board.md`. A path `canon tasks plan-reach` reports as claimed is a shared file rather than a hold. Name each one and its holder wherever the row is reported below, so whoever controls the board decides whether a contract, a relocation, or a sweep moves the row to `## Up next`.
 
 Check the roster the way `canon:task-board` Step 4 does, reading `canon sessions list --self --json` for this session and `canon sessions list --json` for a row from the same repository, under another `sessionId`, whose `name` starts with `orchestrator-`. Treat a refused read as a roster read that failed.
 

package/claude/skills/draft-ready/references/assembly.md

@@ -5,7 +5,7 @@ description: The overview and thin-plan templates for a ready folder, and the ma
 
 # Assembly
 
-Loaded from Step 3 and Step 5 of `draft-ready`. The shape rules live in `${CLAUDE_SKILL_DIR}/../../standards/ready.md` and `${CLAUDE_SKILL_DIR}/../../standards/plan.md`, so this file holds the fill-in forms and the one check that compares them.
+Loaded from Step 3 and Step 5 of `draft-ready`. The shape rules live in `${CLAUDE_SKILL_DIR}/references/ready.md` and `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`, so this file holds the fill-in forms and the one check that compares them.
 
 ## The overview
 

package/{standards → claude/skills/draft-ready/references}/ready.md

@@ -1,10 +1,6 @@
 ---
 title: Ready reference
 description: Folder layout, ordinal naming, the overview frontmatter, the thin-plan contract, and the archive lifecycle for a finished-file handoff
-paths:
-  - '.canon/ready/**'
-rule:
-  - 'Load the `canon:draft-ready` skill to write a ready folder, its overview, the thin plan, and the task row. It owns the procedure. Report it rather than proceeding silently when it does not resolve, since it ships with the plugin and this rule ships with the CLI.'
 ---
 
 # Ready reference
@@ -13,6 +9,18 @@ Applies to a ready folder at `.canon/ready/<nn>-<slug>/`. A warm session that ha
 
 The folder is gitignored, and backed wherever a records remote is configured: `canon records push` and `canon records pull` protect it against the machine being lost there, refuse with `no-remote` where it is not, and protect nothing against a folder deleted before anyone has pushed. That is why the archive step below is a move rather than a cleanup.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working ready folder looks like](#what-a-working-ready-folder-looks-like)
+- [Folder name](#folder-name)
+- [00-overview.md](#00-overviewmd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [The mirrored tree](#the-mirrored-tree)
+- [The thin-plan contract](#the-thin-plan-contract)
+- [Lifecycle](#lifecycle)
+- [Anti-patterns](#anti-patterns)
+- [Template](#template)
+
 ## Scope
 
 The `draft-ready` skill owns the procedure that writes a ready folder, and this standard owns the shape it writes to.
@@ -68,7 +76,7 @@ Below the frontmatter, state in prose what the worker still owns beyond copying
 
 ## The mirrored tree
 
-- Every other file in the folder sits at the same relative path its destination has in the project, so `standards/ready.md` inside the destination tree sits at `<nn>-<slug>/standards/ready.md` inside the ready folder.
+- Every other file in the folder sits at the same relative path its destination has in the project, so `standards/ready.md` inside the destination tree sits at `<nn>-<slug>/standards/ready.md` inside the ready folder. <!-- canon-allow-reference: the example shows a target tree, where the standard sits under standards/ -->
 - Carry no file the destination tree would not carry. A ready folder is a source for `git mv`-shaped copies, not a scratch pad for the warm session's own notes. Anything else belongs in the plan or in the pull request body.
 - Write each file exactly as it should land. The worker copies verbatim and edits only what the gate or the overview's own list requires, so a placeholder or a half-finished passage ships as written.
 

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

@@ -14,7 +14,7 @@ Format an issue from session context following the issue standard, then file it
 Read these in parallel:
 
 - `${CLAUDE_SKILL_DIR}/references/issue.md`: issue title, labels, body sections, and banned phrases
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 Then gather repo context in parallel:

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

@@ -30,7 +30,7 @@ Does not govern:
 ## Labels
 
 - Apply `bug` for a defect and `enhancement` for a task or improvement. Both are GitHub default labels.
-- Apply `feedback` to a report filed through `canon feedback --github`, which sets the label unconditionally rather than a session choosing it. It is not a GitHub default. Create it once per project with `gh label create feedback`.
+- Apply `feedback` to a report filed through `canon feedback`, which sets the label unconditionally rather than a session choosing it. It is not a GitHub default. Create it once per project with `gh label create feedback`.
 - A label that does not exist makes `gh` reject the issue. Create each one once with `gh label create`.
 - One label per issue unless a second genuinely applies.
 
@@ -83,11 +83,11 @@ Fix the feedback CLI so it applies the `feedback` label.
 
 ## Details
 
-`canon feedback --github` opens an issue with no label, so `canon-feedback-triage` never lists it.
+`canon feedback` opens an issue with no label, so `canon-feedback-triage` never lists it.
 
 ## Context
 
-Run a piped `canon feedback --github`, then check the issue carries no `feedback` label.
+Run a piped `canon feedback`, then check the issue carries no `feedback` label.
 
 ## Proposed
 

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

@@ -14,7 +14,7 @@ Read these files in parallel:
 - `${CLAUDE_SKILL_DIR}/../../standards/branch.md`: branch format, valid types, and constraints
 - `${CLAUDE_SKILL_DIR}/../../standards/pr.md`: structure, rules, and banned phrases
 - `${CLAUDE_SKILL_DIR}/references/labels.md`: label map format, matching, and the missing-label warning. Skip when the project has no `canon/config/pr-labels.toml` and no `.claude/canon/pr-labels.toml`.
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 - `${CLAUDE_SKILL_DIR}/../../standards/versioning.md`: phase label vs semver discipline
 

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

@@ -23,13 +23,11 @@ The sequence also reaches the remote on work nothing re-checked. This skill is t
 - Name the condition under which the closing block is not emitted, since a caller that closes on its own block leaves two instructions about the last line and nothing deciding between them
 - Watch continuous integration to a terminal state in the background, so the session stays reachable while CI runs, and stop on a failure naming the check
 - Read the evidence thread with `canon pr evidence <number> --check --json` once CI passes, run what it reports owed, and report done only on `settled`, since a chain that never reads the thread ships a regenerated image with no comment and no preview and leaves the controller to repair it
-- Stop memory work at the Propose phase
 
 ## Must not
 
 - Auto-trigger. Shipping is a decision the user takes, and the tool permission dialog on the push and the pull request is the gate that holds it now that the frontmatter no longer disables model invocation.
 - Fix a failing check. The stop is the point, since a green pull request reached by auto-fix hides what broke.
-- Run the memory Apply phase. Promoting an entry changes how the agent operates and ships as its own change.
 - Attempt a fix for a failing verify. The user is already making one, which is what brought the run back here.
 - Implement or review. This chain starts from work already believed done.
 - Report the chain done before the CI watch exits. A turn ending on the watch line leaves a pull request still waiting on CI, and a `✅ Shipped` there claims a result nothing has read.

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

@@ -9,7 +9,7 @@ metadata:
 
 Run the full post-feature workflow by invoking each skill in sequence using the Skill tool. After each skill returns, invoke the next step immediately in the same response.
 
-Do not output any text between steps and do not wait for user input. Tool permission dialogs are the only interrupts allowed. The final output is `✅ Shipped`, emitted on the wake after the step 9 watch exits on `passing` rather than when the turn ends on the watch line, unless a wrapping caller states it closes on its own block, which `auto-ship` does.
+Do not output any text between steps and do not wait for user input. Tool permission dialogs are the only interrupts allowed. The final output is `✅ Shipped`, emitted on the wake after the step 8 watch exits on `passing` rather than when the turn ends on the watch line, unless a wrapping caller states it closes on its own block, which `auto-ship` does.
 
 ## Verify
 
@@ -25,17 +25,16 @@ Run `git diff --cached --name-only 2>/dev/null` to check for staged files. If ou
 
 ## Sequence
 
-1. Invoke `canon:memory-capture` to route what this session learned to the context entries that own it and write the residue to `.canon/memory/`
-2. Invoke `canon:context-fold` to sync internal planning docs against session decisions, folding in the routed facts
-3. Invoke `canon:docs-sync` to sync public docs against changes since main
-4. Run `git add -A` to stage any files the sync skills wrote
-5. Run `canon tasks plan-reach <plan> --json` and report both lists it carries. Name the plan this branch built under, by path or by slug. Read `claimed` first and say who holds each path, since that is the half a reader acts on, then say how many of the changed paths `undeclared` names. Branch on the record rather than on the exit code, which a shell function wrapping `canon` can flatten to zero. This step reports and never stops the sequence.
-6. Invoke `canon:git-stage` to group staged changes and commit by concern, only when `git diff --cached --name-only` prints a path. When it prints nothing, the work already reached history in slices, so continue to step 7.
-7. Invoke `canon:git-branch` to rename branch to match conventional format
-8. Invoke `canon:git-pr` to push branch and open pull request
-9. After the PR opens, watch CI in the background, so the session stays reachable while CI runs. Read `### Watching CI` below for the commands and the wake.
+1. Invoke `canon:context-fold` to sync internal planning docs against session decisions
+2. Invoke `canon:docs-sync` to sync public docs against changes since main
+3. Run `git add -A` to stage any files the sync skills wrote
+4. Run `canon tasks plan-reach <plan> --json` and report both lists it carries. Name the plan this branch built under, by path or by slug. Read `claimed` first and say who holds each path, since that is the half a reader acts on, then say how many of the changed paths `undeclared` names. Branch on the record rather than on the exit code, which a shell function wrapping `canon` can flatten to zero. This step reports and never stops the sequence.
+5. Invoke `canon:git-stage` to group staged changes and commit by concern, only when `git diff --cached --name-only` prints a path. When it prints nothing, the work already reached history in slices, so continue to step 6.
+6. Invoke `canon:git-branch` to rename branch to match conventional format
+7. Invoke `canon:git-pr` to push branch and open pull request
+8. After the PR opens, watch CI in the background, so the session stays reachable while CI runs. Read `### Watching CI` below for the commands and the wake.
 
-A caller wrapping this sequence may act between step 8 and step 9, which is the one gap the order leaves open, since the pull request exists there and nothing has read its checks yet. `auto-ship` marks the pull request draft in it. Nothing else may go there, and a caller that needs a step anywhere else in the sequence is asking for a change to this body rather than for a place to stand.
+A caller wrapping this sequence may act between step 7 and step 8, which is the one gap the order leaves open, since the pull request exists there and nothing has read its checks yet. `auto-ship` marks the pull request draft in it. Nothing else may go there, and a caller that needs a step anywhere else in the sequence is asking for a change to this body rather than for a place to stand.
 
 ### Watching CI
 
@@ -62,18 +61,18 @@ Do not auto-fix any of these. The watch line and a stop report from any branch a
 
 ### Settling the evidence thread
 
-On a `passing` wake, run `canon pr evidence <number> --check --json` against the number step 8 returned. It reads the pull request's comments and edits none, so the comment a reviewer already ticked stays as it is. Branch on `reason` and `owed` rather than the exit.
+On a `passing` wake, run `canon pr evidence <number> --check --json` against the number step 7 returned. It reads the pull request's comments and edits none, so the comment a reviewer already ticked stays as it is. Branch on `reason` and `owed` rather than the exit.
 
 - `settled`: nothing is owed, which is also what a branch that changed no rendered surface reads. Continue to After completion.
 - `owed`: run each step the record's `owed` list names, from `canon:git-pr`'s `references/evidence.md`, evidence first and then preview. Re-read once with the same command. Continue to After completion only on `settled`. Any other reading stops the sequence and reports the `reason` with the `owed` list, and the sequence never loops back for a second pass. A preview step that refuses, or a deploy that failed, leaves `preview` owed on the re-read, so that is the stop and not a retry.
 - Any other `reason`, such as `gh-failed`: the thread went unread. Stop and report the `reason`, since an unread thread is not a settled one.
 - No record at all, or an unknown flag error: the installed binary predates `--check`. Report the thread unread rather than settled, and continue to After completion without emitting a claim that it was checked.
 
-The read is a closing step and the draft mark stays the only thing between steps 8 and 9. A caller that closes on its own block, as `auto-ship` does, waits on the same CI wake, so the read lands here and not in that body.
+The read is a closing step and the draft mark stays the only thing between steps 7 and 8. A caller that closes on its own block, as `auto-ship` does, waits on the same CI wake, so the read lands here and not in that body.
 
-### Why the reach reads at step 5
+### Why the reach reads at step 4
 
-The branch is whole there and nowhere earlier. Steps 2 and 3 write past whatever the plan declared, so a reading taken ahead of them misses the chain's own additions, and no pull request exists until step 8 to carry the answer anywhere.
+The branch is whole there and nowhere earlier. Steps 1 and 2 write past whatever the plan declared, so a reading taken ahead of them misses the chain's own additions, and no pull request exists until step 7 to carry the answer anywhere.
 
 It is the one step here that reports rather than acts, which is why it never stops the sequence. Every crossing measured on the wave it was filed against merged clean, and the undeclared list runs long enough on an ordinary branch that a gate would fire on nearly every ship.
 
@@ -81,19 +80,12 @@ It is the one step here that reports rather than acts, which is why it never sto
 
 An installed binary carrying no `plan-reach` subcommand reports the reach unread rather than clear. Say that, and continue. The verb ships with the CLI and this body ships with the plugin, so a target on an older binary meets a missing subcommand, and a body reading that absence as a clean answer would report the check passing on every branch that never ran it.
 
-Capture leads the sequence because a routed fact lands in a context entry, which is a tracked file. Running it after the pull request opens leaves that edit off the branch entirely, so the fact reaches nothing. Memory files are gitignored either way, which is what hid the ordering while capture wrote only those.
-
 ## After completion
 
-Output up to four lines:
+Output one line:
 
 ```plaintext
 ✅ Shipped
-<N facts routed to context entries>
-<N memories captured in .canon/memory/>
-<the review line memory-capture returned>
 ```
 
-Omit the second line if nothing routed, the third if `memory-capture` wrote no memory file this session, and the fourth if `memory-capture` returned no review line. Pass that line through verbatim rather than restating it.
-
-Emit nothing here when a wrapping caller states it closes on its own block. `auto-ship` is that caller and its block carries these same three trailing lines below a first line naming the draft state, so emitting both reports one run twice. A caller that states no such thing gets this block, which is every direct invocation.
+Emit nothing here when a wrapping caller states it closes on its own block. `auto-ship` is that caller and its block opens on a line naming the draft state, so emitting both reports one run twice. A caller that states no such thing gets this block, which is every direct invocation.

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

@@ -10,7 +10,7 @@ metadata:
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/commit.md`: format, types, scopes, and constraints
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 ## Context

package/claude/skills/markdown-craft/REQUIREMENT.md

@@ -0,0 +1,23 @@
+---
+name: markdown-craft
+description: Why the markdown format rules travel in a skill, and where the boundary sits against the voice skill and the audit command
+---
+
+# Markdown craft requirement
+
+## Gap
+
+Without this skill, the markdown format rules sat in a standard that a session opened only when a rule told it to. The banned characters and the structure rules are facts a scan settles, yet a session wrote the whole document from memory and learned the result only from the audit's exit.
+
+The rules also had three carriers, a standard, a generated rule pointing at it, and a second hand-written rule routing voice. Each stated one routing and each drifted from the others.
+
+## Must
+
+- Hold the format and structure reference in `references/markdown.md`, the one copy, read by sibling path from every skill that writes markdown
+- Send the session to `canon markdown audit` after an edit, since the audit reads the bans from the package and a restated list would drift
+- Route voice to `write-human` and a Mermaid fence to `draft-figure` rather than restating either
+
+## Must not
+
+- Restate the banned characters in the body
+- Carry voice, rhythm, or word guidance, which `write-human` owns

package/claude/skills/markdown-craft/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: markdown-craft
+description: Carries the format and structure rules for markdown, being headings, paragraph and list shape, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording, and runs the audit after an edit. Use before a substantial markdown edit, when writing a README, a doc, a skill body, or any `.md` file, or when asked "what are the markdown rules" or "which characters are banned". Do NOT use for voice, rhythm, or word choice, which is `write-human`, or for a Mermaid fence or figure, which is `draft-figure`.
+metadata:
+  family: answer
+---
+
+# Markdown craft
+
+Read `${CLAUDE_SKILL_DIR}/references/markdown.md` before a substantial markdown edit. Every rule in it is a fact a scan can settle, so do not work the banned characters from memory.
+
+Run `canon markdown audit <path>` after the edit. Rewrite the sentence carrying a hit rather than swapping the token for a near-synonym.
+
+## Routes
+
+- Voice, rhythm, sentence construction, and information density: load `write-human`.
+- A Mermaid fence or a figure: load `draft-figure`, since the audit skips every line inside a fence.