@erclx/canon 4.103.0 → 4.104.0

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

@@ -1,38 +0,0 @@
----
-name: setup-smoke
-description: Why the heavy scaffold stages need an owner and what heuristic judges a server smoke pass
----
-
-# Setup smoke requirement
-
-## Gap
-
-Without this skill, a freshly scaffolded project's dev server, preview server, end-to-end suite, and screenshot harness never run anywhere. `setup-verify` excludes all three for the flakiness reasons that make them wrong for an unattended chain, and names no destination for any of them, so a broken dev server or a missing end-to-end dependency surfaces only once the user hits it by hand.
-
-A dev or preview server carries no exit code to read, since it runs until stopped rather than finishing on its own, unlike the leaf scripts `setup-verify` runs. Judging it needs a heuristic rather than a pass/fail read.
-
-## Must
-
-- Read the scripts the project declares and run only those, skip absent ones
-- Run `dev`, `preview`, `test:e2e`, `screenshot` in that fixed order, stopping at the first failure
-- Judge a server script by running it in the background, waiting a fixed window, checking the process is alive and its output carries no fatal error string, then killing it regardless of the outcome
-- Install dependencies itself when missing, so it runs standalone without `setup-verify` having run first
-
-## Must not
-
-- Invent a fallback command for an absent script
-- Run a composite script
-- Require `setup-verify` to have passed first
-- Duplicate a leaf script `setup-verify` already runs
-- Get invoked by anything other than a person or a chain naming it directly. Review this at each future change, since nothing can answer it before the skill has run. `canon docs target-projects` states the scaffold chain that keeps it outside the unattended path, for the same flakiness reasons that keep it out of `setup-verify`'s own leaf-script order.
-
-## Guards
-
-- No `package.json` at the project root stops, since there are no declared scripts to read
-- A missing dependency folder installs first rather than letting every script fail on the same cause
-
-## Out of scope
-
-- The leaf scripts `setup-verify` already runs: `lint:fix`, `typecheck`, `check`, `test:run`, `build`
-- Generating the configs these scripts drive, which the tooling stack reference owns
-- A true port-probe readiness check, since no manifest key exposes a generic port across stacks

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

@@ -1,53 +0,0 @@
----
-name: setup-smoke
-description: Runs the heavy scaffold checks setup-verify skips - dev and preview server smoke, Playwright end-to-end tests, and the screenshot harness - on the same declared-scripts contract. Use after setup-verify passes, or when asked to "run the smoke tests", "check the dev server", "run e2e against the scaffold", or "run the heavy checks". Do NOT use in place of setup-verify, or on a project without package.json.
----
-
-# Smoke scaffold
-
-Runs the local checks a scaffold's leaf scripts cannot cover: whether the dev and preview servers actually start, whether the end-to-end suite passes against a real server, and whether the screenshot harness produces output. Standalone from `setup-verify`. Neither skill requires the other to have run first.
-
-## Guards
-
-- If `package.json` does not exist at the project root, stop: `❌ No package.json found. Cannot smoke test.`
-- If `node_modules/` does not exist, run `bun install` first, then proceed.
-
-## Step 1: read scripts
-
-Read `package.json` from the project root and extract the `scripts` block. Do not hardcode script names.
-
-## Step 2: run the chain
-
-Run the scripts below in order. Stop on the first failure and surface the error.
-
-| Order | Script       | Skip if | How judged              |
-| ----- | ------------ | ------- | ----------------------- |
-| 1     | `dev`        | absent  | server smoke, see below |
-| 2     | `preview`    | absent  | server smoke, see below |
-| 3     | `test:e2e`   | absent  | leaf script: exit code  |
-| 4     | `screenshot` | absent  | leaf script: exit code  |
-
-Skip any script not present in `package.json`. Do not invent a fallback command. Run each leaf script as `bun run <script>` from the project root.
-
-### Server smoke
-
-`dev` and `preview` run until stopped, so there is no exit code to read. Start the script backgrounded, wait 5 seconds, then check two things: the process is still running, and its captured output carries no string matching `error`, `Error`, or `fatal`. Kill the process either way once judged. Report a failure on either check failing.
-
-This is weaker than a real readiness probe. No manifest key exposes a generic port to poll across stacks, so port-probing is out of reach here.
-
-## Step 3: report
-
-For each script run, report one of:
-
-- `✅ <script>`
-- `❌ <script>` followed by the failing output (last 40 lines) or, for a server script, the reason judged (process died, or a fatal string in its output)
-
-End with a summary line:
-
-- On pass: `✅ Scaffold smoke-tested (<n> scripts passed).`
-- On fail: `❌ Scaffold failed at <script>. Fix the error and re-run setup-smoke.`
-
-## Out of scope
-
-- `lint:fix`, `typecheck`, `check`, `test:run`, `build`. Those are `canon:setup-verify`'s leaf-script chain.
-- Generating the configs these scripts drive, which the tooling stack reference owns.

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

