@erclx/canon 4.102.0 → 4.104.0

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

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "4.102.0",
+  "version": "4.104.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/canon-cli/SKILL.md

@@ -17,7 +17,7 @@ Consult before running an unfamiliar `canon` verb, before a sync or install, or
 
 | Surface                                                  | Command              | Effect on existing files                                                    |
 | -------------------------------------------------------- | -------------------- | --------------------------------------------------------------------------- |
-| Golden configs, listed in full below                     | `canon tooling sync` | Overwritten once `--write` is passed. Local edits are lost.                 |
+| Golden configs                                           | `canon tooling sync` | Overwritten once `--write` is passed. Local edits are lost.                 |
 | Dictionary seeds (`.cspell/*.txt`)                       | `canon tooling sync` | Merged and sorted. Existing terms preserved.                                |
 | Other seeds (`cspell.json`, `.lintstagedrc`, state docs) | `canon tooling sync` | Copy-once. Dropped on first install, untouched after.                       |
 | Standards                                                | none                 | Nothing installs. `canon standards <name>` reads and never writes.          |
@@ -31,83 +31,12 @@ Consult before running an unfamiliar `canon` verb, before a sync or install, or
 
 A golden config is any file a stack ships under `configs/`, and the category is wider than its name suggests. It carries the CI workflow, the git hooks, the end-to-end harness, the shell scripts under `scripts/`, and the editor settings, alongside the linters and compilers a reader expects. A stack inherits its parent's configs, so syncing `astro` also writes everything `web` and `base` hold.
 
-Run `canon tooling diff <stack> <target>` for the list resolved against a real target. It reports every path, writes nothing, and exits 1 when any differs. The list below is what the stacks hold as shipped, before any chain resolution.
-
-<!-- generated:tooling-paths -->
-
-### astro
-
-- `astro.config.mjs`
-- `eslint.config.js`
-- `playwright.config.ts`
-- `src/components/dev/scenarios.astro`
-- `tsconfig.json`
-- `vitest.config.ts`
-
-### base
-
-- `.editorconfig`
-- `.github/pull_request_template.md`
-- `.github/workflows/phase-label-gate.yml`
-- `.github/workflows/verify.yml`
-- `.husky/commit-msg`
-- `.husky/post-merge`
-- `.husky/post-rewrite`
-- `.husky/pre-commit`
-- `.husky/pre-push`
-- `.prettierrc`
-- `.shellcheckrc`
-- `.vscode/extensions.json`
-- `.vscode/settings.json`
-- `commitlint.config.js`
-- `scripts/verify.sh`
-
-### cloudflare
-
-- `.github/workflows/deploy.yml`
-
-### nextjs
-
-- `eslint.config.js`
-- `next.config.ts`
-- `playwright.config.ts`
-- `vitest.config.ts`
-
-### python
-
-- `.coveragerc`
-- `.python-version`
-- `mypy.ini`
-- `pytest.ini`
-- `ruff.toml`
-- `scripts/verify.sh`
-
-### vite-react
-
-- `playwright.config.ts`
-- `tsconfig.json`
-- `vite.config.ts`
-- `vitest.config.ts`
-
-### web
-
-- `.github/workflows/verify.yml`
-- `.vscode/extensions.json`
-- `.vscode/settings.json`
-- `e2e/home.spec.ts`
-- `e2e/screenshot.ts`
-- `eslint.config.js`
-- `scripts/screenshot.sh`
-- `scripts/verify.sh`
-- `scripts/worktree-port.sh`
-- `src/test/setup.ts`
-
-<!-- /generated:tooling-paths -->
+No list of those paths ships in this body, since a copy would go stale on a different cadence than the stacks. Run `canon tooling diff <stack> <target>` for the list resolved against a real target. It reports every path, writes nothing, and exits 1 when any differs. A binary older than that verb answers the same question through `canon tooling sync <stack> <target> --check`, which names each file it would replace.
 
 ## Rules
 
 - `canon tooling sync` writes nothing until `--write` is passed. A headless run without it reports and exits 1, so a script that forgets the flag fails rather than silently skipping the sync.
-- Run `--check` first when the project carries local edits to any path above. The report names each file it would replace, which is the warning the user needs before the write.
+- Run `--check` first when the project carries local edits to a config the stack ships. The report names each file it would replace, which is the warning the user needs before the write.
 - An interactive run still prompts. `--write` skips the prompt, and `--check` refuses to write even with a TTY.
 - Seeds are user-owned. Dictionary `.txt` files merge and sort. Other seeds are copy-once, so re-seeding a structured file means deleting it and syncing again.
 - No command writes a standard into a project. A `.claude/standards/` folder from an older toolkit is inert, and deleting it costs nothing.

package/claude/skills/canon-operator/REQUIREMENT.md

@@ -53,9 +53,9 @@ The last failure is a section no route reaches. `## Route` maps an intent or a d
 
 ## Out of scope
 
-- First-time scaffold of a fresh project: `setup-init`
+- First-time scaffold of a fresh project: `target-setup`
 - Seed and preamble drift in installed files: `seed-sync`
-- Governance rule install and index bootstrap: `setup-gov` and `setup-indexes`
+- Governance rule install and index bootstrap: `target-setup`, on its `gov` and `indexes` phases
 - What a given sync overwrites once it runs: `canon-cli`
 
 That last contract carries no row for the governance install this skill routes to, so the overwrite `Must` above reads nothing at one of its own destinations. The row belongs to the skill owning the table. This file records the silence rather than answering it, since a rule written here for a silent contract teaches a session that silence means safe.

