@erclx/canon 5.31.0 → 5.32.0

package/docs/workflow/skill-map.md

@@ -14,14 +14,10 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 
 ## Set up a project
 
-| Skill                  | When to use                                                                                                 |
-| ---------------------- | ----------------------------------------------------------------------------------------------------------- |
-| `canon:target-setup`   | On a fresh scaffold, to detect the stack and run the install chain, or to reach one phase of it alone       |
-| `canon:canon-operator` | On a project that already exists, to read what it carries before an install is picked                       |
-| `canon:sketch-design`  | Before `design-extract`'s greenfield path, to trace a design direction from reference images or URLs        |
-| `canon:design-extract` | Before the first UI feature, to draft `canon/DESIGN.md`                                                     |
-| `canon:deploy-app`     | Once a project is ready to publish, to set up its Cloudflare or Vercel deploy and stop for token and domain |
-| `canon:repo-metadata`  | When the GitHub About text, homepage, or topics may have drifted, to reconcile them against the README      |
+| Skill                | When to use                                                                                                 |
+| -------------------- | ----------------------------------------------------------------------------------------------------------- |
+| `canon:target-setup` | On a fresh scaffold, to detect the stack and run the install chain, or to reach one phase of it alone       |
+| `canon:deploy-app`   | Once a project is ready to publish, to set up its Cloudflare or Vercel deploy and stop for token and domain |
 
 ## Decide what to build
 
@@ -43,8 +39,7 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 | Skill                         | When to use                                                                                                |
 | ----------------------------- | ---------------------------------------------------------------------------------------------------------- |
 | `canon:session-worktree`      | At the plan-to-execute boundary, to get an isolated tree and branch, or to route a refused main-root write |
-| `canon:auto-ship`             | After plan approval, to chain implement, verify, review, draft PR                                          |
-| `canon:project-commands`      | When the project's own command needs running                                                               |
+| `canon:auto-ship`             | After plan approval, to chain implement, verify, draft PR                                                  |
 | `canon:test-first`            | Before implementing a planned change, to run its test red, green, then refactor                            |
 | `canon:test-craft`            | When writing or changing any test, to pick its layer and filter what it asserts                            |
 | `canon:build-in-slices`       | While building a plan, to commit each tested slice and note out-of-scope defects rather than fix them      |
@@ -60,28 +55,23 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 
 ## Check the work before it leaves the branch
 
-| Skill                    | When to use                                                                             |
-| ------------------------ | --------------------------------------------------------------------------------------- |
-| `canon:review-branch`    | On the local branch diff, before anything is pushed                                     |
-| `canon:document-health`  | When the documents themselves have to answer for length, placement, and staleness       |
-| `canon:markdown-propose` | When a markdown claim needs rewriting and the change should wait for an answer per file |
-| `canon:ux-audit`         | To read UI source for missing states, edge cases, and inconsistencies                   |
-| `canon:ux-measure`       | To start the interface and measure paint, processor, and layout cost                    |
-| `canon:ux-walkthrough`   | To run a multi-finding inspection pass over a running app with the operator             |
+| Skill                   | When to use                                                                       |
+| ----------------------- | --------------------------------------------------------------------------------- |
+| `canon:document-health` | When the documents themselves have to answer for length, placement, and staleness |
+| `canon:ux-audit`        | To read UI source for missing states, edge cases, and inconsistencies             |
+| `canon:ux-measure`      | To start the interface and measure paint, processor, and layout cost              |
 
 ## Ship it
 
