@erclx/canon 5.18.0 → 5.20.0

package/standards/groundwork-spikes.md

@@ -0,0 +1,66 @@
+---
+title: Groundwork spikes reference
+description: What each spike in a track's 08-spikes.md records, the sample rule, and the three folders that hold what a spike produced
+---
+
+# Groundwork spikes reference
+
+Applies to `08-spikes.md` inside a groundwork track at `.canon/groundwork/<nn>-<slug>/`, and to the folders beside it that hold what a spike produced. It records evidence by experiment, beside the evidence by measurement `01-current-state.md` holds.
+
+## Scope
+
+Governs `08-spikes.md`, what each spike in it carries, how a spike is sized, and the `evidence/`, `scripts/`, and `clones/` folders in a track.
+
+Does not govern:
+
+- The track's folder layout, its other files, frontmatter, and numbering: `groundwork.md`
+- Running a spike, which belongs to the surface driving the track
+
+## What a working spike record looks like
+
+A spike record works when a later reader can re-run each spike and trust what it settled:
+
+- Which open question did each spike answer, and did it close it?
+- Can the method be re-run from the file, against the fixture it names?
+- What did it cost, and what does the result not prove?
+
+## Spikes
+
+The file is optional, since measuring what is already there settles most questions.
+
+Each spike carries four things:
+
+- The open question it answers, named by file and number. A spike attached to no question is a runaway.
+- The method, stated fully enough for a later reader to re-run it. Name the fixture and where it lived, since an arm pointed at a fixture inside the project measured the project, plus the exact command and the repetition count.
+- The result, and which question it closes. Record a spike that settles nothing too, so a later pass does not pay for it twice.
+- The measured cost, even for a single read, and the caveats bounding what the result proves. Cost is a report rather than a limit, and it makes the next spike estimable.
+
+Start a spike against a sample bounded on input size, duration, and spend, and scale up only once it shows the method works. Record the sample's bounds beside the figure for the full input.
+
+## What a spike produced
+
+A file a reader opens to verify how a result was produced or what it showed lives inside the track, and bulk input such as a large fixture stays outside it. Three unnumbered subfolders carry the first kind, since a reader reaches them from the citing claim rather than in read order:
+
+- `evidence/`: what a run produced and the record cites, being a recording, a render, or a frame pulled from one, beside the file citing it.
+- `scripts/`: the arm scripts and harnesses a spike ran, which a reader opens to check the method.
+- `clones/`: checkouts and copies of outside material a claim rests on, kept small enough to hold in the folder. A checkout too large to keep is cited by its address and commit instead.
+
+Open no other subfolder: `spikes/`, `web/`, and `research/` fold into these three, with a fetched page in `clones/` and a reference-site screenshot in `evidence/`.
+
+Reach for a test harness the project already carries before building one. An experiment no existing harness can express is a finding for the folder, not a new abstraction.
+
+Never count transcript matches to show a file was read. An instruction naming a path puts it in the transcript whether or not anything opened it, so the check is the tool call.
+
+## Template
+
+```markdown
+# Spikes
+
+## <nn>. <what the spike tests>
+
+- Question: <file and number of the open question>
+- Method: <fixture and where it lived, exact command, repetition count>
+- Result: <what it showed, and which question it closes>
+- Cost: <measured cost>, <sample bounds beside the full-input figure>
+- Caveats: <what the result does not prove>
+```

package/standards/groundwork.md

@@ -1,6 +1,10 @@
 ---
 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
@@ -15,6 +19,7 @@ Governs a groundwork track under `.canon/groundwork/<nn>-<slug>/`: folder layout
 
 Does not govern:
 
+- `08-spikes.md`, what each spike records, and the folders holding what a spike produced: `groundwork-spikes.md`
 - A dump of many findings filed by domain, each carrying its own verdict: `intake.md`
 - The feature plan a closed track feeds, and the contract its answer slots keep: `plan.md`
 - The task file a closing track writes, and the origin line pointing back at the folder: `tasks.md`
@@ -110,31 +115,6 @@ The dropped list is what stops a future session re-proposing something already r
 
 Written to survive a compaction that loses the conversation. It repeats facts held elsewhere in the folder rather than pointing at them. That duplication is correct here and wrong everywhere else.
 
