fix(release): three traps that report success while doing nothing

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brentrager]

All three confirmed live in this repo, not theoretical. Flagged by the audit agent from a sibling repo; each reproduced here before fixing.

1. go test ./... served a cached pass against a corrupted fixture

Go's build cache doesn't invalidate on a file read from outside the package directory — exactly the shape of the shared contract fixtures in spec/. Reproduced:

$ python3 -c "...zero every sha256, set headBytes to 999..."
$ go test ./...
ok github.com/SmooAI/file/go/file/v2 (cached)

So the Go quarter of the five-port lazy contract was proving nothing.go:test now passes -count=1, and the same corruption fails immediately (streamHeadBytes = 65536, contract says 999). Verified end to end through pnpm go:test: exit 1 corrupted, exit 0 restored.

The other four ports were never affected — vitest, pytest, cargo and dotnet all re-read the fixture. -count=1 went in the package.json script rather than the workflow, so pnpm test, pnpm check-all and the husky pre-commit all get it.

2. release.yml ran pnpm format in write mode

Whatever it rewrote was either swept into the release commit unreviewed, or — in publish mode, where the changesets action commits nothing — left the tree dirty for cargo publish --locked, which would fail every release now that --allow-dirty is gone (dropped in #66). #68 widened the blast radius by adding dotnet format to pnpm format.

Now format:check, with the write moved into pnpm run version, before the action commits.

Sequencing confirmed necessary rather than assumed: ran changeset version locally and checked its output — the generated CHANGELOG.md is not oxfmt-clean. Without formatting inside version, format:check would redden every future release PR. With it, pnpm run version leaves a format-clean tree.

3. Four registries gated on npm succeeding in the same run

if: steps.changesets.outputs.published == 'true' on PyPI, crates.io, the Go tag and NuGet. npm succeeds, a later step fails, the retry finds nothing new for npm → published is false → all four skip, the run goes green, and nothing was published.

Each step is now gated on whether its own registry carries package.json's version, so a retry ships exactly what's missing, plus a final step that fails the run on a real strand.

Two corrections found while verifying this, not after merging it

• A fail-open in the fix itself. A botched edit left the npm-probe result being overwritten by a later branch, so --expect-npm exited 0 on a version npm didn't have. Since every gate is !has && present.npm, a false npm reading would have switched all four publishes off and gone green having shipped nothing — the exact defect being removed, reintroduced one level up. Now exits 1 naming the disagreement.
• NuGet is reported but not asserted. Its index takes minutes to tens of minutes to show a package it has already accepted: 2.2.19 logged Your package was pushed for both packages at 19:26 and the flat-container index still read 2.2.14 twenty minutes later. Asserting on it would have reddened every successful release, and a guard that cries wolf gets deleted. NuGet keeps its own protection — dotnet nuget push exits non-zero on a real failure, and the per-registry gate skips it only when the version is genuinely there.

Controls, all three run

control	expected	result
all five present (2.2.14)	exit 0	✅
npm present, Go tag missing, NuGet lagging	exit 1 naming go only	✅
--expect-npm on an unpublished version	exit 1	✅

Status check the lead asked for — not stranded

At the time of checking, npm / PyPI / crates.io / both NuGet packages / the Go tag were all on 2.2.14, so the truncation fix reached every port. 2.2.19 has since published to npm, PyPI, crates.io and the Go tag, with NuGet accepted and indexing. Two earlier release runs did fail, both at "a pull request already exists for changeset-release/main" — a concurrency race before any publish step, so nothing was half-published.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

[changeset-bot]

🦋 Changeset detected

Latest commit: 18b8e9a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@smooai/file	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR