@erclx/canon 5.19.0 → 5.21.0

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`
@@ -134,7 +141,7 @@ One plan per task, or one per slice, which the board check reads as distinct pla
 
 `Pull request:` records which pull requests carry the task's work, each as a bare `#NNN` the way `Issue:` does. It lists every pull request that shipped part of the task, oldest first and separated by commas, as in `Pull request: #NNN, #NNN`, and a task shipped whole lists one. It is not an origin, so a task without one is well-formed. `git-pr` appends to it when a pull request opens.
 
-The line is what lets a merge close its own task. `canon tasks archive --pull-request <n>` finds the task by any number the line lists and archives it only on the last. One pull request, one task: two tasks naming the same number refuse to archive rather than both moving. `Pending branch: <branch>` holds that merge back while a branch that ticked an outcome waits on its own number, since `canon tasks outcome` writes it and `canon tasks pull-request` clears it.
+The line is what lets a merge close its own task. `canon tasks archive --pull-request <n>` finds the task by any number the line lists and archives it only on the last. One pull request, one task: two tasks naming the same number refuse to archive rather than both moving. `Pending branch: <branch>` holds that merge back while a branch that ticked an outcome waits on its own number, since `canon tasks outcome` writes it and `canon tasks pull-request` clears it. `canon tasks outcome` skips the write when the branch's own pull request is already on the line.
 
 ## What goes in
 
@@ -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/tooling/astro/configs/card-src/pages/og-card.astro

@@ -20,12 +20,12 @@
  * `scripts/check-card-exclusion.sh` fails a build that carries the marker
  * below, which is what keeps the route out of the published site.
  */
-import '@/styles/global.css'
 
-// Retarget the import above when this project keeps its global stylesheet
+// Point the import below at this project's global stylesheet when it lives
 // somewhere else. An unresolved path refuses the card server by name, which is
 // the loud direction: a card captured against no stylesheet renders as an
 // unstyled box and reports success.
+import '@/styles/global.css'
 ---
 
 <html lang="en">

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