-| Skill                  | When to use                                                                           |
-| ---------------------- | ------------------------------------------------------------------------------------- |
-| `canon:git-ship`       | To run the whole post-feature chain from the verify gate through open PR              |
-| `canon:memory-capture` | First skill in that chain, to route what the session learned to the surface owning it |
-| `canon:context-fold`   | When decisions diverged from the plan, or a shipped task needs its outcomes marked    |
-| `canon:docs-sync`      | When a change since main left `README.md` or `docs/` stale                            |
-| `canon:git-stage`      | When the staged set spans several concerns and wants one commit each                  |
-| `canon:git-commit`     | When the staged set is one concern, or was staged hunk by hand                        |
-| `canon:git-branch`     | When a branch name needs generating or renaming to conventional form                  |
-| `canon:git-pr`         | When a pull request needs a title and body written from the diff                      |
-| `canon:memory-review`  | When the pen has grown, to propose where each entry belongs                           |
+| Skill                | When to use                                                                        |
+| -------------------- | ---------------------------------------------------------------------------------- |
+| `canon:git-ship`     | To run the whole post-feature chain from the verify gate through open PR           |
+| `canon:context-fold` | When decisions diverged from the plan, or a shipped task needs its outcomes marked |
+| `canon:docs-sync`    | When a change since main left `README.md` or `docs/` stale                         |
+| `canon:git-stage`    | When the staged set spans several concerns and wants one commit each               |
+| `canon:git-commit`   | When the staged set is one concern, or was staged hunk by hand                     |
+| `canon:git-branch`   | When a branch name needs generating or renaming to conventional form               |
+| `canon:git-pr`       | When a pull request needs a title and body written from the diff                   |
 
 ## After the pull request opens
 
@@ -113,7 +103,5 @@ Each row sits under the group its skill's `metadata.family` names. The landing p
 | Skill                         | When to use                                                                            |
 | ----------------------------- | -------------------------------------------------------------------------------------- |
 | `canon:target-check`          | In a target project, to report per domain what it holds against what the toolkit ships |
-| `canon:seed-sync`             | After a toolkit update, to reconcile installed seeds without losing customizations     |
 | `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         |
+| `canon:canon-feedback-triage` | In the toolkit repo, to file the open feedback issues into an intake folder            |

package/docs/workflow/visual-design-workflow.md

@@ -1,6 +1,6 @@
 ---
 title: Visual design workflow
-description: Tiered guide for design and wireframe authoring with Claude Code
+description: Tiered guide for design authoring with Claude Code
 category: Workflow
 ---
 
@@ -14,17 +14,17 @@ The tier framework sits alongside [Claude Design](../../wiki/claude/design.md),
 
 ## Tier 0: prose only
 
-The default. `canon/DESIGN.md` holds visual intent as token tables for color, typography, spacing, and borders, with one Personality paragraph and at most three one-line rules a section, motion and iconography included. `.claude/WIREFRAMES.md` holds each surface's regions and states.
+The default. `canon/DESIGN.md` holds visual intent as token tables for color, typography, spacing, and borders, with one Personality paragraph and at most three one-line rules a section, motion and iconography included.
 
-Claude Code reads both and writes the implementation. Works for CLI tools, internal dashboards, admin panels, and backend-focused projects.
+Claude Code reads it and writes the implementation. Works for CLI tools, internal dashboards, admin panels, and backend-focused projects.
 
 ### Seed shape
 
 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.
 
-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/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design/index.md`.
+`canon design render` writes an HTML plus CSS preview to `.canon/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design/index.md`.
 
-A project wanting a neutral starting point to override runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying an achromatic token set as custom properties and two components built on them. Greys run from near-black to near-white and the accent is monochrome, so the only palette the project renders is one it writes itself. 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.
+A project wanting a neutral starting point to override runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying an achromatic token set as custom properties and two components built on them. Greys run from near-black to near-white and the accent is monochrome, so the only palette the project renders is one it writes itself. 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 the project wrote is its own, and the installed stylesheet is the toolkit's.
 
 A cell no source anchors ends in `? verify`, and the preview shows that marker beside the value rather than folding it in, so a swatch and a font sample stay built from the value alone. A confidence line above the sections names how many cells are anchored against how many are tagged, which is what tells a reader whether they are looking at a record of the code or a proposal about it. It reads the columns a source could anchor and leaves out the row names, so the ratio is not diluted by cells no tag could ever reach. The proposal path tags nearly all of them, so that count reads low on day one by design.
 
@@ -35,14 +35,11 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
 
 ### Skills
 
