@erclx/canon 5.29.0 → 5.31.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
-  "version": "5.29.0",
+  "version": "5.31.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/build-in-slices/REQUIREMENT.md

@@ -23,7 +23,7 @@ The ship chain assumed the work arrives uncommitted. `git-ship` ran `git-stage`
 
 ## Must not
 
-- Restate the scope floors `565-behavior` already carries for every session
+- Restate the scope floors of minimal edits and no unrequested features, which a scope call the skill makes already holds
 - Carry simplicity or abstraction rules, which `code-craft` owns
 - Name a feature flag pattern, since the slices of one branch merge as one pull request rather than reaching trunk one at a time
 - Name a framework, a test runner, or a line-count threshold, none of which holds across stacks

package/claude/skills/build-in-slices/references/adopted.md

@@ -30,7 +30,7 @@ External sources were read and filtered rather than imported. This file is the r
 
 **Rule 0, simplicity first, and the abstraction red flags.** Declined because `code-craft` owns when an abstraction earns its place and when to write the plainest code that passes. Restating it here would put two owners on one rule.
 
-**The rest of its scope section.** Declined because `565-behavior` already carries the scope floors every session loads, being minimal edits, no unrequested features, and edits limited to what the user named. Only the noticed list was new.
+**The rest of its scope section.** Declined as a scope call this skill makes: its slices already keep to the plan, and minimal edits, no unrequested features, and edits limited to what the user named restate that in different words. Only the noticed list was new.
 
 **Rule 3, feature flags for incomplete features.** Declined because the slices of one branch merge together as one pull request rather than reaching trunk one at a time, so nothing incomplete is exposed between them.
 

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

@@ -43,6 +43,8 @@ Classify against the toolkit's own surfaces. Score in this order and stop at the
 
 State the class and the one-line reason per issue before routing. Do not batch unrelated fixes into one branch.
 
+When the fix encodes into a skill, standard, or seed, keep the principle and strip the reporting project's specifics: its filenames, frameworks, deploy targets, and label values. The issue describes one project, and the fix serves every project that installs the toolkit.
+
 ## Step 3: route
 
 - Direct fix: rename the branch to a conventional name (invoke `git-branch`), make the edit, then open the PR with `git-pr`.

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

@@ -90,7 +90,7 @@ Read `ok` and `reason` out of that record rather than the exit. An operator's sh
 - Update only the sections affected by session decisions.
 - Do not rewrite sections unrelated to what changed.
 - Rewrite a restated or superseded statement in place rather than appending the replacement beside it. State the fact that stands and keep the earlier reasoning only where it is the alternative that lost, per `${CLAUDE_SKILL_DIR}/../../standards/context.md` and `${CLAUDE_SKILL_DIR}/../../standards/architecture.md`.
-- Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` and the `write-human` skill for all edits.
+- Follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` and the `write-human` skill for all edits.
 - Write a session decision into the `canon/context/` entry for the domain it constrains, under that entry's `## Decisions`, by default.
 - Touch `canon/ARCHITECTURE.md` only when a plan a matched task's `Plan:` line names states a decision filling a slot `${CLAUDE_SKILL_DIR}/../../standards/architecture.md` names. A slot decision no plan carries goes to the domain entry.
 - Read the entry cap the record states before adding a decision to it. At the cap, merge two decisions or retire one to the domain entry it constrains, and name which in the report. Never compress a decision's prose to fit, and never pack two decisions under one heading.

package/claude/skills/create-skill/SKILL.md

@@ -12,7 +12,7 @@ Read these files in parallel:
 - `${CLAUDE_SKILL_DIR}/../../standards/skill.md`: skill structure, skill types, frontmatter fields, invocation rules
 - `${CLAUDE_SKILL_DIR}/../../standards/skill-requirement.md`: what `REQUIREMENT.md` must answer, its sections, and its template
 - `${CLAUDE_SKILL_DIR}/../../standards/skill-paths.md`: which root a path in the body resolves against, and how the body cites a standard
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for skill body text
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for skill body text
 - The `write-human` skill: voice, rhythm, and sentence construction for skill body text
 
 ## Guards

package/claude/skills/create-standard/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 Creates one standard file. Read these files in parallel:
 
-- `${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/standard.md`: the meta-standard for shape, frontmatter, and structure
 

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