-## 08-spikes.md
-
-Evidence by experiment, beside the evidence by measurement `01-current-state.md` holds. Optional, since measuring what is already there settles most questions.
-
-Each spike carries four things:
-
-- The open question it answers, named by file and number. A spike attached to no question is a runaway.
-- The method, stated fully enough for a later reader to re-run it. Name the fixture and where it lived, since an arm pointed at a fixture inside the project measured the project, plus the exact command and the repetition count.
-- The result, and which question it closes. Record a spike that settles nothing too, so a later pass does not pay for it twice.
-- The measured cost, even for a single read, and the caveats bounding what the result proves. Cost is a report rather than a limit, and it makes the next spike estimable.
-
-Start a spike against a sample bounded on input size, duration, and spend, and scale up only once it shows the method works. Record the sample's bounds beside the figure for the full input.
-
-A file a reader opens to verify how a result was produced or what it showed lives inside the track, and bulk input such as a large fixture stays outside it. Three unnumbered subfolders carry the first kind, since a reader reaches them from the citing claim rather than in read order:
-
-- `evidence/`: what a run produced and the record cites, being a recording, a render, or a frame pulled from one, beside the file citing it.
-- `scripts/`: the arm scripts and harnesses a spike ran, which a reader opens to check the method.
-- `clones/`: checkouts and copies of outside material a claim rests on, kept small enough to hold in the folder. A checkout too large to keep is cited by its address and commit instead.
-
-Open no other subfolder: `spikes/`, `web/`, and `research/` fold into these three, with a fetched page in `clones/` and a reference-site screenshot in `evidence/`.
-
-Reach for a test harness the project already carries before building one. An experiment no existing harness can express is a finding for the folder, not a new abstraction.
-
-Never count transcript matches to show a file was read. An instruction naming a path puts it in the transcript whether or not anything opened it, so the check is the tool call.
-
 ## Open questions
 
 Every open question carries a lean, wherever it appears. A bare numbered list hands the reader a quiz and defers the judgment the track exists to inform.

package/standards/index.md

@@ -17,12 +17,14 @@ Reference docs for consistent authoring across the toolkit and target projects.
 - [Docs reference](docs.md): Reader and jurisdiction, frontmatter, page structure, what a page links out to, the diagram permission, and when a category earns a subfolder
 - [Figure reference](figures.md): When a figure earns its place, the render-first policy for a graph-shaped subject, freehand SVG as the escape hatch, and its wrapping, color, and accessibility rules
 - [Glossary reference](glossary.md): Frontmatter, entry shape, ordering, and the rules deciding which terms a glossary carries
+- [Groundwork spikes reference](groundwork-spikes.md): What each spike in a track's 08-spikes.md records, the sample rule, and the three folders that hold what a spike produced
 - [Groundwork reference](groundwork.md): Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
 - [Intake reference](intake.md): Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
 - [Markdown reference](markdown.md): Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording
 - [Memory reference](memory.md): Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
 - [Mermaid reference](mermaid.md): Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram
-- [Plan reference](plan.md): Filename and slug, required sections, the suggested-and-answer contract, and the lifecycle from the live folder to the archive
+- [Plan lifecycle reference](plan-lifecycle.md): When a feature plan is written, where it lives, how it changes mid-flight, and its move to the archive
+- [Plan reference](plan.md): Filename and slug, the required sections, and the suggested-and-answer contract for a feature plan
 - [Pull request reference](pr.md): Pull request title and body conventions
 - [Publish reference](publish.md): Scan an author runs against finished text, the cross-reference form each destination takes, and the response to an unreadable source
 - [Readme reference](readme.md): Readme voice, structure, and content conventions
@@ -30,11 +32,13 @@ Reference docs for consistent authoring across the toolkit and target projects.
 - [Requirements reference](requirements.md): Shape and content rules for canon/REQUIREMENTS.md
 - [Governance rule reference](rule.md): Rule frontmatter, body shape, and voice for .claude/rules files
 - [Session map reference](session.md): Filename and location, the sections a handoff carries, the write and read procedures, and how a role extends it
+- [Skill path reference](skill-paths.md): Which root a file a skill body names resolves against, and how a body cites a standard
 - [Practice skill reference](skill-practice.md): Closing sections and source ledger for a skill carrying engineering practice
 - [Skill requirement reference](skill-requirement.md): Shape and content rules for the REQUIREMENT.md beside a skill