@@ -1,25 +0,0 @@
----
-name: docs-fold
-description: Why a pointer answers under the fold skill's old name, and the test that retires it
----
-
-# Docs fold requirement
-
-## Gap
-
-Without this skill, a person typing the old name after the rename to `context-fold` meets an unknown command with nothing naming where the skill went. A target that has not run `canon migrate skill-names` still holds files telling someone to type it, and a live gitignored record written before the rename still names it, since the sweep reads the tracked listing only.
-
-## Must
-
-- Name `context-fold` as the skill to run, so a typed invocation of the old name reaches the new one in one step
-- Carry `disable-model-invocation: true`, so routing never matches the old description against a request the new skill owns
-
-## Must not
-
-- Carry any part of the fold procedure, which would give one behavior two bodies that drift apart
-- Retire on a release number. Retire it when `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name, since a release number retires it on a date nothing measured.
-
-## Out of scope
-
-- The fold itself, which `context-fold` owns
-- Rewriting a stale citation, which `canon migrate skill-names` owns in a tracked file and the controlling session owns on the board

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

@@ -1,9 +0,0 @@
----
-name: docs-fold
-description: Renamed to `context-fold`. Answers a typed invocation of the old name by pointing at the new one.
-disable-model-invocation: true
----
-
-# Docs fold
-
-This skill is now `context-fold`. Run `/canon:context-fold` instead, and change any file that still names this one.

package/claude/skills/standards-audit/REQUIREMENT.md

@@ -1,33 +0,0 @@
----
-name: standards-audit
-description: What the standards audit is for, the gaps it closes, and the fixing it deliberately refuses
----
-
-# Standards audit requirement
-
-## Gap
-
-Without this skill, markdown ships unchecked against the authoring standards it was written under. A session fresh from writing prose does not reopen the standard it was meant to follow, banned punctuation survives because it reads fine, and the mapping from a file to the standards governing it gets re-derived by guess on every pass.
-
-## Must
-
-- Scope the audit to markdown the project hand-authors, so a generated file is not reported against a standard nobody applies to it
-- Decide which standards govern each changed file, rather than auditing every file against every standard
-- Grep for the violations a standard makes mechanically detectable, because reading alone misses occurrences
-- Report each finding with a file and a line, grouped so one file is one fix pass
-
-## Must not
-
-- Fix a violation, or propose the fix inline. The cheap swap satisfies the grep and breaks the rule the grep was standing in for.
-- Enumerate specific rules or tokens from a standard. The standard is the list, and a copy of it here drifts the moment the standard changes.
-
-## Guards
-
-- No markdown changed since main: stop with a pass, not an error
-- No installed standards to audit against: stop and say where they come from
-
-## Out of scope
-
-- Code style and structure, which `.claude/rules/` governs and Claude Code loads directly
-- Whether a standard is itself correct. A finding against the corpus is an argument to change the standard, and that is a standards edit rather than an audit result.
-- Persisting a report. The diff is the living state and the audit is a check against it at a moment.

package/claude/skills/standards-audit/SKILL.md

@@ -1,99 +0,0 @@
----
-name: standards-audit
-description: Audits changed markdown files against every authoring standard that declares jurisdiction over their paths and reports violations without fixing. Reads the standards catalog to map each file, greps for banned tokens, and groups findings by file. Use when asked to "audit prose", "audit standards", "check standards", "standards audit", or after editing markdown where standards compliance matters. Do NOT fix violations. Reporting only.
----
-
-# Standards audit
-
-## Guards
-
-- Resolve the base ref first, per Diff baseline below, then scope the file list exactly as Step 1 does, fallback included. If no markdown files changed, stop: `✅ No markdown changes to audit.` A guard that reads bare local `main`, or that skips the unusable-baseline fallback, passes the skill clean on a branch it never read.
-- If `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` is not present, stop: `❌ markdown.md standard not found. Reinstall the canon plugin.` Test the file rather than the directory, since a plugin cache built before a given file existed keeps the directory without ever receiving that file.
-- `markdown.md` is the one standard testable before the mapping runs, since its scope statement declares an attribute and every changed markdown file therefore maps to it. Every other standard is tested in Step 3, where the mapping has named which ones the run needs.
-
-## Diff baseline
-
-Resolve the base ref once and reuse it in the guard and in Step 1:
-
-```bash
-git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null
-```
-
-Prefer `origin/main` over local `main`. On `main` itself the local ref resolves to HEAD, so every committed change drops out of the set and the audit passes clean rather than admitting it cannot see the files.
-
-The baseline is unusable in two cases:
-
-- No merge base resolves against either ref.
-- The base equals HEAD, whichever ref resolved it. Nothing is committed ahead of the base to compare against. This is the ordinary shape on `main`, and on a feature branch before its first commit.
-
-An unusable baseline costs only the committed half. Audit `git diff HEAD --name-only` instead and lead the report with `⚠ Baseline unusable. Audited the uncommitted set only.`, so a clean result is never read as a clean branch.
-
-## Step 1: scope the audit
-
-Get the changed file list, substituting `git diff HEAD --name-only` when the baseline is unusable:
-
-```bash
-git diff <base> HEAD --name-only
-```
-
-Filter to markdown (`.md`), then drop what the project does not hand-author:
-
-- `index.md`, unless its frontmatter carries `auto: false`
-- Any file in a gitignored directory
-- Any file sitting in a skill's bundled reference folder whose frontmatter names the consumers a generator copied it out to
-
-The last rule keeps a fan-out from multiplying one edit into a finding per copy. The source is the file to audit and the only one an author can fix, because the next regen overwrites every copy.
-
-It takes both halves. A generator copies frontmatter verbatim, so the field alone matches the source as well and drops the one file the rule means to keep. The location alone matches a reference the skill author wrote by hand, which carries no such field and is governed like the rest of the folder.
-
-## Step 2: map files to standards
-
-Read the mapping rather than holding it here. Every standard declares the paths it governs, so a standard added later joins this audit with no edit to this body:
-
-```bash
-canon standards list --json
-```
-
-Each entry carries `appliesTo`, the paths its `## Scope` statement declares. Match every changed file against every entry:
-
-- `*` matches every changed markdown file
-- An entry ending in `/` matches when the file path contains it at a path-segment boundary
-- Any other entry matches when the file path ends with it at a path-segment boundary
-
-Add any standard the catalog did not list, reading `${CLAUDE_SKILL_DIR}/../../standards/` and whatever folder the project authors its own standards in, and derive every declaration the same way when `canon` is unavailable: the backticked paths in the first sentence under `## Scope`, or `*` when that sentence says the standard governs an attribute. Skip `index.md`, which is generated from the others and declares nothing.
-
-An entry whose `appliesTo` is empty declared nothing this can read. Report it as a finding against that standard's own file in Step 4 and audit the rest. A standard dropped in silence is the same miss this mapping exists to remove, one level up.
-
-Every mapping names a changed markdown file, which is the only thing Step 1 produces. Text that never lands in the tree, such as a branch name or a pull request body, is checked by the skill that publishes it rather than here.
-
-## Step 3: read standards and audit
-
-Read each applicable standard once from `${CLAUDE_SKILL_DIR}/../../standards/<name>`, testing the file before reading it. A standard the mapping named and that path does not carry is reported as a finding against the file that mapped to it rather than skipped, since a standard read from nowhere reports every file under it clean.
-
-For each changed file, audit against every rule:
-
-- **Pattern rules**: grep the file for every token the standard bans. Grep is authoritative. Reading alone misses occurrences.
-- **Judgment rules**: check each rule in context against the standard that states it.
-
-Every changed markdown file gets the pattern pass, since `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` applies to all of them. Take the banned tokens from that standard at read time rather than from a list held here. It carries the banned characters, so one read covers every token this pass greps for.
-
-## Step 4: report
-
-Group findings by file with line references, naming the standard each one comes from. One file is one fix pass, and the standard is what the reader opens to settle a finding they disagree with. Use this shape:
-
-```markdown
-path/to/file.md
-
-- L12: `markdown.md`, em dash in prose
-- L34: `markdown.md`, semicolon used to join clauses
-- L51: `markdown.md`, vague qualifier `simply`
-- L67: `context.md`, decision entry names no rejected alternative
-```
-
-If clean, respond with `✅ No violations.`
-
-Reporting only. Do not rewrite any file, swap any punctuation, or propose fixes inline. Fixes are a separate user-initiated step because a lazy swap (semicolon to period, em dash to comma) leaves the sentence in the shape the ban exists to remove.
-
-## Output
-
-Chat output is the full report. This skill does not persist a file. The audit is a momentary check and living state is the diff itself.

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`.

package/governance/rules/canon/620-wireframes.md

@@ -1,13 +0,0 @@
----
-description: Route canon/wireframes edits to the wireframe standard for layout and interaction intent
-paths:
-  - 'canon/wireframes/**'
-  - '.claude/wireframes/**'
----
-
-# Wireframe standards
-
-## Authority
-
-- Follow the wireframes standard for layout and interaction intent: regions, the states table and its evidence links, copy, behavior, exclusions, and what moves to `canon/context/`. It is the single source. Read it with `canon standards wireframes`.
-- Read it before adding or revising a surface.

package/governance/rules/canon/630-requirements.md

@@ -1,12 +0,0 @@
----
-description: Route canon/REQUIREMENTS.md edits to the requirements standard for product scope and goals
-paths:
-  - 'canon/REQUIREMENTS.md'
-  - '.claude/REQUIREMENTS.md'
----
-
-# Requirements standards
-
-## Authority
-
-- Follow the requirements standard for what belongs in the problem, goals, non-goals, MVP features, and constraints. It is the single source. Read it with `canon standards requirements`.

package/governance/rules/canon/650-design.md

@@ -1,12 +0,0 @@
----
-description: Route canon/DESIGN.md edits to the design standard for visual intent and token tables
-paths:
-  - 'canon/DESIGN.md'
-  - '.claude/DESIGN.md'
----
-
-# Design standards
-
-## Authority
-
-- Follow the design standard for visual intent, the token tables, and the render contract. It is the single source. Read it with `canon standards design`.

package/governance/rules/canon/655-tasks.md

@@ -1,13 +0,0 @@
----
-description: Route .canon/tasks/ edits to the tasks standard for task files and the board standard for priority.md and backlog.md
-paths:
-  - '.canon/tasks/**'
----
-
-# Tasks standards
-
-## Authority
-
-- Follow the tasks standard for filenames, frontmatter, what belongs, and the task file format. It is the single source. Read it with `canon standards tasks`.
-- 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.

package/governance/rules/canon/656-groundwork.md

@@ -1,11 +0,0 @@
----
-description: Route .canon/groundwork/ edits to the groundwork standard for ordinal naming, numbering, frontmatter, and required file contents
-paths:
-  - '.canon/groundwork/**'
----
-
-# Groundwork standards
-
-## Authority
-
-- Follow the groundwork standard for reserved numbering, frontmatter and dating, what each required file holds, and the conventions a track keeps. It is the single source. Read it with `canon standards groundwork`.

package/governance/rules/canon/657-intake.md

@@ -1,11 +0,0 @@
----
-description: Route .canon/intake/ edits to the intake standard for the item format, the answer contract, and ordinal naming
-paths:
-  - '.canon/intake/**'
----
-
-# Intake standards
-
-## Authority
-
-- Follow the intake standard for the folder layout, frontmatter and dating, the item format, and retrieval. It is the single source. Read it with `canon standards intake`.

package/governance/rules/canon/659-memory.md

@@ -1,11 +0,0 @@
----
-description: Route .canon/memory/ edits to the memory standard for the filename, frontmatter, body shape, and lifecycle
-paths:
-  - '.canon/memory/**'
----
-
-# Memory standards
-
-## Authority
-
-- Follow the memory standard for the filename and type prefix, the frontmatter, the body shape per type, links between entries, and the lifecycle. It is the single source. Read it with `canon standards memory`.