package/claude/skills/canon-operator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: canon-operator
-description: Front door to the toolkit in a target project. Orients on the toolkit's own docs and live `canon` catalogs, then runs or routes any toolkit operation from a plain-language intent. Use when you want one entry point instead of picking a specific setup or sync skill, or when asked to "use the toolkit", "what can the toolkit do", "sync my standards", "install rules", or "help me set up this project". User-invoked only. Defers first-time scaffold to setup-init and seed drift to seed-sync.
+description: Front door to the toolkit in a target project. Orients on the toolkit's own docs and live `canon` catalogs, then runs or routes any toolkit operation from a plain-language intent. Use when you want one entry point instead of picking a specific setup or sync skill, or when asked to "use the toolkit", "what can the toolkit do", "sync my standards", "install rules", or "help me set up this project". User-invoked only. Defers first-time scaffold to setup and seed drift to seed-sync.
 disable-model-invocation: true
 ---
 
@@ -47,9 +47,9 @@ The two can name different rows, and a reply answers both rather than picking on
 - Anything in `superseded`: name which files and what replaced them, then hand off to `migration-superseded`. Both skills propose, so neither moves nor deletes the file
 - A folder in `unclaimed`: name it and the attribution it carries. No command moves it and the content may be the project's own, so the decision is the user's
 
-- First-time scaffold of a fresh project: hand off to `setup-init`
-- Governance rules for the project stack: hand off to `setup-gov`
-- Bootstrap the `index.md` system: hand off to `setup-indexes`
+- First-time scaffold of a fresh project: hand off to `target-setup`
+- Governance rules for the project stack: hand off to `target-setup`, which installs them alone on its `gov` phase
+- Bootstrap the `index.md` system: hand off to `target-setup`, which bootstraps it on its `indexes` phase
 - Seed or standards drift in `CLAUDE.md` or `.claude/` preambles: hand off to `seed-sync`
 - Install one snippet, standard, or rule: run the domain `install` command
 - Sync one domain or every installed domain: run `canon <domain> sync` or `canon sync`
@@ -104,5 +104,5 @@ The comparison needs the earlier report. When `## Diagnose` was skipped because
 ## Boundaries
 
 - Run `canon`. Never reimplement its install or sync logic, and never edit managed files like rules, configs, or seeds by hand.
-- Hand off the deep flows. Do not duplicate `setup-init` detection or `seed-sync` part-diffing inline.
+- Hand off the deep flows. Do not duplicate `target-setup` detection or `seed-sync` part-diffing inline.
 - Resolve names from catalogs at runtime. A hardcoded name is a bug.

package/claude/skills/canon-rollout/SKILL.md

@@ -88,7 +88,7 @@ Report each dispatch by naming the target, the clone, the branch, the model, and
 
 1. Address every finding whatever its severity. A minor is a finding, and a reviewer calling one non-blocking does not close the pass that raised it.
 2. Resolve who holds the branch before dispatching anybody. Run `canon sessions list --branch chore/agents --repository <clone> --json` and read the count rather than the first row.
-   - A live session holds it: send that session the findings and name `canon:review-address` for it to run, which is step 6 of `## The worker role` and the step that session already stands at. Never name this skill in that message. This body carries `disable-model-invocation: true`, which blocks the `Skill` tool rather than only suppressing an auto-trigger, and a session acting on an inbound message reaches a skill that way and no other, so a message naming this one halts the address leg with the branch built and the findings unread. A launch prompt is the one route to a flagged body, which is why the dispatch above names this skill and this message must not. Assuming the worker was gone is what one hand-driven pass got wrong. All four sessions that opened those pull requests were still alive holding their worktrees hours later, and of two fresh addressers sent over them, one refused on the worktree lock and one cut a second worktree on the same branch, which would have put two sessions pushing to one ref.
+   - A live session holds it: send that session the findings and name `canon:review-address` for it to run, which is step 7 of `## The worker role` and the step that session already stands at. Never name this skill in that message. This body carries `disable-model-invocation: true`, which blocks the `Skill` tool rather than only suppressing an auto-trigger, and a session acting on an inbound message reaches a skill that way and no other, so a message naming this one halts the address leg with the branch built and the findings unread. A launch prompt is the one route to a flagged body, which is why the dispatch above names this skill and this message must not. Assuming the worker was gone is what one hand-driven pass got wrong. All four sessions that opened those pull requests were still alive holding their worktrees hours later, and of two fresh addressers sent over them, one refused on the worktree lock and one cut a second worktree on the same branch, which would have put two sessions pushing to one ref.
    - No live session holds it: dispatch a fresh worker into that clone and brief it with the findings, since it holds none of the reasoning behind the diff.
    - More than one row: report the ambiguity and stop rather than picking among candidates.
 3. Re-review when the answer lands, scoped to the commits added since. A worker's reply never closes a target. One fix for two minor findings closed both and introduced four more, every one of them in prose that fix added, and a loop trusting the reply merges that.
@@ -101,11 +101,12 @@ One session, one target, from the worktree entry to the merge of the branch it o
 
 1. Confirm the clone is current. Fetch, then compare against the origin's default branch. Report a checkout that is behind and stop, rather than branching from a stale base.
 2. Enter a worktree. Invoke `canon:session-worktree chore/agents`, which takes the branch as its tier 0 argument and enters a linked worktree inside this target. Branching in the checkout itself is what this avoids, since the operator may be working in it.