@@ -34,7 +34,7 @@ Read these on both paths, skipping any that do not exist:
 
 - `CLAUDE.md`: voice and personality
 - `canon/REQUIREMENTS.md`: the `## Personality` paragraph, worldview, non-goals
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: word, punctuation, and formatting constraints
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: word, punctuation, and formatting constraints
 - The `write-human` skill: tone and sentence construction constraints
 
 On the source path, also read the UI surfaces matched in Step 1 plus `canon docs output-shape` and `canon docs index`, for output shape or framing rules already documented in the toolkit's own reference. Skip either that fails to resolve, since a project keeping its framing rules elsewhere is read there instead.
@@ -57,7 +57,7 @@ Use the returned content as the target shape. Keep every section heading and eve
 
 ## Step 4: fill the template
 
-Walk each section once. Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation throughout: no em dashes, no semicolons. Use commas or separate sentences instead. Load the `write-human` skill for word choice, which keeps marketing words out.
+Walk each section once. Follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation throughout: no em dashes, no semicolons. Use commas or separate sentences instead. Load the `write-human` skill for word choice, which keeps marketing words out.
 
 Mark any cell not traced to a source value by appending ` ? verify` inside the cell value, never as a trailing column. The cell stays inside the table shape: `| #ffffff ? verify |`. A trailing `| ? verify` after the row breaks the parser. A prose section takes its uncertainty inline instead, for example `Proposed 150ms ease-out, not yet confirmed.`, because a trailing tag on a sentence renders raw in the preview.
 

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

@@ -46,7 +46,7 @@ Two worked examples:
 
 The read fixes the kind, which decides which rules apply, and names the layer, which decides what may vary. A round that cannot state its read has not decided what it is doing.
 
-Put the read to the operator through the structured question surface where it genuinely forks, per `565-behavior`. Where context settles it, declare and proceed rather than asking.
+Put the read to the operator through the structured question surface where it genuinely forks. Where context settles it, declare and proceed rather than asking.
 
 ## The layers, and the order they settle
 

package/claude/skills/docs-sync/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 Read these files in parallel:
 
-- `${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/readme.md`: README structure, required sections, and content rules
 - `${CLAUDE_SKILL_DIR}/../../standards/docs.md`: the reader a page under `docs/` serves, its frontmatter, structure, and what it links out rather than carrying

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

@@ -30,7 +30,7 @@ Each kind has one standard and one reference. Load the reference for the resolve
 Read these in parallel, from the project root where a path is relative:
 
 - The kind's standard from the table above: the reader the document serves, its frontmatter, its structure, and what it links out to rather than restates
-- `${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
 - The kind's reference from the table above
 

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

@@ -19,7 +19,7 @@ Decide whether a requested figure reduces to a graph Mermaid can draw, is one of
 Read these in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/figures.md`: when a figure earns its place, the render-first policy, wrapping and captioning, and the color and accessibility rules
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: formatting for the caption prose
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: formatting for the caption prose
 - The `write-human` skill: voice and rhythm for the caption prose
 
 ## Step 2: does it earn its place

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

@@ -10,7 +10,7 @@ description: The hand-drawn render config, the SVG and PNG pair, the hex rewrite
 ## Draft the fence
 
 - 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.
+- 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
 

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.
+- `standards/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/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-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-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.

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/memory-capture/SKILL.md

@@ -29,7 +29,7 @@ Read in parallel, skipping any that do not exist:
 - `CLAUDE.md`: the project's write location and any rule it states over the folder
 - `.canon/memory/index.md`: existing index, to avoid duplicates
 - `canon/context/index.md`: the domain catalog Step 3 routes against, read under `.claude/` instead in a project the surface move has not reached
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting applied to memory file bodies
+- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting applied to memory file bodies
 - The `write-human` skill: voice, rhythm, and sentence construction applied to memory file bodies
 
 ## Step 2: classify candidates

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

@@ -73,7 +73,7 @@ An entry's `unresolved` list in the stale record names paths it cites that the t
 
 For each in-scope entry (see Scope), pick one action:
 
-- **Promote to an always-loaded rule**: the rule is cross-domain behavior or a design principle applied across the whole project, passing `592-claude-md.md`'s test (applies every session regardless of what is being edited). Do not author a toolkit rule file inline.
+- **Promote to an always-loaded rule**: the rule is cross-domain behavior or a design principle applied across the whole project, passing the tier test in `canon/context/context-model/overview.md` (applies every session regardless of what is being edited). Do not author a toolkit rule file inline.
   - In the toolkit repo, hand off to `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own `internal/rules/` (this repo only, never ships) and the audience group under `governance/rules/` the rule serves (ships to every target that group reaches).
   - In a target project, append the rule to an existing file under `.claude/rules/project/` with `Edit`, since a project rule is project-owned and sync never overwrites it, or hand off to the `create-rule` skill when no existing file fits.
 - **Promote to a skill body**: the rule fires only when editing a specific path-scoped domain. Name the target skill.

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

