@erclx/canon 4.103.0 → 4.105.0

package/src/commands/sync.ts

@@ -109,7 +109,7 @@ function renderCheck(report: CheckReport): void {
     logStep('Not a toolkit project')
     logWarn('No .claude/ directory and no CLAUDE.md at the target.')
     logInfo(
-      'Run `canon init` to install, or /canon:setup-init to resolve a stack.',
+      'Run `canon init` to install, or /canon:target-setup to resolve a stack.',
     )
     outro()
     return

package/src/commands/tasks.ts

@@ -218,6 +218,7 @@ export function register(program: Command): void {
         '',
         'Checks:',
         '  every Run now row points at a plan file that resolves',
+        '  no Needs a plan row has a live plan, and every Up next row has one',
         '  every task file carries a board row or a backlog line, never both',
         '  no task carries more than one row',
         '  no two Run now rows touch the same file',

package/src/design/document.ts

@@ -134,6 +134,8 @@ export function renderDesignDocument(tokens: DesignTokens = TOKENS): string {
       ),
     ),
     '',
+    section('Layout', tokens.layout),
+    '',
     section('Motion', tokens.motion),
     '',
     section('Iconography', tokens.iconography),

package/src/design/tokens.ts

@@ -70,6 +70,7 @@ export interface DesignTokens {
   readonly spacingNote: string
   readonly borders: readonly BorderToken[]
   readonly bordersNote: string
+  readonly layout: string
   readonly motion: string
   readonly iconography: string
   readonly preamble: string
@@ -371,6 +372,9 @@ export const TOKENS: DesignTokens = {
     },
   ],
 
+  layout:
+    'Capture widths are 320, 768, 1280 and 1536 pixels, declared once in `tooling/web/configs/e2e/screenshot.ts`, with 320 and 1280 committed as evidence. 320 is the reflow floor and the rest are the breakpoint buckets. The landing page under `web/` sets its own `max-width` media queries between 430 and 1100 pixels per component rather than from a shared scale.',
+
   motion:
     'Motion is not used. No transition, animation, or keyframe declaration appears on any rendered surface, and the capture pipeline screenshots a static frame.',
 

package/src/gate/measures.ts

@@ -629,6 +629,63 @@ export const shippedReferences: Measure = async (ctx) => {
   }
 }
 