@@ -1,39 +0,0 @@
----
-name: setup-verify
-description: Why a fresh scaffold is checked with declared leaf scripts in a fixed order, and what the excluded stages would cost
----
-
-# Setup verify requirement
-
-## Gap
-
-Without this skill, a freshly scaffolded project is handed over on the strength of the configs looking right, and the first typo surfaces when the user runs something. A scaffold is generated from a reference, so the errors it carries are wiring mistakes and missing dependencies, both of which any script run would have caught.
-
-The naive check fails two ways. A session that assumes script names runs `test` against a stack that exposes `test:run`, or invents a fallback command when a script is absent, and either result reports on something the project never declared. A session that runs a composite script gets one failure covering several stages, so the output names the wrapper rather than the break.
-
-The stages left out are the ones that lie, and each now has an owner in `canon:setup-smoke` rather than nowhere at all. A dev server or a preview reads as failed when it starts slowly, a browser test needs an install and a running server before it can even fail correctly, and a CI workflow cannot be judged locally at all. Including any of them turns a scaffold check into a flaky one, and a flaky check gets ignored.
-
-## Must
-
-- Read the scripts the project declares and run only those
-- Run leaf scripts in a fixed order, so a failure points at the exact stage that broke
-- Stop at the first failure and surface its output rather than continuing to collect more
-- Report per script and close with one summary line naming the failing stage when there is one
-
-## Must not
-
-- Invent a fallback command for an absent script. Skip it.
-- Run a composite script, which hides which stage broke
-- Run a dev server, a preview, or a browser test
-
-## Guards
-
-- No `package.json` at the project root stops, since there are no declared scripts to read
-- A missing dependency folder installs first rather than letting every script fail on the same cause
-
-## Out of scope
-
-- Dev and preview smoke tests, which `project-commands` starts on request and `canon:setup-smoke` checks automatically
-- Browser end-to-end tests, which need a browser install and a running server, covered by `canon:setup-smoke`
-- CI workflow validation, which runs on the pull request rather than locally. `canon:setup-smoke` runs the same stages locally as the closest proxy
-- Generating the configs it checks, which the tooling stack reference owns

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