-3. Diagnose and repair. Invoke `canon:canon-operator`, which reads `canon sync --check . --json` and routes each finding to the command or the skill that owns it. Do not restate that routing here and do not edit a managed file by hand.
-4. Commit and open the pull request through `canon:git-commit` and `canon:git-pr`, handing each the fixed shape above rather than taking the title the generator derives from the diff.
-5. Announce as the pull request opens, carrying its URL, its number, and the branch, to whoever dispatched this session. That transition is the one moment only this session can observe.
-6. Answer the review. Invoke `canon:review-address`, which pulls the findings and the CI state on this branch's open pull request, fixes each in the working tree, replies, and pushes. Answer every finding whatever its severity.
-7. Stop there. Do not mark the pull request ready, do not merge, and do not declare the review closed. A narrow re-review posts `## Review closed`.
+3. Check what this target holds. Invoke `canon:target-check`, which reports per domain what the target carries against what the toolkit ships and repairs nothing. It runs before any repair so the wave reads one stated set of domains per target rather than whatever each session decided to examine.
+4. Diagnose and repair. Invoke `canon:canon-operator`, which reads `canon sync --check . --json` and routes each finding to the command or the skill that owns it. Do not restate that routing here and do not edit a managed file by hand.
+5. Commit and open the pull request through `canon:git-commit` and `canon:git-pr`, handing each the fixed shape above rather than taking the title the generator derives from the diff.
+6. Announce as the pull request opens, carrying its URL, its number, and the branch, to whoever dispatched this session. That transition is the one moment only this session can observe.
+7. Answer the review. Invoke `canon:review-address`, which pulls the findings and the CI state on this branch's open pull request, fixes each in the working tree, replies, and pushes. Answer every finding whatever its severity.
+8. Stop there. Do not mark the pull request ready, do not merge, and do not declare the review closed. A narrow re-review posts `## Review closed`.
 
 Send a block out as a message before it becomes an interactive prompt. A session already waiting on input never reaches the tool round an inbound message drains at, so an answer relayed afterwards arrives under the open question and changes nothing.
 

package/claude/skills/design-taste/references/craft.md

@@ -39,7 +39,7 @@ Reaching for size is the first instinct and the weakest tool.
 - **Measure.** Body text running the full width of a wide container is unreadable however good the type is.
 - **Figures in columns.** Numbers that change, in a table, a price or a timer, need tabular figures or the column jitters.
 - **Tracking by size.** Large type wants tighter letter spacing, small uppercase labels want looser. Body text wants whatever the face was drawn with.
-- **Casing.** Sentence case for headings and labels. Title case on every heading reads as a template.
+- **Casing.** Sentence case for headings and labels. `465-interface-casing` states the rule and its exceptions.
 
 ## Depth and texture
 

package/claude/skills/design-taste/references/preflight.md

@@ -28,7 +28,7 @@ Skip nothing on the ground that it is obviously fine. A rule is on this list bec
 
 - [ ] No layout family used twice. Eight sections carry at least four families
 - [ ] No three consecutive sections sharing the image-and-text split
-- [ ] Small uppercase labels above headings number no more than one per three sections
+- [ ] Small uppercase labels above headings number no more than one per three sections, per `465-interface-casing`
 - [ ] At most one horizontal marquee
 - [ ] Grid cells equal content items, with no blank tile filling a gap
 - [ ] Lists over five items use something other than a longer list
@@ -62,7 +62,7 @@ Skip this group where the surface draws on a system already settled.
 - [ ] Every number either real, labeled as sample, or removed
 - [ ] No placeholder that reads as placeholder: generic names, generic company names, reused portraits, identical dates
 - [ ] No filler verbs
-- [ ] Sentence case throughout
+- [ ] Sentence case throughout, with exceptions per `465-interface-casing`
 - [ ] Every claim about what the product does is a thing it does
 
 ## Motion

package/claude/skills/design-taste/references/tells.md

@@ -61,7 +61,7 @@ These are the rules with numbers, so they are checked by counting rather than by
 
 - **A layout family appears once.** Once a section uses a shape, no other section on the surface uses it. Eight sections need at least four distinct families.
 - **Two consecutive splits, never three.** Alternating image-left and image-right reads as considered twice and as filler by the third. Break it with a full-width section, a vertical stack, a grid, or anything else.
-- **One small uppercase label per three sections.** The tiny wide-tracked line above a heading is the single most over-reached default in model output. Count them: more than `ceil(sections / 3)` is too many, and the first screen counts as one. The fix is usually to delete it, since a section's position already says what it is.
+- **One small uppercase label per three sections.** The tiny wide-tracked line above a heading is the single most over-reached default in model output. `465-interface-casing` carries the count. The fix is usually to delete it, since a section's position already says what it is.
 - **One marquee.** Two sliding strips on one surface read as filler rather than as a device.
 - **Cells equal items.** A grid with a hole in it, or a blank tile at the end, means the grid was shaped before the content was counted. Reshape it.
 - **Over five items wants a different component.** A longer list is the lazy answer. Group into clusters, split into columns, give each item a card, make them scrollable, or collapse the tail behind a disclosure.

package/claude/skills/draft-readme/REQUIREMENT.md

