Remove the submodule-era residue — the manual deploy workflow still runs inside `./lib/rain.interpreter`, which does not exist

[thedavidmeister]

What is wrong

REUSE.toml and .soldeerignore still name foundry.lock and .gitmodules — neither of which exists here — and, the part that is not cosmetic, .github/workflows/manual-sol-artifacts.yaml still runs three steps inside ./lib/rain.interpreter, a submodule directory this repo does not have and a dependency it no longer takes. That workflow is the only way this repo deploys, and as written it cannot run.

Everything dangling in this repo

Every reference below names a path that does not exist on main. All of it is one removal, not separate work.

A deploy workflow pointed at a submodule that is gone

• .github/workflows/manual-sol-artifacts.yaml lines 49–54:

  - run: nix develop -c rainix-sol-prelude
    working-directory: ./lib/rain.interpreter
  - run: nix develop -c rainix-rs-prelude
    working-directory: ./lib/rain.interpreter
  - run: nix develop -c i9r-prelude
    working-directory: ./lib/rain.interpreter

  There is no lib/ directory in this repo and git ls-files --stage on a fresh clone reports zero gitlinks (mode 160000). rain.interpreter is not in foundry.toml [dependencies] or soldeer.lock either — the interpreter surface this repo uses now arrives as the soldeer packages rain-interpreter-interface 0.1.0 and rainlang 0.1.2, under dependencies/. A workflow_dispatch run fails at the first of these three steps, before it reaches the rainix-sol-prelude / rainix-sol-artifacts steps that do the actual deploy. This is a workflow_dispatch-only workflow, so nothing has been exercising it.

Submodule paths that no longer exist

• REUSE.toml line 9 — ".gitmodules",. There is no .gitmodules in the tree and no gitlinks.
• REUSE.toml line 18 — "foundry.lock",. There is no foundry.lock; it was deleted here already, ahead of the ten pass-2 repos that still carry one.
• .soldeerignore line 25 — /foundry.lock, same absent file.

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. This one does not: foundry.toml sets libs = ["dependencies"] and soldeer.lock is the live lockfile for 18 packages, all 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.

Other dangling references found while checking

• .soldeerignore line 11 — .envrc. No such file here, and it is not gitignored.
• flake.nix line 5 — rainix.url = "github:rainprotocol/rainix". The repo has been rainlanguage/rainix for a long time; this resolves only through GitHub's rename redirect, and flake.lock already records the input as rainlanguage/rainix. Same era of residue, one line, worth taking with the rest.

Deliberately not in scope. .soldeerignore also names .DS_Store, .pre-commit-config.yaml and the build/publish outputs (/out, /cache, /dependencies, /node_modules). Those are absent from a clean checkout by design — OS junk, local developer files, or artifacts generated at forge soldeer install / forge build / devShell-entry time and therefore present when soldeer push runs. They are correct ignores and must stay.

Nothing else references any of it. flake.nix, foundry.toml, remappings.txt, .gitignore, script/, meta/, test/, slither.config.json and README.md were grepped and are otherwise clean; the other three workflows (rainix-sol.yaml, package-release.yaml, git-clean.yaml) never mention lib/. There is no CLAUDE.md, so there is no stale prose describing lib/ submodules to fix here.

Neither annotation blocks its own deletion — reuse lint (the rainix-sol legal job) tolerates annotation paths that do not exist, and a .soldeerignore line for a nonexistent path is a no-op. The workflow does not block anything either, because it only ever runs on demand.

Context

This is the tail of an unfinished migration, not a convention.

Pass 1 of this sweep covered the 17 repos that consume rain.solmem via soldeer. Every one of them carried residue, and each now has its own issue. This is pass 2: a further 17 rainlanguage repos with the same dangling entries — rain.deploy, rain.sol.codegen, rain.factory, rainix, rain.factory.deploy, rain.vats, rain.math.saturating, rain.math.binary, rain.pyth, rain.vats.flare, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.verify.interface, rain.lib.typecast, rain.lib.hash, raindex.interface — of which ten still carry a dead foundry.lock: rain.deploy, rain.sol.codegen, rain.math.saturating, rain.math.binary, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.lib.typecast, rain.lib.hash, raindex.interface. This issue covers rain.pyth only.

Deleting the file was never the whole job — rain.pyth is the case that shows why. The annotations are harmless; the workflow that inherited the same lib/ assumption is not.

rainlanguage/flow and rainlanguage/rain.tier.interface genuinely still use git submodules — live gitlinks, verified — so their .gitmodules and lib/ entries are correct and must be left alone.

This is CI configuration only. No Solidity source, no deployed bytecode and no audited artifact changes.

Done when

• manual-sol-artifacts.yaml lines 49–54 removed, and the workflow re-read end to end against the current soldeer dependency set so a workflow_dispatch run reaches rainix-sol-artifacts
• REUSE.toml lines 9 and 18 removed
• .soldeerignore lines 11 and 25 removed
• flake.nix line 5 points at rainlanguage/rainix, flake.lock re-locked
• no reference to .gitmodules, lib/ or foundry.lock remains anywhere in the tree outside dependencies/
• CI green (rainix-sol test / static / legal)