@erclx/canon 4.109.0 → 4.110.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.109.0",
+  "version": "4.110.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/{canon-feedback-file → canon-feedback}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: canon-feedback-file
-description: Why a toolkit defect is reported from session context alone, and what shipping through the CLI replaces
+name: canon-feedback
+description: Why a toolkit defect is reported from session context alone, and what opening an issue through the CLI replaces
 ---
 
-# Canon feedback file requirement
+# Canon feedback requirement
 
 ## Gap
 
@@ -18,8 +18,9 @@ The last failure is the session's own effort. Asked to report, a session starts
 - Build the report from what the session already holds
 - Name the surface and its type, since the toolkit routes on that rather than on the symptom
 - Write the stated fallback for a field the session cannot fill, so an empty field reads as absent rather than as unreported
-- Ship through the CLI so the report lands without a copy-paste, and print the returned path on its own line
-- Offer the durable route for a report worth keeping across sessions and machines
+- Open a GitHub issue on the toolkit repo through the CLI so the report lands where triage reads it, and print the returned URL on its own line
+- Say which file and which reason when the issue call fails and the report falls back to a local folder, since a silent fallback leaves it where nothing reads it
+- Hold a report the operator marks sensitive, since the issue is public
 - Fall back to printing the block when the CLI is absent, so the report still exists
 
 ## Must not
@@ -36,5 +37,5 @@ The last failure is the session's own effort. Asked to report, a session starts
 
 - Fixing the defect, which happens in the toolkit repository against its own source
 - Draining the queue this fills: `canon-feedback-triage`
-- Filing an issue against the current project: `git-issue`
+- Filing an issue against the current project, which `git-issue` does and this skill cannot delegate to, since that skill targets the current repository
 - Complaints about tooling the toolkit does not own

package/claude/skills/{canon-feedback-file → canon-feedback}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: canon-feedback-file
-description: Format a paste-back report about something broken, missing, or off in canon and write it directly to the toolkit's `.canon/feedback/` folder via `canon feedback`. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
+name: canon-feedback
+description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback --github`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
 ---
 
-# Canon feedback file
+# Canon feedback
 
-Format a `## Toolkit feedback` block from the current session, then ship it to the toolkit repo without manual copy-paste.
+Format a `## Toolkit feedback` block from the current session, then open it as a GitHub issue labeled `feedback` on the toolkit repo. `canon-feedback-triage` reads that queue.
 
 ## Guards
 
@@ -69,9 +69,9 @@ Detect whether `canon` is on PATH:
 command -v canon >/dev/null 2>&1
 ```
 
-Before either pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block. `.canon/review/` is gitignored, so no hook reaches either write, and this scan is the only gate. The banned-character half runs on both branches, including the local write. The phase-label half applies only on the `--github` branch, where the block reaches a remote.
+The destination is a public GitHub issue on the toolkit repo, so the report leaves the machine. Hold it and ask when the operator has marked it sensitive, and never send it on a guess.
 
-Local scratch only writes from a toolkit checkout, since `canon feedback` resolves the destination against the toolkit's own `.claude/` folder and a target project never carries one. Pipe the block to `canon feedback --github` first.
+Before the pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block, phase-label half included. Nothing else checks what reaches the remote, so this scan is the only gate.
 
 ```bash
 cat <<'EOF' | canon feedback --github
@@ -81,19 +81,9 @@ cat <<'EOF' | canon feedback --github
 EOF
 ```
 
-The CLI opens a GitHub issue on the toolkit repo and prints the issue URL. It needs `gh` authenticated, and falls back to local scratch with the reason on stderr when the call produces no URL and the session holds a toolkit checkout to fall back onto.
+The CLI opens a GitHub issue labeled `feedback` on the toolkit repo and prints the issue URL, which this skill reports back on its own line. It needs `gh` authenticated. `git-issue` is not the route, since it files on the current repository and this report belongs on the toolkit's.
 
-From a toolkit checkout, plain `canon feedback` reaches the same destination without opening an issue:
-
-```bash
-cat <<'EOF' | canon feedback
-## Toolkit feedback
-
-...
-EOF
-```
-
-It writes to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the absolute path on stdout. Report the printed path back to the user on its own line, in the form the project's instruction file sets under `## Output`.
+From a toolkit checkout, a call that produces no URL falls back to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the reason on stderr. Say so in the same reply, naming the file and the reason, since a silent fallback leaves the report where nothing reads it. A target project has no such folder, so a failed call there prints the block in chat.
 
 If `canon` is not on PATH, fall back: print the block in chat and tell the user `📋 Copy the block above into a toolkit-repo session.`
 