@@ -40,6 +40,13 @@ 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.
@@ -47,10 +54,13 @@ The section list, what each section holds, and the suggested-and-answer contract
 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 +69,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.

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

@@ -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-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/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>

package/claude/skills/role-orchestrator/references/orchestrator-dispatch.md

@@ -42,6 +42,7 @@ Run `canon tasks plan-answers <plan> --json` and read `launchable` off the recor
 - `reason: archived`: the row's plan sits in `.canon/plans/archive/` and describes work that already shipped. Repoint the row at a live plan rather than dispatching, since `auto-ship` Step 1 refuses the same file and the worker would meet that refusal after the launch spent.
 - The command refuses for any other reason, or the record carries no `launchable` key: treat the row as unverified rather than clear, name what could not be read, and fall back to the human. A gate that reads nothing and proceeds is the gate not running.
 - The same read also refuses a plan still staging its batches in one file with `**Batch N**` sub-headings. That reports as an entry in `open` labeled `Batch staging`, so a staged plan reads as `launchable: false` the same way an unanswered operator call does, and the row waits on a split rather than on the operator.
+- An entry labeled `Stacked sibling` means the plan stacks on a live sibling it mostly shares files with, so the row waits on a fold into that sibling or on a `Judged apart from` constraint line, and not on the operator.
 
 Branch on `launchable` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero and so read a held row as a clear one.
 

package/claude/skills/target-setup/references/indexes.md

@@ -75,7 +75,7 @@ candidate list and stop rather than choosing on the operator's behalf.
 For each chosen folder, read every `*.md` sibling and draft frontmatter:
 
 - `title`: derived from the first H1. If absent, derive from the filename in sentence case.
-- `description`: one line summarizing the file's purpose, drawn from the first paragraph after the H1. Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` § Frontmatter descriptions for length and style.
+- `description`: one line summarizing the file's purpose, drawn from the first paragraph after the H1. Follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` § Frontmatter descriptions for length and style.
 
 Surface every drafted entry to the user grouped by file:
 

package/claude/skills/test-first/REQUIREMENT.md

@@ -33,7 +33,7 @@ Without this skill, a session implementing a planned change writes the test afte
 
 - Choosing the layer a test belongs at and judging whether it is a good test: `canon:test-craft`, loaded at step 1 rather than restated here
 - Finding the cause of an unexplained failure: `canon:systematic-debugging`
-- Confirming visual output after a change lands: `567-planning.md` states the order and `ui-checklist` writes the list to confirm against
+- Confirming visual output after a change lands: `ui-checklist` writes the list to confirm against
 - Shaping the function, class, or module the implementation writes: `canon:code-craft`, loaded at step 4 rather than restated here
 - Committing the behavior as a slice and ordering the slices of a larger build: `canon:build-in-slices`
 - The mechanical audit of whether an implementation reached history ahead of its test: `canon gov test-order`, invoked from `auto-ship`

package/claude/skills/write-human/SKILL.md

@@ -11,7 +11,7 @@ Write prose that reads as though a person wrote it. A ban list subtracts words a
 
 Load this before drafting a passage rather than after. A revision pass recovers the words and never recovers the structure the draft already settled.
 
-The banned characters sit in `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`. They stay in force here. This skill adds to them and never restates them, since `canon markdown audit` reads them from the package and a second copy would drift. The word guidance under `## Voice` is the one copy of that list, and no command reads it.
+The banned characters sit in `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`. They stay in force here. This skill adds to them and never restates them, since `canon markdown audit` reads them from the package and a second copy would drift. The word guidance under `## Voice` is the one copy of that list, and no command reads it.
 
 ## What yields and what does not
 

package/docs/agents/commands.md

@@ -55,6 +55,7 @@ One row per top-level command, in the order `canon --help` prints them. A domain
 | `canon markdown <verb>`     | Fail markdown on a banned character or a dead link, and report its structure               |
 | `canon repo <verb>`         | Propose and apply the remote's description, homepage, and topics                           |
 | `canon census [path]`       | Report tracked file count, extensions, and a line total skipping binaries                  |
