@erclx/canon 4.78.0 → 4.80.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +9 -9
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/canon-operator/SKILL.md +1 -1
- package/claude/skills/canon-rollout/SKILL.md +1 -1
- package/claude/skills/create-standard/SKILL.md +1 -1
- package/claude/skills/design-extract/REQUIREMENT.md +4 -4
- package/claude/skills/design-extract/SKILL.md +11 -11
- package/claude/skills/docs-fold/SKILL.md +14 -14
- package/claude/skills/docs-fold/references/anchor-sweep.md +1 -1
- package/claude/skills/docs-fold/references/wireframe-sweep.md +4 -4
- package/claude/skills/draft-context/REQUIREMENT.md +6 -6
- package/claude/skills/draft-context/SKILL.md +8 -6
- package/claude/skills/draft-diagram/SKILL.md +5 -5
- package/claude/skills/draft-identity/SKILL.md +3 -3
- package/claude/skills/draft-readme/REQUIREMENT.md +1 -1
- package/claude/skills/draft-screencast/SKILL.md +1 -1
- package/claude/skills/draft-wireframes/REQUIREMENT.md +7 -7
- package/claude/skills/draft-wireframes/SKILL.md +7 -5
- package/claude/skills/git-pr/SKILL.md +3 -3
- package/claude/skills/git-pr/references/labels.md +1 -1
- package/claude/skills/memory-capture/REQUIREMENT.md +1 -1
- package/claude/skills/memory-capture/SKILL.md +6 -6
- package/claude/skills/memory-review/SKILL.md +1 -1
- package/claude/skills/migration-claude-md/REQUIREMENT.md +3 -3
- package/claude/skills/migration-claude-md/SKILL.md +7 -5
- package/claude/skills/migration-context/REQUIREMENT.md +3 -3
- package/claude/skills/migration-context/SKILL.md +11 -9
- package/claude/skills/plan-feature/SKILL.md +4 -4
- package/claude/skills/plan-groundwork/SKILL.md +2 -2
- package/claude/skills/plan-intake/SKILL.md +2 -2
- package/claude/skills/project-commands/SKILL.md +2 -2
- package/claude/skills/review-branch/SKILL.md +3 -3
- package/claude/skills/review-pr/SKILL.md +2 -2
- package/claude/skills/role-orchestrator/SKILL.md +1 -1
- package/claude/skills/role-planner/SKILL.md +1 -1
- package/claude/skills/session-relay/REQUIREMENT.md +1 -1
- package/claude/skills/session-resume/SKILL.md +1 -1
- package/claude/skills/setup-gov/SKILL.md +1 -1
- package/claude/skills/setup-init/SKILL.md +1 -1
- package/claude/skills/teach-workspace/references/promotion.md +5 -5
- package/claude/skills/ux-audit/SKILL.md +5 -5
- package/claude/skills/ux-measure/SKILL.md +1 -1
- package/docs/agents/audits.md +2 -2
- package/docs/agents/commands.md +7 -2
- package/docs/agents/context-audit-checks.md +3 -3
- package/docs/agents/context-audit.md +2 -2
- package/docs/agents/counts.md +3 -3
- package/docs/agents/design-board.md +3 -3
- package/docs/agents/docs.md +3 -3
- package/docs/agents/indexes.md +1 -1
- package/docs/agents/install-and-sync.md +4 -4
- package/docs/agents/label-coverage.md +1 -1
- package/docs/agents/review-classification.md +1 -1
- package/docs/agents/routing.md +2 -2
- package/docs/agents/rule-citations.md +1 -1
- package/docs/agents/sandbox.md +1 -1
- package/docs/agents/scripting.md +1 -1
- package/docs/agents/skills-audit.md +1 -1
- package/docs/agents/skills-reach.md +4 -4
- package/docs/target-projects.md +11 -11
- package/docs/workflow/ai-workflow.md +15 -13
- package/docs/workflow/operating-model.md +2 -2
- package/docs/workflow/visual-design-workflow.md +8 -8
- package/governance/rules/claude/510-context.md +3 -2
- package/governance/rules/claude/520-wireframes.md +3 -2
- package/governance/rules/claude/530-requirements.md +2 -1
- package/governance/rules/claude/540-architecture.md +2 -1
- package/governance/rules/claude/550-design.md +2 -1
- package/governance/rules/core/025-indexes.md +1 -1
- package/governance/rules/core/045-memory.md +1 -1
- package/package.json +1 -1
- package/scripts/core/check-ignore-parity.sh +1 -1
- package/scripts/core/check-seed-independence.sh +5 -2
- package/scripts/core/install-check.sh +1 -1
- package/scripts/core/list-seed-roots.sh +3 -3
- package/scripts/core/regen-hero.sh +1 -1
- package/scripts/docs/list.sh +3 -3
- package/scripts/lib/sandbox-git.sh +1 -1
- package/scripts/lib/tooling.sh +6 -4
- package/snippets/claude/figma-steps.md +1 -1
- package/src/audits/baseline.ts +17 -5
- package/src/audits/catalog.ts +2 -2
- package/src/autoship/paths.ts +1 -1
- package/src/claude/cases/authoring.ts +2 -2
- package/src/claude/cases/setup.ts +1 -1
- package/src/claude/routing.ts +1 -1
- package/src/claude/seeds-list.ts +1 -1
- package/src/claude/seeds.ts +62 -28
- package/src/claude/skills-reach.ts +3 -3
- package/src/commands/claude.ts +1 -1
- package/src/commands/context.ts +8 -8
- package/src/commands/design.ts +1 -1
- package/src/commands/gov.ts +1 -1
- package/src/commands/migrate.ts +182 -1
- package/src/commands/sync.ts +1 -1
- package/src/context/audit.ts +1 -1
- package/src/context/citations.ts +7 -5
- package/src/context/folders.ts +2 -2
- package/src/counts/scan.ts +4 -4
- package/src/design/board.ts +5 -5
- package/src/design/components.ts +2 -2
- package/src/design/css.ts +1 -1
- package/src/design/document.ts +1 -1
- package/src/design/regen.ts +1 -1
- package/src/design/render.ts +1 -1
- package/src/design/tokens.ts +2 -2
- package/src/docs/read.ts +9 -3
- package/src/gate/measures.ts +14 -11
- package/src/gate/stages.ts +4 -4
- package/src/labels/map.ts +19 -5
- package/src/legacy-path.ts +15 -0
- package/src/markdown/scan.ts +1 -1
- package/src/migrate/plan.ts +1 -0
- package/src/migrate/surface-roots.ts +457 -0
- package/src/record-root.ts +6 -4
- package/src/sandbox/census.ts +1 -1
- package/src/shipped/references.ts +3 -3
- package/src/surface-root.ts +33 -8
- package/src/sync/layout.ts +10 -6
- package/src/sync/reverse.ts +1 -1
- package/src/sync/stamp.ts +22 -17
- package/src/targets/sweep.ts +6 -2
- package/src/tooling/inject.ts +5 -3
- package/src/tooling/scan.ts +4 -1
- package/standards/architecture.md +4 -4
- package/standards/context.md +7 -7
- package/standards/design.md +3 -3
- package/standards/diagrams.md +6 -6
- package/standards/index.md +5 -5
- package/standards/markdown.md +2 -2
- package/standards/publish.md +3 -3
- package/standards/readme.md +1 -1
- package/standards/requirements.md +4 -4
- package/standards/skill.md +2 -2
- package/standards/tasks.md +1 -1
- package/standards/wiki.md +1 -1
- package/standards/wireframes.md +8 -8
- package/tooling/astro/reference.md +3 -3
- package/tooling/base/reference.md +3 -3
- package/tooling/claude/reference.md +7 -3
- package/tooling/claude/seeds/CLAUDE.md +9 -9
- package/tooling/nextjs/reference.md +2 -2
- package/tooling/python/reference.md +1 -1
- package/tooling/vite-react/reference.md +2 -2
- package/tooling/web/reference.md +2 -2
- /package/tooling/base/seeds/{.claude → canon}/context/ci.md +0 -0
- /package/tooling/base/seeds/{.claude → canon}/context/development.md +0 -0
- /package/tooling/base/seeds/{.claude → canon}/context/index.md +0 -0
- /package/tooling/claude/seeds/{.claude → canon}/ARCHITECTURE.md +0 -0
- /package/tooling/claude/seeds/{.claude → canon}/DESIGN.md +0 -0
- /package/tooling/claude/seeds/{.claude → canon}/REQUIREMENTS.md +0 -0
- /package/tooling/claude/seeds/{.claude → canon}/wireframes/index.md +0 -0
|
@@ -5,7 +5,7 @@ description: Running the audit, its flags and folder scope, the exit codes, the
|
|
|
5
5
|
|
|
6
6
|
# Context audit
|
|
7
7
|
|
|
8
|
-
`canon context audit [path]` reports the structural state of the folders following the index-plus-entry contract, meaning a generated `index.md` beside entries carrying frontmatter, and it measures
|
|
8
|
+
`canon context audit [path]` reports the structural state of the folders following the index-plus-entry contract, meaning a generated `index.md` beside entries carrying frontmatter, and it measures `canon/ARCHITECTURE.md` beside them. It reads and reports. Fixing what it finds is separate work. What each finding means is in `context-audit-checks.md`.
|
|
9
9
|
|
|
10
10
|
Findings stated over every markdown file rather than over a context entry are measured by `canon markdown audit`, described in `markdown-audit.md`. That command resolves no folder, so it reaches trees this one refuses.
|
|
11
11
|
|
|
@@ -72,7 +72,7 @@ The exemption exists because the section check has a false-positive class. A sta
|
|
|
72
72
|
|
|
73
73
|
The citation check resolves every path into an audited folder that appears anywhere in the repository, and it is the half wired into `bun run check`. A stale reference has a silent failure mode: the session opens nothing and carries on.
|
|
74
74
|
|
|
75
|
-
Three exclusions keep it from firing on prose about paths. Fenced blocks are skipped in markdown, which covers a standard displaying a path as an example. Fixture and harness trees are skipped by location, covering sandbox scenarios that describe their own scratch tree, the eval harness naming its target project, and `*.test.ts`. A path into a folder the project does not carry is skipped, so a skill directing a reader to
|
|
75
|
+
Three exclusions keep it from firing on prose about paths. Fenced blocks are skipped in markdown, which covers a standard displaying a path as an example. Fixture and harness trees are skipped by location, covering sandbox scenarios that describe their own scratch tree, the eval harness naming its target project, and `*.test.ts`. A path into a folder the project does not carry is skipped, so a skill directing a reader to `canon/wireframes/index.md` stays valid in a project that has wireframes and silent in one that does not.
|
|
76
76
|
|
|
77
77
|
Two cases remain, and no syntax separates either from a real reference. One is a sentence naming a hypothetical entry to show the shape of a name. The other is a line instructing a target project about its own tree, which resolves against the target rather than against this repository and passes here only while the two layouts agree. Splitting a seeded domain into a folder ends that agreement and turns every such line red at once.
|
|
78
78
|
|
package/docs/agents/counts.md
CHANGED
|
@@ -43,7 +43,7 @@ Nothing stands between the trigger and the number, which is the rule an author w
|
|
|
43
43
|
|
|
44
44
|
The verb gate is not the first design tried. A bare number next to a catalog noun anywhere in the tracked corpus returned 290 findings against a repository whose actionable instance count was one. Reading that run showed why: `18 rules citing a standard`, `21 skill bodies`, and `eight internal skills` all pair a number with a catalog noun while naming a subset, an example, or a different catalog than the one matched, and that shape dominates ordinary prose. Every instance this sweep was written against reads the number as the direct object of a verb asserting the catalog's own total, and gating on that verb is what took the false-positive count from 290 to five on the same tree.
|
|
45
45
|
|
|
46
|
-
The article half was added after a first review of the shipped design found a live miss:
|
|
46
|
+
The article half was added after a first review of the shipped design found a live miss: `canon/context/development/gates.md` 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.
|
|
47
47
|
|
|
48
48
|
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 70 rules` at every width, and reached `the toolkit authors 70 rules` only at a width admitting the indirect-noun shape below. The two words reach both at 75 sentences and no false positive.
|
|
49
49
|
|
|
@@ -53,7 +53,7 @@ The verb gate alone still left four false positives standing: `carries two rules
|
|
|
53
53
|
|
|
54
54
|
A stated figure is read only when it sits within a factor of two of the true count, in either direction. That bound is tuned against the run this sweep was written against rather than reasoned to from first principles, the way `restated.ts` tunes its own document-frequency ceiling, and it is a property of the scale every catalog here sits at (the tens) rather than a universal rule.
|
|
55
55
|
|
|
56
|
-
The article gate is looser than the verb list and carries a real cost. Re-running against the tree once it widened caught the live miss above and also misread a passage in
|
|
56
|
+
The article gate is looser than the verb list and carries a real cost. Re-running against the tree once it widened caught the live miss above and also misread a passage in `canon/context/standards/destinations.md` naming a real subset, a standard outside the retired `standards/bundled/` fan-out, as a claim about the whole standards catalog. The qualifying adjective there fills the same optional-word slot `sixty-one shipped skills` needs to match at all, and no syntactic rule tells a qualifier that narrows a catalog from one that only restates it. The finding could not be closed by correcting a figure, since the sentence was true when the corpus held it, only unmarked as a past state, which is the class the date exclusion already reads past. Naming the moment, the same way `canon/ARCHITECTURE.md` dates its own figures, closed it with no change to the matcher.
|
|
57
57
|
|
|
58
58
|
## What it does not measure
|
|
59
59
|
|
|
@@ -61,7 +61,7 @@ A delta phrased as a transition (`from fourteen to fifteen`), a fraction (`thirt
|
|
|
61
61
|
|
|
62
62
|
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 70 rules under governance/rules/ and consumes 62 into .claude/rules/` is read for its 70 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.
|
|
63
63
|
|
|
64
|
-
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.
|
|
64
|
+
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.
|
|
65
65
|
|
|
66
66
|
The wider check over prose restatements is deliberately out of reach here. `canon gov restated` already records a parser over prose as rejected, and this sweep reaches a number with a command behind it rather than two sentences a reader has to judge as agreeing.
|
|
67
67
|
|
|
@@ -5,7 +5,7 @@ description: Generating a static index over the toolkit checkout's own design su
|
|
|
5
5
|
|
|
6
6
|
# Design board
|
|
7
7
|
|
|
8
|
-
`canon design board [--out <path>]` generates a static page set indexing five design surfaces and reports the path a reader opens with `canon serve`. Like `canon design regen`, it runs against the toolkit checkout the CLI resolves its own root from, never against a target project's own files: a target holds none of the sources below, since none of
|
|
8
|
+
`canon design board [--out <path>]` generates a static page set indexing five design surfaces and reports the path a reader opens with `canon serve`. Like `canon design regen`, it runs against the toolkit checkout the CLI resolves its own root from, never against a target project's own files: a target holds none of the sources below, since none of `canon/DESIGN.md`, `canon/wireframes/`, `web/`, or the gitignored `.canon/` records ship with the published package. Running the installed CLI from inside a checkout of this project prints a mismatch warning when the caller's working directory disagrees with the root it resolved.
|
|
9
9
|
|
|
10
10
|
Each panel reads what is already on disk and reports its own missing source rather than failing the run, so an absent build or an empty corpus renders an empty-state message instead of a broken frame.
|
|
11
11
|
|
|
@@ -20,9 +20,9 @@ canon serve .canon/review/board
|
|
|
20
20
|
|
|
21
21
|
## Panels
|
|
22
22
|
|
|
23
|
-
- **Tokens** renders
|
|
23
|
+
- **Tokens** renders `canon/DESIGN.md` through the same renderer `canon design render` uses, rather than a second one.
|
|
24
24
|
- **Surfaces** iframes the built landing page from `web/dist/` and a teach workspace from `.canon/teach/`, copying each whole into the board's own tree. Either reports its own missing build or absent workspace rather than rendering a broken frame.
|
|
25
|
-
- **Wireframes** renders each of the six files under
|
|
25
|
+
- **Wireframes** renders each of the six files under `canon/wireframes/` as-is inside a `<pre>`, beside a line naming the surface it describes.
|
|
26
26
|
- **Past candidates** lists an arm capture image per folder under `.canon/review/evidence/`, and states the corpus carries none rather than rendering an empty grid.
|
|
27
27
|
- **Components** iframes the gallery built by `bun run web:gallery`, a second Astro config at `web/gallery.config.mjs` reading `web/gallery-src/` and writing `web/gallery-dist/`. That config's `srcDir` is never read by `web:build`'s own config, so the gallery never reaches the published `web/dist/`. The gallery page renders every component under `web/src/components/` except two whose props carry no defaults, which it names rather than filling with invented data. Reports a missing gallery build rather than rendering a broken frame.
|
|
28
28
|
|
package/docs/agents/docs.md
CHANGED
|
@@ -5,10 +5,10 @@ description: How canon docs resolves the toolkit's own reference surface from an
|
|
|
5
5
|
|
|
6
6
|
# Docs
|
|
7
7
|
|
|
8
|
-
`canon docs` emits the toolkit's own reference docs so an agent in a target project can orient without the toolkit source checked out. The CLI resolves `docs/` and
|
|
8
|
+
`canon docs` emits the toolkit's own reference docs so an agent in a target project can orient without the toolkit source checked out. The CLI resolves `docs/` and `canon/context/` from its install root, and which of the two it finds depends on how the CLI was installed. A registry install carries `docs/` alone, since `.claude/` is not published. A clone or a linked worktree carries both.
|
|
9
9
|
|
|
10
|
-
- `canon docs list [--json]` lists the downstream catalog: the consumer-facing `docs/` surface plus per-domain narrative from
|
|
11
|
-
- `canon docs <topic>` prints one doc to stdout, resolved by exact name from `docs/` first, then
|
|
10
|
+
- `canon docs list [--json]` lists the downstream catalog: the consumer-facing `docs/` surface plus per-domain narrative from `canon/context/` when that root is present. Toolkit-internal context entries (`ci`, `development`, `sandbox`) are dropped. From a registry install the context section is absent rather than empty.
|
|
11
|
+
- `canon docs <topic>` prints one doc to stdout, resolved by exact name from `docs/` first, then `canon/context/`. Any doc the install carries is reachable by name, including the toolkit-internal topics the list omits.
|
|
12
12
|
|
|
13
13
|
## How a name resolves
|
|
14
14
|
|
package/docs/agents/indexes.md
CHANGED
|
@@ -48,4 +48,4 @@ Exit codes: `0` no errors, `1` root not a directory, or a folder failed frontmat
|
|
|
48
48
|
|
|
49
49
|
A git-ignored indexed folder, such as `.canon/tasks/` or `.canon/memory/`, never appears in the output. `listIndexes` filters candidates through `git check-ignore` the same way `regen`'s whole-repo walk does, which is the right default for a documentation lookup since those rows are session scratch, but it is a gap against `regen`'s positional-path mode, which bypasses that filter for those two folders.
|
|
50
50
|
|
|
51
|
-
For the system rationale, frontmatter contract, when to adopt, and bootstrap path, see
|
|
51
|
+
For the system rationale, frontmatter contract, when to adopt, and bootstrap path, see `canon/context/indexes.md`.
|
|
@@ -158,9 +158,9 @@ Use `--json` for the machine-readable report and `--exit-code` to fail a CI job.
|
|
|
158
158
|
and missing files are both excluded from that exit code: a project-authored
|
|
159
159
|
rule never converges, and a sync that added a missing one silently changes
|
|
160
160
|
what the project is governed by, which stays a separate command an operator
|
|
161
|
-
chooses to run. Attribution reads `canon/config/config.json` first
|
|
162
|
-
back to `.claude/canon/config.json
|
|
163
|
-
|
|
161
|
+
chooses to run. Attribution reads `canon/config/config.json` first, which every
|
|
162
|
+
install and sync now writes, and falls back to `.claude/canon/config.json` for
|
|
163
|
+
a target that has not moved.
|
|
164
164
|
|
|
165
165
|
A target installed before stamping shipped has no such file, and neither does
|
|
166
166
|
that fallback do anything to migrate it. A target stamped before the file
|
|
@@ -377,7 +377,7 @@ toolkit shipped and the target renamed goes unmatched, the same limit the
|
|
|
377
377
|
|
|
378
378
|
`migrations` names a proposal-only skill with a live case in this target. It
|
|
379
379
|
fires on a `CLAUDE.md` past 250 lines for `migration-claude-md`, and on a `docs/` folder
|
|
380
|
-
holding markdown with no populated
|
|
380
|
+
holding markdown with no populated `canon/context/` for `migration-context`.
|
|
381
381
|
Each entry carries the skill name and the measurement behind it, so a consumer
|
|
382
382
|
can check the proposal before running it. Without the field both skills are
|
|
383
383
|
documented and unreachable from any report.
|
|
@@ -28,7 +28,7 @@ Under `--json` the record holds stdout alone and the frame still renders on stde
|
|
|
28
28
|
|
|
29
29
|
## The map it reads
|
|
30
30
|
|
|
31
|
-
The map sits at `.claude/canon/pr-labels.toml` and carries two tables. `[domains]` keys a label name to the path prefixes that earn it, and `[declined]` keys a reason to the prefixes that earn no label on purpose.
|
|
31
|
+
The map sits at `canon/config/pr-labels.toml`, falling back to `.claude/canon/pr-labels.toml` for a project that has not moved, and carries two tables. `[domains]` keys a label name to the path prefixes that earn it, and `[declined]` keys a reason to the prefixes that earn no label on purpose.
|
|
32
32
|
|
|
33
33
|
```toml
|
|
34
34
|
[domains]
|
|
@@ -48,7 +48,7 @@ Most carry two spellings, the one a surface authors at and the one it reaches a
|
|
|
48
48
|
|
|
49
49
|
`CLAUDE.md` is matched as a whole path rather than as a prefix, because a prefix reaches nothing that sits in no folder. A nested `docs/CLAUDE.md` stays informational.
|
|
50
50
|
|
|
51
|
-
The set is data at `src/autoship/paths.ts`. That makes it permanently exempt from any later design that folds a machine-parsed list back into the surface citing it, per the machine-parsed clause in
|
|
51
|
+
The set is data at `src/autoship/paths.ts`. That makes it permanently exempt from any later design that folds a machine-parsed list back into the surface citing it, per the machine-parsed clause in `canon/ARCHITECTURE.md`.
|
|
52
52
|
|
|
53
53
|
## Exit codes and refusals
|
|
54
54
|
|
package/docs/agents/routing.md
CHANGED
|
@@ -5,7 +5,7 @@ description: Reading per CLAUDE.md section how many bullets name a path, what co
|
|
|
5
5
|
|
|
6
6
|
# Routing report
|
|
7
7
|
|
|
8
|
-
`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.
|
|
8
|
+
`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. `canon/ARCHITECTURE.md` names two further axes, conditional presence and updatability, that this verb does not check.
|
|
9
9
|
|
|
10
10
|
```bash
|
|
11
11
|
canon claude routing
|
|
@@ -34,7 +34,7 @@ A bullet is path-scoped here when it names a path. That is evidence for the tier
|
|
|
34
34
|
|
|
35
35
|
A backticked token counts when it carries a separator or an alphabetic extension, which admits `src/cli.ts` and `cspell.json` while leaving a flag, a bare word, and a version string out.
|
|
36
36
|
|
|
37
|
-
A shape counts as the folder above its placeholder.
|
|
37
|
+
A shape counts as the folder above its placeholder. `canon/context/<domain>.md` names `canon/context/` and nothing narrower, so dropping the token whole would report the section carrying it as naming no path at all. A placeholder opening the first segment has no openable prefix and is dropped.
|
|
38
38
|
|
|
39
39
|
## When a rule counts as covering it
|
|
40
40
|
|
|
@@ -48,7 +48,7 @@ A `path` is anchored on the whole backticked span rather than on a trailing patt
|
|
|
48
48
|
|
|
49
49
|
A rule body is full of backticked spans carrying a slash, and almost none of them names a file in this tree. The stage declines four shapes outright.
|
|
50
50
|
|
|
51
|
-
- A placeholder or glob segment describes a shape rather than naming a file:
|
|
51
|
+
- A placeholder or glob segment describes a shape rather than naming a file: `canon/context/<domain>.md`, `standards/<name>.md`, `app/**/route.ts`, `${CLAUDE_SKILL_DIR}/../../standards/<name>.md`.
|
|
52
52
|
- A bare filename names a convention: `route.ts`, `manifest.toml`, `components.json`, `playwright.config.ts`. A bare name is read as a citation only when it matches a rule filename, which is how `562-session.md` points at `555-tasks.md`.
|
|
53
53
|
- A span carrying no file extension is a folder or a module specifier: `src/pages/`, `next/font`, `try/except`, `react-hooks/set-state-in-effect`, `oven-sh/setup-bun@v2`, `@/lib/utils`.
|
|
54
54
|
- A fenced block displays a path rather than pointing at one.
|
package/docs/agents/sandbox.md
CHANGED
|
@@ -39,7 +39,7 @@ The verdict `state` is `pass`, `fail`, or `unchecked`. An arm with no `expect.to
|
|
|
39
39
|
|
|
40
40
|
Omitting `--writes`, `--escapes`, or `--envelope` does not silently drop the assertion kinds that need them. Write scope, escape scope, the turn ceiling, and the reply assertion report as unchecked and appear in the count, so the standalone command cannot claim more coverage than it had. Supplying `--escapes` without `--escapes-watched` reports the same way: a zero-escape result with no root confirmed watched is unmeasured rather than a pass. A verdict never reports `pass` with zero assertions.
|
|
41
41
|
|
|
42
|
-
An arm declaring `escape_scope` asserts a bound on `run.sh`'s own escape watch rather than on the sandbox tree. `write_scope` skips when the run wrote nothing, since a required output missing is itself a finding, but `escape_scope` passes on zero escapes outright, since a clean run producing none is the expected outcome for a destination nothing requires a skill to touch, provided `--escapes-watched` confirms a root held something to watch. Declaring `escape_scope = []` asserts that a correct run reaches none of the watched destinations at all.
|
|
42
|
+
An arm declaring `escape_scope` asserts a bound on `run.sh`'s own escape watch rather than on the sandbox tree. `write_scope` skips when the run wrote nothing, since a required output missing is itself a finding, but `escape_scope` passes on zero escapes outright, since a clean run producing none is the expected outcome for a destination nothing requires a skill to touch, provided `--escapes-watched` confirms a root held something to watch. Declaring `escape_scope = []` asserts that a correct run reaches none of the watched destinations at all. `canon/context/sandbox/overview.md` names what the watch reaches and what it cannot.
|
|
43
43
|
|
|
44
44
|
An envelope that parses but carries no `result` field skips the reply assertion the same way an absent file does. An envelope carrying an empty `result` fails it, since a run that returned no text is a finding rather than a gap in the input.
|
|
45
45
|
|
package/docs/agents/scripting.md
CHANGED
|
@@ -38,7 +38,7 @@ array rather than skipping the standard behind it.
|
|
|
38
38
|
|
|
39
39
|
`canon claude seeds list` reads the same plan `canon claude init` applies, so the
|
|
40
40
|
listing and the install cannot disagree. It now reports
|
|
41
|
-
|
|
41
|
+
`canon/context/index.md`, which `init` has always installed and the listing
|
|
42
42
|
never named, and it emits the project-level `CLAUDE.md` last rather than first.
|
|
43
43
|
|
|
44
44
|
`canon gov list` reports each stack's rules already expanded. A stack entry names
|
|
@@ -91,4 +91,4 @@ The verb answers only when someone runs it, and a report read is not a report ac
|
|
|
91
91
|
|
|
92
92
|
Two cases fall outside the range. An uncommitted edit in the working tree is not history yet, so a body changed and left unstaged reports as unmoved. A target project loads the plugin from a marketplace cache with no repository behind it, where the verb refuses and names the absent history rather than reporting a clean tree.
|
|
93
93
|
|
|
94
|
-
Exit codes are `0` when history was read, whether or not a body moved, and `1` when the question could not be answered. An absent shipped corpus, an absent repository, and a ref matching no commit each refuse with their own reason on stderr. A command exiting zero on a question it never answered is the failure
|
|
94
|
+
Exit codes are `0` when history was read, whether or not a body moved, and `1` when the question could not be answered. An absent shipped corpus, an absent repository, and a ref matching no commit each refuse with their own reason on stderr. A command exiting zero on a question it never answered is the failure `canon/ARCHITECTURE.md` already records against two skills, which is why no path here reports an empty result in place of a refusal.
|
|
@@ -23,13 +23,13 @@ canon claude skills reach ~/repos/my-project
|
|
|
23
23
|
|
|
24
24
|
## The defect it reads for
|
|
25
25
|
|
|
26
|
-
A plugin skill installs into a project and the toolkit's own tree is not there. A body naming
|
|
26
|
+
A plugin skill installs into a project and the toolkit's own tree is not there. A body naming `canon/context/transcripts.md` resolves for a session running in this repository and sends every other reader to nothing, and no stage asked the question until this one. The shape is wider than one folder: a seed naming a standard with no route and a machine-readable field naming a toolkit-only path are the same claim, true here and false in a target.
|
|
27
27
|
|
|
28
28
|
## What counts as a citation
|
|
29
29
|
|
|
30
30
|
A backticked token carrying a separator and an extension, which is how every body spells a path it means a reader to open. Three forms are skipped by construction.
|
|
31
31
|
|
|
32
|
-
- A placeholder such as
|
|
32
|
+
- A placeholder such as `canon/context/<domain>.md`, which names a shape rather than a file
|
|
33
33
|
- A path resolved through `${CLAUDE_SKILL_DIR}`, which is self-contained wherever the plugin loads
|
|
34
34
|
- A sibling named relatively, such as `references/labels.md`, which matches no authoring root and travels with the body
|
|
35
35
|
|
|
@@ -43,7 +43,7 @@ A cited path counts when it sits under an authoring root no install channel deli
|
|
|
43
43
|
|
|
44
44
|
`src/`, `scripts/`, and bare `docs/` are deliberately outside the list. A body naming one of those is describing the reader's own tree, so listing them reports a correct citation on every run and buries the finding under the pass.
|
|
45
45
|
|
|
46
|
-
|
|
46
|
+
`canon/context/` joins them when the corpus read is a project's own. A seed put those entries there and the project owns them afterward, so a body under `.claude/skills/` naming one points at a file its reader holds. The seed disowning below cannot answer that in a project, since it reads a `tooling/` tree only the toolkit carries.
|
|
47
47
|
|
|
48
48
|
A path a seed installs is disowned twice, under its own name and under the folder spelling it takes once a project splits the entry. A domain that outgrows one file becomes `<domain>/`, which is still the entry the seed delivered, so reporting the split form would fail a project for growing.
|
|
49
49
|
|
|
@@ -52,7 +52,7 @@ A path a seed installs is disowned twice, under its own name and under the folde
|
|
|
52
52
|
A correct citation and a defective one are the same string, and the sentence around it is the difference. A citation counts as decided when its line names the toolkit as the owner, matching the bodies that already spell it that way. The repair for a finding is to say whose copy the path is, never to delete the citation, since the paths name real documents a reader wants.
|
|
53
53
|
|
|
54
54
|
```markdown
|
|
55
|
-
Read
|
|
55
|
+
Read `canon/context/indexes.md` from the toolkit if context on the system is needed.
|
|
56
56
|
```
|
|
57
57
|
|
|
58
58
|
A line mentioning the toolkit for an unrelated reason exempts a citation on it. That is the accepted cost of a word over a notation every future body would have to learn.
|
package/docs/target-projects.md
CHANGED
|
@@ -8,7 +8,7 @@ category: Agent surface
|
|
|
8
8
|
|
|
9
9
|
How a project outside this repo consumes the toolkit across its lifecycle. Three phases: scaffold once, add a domain later when a new need appears, and sync when the upstream toolkit moves.
|
|
10
10
|
|
|
11
|
-
This doc stays at the narrative layer. For command flags and JSON shapes, see [agents](agents/index.md). For per-domain mechanics, see each
|
|
11
|
+
This doc stays at the narrative layer. For command flags and JSON shapes, see [agents](agents/index.md). For per-domain mechanics, see each `canon/context/<domain>.md`.
|
|
12
12
|
|
|
13
13
|
## Getting the skills
|
|
14
14
|
|
|
@@ -57,7 +57,7 @@ The chain is:
|
|
|
57
57
|
|
|
58
58
|
- `canon init` installs base tooling, Claude seeds, and governance rules into `.claude/rules/` in the same pass
|
|
59
59
|
- `canon tooling sync <stack> --write` adds stack-specific deps, scripts, and gitignore entries
|
|
60
|
-
- The agent reads `canon tooling reference <stack>` (plus parents) as its audit context, follows it to generate eslint, vitest, playwright configs and the stack's setup script, and extends
|
|
60
|
+
- The agent reads `canon tooling reference <stack>` (plus parents) as its audit context, follows it to generate eslint, vitest, playwright configs and the stack's setup script, and extends `canon/context/ci.md` and `canon/context/development.md` per the reference's extend sections <!-- audit-ignore-citations: canon/context/development.md -->
|
|
61
61
|
- `setup-verify` runs the installed `package.json` scripts (lint, typecheck, check, test, build) and reports pass or fail
|
|
62
62
|
- `setup-indexes` bootstraps the `index.md` system over the project's own documentation folders, confirming candidate folders with the operator rather than running unattended
|
|
63
63
|
|
|
@@ -65,14 +65,14 @@ The chain stops at the project edge. `repo-metadata` and `git-commit` also ship,
|
|
|
65
65
|
|
|
66
66
|
Run `canon:setup-smoke` by hand once `setup-verify` passes, for the heavier server smoke, end-to-end, and screenshot pass, since the same flakiness reasons that excluded those stages from `setup-verify` keep it out of this unattended chain too.
|
|
67
67
|
|
|
68
|
-
Keep the `## Scripts` table in
|
|
68
|
+
Keep the `## Scripts` table in `canon/context/development.md` current as scripts are added. Base tooling seeds that entry with the commands it installs, and each stack reference extends the table. `project-commands` reads it to start the app or run a check on request, so a command missing from the table cannot be run that way. A project whose entry outgrew one file and split into `canon/context/development/` keeps the table in `overview.md`, which is where the skill looks next. <!-- audit-ignore-citations: canon/context/development.md -->
|
|
69
69
|
|
|
70
70
|
### From scaffold to first feature
|
|
71
71
|
|
|
72
72
|
Scaffold installs tooling and seeds. It does not fill the planning docs or the design system. Complete those before the first feature session:
|
|
73
73
|
|
|
74
|
-
1. Fill
|
|
75
|
-
2. For a UI project, invoke `canon:design-extract` to draft
|
|
74
|
+
1. Fill `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md`. The seed provides the files, the scope and decisions are yours to write.
|
|
75
|
+
2. For a UI project, invoke `canon:design-extract` to draft `canon/DESIGN.md`. With no UI code yet it takes the greenfield path and proposes tokens from the requirements and a `## Personality` section. Skip for non-UI projects.
|
|
76
76
|
3. Optionally invoke `canon:draft-diagram` to draft entries under `.canon/diagrams/` from the architecture and the requirements. One file per diagram kind, so a later refresh of one kind leaves the others untouched. It renders each diagram it writes to verify the layout, which downloads the Mermaid CLI on first use and takes about 15 seconds.
|
|
77
77
|
4. Start the feature loop. See [AI workflow](workflow/ai-workflow.md) for the per-feature sequence.
|
|
78
78
|
|
|
@@ -80,7 +80,7 @@ A machine without a renderer still gets the diagrams and is told which check was
|
|
|
80
80
|
|
|
81
81
|
Each diagram entry records the commit and date it was last verified against, and nothing maintains that record for you. The folder is redrawn on demand rather than swept on every ship, so `verified` carries the whole signal: an entry whose date sits far behind your branch is due a read, and no pass will name which one. Run `canon:draft-diagram` again when the code a kind is drawn from moves.
|
|
82
82
|
|
|
83
|
-
|
|
83
|
+
`canon/ARCHITECTURE.md` carries the same mechanism on the same ship. `canon:docs-fold` anchors a decision it amends to the paths that decision cites, and reports an anchored decision whose cited path the branch touched.
|
|
84
84
|
|
|
85
85
|
### Stack decision
|
|
86
86
|
|
|
@@ -208,7 +208,7 @@ The report opens by naming the binary running it. The installed version reads ag
|
|
|
208
208
|
|
|
209
209
|
A `stale` file still matches what the toolkit installed, so the update is mechanical. A `customized` file carries local edits, so taking the upstream version is a decision and `canon:seed-sync` is the tool for it. A `stranded` file sits where an older toolkit installed it and the toolkit has since moved, which is a relocation the report names but no command runs.
|
|
210
210
|
|
|
211
|
-
That attribution comes from `canon/config/config.json
|
|
211
|
+
That attribution comes from `canon/config/config.json`, which every install and sync now writes, falling back to `.claude/canon/config.json` for a target stamped before that move. A target stamped before that path shipped is read from the retired `.claude/canon.json` instead, reported rather than migrated. Governance records a hash per installed file, plus the stack `canon gov install` was given, and tooling records the stack chain it resolved instead of any file hash, since its install runs no per-file walk to attribute.
|
|
212
212
|
|
|
213
213
|
Each domain holds its own toolkit commit, so syncing governance today does not move the revision tooling measures against, and each domain reports the upstream commits touching its own source path. Running any sync stamps that domain, and the report names the ones still unstamped.
|
|
214
214
|
|
|
@@ -262,7 +262,7 @@ Standards take no part in that run. Nothing installed them, so there is no copy
|
|
|
262
262
|
|
|
263
263
|
### Targeted
|
|
264
264
|
|
|
265
|
-
- Claude seed docs such as `CLAUDE.md` and
|
|
265
|
+
- Claude seed docs such as `CLAUDE.md` and `canon/REQUIREMENTS.md`: invoke `canon:seed-sync`. The skill splits each file into a preamble (between the H1 and the first H2) plus one part per `##` section, then diffs part by part and proposes per-part edits. User customizations are preserved.
|
|
266
266
|
- Governance rules already installed: `canon gov sync <path>` diffs and applies, and never adds new rules. A rule your recorded stack lists reports as `missing` instead.
|
|
267
267
|
- Tooling configs and seeds: `canon tooling <stack> <path>` overwrites golden configs and merges seeds
|
|
268
268
|
- Reference docs for a stack: `canon tooling reference <stack>` reads and never writes, so there is nothing to sync
|
|
@@ -272,7 +272,7 @@ Use a targeted entry point when only one surface moved upstream. Use the catch-a
|
|
|
272
272
|
|
|
273
273
|
## Verify a sync
|
|
274
274
|
|
|
275
|
-
Before running a sync against a real project, run the relevant sandbox scenario. The sandbox provisions a representative project state and routes `SANDBOX_SCENARIO=sync` through the domain flow. See [sandbox](
|
|
275
|
+
Before running a sync against a real project, run the relevant sandbox scenario. The sandbox provisions a representative project state and routes `SANDBOX_SCENARIO=sync` through the domain flow. See [sandbox](../canon/context/sandbox/index.md) for the scenario catalog and routing patterns.
|
|
276
276
|
|
|
277
277
|
## Scenarios
|
|
278
278
|
|
|
@@ -326,5 +326,5 @@ Sync also refuses a target whose working tree is dirty, so commit or stash befor
|
|
|
326
326
|
|
|
327
327
|
- [agents](agents/index.md): CLI flags, exit codes, and JSON output shapes
|
|
328
328
|
- [AI workflow](workflow/ai-workflow.md): feature-development loop inside a toolkit-managed project
|
|
329
|
-
- [tooling](
|
|
330
|
-
- [sandbox](
|
|
329
|
+
- [tooling](../canon/context/tooling.md), [governance](../canon/context/governance/index.md), [claude plugin](../canon/context/claude-plugin/index.md), [indexes](../canon/context/indexes.md), [snippets](../canon/context/snippets.md), [standards](../canon/context/standards/index.md): per-domain mechanics
|
|
330
|
+
- [sandbox](../canon/context/sandbox/index.md): scenario catalog for verifying domain flows
|
|
@@ -12,15 +12,17 @@ A concise reference for when to reach for which tool, organized by what you're t
|
|
|
12
12
|
|
|
13
13
|
## Documents
|
|
14
14
|
|
|
15
|
-
Project docs split across
|
|
15
|
+
Project docs split across three roots at the project root. What the project authors and commits lives in `canon/`, what Claude Code reads lives in `.claude/`, and every gitignored session record lives in `.canon/`, which a single ignore entry covers.
|
|
16
16
|
|
|
17
17
|
```plaintext
|
|
18
|
-
|
|
18
|
+
canon/
|
|
19
19
|
├── REQUIREMENTS.md ← goals, non-goals, MVP scope
|
|
20
20
|
├── ARCHITECTURE.md ← technical design decisions
|
|
21
21
|
├── DESIGN.md ← visual intent and token decisions (UI projects)
|
|
22
|
-
├──
|
|
23
|
-
|
|
22
|
+
├── wireframes/ ← ASCII wireframes: layout, UI copy, and interaction rules (UI projects)
|
|
23
|
+
└── context/ ← per-domain narrative loaded on demand via index.md
|
|
24
|
+
|
|
25
|
+
.claude/
|
|
24
26
|
└── rules/ ← path-scoped governance rules, written by canon gov install
|
|
25
27
|
|
|
26
28
|
.canon/
|
|
@@ -31,9 +33,9 @@ Project docs split across two roots at the project root, on one mechanical line:
|
|
|
31
33
|
└── tmp/ ← deletable scratch, safe to remove without loss
|
|
32
34
|
```
|
|
33
35
|
|
|
34
|
-
A project scaffolded before the move keeps its records under `.claude/`, and every command reads either root. `canon migrate records` moves one project across and repoints what cites it, and `canon migrate record-tree` follows it to reach the citations inside the records themselves, which the first verb passes over because it enumerates through git.
|
|
36
|
+
A project scaffolded before the move keeps its records under `.claude/`, and every command reads either root. `canon migrate records` moves one project across and repoints what cites it, and `canon migrate record-tree` follows it to reach the citations inside the records themselves, which the first verb passes over because it enumerates through git. A project scaffolded before the surface move keeps its context, wireframes, and loose documents under `.claude/` the same way, and `canon migrate surface-roots` moves those to `canon/` with the history following each file.
|
|
35
37
|
|
|
36
|
-
Three tiers of context load with different cost: always-loaded (root `CLAUDE.md`,
|
|
38
|
+
Three tiers of context load with different cost: always-loaded (root `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`), path-scoped lazy (`.claude/rules/<scope>.md` with `paths:` glob), and on-demand lookup (`canon/context/<domain>.md`, or `canon/context/<domain>/` once a domain outgrows one file, discovered via `canon/context/index.md`). See [the context model](../../canon/context/context-model.md) for the full picture.
|
|
37
39
|
|
|
38
40
|
Run `canon init` to seed the `.claude/` directory, a root `CLAUDE.md` file, and `.claude/rules/` in one pass. `canon init` chains claude init and governance install. Claude Code auto-loads every file in `.claude/rules/` at session start, applying always-on rules unconditionally and path-scoped rules to files matching their `paths:` glob.
|
|
39
41
|
|
|
@@ -84,7 +86,7 @@ When features are independent, run them in parallel instead of sequentially. Use
|
|
|
84
86
|
|
|
85
87
|
To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `canon:role-orchestrator`. It holds the cross-feature call, plans each feature itself or dispatches a cold planner under `canon:role-planner` to write the plan, refills the ready queue so a free worker never waits, and reviews each worker's PR with `canon:review-pr`, then tells the session holding that branch to run `canon:review-address` whenever the pass posted a finding at any severity, which is the same threshold `canon:review-pr` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
|
|
86
88
|
|
|
87
|
-
Execution order comes off `.canon/tasks/priority.md` and nothing sequences work into versions. Scope stays in
|
|
89
|
+
Execution order comes off `.canon/tasks/priority.md` and nothing sequences work into versions. Scope stays in `canon/REQUIREMENTS.md` as a statement of what is wanted, and it reaches the board as discrete tasks the orchestrator orders by readiness.
|
|
88
90
|
|
|
89
91
|
Run one orchestrator at a time. The board is gitignored, so a second session reads none of the first one's writes and the two collide on labels and archives.
|
|
90
92
|
|
|
@@ -157,7 +159,7 @@ The list stays written in the skill body as the fallback for a target whose inst
|
|
|
157
159
|
|
|
158
160
|
#### Memory in the chain
|
|
159
161
|
|
|
160
|
-
`git-ship` runs its verify gate and then opens on `memory-capture`, which sends what the session learned to the surface that owns it. `autoship` reaches the same step by invoking that skill at its Step 8 rather than restating the order. A fact about a domain carrying an entry in
|
|
162
|
+
`git-ship` runs its verify gate and then opens on `memory-capture`, which sends what the session learned to the surface that owns it. `autoship` reaches the same step by invoking that skill at its Step 8 rather than restating the order. A fact about a domain carrying an entry in `canon/context/index.md` is routed to that entry, and `docs-fold` folds it in on the next step, so it ships in the same pull request. Anything no entry owns stays a file in `.canon/memory/`.
|
|
161
163
|
|
|
162
164
|
Capture leads rather than trails because a routed fact edits a tracked file, which has to reach the branch before the commit steps run.
|
|
163
165
|
|
|
@@ -202,7 +204,7 @@ This section is the corpus the coverage claim is measured against: every name `c
|
|
|
202
204
|
| `canon:setup-plugins` | On a new machine, to install the community and official plugins user-scoped |
|
|
203
205
|
| `canon:setup-verify` | After the agent generates configs, to run the installed scripts and report pass or fail |
|
|
204
206
|
| `canon:setup-smoke` | After `setup-verify` passes, to check the dev and preview servers, end-to-end tests, and the screenshot harness |
|
|
205
|
-
| `canon:design-extract` | Before the first UI feature, to draft
|
|
207
|
+
| `canon:design-extract` | Before the first UI feature, to draft `canon/DESIGN.md` |
|
|
206
208
|
| `canon:draft-diagram` | Once the architecture is written, to draft per-kind entries under `.canon/diagrams/` |
|
|
207
209
|
| `canon:repo-metadata` | When the GitHub About text, homepage, or topics may have drifted, to reconcile them against the README |
|
|
208
210
|
|
|
@@ -281,7 +283,7 @@ This section is the corpus the coverage claim is measured against: every name `c
|
|
|
281
283
|
| -------------------------------- | ---------------------------------------------------------------------------------- |
|
|
282
284
|
| `canon:seed-sync` | After a toolkit update, to reconcile installed seeds without losing customizations |
|
|
283
285
|
| `canon:migration-claude-md` | When `CLAUDE.md` grew past what always-load context should carry |
|
|
284
|
-
| `canon:migration-context` | When `docs/` holds agent-flavored files belonging in
|
|
286
|
+
| `canon:migration-context` | When `docs/` holds agent-flavored files belonging in `canon/context/` |
|
|
285
287
|
| `canon:migration-superseded` | When a drift report names a `.claude/` file a folder has replaced |
|
|
286
288
|
| `canon:migration-standards-drop` | When the project still holds an installed `.claude/standards/` tree |
|
|
287
289
|
| `canon:canon-feedback-file` | When something in the toolkit is broken, missing, or off |
|
|
@@ -297,8 +299,8 @@ This section is the corpus the coverage claim is measured against: every name `c
|
|
|
297
299
|
| `canon:create-snippet` | For a reusable prompt |
|
|
298
300
|
| `canon:create-standard` | For a new authoring convention |
|
|
299
301
|
| `canon:draft-docs` | For a brand-new `docs/*.md` page, drafted against `standards/docs.md` |
|
|
300
|
-
| `canon:draft-context` | For a brand-new
|
|
301
|
-
| `canon:draft-wireframes` | For a brand-new
|
|
302
|
+
| `canon:draft-context` | For a brand-new `canon/context/<domain>.md` entry, drafted against `standards/context.md` |
|
|
303
|
+
| `canon:draft-wireframes` | For a brand-new `canon/wireframes/<surface>.md` file, drafted against `standards/wireframes.md` |
|
|
302
304
|
| `canon:draft-figure` | For a hand-drawn figure inside an existing doc, drafted against `standards/figures.md` and rendered through Mermaid or freehand SVG |
|
|
303
305
|
| `canon:draft-readme` | For a project's `README.md`, drafted against `standards/readme.md` |
|
|
304
306
|
| `canon:bash-script` | For an interactive, human-facing shell tool |
|
|
@@ -335,4 +337,4 @@ review finds → Session 2 (fix alongside review, before ship)
|
|
|
335
337
|
|
|
336
338
|
## Snippets
|
|
337
339
|
|
|
338
|
-
For the full list of snippets that complement this workflow, see
|
|
340
|
+
For the full list of snippets that complement this workflow, see `canon/context/snippets.md`.
|
|
@@ -222,7 +222,7 @@ Two tiers hold work at different altitudes.
|
|
|
222
222
|
- Edits: a few lines, done immediately with no ceremony.
|
|
223
223
|
|
|
224
224
|
Nothing above these sequences work into versions. Scope is stated in
|
|
225
|
-
|
|
225
|
+
`canon/REQUIREMENTS.md` and reaches the board as discrete tasks, so why one
|
|
226
226
|
task runs before its neighbors is on its row and why one group of work runs
|
|
227
227
|
before another is carried nowhere at all.
|
|
228
228
|
|
|
@@ -263,4 +263,4 @@ port-collision detail.
|
|
|
263
263
|
|
|
264
264
|
- [Claude Code and git worktrees](../../wiki/claude/claude-worktrees.md) for the isolation and fan-out mechanics
|
|
265
265
|
- [Claude Code subagents](../../wiki/claude/claude-subagents.md) for in-session parallelism without worktrees
|
|
266
|
-
-
|
|
266
|
+
- `canon/context/claude-plugin/skill-strategy.md` for how the skills in the loop are categorized
|
|
@@ -14,15 +14,15 @@ Two tools anchor tier 1 and tier 2. Stitch is the agent-addressable default thro
|
|
|
14
14
|
|
|
15
15
|
## Tier 0: prose only
|
|
16
16
|
|
|
17
|
-
The default.
|
|
17
|
+
The default. `canon/DESIGN.md` holds visual intent as prose plus token tables for color, typography, spacing, borders, motion, and iconography. `.claude/WIREFRAMES.md` holds ASCII layouts.
|
|
18
18
|
|
|
19
19
|
Claude Code reads both and writes the implementation. Works for CLI tools, internal dashboards, admin panels, and backend-focused projects.
|
|
20
20
|
|
|
21
21
|
### Seed shape
|
|
22
22
|
|
|
23
|
-
The toolkit seed in `tooling/claude/seeds
|
|
23
|
+
The toolkit seed in `tooling/claude/seeds/canon/DESIGN.md` ships a token-table template with a starting set of roles, and `standards/design.md` carries the same tables under `## Template` with placeholder rows. The column headers are what the renderer parses, so they stay verbatim in either, while the rows and values are the project's own.
|
|
24
24
|
|
|
25
|
-
The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from
|
|
25
|
+
The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `canon/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/review/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design.md`.
|
|
26
26
|
|
|
27
27
|
A project wanting the toolkit's own values rather than its own runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying the token set as custom properties and two components built on them. That file is toolkit-owned and `canon design sync` refreshes it, so a project overrides a value in `.claude/design/project/` instead, which sync never touches. Nothing arrives without that install, and the two channels are independent: a record drafted by the extract skill is the project's own, and the installed stylesheet is the toolkit's.
|
|
28
28
|
|
|
@@ -35,7 +35,7 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
|
|
|
35
35
|
|
|
36
36
|
### Skills
|
|
37
37
|
|
|
38
|
-
- `canon:design-extract` to draft
|
|
38
|
+
- `canon:design-extract` to draft `canon/DESIGN.md`, from existing project signals or from requirements alone on day one
|
|
39
39
|
- `canon:ui-test` for e2e test generation after UI changes
|
|
40
40
|
- `canon:ux-audit` for UX gap detection on existing surfaces
|
|
41
41
|
- `canon:ux-measure` for what a running surface costs to paint, read against published thresholds
|
|
@@ -64,7 +64,7 @@ All three produce derived artifacts, so human edits are review annotations rathe
|
|
|
64
64
|
|
|
65
65
|
Same as tier 0 with two additions. `WIREFRAMES.md` opts into Excalidraw rendering via a top-of-file marker like `<!-- excalidraw: WIREFRAMES.excalidraw -->`. `DESIGN.md` stays human-maintained, and its content is what the toolkit provisions into Stitch via `create_design_system` when visual generation is needed.
|
|
66
66
|
|
|
67
|
-
Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in the Stitch DESIGN.md spec format. These are separate files from the toolkit's
|
|
67
|
+
Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in the Stitch DESIGN.md spec format. These are separate files from the toolkit's `canon/DESIGN.md` and are not synced with it. Treat impeccable's pair as its own source of truth for its commands, and the toolkit's `canon/DESIGN.md` as the source other toolkit skills read.
|
|
68
68
|
|
|
69
69
|
### Tools
|
|
70
70
|
|
|
@@ -100,11 +100,11 @@ Most tier 1 projects pick one. Projects with a messy codebase and no curated `DE
|
|
|
100
100
|
|
|
101
101
|
## Tier 2: visual as source of truth
|
|
102
102
|
|
|
103
|
-
Design happens in a graphical tool.
|
|
103
|
+
Design happens in a graphical tool. `canon/DESIGN.md` either regenerates from the graphical source or takes a secondary role as agent-facing summary. Implementation follows the graphical source, either through an MCP round-trip or a one-way handoff bundle. Fits teams with a dedicated designer or projects where design iteration outpaces code changes.
|
|
104
104
|
|
|
105
105
|
### Seed shape
|
|
106
106
|
|
|
107
|
-
|
|
107
|
+
`canon/DESIGN.md` becomes a generated artifact. A top-of-file note identifies the upstream source, either a Claude Design project ID or a Figma file URL. Manual edits in the seed carry a warning tag because they will not survive regeneration.
|
|
108
108
|
|
|
109
109
|
### Tools
|
|
110
110
|
|
|
@@ -148,7 +148,7 @@ Resist over-tiering early. Moving up is cheap because tiers stack. Moving down m
|
|
|
148
148
|
## References
|
|
149
149
|
|
|
150
150
|
- [Claude Design](../../wiki/claude/claude-design.md): first-party hosted design product and handoff bundle
|
|
151
|
-
-
|
|
151
|
+
- `canon/context/claude-plugin/skill-strategy.md`: how to decide between workflow and domain-knowledge skills
|
|
152
152
|
- [`microsoft/playwright-mcp`](https://github.com/microsoft/playwright-mcp): browser automation MCP used in tier 1 and tier 2
|
|
153
153
|
- [`ChromeDevTools/chrome-devtools-mcp`](https://github.com/ChromeDevTools/chrome-devtools-mcp): live frontend debugging MCP used in tier 1 and tier 2
|
|
154
154
|
- [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw): community MCP server behind the tier 1 wireframe companion
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Route
|
|
2
|
+
description: Route canon/context edits to the context-entry standard and the consult-first workflow
|
|
3
3
|
paths:
|
|
4
|
+
- 'canon/context/**'
|
|
4
5
|
- '.claude/context/**'
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -8,7 +9,7 @@ paths:
|
|
|
8
9
|
|
|
9
10
|
## Before editing
|
|
10
11
|
|
|
11
|
-
- Before non-trivial work in a domain, read its
|
|
12
|
+
- Before non-trivial work in a domain, read its `canon/context/<domain>.md` entry. Use `canon/context/index.md` to find it.
|
|
12
13
|
- Leave the entry conforming when work in its domain changes what it describes.
|
|
13
14
|
|
|
14
15
|
## Narration pronouns
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Route
|
|
2
|
+
description: Route canon/wireframes edits to the wireframe standard for layout and interaction intent
|
|
3
3
|
paths:
|
|
4
|
+
- 'canon/wireframes/**'
|
|
4
5
|
- '.claude/wireframes/**'
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -8,5 +9,5 @@ paths:
|
|
|
8
9
|
|
|
9
10
|
## Authority
|
|
10
11
|
|
|
11
|
-
- Follow the wireframes standard for layout and interaction intent: ASCII layout, region labels, variants, copy, and what moves to
|
|
12
|
+
- Follow the wireframes standard for layout and interaction intent: ASCII layout, region labels, variants, copy, and what moves to `canon/context/`. It is the single source. Read it with `canon standards wireframes`.
|
|
12
13
|
- Read it before adding or revising a surface.
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Route
|
|
2
|
+
description: Route canon/REQUIREMENTS.md edits to the requirements standard for product scope and goals
|
|
3
3
|
paths:
|
|
4
|
+
- 'canon/REQUIREMENTS.md'
|
|
4
5
|
- '.claude/REQUIREMENTS.md'
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Route
|
|
2
|
+
description: Route canon/ARCHITECTURE.md edits to the architecture standard for system decisions and risks
|
|
3
3
|
paths:
|
|
4
|
+
- 'canon/ARCHITECTURE.md'
|
|
4
5
|
- '.claude/ARCHITECTURE.md'
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Route
|
|
2
|
+
description: Route canon/DESIGN.md edits to the design standard for visual intent and token tables
|
|
3
3
|
paths:
|
|
4
|
+
- 'canon/DESIGN.md'
|
|
4
5
|
- '.claude/DESIGN.md'
|
|
5
6
|
---
|
|
6
7
|
|
|
@@ -6,4 +6,4 @@ description: Check a folder's index before searching its contents
|
|
|
6
6
|
|
|
7
7
|
## Before searching
|
|
8
8
|
|
|
9
|
-
- Check a folder's `index.md` before grepping its source or reading its files, starting with
|
|
9
|
+
- Check a folder's `index.md` before grepping its source or reading its files, starting with `canon/context/` for a domain and `canon/wireframes/` for a UI surface. It orients faster than a blind search.
|
|
@@ -7,6 +7,6 @@ description: Keep memory writes scoped to .canon/memory/ and out of context-owne
|
|
|
7
7
|
## Writing memory
|
|
8
8
|
|
|
9
9
|
- Write all memory files to `.canon/memory/`, not `~/.claude/projects/`
|
|
10
|
-
- A fact about a domain goes to that domain's
|
|
10
|
+
- A fact about a domain goes to that domain's `canon/context/` entry, not to memory. `canon:memory-capture` routes it there and `canon:docs-fold` folds it in. Memory keeps only what no context entry owns. Report it rather than proceeding silently when either skill does not resolve. Both ship with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have them.
|
|
11
11
|
- Never delete a memory entry. Retire one by moving it to `.canon/tmp/memory-archive/`. A bulk retire runs through the shell, where no file edit fires a path-scoped rule, and the folder is gitignored with nothing to recover from.
|
|
12
12
|
- Follow the memory standard for the filename and type prefix, the frontmatter, the body shape each type carries, and the lifecycle. Read it with `canon standards memory`. Check every entry in the pen against that standard and fix what breaks it, since nothing keeps the folder conforming on its own.
|