[IanFrelinger]

The post-push integrity check could never pass, and it runs after the push

reusable-release-nuget.yml hashes every .nupkg before pushing (line 87), pushes (line 187), then downloads what nuget.org serves and asserts the SHA-256 matches (line 251).

Those bytes are never equal. nuget.org repository-signs on publish, appending a .signature.p7s entry. Measured on the real feed:

$ curl -s https://api.nuget.org/v3-flatcontainer/ashlar.sdk/0.1.2/ashlar.sdk.0.1.2.nupkg
served bytes : 42664
sha256       : eb2111dcaa00867068186ca61fbb0533366bf329e823800fc69ff7ebf45c21d3
entries      : ... , .signature.p7s (12987 bytes)

That is not the hash of the file that was pushed. And it fails at the worst moment: dotnet nuget push has already run, and nuget.org permits unlisting but not deletion, so the release is public and unrecallable by the time the step reports.

Why nobody noticed

It has never executed. The v0.1.2 release (run 33867752688) failed one step earlier, on flat-container index lag — 12 attempts × 15s against an index that had not caught up. The byte comparison was never reached.

That earlier step has since had its budget raised to 40 × 15s. So the next release is the first time this one runs, and it will fail. A check that cannot pass, sitting behind a check that failed, is indistinguishable from a check that works.

What it compares now

Every archive entry except the signature, by name and uncompressed content (scripts/lib/nupkg_content_digest.py) — the part publication must not alter, and the part a consumer restores. Verified against the served package: signing appends .signature.p7s and touches nothing else; [Content_Types].xml does not even declare the p7s extension.

The signature's presence is now asserted positively and separately, so excluding it from the digest loses nothing. The manifest keeps raw sha256 as provenance and adds contentSha256; a manifest written by the old script has no contentSha256, and the verifier refuses it by name rather than silently passing. Both sides import the same module, so they cannot drift into computing different things and agreeing anyway. A run that verified zero packages is also refused.

The test holds two properties that must be true at once

appending a repository signature must not change the digest	or every release fails
changing any packaged byte must change it	or nothing is caught

It also asserts that the raw file hash does move when a signature is appended — the fact that made the original check impossible — so the reason stays visible.

Mutation-checked, all three caught: removing the signature exclusion, ignoring entry content, dropping the length prefix. The length prefix initially survived its mutation, so frame_entry was extracted as a pure function and the injectivity property is now asserted on chosen bytes rather than left as a claim no test could reach.

Second hole, same publish path

release-nuget.yml is a workflow_dispatch taking an arbitrary version and handing it straight to the same reusable publish job — with none of release.yml's guards. A dispatch could publish packages whose version disagreed with the assemblies inside them, or leave consumer-template pinning a different release.

It now runs the same validate job first: SDK pin, assert_dispatch_version_allowed, assert_consumer_pin_matches. The guards are duplicated rather than shared because a reusable workflow cannot gate its own caller, and a guard the caller may skip is not a guard.

Not changed

ci/published-version reads 0.1.2 and that is correct — it names what is on nuget.org, not what is being cut (consumer-template/CONSUMING.md:5). release.yml's guard deliberately requires it to move on the release commit. The gap is that the only written tag procedure (CHANGELOG.md:7) does not mention that step; that is a changelog fix, kept out of this PR so the two do not conflict.

🤖 Generated with Claude Code

[IanFrelinger]

Added one commit unrelated to the release machinery, because it was blocking this PR and every other one.

lychee (README + docs) is a required check with no path filter on pull_request, so it runs on every PR. It fails on two links in docs/handoff/HANDOFF.md:

[403] https://claude.ai/code/artifact/a1b2328c-... (at 38:4)
[403] https://claude.ai/code/artifact/bcfebaf4-... (at 40:4)

Those are private Claude artifacts from the session that originated the handoff notes. claude.ai answers an unauthenticated fetch with 403 by design, so a link checker can never verify them — it is measuring claude.ai's auth behaviour, not anything about this repository.

Not a regression from this PR. The links have been on master since 2026-08-22 (#362). The workflow's push trigger had not re-run over that file since 2026-09-10, and its pull_request trigger has no path filter — so the first PR to reach the check inherited a defect that had been on master for five weeks.

Excluded in .lycheeignore rather than deleted: the links are the only pointer to that reference material for whoever can open them.