Checkwright

Checkwright v0.17.0

2026-07-27

Checkwright is the verification layer under agent orchestration, and this release gives it a delivery channel that works. The previous release announced an install command that never functioned: v0.16.0 was tagged and its note published, but the publish job handed npm a package spec npm read as a GitHub owner/repo shorthand rather than as a path, so it exited before reaching the registry and nothing was ever published. Every tagged release now attaches the installer tarball and its .sha256 to the GitHub Release, which needs no Node to consume and is the primary path from here on.

Tightened gates

  • check-action-run-shell — new, in gate-sdk. Every GitHub Actions run: literal block scalar must be ShellCheck-clean at -S warning under the dialect the step actually runs. It closes a real hole: a workflow’s run: body is shell that nothing lints or executes until a push or a tag, so a defect in it surfaces in CI rather than at your pre-commit. The scan walks *.yml / *.yaml from the scan root and then narrows to files carrying a top-level jobs: key (a workflow) or runs: key (a composite action); everything else is skipped and counted, never linted, so a non-Actions CI dialect in your tree is not read as shell. Expect it to reach your own workflows and any kit workflow template you have copied out — gate-sdk’s templates/gates-workflow.yml and site-kit’s templates/site-health.yml both carry run: shell.

This repository’s own scripts/ gate directory also gained check-npm-publish-spec this release, holding the npm publish spec that broke v0.16.0. It does not ship inside a kit, so it cannot appear in a vendored tree and is not part of the allowed-red set below.

Renamed knobs

None. check-action-run-shell takes an optional positional scan root and adds no environment knob, so no configuration surface moved.

Behavior changes

  • Release assets — new. Every tagged release now carries the installer tarball and a .sha256 beside it, attached by a release job that consumes the same artifact the npm job publishes. One pack, two transports. This is the Node-free install path: download, verify, extract, run init. The checksum travels from the same origin over the same session as the tarball, so it catches a corrupted or truncated download and is not evidence the release host was uncompromised — the property carrying that is a build attestation, which the npm channel’s --provenance mints and this channel does not yet.
  • docs/install.md §Quick start — rewritten around the tarball path, with one step that is easy to get wrong called out: unpack outside the repository. init refuses a worktree that is not clean, and an extracted package/ sitting in your root is untracked content that makes it exactly that — so a tarball unpacked in place blocks the install it was downloaded for.

Upgrading

Replace the vendored kit directories wholesale at v0.17.0, then regenerate the generated artifacts — the pre-commit hook and the graph projection. Then run the full battery.

The allowed red. check-action-run-shell is new and may red once you register it. Clear it by making each Actions run: block ShellCheck-clean at -S warning — most reds are an unquoted expansion or an unchecked cd. A run: block you do not want linted belongs in a file the Actions-shape predicate does not match; there is no per-block valve.

The behavior changes above are declared for reading, not a mechanical scan. If a gate reds that this note does not name, the upgrade smoke was supposed to catch it first — open an issue, because that is a defect in the release rather than work for you.