@@ -1,51 +0,0 @@
----
-name: setup-verify
-description: Verifies a freshly scaffolded project by running its `package.json` scripts in order and reporting pass/fail per script. Use after the agent has followed a tooling stack reference and generated configs, or when asked to "verify the scaffold", "check the setup", "run verify", or "make sure everything works". Do NOT use on a project without `package.json`, or to run E2E or dev servers.
----
-
-# Verify scaffold
-
-Runs the local verification chain against a freshly scaffolded project. Catches config typos, missing deps, and wiring mistakes before the user ever sees them.
-
-## Guards
-
-- If `package.json` does not exist at the project root, stop: `❌ No package.json found. Cannot verify.`
-- If `node_modules/` does not exist, run `bun install` first, then proceed.
-
-## Step 1: read scripts
-
-Read `package.json` from the project root and extract the `scripts` block. Do not hardcode script names. Different stacks expose different scripts.
-
-## Step 2: run the chain
-
-Run the scripts below in order. Stop on the first failure and surface the error. Each script is a leaf command so failures point at the exact break.
-
-| Order | Script      | Skip if                     |
-| ----- | ----------- | --------------------------- |
-| 1     | `lint:fix`  | absent                      |
-| 2     | `typecheck` | absent                      |
-| 3     | `check`     | absent                      |
-| 4     | `test:run`  | absent, fall back to `test` |
-| 5     | `build`     | absent                      |
-
-Skip any script not present in `package.json`. Do not invent a fallback command. Do not run composite scripts like `check:full`. Do not run `dev`, `preview`, `test:e2e`, `test:ui`, `screenshot`.
-
-Run each as `bun run <script>` from the project root.
-
-## Step 3: report
-
-For each script run, report one of:
-
-- `✅ <script>`
-- `❌ <script>` followed by the failing output (last 40 lines)
-
-End with a summary line:
-
-- On pass: `✅ Scaffold verified (<n> scripts passed).`
-- On fail: `❌ Scaffold failed at <script>. Fix the error and re-run setup-verify.`
-
-## Out of scope
-
-- Dev server and preview server smoke tests. Too flaky for a scaffold check, where a slow start reads as a failure. Use `project-commands` to start one on request, or `canon:setup-smoke` to check both automatically.
-- Playwright E2E tests. Require browser install and a running server. Use `canon:setup-smoke`.
-- CI workflow validation. Runs in GitHub Actions on PR, not locally. `canon:setup-smoke` runs the same end-to-end and screenshot stages locally, as the closest proxy.

package/scripts/core/regen-tooling-paths.sh

@@ -1,61 +0,0 @@
-#!/usr/bin/env bash
-set -e
-set -o pipefail
-
-# Rewrites the generated path block in the shipped overwrite contract, which
-# names every file a tooling sync can replace. The category reaches past the
-# linters its name suggests, into the CI workflow, the end-to-end harness, and
-# the shell scripts under scripts/, so a reader cannot infer the list. Generating
-# it is what keeps a stack gaining a file from leaving the contract wrong.
-#
-# The stack names come from `tooling list` rather than from a directory walk,
-# so a stack the verb excludes never reaches a contract about what the verb does.
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-PROJECT_ROOT="${PROJECT_ROOT:-$(cd "$SCRIPT_DIR/../.." && pwd)}"
-
-TOOLING_DIR="$PROJECT_ROOT/tooling"
-CONTRACT="$PROJECT_ROOT/claude/skills/canon-cli/SKILL.md"
-
-BEGIN="<!-- generated:tooling-paths -->"
-END="<!-- /generated:tooling-paths -->"
-
-[ -d "$TOOLING_DIR" ] || exit 0
-[ -f "$CONTRACT" ] || exit 0
-
-grep -qF "$BEGIN" "$CONTRACT" || {
-  echo "Missing $BEGIN marker in $CONTRACT" >&2
-  exit 1
-}
-
-block="$(mktemp)"
-trap 'rm -f "$block" "$CONTRACT.tmp"' EXIT
-
-{
-  echo "$BEGIN"
-  echo
-  while IFS= read -r stack; do
-    [ -d "$TOOLING_DIR/$stack/configs" ] || continue
-    echo "### $stack"
-    echo
-    while IFS= read -r rel; do
-      echo "- \`$rel\`"
-    done < <(cd "$TOOLING_DIR/$stack/configs" && find . -type f | sed 's|^\./||' | sort)
-    echo
-  done < <(bun "$PROJECT_ROOT/src/cli.ts" tooling list --json | jq -r '.stacks[].name' | sort)
-  echo "$END"
-} >"$block"
-
-# awk streams the file rather than editing in place, so a pattern that matches
-# nothing produces a file missing the block instead of an unchanged one that
-# exits zero.
-awk -v block_file="$block" -v begin="$BEGIN" -v end="$END" '
-  $0 == begin { while ((getline line < block_file) > 0) print line; skipping = 1; next }
-  $0 == end { skipping = 0; next }
-  !skipping { print }
-' "$CONTRACT" >"$CONTRACT.tmp"
-
-# The destination is a tracked file with a mode the copy must not inherit from
-# mktemp, so the content moves onto the original rather than replacing it.
-cat "$CONTRACT.tmp" >"$CONTRACT"
-rm -f "$CONTRACT.tmp"