autopublish: make cutting constant snapshots and deploying manual actions, generally

[thedavidmeister]

Ask

Make cutting a constant snapshot, and deploying, manual actions — generally.

Keep autopublish's soldeer publish and patch bump on merge exactly as they are. Neither should imply a deploy or a snapshot.

Today a merge does all of it as one indivisible act, and the four have different lifecycles:

act	correct trigger	today
publish to soldeer	content change on merge	on merge
patch bump [package].version	after publish	on merge
cut a src/generated/<tag>/ constant snapshot	manual	implied by the bump
deploy	manual	n/a

Why the coupling exists

[package].version serves two masters. It is the soldeer package version, bumped on every content change — and it is the deploy-record tag:

// rain.sol.codegen src/lib/LibSnapshot.sol:34
string memory version = vm.parseTomlString(vm.readFile("foundry.toml"), ".package.version");

(st0x.deploy's local script/BuildPointers.sol derives it the same way.)

So every publish silently redefines where the deploy record lives, whether or not any bytecode moved. The generator opens a fresh empty <tag>/ slot, the regenerate-and-diff check finds it uncommitted, and the tree is dirty.

The autopublish input docs already assert the invariant this breaks:

The bump does NOT generate per-release artifacts: a version's deploy-pin snapshot is built and committed by the PR that defines that version's content, so a next-version slot never carries a placeholder snapshot on main

That holds for the artifact but not for the tag. rainix#267 stopped pre-generating at bump time; the tag derivation stayed keyed to the bumped version, so the empty slot still appears on the next build.

Making snapshot + deploy manual dissolves this: a release with no deploy cuts no snapshot, and the "empty next-version slot" state stops existing rather than being tolerated.

Live evidence: S01-Issuer/st0x.deploy#252

15:46:58  bc2df58   git-clean SUCCESS                              (version 0.1.7)
15:47:47  d2a01b2   "Package Release: soldeer st0x-deploy 0.1.8"   (autopublish bump)
15:50:00  9e660d3   PR #252's only commit, on top of d2a01b2
16:02     #252 git-clean FAIL: "Committed pointer artifacts are stale. Regenerate and commit."

The failing diff is an entire 0_1_8 constant block. #252 is ahead=1, behind=0 from d2a01b2 and its own diff only pins the V4 authoriser clone address — it caused none of this; it was just the first branch on top of the bump.

main is red and CI cannot see it. git-clean is on: [push], but d2a01b2 has zero workflow runs — commits pushed by Actions with the default GITHUB_TOKEN do not trigger workflows. The newest CI result on main tests bc2df58, which is no longer HEAD and had a different version. main looks green and is red; the first victim is whoever branches next.

Not a one-off: after 0.1.5 (e22eeae, 07-09) main stayed dirty until fcb6dfb regenerated on 07-10.

Blast radius

LibSnapshot.deployTag() is shared, so this is org-wide. Snapshot dirs already frozen on main:

repo	src/generated/<tag>/ dirs
raindex	0_1_4 .. 0_1_13 (10)
S01-Issuer/st0x.deploy	0_1_1 .. 0_1_7 (7)
rain.factory	0_1_3 .. 0_1_5 (3)

Ten snapshots in raindex is the tell: a snapshot per release is not a snapshot per deploy. Where bytecode did not move between two releases, the two frozen records are identical noise that consumers pin against — and rainix#268's append-only gate makes them permanent.

Related

• rainix#267 — stopped the bump generating artifacts; left the tag keyed to the bumped version.
• rainix#268 — append-only snapshot gate; makes every accidental snapshot permanent once on main.
• Scripts as migrations: on-chain migration registry, state-relevant tests, drop the deadline-gated dual-state invariant S01-Issuer/st0x.deploy#256 — scripts-as-migrations; overlaps on "what deserves a deploy record".