-- [Claude skill reference](skill.md): Claude skill structure and authoring rules
+- [Claude skill reference](skill.md): Skill structure and authoring rules for Claude Code
 - [Slug reference](slug.md): Transform from a git branch name to a slug, and the three responses to an empty result
 - [Standard reference](standard.md): Shape and content rules for authoring a standard
+- [Task decline reference](tasks-decline.md): Where a task decided against moves, the Declined line it carries, and what happens to its plan and board row
 - [Tasks reference](tasks.md): Folder layout, filename convention, file format, origin lines, and archiving for task files under .canon/tasks/
 - [Teach reference](teach.md): Workspace layout, ordinal naming, frontmatter, and the mission and learning-record formats for a learning workspace
 - [Versioning reference](versioning.md): Phase label vs semver discipline across tasks, PRs, reviews, issues, commits, and tags

package/standards/intake.md

@@ -1,6 +1,8 @@
 ---
 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

package/standards/markdown.md

@@ -1,6 +1,12 @@
 ---
 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.'
 ---
 
 # Markdown reference

package/standards/memory.md

@@ -1,6 +1,8 @@
 ---
 title: Memory reference
 description: Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
+paths:
+  - '.canon/memory/**'
 ---
 
 # Memory reference

package/standards/mermaid.md

@@ -1,6 +1,12 @@
 ---
 title: Mermaid reference
 description: Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram
+paths:
+  - '**/*.md'
+rule:
+  - 'Apply this rule only when the edit drafts or revises a Mermaid fence. Skip it on a markdown edit carrying no diagram.'
+  - 'Read it before drafting the fence. Do not work the layout or the budgets from memory.'
+  - 'Which diagram a document carries and what question it answers is a separate topic. The diagrams standard routes it.'
 ---
 
 # Mermaid reference

package/standards/plan-lifecycle.md

@@ -0,0 +1,36 @@
+---
+title: Plan lifecycle reference
+description: When a feature plan is written, where it lives, how it changes mid-flight, and its move to the archive
+---
+
+# Plan lifecycle reference
+
+Applies to a feature plan at `.canon/plans/feature-<slug>.md` from the session that writes it to the archive. The folder is gitignored, so nothing but this lifecycle keeps a plan's rejected alternatives readable after the work ships.
+
+This standard governs when a plan moves and changes rather than what the file holds, so it carries no template. The plan's own template is in `plan.md`.
+
+## Scope
+
+Governs when a feature plan is written, where it lives across working trees, how it is amended, and its move to `.canon/plans/archive/`.
+
+Does not govern:
+
+- The filename, the required sections, and the suggested-and-answer contract: `plan.md`
+- The task file a plan is linked from, and how it is archived: `tasks.md`
+
+## What a working lifecycle looks like
+
+A plan's lifecycle works when a later reader can still answer, from the file alone:
+
+- What did the work set out to do, and which alternative did it reject?
+- Which answer to each question is current, without reconciling two passages?
+
+A plan lost to deletion, or carrying two answers to one question, fails both.
+
+## Lifecycle
+
+- Write the plan before implementation starts, and treat it as the scope of the run that executes it. A subject that has to be measured before anyone can plan against it takes a measurement track first.
+- Keep every plan at one root. A plan copied into each parallel working tree forks, and the copies answer the same question differently.
+- Amend the plan in place when a decision changes mid-flight. Do not append a second passage narrating the change, which leaves a reader to work out which of two answers is current. An execution-time deviation from a suggestion is one such amendment, and the suggested-and-answer contract in `plan.md` fixes which line takes it.
+- Move the plan to `.canon/plans/archive/` when the work it describes ships or is declined. Never delete it, because the plan is where the rejected alternative is written down. A flat `.claude/plans-archive/` sibling is the older layout.
+- Write the plan in the same session that opens the task it serves. The session executing it later inherits reasoning it would otherwise re-derive.

package/standards/plan.md

@@ -1,20 +1,30 @@
 ---
 title: Plan reference
-description: Filename and slug, required sections, the suggested-and-answer contract, and the lifecycle from the live folder to the archive
+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
 
 Applies to a feature plan at `.canon/plans/feature-<slug>.md`. One file holds one concern, written before implementation starts and read by whatever executes it, so it has to carry the scope without the conversation that produced it.
 
