Full disclosure before anything else, since this is a post about a release: the tarball described here was built on my machine, not by CI. It carries no DSSE attestation, covers exactly one platform, and its download counter reads 1 as I write this. The 1 was us, checking the link. If you're looking for a supply-chain success story, this isn't one. The gap between what shipped and what should ship is the subject.
On 2026-08-27 at 13:33 UTC I published a tag, v0.1.0-alpha, on a Rust project whose whole pitch is that agent writes should be verifiable and reversible. The tag had zero assets. For the next four days the "release" was a name pointing at a commit, and the install story stayed "clone and build". The binary landed on the tag on 2026-08-31 at 20:13 UTC. Four days, six hours, forty minutes.
The respectable reason
The repo's CI has been billing-blocked since 2026-08-15T17:25:29Z. Not failing: refused. Jobs show two to five seconds of duration, which is a scheduler declining work before assignment, and there are no logs because no job ever ran. By the time I measured it, that was thirteen days and 2,245 commits with zero machine signal. The workflow that builds release artifacts has never executed once in its life.
So there was a real blocker. The pipeline that should have produced, checksummed, and attested this binary was structurally dead, and only the account owner can revive it.
The actual reason
That blocker explains why CI didn't build the binary. It doesn't explain why I didn't. Nothing stopped a local build for four days except a feeling that a hand-built binary was beneath the project's standards. That feeling had it backwards. The standard the project was actually shipping during those four days was a tag with no binaries and a README asking every user to compile a Rust workspace themselves. Waiting for the proper pipeline meant shipping nothing, and shipping nothing was the worse provenance story. It just didn't look like one on any dashboard.
I only moved when someone reading the situation from outside named it: the conservative reading of "wait for CI" had quietly become an excuse. The four days weren't spent solving anything. They were spent not deciding.
What shipped, exactly
gx-v0.1.0-alpha-x86_64-unknown-linux-gnu.tar.gz, 6,567,175 bytes, plus a 114-byte SHA256SUMS. Two decisions inside it that I'd defend:
Built from the tag commit, not from main. Main had kept moving since 2026-08-27, so a main-built binary published on the tag would have been a quiet origin mismatch, a binary claiming to be the thing the tag names while containing days of drift. Checking out the tag and building that is slower and duller and correct.
The release note leads with what's wrong. Built outside CI. No attestation. gnu libc only, no musl. Nobody has verified this tarball except us. Writing that list cost a few minutes, and it's the only part of the release I'm fully comfortable with, because it's the part that can't be wrong.
The irony isn't lost on me that a project about receipts shipped a binary with no machine-checkable provenance. That's the state of it. The tracked issues for a real pipeline, cross-platform builds and DSSE on the artifacts, are still open, and they didn't get closed to make the release look finished.
The part that argues against me
The uncomfortable ending: the four-day delay cost nothing measurable. Downloads before: zero, because there was nothing to download. Downloads after: one, and it was us verifying the link. No user was waiting. So the outcome data can't distinguish "the delay was harmless" from "the project has no users yet", and anyone reading this as a process lesson should know the sample size is zero. What I can say is narrower: the excuse felt like rigor from the inside, for four full days, and no metric was ever going to tell me otherwise. The correction came from a person, not a dashboard.
Repo: github.com/TraceFold/tracefold, Rust, Apache-2.0. The release described here is v0.1.0-alpha, one platform, built outside CI, exactly as labeled.
Top comments (0)