@erclx/canon 5.30.0 → 5.32.0

package/{standards → claude/skills/markdown-craft/references}/markdown.md

@@ -1,19 +1,26 @@
 ---
 title: Markdown reference
 description: Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording
-paths:
-  - '**/*.md'
-rule:
-  - 'Read it before a substantial markdown edit. Do not work the banned characters from memory.'
-  - 'Run `canon markdown audit <path>` after the edit, and rewrite the sentence carrying a hit rather than swapping the token for a near-synonym.'
-  - 'Voice, rhythm, and sentence construction are a separate topic. `800-prose` routes them.'
-  - 'Load the `canon:draft-figure` skill before drafting or revising a Mermaid fence or a figure, and report it rather than proceeding silently when it does not resolve.'
 ---
 
 # Markdown reference
 
 Applies to markdown reference docs, READMEs, and inline documentation in repos. Every rule here is a fact a scan can settle rather than a judgment, so no surface yields any of them. A surface stating its own voice claims that yield from the voice guidance and formats and spells by this file regardless.
 
+## Contents
+
+- [Scope](#scope)
+- [Headings](#headings)
+- [Paragraphs and lists](#paragraphs-and-lists)
+- [Code and identifiers](#code-and-identifiers)
+- [Dates](#dates)
+- [Punctuation](#punctuation)
+- [Language](#language)
+- [Frontmatter descriptions](#frontmatter-descriptions)
+- [Emphasis and dividers](#emphasis-and-dividers)
+- [Links and file references](#links-and-file-references)
+- [Examples](#examples)
+
 ## Scope
 
 Governs what a check can decide about a markdown file: headings, paragraph and list structure, code spans and fences, the form a date takes, punctuation, emphasis, file references, the spelling convention, what prose may claim about its sources, and the wording of a catalog title and description. It is an attribute standard rather than a document-type one, so it applies over documents whose shape another standard sets, and it carries no template because these rules are written across every document and have no shape of their own.

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

@@ -13,8 +13,9 @@ Without this skill, implementation starts before anyone knows what it touches. A
 
 - Read the project's own Claude setup before scanning source, so the plan inherits decisions already made instead of reopening them
 - Reframe a vague ask as observable, checkable success criteria before listing any file, and carry each criterion into the plan's verification, so a plan never ships a check with nothing measurable to prove
-- Slice batches by a user-visible path rather than by layer, and sequence the riskiest batch first while a sweep stays last, so the batch most likely to change the plan lands while later ones can still move
+- Slice batches by a user-visible path rather than by layer, and sequence the riskiest batch first while a sweep stays last, so the batch most likely to change the plan lands while later ones can still move, and fold a stacked batch that shares most of its files into its parent unless the plan writes down why the two are judged apart, since a canvas inspector built as five stacked pull requests over 26 files paid the full review, rebase, and merge cost five times
 - Predict the operator's answers to the next three questions about the ask's success criteria, proceed on the ones it can predict, and ask when it can predict none, since a plan built on a guessed goal proves the wrong thing
+- Fetch the outside source a decision rests on, quote the passage relied on in the plan's `**Sources:**` section, and mark a source it could not fetch as unverified, since a planner that paraphrases a practice from model memory ships an unaudited claim. A measured planner run fetched its sources only after a follow-up message asked, and the `search-craft` measured run shows a plain research request never loaded that skill unprompted
 - Name every file the work touches with the reason it is touched
 - Place each new path against the layout guidance with a one-clause reason, loading that guidance only when the plan creates a file or folder, since the planner decides placement and the worker copies whatever path it is given
 - Name how each outcome is proven and which input or state would break the change, so the executing session has a check to run and the reviewer has a place to look

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

@@ -20,15 +20,11 @@ Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
 - `canon/REQUIREMENTS.md`: feature scope and non-goals
-- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: current scope and status, then any task file the feature relates to
 
 Also read these when the feature touches code or UI. Skip them for prose, docs, catalog, or config-only changes:
 
 - `canon/DESIGN.md`: tokens, typography, spacing, and component rules
-- `canon/wireframes/index.md` + the surface files relevant to the feature: intended UI layout and behavior. Read `index.md` first, then follow only the links the feature actually touches, each a flat `canon/wireframes/<surface>.md` or a grouped surface's own `canon/wireframes/<surface>/index.md` and the siblings it lists. Do not read the whole folder speculatively.
-
-When the plan adds or revises a surface, the wireframe file follows `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md`.
 
 Coding standards live in `.claude/rules/`. Claude Code loads them automatically. Path-scoped rules apply to the files they match.
 
@@ -40,17 +36,27 @@ Measure against the tree rather than recall. Grep for each construct the plan wi
 
 Open each file before describing what is in it. A count or a claim carried from an earlier session, a summary, or another document is the most common way a plan ships the wrong scope.
 
+When a decision the plan will make rests on an outside practice or a third-party behavior, invoke `canon:search-craft` before searching, fetch each source, and record the passage relied on. Skip this for a plan that rests on nothing outside the project.
+
+- Ask the fetch for the verbatim passage, and confirm the wording through `curl` where a decision turns on exact wording, since `WebFetch` returns a model's answer rather than the page.
+- Route a Claude Code subject to the `claude-code-guide` agent.
+- Mark a source that could not be fetched as unverified rather than citing recall.
+- Report it rather than proceeding silently when `canon:search-craft` does not resolve.
+
 ## Step 3: build the plan
 
-The section list, what each section holds, and the suggested-and-answer contract are fixed by `${CLAUDE_SKILL_DIR}/../../standards/plan.md`, and the lifecycle by `${CLAUDE_SKILL_DIR}/../../standards/plan-lifecycle.md`. Read it before writing the file and follow it rather than working the shape from memory.
+The section list, what each section holds, and the suggested-and-answer contract are fixed by `${CLAUDE_SKILL_DIR}/references/plan.md`, and the lifecycle by `${CLAUDE_SKILL_DIR}/references/plan-lifecycle.md`. Read it before writing the file and follow it rather than working the shape from memory.
 
 What this skill adds on top of the standard:
 
 - Reframe a vague ask as success criteria before writing `**Files to touch:**`. Each criterion names something observable and a check that decides it, such as a measure and the threshold it must stay under, drawn from the ask or the project context. "Make it faster" names no criterion, while a stated budget for one path does. Each criterion becomes one `**Verification:**` bullet.
+- Confirm a concrete project or use case drives the feature before shaping it, and lift patterns from that project where precedent exists. A feature with no named user is a guess about what one will want.
+- Prefer one layout that serves both a new and a grown project over a dual-mode toggle or a migration shim. Two modes double what every later change has to hold.
 - Apply senior judgment to every `- Suggested:` line. Pick the best option and state it in one line with its reason or main tradeoff. No padding, no alternatives unless they change the pick.
 - Suggest a real default when best practice, the codebase, or prior context points to one.
 - Load the `canon:codebase-layout` skill before writing the `**Files to touch:**` entries when any of them names a file or folder that does not exist yet, and give each new path its placement reason in its entry. Skip the load when every entry edits an existing file. Report it rather than proceeding silently when the skill does not resolve.
 - Write `**Verification:**` as one bullet per outcome naming the test or command that proves it, and `**Review focus:**` as the inputs or states that would break the change. You understood the risk before any diff existed, and these two sections carry it to the executing session and to the reviewer.
+- Cite the `**Sources:**` entry for every decision Step 2 sourced, each with its quoted passage or the word `unverified`.
 - Prefer `None identified.` over low-signal fillers. A small feature should produce a short plan, not a padded one.
 - When three or more questions remain, keep chat output to the file pointer plus a short summary. Inline chat is fine when two or fewer remain.
 
@@ -59,9 +65,9 @@ What this skill adds on top of the standard:
 A plan sequencing its work into batches declares where one pull request ends, here rather than at ship time. A dependency chain cannot be split once it is built, so the choice exists only while the batches are still a plan.
 
 - One batch is one pull request, and one pull request is one plan file, named for its own concern rather than a numeric suffix. `canon tasks plan-branch` derives one branch from one plan filename, so a `**Batch N**` sub-heading inside one file's `**Files to touch:**` shares that one branch across every batch, and the batch that merges first strands every batch behind it with nothing left to open a pull request against. Write a plan opening five batches as five files before the first line of any of them.
-- State a dependent batch's dependency on the ones before it in its own `**Constraints:**`, naming the earlier batch's slug and stacking rather than merging into it. The batches are built in order and depend on each other in that order, which is what a stack expresses, so the dependency argues for stacking and never for collapsing two batches into one file or one review.
+- State a dependent batch's dependency on the ones before it in its own `**Constraints:**`, naming the earlier batch's slug and stacking rather than merging into it. A batch that builds after another and shares most of its files with it folds into that batch as contiguous commits on one branch, since each pull request pays a fixed cost a same-file slice cannot earn back, and the rebases between stacked slices land on the same files. Keep a batch apart only where a reviewer or the operator would judge it apart: a contract a later batch is built against, a taste call the operator judges in its own sitting, or a fold that would exceed one review. Write that reason as ``Judged apart from `feature-<parent>`: <reason>`` in the batch's `**Constraints:**`. `canon records validate plans` reports a stacked batch that should have folded, and its thresholds live there.
 - Mark each batch dependent or independent by comparing the file sets rather than the descriptions. A batch sharing no file with another is independent and earns its own branch even where both arrived in one request. One run measured at 68 files carried three such batches into a single review because nothing drew the boundary.
-- Slice a batch by one user-visible path end to end rather than by layer, so each batch ships something a person can exercise. The slice decides what a batch contains, and the file-set comparison above still decides whether two batches depend on each other, so two slices sharing a file stay marked dependent and stacked.
+- Slice a batch by one user-visible path end to end rather than by layer, so each batch ships something a person can exercise. The slice decides what a batch contains, and the file-set comparison above still decides whether two batches depend on each other, so two slices sharing a file stay marked dependent. A path too thin to pay a pull request of its own folds forward into the next.
 - Sequence the riskiest batch first, so the batch most likely to change the plan is built while every later batch can still move. A sweep is the one exception and stays last even when it is the riskiest, per the next bullet.
 - Sequence a sweep last. A batch deliberately rewriting files earlier batches touched is coherent as the final one and forces every batch behind it into one review anywhere else.
 - Keep each batch's commits contiguous once the work starts. A later fix to an earlier batch belongs on that batch's own commits, since a batch interrupted by another cannot be lifted onto its own branch afterward.
@@ -109,7 +115,7 @@ Derive a 2-to-4-word kebab-case slug from the feature description. Write the ful
 
 The plan is a main-root write, from a linked worktree and from a background session sitting at the main root with none entered alike, so it goes out as a heredoc, routed the way `session-worktree` states.
 
-The file follows the template in `${CLAUDE_SKILL_DIR}/../../standards/plan.md`. Copy the shape from there rather than from this body, so one edit to the standard moves every plan.
+The file follows the template in `${CLAUDE_SKILL_DIR}/references/plan.md`. Copy the shape from there rather than from this body, so one edit to the standard moves every plan.
 
 Run `canon records validate plans` after writing the file when the CLI is on PATH. It reports a section, a filename, or an answer slot that does not hold, and it writes nothing.
 

package/{standards → claude/skills/plan-feature/references}/plan.md

@@ -1,15 +1,6 @@
 ---
 title: Plan reference
 description: Filename and slug, the required sections, and the suggested-and-answer contract for a feature plan
-paths:
-  - '.canon/plans/**'
-rule:
-  - 'Never fill an `- Answer:` slot on behalf of the person who owns it. A blank slot accepts the suggestion at execution time.'
-  - 'Never ship a question without a `- Suggested:` line. Write `- Suggested: needs your call, <why>` where the answer turns on preference.'
-  - "Rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement when execution deviates from an unanswered question, leaving the slot blank. Put the same deviation in one line under the open task's `## Findings`."
-  - 'Move a shipped plan to `.canon/plans/archive/`. Never delete one.'
-  - 'Amend a plan in place when a decision changes. Do not append a second passage narrating the change.'
-  - 'Follow the plan lifecycle standard for when a plan is written, how it is amended, and its move to the archive. Read it with `canon standards plan-lifecycle`.'
 ---
 
 # Plan reference
@@ -20,6 +11,15 @@ The folder is gitignored, and backed by `canon records push` wherever a records
 
 <!-- canon-length-exempt: the constraint forms and the answer contract share one reader, and a split into a second standard is queued as its own change -->
 
+## Contents
+
+- [Scope](#scope)
+- [What a working plan looks like](#what-a-working-plan-looks-like)
+- [Filename and slug](#filename-and-slug)
+- [Sections](#sections)
+- [The suggested-and-answer contract](#the-suggested-and-answer-contract)
+- [Template](#template)
+
 ## Scope
 
 Governs a feature plan under `.canon/plans/feature-<slug>.md`: the filename, the required sections, what each holds, and the suggested-and-answer contract.
@@ -51,7 +51,7 @@ A plan failing these is non-conforming even when it satisfies every shape rule b
 
 - Name the file `feature-<slug>.md`, with `<slug>` two to four kebab-case words naming the concern.
 - Write one concern per file. A request spanning two independent concerns takes two plans rather than one bundling both, since a bundled plan cannot be executed by two sessions or abandoned by half.
-- A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `**Files to touch:**`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges. State a batch's dependency on the ones before it in its own `**Constraints:**`.
+- A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `**Files to touch:**`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges. State a batch's dependency on the ones before it in its own `**Constraints:**`. A batch that stacks on another and shares most of its files with it folds into that batch as contiguous commits on one branch rather than taking a file, unless its constraints carry ``Judged apart from `feature-<parent>`: <reason>`` with a reason after the colon. `canon records validate plans` reports `stack-foldable` for a stacked batch that has neither.
 - Derive the slug from the concern rather than from a branch, because the plan is written before the branch exists.
 - Give the branch that executes the plan the same slug. A later surface finds the plan from the branch name and finds nothing when the two spellings differ.
 
@@ -61,17 +61,18 @@ A plan carries no frontmatter. Its filename is the whole of its identity, so a f
 
 The document opens with `# Feature: <short title>` and one paragraph stating what is being built and why now. The sections below follow in this order.
 
-| Section               | Holds                                                                     | Required      |
-| --------------------- | ------------------------------------------------------------------------- | ------------- |
-| `## Summary`          | three to five one-line bullets: the goal, the deliverables, the trade-off | Always        |
-| `**Constraints:**`    | durable rules the work must respect                                       | When supplied |
-| `**Files to touch:**` | each file with a one-line reason                                          | Always        |
-| `**Verification:**`   | the test or command that proves each outcome                              | Always        |
-| `**Risks:**`          | conflicts, coupling, and the tricky spots                                 | Always        |
-| `**Review focus:**`   | the inputs or states that would break the change, for the reviewer        | Always        |
-| `**Questions:**`      | numbered open decisions, each with a suggestion and an answer slot        | Always        |
-
-- Write each marker as the table gives it. `Summary` opens the prose a reader scans, so it takes an H2, and the six that follow are labels over lists rather than sections of prose.
+| Section               | Holds                                                                     | Required                                   |
+| --------------------- | ------------------------------------------------------------------------- | ------------------------------------------ |
+| `## Summary`          | three to five one-line bullets: the goal, the deliverables, the trade-off | Always                                     |
+| `**Constraints:**`    | durable rules the work must respect                                       | When supplied                              |
+| `**Files to touch:**` | each file with a one-line reason                                          | Always                                     |
+| `**Verification:**`   | the test or command that proves each outcome                              | Always                                     |
+| `**Risks:**`          | conflicts, coupling, and the tricky spots                                 | Always                                     |
+| `**Review focus:**`   | the inputs or states that would break the change, for the reviewer        | Always                                     |
+| `**Questions:**`      | numbered open decisions, each with a suggestion and an answer slot        | Always                                     |
+| `**Sources:**`        | the outside sources a decision rests on, each with its quoted passage     | When a decision rests on an outside source |
+
+- Write each marker as the table gives it. `Summary` opens the prose a reader scans, so it takes an H2, and the others are labels over lists rather than sections of prose.
 - A section written in the other spelling is still that section, since `## Risks` and `**Risks:**` name one thing. Write the table's form in a new plan and leave an existing plan's spelling alone. Either spelling breaks a depth run.
 - Write `None identified.` under a required section with nothing to report rather than dropping the marker. A dropped section and an unconsidered one read identically.
 - Aim `## Summary` at a person scanning the plan, not at the session executing it. The other sections carry what execution needs.
@@ -118,6 +119,13 @@ A constraint naming a `.canon/ready/` folder is a third shape beside the hold an
 - Write it for the reviewer rather than the builder, since this section is where the planner's understanding of the risk reaches the review pass.
 - Keep it apart from `**Risks:**`. A risk is something the work might collide with, and a focus item is something the finished diff must be shown to handle.
 
+### Sources
+
+- Give each entry a link, the decision it backs, and the passage relied on in double quotes.
+- Mark a source that could not be fetched `unverified` and never quote it. A quote for a page nobody opened is the failure this section exists to prevent.
+- Cite no source that was found and not opened, following the lead rule in `groundwork.md`.
+- Leave the section out when no decision rests on an outside practice or behavior. `canon records validate plans` checks that an entry is well formed, not that every outside claim got one.
+
 ## The suggested-and-answer contract
 
 Every question carries a `- Suggested:` line and an empty `- Answer:` slot below it.
@@ -191,4 +199,8 @@ This contract inverts the one an intake folder keeps, where an empty slot means
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>
    - Answer:
+
+**Sources:**
+
+- [<title>](url), backing <decision>: "<passage relied on>"
 ```

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

@@ -9,7 +9,7 @@ metadata:
 
 Groundwork gathers and weighs. A plan commits. A groundwork folder costs nothing to throw away, which is what makes it the right container for a question nobody has answered yet.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/groundwork.md` before writing any file in the folder. It holds the reserved numbers, the frontmatter and dating rules, what each required file carries, the conventions, and the anti-patterns. Do not work them from memory.
+Read `${CLAUDE_SKILL_DIR}/references/groundwork.md` before writing any file in the folder. It holds the reserved numbers, the frontmatter and dating rules, what each required file carries, the conventions, and the anti-patterns. Do not work them from memory.
 
 ## Guards
 
@@ -25,7 +25,7 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/groundwork.md` before writing any file
 - One exception, at close only: write one task file recording what the track concluded.
 - A second exception, for what a spike reads as bulk input: write a large fixture under `.canon/tmp/runs/groundwork-fixtures/<slug>/`. Keep it out of `.canon/groundwork/` so mode detection never matches a fixture as a track. A fixture a headless run is pointed at goes outside the repository instead, per the rule in `## Running a spike`. An arm script and a checkout a claim rests on are not fixtures, and go inside the track under `scripts/` and `clones/`, per the standard.
 - What a spike produces stays inside the track rather than joining the two exceptions above: write evidence a spike file cites under `.canon/groundwork/<nn>-<slug>/evidence/`, which the first rule already permits. Mode detection matches entries at the top level of the tracks directory, so the sibling the fixtures rule guards against cannot be a folder nested inside a track, and the scratch path holds only what can be deleted without loss, which a recording a finding rests on is not.
-- A `draft-and-pick` run invoked from inside a live track follows its own branch for this, writing to `evidence/` here rather than `.canon/tmp/<slug>/`.
+- A `draft-and-pick` run invoked from inside a live track follows its own branch for this. It writes its renders to `evidence/` here, and drafts its candidates as canvas pages under `.canon/canvas/` that its close deletes.
 - Reading is not restricted. External research is in scope, so read documentation, comparable projects, and papers whenever a live question needs them. Invoke `canon:search-craft` with the skill tool before an outside search, and report it rather than proceeding silently when the skill does not resolve.
 - Every claim about a source outside the project carries a link to it. A source found and not read is listed as a lead and is never cited.
 - Treat the folder as gitignored, and backed only where a records remote is configured: `canon records push` and `canon records pull` protect it against the machine being lost there and refuse with `no-remote` otherwise, and neither protects against a compaction dropping this session's own reasoning before anyone has pushed, so `07-next-session.md` repeats what it needs instead of pointing at its siblings.
@@ -35,7 +35,7 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/groundwork.md` before writing any file
 A track may run an experiment to settle an open question without stopping to ask. What it takes depends on what the experiment does.
 
 - Reading or computing: run it. Unrestricted reading already covers this, and it is what most spikes turn out to be.
-- Anything that processes an input: start against a sample and scale up after it works, per the sample rule in `${CLAUDE_SKILL_DIR}/../../standards/groundwork-spikes.md`, which bounds it on size, duration, and spend.
+- Anything that processes an input: start against a sample and scale up after it works, per the sample rule in `${CLAUDE_SKILL_DIR}/references/groundwork-spikes.md`, which bounds it on size, duration, and spend.
 - Writing a fixture this session reads or provisions itself: run it, under the fixtures path above. Provisioning is the usual blocker rather than spend, and it costs nothing.
 - Spawning a billed headless session: run up to three, then ask before spawning more. The bound is a run count rather than a budget, because a headless run reports its total cost only after it finishes, so a dollar ceiling is reportable and not enforceable while a run count is checkable before spawning.
 
@@ -64,7 +64,6 @@ Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
 - `canon/REQUIREMENTS.md`: scope and non-goals
-- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: what is already tracked, and what a prior track concluded. Open a task file only when its entry looks related.
 
 Then read only what a live question needs. Do not read entire directories speculatively. Where a folder carries an `index.md`, read it first and load only the files it points at.
@@ -77,7 +76,7 @@ The standard sets the open question format and requires it inside a topic file a
 
 ## Open mode
 
-1. Claim the ordinal and create the folder in one act with `canon records ordinal groundwork <slug> --claim`, per `${CLAUDE_SKILL_DIR}/../../standards/groundwork.md`. Where the installed binary carries no such subcommand, fall back to listing both `.canon/groundwork/` and `.canon/intake/` and creating `.canon/groundwork/<nn>-<slug>/` at the highest ordinal present across the two, incremented.
+1. Claim the ordinal and create the folder in one act with `canon records ordinal groundwork <slug> --claim`, per `${CLAUDE_SKILL_DIR}/references/groundwork.md`. Where the installed binary carries no such subcommand, fall back to listing both `.canon/groundwork/` and `.canon/intake/` and creating `.canon/groundwork/<nn>-<slug>/` at the highest ordinal present across the two, incremented.
 2. Write `README.md` first. Writing it first forces the question of what the track is for.
 3. Write `01-current-state.md` by measuring now. Never carry a figure from a previous session or from recall without re-measuring it. Measure only what an open question in the folder needs. A number with no question attached is how groundwork turns into the work.
 4. Write `00-scope.md` when the track is large enough to run away. Skip it on a small track.
@@ -96,7 +95,7 @@ The standard sets the open question format and requires it inside a topic file a
 1. Write `06-decision.md`. It states the problem once, names the goal, lists what to do, and lists what was considered and dropped. Carry the "Overturned by" line of each lean that became the decision into a `## Revisit when` section, and carry none from a lean the decision did not take.
 2. Write `07-next-session.md` self-contained, so it survives a compaction that loses the conversation.
 3. Update the file map in `README.md`.
-4. Write one task file in `.canon/tasks/` recording what the track concluded, even when the conclusion is to do nothing. Follow `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` for the filename and frontmatter. Place the row through `task-board` Step 4, which checks the roster for a live orchestrator before writing `priority.md` or `backlog.md` directly. Aside from an experiment fixture, this and the routing in Step 5 are the only ways close mode reaches outside the folder.
+4. Write one task file in `.canon/tasks/` recording what the track concluded, even when the conclusion is to do nothing. Follow `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md` for the filename and frontmatter. Place the row through `task-board` Step 4, which checks the roster for a live orchestrator before writing `priority.md` or `backlog.md` directly. Aside from an experiment fixture, this and the routing in Step 5 are the only ways close mode reaches outside the folder.
 5. When the task written in Step 4 does not cover every finding the track surfaced, route what it leaves out through `plan-intake`. Skip this step when it does.
 6. Report uncited external claims. Closing already reads every file in the folder, so list any statement about a source outside the project that carries neither a link nor a lead entry. Report and do not block, because judging whether a sentence makes an external claim is the call a checker gets wrong.
 

package/{standards → claude/skills/plan-groundwork/references}/groundwork.md

@@ -1,10 +1,6 @@
 ---
 title: Groundwork reference
 description: Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
-paths:
-  - '.canon/groundwork/**'
-rule:
-  - 'Follow the groundwork spikes standard for `08-spikes.md` and the folders holding what a spike produced. Read it with `canon standards groundwork-spikes`.'
 ---
 
 # Groundwork reference
@@ -13,6 +9,23 @@ Applies to a groundwork track at `.canon/groundwork/<nn>-<slug>/`. A track measu
 
 The folder is gitignored, and backed by `canon records push` wherever a records remote is configured. Nothing backs it against a compaction dropping a session's reasoning before a push, so the handoff file has to be self-contained.
 
+## Contents
+
+- [Scope](#scope)
+- [Folder name](#folder-name)
+- [What a working track looks like](#what-a-working-track-looks-like)
+- [Frontmatter and dating](#frontmatter-and-dating)
+- [Reserved numbers](#reserved-numbers)
+- [README.md](#readmemd)
+- [01-current-state.md](#01-current-statemd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [00-scope.md](#00-scopemd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [06-decision.md](#06-decisionmd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [07-next-session.md](#07-next-sessionmd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [Open questions](#open-questions)
+- [Conventions](#conventions)
+- [Anti-patterns](#anti-patterns)
+- [Template](#template)
+
 ## Scope
 
 Governs a groundwork track under `.canon/groundwork/<nn>-<slug>/`: folder layout, ordinal naming, reserved numbering, frontmatter and dating, what each required file holds, and the conventions a track keeps.

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

@@ -9,7 +9,7 @@ metadata:
 
 Intake dispositions many findings in breadth. A dump goes in, an inventory comes out, and every item carries a problem measured against the tree, one proposed fix, and a verdict. The item that turns out to be already settled is the highest-value output, and it is the one thing neither a plan nor a groundwork track has anywhere to put.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/intake.md` before writing any file in the folder. It holds the numbering, the file map, the frontmatter and dating rules, the item format, and the answer contract. Do not work them from memory.
+Read `${CLAUDE_SKILL_DIR}/references/intake.md` before writing any file in the folder. It holds the numbering, the file map, the frontmatter and dating rules, the item format, and the answer contract. Do not work them from memory.
 
 ## Routing
 
@@ -44,7 +44,7 @@ List `.canon/intake/` from the project root and match the topic against the slug
 
 Never match against `.claude/` itself. That directory holds every other workflow surface, so a topic matched there lands on a folder that was never an intake.
 
-With no match, derive a kebab-case slug named for the subject rather than the activity. Prefer `toolkit-overview` over `august-triage`. Claim the ordinal and create the folder in one act with `canon records ordinal intake <slug> --claim`, per `${CLAUDE_SKILL_DIR}/../../standards/intake.md`. Where the installed binary carries no such subcommand, fall back to listing both `.canon/intake/` and `.canon/groundwork/` and taking the highest ordinal present across the two, incremented. An absent folder opens, and a present one resumes by appending items and revising verdicts the tree has moved under.
+With no match, derive a kebab-case slug named for the subject rather than the activity. Prefer `toolkit-overview` over `august-triage`. Claim the ordinal and create the folder in one act with `canon records ordinal intake <slug> --claim`, per `${CLAUDE_SKILL_DIR}/references/intake.md`. Where the installed binary carries no such subcommand, fall back to listing both `.canon/intake/` and `.canon/groundwork/` and taking the highest ordinal present across the two, incremented. An absent folder opens, and a present one resumes by appending items and revising verdicts the tree has moved under.
 
 ## Step 2: orient
 
@@ -52,7 +52,6 @@ Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: behavior rules, conventions, commands
 - `canon/REQUIREMENTS.md`: scope and non-goals
-- `canon/ARCHITECTURE.md`: decisions already made
 - `.canon/tasks/index.md`: what is already tracked. Open a task file whose entry looks related to an item.
 
 Then read only what a live item needs. Do not read entire directories speculatively. Where a folder carries an `index.md`, read it first and load only the files it points at.

package/{standards → claude/skills/plan-intake/references}/intake.md

@@ -1,8 +1,6 @@
 ---
 title: Intake reference
 description: Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
-paths:
-  - '.canon/intake/**'
 ---
 
 # Intake reference
@@ -11,6 +9,23 @@ Applies to an intake folder at `.canon/intake/<nn>-<slug>/`. One folder holds on
 
 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 neither protects against a compaction dropping a session's reasoning before anyone has pushed. No check reaches its contents, so the shape below survives only by being read.
 
+<!-- canon-length-exempt: the folder shape and the item template share one reader, and a split into a second reference is queued as its own change -->
+
+## Contents
+
+- [Scope](#scope)
+- [Folder name](#folder-name)
+- [What a working intake looks like](#what-a-working-intake-looks-like)
+- [Files](#files)
+- [Frontmatter and dating](#frontmatter-and-dating)
+- [00-overview.md](#00-overviewmd) <!-- canon-allow-reference: a heading anchor, not a pull request number -->
+- [Item format](#item-format)
+- [The answer contract](#the-answer-contract)
+- [Retrieval](#retrieval)
+- [Conventions](#conventions)
+- [Anti-patterns](#anti-patterns)
+- [Template](#template)
+
 ## Scope
 
 Governs an intake folder under `.canon/intake/<nn>-<slug>/`: folder layout, ordinal naming, the reserved index number, frontmatter and dating, the item format, the answer contract, and retrieval.

package/claude/skills/plan-intake-answer/REQUIREMENT.md

@@ -43,6 +43,6 @@ The batching fails a fifth way. A folder holding thirty unread items put as thir
 
 - Filing a dump and writing the items, which is `plan-intake` and owns every other write into the folder
 - Promoting an answered item onto the board, which is `task-board` and runs after the answers land
-- The item format, the answer contract, and retrieval, which the toolkit's `standards/intake.md` owns and this skill cites
+- The item format, the answer contract, and retrieval, which the `plan-intake` skill's `references/intake.md` owns and this skill cites
 - The comparable answer slots in groundwork and feature plans, which carry their own contracts and are a separate measurement
 - Deciding when to fire. The skill is user-invoked through `disable-model-invocation`, so answering is the operator's call rather than a description match.

package/claude/skills/plan-intake-answer/SKILL.md

@@ -12,7 +12,7 @@ Put an intake folder's unread items as batched questions, then land each selecti
 
 A folder is answered by opening each cluster file and typing under the item, which on a dump spanning six clusters means navigating to each in turn. This walks the same items in chat and writes the answers back, so the file rather than the conversation stays the record.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/intake.md` before writing anything. It holds the item format and the answer contract this skill is bound by.
+Read `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` before writing anything. It holds the item format and the answer contract this skill is bound by.
 
 ## Guards
 

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

@@ -42,7 +42,7 @@ Do not push a red follow-up.
 
 ## Step 4: refresh stale docs
 
-The fixes may have changed or added behavior that `.claude/` context entries, docs, or wireframes describe. Refresh them with the `context-fold` skill, which maps the changed files to the entries that reference them and rewrites the stale sections. Do not reimplement that mapping here. When a fix adds a new capability with no existing entry, `context-fold` flags it rather than creating one.
+The fixes may have changed or added behavior that `.claude/` context entries or docs describe. Refresh them with the `context-fold` skill, which maps the changed files to the entries that reference them and rewrites the stale sections. Do not reimplement that mapping here. When a fix adds a new capability with no existing entry, `context-fold` flags it rather than creating one.
 
 ## Step 5: rebase a stale branch
 
@@ -112,7 +112,7 @@ fixes.
 
 The reply is a rendered-for-human GitHub surface, so load the `write-human`
 skill for voice and word choice, follow
-`${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation, and keep each
+`${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation, and keep each
 mapping to a line or two.
 
 Open the body with the `## Review response` heading so it anchors as a section

package/claude/skills/review-address/references/post-review-findings.md

@@ -7,7 +7,7 @@ description: How review-address posts something worth reporting after Step 7 clo
 
 Outside the numbered flow of `review-address`. The session reads this file when it has something worth reaching the reviewing session after Step 7 already closed the review.
 
-Not everything worth reaching the reviewing session surfaces inside the numbered flow in `SKILL.md`. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice and word choice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting with `canon labels scan --body-file .canon/tmp/pr/reply/reply-<number>.md`.
+Not everything worth reaching the reviewing session surfaces inside the numbered flow in `SKILL.md`. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice and word choice, follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting with `canon labels scan --body-file .canon/tmp/pr/reply/reply-<number>.md`.
 
 Open with `## Post-review findings` rather than `## Review response`, since nothing on the thread is being answered. `review-pr` states the full heading set this belongs to and routes it the same as a response: `role-orchestrator`'s poll picks it up and sends the reviewing session back for a pass. Close the body with `🤖 Addressed by Claude Code` on its own line, matching the reply's footer.
 

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

@@ -37,14 +37,14 @@ The axes also said nothing about a change that passes by lowering the bar it has
 
 ## Must not
 
-- State a severity or a posting rule. `review-pr` and `review-branch` each own a ladder, and the two define `should-fix` differently.
+- State a severity or a posting rule. `review-pr` owns the ladder.
 - Restate the high-signal filter either procedure carries
-- Name a repository-specific capture layout, width list, or folder. The evidence marker and `canon/wireframes/` are target contracts, and everything else is the project's.
+- Name a repository-specific capture layout, width list, or folder. The evidence marker is a target contract, and everything else is the project's.
 - Carry a per-surface reference beyond security and rendered output before a measured miss asks for one
 
 ## Out of scope
 
-- Running a review, reading the diff, posting findings, and grading them: `review-branch` and `review-pr`
+- Running a review, reading the diff, posting findings, and grading them: `review-pr`
 - The high-signal filter and the severity ladder, which stay in each procedure body
 - Which layer a test belongs at: `test-craft`
 - Capturing screenshots or writing the visual checklist: `canon pr evidence` and `ui-checklist`

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

@@ -1,6 +1,6 @@
 ---
 name: review-craft
-description: Carries what a code review looks for and how much evidence a finding needs, from design and scope through breakage outside the diff, a test or check the change weakens to pass, performance, developer experience, executable prose, stale docs, security classes, and rendered output checked against the screenshots a pull request carries. Use when reviewing a change, when a review procedure loads it for its axes, or when asked "what should a review look for", "what does a good review check", "how sure do I need to be before flagging this", or "did the review look at the screenshots". Do NOT use to run a review, post it, or grade its findings, which is `review-branch` for local work and `review-pr` for a pull request, and do NOT use for a deliberate full security audit, which is the built-in `security-review`.
+description: Carries what a code review looks for and how much evidence a finding needs, from design and scope through breakage outside the diff, a test or check the change weakens to pass, performance, developer experience, executable prose, stale docs, security classes, and rendered output checked against the screenshots a pull request carries. Use when reviewing a change, when a review procedure loads it for its axes, or when asked "what should a review look for", "what does a good review check", "how sure do I need to be before flagging this", or "did the review look at the screenshots". Do NOT use to run a review, post it, or grade its findings, which is `review-pr`, and do NOT use for a deliberate full security audit, which is the built-in `security-review`.
 metadata:
   family: build
 ---
@@ -102,7 +102,7 @@ Three scope checks follow the walk:
 
 ## What this delegates
 
-- Which files a pass reads, the high-signal filter, the severity ladder, and where findings go: `review-branch` for local work and `review-pr` for a pull request
+- Which files a pass reads, the high-signal filter, the severity ladder, and where findings go: `review-pr`
 - Which layer a test belongs at and what makes it good: `test-craft`
 - Writing what a reviewer should look at on a rendered change: `ui-checklist`
 - A deliberate full security audit of a codebase: the built-in `security-review`

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

@@ -6,7 +6,7 @@ Stills are this pass's evidence. Driving the running app through the checklist b
 
 ## When it applies
 
-The diff touches a file that paints: markup, a stylesheet, a component or template, a design token file, a rendered document source, or a path a `canon/wireframes/` surface file names. Or the pull request carries an evidence comment, whatever the diff touches.
+The diff touches a file that paints: markup, a stylesheet, a component or template, a design token file, or a rendered document source. Or the pull request carries an evidence comment, whatever the diff touches.
 
 ## First, check that a screenshot exists
 
@@ -59,11 +59,11 @@ A second theme earns a read only when the diff touches a color token. Name the s
 
 ## Comparing
 
-Read `canon/wireframes/index.md` and open only the surface files the evidence states map to. Check each opened image for the layout, the order of regions, and the behavior at that width the surface file states. Check `canon/DESIGN.md` for the tokens the image makes visible: color, type scale, spacing, and component rules.
+Check each opened image against the layout its checklist box claims, and check `canon/DESIGN.md` for the tokens the image makes visible: color, type scale, spacing, and component rules.
 
-Read the width and theme from whatever the image path carries, and fix no width list, since which widths matter belongs to the project. Skip a comparison silently when the project has no wireframe or design file.
+Read the width and theme from whatever the image path carries, and fix no width list, since which widths matter belongs to the project. Skip the design file comparison silently when the project has none.
 
-A finding names the wireframe or design-file line the image breaks, never a taste.
+A finding names the checklist box or design-file line the image breaks, never a taste.
 
 ## The checklist
 

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

@@ -49,5 +49,5 @@ Scoping a later pass off GitHub's review stamp skipped real work. On 2026-09-07
 ## Out of scope
 
 - Fixing what it finds, which `review-address` owns. The split is by side of the channel: this one posts findings from an independent session and that one consumes them.
-- Reviewing local uncommitted work, which `review-branch` owns. That one writes to disk for the session that wrote the code, and this one posts to a pull request it did not write.
+- Reviewing local uncommitted work. This skill posts to a pull request it did not write.
 - Merging, which stays the human's decision

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

@@ -1,16 +1,15 @@
 ---
 name: review-pr
-description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass against the whole change and every later pass against only the commits added since, under `## Review` while any finding is open and `## Review closed` once a pass carries none. Reads project docs and the task board for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes. That is `review-branch`.
+description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass against the whole change and every later pass against only the commits added since, under `## Review` while any finding is open and `## Review closed` once a pass carries none. Reads project docs and the task board for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes.
 metadata:
   family: after-pr
 ---
 
 # Review PR
 
-This is the orchestrator's independent review, distinct from `review-branch`.
-`review-branch` reviews local changes for the session that wrote them and writes
-to disk. This one reviews an open PR the session did not write and posts the
-findings to the PR, so the vantage is independent and the output is durable.
+This is the orchestrator's independent review. It reviews an open PR the session
+did not write and posts the findings to the PR, so the vantage is independent
+and the output is durable.
 
 It posts at least twice over a pull request's life. A first pass opens the
 review against the whole change, and every later pass reads only the commits
@@ -32,7 +31,7 @@ reader scanning the thread finds the current verdict where the last one sat.
 
 ## Guards
 
-- If no open PR resolves for the target branch via `canon pr head --json`, stop: `❌ No open PR to review. Open one first, or use /review-branch for local changes.`
+- If no open PR resolves for the target branch via `canon pr head --json`, stop: `❌ No open PR to review. Open one first.`
 - Review and post. Do not merge. Merging is the human's gate.
 
 ## Step 1: resolve the PR and read context
@@ -59,7 +58,6 @@ Read these in parallel from the project root, skipping any that do not exist:
 
 - `CLAUDE.md`: project type, conventions, and commands
 - `canon/REQUIREMENTS.md`: feature scope and non-goals
-- `canon/ARCHITECTURE.md`: technical design decisions
 - `.canon/tasks/priority.md`: where this feature sits on the board and what each neighboring row waits on. Resolve this one at the main worktree root the way `session-worktree` does, since the board is gitignored and a linked worktree holds no copy of it
 - `.canon/plans/feature-<slug>.md` for the branch, when present: the intent the PR should satisfy, and its `**Review focus:**` section as the inputs this pass must confirm the diff handles
 

package/claude/skills/review-pr/references/post.md

@@ -29,11 +29,11 @@ A finding bound to a line links to it, so a reader skips the hunt:
 
 A finding that spans lines anchors to the span as `#L12-L14`, with no spaces and no en dash, and a single-line finding anchors as `#L12`. Take the line number from the file read at `<headRefOid>`, `git show <headRefOid>:<path>`, never from another checkout. The URL carries the full 40-character `<headRefOid>`, never `<short-sha>`, `HEAD`, or the branch name, so the link survives a push. A later pass restating an open finding links it again at its own `<headRefOid>` rather than copying the old bullet.
 
-Four findings take the plain bullet with no link: a `**PR body**` entry, a finding on a file the head deleted, a finding on a line the diff removed from a file that survives, since the head holds no number for it, and a finding about a whole file with no one line. A path holding a character a URL needs encoded, such as a space or `#`, is percent-encoded in the link or keeps the plain bullet. Keep the file block header a bare backticked path, so the section-marker reading in `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` does not change.
+Four findings take the plain bullet with no link: a `**PR body**` entry, a finding on a file the head deleted, a finding on a line the diff removed from a file that survives, since the head holds no number for it, and a finding about a whole file with no one line. A path holding a character a URL needs encoded, such as a space or `#`, is percent-encoded in the link or keeps the plain bullet. Keep the file block header a bare backticked path, so the section-marker reading in `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` does not change.
 
 ## The body shapes
 
-The comment is a rendered-for-human GitHub surface, so load the `write-human` skill for voice and word choice and follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation: cut editorializing, and keep every sentence load-bearing. Match this shape on a first pass:
+The comment is a rendered-for-human GitHub surface, so load the `write-human` skill for voice and word choice and follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation: cut editorializing, and keep every sentence load-bearing. Match this shape on a first pass:
 
 ```markdown
 ## Review

package/claude/skills/review-ui/REQUIREMENT.md

@@ -53,7 +53,6 @@ A verdict also goes stale without saying so. A push after the pass changes what
 ## Out of scope
 
 - Reviewing the code and the stills, which `review-pr` owns. The two run as separate sessions so each finishes on its own clock and neither hears the other.
-- Inspecting a running app across many findings with the operator present, which `ux-walkthrough` owns
 - Writing the checklist and its drivable format, which `ui-checklist` owns
 - Dispatching the pass, polling its verdict, and lifting the draft mark, which `role-orchestrator` owns
 - A subagent inside the code reviewer, dropped because its cost stays invisible until it returns

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

@@ -1,6 +1,6 @@
 ---
 name: review-ui
-description: Drives an open pull request's visual checklist in the running app, one box at a time through a pinned agent browser, and posts one verdict per box as its own review comment under `## UI review` while the branch owes a fix, being a failed box, a sweep finding, or a box the page kept from being driven, and `## UI review closed` once it owes none. Never reads the diff, never builds the head, and never judges a box marked as taste. Use when asked to "drive the checklist", "run the UI review", "check the running app against the checklist", "review the PR in the browser", or launched as the UI reviewer beside a code review. Do NOT use to review the code or the screenshots, which is `review-pr`, to inspect a running app with the operator present, which is `ux-walkthrough`, or to write the checklist, which is `ui-checklist`.
+description: Drives an open pull request's visual checklist in the running app, one box at a time through a pinned agent browser, and posts one verdict per box as its own review comment under `## UI review` while the branch owes a fix, being a failed box, a sweep finding, or a box the page kept from being driven, and `## UI review closed` once it owes none. Never reads the diff, never builds the head, and never judges a box marked as taste. Use when asked to "drive the checklist", "run the UI review", "check the running app against the checklist", "review the PR in the browser", or launched as the UI reviewer beside a code review. Do NOT use to review the code or the screenshots, which is `review-pr`, or to write the checklist, which is `ui-checklist`.
 metadata:
   family: after-pr
 ---

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

@@ -18,7 +18,7 @@ A needs-eyes box leaves the review closed, and so does a box not driven for a ca
 
 ## The body
 
-Write it to `.canon/tmp/pr/review-ui/body-<number>-<short-sha>.md` at the main worktree root, sent as a heredoc the way `session-worktree` states for a main-root write. Load the `write-human` skill for the prose and follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation.
+Write it to `.canon/tmp/pr/review-ui/body-<number>-<short-sha>.md` at the main worktree root, sent as a heredoc the way `session-worktree` states for a main-root write. Load the `write-human` skill for the prose and follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation.
 
 ```markdown
 <## UI review, or ## UI review closed, by the rule above>