-The folder is gitignored, and backed by `canon records push` wherever a records remote is configured. Nothing backs a plan deleted before a push, which is why the archive step below is a move rather than a cleanup.
+The folder is gitignored, and backed by `canon records push` wherever a records remote is configured. Nothing backs a plan deleted before a push, which is why the archive step is a move rather than a cleanup.
 
 ## Scope
 
-Governs a feature plan under `.canon/plans/feature-<slug>.md`: the filename, the required sections, what each holds, the suggested-and-answer contract, and the lifecycle from the live folder to the archive.
+Governs a feature plan under `.canon/plans/feature-<slug>.md`: the filename, the required sections, what each holds, and the suggested-and-answer contract.
 
 Does not govern:
 
+- When a plan is written, how it is amended, and its move to the archive: `plan-lifecycle.md`
 - One question measured in depth before anyone can plan against it: `groundwork.md`
 - A dump of many findings filed by domain, each carrying its own verdict: `intake.md`
 - The task file a plan is linked from, and the origin line pointing back at it: `tasks.md`
@@ -135,14 +145,6 @@ The plan is archived at ship, so the same deviation takes one line in the open t
 
 This contract inverts the one an intake folder keeps, where an empty slot means unread and acceptance is typed out. A plan is written and read in one sitting with every question already surfaced, so silence is a usable default here and is not one there.
 
-## Lifecycle
-
-- Write the plan before implementation starts, and treat it as the scope of the run that executes it. A subject that has to be measured before anyone can plan against it takes a measurement track first.
-- Keep every plan at one root. A plan copied into each parallel working tree forks, and the copies answer the same question differently.
-- Amend the plan in place when a decision changes mid-flight. Do not append a second passage narrating the change, which leaves a reader to work out which of two answers is current. An execution-time deviation from a suggestion is one such amendment, and the contract above fixes which line takes it.
-- Move the plan to `.canon/plans/archive/` when the work it describes ships or is declined. Never delete it, because the plan is where the rejected alternative is written down. A flat `.claude/plans-archive/` sibling is the older layout.
-- Write the plan in the same session that opens the task it serves. The session executing it later inherits reasoning it would otherwise re-derive.
-
 ## Template
 
 ```markdown

package/standards/readme.md

@@ -1,6 +1,8 @@
 ---
 title: Readme reference
 description: Readme voice, structure, and content conventions
+paths:
+  - '**/README.md'
 ---
 
 # Readme reference

package/standards/ready.md

@@ -1,6 +1,10 @@
 ---
 title: Ready reference
 description: Folder layout, ordinal naming, the overview frontmatter, the thin-plan contract, and the archive lifecycle for a finished-file handoff
+paths:
+  - '.canon/ready/**'
+rule:
+  - 'Load the `canon:draft-ready` skill to write a ready folder, its overview, the thin plan, and the task row. It owns the procedure. Report it rather than proceeding silently when it does not resolve, since it ships with the plugin and this rule ships with the CLI.'
 ---
 
 # Ready reference

package/standards/requirements.md

@@ -1,6 +1,9 @@
 ---
 title: Requirements reference
 description: Shape and content rules for canon/REQUIREMENTS.md
+paths:
+  - 'canon/REQUIREMENTS.md'
+  - '.claude/REQUIREMENTS.md'
 ---
 
 # Requirements reference

package/standards/rule.md

@@ -1,6 +1,10 @@
 ---
 title: Governance rule reference
 description: Rule frontmatter, body shape, and voice for .claude/rules files
+paths:
+  - '.claude/rules/**/*.md'
+rule:
+  - 'Read it before writing or editing a rule. Do not work the shape from memory.'
 ---
 
 # Governance rule reference
@@ -36,7 +40,8 @@ Write both when both apply. A rule stating the directive and a skill stating how
 - `<n>` is a number from the band reserved for the rule's source and `<slug>` is a one-to-three-word kebab topic
 - A rule the project authored itself lives at `.claude/rules/project/<subdirectory>/<n>-<slug>.md`, a sibling of `canon/` rather than nested inside it, keeping the same subdirectory names
 - This repository's own toolkit-only rules, which never ship to a target, live at `.claude/rules/internal/<subdirectory>/<n>-<slug>.md`, a second sibling of `canon/`. See "Two sources numbering into one folder" below.
-- Give every rule a numeric prefix. A bare-word filename reads as a folder name where a stack names its rules, so a rule without one is unreachable from a stack entry.
+- Give every authored rule a numeric prefix. A bare-word filename reads as a folder name where a stack names its rules, so a rule without one is unreachable from a stack entry.
+- A rule that only routes a path to a standard is generated, not authored. It lives at `governance/rules/standards/<standard>.md` under the standard's name, carries no number, and installs to `.claude/rules/canon/standards/`. Never hand-edit one. Change its globs and bullets in the standard's `paths` and `rule` frontmatter, and `canon gov regen` rewrites it. The generator refuses a standard named like a band folder, which keeps the bare-word name reachable.
 
 ## Reserved numbers
 

package/standards/session.md

@@ -1,6 +1,10 @@
 ---
 title: Session map reference
 description: Filename and location, the sections a handoff carries, the write and read procedures, and how a role extends it
+paths:
+  - '.canon/tasks/session-*.md'
+rule:
+  - 'Follow this rule rather than the tasks rule for a `session-` file. A handoff is not a task and carries neither `## Outcomes` nor `## Findings`.'
 ---
 
 # Session map reference