@@ -109,4 +99,4 @@ A `--github` run from a toolkit checkout whose GitHub call fails warns and write
 ## Notes
 
 - `canon feedback` resolves the toolkit root from the running `canon` binary's source location. If multiple toolkit clones exist on the machine, the first `canon` on PATH wins.
-- The destination `.canon/review/` is gitignored in the toolkit repo. Feedback lives as session scratch for the next toolkit-side triage, not as a durable archive.
+- The local folder is a fallback for a failed issue call, and nothing reads it on a schedule. The issue is the durable record.

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

@@ -35,6 +35,6 @@ The queue also fails to drain even when the work ships. A fix merged with no lin
 
 ## Out of scope
 
-- Filing new feedback: `canon-feedback-file`
+- Filing new feedback: `canon-feedback`
 - Writing the plan a plan-worthy issue needs: `plan-feature`
 - Triage of issues carrying any other label, which surface here by design only under the feedback label

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

@@ -1,6 +1,6 @@
 ---
 name: canon-feedback-triage
-description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback-file`), or for general GitHub issue triage unrelated to toolkit feedback.
+description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback`), or for general GitHub issue triage unrelated to toolkit feedback.
 ---
 
 # Canon feedback triage

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

@@ -0,0 +1,42 @@
+---
+name: draft-wiki
+description: Why a brand-new wiki reference page needs both placement tests, a catalog collision check, and a sourced read before anything is written
+---
+
+# Wiki draft requirement
+
+## Gap
+
+Without this skill, a session asked for a wiki page writes one from training knowledge, which is the single thing the wiki standard forbids outright, and nothing in the resulting file shows that it happened. It also files the page by where the request came from rather than by who owns the subject, so material about the project itself lands in the wiki and material about a third-party tool acquires a folder the standard never sanctioned.
+
+The standard can state all of this and still be read by nothing, which is the condition this skill was written into in the toolkit. A page written under that condition conforms by the author's memory rather than by a read, and it ships looking identical to one that was checked.
+
+## Must
+
+- Read the wiki standard before drafting, since the placement tests and the sourcing rule are the two things a session gets wrong from memory
+- Run both placement tests and refuse on either, since a page passing one and failing the other is still non-conforming
+- Check the subject against the catalog by title and description, not by slug alone, since a subject can be covered under a name the slug does not guess
+- Build the draft on a fetched read and stop when the fetch fails, since a page written from recall is indistinguishable from a checked one once it ships
+- Confirm the path, the source, and the content with the user before writing, since the standard forbids writing a wiki file unasked
+- Name the folder by resolving what the standard states rather than by carrying a path in the body, since the body ships to projects whose layout this repository does not set
+
+## Must not
+
+- Widen the folder split to admit a subject the second placement test rejects. That is a change to the standard, argued there.
+- Edit or refresh a page that already exists. A collision refuses toward editing the existing page rather than drafting a second one.
+- Substitute recall for a failed fetch, even for a subject the session believes it knows.
+
+## Guards
+
+- No subject given: stop and ask what subject the page should cover.
+- The wiki root does not resolve: say so and ask before creating it, since a project holding no wiki has never taken the placement rule.
+- The slug already resolves to a page: stop and point at editing that page.
+- The catalog already covers the subject under a different name: stop the same way, checked against the titles and descriptions the Collision step already reads.
+
+## Out of scope
+
+- Editing or refreshing a wiki page that already exists: a plain edit against the same standard
+- Drafting a `docs/*.md` page: `draft-docs`
+- Drafting a `canon/context/<domain>.md` entry: `draft-context`
+- Voice, rhythm, and sentence construction in the drafted page: the `write-human` skill
+- Punctuation, headings, and word choice in the drafted page: the markdown standard

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