-- `canon:sketch-design` to trace a design direction from reference images or URLs, before `design-extract`'s greenfield path proposes from a personality paragraph alone
-- `canon:design-extract` to draft `canon/DESIGN.md`, from existing project signals or from requirements alone on day one
 - `canon:ui-checklist` for what a reviewer has to look at after UI changes, and what ships without a test
 - `canon:ux-audit` for UX gap detection on existing surfaces
 - `canon:ux-measure` for what a running surface costs to paint, read against published thresholds
-- `canon:draft-and-pick` for a call settled by looking, drafting several candidates onto one page and taking your pick
+- `canon:draft-and-pick` for a call settled by looking, drafting several candidates as frames on the canvas and taking your pick
 - `canon:canvas` for a direction worked out over several turns, drawn as HTML frames you drag, select, and restyle in the browser while the session reads your changes back. Only the pick moves into `canon/DESIGN.md`, since the canvas folder is gitignored
-- `canon:ux-walkthrough` for a multi-finding inspection pass over a running app with the operator, drafting arms from the app's own markup and recording each pick for a builder
 - `canon:draft-identity` to draft a project's logo mark and compose it into an icon sequence and a social card, through `draft-and-pick`'s own render-and-pick loop. On an Astro project holding the card route scaffold, the card lands as a route the project keeps and is captured through a running server, so it reads the project's real stylesheet rather than typed copies of every color. Everywhere else it ships as a PNG and the run says so.
 - Anthropic's `frontend-design` plugin optional for light visual steering
 
@@ -55,16 +52,16 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
 
 ## Tier 1: visual companion
 
-ASCII and prose stay as source of truth. Add a visual render as a feedback surface for the agent and for human review.
+Prose stays as source of truth. Add a visual render as a feedback surface for the agent and for human review.
 
-- Excalidraw handles agent-driven wireframes when the round-trip canvas loop matters
+- Excalidraw handles agent-drawn layouts when the round-trip canvas loop matters
 - Claude Design joins only when codebase extraction or the annotated handoff bundle is worth the ceiling cost
 
 Both produce derived artifacts, so human edits are review annotations rather than source changes.
 
 ### Seed shape
 
-Same as tier 0 with one addition. `WIREFRAMES.md` opts into Excalidraw rendering via a top-of-file marker like `<!-- excalidraw: WIREFRAMES.excalidraw -->`. `DESIGN.md` stays human-maintained.
+Same as tier 0. `DESIGN.md` stays human-maintained.
 
 Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in its own 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.
 
@@ -91,7 +88,7 @@ Impeccable, if installed, keeps its own root `DESIGN.md` and `PRODUCT.md` in its
 
 The two tools solve non-overlapping halves of the visual companion problem.
 
-Excalidraw gives the agent a canvas it can read back over MCP. Output is agent-facing and persists as a JSON file in the repo. Pick it when Claude Code needs to iterate on wireframes autonomously, not when a human needs polished review artifacts.
+Excalidraw gives the agent a canvas it can read back over MCP. Output is agent-facing and persists as a JSON file in the repo. Pick it when Claude Code needs to iterate on layouts autonomously, not when a human needs polished review artifacts.
 
 Claude Design reads the raw codebase without prose curation and produces a polished handoff bundle with chat history. Weekly quota makes it expensive, so reserve it for the extraction pass or the final handoff moment, not daily iteration.
 