package/standards/skill-paths.md

@@ -0,0 +1,50 @@
+---
+title: Skill path reference
+description: Which root a file a skill body names resolves against, and how a body cites a standard
+---
+
+# Skill path reference
+
+Applies to every path a skill body names, under `skills/<name>/`. A skill reads from two roots, so the path it writes decides whether the file is found once the skill runs from another project.
+
+This is an attribute standard. It governs the path strings a body carries rather than a file of its own, so it carries no template.
+
+## Scope
+
+Governs how a `SKILL.md` body or a file under its `references/` names a bundled asset, an installed shared doc, or a standard.
+
+Does not govern:
+
+- The skill folder, its frontmatter, the body rules, and the choice between skill types: `skill.md`
+- Punctuation, formatting, and word choice: `markdown.md`
+
+## What a working path looks like
+
+A path in a skill body works when the skill resolves it from any project it runs in:
+
+- Does each bundled asset resolve against the skill's own directory rather than the session's working directory?
+- Does each cited standard resolve in a target that installed nothing but the plugin?
+- Does a procedure two skills share live in one place, with each body citing it?
+
+A body failing any of these is non-conforming even when every path resolves in this repository.
+
+## Path resolution
+
+Know which root a file lives under before referencing it.
+
+- Bundled skill assets (`references/`, `scripts/`, `assets/`) resolve against the skill's own directory. Reference them with `${CLAUDE_SKILL_DIR}/<path>`, never a bare relative path, which resolves against the session cwd and fails when a plugin skill runs from another project.
+- Installed shared docs (`.claude/rules/`, `canon/context/`) resolve against the target project cwd, where install placed them. Reference them by that path.
+- Do not hand-copy a standard into a skill. If a skill must carry its own copy, generate it from the single source and reference it through `${CLAUDE_SKILL_DIR}`, so one owner keeps every copy in sync.
+
+## Citing a standard
+
+No standard installs into a project, so a body cites one place rather than choosing between two.
+
+- Cite `${CLAUDE_SKILL_DIR}/../../standards/X.md`. The plugin ships the whole standards folder beside `skills/`, so the path resolves in every install.
+- Never cite `.claude/standards/X.md` from a shipped body. A target holds no such folder. <!-- audit-ignore-citations: .claude/standards/X.md -->
+- Name `canon standards X` instead where the body wants the document rather than a path to open, such as a value it captures or reports. That verb resolves `standards/` at the project root and then the corpus inside the package.
+- State the path once per body, at the site that reads the standard. A later mention of a standard the body already read stays bare, since repeating the path at every mention is noise rather than instruction.
+- A guard on a standard's presence names the file rather than the folder holding it, since a folder test answers for a sibling that happens to be there.
+- Use `${CLAUDE_SKILL_DIR}`, never a bare `../../` and never `${CLAUDE_PLUGIN_ROOT}`, since only the first expands before the body reaches the model.
+- Cite a shared procedure, never restate it. A procedure two or more skills execute gets one definition in a standard and a citation in each body.
+- Keep the trigger in the body and the procedure in the standard. The citing skill states when the procedure runs and what it runs against, since that varies per skill and the standard cannot know it.

package/standards/skill.md

@@ -1,6 +1,18 @@
 ---
 title: Claude skill reference
