What is wrong
.soldeerignore still names foundry.lock, .gitmodules and /lib — none of which exists here. It is residue from the submodule → soldeer migration.
Everything dangling in this repo
Submodule paths that no longer exist
.soldeerignore line 10 — .gitmodules. There is no .gitmodules in the tree and git ls-files --stage reports zero gitlinks..soldeerignore line 21 — /foundry.lock. There is no foundry.lock; it was deleted here already..soldeerignore line 23 — /lib. There is no lib/ directory. foundry.toml sets libs = ['dependencies'], so forge resolves everything under dependencies/ and never creates lib/.
foundry.lock is Foundry's git submodule lockfile — it records the commit each dependency vendored under lib/ is pinned to, so forge install / forge update can restore identical submodule revisions. It is only meaningful in a repo that vendors dependencies as git submodules, and this repo does not: soldeer.lock is the live lockfile and everything lands under dependencies/.
None of it can come back. rainix CI runs a no-submodules check that fails on a root .gitmodules or any committed gitlink.
Checked and clean. REUSE.toml is clean here — every annotated path resolves, including .cargo/**/, .coderabbit.yaml, .devcontainer.json, .envrc and .prettierignore, all of which dangle in sibling repos that copied the same template without the files. CLAUDE.md contains no stale claim that dependencies are git submodules under lib/. Leave both alone.
Deliberately not in scope. .soldeerignore also names .DS_Store, .pre-commit-config.yaml and the build/publish outputs (/out, /cache, /dependencies, /deployments). Those are absent from a clean checkout by design — OS junk, local developer files, or artifacts generated at forge soldeer install / forge build time and therefore present when soldeer push runs. They are correct ignores and must stay.
Nothing else references any of it. .github/workflows/, flake.nix, foundry.toml, Cargo.toml, crates/, remappings.txt, .gitignore, script/, meta/, README.md, TESTING.md and the rest of the tree were grepped and are clean.
Why only these three lines go
.soldeerignore is a publish filter, not a description of the tree. An entry naming an absent path is a forward-looking rule: it is the thing that keeps that path out of the published package if anyone ever adds it. So the test for deleting an entry is impossible, not absent — an entry may only go if the path it names can never exist again.
These three pass that test, and they pass it structurally rather than by observation: rainix CI's no-submodules check fails the build on a root .gitmodules or any committed gitlink, /lib is that same vendored-submodule directory, and foundry.lock is only ever written for lib/ submodule dependencies. While that check stands none of the three can be recreated, so their filter entries can never match anything again. They are genuinely dead, and they are the only lines this issue removes.
Every other entry — .cargo, .coderabbit.yaml, .devcontainer.json, .envrc, .prettierignore, and the rest — is either matching something today or merely not yet added. Deleting one of those cleans nothing up; it arms a leak, so that the day someone adds the file it ships inside the published soldeer package. Proved live in rain.lib.memkv — dropping the /soldeer.lock line took forge soldeer push --dry-run from 14 entries to 15, with soldeer.lock now inside the package.
Nothing catches an over-deletion. No CI job reads .soldeerignore, so the mistake goes green and only surfaces later, when someone adds the file and it silently publishes.
(REUSE.toml is the opposite case: its annotations describe files that exist, so a dangling path there is residue and does go. Nothing dangles here — see above.)
Context
This is the tail of an unfinished migration, not a convention.
Across the repos that consume rain.solmem via soldeer, nine have already dropped foundry.lock (raindex, rain.verify, rain.tofu.erc20-decimals, rain.flare, rain.dia, rain.erc4626.words, rainlang, rain.merkle, S01-Issuer/st0x.deploy) and eight still carry one (rain.solmem, rainlang.interface, rain.extrospection, rain.math.float, rain.string, rain.lib.memkv, rain.intorastring, rain.datacontract), each with its own issue.
Deleting the file was never the whole job — every one of those nine left dangling .gitmodules and/or lib/ references behind. This issue covers rainlang only.
The same residue exists in a further 17 rainlanguage repos outside that consumer set, 10 of which also still carry a dead foundry.lock. They are out of scope here. flow and rain.tier.interface genuinely still use git submodules, so their .gitmodules and lib/ entries are correct and must be left alone.
Done when
What is wrong
.soldeerignorestill namesfoundry.lock,.gitmodulesand/lib— none of which exists here. It is residue from the submodule → soldeer migration.Everything dangling in this repo
Submodule paths that no longer exist
.soldeerignoreline 10 —.gitmodules. There is no.gitmodulesin the tree andgit ls-files --stagereports zero gitlinks..soldeerignoreline 21 —/foundry.lock. There is nofoundry.lock; it was deleted here already..soldeerignoreline 23 —/lib. There is nolib/directory.foundry.tomlsetslibs = ['dependencies'], so forge resolves everything underdependencies/and never createslib/.foundry.lockis Foundry's git submodule lockfile — it records the commit each dependency vendored underlib/is pinned to, soforge install/forge updatecan restore identical submodule revisions. It is only meaningful in a repo that vendors dependencies as git submodules, and this repo does not:soldeer.lockis the live lockfile and everything lands underdependencies/.None of it can come back. rainix CI runs a
no-submodulescheck that fails on a root.gitmodulesor any committed gitlink.Checked and clean.
REUSE.tomlis clean here — every annotated path resolves, including.cargo/**/,.coderabbit.yaml,.devcontainer.json,.envrcand.prettierignore, all of which dangle in sibling repos that copied the same template without the files.CLAUDE.mdcontains no stale claim that dependencies are git submodules underlib/. Leave both alone.Deliberately not in scope.
.soldeerignorealso names.DS_Store,.pre-commit-config.yamland the build/publish outputs (/out,/cache,/dependencies,/deployments). Those are absent from a clean checkout by design — OS junk, local developer files, or artifacts generated atforge soldeer install/forge buildtime and therefore present whensoldeer pushruns. They are correct ignores and must stay.Nothing else references any of it.
.github/workflows/,flake.nix,foundry.toml,Cargo.toml,crates/,remappings.txt,.gitignore,script/,meta/,README.md,TESTING.mdand the rest of the tree were grepped and are clean.Why only these three lines go
.soldeerignoreis a publish filter, not a description of the tree. An entry naming an absent path is a forward-looking rule: it is the thing that keeps that path out of the published package if anyone ever adds it. So the test for deleting an entry is impossible, not absent — an entry may only go if the path it names can never exist again.These three pass that test, and they pass it structurally rather than by observation: rainix CI's
no-submodulescheck fails the build on a root.gitmodulesor any committed gitlink,/libis that same vendored-submodule directory, andfoundry.lockis only ever written forlib/submodule dependencies. While that check stands none of the three can be recreated, so their filter entries can never match anything again. They are genuinely dead, and they are the only lines this issue removes.Every other entry —
.cargo,.coderabbit.yaml,.devcontainer.json,.envrc,.prettierignore, and the rest — is either matching something today or merely not yet added. Deleting one of those cleans nothing up; it arms a leak, so that the day someone adds the file it ships inside the published soldeer package. Proved live in rain.lib.memkv — dropping the/soldeer.lockline tookforge soldeer push --dry-runfrom 14 entries to 15, withsoldeer.locknow inside the package.Nothing catches an over-deletion. No CI job reads
.soldeerignore, so the mistake goes green and only surfaces later, when someone adds the file and it silently publishes.(
REUSE.tomlis the opposite case: its annotations describe files that exist, so a dangling path there is residue and does go. Nothing dangles here — see above.)Context
This is the tail of an unfinished migration, not a convention.
Across the repos that consume
rain.solmemvia soldeer, nine have already droppedfoundry.lock(raindex, rain.verify, rain.tofu.erc20-decimals, rain.flare, rain.dia, rain.erc4626.words, rainlang, rain.merkle, S01-Issuer/st0x.deploy) and eight still carry one (rain.solmem, rainlang.interface, rain.extrospection, rain.math.float, rain.string, rain.lib.memkv, rain.intorastring, rain.datacontract), each with its own issue.Deleting the file was never the whole job — every one of those nine left dangling
.gitmodulesand/orlib/references behind. This issue covers rainlang only.The same residue exists in a further 17 rainlanguage repos outside that consumer set, 10 of which also still carry a dead
foundry.lock. They are out of scope here.flowandrain.tier.interfacegenuinely still use git submodules, so their.gitmodulesandlib/entries are correct and must be left alone.Done when
.soldeerignorelines 10, 21 and 23 removed.soldeerignoreline left exactly as it is.gitmodules,lib/orfoundry.lockremains anywhere in the tree outsidedependencies/rainix-soltest / static / legal)