+const RAW_FIELD_FILE_REFERENCE = /(?:^|\s)(?:-f|--raw-field)[ =]\S+=@/
+
+/**
+ * A `gh api` raw-string flag carrying a file reference, over the seven shipped
+ * corpora.
+ *
+ * `-f body=@<path>` sends the literal path as the field value, so a comment
+ * edited that way is overwritten with the path itself and loses the marker a
+ * later read resolves it by. `-F` is the flag that reads the file. The pattern
+ * requires `=@`, so `-F`, `--field`, and a raw string such as `-f body="text"`
+ * all pass.
+ *
+ * It scans prose rather than parsing a command, so a body quoting the wrong
+ * spelling to explain it fails too. Reword it rather than exempting it, since an
+ * exemption is what lets a real occurrence hide.
+ */
+export const rawFieldFileReference: Measure = async (ctx) => {
+  const files = shippedCorpusFiles(ctx.root)
+
+  if (files.length === 0) {
+    return {
+      emissions: [],
+      unmeasured: `No corpus under ${SHIPPED_CORPORA.join(', ')} is present, so no shipped file was read.`,
+    }
+  }
+
+  const found = files.flatMap((file) =>
+    readFileSync(join(ctx.root, file), 'utf8')
+      .split('\n')
+      .flatMap((text, index) =>
+        RAW_FIELD_FILE_REFERENCE.test(text) ? [`${file}:${index + 1}`] : [],
+      ),
+  )
+
+  if (found.length === 0) {
+    return {
+      emissions: [
+        info(
+          `No raw-field file reference across ${files.length} files in ${SHIPPED_CORPORA.length} shipped corpora`,
+        ),
+      ],
+    }
+  }
+
+  return {
+    emissions: found.map((location) =>
+      warn(
+        `${location} passes a file reference through a raw-string flag, which posts the path as the field value. Use -F instead`,
+      ),
+    ),
+    failure:
+      found.length === 1
+        ? 'One raw-field file reference in the shipped corpora. Change -f or --raw-field to -F or --field where the value reads a file with @, or reword a prose line quoting the wrong spelling.'
+        : `${found.length} raw-field file references in the shipped corpora. Change -f or --raw-field to -F or --field where the value reads a file with @, or reword a prose line quoting the wrong spelling.`,
+  }
+}
+
 /**
  * Every git-tracked file quoting a listed client command with the wrong
  * argument, over the whole tree rather than one corpus, since a wrong

package/src/gate/stages.ts

@@ -10,6 +10,7 @@ import {
   recordIdempotence,
   sandboxCoverage,
   seedStandards,
+  rawFieldFileReference,
   shippedReferences,
   standardCriteria,
   unreferencedRules,
@@ -207,20 +208,6 @@ export const STAGES: readonly Stage[] = [
     ],
     success: 'Hero clean',
   },
-  {
-    id: 'tooling-paths',
-    label: 'Tooling paths',
-    checks: [
-      script('regen-tooling-paths.sh', 'Tooling-path regen failed'),
-      {
-        kind: 'drift',
-        pathspec: 'claude/skills/canon-cli/SKILL.md',
-        failure:
-          'The overwrite contract drifted from what the stacks hold. Run bun run check and commit claude/skills/canon-cli/SKILL.md.',
-      },
-    ],
-    success: 'Tooling paths clean',
-  },
   {
     // `canon/DESIGN.md`, the base stylesheet, the web stylesheet, and the
     // tab icon are all written from `src/design/tokens.ts` and none is edited
@@ -423,6 +410,15 @@ export const STAGES: readonly Stage[] = [
     skipped: 'No shipped corpus changed, so no reference was read',
     checks: [{ kind: 'measure', measure: shippedReferences }],
   },
+  {
+    // Same corpora as shipped-references and a separate stage, since the
+    // verdict is a flag spelling rather than an unresolvable reference.
+    id: 'raw-field-file-reference',
+    label: 'Raw-field file references',
+    scope: new RegExp(SHIPPED_CORPORA.map((corpus) => `^${corpus}/`).join('|')),
+    skipped: 'No shipped corpus changed, so no flag was read',
+    checks: [{ kind: 'measure', measure: rawFieldFileReference }],
+  },
   {
     // Scoped to the two files a citation can drift between, so an edit to
     // either one runs the check. web/src/content/copy.ts carries the anchors

package/src/gov/list.ts

@@ -30,7 +30,7 @@ export interface GovCatalog {
 
 /**
  * Reports each stack's own entries expanded, so a folder entry reaches a
- * consumer as the rules it stands for. `setup-gov` dedupes `--add` extras
+ * consumer as the rules it stands for. the `setup` skill dedupes `--add` extras
  * against this list, and a stack answering `core` there would re-add every
  * rule that folder already carries.
  *

package/src/sandbox/census.ts

@@ -71,9 +71,9 @@ export function listSkills(root: string): string[] {
  *
  * `<category>-<command>` is the rule `canon/context/sandbox/coverage.md` states, and it
  * alone pairs 29 of 54 skills. The bare `<command>` fallback is what reaches the
- * rest: `claude/setup-init.sh` drives the `setup-init` skill, not a
- * `claude-setup-init` that does not exist. Stating one spelling and shipping two
- * is what let the audit report a paired skill as unpaired.
+ * rest: `claude/target-setup.sh` drives the `target-setup` skill, not a `claude-target-setup` that
+ * does not exist. Stating one spelling and shipping two is what let the audit
+ * report a paired skill as unpaired.
  *
  * Returns undefined for a scenario driving no skill at all, which is every
  * `infra/` and `tooling/` scenario. Those exercise a CLI domain rather than a

package/src/shipped/references.ts

@@ -210,7 +210,7 @@ const PHASE_LABEL = /\bv\d+\.\d+(?!\.\d)\b/g
  *
  * Anchored on the trailing `\d{3}-[\w-]+\.md` rather than on the bare
  * `.claude/rules/` prefix, which is what keeps a folder mention carrying no
- * number, such as `create-rule`, `memory-review`, and `setup-gov` already
+ * number, such as `create-rule`, `memory-review`, and `target-setup` already
  * write correctly, from matching. The segment group between `rules/` and the
  * numbered file admits both a governance-namespace path
  * (`canon/core/055-scratch.md`) and a project-namespace one

package/src/tasks/validate.ts

@@ -8,6 +8,7 @@ import {
   readOutcomes,
   readPlanTarget,
   readPullRequest,
+  resolveLivePlan,
   tasksDir,
 } from '@/tasks/archive'
 import { gitTrunkReader, type TrunkReader } from '@/tasks/trunk'
@@ -38,6 +39,8 @@ export const FINDING_KINDS = [
   'plan-unresolved',
   'plan-uncited',
   'plan-mismatched',
+  'plan-parked',
+  'plan-absent',
   'task-unresolved',
   'row-duplicated',
   'row-misshapen',
@@ -747,6 +750,70 @@ async function planDisagreement(
   }
 }
 
+/**
+ * Tests the claim a group name makes about a plan. `## Needs a plan` says none
+ * is live and `## Up next` says one is written, and neither group has a `Plan`
+ * column, so the task file's own `Plan:` line is the only place either claim
+ * can be read against.
+ *
+ * A live plan is one the archive's resolution accepts and the disk holds, so a
+ * plan already archived reads as not live and a cited path with no file behind
+ * it reads the same way. A row whose task file is gone is left to
+ * `task-unresolved`, which owns that report.
+ */
+async function checkGroupClaims(
+  rows: readonly BoardRow[],
+  dir: string,
+  root: string,
+): Promise<Finding[]> {
+  const parked = rows.filter(
+    (row) => row.group === 'Needs a plan' || row.group === 'Up next',
+  )
+
+  const found = await Promise.all(
+    parked.map(async (row) => groupClaimFinding(row, dir, root)),
+  )
+
+  return found.filter((finding): finding is Finding => finding !== undefined)
+}
+
+async function groupClaimFinding(
+  row: BoardRow,
+  dir: string,
+  root: string,
+): Promise<Finding | undefined> {
+  if (!row.stem) return undefined
+
+  const file = join(dir, `${row.stem}.md`)
+  if (!existsSync(file)) return undefined
+
+  const target = readPlanTarget(await readFile(file, 'utf8'))
+  const live = target ? resolveLivePlan(target, dir, root) : undefined
+  const hasLivePlan = live !== undefined && existsSync(live)
+
+  if (row.group === 'Needs a plan' && hasLivePlan) {
+    return {
+      kind: 'plan-parked',
+      group: row.group,
+      subject: row.stem,
+      message: `sits under ${row.group} and its task cites ${target}, a live plan. A row with a plan belongs under Up next or Run now, or the plan is stale and belongs in the archive.`,
+    }
+  }
+
+  if (row.group === 'Up next' && !hasLivePlan) {
+    return {
+      kind: 'plan-absent',
+      group: row.group,
+      subject: row.stem,
+      message: target
+        ? `sits under ${row.group}, which claims a written plan, and its task cites ${target}, which is not a live plan.`
+        : `sits under ${row.group}, which claims a written plan, and its task carries no Plan: line.`,
+    }
+  }
+
+  return undefined
+}
+
 /**
  * Where a plan pointer lands, resolved against the board and against the
  * project root the way the archive resolves the same line. Neither base
@@ -1186,6 +1253,7 @@ export async function validateBoard(
     ...checkMapping(rows, backlog, dir),
     ...checkPlans(rows, dir, root),
     ...(await checkPlanAgreement(rows, dir, root)),
+    ...(await checkGroupClaims(rows, dir, root)),
     ...checkCollisions(rows),
     ...checkOrdering(rows),
     ...parked.findings,

package/standards/design.md

@@ -51,7 +51,7 @@ Use `## Personality`, `## Color`, `## Typography`, `## Spacing`, `## Borders`, `
 
 Add either optional section when the project has content for it:
 
-- `## Layout`: page width, breakpoints, and grid rules, as current constraints
+- `## Layout`: page width, breakpoints, and grid rules, as current constraints. The surface-capture rule reads the breakpoints from here, so a project with none declared here is captured at the 320 reflow floor alone.
 - `## Mark`: the logo's construction rules and the files that carry it
 
 ## Template

package/standards/index.md

@@ -19,7 +19,6 @@ Reference docs for consistent authoring across the toolkit and target projects.
 - [Glossary reference](glossary.md): Frontmatter, entry shape, ordering, and the rules deciding which terms a glossary carries
 - [Groundwork reference](groundwork.md): Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
 - [Intake reference](intake.md): Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
-- [Issue reference](issue.md): GitHub issue title, labels, and body conventions
 - [Markdown reference](markdown.md): Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, banned words, and frontmatter wording
 - [Memory reference](memory.md): Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
 - [Mermaid reference](mermaid.md): Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram

package/claude/skills/setup-gov/REQUIREMENT.md

@@ -1,37 +0,0 @@
----
-name: setup-gov
-description: Scope boundary for governance rule install and the authoring it refuses to do in a target
----
-
-# Setup gov requirement
-
-## Gap
-
-Without this skill, a session picks a stack name from memory and installs rules written for a framework the project does not use, passes an extra the catalog does not carry so the install warns on a file it cannot resolve, and adds a rule the picked stack already pulls in.
-
-The two costly failures are quieter. An unmatched technology gets the nearest rule instead of a stop, so the project carries governance authored for something adjacent and nothing marks it as a guess. A rule written directly into the target lands where no sync will ever reach it, so it drifts from the toolkit copy that owns it.
-
-The last failure sits at a boundary rather than inside a run. `setup-init` turns away a project whose language it carries no stack for and sends it here, and a body stating only what this skill does not cover leaves that route running one way, so a person arriving on it reads a skill that never says it is the destination.
-
-## Must
-
-- Read the catalog at run time and resolve both the stack and every extra against it
-- Name the evidence file behind each detected technology in the preview, so a wrong match is visible before the install rather than after
-- Dedupe extras against the rules the picked stack already resolves
-- Run the install non-interactively, since the CLI picker blocks where no terminal is attached
-- State the inbound route from `setup-init`, so a project sent here for the language-neutral rule layer can tell it landed at the destination the chain named
-
-## Must not
-
-- Author a rule inside the target project. Rules are authored in the toolkit and reach a project by install or sync.
-- Install a stack or extra whose name did not come from the catalog read
-
-## Guards
-
-- An unmatched technology stops and presents the options rather than resolving to a nearby rule. Authoring the missing rule in the toolkit, installing the matching layers without the technology-specific one, and aborting are the three, and this skill picks none of them.
-
-## Out of scope
-
-- The rest of the onboarding chain. This skill installs governance and nothing else, and `setup-init` is the one-shot path that installs governance beside tooling, snippets, and the seeds.
-- Scaffolding the rule file an unmatched technology needs. `create-rule` writes one into a target project, and a rule the toolkit should ship is authored under `governance/rules/` against `canon standards rule`.
-- Updating rules a project already has, which `canon gov sync` owns

package/claude/skills/setup-gov/SKILL.md

@@ -1,77 +0,0 @@
----
-name: setup-gov
-description: Detects a project's stack from its files and installs matching toolkit governance rules into `.claude/rules/`. Use after scaffolding a new project, when asked to "install gov rules", "install governance", "set up governance", or when a target project has no `.claude/rules/` yet. Assumes the `canon` CLI is on PATH.
----
-
-# Gov install
-
-Automates `canon gov install` by inferring the stack and extras from the current project, then shelling out to the CLI with the resolved arguments.
-
-## Scope
-
-- Governance rules and nothing else. `setup-init` is the one-shot chain that installs governance beside tooling, standards, snippets, and the seeds.
-- This is where `setup-init` sends a project whose language the toolkit carries no stack for. Rules install without the `base` development dependencies the tooling layer would drop on it. Resolve and stop exactly as below, since a language with no stack is the unmatched case `## Gap handling` already owns and arriving by that route changes none of it.
-
-## Read the catalog
-
-Run this first to load the current stacks and rules. Never hardcode names. The catalog is the source of truth.
-
-```bash
-canon gov list --json 2>/dev/null
-```
-
-## Detect the stack
-
-Read these from the project root in parallel:
-
-- `package.json`: dependencies and devDependencies
-- Root config files: `astro.config.*`, `next.config.*`, `vite.config.*`, `tailwind.config.*`, `tsconfig.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
-- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
-- Directory structure via `ls -1` of the project root and `src/` if present
-
-## Match
-
-Match the detected evidence to the catalog:
-
-- Pick the closest stack. Match detected runtime or framework against stack names in the catalog.
-- Identify additional technologies not already covered by the picked stack. For each, find a rule whose `description` or `paths` points at that technology, then add it via `--add`.
-- Dedupe extras against stack rules. Do not add a rule the stack already pulls in.
-
-## Gap handling
-
-If a detected technology has no matching rule, stop and surface the gap. Do not guess.
-
-Present four options:
-
-1. Author a new rule in the toolkit at `governance/rules/<domain>/<num>-<name>.md` following `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, commit, then re-run install. Take this route when the toolkit should ship the rule to every project.
-2. Invoke `create-rule`, which scaffolds the file into the target project at a non-colliding number. Take this route when the rule is specific to this project and no sync should ever overwrite it.
-3. Install the matching non-<tech> rules and skip the tech-specific layer.
-4. Abort.
-
-This skill authors no rule itself. Option 1 writes in the toolkit repository, and option 2 hands the project-local file to `create-rule`.
-
-## Preview
-
-Before executing, output:
-
-- **Detected:** each technology with the file that evidenced it
-- **Stack:** picked stack name and total resolved rule count
-- **Extras:** each `--add` rule with a one-line reason
-- **Target:** resolved target path
-- **Command:** the exact shell command to run
-
-## Execute
-
-Run with `CANON_NON_INTERACTIVE=1` so no CLI picker prompts appear. Claude Code's tool permission dialog is the confirmation gate.
-
-```bash
-CANON_NON_INTERACTIVE=1 canon gov install <stack> --add <extras> <target>
-```
-
-## Response
-
-After execution, report:
-
-- Rule count installed
-- Target path
-- Any rules that failed to resolve (the CLI warns on missing rule files)

package/claude/skills/setup-indexes/REQUIREMENT.md

@@ -1,48 +0,0 @@
----
-name: setup-indexes
-description: Why index bootstrap is all-or-nothing per folder, what the confirmation loop protects, and why the convention block is pasted rather than written
----
-
-# Setup indexes requirement
-
-## Gap
-
-Without this skill, a session bootstrapping the index system writes `index.md` into a folder and leaves the sibling frontmatter for later, so the first regen hard-errors on the first file missing a `title`. Partial coverage is not a partial success. The folder is broken until every sibling carries both fields, and the error surfaces at regen rather than at the write that caused it.
-
-The scan is where the other failures start. A walk that does not prune reaches `node_modules`, gitignored output, and the snippets folder, which is invoked by reference rather than browsed and needs neither an index nor per-file frontmatter. A folder that already carries an `index.md` gets a second one written over the first.
-
-One failure predates the scan. `setup-init` declines an install that wants the Claude layer without the tooling chain and names this skill as where the index system gets bootstrapped, and a body that never states the inbound route leaves the person arriving on it unable to tell whether they landed at the destination or somewhere adjacent to it.
-
-Drafted frontmatter is a proposal, and a session that writes it before the user sees it turns a review into a cleanup. The convention block has the mirror failure. A session that paraphrases it into `CLAUDE.md` produces a copy that reads correctly and no longer matches its source, so the two drift with nothing reporting it. And a project with no `CLAUDE.md` gets one scaffolded to hold the block, which installs a file the project declined.
-
-A fourth failure sits after the scan rather than inside it. `## Present candidates` had no branch for a scan that finds zero folders, so an empty result walked straight into the ask with nothing to choose from. `setup-init` folds this skill into the onboarding chain, and a fresh scaffold usually carries no markdown-heavy folder yet, so the ordinary onboarding run reached the undefined case.
-
-## Must
-
-- Bootstrap all-or-nothing per chosen folder, since a folder carrying partial frontmatter hard-errors on regen
-- Prune the scan to folders a reader browses, and skip any folder already carrying an `index.md`
-- Surface every drafted `title` and `description` for the user to accept, edit, or reject before anything is written
-- Validate with a dry run and stop on the first reported error, before writing for real
-- Paste the convention block verbatim from its single source
-- Emit the closeout exactly once, whatever the seed step concluded
-- State the inbound route from `setup-init`, so an install wanting the Claude layer without the tooling chain can tell it landed at the destination the chain named
-
-## Must not
-
-- Write a draft the user has not confirmed
-- Index the snippets folder, which is read by reference rather than browsed
-- Create `CLAUDE.md` to hold the convention block. Name the skip and the command that installs the file.
-- Overwrite content below the frontmatter block, or touch a file the user rejected
-
-## Guards
-
-- A folder with fewer than the sibling threshold stays out of the candidate list unless the user names it explicitly, so the scan proposes and the user overrides
-- A `CLAUDE.md` already carrying the convention section skips the seed silently rather than appending a second copy
-- A scan that finds no candidate reports a one-line result and returns, skipping the ask and every step between it and the seed offer, rather than opening a prompt with nothing in it
-
-## Out of scope
-
-- Regenerating an index in a project that already runs the system, which `canon indexes regen` does on its own
-- Wiring the lint-staged entry or the hook, which the closeout offers and the user opts into
-- Installing governance rules or scaffolding a project: `setup-gov` and `setup-init`
-- Writing the frontmatter conventions themselves, which the prose standard owns

package/claude/skills/setup-init/REQUIREMENT.md

@@ -1,46 +0,0 @@
----
-name: setup-init
-description: Scope boundary for the one-shot onboarding chain and the setup steps it leaves to a caller
----
-
-# Setup init requirement
-
-## Gap
-
-Without this skill, a session installs a stack whose name it recalled rather than read, hand-writes configs the tooling sync already ships as golden files, and re-runs the chain over a project that owns its configs already.
-
-Two failures are the expensive ones because both return success. A monorepo run drops husky into every subtree, git honors one `core.hooksPath`, and the extra hook directories go quiet with nothing reporting it. A caller reads the chain as onboarding complete when plugin provisioning never runs, since no step states that it sits outside the chain.
-
-Two more start at the resolve step. A project whose language the toolkit carries no stack for resolves to `base`, and the preview reports the resolved name without marking it as a fallback, so `base` development dependencies, scripts, and hooks land on a project that will not use them and nobody had the moment to decline.
-
-The other is the refusal that ends rather than routes. An existing project, an install wanting the Claude layer without the tooling chain, and a language with no stack are the three states the chain does not serve, and each is declined by a declaration naming no destination, so the person who arrived with one reads a stop and goes no further.
-
-## Must
-
-- Resolve every domain argument against a catalog read at run time, so a stack, rule, snippet, or tooling name the catalog does not carry cannot reach the command line
-- Preview the resolved chain before the first command runs, naming the evidence file behind each detected technology
-- Pass `--skip base` on every subtree past the first in a monorepo, so the shared hook layer lands once
-- State which onboarding steps the chain does not run and why, so a caller knows what is left and where the boundary sits rather than inferring completeness from a clean report
-- Mark a stack reached by fallback as a fallback in the preview, and name what `base` carries, so the write can be declined at the one point it is still declinable
-- Name a destination for every state the chain does not serve, in this body rather than only in a reference doc the person would have to already know to open, and say for each whether the chain stops or runs on a default
-
-## Must not
-
-- Generate a config that tooling sync ships as a golden file. Generating from prose duplicates the installed file and the two drift.
-- Author a rule, stack, or snippet inside the target project when detection finds no match. Authoring happens in the toolkit and reaches a project by install or sync.
-- Grow an existing-project branch, a mode switch, or a clobber guard. The chain runs once against a fresh scaffold and the per-domain paths cover everything after that.
-
-## Guards
-
-- An unmatched technology stops for a decision. Surface the gap and either defer to rule authoring or proceed on the matched layer with the gap named in the report, rather than resolving to the nearest rule.
-
-## Out of scope
-
-- Installing governance rules alone: `setup-gov`. This skill installs governance beside tooling and the seeds.
-- Provisioning Claude Code plugins: `setup-plugins`. Those install once per machine rather than into a project, so no project-scoped chain can carry them.
-- Running the verification scripts, which `setup-verify` owns and this chain invokes as step 4
-- Publishing repository metadata: `repo-metadata`. It reaches a remote, which is past the project edge this chain stops at.
-- Making the first commit: `git-commit`. It reaches the project's history, which is past the project edge this chain stops at.
-- Re-installing into a project that already has the files, which the per-domain `canon <domain> install` and `canon sync` commands own
-- Deciding which of those per-domain commands an existing project needs: `canon-operator`. That skill reads the target before naming one, which this chain never does, so it is the destination rather than a guess made here.
-- Seeding the `.claude/` folder without the tooling chain, which `canon claude init` does on its own and `setup-indexes` finishes