+| `canon upstream <verb>`     | Read Claude Code releases from a cursor, and list the toolkit's own mechanisms             |
 
 `canon serve` drives no browser, which is what separates it from the four that do. All four ship now that `capture` does, so the line between them is the engine rather than the package. A generated page loses its script to an editor preview and to a `file://` open, so the link is the delivery rather than a convenience, and every generated surface here reaches a reader through one. A teach lesson's stylesheet is embedded rather than linked, so only its script still needs a server. It binds `127.0.0.1` and never a wildcard, because what it is pointed at is routinely a gitignored record tree. It sends `cache-control: no-store`, since a preview exists to be edited and reloaded and a cached stylesheet reads as a fix that did not work.
 
@@ -150,7 +151,7 @@ the JSON record rather than on the exit, since an offline machine has to read as
 unmeasured rather than as a failing check.
 
 `canon upgrade --json` carries one further state, `pending`, that the skew report
-does not. It means the checkout at the working directory holds a release npm does
-not serve yet, so there is nothing to install. The record names that version in
-`checkout` beside `latest`, exits 0, and its `message` starts `CLI stays at`. A
-directory outside any canon checkout never reads `pending`.
+does not: the working directory's checkout holds a release npm does not serve
+yet, so there is nothing to install. The record names it in `checkout` beside
+`latest`, exits 0, and its `message` starts `CLI stays at`. Outside a canon
+checkout it never reads `pending`.

package/docs/agents/context-audit-checks.md

@@ -45,7 +45,7 @@ Only the third is mechanical, and it is the provenance check already reported be
 
 It reports and never gates, which the standard settles rather than the usual judgment-against-fact line: the 150 checkpoint is diagnostic, so an entry that answers all three and is still long is a correct outcome. The one hard cap is the 300-line whole-document ceiling, which `canon markdown audit` and the Document ceiling gate stage read rather than this check. The JSON record carries the joined findings as `length`, each with a `causes` array in the standard's order, and the jurisdiction the join reads as `entries[].governed`. That flag is what parts a provenance list measured and empty from one never scanned, which the count alone cannot say. The join is published rather than left to a consumer, since deriving it means restating which question the provenance count answers.
 
-Depth and bullet weight are quoted from `standards/markdown.md`, which states both over every markdown file rather than over a context entry, so `canon markdown audit` measures them and this command no longer does. They share `renderedHeight` with the length measure, since the two checkpoints sit in one section of that standard and a reader compares them. What the split costs is that a session wanting both numbers for one entry runs two commands, and what it buys is that either number can be had for a file in a folder this audit refuses to resolve.
+Depth and bullet weight are quoted from `claude/skills/markdown-craft/references/markdown.md`, which states both over every markdown file rather than over a context entry, so `canon markdown audit` measures them and this command no longer does. They share `renderedHeight` with the length measure, since the two checkpoints sit in one section of that standard and a reader compares them. What the split costs is that a session wanting both numbers for one entry runs two commands, and what it buys is that either number can be had for a file in a folder this audit refuses to resolve.
 
 ## Tables
 

package/docs/agents/counts.md

@@ -36,7 +36,7 @@ The set is closed rather than derived, so widening it is a deliberate change to
 
 A sentence has to carry an assertion verb (`loads`, `ships`, `carries`, `holds`, `counts`, `totals`, `documents`, `declares`, `installs`, `lists`, `contains`, `comprises`, `authors`), the quantifier `all`, or an article (`the`, `a`, `an`) immediately ahead of the number, which is immediately ahead of the catalog noun, with one optional qualifying word between the number and the noun (`sixty-one shipped skills`). The number reads either as digits or as a spelled-out cardinal through ninety-nine, since this corpus states a catalog size in words as often as in digits.
 
-Nothing stands between the trigger and the number, which is the rule an author writing a new count has to know. It separates `the toolkit authors 74 rules` and `took all 74 rules`, both read, from `a domain of 55 skills` and `denominator of sixty-one shipped skills`, neither of them read. A figure meant as a past state takes a date in the same sentence instead, which reads the sentence past whatever its shape.
+Nothing stands between the trigger and the number, which is the rule an author writing a new count has to know. It separates `the toolkit authors 65 rules` and `took all 65 rules`, both read, from `a domain of 55 skills` and `denominator of sixty-one shipped skills`, neither of them read. A figure meant as a past state takes a date in the same sentence instead, which reads the sentence past whatever its shape.
 
 ## How the trigger set grew
 