-description: Claude skill structure and authoring rules
+description: Skill structure and authoring rules for Claude Code
+paths:
+  - '.claude/skills/**/SKILL.md'
+  - 'claude/skills/**/SKILL.md'
+  - '.claude/skills/**/REQUIREMENT.md'
+  - 'claude/skills/**/REQUIREMENT.md'
+rule:
+  - "Confirm `canon:create-skill`'s two creation-time questions are answered before a new `SKILL.md` lands, whether drafted by hand, by another skill, or by `canon:create-skill` itself. Carry the third question into the sibling `REQUIREMENT.md`'s `Must not` section as a review criterion rather than a gate."
+  - 'Report it rather than proceeding silently when `canon:create-skill` does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.'
+  - 'Re-read a skill body this session edited before invoking that skill again in the same session'
+  - 'Do not read a resolved file path in a held body as evidence the body is current'
+  - 'Follow the skill requirement standard for the shape a `REQUIREMENT.md` states. Read it with `canon standards skill-requirement`.'
+  - 'Follow the skill path standard for which root a path in a body resolves against and how a body cites a standard. Read it with `canon standards skill-paths`.'
 ---
 
 # Claude skill reference
@@ -17,11 +29,12 @@ Does not govern:
 
 - What a `REQUIREMENT.md` must answer, its sections, and its template: `skill-requirement.md`
 - A practice skill's closing sections and ledger: `skill-practice.md`
+- Which root a path in a body resolves against, and how a body cites a standard: `skill-paths.md`
 - Path-scoped coding rules, which load on a file match rather than on a request match: `rule.md`
 - Voice, rhythm, and sentence construction in a skill body: the `write-human` skill
 - Punctuation, formatting, and word choice in a skill body: `markdown.md`
 - The transform from a branch name to a slug a skill carries in a filename: `slug.md`
-- Whether a new skill earns its place: the three-question test in the `create-skill` skill and the clause in `570-skill.md`
+- Whether a new skill earns its place: the three-question test in the `create-skill` skill and the creation-time bullet in this standard's own `rule` frontmatter
 
 ## Changing a skill
 
@@ -146,27 +159,6 @@ allowed-tools: <tools required>
 - Use `#!/usr/bin/env bash` shebang
 - Always include `2>/dev/null || echo "FALLBACK"` guards on git and shell commands
 
-## Path resolution
-
-A skill reads from two roots, so know which one a file lives under before referencing it.
-
-- Bundled skill assets (`references/`, `scripts/`, `assets/`) resolve against the skill's own directory. Reference them with `${CLAUDE_SKILL_DIR}/<path>`, never a bare relative path, which resolves against the session cwd and fails when a plugin skill runs from another project.
-- Installed shared docs (`.claude/rules/`, `canon/context/`) resolve against the target project cwd, where install placed them. Reference them by that path.
-- Do not hand-copy a standard into a skill. If a skill must carry its own copy, generate it from the single source and reference it through `${CLAUDE_SKILL_DIR}`, so one owner keeps every copy in sync.
-
-### Citing a standard
-
-No standard installs into a project, so a body cites one place rather than choosing between two.
-
-- Cite `${CLAUDE_SKILL_DIR}/../../standards/X.md`. The plugin ships the whole standards folder beside `skills/`, so the path resolves in every install.
-- Never cite `.claude/standards/X.md` from a shipped body. A target holds no such folder. <!-- audit-ignore-citations: .claude/standards/X.md -->
-- Name `canon standards X` instead where the body wants the document rather than a path to open, such as a value it captures or reports. That verb resolves `standards/` at the project root and then the corpus inside the package.
-- State the path once per body, at the site that reads the standard. A later mention of a standard the body already read stays bare, since repeating the path at every mention is noise rather than instruction.
-- A guard on a standard's presence names the file rather than the folder holding it, since a folder test answers for a sibling that happens to be there.
-- Use `${CLAUDE_SKILL_DIR}`, never a bare `../../` and never `${CLAUDE_PLUGIN_ROOT}`, since only the first expands before the body reaches the model.
-- Cite a shared procedure, never restate it. A procedure two or more skills execute gets one definition in a standard and a citation in each body.
-- Keep the trigger in the body and the procedure in the standard. The citing skill states when the procedure runs and what it runs against, since that varies per skill and the standard cannot know it.
-
 ## Invocation
 
 - Invoke a plugin skill by its namespaced name, `/<plugin>:<skill-name>`.

