LibSnapshot already implements the release freeze in Solidity; which layer owns it?

[thedavidmeister]

rain-sol-codegen's LibSnapshot already implements the release freeze, in Solidity, callable from a build script. #302 is reimplementing it in Rust, and two repos hand-roll it in bash. This asks which layer owns it before #302 lands.

What LibSnapshot already provides

rain.sol.codegen/src/lib/LibSnapshot.sol:

• deployTag(Vm) — [package].version from foundry.toml, dots to underscores. Its NatSpec calls itself "the single definition of the tag form".
• dirForTag(string) — src/generated/<tag>
• frozenPathForContract(string, string)
• freezeSnapshot(Vm, string[]) — creates the dir, copies each generated file to its frozen path, and enforces append-only:

require(
    keccak256(bytes(vm.readFile(frozenPath))) == keccak256(bytes(content)),
    "LibSnapshot: frozen snapshot would change; bump [package].version for a new release"
);

Where the same work is duplicated

implementation	language	layer
LibSnapshot.freezeSnapshot	Solidity	build script
script/cut-release.sh in rain.factory.deploy	bash	CI step
script/cut-release.sh in S01-Issuer/st0x.deploy	bash	CI step
rainix-static cut-release (#302, open, HELD)	Rust	CI step

Plus deployTag restated locally in rain.deploy's script/Build.sol (being fixed in rain.deploy#26), and in rain.factory.deploy's and st0x.deploy's BuildPointers.sol.

The question

Which layer owns the freeze? #302's stated value is making the regenerate-then-freeze ordering unrepresentable, after the inverted ordering was found live in st0x.deploy — it copies candidate and only then runs forge script, so a drifted candidate is frozen stale while regeneration moves candidate on, publishing one address and permanently recording another.

But LibSnapshot puts the freeze in the same forge script run as the generation, which is where #304 argues it belongs — pointer generation is part of build, not a separate step. If generation and freezing are one script, a CI-layer freeze may be solving an ordering problem that only exists because they were split.

Points to settle, from the source rather than from this summary:

• Does freezeSnapshot do everything cut-release.sh does? Missing candidates: the strict X.Y.Z version check, the refusal when candidate/ is absent, the diff -r assertion, the forge fmt step.
• Does it prevent the ordering bug? The require fires only when a frozen path ALREADY exists, so on a NEW tag a stale freeze writes silently. Prevented, merely visible, or neither?
• Does calling it from the build make the sequence structural, since both would then live in one forge script run?
• If the Solidity layer is right, what is left for rainix owns the deploy-repo release freeze: rainix-static cut-release #302 — the guards that need to run before any generation, or nothing?

Why this is blocking-shaped

#302 is already HELD pending #303 and #304. This adds a third reason to settle the design before merging: it may be reimplementing a published library in a different language at a different layer. Landing it would make five implementations of one operation.

Related: #301, #302, #303, #304; rain.deploy#26 (dropping its local deployTag and address-constant emitter for the shared ones).

[thedavidmeister]

Ruling: Solidity is the preferred home. From the human — "if we can do things in sol then that's great."

That answers this issue's question. Where logic can live in a forge script operating on Solidity artifacts, it should, rather than being reimplemented in bash or Rust at the CI layer. So LibSnapshot.freezeSnapshot is the right shape and the other three implementations are the ones to retire.

The follow-on being determined in rainlanguage/rain.deploy#26: how much of cut-release.sh's remaining logic also moves into the script. Candidates, each checkable in Solidity — strict X.Y.Z validation (vm.parseTomlString already reads the version), refusing when candidate/ is absent (vm.exists), refusing to overwrite an already-frozen tag, and the byte-identity assertion, which may be by construction since freezeSnapshot writes the content it just read. What plausibly cannot move is forge fmt, being a forge invocation rather than script logic, and anything that must run before forge starts at all.

If those guards land in Solidity, #302 is retired rather than shrunk — generate-and-freeze become one forge run with the guards inside it, and there is nothing left for a Rust CI step to own. #302 is already held pending #303 and #304; this makes the question whether it should be closed rather than merged.

Note the apparent tension with rainix's own convention that its tooling is Rust, never bash or Python logic. These do not collide: that rule governs CI tooling running outside forge. This is about not reimplementing, at the CI layer, logic that operates on Solidity artifacts inside a build that already runs forge.

Related framing from the same session: the canonical deploy and release process is being defined in rain.deploy#26, and the existing implementations are expected to be replaced by it rather than reconciled with it.