@@ -44,7 +44,7 @@ The verb gate is not the first design tried. A bare number next to a catalog nou
 
 The article half was added after a first review of the shipped design found a live miss: the development domain's gating-stages entry stated a stale audit total while the tree held 20, and the verb gate never reached it, since that sentence puts its verb after the noun rather than ahead of the number. Widening the trigger set to admit an article ahead of the number closed that gap.
 
-The quantifier `all` and the verb `authors` joined on the same evidence, two more live misses failing only the trigger test. Allowing words to stand between the trigger and the number was the other candidate, measured and declined: at widths of one, two, and three it reached 77, 104, and 132 sentences against a baseline of 65, missed `took all 74 rules` at every width, and reached `the toolkit authors 74 rules` only at a width admitting the indirect-noun shape below. The two words reach both at 75 sentences and no false positive.
+The quantifier `all` and the verb `authors` joined on the same evidence, two more live misses failing only the trigger test. Allowing words to stand between the trigger and the number was the other candidate, measured and declined: at widths of one, two, and three it reached 77, 104, and 132 sentences against a baseline of 65, missed `took all 65 rules` at every width, and reached `the toolkit authors 65 rules` only at a width admitting the indirect-noun shape below. The two words reach both at 75 sentences and no false positive.
 
 ## The plausibility filter
 
@@ -58,7 +58,7 @@ The article gate is looser than the verb list and carries a real cost. Re-runnin
 
 A delta phrased as a transition (`from fourteen to fifteen`), a fraction (`thirteen of sixteen`), and a total reached through an indirect noun (`denominator of sixty-one shipped skills`) are all catalog-size claims this corpus carries, and none matches the trigger shape this reads. Each stays a known gap. The false-positive rate that gated closing them has a measurement behind it now, and what it showed is that the widening these three need is the one that costs a false positive rather than the one that does not.
 
-A second figure in a sentence whose first figure already matched is a fourth gap and a structural one, since one match is taken per catalog per sentence. `authors 74 rules under governance/rules/ and consumes 62 into .claude/rules/` is read for its 74 alone, which is correct here because the two figures name different populations, and a sentence stating one catalog twice would go unread the same way.
+A second figure in a sentence whose first figure already matched is a fourth gap and a structural one, since one match is taken per catalog per sentence. `authors 65 rules under governance/rules/ and consumes 44 into .claude/rules/` is read for its 65 alone, which is correct here because the two figures name different populations, and a sentence stating one catalog twice would go unread the same way.
 
 A calendar date (`2026-08-21`) or a backticked commit reference in the same sentence reads the whole sentence past, since that is how this corpus already marks a figure as a historical record rather than a live claim. `canon/ARCHITECTURE.md` and the context entries carry a figure this way deliberately, and every one of them stays correct forever.
 

package/docs/agents/index.md

@@ -67,4 +67,5 @@ CLI catalog and invocation rules for agents, split by command domain. Start with
 - [Teach authoring](teach-authoring.md): Resolving what the next lesson needs before it is written, rendering a lesson body's blocks to HTML, and rewriting the root listing, a contents page, and each lesson's chrome and quiz stepper from its marker regions
 - [Teach](teach.md): Listing learning workspaces with what their records schedule next, opening one with its required files, recording sources and glossary terms, viewing one with its chrome refreshed, where the lesson authoring verbs are described, the refusal reasons, and why every write here runs through a verb
 - [Test order](test-order.md): Reading where an implementation reached history ahead of its test, how a pair is decided, the three verdicts, the coverage the pairing cannot reach, and why the check reports rather than gates
+- [Upstream](upstream.md): The fetch, catalog, and advance verbs that read Claude Code releases against the toolkit, the cursor record, and each refusal reason
 - [Worktrees](worktrees.md): Reporting which worktrees are reclaimable, removing the ones that are, the hidden verb that clears a stranded bare flag, the record a hook reads back, why the reading keys on the pull request rather than on git ancestry, the refusals it names, and the two removal shapes

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

@@ -30,9 +30,9 @@ applies, and the target's git diff is the record afterwards. `canon sync
 The `standards` band is the largest such move. Each rule that only routed a
 path to a standard now ships under that standard's name at
 `.claude/rules/canon/standards/<standard>.md`, so a target holding