@@ -16,6 +16,7 @@ A README whose real documentation lives in `canon/context/` or `docs/` was a sec
 - Read `standards/readme.md` before drafting, since its `## Voice` section is scoped to a repository-root README and yields to `write-human`'s reference voice everywhere else
 - Detect every project type the standard's `## Content` list applies to, from the manifest and the tree, rather than drafting against the closest single type
 - Treat an existing README with no H1, or with headings that name only the scaffold that wrote it, as unedited generator output to draft over rather than a page to sync section by section
+- Read the header block's slots off the repository, being the mark, the claim, the live link, and the product screenshot, and skip the link and the screenshot for a project with no page, so every element traces to a file or field the project holds
 - Verify a candidate badge by the value it would render rather than by a fetch's status code, since a badge service answers 200 for a query it cannot satisfy
 - Confirm the resolved path, the detected types, the badge candidates, and the full content with the user before writing, since project-type detection and badge selection are judgment calls with no diff to preview them against
 
@@ -23,6 +24,7 @@ A README whose real documentation lives in `canon/context/` or `docs/` was a sec
 
 - Rewrite an authored README. One carrying an H1 that names the project refuses toward `docs-sync`.
 - Offer to overwrite an authored README on the refusal path, or propose conforming it to what this skill would have drafted. A target project's own citations into its README are invisible from here, so the refusal reports rather than proposes.
+- Invent a screenshot or a mark the project does not hold, or write a placeholder path for one. An omitted slot is a correct page and an invented image is the failure.
 - Assume this skill's own invocation frequency needs no check. Whether anything reaches for it beyond an author typing its name has no answer at creation time, so a review pass some months in should read that back rather than take the assumption on faith.
 
 ## Guards

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

@@ -27,10 +27,16 @@ Read these files in parallel:
 - Read the project's manifest (`package.json`, `pyproject.toml`, `Cargo.toml`, or equivalent) for a `bin` field or CLI entry point, an installable package name, and its declared dependencies.
 - Check for a `claude/skills/` or `.claude/skills/` folder, a `plugin.json`, or a marketplace manifest, each naming an agent-facing or marketplace-distributed surface.
 - A project is often several of these at once. Note every type that applies rather than stopping at the first match, since the Draft step covers each one the project actually is.
+- Check for a page. A dependency on a site framework or a site config file in the manifest or the tree marks a project as having one. Read a live URL separately, from a `homepage` field or a deploy config, since a project can have a page and no known URL.
+- A monorepo can carry a page in one package and a CLI in another, so both signals may fire. Report each rather than picking one.
+- Look for the mark and the screenshot among images the project already commits: scan the existing README for image references, then the asset and public folders.
 
 ## Draft
 
 - Draft the page against `${CLAUDE_SKILL_DIR}/../../standards/readme.md`: H1, a 2-3 sentence description in plain text, then the required sections, then whichever optional sections and per-type content the Detect step found.
+- Open the page with the standard's header block, filling each slot from what Detect found: mark, title, badges, a one-line claim from the manifest description, the live link, then the product screenshot.
+- Fill the screenshot slot only with an image the project already commits, referenced with alt text naming what it depicts. This skill cannot capture one. Omit the slot when no such image exists and say so in the preview. Never write a placeholder path.
+- Omit the link and the screenshot for a project with no page, and the mark for a project with none, without a note in the drafted page. A project with a page and no known URL gets the screenshot slot, and the Confirm step asks for the link.
 - Cover every applicable project type from the standard's `## Content` list rather than picking the closest one.
 - Candidate badges: check for a published package (a registry field in the manifest), a CI workflow, and a `LICENSE` file.
 - State each candidate's rendered value in the preview rather than trusting a fetch's status code, since a badge service answers 200 for a query it cannot satisfy.
@@ -38,7 +44,8 @@ Read these files in parallel:
 
 ## Confirm
 
-- Show the resolved path, the detected project types, the badge candidates and what backs each one, and the full drafted content before writing.
+- Show the resolved path, the detected project types, the header slots filled or skipped with the reason for each, the badge candidates and what backs each one, and the full drafted content before writing.
+- The skill can confirm that an image file exists and is referenced, and it cannot verify the picture shows the product. Ask the user to look at it in the preview.
 - Confirm with the user. This skill waits for that answer rather than treating the tool permission dialog as the gate, since project-type detection and badge selection are judgment calls with no diff to preview them against.
 
 ## Write
@@ -52,6 +59,7 @@ Read these files in parallel:
 
 **Target:** `<path>` (root | nested)
 **Detected:** `<project types>`