@@ -147,4 +144,4 @@ Resist over-tiering early. Moving up is cheap because tiers stack. Moving down m
 - `canon/context/claude-plugin/skill-strategy/overview.md`: how to decide between workflow and domain-knowledge skills
 - [`microsoft/playwright-mcp`](https://github.com/microsoft/playwright-mcp): browser automation MCP used in tier 1 and tier 2
 - [`ChromeDevTools/chrome-devtools-mcp`](https://github.com/ChromeDevTools/chrome-devtools-mcp): live frontend debugging MCP used in tier 1 and tier 2
-- [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw): community MCP server behind the tier 1 wireframe companion
+- [`yctimlin/mcp_excalidraw`](https://github.com/yctimlin/mcp_excalidraw): community MCP server behind the tier 1 visual companion

package/governance/renames.toml

@@ -20,24 +20,14 @@
 [renamed]
 "015-output" = "566-output"
 "035-tasks" = "602-tasks"
-"045-memory" = "603-memory"
 "055-scratch" = "604-scratch"
 "085-worktrees" = "605-worktrees"
 "087-git" = "606-git"
 "510-context" = "610-context"
 "511-indexes" = "611-indexes"
-"520-wireframes" = "620-wireframes"
-"530-requirements" = "630-requirements"
-"540-architecture" = "640-architecture"
 "550-design" = "650-design"
 "555-tasks" = "655-tasks"
-"556-groundwork" = "656-groundwork"
-"557-intake" = "657-intake"
 "558-plan" = "658-plan"
-"559-memory" = "659-memory"
-"561-teach" = "661-teach"
-"562-session" = "662-session"
-"563-ready" = "663-ready"
 "501-markdown" = "801-markdown"
 "580-readme" = "880-readme"
 "591-standard-authoring" = "891-standard-authoring"
@@ -47,17 +37,8 @@
 "090-code-comments" = "790-code-comments"
 "658-plan" = "plan"
 "610-context" = "context"
-"620-wireframes" = "wireframes"
-"630-requirements" = "requirements"
-"640-architecture" = "architecture"
 "650-design" = "design"
 "655-tasks" = "tasks"
-"656-groundwork" = "groundwork"
-"657-intake" = "intake"
-"659-memory" = "memory"
-"661-teach" = "teach"
-"662-session" = "session"
-"663-ready" = "ready"
 "570-skill" = "skill"
 "590-rule-authoring" = "rule"
 "801-markdown" = "markdown"

package/governance/rules/canon/605-worktrees.md

@@ -10,5 +10,5 @@ description: Enter a linked worktree for implementation, resolve shared session
 
 ## Shared session scratch
 
-- Shared session scratch (`.canon/plans/`, `.canon/review/`, `.canon/memory/`, `.canon/tasks/`) lives at the main worktree root, not inside a linked worktree. From a linked worktree, resolve these paths against the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. Fall back to `pwd` if not a git repo.
+- Shared session scratch (`.canon/plans/`, `.canon/review/`, `.canon/tasks/`) lives at the main worktree root, not inside a linked worktree. From a linked worktree, resolve these paths against the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. Fall back to `pwd` if not a git repo.
 - From a linked worktree, or from a background session that entered none, `Edit` and `Write` refuse a main-root path and redirect to a worktree copy no later session reads. Never take that redirect. Route the write the way the `session-worktree` skill states, and report it rather than proceeding silently when that skill does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.

package/governance/rules/{standards → canon}/plan.md

@@ -1,19 +1,18 @@
 ---
-# Generated by `canon gov regen` from standards/plan.md. Edit that frontmatter, not this file.
-description: Filename and slug, the required sections, and the suggested-and-answer contract for a feature plan
+description: Route edits under .canon/plans/ to the plan-feature skill for the plan's sections, the answer contract, and its lifecycle
 paths:
   - '.canon/plans/**'
 ---
 
 # Plan standards
 
-## Authority
+## Plan files
 
-- Follow the plan standard for filename and slug, the required sections, and the suggested-and-answer contract for a feature plan. It is the single source. Read it with `canon standards plan`.
+- Load the `canon:plan-feature` skill before a hand edit under `.canon/plans/`. It carries the filename and slug, the required sections, and the suggested-and-answer contract for a feature plan. Report it rather than proceeding silently when the skill does not resolve.
 - Never fill an `- Answer:` slot on behalf of the person who owns it. A blank slot accepts the suggestion at execution time.
 - Never ship a question without a `- Suggested:` line. Write `- Suggested: needs your call, <why>` where the answer turns on preference.
 - Rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement when execution deviates from an unanswered question, leaving the slot blank. Put the same deviation in one line under the open task's `## Findings`.
 - Fetch the source a decision rests on and quote the passage under `**Sources:**`, or mark the entry `unverified`. Never cite an outside source from recall.
 - Move a shipped plan to `.canon/plans/archive/`. Never delete one.
 - Amend a plan in place when a decision changes. Do not append a second passage narrating the change.
-- Follow the plan lifecycle standard for when a plan is written, how it is amended, and its move to the archive. Read it with `canon standards plan-lifecycle`.
+- Follow the lifecycle the `canon:plan-feature` skill carries for when a plan is written, how it is amended, and its move to the archive.

package/governance/rules/canon/tasks.md

@@ -0,0 +1,18 @@
+---
+description: Route edits under .canon/tasks/ to the task-board skill for task shape, the board, and a declined task, and keep a session handoff apart from a task
+paths:
+  - '.canon/tasks/**'
+---
+
+# Tasks standards
+
+## Task files
+
+- Load the `canon:task-board` skill before a hand edit under `.canon/tasks/`. It carries the folder layout, filename convention, file format, origin lines, and archiving for a task file. Report it rather than proceeding silently when the skill does not resolve.
+- Follow the board shape the `canon:task-board` skill carries for `priority.md` and `backlog.md`, their readiness groups, and row order.
+- Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter.
+- Follow the decline shape the `canon:task-board` skill carries for a task decided against.
+
+## Session handoffs
+
+- Treat a `.canon/tasks/session-*.md` file as a handoff governed by the `canon:session-map` skill. It is not a task and carries neither `## Outcomes` nor `## Findings`.

package/governance/stacks/base.toml

@@ -8,4 +8,4 @@ extends = ""
 # project loads no rule it can never apply. `standards` holds one rule per
 # standard routing its paths to it, generated by `canon gov regen` from each
 # standard's frontmatter rather than authored.
-rules = ["canon", "claude", "standards", "tooling", "writing", "120-bash"]
+rules = ["canon", "claude", "standards", "tooling", "writing"]

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "5.31.0",
+  "version": "5.32.0",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
   "license": "MIT",
   "bin": {

package/scripts/core/install-check.sh

@@ -101,7 +101,7 @@ log_step "Assert scaffold"
 # scaffold reads a standard through `canon standards <name>`, resolving against
 # the toolkit rather than a copy this gate could assert on. The two
 # rule paths stand for the `claude` and `canon` groups `base` takes whole.
-for path in "CLAUDE.md" ".claude/wiki/index.md" ".claude" "canon/context/index.md" "canon/wireframes/index.md" \
+for path in "CLAUDE.md" ".claude/wiki/index.md" ".claude" "canon/context/index.md" \
   ".prettierrc" ".editorconfig" ".lintstagedrc" ".husky/pre-commit" ".github/workflows/verify.yml" "scripts/verify.sh" \
   ".claude/rules/canon/claude/566-output.md" ".claude/rules/canon/canon/604-scratch.md"; do
   if [ ! -e "$TARGET_DIR/$path" ]; then

package/scripts/core/regen-web-previews.ts

@@ -43,7 +43,7 @@ console.log('regen-web-previews: wrote web/public/previews/design-tokens/')
  * chrome over a scratch copy holding this one workspace alone is what keeps
  * the jump menus from naming anything else.
  *
- * `.canon/teach/` is gitignored session scratch, per `standards/teach.md`, so
+ * `.canon/teach/` is gitignored session scratch, per `claude/skills/teach-workspace/references/teach.md`, so
  * it exists on the machine that authored the lesson and nowhere else,
  * including CI. `web/public/previews/teach-workspace/` is therefore the
  * durable copy: committed once the workspace exists, regenerated here as a

package/src/audits/catalog.ts

@@ -139,100 +139,12 @@ function allOf(
   return counts
 }
 
-/**
- * Reads the architecture record's measures, or nothing when the project
- * carries no record.
- *
- * Three states rather than two, matching what the verb publishes. The key
- * absent is a run that never opened the record, which the aggregate never asks
- * for and so reads as a shape that moved. Null is a project entitled to carry
- * no record, whose other context counts still stand, so it contributes no key
- * rather than a zero that would read as a conforming record.
- */
-function architectureCounts(
-  root: Record<string, unknown>,
-): Record<string, number> | undefined | 'absent' {
-  if (!('architecture' in root)) return undefined
-  if (root.architecture === null) return 'absent'
-
-  const record = asObject(root.architecture)
-  const decisions = record?.decisions
-  if (
-    record === undefined ||
-    !Array.isArray(decisions) ||
-    typeof record.lines !== 'number'
-  ) {
-    return undefined
-  }
-
-  // A record stating no length rule has no ceiling to be past, and reporting
-  // zero there would read as one measured and found conforming.
-  const ceiling =
-    typeof record.ceiling === 'number' ? record.ceiling : undefined
-  const entryCap =
-    typeof record.entryCap === 'number' ? record.entryCap : undefined
-
-  const revisitRequired = record.revisitRequired === true
-  const wordCap =
-    typeof record.wordCap === 'number' ? record.wordCap : undefined
-  const riskCap =
-    typeof record.riskCap === 'number' ? record.riskCap : undefined
-  const risksBullets =
-    typeof record.risksBullets === 'number' ? record.risksBullets : undefined
-
-  let unverifiable = 0
-  let unchecked = 0
-  let lackingRevisit = 0
-  let overWords = 0
-  for (const raw of decisions) {
-    const entry = asObject(raw)
-    const claim = entry?.claim
-    const checks = lengthOf(entry?.checks)
-    if (typeof claim !== 'string' || checks === undefined) return undefined
-
-    if (claim === 'neither') unverifiable += 1
-    else if (checks === 0) unchecked += 1
-    if (revisitRequired && entry?.revisit !== true) lackingRevisit += 1
-    if (
-      wordCap !== undefined &&
-      typeof entry?.words === 'number' &&
-      entry.words > wordCap
-    ) {
-      overWords += 1
-    }
-  }
-
-  return {
-    // A boolean, counted so the aggregate reads it the way it reads every
-    // other measure. The verb gates on it separately, and the key is absent
-    // rather than zero on a record that declared no ceiling.
-    ...(ceiling !== undefined && {
-      recordOverLength: record.lines > ceiling ? 1 : 0,
-    }),
-    // Absent on a record stating no entry cap, for the same reason.
-    ...(entryCap !== undefined && {
-      recordOverCount: decisions.length > entryCap ? 1 : 0,
-    }),
-    // Absent on a record stating no revisit clause, for the same reason.
-    ...(revisitRequired && { recordMissingRevisit: lackingRevisit }),
-    // Absent on a record stating no word cap or no bullet cap, for the same
-    // reason, and the bullet key absent too on a record with no Risks section.
-    ...(wordCap !== undefined && { recordOverWords: overWords }),
-    ...(riskCap !== undefined &&
-      risksBullets !== undefined && {
-        recordOverRisks: risksBullets > riskCap ? 1 : 0,
-      }),
-    recordUnverifiable: unverifiable,
-    recordUnchecked: unchecked,
-  }
-}
-
 /**
  * Reads the requirements record's one cap, or nothing when the record is
  * absent, states no cap, or the run never opened it.
  *
- * The key is optional rather than required the way `architecture` is, so a
- * record from a binary predating it still counts its other findings.
+ * The key is optional, so a record from a binary predating it still counts
+ * its other findings.
  */
 function requirementsCounts(
   root: Record<string, unknown>,
@@ -301,8 +213,6 @@ function contextCounts(record: unknown): Record<string, number> | undefined {
     bareReferences += bare
   }
 
-  const architecture = architectureCounts(root)
-  if (architecture === undefined) return undefined
   const requirements = requirementsCounts(root)
 
   const counts = allOf({
@@ -314,9 +224,7 @@ function contextCounts(record: unknown): Record<string, number> | undefined {
   })
 
   if (counts === undefined) return undefined
-  return architecture === 'absent'
-    ? { ...counts, ...requirements }
-    : { ...counts, ...architecture, ...requirements }
+  return { ...counts, ...requirements }
 }
 
 function markdownCounts(record: unknown): Record<string, number> | undefined {
@@ -587,8 +495,8 @@ export const AUDITS: readonly AuditSpec[] = [
     corpus: 'tracked',
     // The one reason this verb refuses for that is an absence rather than a
     // break, on the same test the reach check and the skill audit take: no
-    // target adopts `canon/context/`, an older install's `.canon/diagrams/`,
-    // and `canon/wireframes/` all at once, so without the allowance every such
+    // target adopts `canon/context/` and an older install's `.canon/diagrams/`
+    // both, so without the allowance every such
     // project reports the verb unmeasured on every run and never changes.
     absentReasons: ['no-folders'] satisfies ContextAuditRefusal[],
     counts: contextCounts,

package/src/claude/cases/authoring.ts

@@ -10,19 +10,10 @@ export const AUTHORING_CASES: readonly SkillCase[] = [
       'Wire up a GitHub Actions pipeline with parallel jobs for this repo.',
     expect: 'ci-workflow',
   },
-  {
-    prompt:
-      'Write me a headless automation script with no interactive prompts.',
-    expect: 'bash-cli-script',
-  },
   {
     prompt: 'Scaffold a brand-new SKILL.md for this capability.',
     expect: 'create-skill',
   },
-  {
-    prompt: 'Write a fresh authoring convention as a new standard file.',
-    expect: 'create-standard',
-  },
   {
     prompt:
       "The docs folder and README are stale against what's on main, refresh them.",
@@ -47,20 +38,11 @@ export const AUTHORING_CASES: readonly SkillCase[] = [
       'Write a context entry for the payments domain, there is no canon/context page for it yet.',
     expect: 'draft-doc',
   },
-  {
-    prompt:
-      'Draft a wireframe for the settings panel, nothing under canon/wireframes covers that surface yet.',
-    expect: 'draft-doc',
-  },
   {
     prompt:
       'Write a wiki reference page for Claude Code output styles, no page covers that subject yet.',
     expect: 'draft-doc',
   },
-  {
-    prompt: 'Say what that dense answer actually means in plain terms.',
-    expect: 'restate-plainly',
-  },
   {
     prompt: 'This passage reads flat and robotic, give it some real cadence.',
     expect: 'write-human',

package/src/claude/cases/misc.ts

@@ -22,20 +22,11 @@ export const MISC_CASES: readonly SkillCase[] = [
       'This project has no logo yet. Draft one and give me a social card to go with it.',
     expect: 'draft-identity',
   },
-  {
-    prompt:
-      "I found two sites whose look I want us to draw from. Put them side by side and let's settle which one the design should follow before anyone writes a token.",
-    expect: 'sketch-design',
-  },
   {
     prompt:
       'Draw the signup screen as a frame on the canvas, then restyle the element I just selected there.',
     expect: 'canvas',
   },
-  {
-    prompt: 'Fire up the dev server the way this project documents it.',
-    expect: 'project-commands',
-  },
   {
     prompt:
       "We're about to hit the context limit, write the handoff before we lose state.",
@@ -104,10 +95,6 @@ export const MISC_CASES: readonly SkillCase[] = [
       'The old parseDate helper was replaced months ago. Can I just delete it, or could a few files still be calling it?',
     expect: 'deprecation-migration',
   },
-  {
-    prompt: 'Does our github about text still match what the readme says?',
-    expect: 'repo-metadata',
-  },
   {
     prompt: 'Connect this repo to Cloudflare Pages and set up the deploy.',
     expect: 'deploy-app',

package/src/claude/cases/setup.ts

@@ -45,14 +45,6 @@ export const SETUP_CASES: readonly SkillCase[] = [
       'Something about the toolkit itself is broken, write it up and send it back to the maintainers.',
     expect: 'canon-feedback',
   },
-  {
-    prompt:
-      "I don't know which specific toolkit skill I need, just handle it for me.",
-    expect: 'canon-operator',
-  },
-  // The performing skill wins a phrase naming its operation over the front
-  // door's own routing framing, even though canon-operator's description
-  // quotes a phrase near this one. See canon/context/cli/audits/routing.md.
   {
     prompt:
       "Whatever the right toolkit command is, get this project's rules installed.",
@@ -60,20 +52,11 @@ export const SETUP_CASES: readonly SkillCase[] = [
   },
   {
     prompt:
-      'Work through the open feedback issues on the toolkit repo one by one.',
+      'File the open feedback issues on the toolkit repo into an intake folder.',
     expect: 'canon-feedback-triage',
   },
-  // The outbound direction is what separates this from the front door above.
-  // canon-operator runs inside one project the session already stands in, and
-  // this reaches every project the toolkit installed into from the toolkit.
-  {
-    prompt:
-      'Take this change out to every project that installed the toolkit and get each one to a pull request.',
-    expect: 'canon-rollout',
-  },
-  // Reporting per domain is what separates this from canon-operator, which
-  // diagnoses on the way to running the operation an intent named. This answers
-  // one fixed question across a fixed domain list and repairs nothing.
+  // This answers one fixed question across a fixed domain list and repairs
+  // nothing, which is what separates it from the setup skill above.
   {
     prompt:
       'Report what this project has fallen behind the toolkit on, domain by domain, and fix nothing.',

package/src/claude/cases/workflow.ts

@@ -20,10 +20,6 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
       'Run the whole implement, verify, review, and ship pipeline for the approved plan.',
     expect: 'auto-ship',
   },
-  {
-    prompt: "Pull together a design system from what's already in the app.",
-    expect: 'design-extract',
-  },
   {
     prompt: 'Draw me a diagram of how the pieces of this system connect.',
     expect: 'draft-figure',
@@ -61,20 +57,6 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
     prompt: 'Walk me through the open intake items so I can decide on each.',
     expect: 'plan-intake-answer',
   },
-  {
-    prompt:
-      "Draft a diff-based proposal for tightening this passage in the standard, don't just edit it.",
-    expect: 'markdown-propose',
-  },
-  {
-    prompt: 'Pull the durable lessons out of this session before it ends.',
-    expect: 'memory-capture',
-  },
-  {
-    prompt:
-      'Go through the memory folder and propose what to do with each entry.',
-    expect: 'memory-review',
-  },
   {
     prompt:
       'Take on the orchestrator role and coordinate the parallel feature builds.',
@@ -104,11 +86,6 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
       'The screencast draft is finished. Turn it into an actual video now.',
     expect: 'record-screencast',
   },
-  {
-    prompt:
-      'Look over everything that changed on this branch for bugs and edge cases.',
-    expect: 'review-branch',
-  },
   {
     prompt:
       'What should a review of a change look for beyond bugs, and how much evidence does a finding need?',
@@ -128,11 +105,6 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
     prompt: 'Draft me a script with beats for a screencast recording.',
     expect: 'draft-screencast',
   },
-  {
-    prompt:
-      "Check whether my installed Claude seed docs have drifted from the toolkit's.",
-    expect: 'seed-sync',
-  },
   {
     prompt: 'Turn this topic into a slide deck I can render.',
     expect: 'draft-slides',
@@ -173,11 +145,6 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
     prompt: 'Tell me the paint and layout cost of this page right now.',
     expect: 'ux-measure',
   },
-  {
-    prompt:
-      'Sit with me while I go through my whole list of app findings one at a time, and write down each pick with what it beat.',
-    expect: 'ux-walkthrough',
-  },
   {
     prompt:
       'I am building this branch for another session. What am I on the hook for, and what is off limits?',

package/src/claude/seeds.ts

@@ -17,13 +17,7 @@ const HOOKS = 'hooks'
  * stem in an older layout, which is what `@/sync/layout` pairs a target against
  * to find a superseded artifact.
  */
-export const SUBDIRS: readonly string[] = [
-  HOOKS,
-  'context',
-  'memory',
-  'tasks',
-  'wireframes',
-]
+export const SUBDIRS: readonly string[] = [HOOKS, 'context', 'memory', 'tasks']
 
 export type SeedScope = 'claude' | 'root'