@@ -0,0 +1,83 @@
+---
+name: draft-wiki
+description: Drafts a brand-new wiki reference page for a subject owned outside this repository, against the wiki standard. Checks the two placement tests and the catalog for a collision, sources the subject from its owner rather than from training knowledge, confirms with the user, then writes. Use when asked to "write a wiki page for X", "add a wiki reference for X", "document X in the wiki", or "create a reference page for X" where no page covers the subject yet. Do NOT use to edit or refresh a page that already exists, which is a plain edit against the same standard. Do NOT use for a subject this repository owns, which is `draft-docs` or `draft-context`.
+---
+
+# Wiki draft
+
+Drafts one brand-new wiki reference page end to end: read the standard, settle placement, check the catalog for a collision, source the subject from its owner, confirm the draft with the user, then write.
+
+Read these files in parallel:
+
+- `${CLAUDE_SKILL_DIR}/../../standards/wiki.md`: the two placement tests, the frontmatter contract, the naming convention, the sourcing rule, and the page template
+- `${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
+
+The standard's `## Placement` section names the folder a page lands in and the vendor subfolder under it. Resolve both from the project root and call them `<wiki-root>` and `<vendor>` below, so the body states the rule once and the standard stays the one owner of the path.
+
+## Guards
+
+- If no subject is given, stop: `❌ No subject given. Name the subject this page should cover.`
+- If `<wiki-root>` does not resolve, say so and ask whether to create it before drafting. A project carrying no such folder has never taken the standard's placement rule, so creating it is a decision rather than a step.
+
+## Placement
+
+The standard sets two tests and a page has to pass both. Run them before drafting anything, since a page failing either is non-conforming however well it is written.
+
+- **Owned outside this repository.** A subject describing how this repository works fails. Refuse and route it: `❌ <subject> is owned by this project, so it belongs in the docs surface, a context entry, or a skill body. Use draft-docs or draft-context.`
+- **Owned by the vendor the folder split covers.** The standard names one owner and one subfolder. A third-party tool or a vendor-neutral concept fails, however reference-like it reads. Refuse and route it: `❌ <subject> is outside the wiki's folder split. Route it to the docs surface or a skill body rather than adding a second folder for it.`
+
+Do not widen the split to admit a subject. Adding a sibling folder is a change to the standard, argued there, rather than a placement this skill takes on its own.
+
+## Collision
+
+- Derive the page slug per the standard's `## Naming` section and check whether `<wiki-root>/<vendor>/<slug>.md` already exists. If it does, stop: `❌ <path> already covers this subject. Edit that page against the standard instead of drafting a second one.`
+- Read `<wiki-root>/<vendor>/index.md` and check every title and description it lists against the subject. The slug check above only catches an exact filename collision, and a subject already covered under a different name still resolves here at no extra cost, since this read already runs.
+- Stop the same way on a match: `❌ <path> already covers this subject under a different name. Edit that page instead.`
+
+## Source
+
+The standard forbids working from training knowledge, so the draft is built on a read rather than on recall.
+
+- Fetch current information through the `claude-code-guide` agent for any subject that agent covers. Its answer is the source the page is written from.
+- Reach a subject the agent does not cover through the owner's own published documentation.
+- Say the fetch failed and stop rather than substituting recall. A page sourced from memory is the failure the rule exists to prevent, and it ships looking identical to one that was checked.
+- Close the intro with the `Source:` sentence the standard requires, linking the canonical page where one exists and naming the owner alone where the subject has no single URL.
+- Stamp the read date on a source revised without notice, as `read <date>`. A claim traced to an undated read cannot be checked against what was actually read.
+
+## Draft
+
+- Draft `title` and `description` frontmatter against the standard's contract, then the intro paragraph closing on `Source:`, then the reference sections.
+- Draft against the standard's template and keep its ordering.
+- Write what the fetch returned rather than what the subject is assumed to do.
+- Answer one question per section and stop. A reader arrives to settle something specific rather than to read the page through.
+- Mark a claim the fetch left unsettled rather than smoothing over it. An unmarked gap reads as a checked fact.
+
+## Confirm
+
+- Show the resolved path, the source the page was built from, and the full drafted content before writing.
+- Confirm all three with the user. This skill waits for that answer rather than treating the tool permission dialog as the gate, since the standard states outright that a wiki file is not written unasked.
+
+## Write
+
+- Write the file at the confirmed path.
+- Run `canon markdown audit <path>`.
+- Run `canon indexes regen <wiki-root>/<vendor>`, naming the folder the page landed in rather than the root above it. The verb rewrites the `index.md` sitting in the folder it is given and does not walk down, so regenerating at the root leaves the vendor catalog untouched and the new page missing from the one the Collision step reads. A page absent there is invisible to the next run, which then drafts a second page on the same subject.
+
+## Response format
+
+### Preview
+
+**Subject:** `<subject>`
+**Placement:** `<path>`
+**Source:** `<owner, and the read it came from>`
+
+```markdown
+<drafted frontmatter and body>
+```
+
+### After confirmation
+
+```plaintext
+✅ Drafted: <path>
+```

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