+**Header:** `<each slot as filled (source) or skipped (reason)>`
 **Badges:** `<candidates, or none>`
 
 ```markdown

package/claude/skills/git-followup/SKILL.md

@@ -31,7 +31,7 @@ A missing tracking ref is no longer a guard. An open pull request proves the bra
 
 5. Post the evidence comparison, on every invocation including `reply-owned`, since this comment is not the reply step 8 owns. Run `canon pr evidence <number> --json`, resolving `<number>` from `gh pr view --json number`, and read `reason` on the record rather than the exit code.
    - `no-evidence`: nothing changed under an `evidence/` segment this push. Say nothing and move on.
-   - `ok`: write `body` to `.canon/tmp/pr/evidence/body-<number>.md` at the main worktree root (resolved the way `session-worktree` does), then post the comment with `gh pr comment <number> --body-file <main-root>/.canon/tmp/pr/evidence/body-<number>.md` when the record carries no `commentId`, or edit the existing one in place with `gh api -X PATCH repos/{owner}/{repo}/issues/comments/<commentId> -f body=@<main-root>/.canon/tmp/pr/evidence/body-<number>.md` when it does. Clean up the tmp file only after the call reports success.
+   - `ok`: write `body` to `.canon/tmp/pr/evidence/body-<number>.md` at the main worktree root (resolved the way `session-worktree` does), then post the comment with `gh pr comment <number> --body-file <main-root>/.canon/tmp/pr/evidence/body-<number>.md` when the record carries no `commentId`, or edit the existing one in place with `gh api -X PATCH repos/{owner}/{repo}/issues/comments/<commentId> -F body=@<main-root>/.canon/tmp/pr/evidence/body-<number>.md` when it does. Clean up the tmp file only after the call reports success.
    - Any other reason is one of the mirrored git refusals (`gh-missing`, `gh-failed`, `no-base`, `unreadable-tree`, `unreadable-changes`). Report it and continue without stopping the chain.
 6. Check for existing review comments: `gh api 'repos/{owner}/{repo}/pulls/<number>/comments' --jq 'length'`, resolving `<number>` from `gh pr view --json number`.
 7. Sync the body and title on every invocation, before the routing below decides on the reply.

package/claude/skills/git-issue/SKILL.md

@@ -11,7 +11,7 @@ Format an issue from session context following the issue standard, then file it
 
 Read these in parallel:
 
-- `${CLAUDE_SKILL_DIR}/../../standards/issue.md`: issue title, labels, body sections, and banned phrases
+- `${CLAUDE_SKILL_DIR}/references/issue.md`: issue title, labels, body sections, and banned phrases
 - `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
@@ -39,7 +39,7 @@ After outputting the preview, execute the final command immediately. Claude Code
 
 ### Pre-publish scan
 
-Before running the final command, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the title and body. The title and body go straight to the remote with nothing checking them on the way, so this scan is the only gate. It covers the phase-label check as well as the characters, since both go to a reader who has no task board. It applies on top of the banned phrases in `${CLAUDE_SKILL_DIR}/../../standards/issue.md`.
+Before running the final command, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the title and body. The title and body go straight to the remote with nothing checking them on the way, so this scan is the only gate. It covers the phase-label check as well as the characters, since both go to a reader who has no task board. It applies on top of the banned phrases in `${CLAUDE_SKILL_DIR}/references/issue.md`.
 
 The `pull_request` check the git-pr surface carries reads a pull request's own title and body alone, so an issue reaches no check behind this scan either.
 

package/{standards → claude/skills/git-issue/references}/issue.md

@@ -1,8 +1,3 @@
----
-title: Issue reference
-description: GitHub issue title, labels, and body conventions
----
-
 # Issue reference
 
 ## Scope
@@ -11,10 +6,10 @@ Governs a tracker issue: its title, its labels, and the sections its body carrie
 
 Does not govern:
 
-- Pull request title and body: `pr.md`
-- Whether a phase label may appear in issue text: `versioning.md`
+- Pull request title and body: the pull request standard
+- Whether a phase label may appear in issue text: the versioning standard
 - Voice, rhythm, and sentence construction in issue prose: the `write-human` skill
-- Punctuation, formatting, and banned words in issue prose: `markdown.md`
+- Punctuation, formatting, and banned words in issue prose: the markdown standard
 
 ## Title
 

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

@@ -181,10 +181,10 @@ Read `reason` on the record rather than the exit code.
 gh pr comment <number> --body-file <main-root>/.canon/tmp/pr/evidence/body-<number>.md
 ```
 
-When the record carries a `commentId`, edit that comment in place instead of posting a second one, reading the body field from the tmp file with `@`:
+When the record carries a `commentId`, edit that comment in place instead of posting a second one, reading the body field from the tmp file with `@`, which needs the typed-field flag `-F` because the raw-string flag `-f` posts the path itself as the body:
 
 ```bash