package/standards/standard.md

@@ -1,6 +1,10 @@
 ---
 title: Standard reference
 description: Shape and content rules for authoring a standard
+paths:
+  - 'standards/**/*.md'
+rule:
+  - 'Read it before writing or editing a standard. Do not work the shape from memory.'
 ---
 
 # Standard reference
@@ -64,7 +68,9 @@ A standard failing these questions is non-conforming even when it satisfies ever
 
 - Start the file with a frontmatter block carrying at least `title` and `description`. A consuming surface may require more.
 - `title`: names the doc type in sentence case, suffixed `reference` (`Commit reference`, `Branch reference`)
-- `description`: one line naming what the standard covers. It becomes the index link label on install.
+- `description`: one line naming what the standard covers. It becomes the index link label on install, and the generated rule's description and pointer bullet.
+- `paths` (optional): the globs where the standard applies, one per entry, copied verbatim into the rule `canon gov regen` generates for it. Omit it when no path should route to the standard, and no rule is generated.
+- `rule` (optional): operative bullets the generated rule carries after its pointer bullet, one per entry, each a full sentence. Quote an entry holding a backtick, a colon, or a leading `-`.
 
 ## Structure
 

package/standards/tasks-decline.md

@@ -0,0 +1,38 @@
+---
+title: Task decline reference
+description: Where a task decided against moves, the Declined line it carries, and what happens to its plan and board row
+---
+
+# Task decline reference
+
+Applies to a task under `.canon/tasks/` that somebody decided against doing. `canon tasks decline` performs the move, and this file fixes what the move leaves behind.
+
+This is an attribute standard. It governs one origin line and one folder move rather than a file of its own, so it carries no template.
+
+## Scope
+
+Governs the `.canon/tasks/declined/` folder, the `Declined:` line, and what declining does to the task's plan and board row.
+
+Does not govern:
+
+- The task file's layout, filename, format, other origin lines, and archiving: `tasks.md`
+- The board rows the move clears: `board.md`
+
+## What a working decline looks like
+
+A declined task works when a later reader can tell, from the folder and the file alone:
+
+- Was the work decided against, rather than shipped or merely unscheduled?
+- Who decided, when, and why?
+
+## Declining
+
+A task decided against moves to `.canon/tasks/declined/` rather than `.canon/tasks/archive/`. The two folders answer different questions: archive means the work shipped, declined means somebody decided against doing it. Neither reading fits a task that is merely unscheduled, which stays on `backlog.md` rather than moving anywhere, since nobody has decided against it and it may still rise when the board has room.
+
+`canon tasks decline` carries no outcome-state gate, so a task can be decided against at any outcome state, open outcomes included.
+
+The decision is recorded on the task itself with a `Declined:` line, in the `Plan:`/`Pull request:` family: `Declined: <reason>, <who> on <YYYY-MM-DD>`. It anchors the same way `Pull request:` does, after the last origin line the task carries. The line is free prose after the colon, since it names no file to link.
+
+Declining a task moves its plan alongside it the same way archiving does, when the declining task is that plan's last live citation. A plan several tasks share stays where it is, and a declined task's plan lands in `.canon/plans/archive/` indistinguishable from a shipped one by folder alone. The task file under `.canon/tasks/declined/` is what records which it was.
+
+The move clears whichever of `priority.md` or `backlog.md` holds the task's row.

package/standards/tasks.md

@@ -1,6 +1,12 @@
 ---
 title: Tasks reference
 description: Folder layout, filename convention, file format, origin lines, and archiving for task files under .canon/tasks/
+paths:
+  - '.canon/tasks/**'
+rule:
+  - 'Follow the board standard for `priority.md` and `backlog.md`, their readiness groups, and row order. Read it with `canon standards board`.'
+  - 'Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter.'
+  - 'Follow the task decline standard for a task decided against. Read it with `canon standards tasks-decline`.'
 ---
 
 # Tasks reference
@@ -13,10 +19,11 @@ The folder is gitignored. Board state changes when work ships rather than when a
 
 ## Scope
 
-Governs the task files under `.canon/tasks/`: folder layout, filenames, frontmatter, file format, origin lines, archiving, and declining.
+Governs the task files under `.canon/tasks/`: folder layout, filenames, frontmatter, file format, origin lines, and archiving.
 
 Does not govern:
 