@@ -33,6 +33,6 @@ Without this skill, an issue takes the shape of whatever the session was saying.
 
 ## Out of scope
 
-- Reporting a toolkit defect from a target project, which `canon-feedback-file` owns. That path writes into the toolkit rather than the current repository.
+- Reporting a toolkit defect from a target project, which `canon-feedback` owns. That path opens an issue on the toolkit repository rather than the current one.
 - Triaging issues already filed, which `canon-feedback-triage` owns
 - Opening a pull request, which `git-pr` owns

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

@@ -1,6 +1,6 @@
 ---
 name: git-issue
-description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `canon-feedback-file`), or to open a pull request (that is `git-pr`).
+description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `canon-feedback`), or to open a pull request (that is `git-pr`).
 ---
 
 # Git issue

package/docs/agents/teach.md

@@ -133,7 +133,7 @@ It reports three things. `lesson` is the numbered path the lesson takes, derived
 
 A lesson written against this record carries its chrome as four empty marker pairs rather than hand-composed markup: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. `canon teach nav`, below, fills them from what the workspace holds on disk.
 
-`canon teach stylesheet <topic>` writes the one file every lesson in the workspace embeds, seeded from the design source so a workspace renders in the system every other surface does. It refuses to overwrite, reporting `written` as false where the workspace already carries one, and `--force` takes the seed back over it. Each workspace used to carry a hand-authored palette, which is how the course styling forked once per workspace, so a lesson adds its own rules under the seed and reaches a value through its custom property rather than restating the hex.
+`canon teach stylesheet <topic>` writes the pair every lesson in the workspace renders through, seeded from the design source so a workspace renders in the system every other surface does. The two halves are written on different terms. `assets/base.css` holds the generated design layer and is rewritten on every run, which is the only way a change to the shared chrome reaches a workspace that already exists. `assets/course.css` is the half a workspace owns, so it refuses to overwrite, reporting `written` as false where the workspace already carries one, and `--force` takes the seed back over it. Each workspace used to carry a hand-authored palette, which is how the course styling forked once per workspace, so a lesson adds its own rules under the seed and reaches a value through its custom property rather than restating the hex.
 
 Each `quiz` entry carries `order`, the authored option indices in presentation order where index `0` is the correct answer, and `answer`, the one-based position that answer lands in. Both travel together because a caller deriving the position itself is a caller that can derive it wrongly.
 
@@ -172,10 +172,12 @@ canon teach nav regular-expressions --json
 
 With no topic it rewrites every workspace. The teach-root listing is always rewritten regardless, since it reports on every workspace and a scoped run leaving it stale would be a second kind of drift this verb exists to end.
 
-A lesson carries its chrome as four marker pairs the authoring skill writes empty: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. This verb splices each one from the current workspace state, embedding the shared stylesheet, rebuilding the breadcrumb and jump menus, the prev/next footer nav, and the behavior scripts, and leaves the authored `<h1>`, lede, body, and quiz between the header and the footnav untouched.
+A lesson carries its chrome as four marker pairs the authoring skill writes empty: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. This verb splices each one from the current workspace state, embedding the shared stylesheet and the script that settles the course panel before the page paints, rebuilding the course sidebar, the breadcrumb and jump menus, the prev/next footer nav, and the behavior scripts, and leaves the authored `<h1>`, lede, body, and quiz between the header and the footnav untouched.
 
 A workspace carrying no `course.css` gets its stylesheet pair seeded first, so the contents page it links is never unstyled, and an existing `course.css` is never overwritten. The embedded copy drops the seed's `@import` line, which resolved against the lesson's own folder and never loaded anything.
 
