codetruss 0.2.52

[DeliriumPulse]

Points the formula at the v0.2.52 release archive.

url    https://github.com/CodeTruss/codetruss-cli/releases/download/v0.2.52/codetruss-cli-0.2.52.tgz
sha256 5afc2a563358f1f7dd41eaf2484dc7913e326d9e7072f0d8c5bdeb1bb77792dd

That digest was measured off the downloaded release asset, not copied from the release notes, and the URL written above was fetched independently and cmpd against it. The asset is byte-identical to public/downloads/codetruss-cli-0.2.52.tgz in the monorepo, to the bytes codetruss.com serves, to the site's latest pointer, and to the archive rebuilt independently in the mirror from its own lockfile. gh attestation verify codetruss-cli-0.2.52.tgz --repo CodeTruss/codetruss-cli passes, and the release carries all three attestations: SLSA provenance v1, CycloneDX, and the in-toto release predicate — the last confirmed through the attestations API, since gh 2.85 cannot verify a predicate signed by GitHub's release identity (dotcom.releases.github.com) under --repo.

The same cmp against 0.2.51 — the version this formula pointed at until now — exits 1, so the comparison is capable of failing. gh attestation verify was likewise checked against a tampered copy of the archive (one appended byte) and against two wrong --repo values; all three exit 1, so its exit 0 above is not vacuous.

Nothing else changes. .github/workflows/test.yml derives the expected version from brew info rather than a literal, so it needs no edit; the version assertion in CI is what proves the installed binary matches the formula.

What 0.2.52 carries

Three corrections to published artifacts, and no behaviour change. dist/cli.cjs in this archive and in 0.2.51's are the same length and differ at exactly one byte — the version string the binary prints.

The one that matters for anyone installing through this tap is a safety claim in the shipped README that was false. Through 0.2.51 it read: "Non-interactive --yes setup requires explicit --allow values." It never did. Given no explicit value, resolveAllowGlobs adopts every conventional source directory that exists at the repository root — src, app, apps, packages, lib, components, server, client, public, test, tests, e2e, spec, docs — as <dir>/** and continues; it refuses only when none of the fourteen exist.

Verified against the published 0.2.52 archive installed into an isolated prefix: codetruss setup --yes --hooks none in a repository holding src/ and tests/, with no --allow at all, exits 0 and prints Adopted detected allowed change roots: src/**, tests/**. The same command in a repository whose only source directory is named something else exits 3 and asks for an explicit --allow. Both match the corrected text; the old text claimed the first case could not happen.

The behaviour itself is deliberate and unchanged — an unattended run should end up protected rather than halted over glob syntax, the adopted list is printed, no repository-wide glob is ever adopted, and verification-command trust is still withheld without --trust-verify. What was wrong was the documentation, so the documentation is what moved. The corrected text also warns that a detected scope can be wider than intended, and that it misses a source directory outside the list — on sindresorhus/ky, whose sources live in source/, --yes adopts test/** alone and leaves the whole source tree out of scope.

Also in 0.2.52: a correction to the 0.2.51 changelog entry, which said a blocking pre-commit hook left "uninstalling as the only escape" — git commit --no-verify also escapes it. 0.2.51's published text is untouched; the correction lives in the 0.2.52 entry. And packages/analyzer-engine/src/scoring.ts no longer carries raw NUL bytes, so git renders the scoring model as text rather than as a binary blob.

🤖 Generated with Claude Code