+- The declined folder, the `Declined:` line, and what declining does to a plan and a board row: `tasks-decline.md`
 - Execution order, readiness groups, the backlog, and the generated index beside the tasks: `board.md`
 - The plan file a task cites, its sections, and its answer contract: `plan.md`
 - Phase-label format and which surfaces a label may appear on: `versioning.md`
@@ -161,15 +168,3 @@ The archive nests inside `.canon/tasks/` rather than sitting beside it as a flat
 Archiving a task archives its plan alongside it, when the closing task is that plan's last live citation. The archived task's `Plan:` line is retargeted at `../../plans/archive/feature-<slug>.md`. The ready folder its `Ready:` line names moves with the plan to `.canon/ready/archive/<nn>-<slug>/`, and both pointers to it are retargeted. A plan several tasks share stays live with its ready folder, and the task archives anyway.
 
 A task with an open outcome stays on the board, and so does its plan. Close it, or cut it from the task when the work is being abandoned, so what was dropped is recorded rather than inferred from an archived file. Cutting means striking the outcome's body: `- ~~<outcome>~~ <why>`. A struck body reads as cut whatever its checkbox holds, so a task carrying only cut outcomes still archives.
-
-## Declining
-
-A task decided against moves to `.canon/tasks/declined/` rather than `.canon/tasks/archive/`. The two folders answer different questions: archive means the work shipped, declined means somebody decided against doing it. Neither reading fits a task that is merely unscheduled, which stays on `backlog.md` rather than moving anywhere, since nobody has decided against it and it may still rise when the board has room.
-
-`canon tasks decline` carries no outcome-state gate, so a task can be decided against at any outcome state, open outcomes included.
-
-The decision is recorded on the task itself with a `Declined:` line, in the `Plan:`/`Pull request:` family: `Declined: <reason>, <who> on <YYYY-MM-DD>`. It anchors the same way `Pull request:` does, after the last origin line the task carries. The line is free prose after the colon, since it names no file to link.
-
-Declining a task moves its plan alongside it the same way archiving does, when the declining task is that plan's last live citation. A plan several tasks share stays where it is, and a declined task's plan lands in `.canon/plans/archive/` indistinguishable from a shipped one by folder alone. The task file under `.canon/tasks/declined/` is what records which it was.
-
-The move clears whichever of `priority.md` or `backlog.md` holds the task's row.

package/standards/teach.md

@@ -1,6 +1,11 @@
 ---
 title: Teach reference
 description: Workspace layout, ordinal naming, frontmatter, and the mission and learning-record formats for a learning workspace
+paths:
+  - '.canon/teach/**'
+rule:
+  - 'Follow the glossary standard for the glossary every workspace carries at its root. It is the single source for the entry shape, the ordering, and which terms the file carries. Read it with `canon standards glossary`.'
+  - 'Report it rather than proceeding silently when that file does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.'
 ---
 
 # Teach reference

package/standards/wiki.md

@@ -1,6 +1,10 @@
 ---
 title: Wiki reference
 description: Folder split, frontmatter, naming convention, and sourcing for a wiki reference page
+paths:
+  - 'wiki/**/*.md'
+rule:
+  - 'Read it before drafting a page. Do not work the placement criterion or the naming convention from memory.'
 ---
 
 # Wiki reference

package/standards/wireframes.md

@@ -1,6 +1,11 @@
 ---
 title: Wireframe reference
 description: Shape and content rules for canon/wireframes/<surface>.md files
+paths:
+  - 'canon/wireframes/**'
+  - '.claude/wireframes/**'
+rule:
+  - 'Read it before adding or revising a surface.'
 ---
 
 # Wireframe reference

package/governance/rules/canon/610-context.md

@@ -1,17 +0,0 @@
----
-description: Route canon/context edits to the context-entry standard and the consult-first workflow
-paths:
-  - 'canon/context/**'
-  - '.claude/context/**'
----
-
-# Context entry standards
-
-## Before editing
-
-- Before non-trivial work in a domain, read its `canon/context/<domain>.md` entry. Use `canon/context/index.md` to find it.
-- Leave the entry conforming when work in its domain changes what it describes.
-
-## Authority
-
-- Follow the context standard for entry shape: frontmatter, sections, length, and what goes in. It is the single source. Read it with `canon standards context`.