Build1 publisher3 min readPublished
contenox stopped publishing commits and started publishing a signed tree
Version 1.0.0 landed as one signed commit into an empty repository, with CI-built binaries. When agents write most of the code, the release becomes the only boundary a reviewer can hold.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- contenox 1.0.0 was shipped not by pushing a tag on top of a thousand commits but as a single commit into an empty repository: the whole tree, one signed tag, and binaries built from that tag by CI. CI builds four binaries from the tag.
- The 957 commits that led to 1.0.0 are still public in the old repository as history, but they are no longer how the project is published.
- 957 commits accumulated in just over a year, most named Checkpoint, Fix tests, or Snapshot WiP, with dozens landing on a busy day.
- The production Go grew from 17,267 hand-written lines to 134,040 agent-assisted lines, measured rather than estimated; the median file stayed the same size while the number of files and packages did not.
- The move from 17,267 to 134,040 lines of production Go is approximately a 7.8x increase.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
contenox shipped 1.0.0 not as a tag on top of a thousand commits but as a single commit into an empty repository: the whole tree, one signed tag, and four binaries built from that tag by CI [1]. The 957 commits that produced it remain public in the old repository as history, but they are no longer how the project is published [2].
The numbers explain the decision better than the manifesto does. Those 957 commits accumulated in just over a year, most of them named Checkpoint, Fix tests, or Snapshot WiP, dozens landing on a busy day [3]. Production Go went from 17,267 hand-written lines to 134,040 agent-assisted ones, a measured figure rather than an estimate, with median file size unchanged and the file and package counts doing the growing [4]. That is roughly a 7.8x increase in the body of code under one nominal author [5]. At one point 530 uncommitted paths sat in a single working tree, and inside that blob the file carrying the repository's own conventions had been deleted; nobody noticed for days, because nobody reviews a 530-file diff [6].
The author's argument is that four unstated assumptions of the GitHub workflow all fail here: that a commit is a unit of human intent, that a pull request is a unit of review, that history is provenance, and that timestamps are labor [7]. What survives is the timestamp, which is why he notes a public commit stream doubles as a timesheet nobody agreed to publish if you also do client work [8]. Review had already inverted in practice: he was reviewing outcomes, not commits, because the commit boundary had become an accident of when an agent stopped [9].
So the boundary moved. The public repository is a release mirror where main advances only by release, every commit is titled Release vX.Y.Z and carries the complete tree, and the diff between two commits is the diff between two releases [10]. Tags are signed, the annotation is the release notes, and CI builds the binaries, writes checksums, attests provenance, and publishes [11]. Contributions still arrive as pull requests and are carried upstream by hand, with Co-authored-by on the release commit and a line in the notes; the branch is evidence, not the delivery vehicle [12]. The mechanism is a short shell script: export exactly what git tracks under the OSS subtree, grep the export against a list of private markers and exit non-zero on a hit, commit, sign, tag, push [13]. Vendors have shipped source drops for years, AOSP among them; what is new, he writes, is that the reason is not secrecy but that intermediate commits stopped carrying information worth publishing [14].
The failure in the first drop is the useful part. It shipped with a CONTRIBUTING.md that described in detail the very workflow built to keep that workflow out of the public repository, written by an agent, thorough, correct, and against the brief, unread because it was one of 29 files in the commit [15]. Then the Go module proxy fetched v1.0.0 and the text became permanent, since re-tagging a Go module hands every later go get a checksum mismatch [16]. Every gate in place was mechanical: lint, tests, a scan for secrets and private paths [17].
Two things to watch. Whether a release-sized diff is actually read, given that 29 files already outran attention while 530 files were the problem being solved [15][6]. And whether the immutability that makes an artifact trustworthy also makes it unforgiving, because a signed, proxied release cannot be quietly amended [16].