-gh api -X PATCH repos/{owner}/{repo}/issues/comments/<commentId> -f body=@<main-root>/.canon/tmp/pr/evidence/body-<number>.md
+gh api -X PATCH repos/{owner}/{repo}/issues/comments/<commentId> -F body=@<main-root>/.canon/tmp/pr/evidence/body-<number>.md
 ```
 
 Delete the handoff file once that call reports success, per the cleanup below, since the checklist now lives on the pull request. Clean up the tmp body file the same way.

package/claude/skills/index-lookup/REQUIREMENT.md

@@ -30,6 +30,6 @@ Without this skill, `canon indexes list --json` exists as a verb with nobody wra
 
 ## Out of scope
 
-- Regenerating or scaffolding an index, which `canon indexes regen` and the `setup-indexes` skill own
+- Regenerating or scaffolding an index, which `canon indexes regen` and the `target-setup` skill's `indexes` phase own
 - Reading a folder's contents once a hit names it, which is an ordinary file read rather than part of the lookup
-- Chaining this skill into `setup-indexes`'s bootstrap flow as a verification step. Left independent: `setup-indexes` already validates through `canon indexes regen --dry-run`, and a second skill call inside a bootstrap flow duplicates a check that already runs.
+- Chaining this skill into the `target-setup` skill's `indexes` phase as a verification step. Left independent: that phase already validates through `canon indexes regen --dry-run`, and a second skill call inside a bootstrap flow duplicates a check that already runs.

package/claude/skills/project-commands/REQUIREMENT.md

@@ -38,5 +38,5 @@ Two more failures are mechanical. A command that stays up run in the foreground
 
 - Confirming a change works in the running app, which is a verification request and needs the steps this skill refuses
 - Deploying, publishing, releasing, migrating, and resetting
-- Running the scaffold verification chain against `package.json` scripts: `setup-verify`
+- Running the scaffold verification chain against `package.json` scripts: the `target-setup` skill's `verify` phase
 - Writing the entry it reads, which belongs to the project's own development docs

package/claude/skills/seed-sync/REQUIREMENT.md

@@ -41,5 +41,5 @@ Two failures belong to the audit rather than to the diff. A decision taken in ch
 - Bulk install and sync of a whole domain, which `canon <domain> install` and `canon <domain> sync` own and `canon-cli` documents. Reach for this skill when the target holds edits worth keeping, and for those commands when it does not.
 - Golden configs, which overwrite by design and carry no section structure to diff
 - Governance rules: `canon gov sync`
-- First-time scaffold of a project that has installed nothing yet: `setup-init`
+- First-time scaffold of a project that has installed nothing yet: `target-setup`
 - Public `README.md` and `docs/` prose: `docs-sync`

package/claude/skills/target-check/REQUIREMENT.md

@@ -0,0 +1,42 @@
+---
+name: target-check
+description: What the target check is for, the gap it closes, and the repairing it refuses
+---
+
+# Target check requirement
+
+## Gap
+
+Without this skill, a session landing in a target project decides for itself what to look at. `canon-rollout` dispatches a worker into each target and gets a pull request out, and nothing told that worker what a target holds against what the toolkit ships, so a wave is only as good as whatever each session happened to examine. Four hand-driven repairs across two waves examined four different sets of surfaces and none of them read the same domain twice.
+
+The second half of the gap is silence. A session that runs a verb the target's binary does not carry, or reads a report key that is absent, has no instruction telling it apart from a clean answer, so an unexamined domain reaches the reader as a domain that passed.
+
+## Must
+
+- Report one section per domain, so a reader can tell which surface a finding came from
+- Read each domain through the verb that already owns that comparison, rather than inspecting the same files by hand, since the verb is the surface under test
+- Take the installed domains from the catalog the report returns rather than from a list in the body, so a domain the toolkit adds later needs no edit here
+- Report a refusal, an absent key, and a missing subcommand as unread, naming the cause, so an unexamined domain never reads as a passing one
+- Report the Claude harness as unchecked on every run while no verb answers for it, as a row rather than an omission
+- Report the toolkit version first, since a target behind on the binary explains every unread section under it
+- Run every read non-interactively by default, because every caller in the near term is a dispatched worker with nobody present to answer a prompt
+
+## Must not
+
+- Repair a finding, write a file in the target, or open a pull request. A check that repaired as it read leaves the reader unable to tell a finding from a fix, and the wave decides what to fix.
+- Emit a verdict across the domains. Five answer from verbs and one answers from nothing, so any roll-up is a figure that lies about the sixth.
+- Answer the harness domain by file inspection. A section reaching a verdict from a hand-rolled read is exactly what the other five sections avoid, and a hole a reader can see is worth more than a number nobody can trace.
+- Hardcode a stack, rule, or domain name. A name written into the body goes stale on its own cadence.
+
+## Guards
+
+- `canon` absent from the path: stop, since no domain can be read
+- No `.claude/` at the working root: stop and name the scaffold command, since nothing is installed to check
+- The working root is the toolkit itself: stop and name `canon-rollout`, since this skill reads what the toolkit installed into rather than the source
+
+## Out of scope
+
+- Document health, which asks a content question rather than a structural one and takes its own surface
+- Repairing anything a section names. Each routes to the command or skill that owns it.
+- A target's own routes, which `canon inventory` reports as a listing rather than a verdict and which is a fact about the project rather than about what the toolkit ships
+- First-time scaffold, which is `target-setup`, and per-intent routing of a single toolkit operation, which is `canon-operator`

package/claude/skills/target-check/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: target-check
+description: Reports what a target project holds against what the toolkit currently ships, one section per domain, reading through `canon` verbs rather than inspecting files. Use when asked to "check this target", "what has this project fallen behind on", "is this project current with the toolkit", "run the target check", or as the first thing a rollout worker runs after entering a target. Do NOT use to repair a finding, which the owning command or skill does, and do NOT use in the toolkit repository itself.
+---
+
+# Target check
+
+Reports, per domain, what this target holds against what the toolkit currently ships. It reports and never repairs, so whoever read the report decides what to fix.
+
+Six domains carry the report. Five answer from a verb that already exists and the sixth answers from nothing, which it says rather than omitting. `${CLAUDE_SKILL_DIR}/references/domains.md` holds what each one reads, what current looks like, and where a finding routes. This body holds the order, the guards, and the report shape.
+
+## Guards
+
+- `canon` absent from the path: stop. `❌ canon is not on PATH, so no domain can be read.`
+- No `.claude/` directory at the working root: stop. `❌ No .claude/ here, so nothing is installed to check. Run canon init first.`
+- A `claude/skills/` folder at the working root, with no leading dot: stop. `❌ This is the toolkit itself rather than a target. canon-rollout takes a change out to the targets.` A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into.
+- Run every command under `CANON_NON_INTERACTIVE=1` and prompt at no point. Every caller in the near term is a worker a wave dispatched, with nobody present to answer, so the non-interactive path is the only path rather than a flag a caller remembers.
+- Branch on each record's own fields rather than on an exit status. An operator's shell profile may wrap `canon` in a function whose status comes from a trailing command, which reports every refusal as success.
+
+## Step 1: read the reports
+
+Run these from the target root, in parallel:
+
+```bash
+CANON_NON_INTERACTIVE=1 canon sync --check . --json
+CANON_NON_INTERACTIVE=1 canon context audit --json
+```
+
+The first answers five domains from one read, being `skew`, `domains`, `seeds`, `tooling`, and the layout fields `unmigrated`, `superseded`, and `reverse`. The second deepens a domain that first read only counts.
+
+Then run `CANON_NON_INTERACTIVE=1 canon records validate <kind> --json` once per record folder the target carries, taking `<kind>` from what is present under the record root rather than from a list held here.
+
+### The tooling read takes a stack, always
+
+The tooling comparison runs last, because it needs a value the first read returns. Take `<stack>` from the first name in the report's `tooling.chain`, which records the stack nearest the target, and pass it:
+
+```bash
+CANON_NON_INTERACTIVE=1 canon tooling sync --check <stack>
+```
+
+Refuse the domain and report it unread when `chain` names nothing, rather than running the command bare. A bare call reaches the stack prompt, and the non-interactive variable this skill's Guards make mandatory resolves that prompt to the first option in the catalog instead of refusing it. The domain would then compare every target against whichever stack sorts first, and report drift that is an artifact of the wrong comparison rather than anything the target did. It would fire on every run rather than on an edge, since nothing about the target is read on the way to that default.
+
+Read every installed domain from the catalog the report returns rather than from a name written into this body. `domains` enumerates what the target actually stamped, so a domain the toolkit adds later reaches this report with no edit here, and a name hardcoded here is a bug.
+
+## Step 2: report each domain
+
+Report the six in this order, one section each, per `${CLAUDE_SKILL_DIR}/references/domains.md`:
+
+1. Toolkit version
+2. The `canon/` folder
+3. Governance rules
+4. Tooling
+5. Seeds
+6. The Claude harness
+
+Give each section three things and nothing else: the state, the evidence the state was read from, and the command or skill that repairs it. Naming the repair is not running it.
+
+### Unread is not current
+
+A refused command, an absent key, or a subcommand the target's binary does not carry leaves a domain unread. Report it as unread, name which read could not be taken, and name the cause. Reading an absent key as an empty answer reports a clean target to a project nothing looked at, which is the failure this report exists to replace.
+
+The version domain is what makes that case legible rather than mysterious. A target a release behind is missing verbs the other five sections call, so the version section is read first and its state explains every unread section under it.
+
+### No verdict across the six
+
+Report a state per domain and no number over them. Five sections answer from verbs and the sixth answers from nothing, so any roll-up is a figure that lies about the sixth. `canon inventory` reports a listing rather than a verdict for the same reason, and it is absent from the six here because its subject is a target's own routes rather than what the toolkit ships.
+
+## Step 3: stop at the report
+
+Repair nothing, write no file in the target, and open no pull request. A wave decides what to fix after reading this, and a check that repaired as it read would leave the reader unable to tell a finding from a fix.
+
+## Output
+
+Lead with the table, then one detail block per domain that is not current:
+
+```markdown
+Target check: `<path>`, against canon `<version>`.
+
+| Domain           | State                     | Evidence                          |
+| ---------------- | ------------------------- | --------------------------------- |
+| Toolkit version  | current / behind / unread | `skew.installed` against `latest` |
+| `canon/` folder  | current / behind / unread | what the layout fields named      |
+| Governance rules | current / behind / unread | the per-state counts              |
+| Tooling          | current / behind / unread | what a sync would change          |
+| Seeds            | current / behind / unread | the per-state counts              |
+| Claude harness   | unchecked                 | no verb reads it                  |
+
+No overall verdict. The harness row is unchecked rather than passing.
+```
+
+Keep the harness row `unchecked` on every run until a verb reads it. A domain left out of the table reads as a domain that passed, which is the one shape the row exists to prevent.

package/claude/skills/target-check/references/domains.md

@@ -0,0 +1,88 @@
+---
+title: Target check domains
+description: What each of the six domains reads, what counts as current, and where a finding routes
+---
+
+# Target check domains
+
+One section per domain, in the order the body reports them. Each names the read, what current looks like, what the states mean, and the command or skill a finding routes to. Naming a repair is not running one.
+
+## 1. Toolkit version
+
+Read `skew` off `canon sync --check . --json`. It carries `state`, `installed`, and `latest`.
+
+- Current: `state` reads `current`, or `installed` equals `latest`.
+- Behind: `installed` trails `latest`. Name both versions.
+- Unread: no `skew` key, or the whole report refused. Say the version could not be read and treat every section under it as read against an unknown binary.
+
+Routes to `canon upgrade`, which reinstalls with the manager that installed it.
+
+This domain is first because it conditions the other five. A target a release behind carries an older verb surface, so a section reporting unread below may be reporting a missing subcommand rather than a missing surface, and the version state is what separates those two readings.
+
+## 2. The `canon/` folder
+
+Read three fields off the same report, then two verbs:
+
+- `unmigrated`: a domain still at the root layout with nothing under `.claude/`. The most urgent finding, because such a domain reports no drift of its own while being entirely behind.
+- `superseded`: a file a newer seed folder replaced. No command moves it, since the content is the project's own.
+- `reverse`: `unclaimed` names folders at roots the toolkit stopped shipping, each with an `attribution` of `dropped`, `unattributed`, or `project`. `migrations` names a proposal-only skill with a live case here and the `reason` behind it.
+- `canon context audit --json`: required sections, entry length, citations, and index drift across the context folder.
+- `canon records validate <kind> --json`, once per record folder the target carries.
+
+- Current: `unmigrated` and `superseded` both empty, `reverse.unclaimed` carrying nothing outside `project` attribution, and both verbs finding nothing.
+- Behind: any of those carrying an entry. Name the entry and its attribution.
+- Unread: `historyUnavailable` set on `reverse`, a `reverse` key the report does not carry at all, or either verb refusing. A missing `reverse` key is a binary predating the field rather than a target with nothing unclaimed.
+
+Routes by finding. `unmigrated` routes to a relocation the user runs, since no command moves it. `superseded` routes to `migration-superseded`. A `migrations` entry routes to the skill its `skill` field names, spelled as the report spells it. An `unclaimed` folder carrying `project` attribution routes nowhere, since history proved the project owns it.
+
+## 3. Governance rules
+
+Read `domains` off the report and take every entry it carries rather than naming governance here. Each entry carries `stamped`, per-state `counts`, and `entries` with a `state` and a `rel` path.
+
+The states are `matching`, `stale`, `customized`, `drifted`, `orphaned`, `stranded`, and `missing`.
+
+- Current: every count but `matching` reads zero.
+- Behind: any other count is non-zero. Report the counts and name the paths behind `stale` and `missing`, which a sync repairs, separately from `customized` and `drifted`, which the project wrote and a sync would overwrite.
+- Unread: `stamped` false with no entries, or the domain absent from the array while the target carries installed rules.
+
+Routes to `canon <domain> sync`, or to `canon sync` for every installed domain at once. Read the `canon-cli` skill before naming either, since a command name says nothing about what it does to a file already there, and a `customized` entry is exactly the file a sync takes back.
+
+## 4. Tooling
+
+Read the `tooling` block off the report first, because the comparison command needs a value it carries.
+
+Read `measured` before anything under it. Every count is zero when `measured` is false, which is an absence of measurement rather than a measured zero.
+
+On a measured report, take `<stack>` from the first name in `chain` and run `canon tooling sync --check <stack>`. Never run it bare. The stack argument is what the target carries, and omitting it reaches a prompt that the non-interactive variable resolves to the catalog's first entry rather than refusing, which compares the target against a stack it does not use and reports the difference as drift.
+
+- Current: `measured` true, `chain` naming stacks the toolkit still ships, and `--check` reporting nothing it would change.
+- Behind: `--check` naming files it would replace, or `counts.gitignore` carrying missing managed entries.
+- Unread: `measured` false. It splits three ways, and each is reported as unmeasured with its cause named rather than as clean. An empty `chain` at a workspace root is by design, since a chain there would guess at what the packages hold. An empty `chain` anywhere else means no tooling install is recorded. A `chain` carrying names the toolkit no longer ships means injecting would write against a retired name.
+
+Routes to `canon tooling sync <stack>`, or to `canon tooling inject --gitignore <stack>` for ignore entries alone, taking `<stack>` the same way the comparison above does. An unmeasured report names no stack, so it routes to neither.
+
+`canon tooling diff` is the verb this section wants and it does not exist yet. `--check` answers the same question today and stays working as an alias by design, so the retarget when that verb lands is a change of name rather than of behavior.
+
+## 5. Seeds
+
+Read `seeds.entries` off the report. Each entry is `matching`, `stale`, `drifted`, or `missing`, and the set spans `CLAUDE.md`, the `canon/` records, the generated indexes, `.claude/settings.json`, and the hook scripts under `.claude/hooks/`.
+
+- Current: every entry reads `matching`.
+- Behind: anything else. Report `stale` and `missing` separately from `drifted`, which means the content matches no version the toolkit ever published, so the project wrote it.
+- Unread: `historyUnavailable` set on `seeds`, which leaves every difference unattributed. Say so rather than reporting a file as untouched.
+
+Routes to `seed-sync`, which proposes per-section edits without overwriting a customization. It is a proposal rather than a write, which is why a `drifted` `CLAUDE.md` routes there rather than to a sync.
+
+A seed entry matching says the file's bytes match the shipped seed. It says nothing about whether the harness those files configure is wired, which is the next domain.
+
+## 6. The Claude harness
+
+No verb reads this domain. Report it `unchecked` on every run and report it as a row rather than omitting it.
+
+What goes unread is whether the target's hooks fire, whether `.claude/settings.json` registers them, which plugin version the target's sessions actually load, and whether the marketplace cache matches what the toolkit ships.
+
+Confirm the gap against the live surface rather than against a list held here, by reading `canon claude --help` and the help of any subcommand under it that sounds like an answer. A list written into this file freezes on the day it was written and would report a gap a later release had closed. `canon claude skills drift` is the verb that comes nearest, and it reads the toolkit's own history against a ref, which says what moved upstream rather than what this target holds. Report the domain checked, with what the verb answered, on the run where a verb does answer one of the four questions above.
+
+Reading it by file inspection is the alternative and it is refused. Every other section here answers from the verb under test, and a section answering from a hand-rolled read of the same files reaches a verdict nothing else in the report is entitled to make. A hole a reader can see is worth more than a number nobody can trace.
+
+`canon claude plugin-update` is what an operator runs to bring a cache forward. Name it as the action available rather than as a repair for a finding, since no finding was taken.