rainix-tag-release's determinism check removes src/generated/<tag>/ and re-runs the repo's generator to prove the frozen snapshot is a fresh regeneration. In a repo whose generated released-suites lib IMPORTS that directory, the removal makes the tree uncompilable, so the generator cannot run and the release can never pass.
Observed
rain.factory.deploy sol-v0.1.9, run 32399215966. Both guards passed (version matches tag; src/generated/0_1_9/ present in the tagged commit — verified via the API at that ref). Then:
rm -rf "src/generated/${DIR}"
nix develop … -c bash -c "… forge script ./script/Build.sol --sig \"cutRelease()\" && forge fmt"
Unable to resolve imports:
"../generated/0_1_9/CloneFactory.sol" in "…/src/lib/LibCloneFactoryReleased.sol"
Error (6275): Source "src/generated/0_1_9/CloneFactory.sol" not found
LibCloneFactoryReleased.sol is itself generated and declares the released suites by importing each frozen record. Removing the directory it imports is what breaks the compile.
Not repo-specific
rain.metadata.deploy is being created now on the same current conventions; its generated LibMetaBoardReleased.sol will import ../generated/0_1_0/MetaBoard.sol, so it hits the identical wall at its first sol-v* tag. Any deploy repo adopting the Option A model with a generated released-suites lib inherits it.
Fix shapes
- Do the determinism check without mutating the working tree — regenerate into a temp dir / worktree and diff, rather than
rm -rf in place.
- Remove the frozen dir AND reset the generated lib that references it, so the tree stays compilable for the regeneration.
- Have the generator tolerate a missing frozen dir (regenerate the lib before compiling anything that imports it).
(1) looks cleanest: the check is read-only in intent already — the comment says "Nothing is committed or pushed — the runner tree is thrown away."
Adjacent, found while diagnosing
The frozen-snapshots-append-only pre-check globs src/generated/*/*.pointers.sol. No current deploy repo has files matching that glob (the generated records are src/generated/<tag>/<Name>.sol), so the gate is a silent no-op org-wide. Worth fixing in the same pass.
🤖 Generated with Claude Code
rainix-tag-release's determinism check removessrc/generated/<tag>/and re-runs the repo's generator to prove the frozen snapshot is a fresh regeneration. In a repo whose generated released-suites lib IMPORTS that directory, the removal makes the tree uncompilable, so the generator cannot run and the release can never pass.Observed
rain.factory.deploy
sol-v0.1.9, run 32399215966. Both guards passed (version matches tag;src/generated/0_1_9/present in the tagged commit — verified via the API at that ref). Then:LibCloneFactoryReleased.solis itself generated and declares the released suites by importing each frozen record. Removing the directory it imports is what breaks the compile.Not repo-specific
rain.metadata.deploy is being created now on the same current conventions; its generated
LibMetaBoardReleased.solwill import../generated/0_1_0/MetaBoard.sol, so it hits the identical wall at its firstsol-v*tag. Any deploy repo adopting the Option A model with a generated released-suites lib inherits it.Fix shapes
rm -rfin place.(1) looks cleanest: the check is read-only in intent already — the comment says "Nothing is committed or pushed — the runner tree is thrown away."
Adjacent, found while diagnosing
The
frozen-snapshots-append-onlypre-check globssrc/generated/*/*.pointers.sol. No current deploy repo has files matching that glob (the generated records aresrc/generated/<tag>/<Name>.sol), so the gate is a silent no-op org-wide. Worth fixing in the same pass.🤖 Generated with Claude Code