+That seeding fires on the absent file alone, so a workspace already holding a `course.css` has neither half rewritten here and its lessons go on embedding the sheet they were built against. A change to the shared chrome therefore takes `canon teach stylesheet <topic>` per workspace first, which rewrites `assets/base.css`, and then this verb to embed the result. Running this one alone renders every lesson missing whatever the change added, and nothing reports it.
+
 A lesson missing one of the four marker pairs is refused by name rather than rewritten, and every other lesson in the run still rewrites. The record's `skipped` list carries the refused files and which marker each is missing.
 
 The `style` region carries the quiz stepper after the workspace stylesheet, for every lesson but the one shape named three paragraphs down, so it wins the cascade at equal specificity and reaches a workspace seeded before it existed. The stepper is CSS over the radio inputs a quiz is written from: it hides every question that follows one holding no checked input, and hides a question's feedback until that question does. The general sibling combinator is what keeps that from depending on the markup contract holding, since it selects the same questions as the adjacent one for a quiz written correctly and goes on gating when anything sits between two of them, where the adjacent one matches nothing and shows them all at once. Gating there rather than in a script is what keeps a later stem from answering an earlier question with nothing to bind, and the whole block sits inside `@supports selector(:has(*))`, so an engine without `:has()` renders every question rather than a stepper showing nothing. Feedback there follows the workspace stylesheet, shown by one that says nothing about `.fb` and hidden by one grown under the retired script.

package/docs/workflow/ai-workflow.md

@@ -293,7 +293,7 @@ This section is the corpus the coverage claim is measured against: every name `c
 | `canon:migration-context`        | When `docs/` holds agent-flavored files belonging in `canon/context/`                  |
 | `canon:migration-superseded`     | When a drift report names a `.claude/` file a folder has replaced                      |
 | `canon:migration-standards-drop` | When the project still holds an installed `.claude/standards/` tree                    |
-| `canon:canon-feedback-file`      | When something in the toolkit is broken, missing, or off                               |
+| `canon:canon-feedback`           | When something in the toolkit is broken, missing, or off, to open an issue on it       |
 | `canon:canon-feedback-triage`    | In the toolkit repo, to work through the open feedback issues                          |
 | `canon:canon-rollout`            | In the toolkit repo, to take one change out to every consuming project at once         |
 
@@ -309,6 +309,7 @@ This section is the corpus the coverage claim is measured against: every name `c
 | `canon:draft-ready`       | For finished files a worker should copy, written as a ready folder with its overview, thin plan, and task                           |
 | `canon:draft-context`     | For a brand-new `canon/context/<domain>.md` entry, drafted against `standards/context.md`                                           |
 | `canon:draft-wireframes`  | For a brand-new `canon/wireframes/<surface>.md` file, drafted against `standards/wireframes.md`                                     |
+| `canon:draft-wiki`        | For a brand-new wiki reference page on a subject owned outside the project, drafted against `standards/wiki.md`                     |
 | `canon:draft-figure`      | For a hand-drawn figure inside an existing doc, drafted against `standards/figures.md` and rendered through Mermaid or freehand SVG |
 | `canon:draft-readme`      | For a project's `README.md`, drafted against `standards/readme.md`                                                                  |
 | `canon:bash-script`       | For an interactive, human-facing shell tool                                                                                         |

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.109.0",
+  "version": "4.110.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/src/claude/cases/authoring.ts

@@ -61,6 +61,11 @@ export const AUTHORING_CASES: readonly SkillCase[] = [
       'Draft a wireframe for the settings panel, nothing under canon/wireframes covers that surface yet.',
     expect: 'draft-wireframes',
   },
+  {
+    prompt:
+      'Write a wiki reference page for Claude Code output styles, no page covers that subject yet.',
+    expect: 'draft-wiki',
+  },
   {
     prompt: 'Say what that dense answer actually means in plain terms.',
     expect: 'restate-plainly',

package/src/claude/cases/setup.ts

@@ -64,7 +64,7 @@ export const SETUP_CASES: readonly SkillCase[] = [
   {
     prompt:
       'Something about the toolkit itself is broken, write it up and send it back to the maintainers.',
-    expect: 'canon-feedback-file',
+    expect: 'canon-feedback',
   },
   {
     prompt: