chore: harden dependency installs and CI execution paths

[josemontesdeoca]

Dependency installs and CI jobs both executed code this repository never reviewed. This closes those paths without changing what anything resolves to.

Install scripts

npm has no allow-list model for lifecycle scripts, so .npmrc sets ignore-scripts=true — the blunt equivalent of pnpm's onlyBuiltDependencies. A trojanized dependency cannot execute on npm ci, in CI or on a laptop where live credentials sit beside the install. A full install and test pass under the setting confirms nothing here needs it: the only install hooks in the tree belong to esbuild, whose platform binary arrives through optionalDependencies and is resolved by the JS shim at runtime.

Registry integrity

npm audit signatures and npm audit --omit=dev both block, in pull-request CI and now on push as well — the release workflow runs on push to main, which is the path a change takes when it lands without a pull request, and it previously ran none of these checks. This repository can afford both gates: every installed package carries a valid registry signature, and its production dependencies have no known advisories. Holding that at zero is cheaper than reclaiming it later.

Tools now come from the lockfile

Every job invoked its tools through npx, which downloads a package when the name is not in the lockfile — so undeclared tools arrived unpinned and unverified at run time, after the gates above had already passed on the installed tree, and in jobs holding a provider key or a write token. tsx is now a declared devDependency, and every invocation takes --no-install so a tool that goes missing fails the job instead of quietly fetching a replacement.

The remaining case was npx biome check .. The Biome CLI is not a dependency of this project and never has been, so that line resolved an unrelated package of the same short name and ran its no-op CLI: the lint gate reported success without reading a single file, while pulling an unreviewed dependency tree into CI and release. Removing it costs no coverage that existed. Adopting @biomejs/biome properly, and fixing the diagnostics it reports, is a change of its own — biome.json stays in place for editors and local use.

Pinned references

anthropics/claude-code-action is pinned to the commit its v1 tag pointed at when the pin was written (v1.0.186). That tag is movable, and it has moved since: v1 now resolves to a different commit. Without the pin that retag would have changed what runs here with nothing in this repository changing — which is the whole argument for pinning, demonstrated inside a week.

The two jobs that install the OpenProse skill took it from openprose/prose's default branch. That skill becomes the instructions the model follows, and both jobs hold a credential — an API key with pull-request write access in one, a provider key in the other. Both now fetch a fixed commit and leave no git credential on disk.

A monthly grouped Dependabot entry keeps the action pins from going stale.

Dispatch inputs

The full eval workflow interpolated its three dispatch inputs straight into a bash script running with a provider key in the environment. Those values are substituted before bash parses the line, so an input carrying command substitution or a statement separator executed as code. They now travel through the step environment as quoted variables, and each is validated before use: tier is a choice, concurrency must be a small positive integer, and a model override must look like a provider/name pair.

Release job scope

It held contents: write for the whole job, with a git credential on disk, while every step in it only reads and builds. It is now contents: read with no persisted credential. The write scope belongs to a release step that does not exist yet; when one is added it should get its own job rather than widening this one.

Note for anyone publishing by hand

ignore-scripts=true also suppresses this package's own prepublishOnly hook, so npm publish will not build dist/ for you. The explicit npm run build step in the release workflow is what produces the artifact, and it must stay ahead of any publish step. Verified: from a clean tree, a publish dry-run under this setting yields a tarball containing only LICENSE, README.md, and package.json.