-`canon/658-plan.md` or `writing/801-markdown.md` syncs onto `standards/plan.md`
-and `standards/markdown.md`. Those rules carry no number, and their globs and
-bullets come from the standard's own frontmatter.
+`canon/658-plan.md` syncs onto `standards/plan.md`. The markdown rule is
+hand-written at `writing/markdown.md`, and a target holding
+`standards/markdown.md` keeps it there as `800-prose` retires.
 
 A project's own rules belong under `.claude/rules/project/`, where
 `canon standards rule` reserves `900-999` for them, and a rule placed under

package/docs/agents/markdown-audit.md

@@ -113,4 +113,4 @@ The verb reads the two attribute standards and nothing else. The five standards
 
 That standard's cross-reference rule is out of reach rather than merely unimplemented. It resolves by destination, bare where the destination auto-links a pull request or issue number and backticked where it does not, so this verb sees only the half where the backticked form is correct. A check here would report every compliant reference in the tree and reach none of the published text that goes wrong, which is why the rule holds on reading alone.
 
-The list-density rule at `standards/markdown.md` is out of scope on purpose, since it carries no number and what a density figure should measure is still open.
+The list-density rule at `claude/skills/markdown-craft/references/markdown.md` is out of scope on purpose, since it carries no number and what a density figure should measure is still open.

package/docs/agents/routing.md

@@ -5,7 +5,7 @@ description: Reading per CLAUDE.md section how many bullets name a path, what co
 
 # Routing report
 
-`canon claude routing` reports, per `CLAUDE.md` section, how many top-level bullets name a path and how many of those a path-scoped rule already covers. It answers the firing axis of the tier test in `.claude/rules/canon/claude/592-claude-md.md`, whether a fact applies every session or fires on one path, and which until this verb existed was a judgment nothing counted. The tier test names two further axes, conditional presence and updatability, that this verb does not check.
+`canon claude routing` reports, per `CLAUDE.md` section, how many top-level bullets name a path and how many of those a path-scoped rule already covers. It answers the firing axis of the tier test in `canon/context/context-model/overview.md`, whether a fact applies every session or fires on one path, and which until this verb existed was a judgment nothing counted. The tier test names two further axes, conditional presence and updatability, that this verb does not check.
 
 ```bash
 canon claude routing

package/docs/agents/tasks-plans.md

@@ -44,7 +44,7 @@ A relative path resolves against the project root first and against `.canon/task
 
 `canon tasks plan-citations` reads a task's `Plan:` line against those same two bases in the opposite order, and tests that the target lands under the live plans folder, which this verb does not. Both answer the same file for every spelling a board writes. Liveness is a separate refusal here: a plan resolving inside `.canon/plans/archive/` returns `archived` rather than a launchable reading, since it answers every question and describes work that already shipped.
 
-A plan still staging its batches with a `**Batch N**` sub-heading inside one file's `**Files to touch:**` reads `launchable: false` the same way, alongside the operator-call case. It reports as an entry in `open` labeled `Batch staging`, stating that the plan must split into one file per batch before it can dispatch, since the row waits on a split rather than on the operator.
+A plan still staging its batches with a `**Batch N**` sub-heading inside one file's `**Files to touch:**` reads `launchable: false` the same way, alongside the operator-call case. It reports as an entry in `open` labeled `Batch staging`, since the row waits on a split into one file per batch rather than on the operator. A plan stacked on a live sibling it mostly shares files with reads the same way under `Stacked sibling`, and waits on a fold or on a ``Judged apart from `feature-<parent>`: <reason>`` constraint.
 
 | Option          | Effect                                      |
 | --------------- | ------------------------------------------- |

package/docs/agents/test-order.md

@@ -5,7 +5,7 @@ description: Reading where an implementation reached history ahead of its test,
 
 # Test order
 
-`canon gov test-order` reports where an implementation reached a commit ahead of the test covering the same behavior. It answers the rule in `.claude/rules/canon/claude/567-planning.md` that asks for the test first, which until this verb existed was prose loaded on a glob match with nothing measuring it.
+`canon gov test-order` reports where an implementation reached a commit ahead of the test covering the same behavior. It measures the test-first order that the `test-first` skill and `auto-ship` hold, which until this verb existed was prose with nothing measuring it.
 
 ```bash
 canon gov test-order