Split rain.math.float into a library half and a new rain.math.float.deploy

[thedavidmeister]

Split rain.math.float into a library half and a new rain.math.float.deploy

rain.math.float is currently a hybrid: it runs the library lifecycle (package-release.yaml → rainix-autopublish, publishes rain-math-float on merge) yet carries the full deploy surface — deployed-contract addresses + codehashes, a frozen generated snapshot, deploy scripts, and deploy tests. That is exactly the mixing the library/deploy split convention prevents (same class as the raindex hybrid). Split it like rain.factory / rain.factory.deploy and rain.extrospection / rain.extrospection.deploy.

What stays in rain.math.float (library — rainix-autopublish, floats ^, no deploy surface)

• src/lib/LibDecimalFloat.sol and the pure helpers: src/lib/format/, src/lib/parse/, src/lib/implementation/, src/lib/table/LibLogTable.sol
• src/error/
• any interface surface
• Publishes rain-math-float. No concrete, no pins, no src/generated/, no deploy scripts, no deploy tests, no fs_permissions for src/generated.

What moves to the new rain.math.float.deploy (deploy — rainix-tag-release, exact-pin =0.8.25)

• src/concrete/DecimalFloat.sol (the deployed concrete)
• src/lib/deploy/LibDecimalFloatDeploy.sol — the pins: ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS (0xc51a1425…), LOG_TABLES_DATA_CONTRACT_HASH (0x2573004a…), ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS (0x799632d2…), and the rest
• src/generated/LogTables.pointers.sol (frozen deploy-pin snapshot)
• script/Deploy.sol, script/BuildPointers.sol, script/CopyArtifacts.sol, script/check-published-deploy-constants.sh, script/lib/LibEtchLogTables.sol, script/lib/LibCopyArtifacts.sol
• test/src/lib/deploy/* (LibDecimalFloatDeploy, checkLogTablesDeployed, DeployProd, DeployTaggedConstants) and test/script/CopyArtifacts.t.sol
• Deploy lifecycle: manual-sol-artifacts.yaml, tag-triggered package-release.yaml → rainix-tag-release with soldeer-package: rain-math-float-deploy, snapshot-generate-cmd = the pointers build. Depends on rain-math-float for the library surface. Publishes rain-math-float-deploy.
• Track the pending push-free tag-release change (rainix-tag-release: make deploy releases push-free (works under branch protection) rainix#338) — the new deploy repo should adopt whatever release flow #338 lands (PR-the-snapshot → tag → publish), not re-introduce a push-back.

Consumer impact

Anything importing LibDecimalFloatDeploy / the deployed addresses (e.g. rainlang's LibDecimalFloatDeploy.ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS) must repoint from rain-math-float to rain-math-float-deploy. An org-wide scan of rain-math-float importers, bucketed into library-only (unaffected) vs deploy-pin (must repoint), is part of the work.

Human / infra steps (agent flags, does not perform)

Creating the rainlanguage/rain.math.float.deploy repo, its CI secrets (PUBLISH_PRIVATE_KEY, SOLDEER_API_TOKEN, RPC fork secrets), and the on-chain deploy attestation are org-admin / human steps. The addresses already exist on-chain (deterministic Zoltu), so the deploy repo's first release attests existing pins rather than deploying fresh.

Precedent

rain.factory#46 (the original library/deploy split), rain.extrospection / rain.extrospection.deploy. Follow their repo shape, foundry.toml conventions, and CLAUDE.md structure (mind the 4096-byte agent-context cap).

[thedavidmeister]

Executable migration plan: rain.math.float → rain.math.float.deploy

Full tree walked (git ls-tree -r) and classified; the tractable deploy file set is staged. Not done here (hard boundaries): repo creation, on-chain deploy, mergeable strip PR. Per-org consumer repointing is out of scope (human narrowing 2026-08-20) — only the ordering constraint below is kept.

Staged deploy repo: /home/gildlab/artifacts/mathfloat-deploy-staged/ (durable). 60 files, ready for git init + push. Validated: forge build succeeds against the published rain-math-float package (92 files, Solc 0.8.25, optimizer_runs = 1_000_000).

---

1. Complete file inventory (STAYS = library, MOVES = deploy)

Counting only code (src/ + script/ + test/, .sol/.sh): 44 MOVE, 65 STAY (of 109). Config/CI/rust/js meta is per-repo (each half authors its own), not "moved".

MOVES to rain.math.float.deploy (44):

• src/concrete/DecimalFloat.sol, src/lib/deploy/LibDecimalFloatDeploy.sol, src/generated/LogTables.pointers.sol (3)
• script/BuildPointers.sol, script/Deploy.sol, script/check-published-deploy-constants.sh, script/lib/LibEtchLogTables.sol (4)
• test/abstract/LogTest.sol (Zoltu-etch helper), test/src/concrete/*.t.sol (31), test/src/lib/deploy/*.t.sol (4), test/src/lib/table/LibLogTable.bytes.t.sol (37)

STAYS in rain.math.float (library, 65): all of src/lib/{LibDecimalFloat, format, parse, implementation, table/LibLogTable} + src/error/* (8); the pure-math test suite test/src/lib/{LibDecimalFloat.*, format, implementation, parse} (48), test/concrete/{TestDecimalFloat.sol, packLossless, unpack} (3), test/lib/* reference impls (3); and — pending the ruling in Hard Case A — the rust-ABI bridge script/CopyArtifacts.sol + script/lib/LibCopyArtifacts.sol + test/script/CopyArtifacts.t.sol (3).

Not touched (stay with the library, out of the src/script/test count): crates/** (the rain-math-float Rust crate + @rainlanguage/float npm), test_js/**, Cargo.*, package*.json, scripts/*.js, audit/, and the library-lifecycle workflows (package-release.yaml → rainix-autopublish, copy-artifacts.yaml, pr-assessment.yaml, rainix-rs-*.yaml, rainix-sol.yaml).

Dependency split (soldeer, recursive_deps = false)

• Library keeps: forge-std, @openzeppelin-contracts, rain-solmem, rain-string, rain-datacontract (still needed by the test log-table helper — see Hard Case C). Drops: rain-deploy, rain-sol-codegen (only the moved scripts used them).
• Deploy declares: forge-std, rain-math-float (NEW), rain-datacontract, rain-deploy, rain-sol-codegen, plus @openzeppelin-contracts + rain-string + rain-solmem reached transitively when the concrete compiles the library.

Shared-file hard cases (imported by both halves) + resolution

A. Rust crate binds the concrete — the real blocker for removing the concrete from the library. crates/float (STAYS; publishes rain-math-float crate + npm) is a binding over the concrete DecimalFloat, not the library: sol!(DecimalFloat, "abi/DecimalFloat.json") is the non-test macro, evm.rs deploys DecimalFloat::DEPLOYED_BYTECODE, and every public Rust op (fromFixedDecimal*, toFixedDecimal*, parse, format, max/min/zero, error decode) calls the concrete's ABI. The concrete also imports the deploy pins (LibDecimalFloatDeploy) and its constructor calls checkLogTablesDeployed() — so it is genuinely deploy surface, yet the library's Rust build needs its ABI + deployed bytecode. script/CopyArtifacts.sol (+ lib + test) is the bridge that regenerates crates/float/abi/{DecimalFloat,TestDecimalFloat}.json; neither rain.factory.deploy nor rain.extrospection.deploy carries such a script. This needs a human ruling and it gates removal of the concrete from the library (NOT the deploy repo's creation/publish). Options: (D, recommended, clean) rebind the Rust crate + its #[cfg(test)] path onto TestDecimalFloat (the harness that STAYS), extending the harness to expose every method the crate calls and etching tables from LibLogTable at an arbitrary address — library becomes self-contained, no concrete, no cross-repo sync; (A, low-risk unblock) freeze abi/DecimalFloat.json in the library as a vendored artifact sourced from rain-math-float-deploy, drop the DecimalFloat half of CopyArtifacts/copy-artifacts.yaml — minimal change, but silent drift risk if the deploy repo's concrete moves; (keep concrete in library) defeats the split — the concrete drags LibDecimalFloatDeploy + src/generated/ back in. My recommendation: D.

B. test/abstract/LogTest.sol — inherited by both concrete tests (deploy) and 8 transcendental library tests. The current file etches tables at the Zoltu pin via LibEtchLogTables + LibDecimalFloatDeploy (deploy surface). Resolution: the current file MOVES to the deploy repo (its concrete tests read the real deployed contract at the Zoltu address). The library gets a new, self-contained test helper — Hard Case C.

C. LibLogTable (STAYS) is the table source; the 8 transcendental library tests need tables etched. test/src/lib/LibDecimalFloat.{log10,pow,pow10,sqrt}.t.sol and test/src/lib/implementation/LibDecimalFloatImplementation.{internals,log10,lookupLogTableVal,pow10}.t.sol inherit LogTest. The pure functions take the tables-contract address as a parameter (log10(address,…)) — they do NOT need the Zoltu pin. Resolution (part of the strip, mandatory): add a library test helper that rebuilds the combined tables purely from LibLogTable — abi.encodePacked(toBytes(logTableDec()), toBytes(logTableDecSmall()), toBytes(logTableDecSmallAlt()), toBytes(antiLogTableDec()), toBytes(antiLogTableDecSmall()), LOG_TABLE_DISAMBIGUATOR) — deploys it via LibDataContract (rain-datacontract stays) at a create address, and passes that address in. No deploy pins, no src/generated/.

D. test/src/lib/table/LibLogTable.bytes.t.sol — library test, imports the moved snapshot. It asserts LibLogTable.toBytes(logTableDec()) == LOG_TABLES (the frozen src/generated/ constant). That is the library-source ↔ frozen-snapshot consistency check; it belongs with the snapshot. Resolution: MOVES to the deploy repo (imports LibLogTable from the rain-math-float package + the local src/generated/…). Already staged there.

E. Tagged deploy constants restart their version lineage. LibDecimalFloatDeploy pinned *_0_1_1 constants referencing the old hybrid rain-math-float 0.1.1 DecimalFloat (0xBee0…CC926). The new package rain-math-float-deploy starts a fresh lineage, so those are dropped in the staged file; check-published-deploy-constants.sh now queries project_name=rain-math-float-deploy (nothing published yet → SKIP → the tagged-constants test skips). The first rain-math-float-deploy release must pin a *_0_1_0 suite equal to the current live constants (0x7996…13D6).

---

2. Consumer scan — OUT OF SCOPE

Dropped per the 2026-08-20 narrowing. Only ordering kept: the library-strip must not LAND until rain-math-float-deploy has published, so external importers of LibDecimalFloatDeploy / the deployed addresses have somewhere to repoint. Enumerating/repointing them is separate follow-up, not this issue.

---

3. Staged deploy file set — /home/gildlab/artifacts/mathfloat-deploy-staged/

Layout mirrors the precedent deploy repos. Import paths rewritten: library symbols → rain-math-float-0.1.7/src/…; deploy-internal (src/, script/, relative) + external soldeer imports unchanged. Repo-shell authored fresh: foundry.toml ([external.package], name rain-math-float-deploy, exact solc=0.8.25, optimizer_runs = 1_000_000, ffi=true, dep on rain-math-float + transitive closure), .github/workflows/{manual-sol-artifacts,package-release,rainix-sol}.yaml, CLAUDE.md (3154 B < 4096 cap), README.md, REUSE.toml, LICENSE→symlink, .soldeerignore, .gitignore, slither.config.json, flake.{nix,lock}, .coderabbitai.yaml, .vscode/.

• package-release.yaml → rainix-tag-release (tag sol-v* triggered), soldeer-package: rain-math-float-deploy, snapshot-generate-cmd: forge script ./script/BuildPointers.sol && forge fmt. Adopts the push-free flow rainix-tag-release: make deploy releases push-free (works under branch protection) rainix#338 lands (PR-the-snapshot → tag → publish); no push-back baked in.
• optimizer_runs = 1_000_000 is the critical divergence from rain.factory.deploy/rain.extrospection.deploy (both 100 000). The pinned Zoltu address/codehash are a pure function of the concrete's creation bytecode; the live deployment used 1 000 000, so this must not be "normalised" to 100 000 or every pin moves. Verified below.
• Excluded from the deploy repo: CopyArtifacts.sol / LibCopyArtifacts.sol / CopyArtifacts.t.sol (Rust-ABI bridge, no crates/ in a deploy repo — Hard Case A).

Validation run in a throwaway copy (nix develop -c): forge soldeer install OK · forge build → 92 files, Solc 0.8.25, successful · in-memory deploy/codehash + concrete-op tests: 58 passed, 0 failed, 1 skipped (35 suites) — incl. testExpectedCodeHashDecimalFloat + testDeployAddress confirming the concrete reproduces the live pins (0x7996…13D6, codehash 0xdc4688…); the tagged-constants test SKIPs (nothing published for rain-math-float-deploy yet). The LibDecimalFloatDeployProdTest fork tests are human/secret-gated (RPC) and were not run.

---

4. Library-strip plan (apply to rain.math.float AFTER the deploy repo publishes)

Deliverable as a written diff (no mergeable PR opened, per boundary). Two tiers because Hard Case A entangles the concrete with the Rust crate.

Mandatory addition first (Hard Case C): add a library-side log-tables test helper (rebuild combined tables from LibLogTable, deploy via LibDataContract at a create address) and repoint the 8 transcendental tests onto it. Without this the pure-math suite loses log10/pow/pow10/sqrt coverage.

Tier 1 — removable as soon as rain-math-float-deploy publishes (no Rust/concrete coupling):

• rm test/src/lib/deploy/*.t.sol (4), rm test/src/lib/table/LibLogTable.bytes.t.sol
• rm script/Deploy.sol, rm script/check-published-deploy-constants.sh
• rm .github/workflows/manual-sol-artifacts.yaml
• foundry.toml: drop deps rain-deploy, rain-sol-codegen; drop [rpc_endpoints] + [etherscan] (no fork tests remain); pragmas stay ^.

Tier 2 — GATED on the Hard Case A ruling (concrete ↔ Rust crate):

• rm src/concrete/DecimalFloat.sol, rm src/lib/deploy/LibDecimalFloatDeploy.sol, rm src/generated/LogTables.pointers.sol, rm script/BuildPointers.sol, rm script/lib/LibEtchLogTables.sol, rm test/abstract/LogTest.sol, rm test/src/concrete/*.t.sol (31)
• foundry.toml: drop the fs_permissions entry for ./src/generated.
• Resolve the Rust bridge per the ruling: option D removes script/CopyArtifacts.sol + script/lib/LibCopyArtifacts.sol + test/script/CopyArtifacts.t.sol + crates/float/abi/DecimalFloat.json + the DecimalFloat entry in LibCopyArtifacts.contracts() and rebinds crates/float onto TestDecimalFloat; option A vendors a frozen abi/DecimalFloat.json and drops only the DecimalFloat half of the bridge + copy-artifacts.yaml's DecimalFloat assertion.

Library keeps: the whole pure-math surface (src/lib/{LibDecimalFloat, format, parse, implementation, table/LibLogTable}, src/error/*), its test suite (48) + the new etch helper, rainix-autopublish (rain-math-float crate/npm/soldeer), ffi=true, and rain-datacontract.

---

5. Ordered execution sequence (human-only steps marked 🔒)

1. 🔒 Ruling on Hard Case A (Rust-crate/concrete coupling) — determines the Tier-2 shape of the strip. Does NOT block steps 2–6.
2. 🔒 Create rainlanguage/rain.math.float.deploy; git init + push the staged set.
3. 🔒 Add CI secrets (PUBLISH_PRIVATE_KEY/deploy key, SOLDEER_API_TOKEN, per-chain RPC + Etherscan keys, Cachix).
4. 🔒 On-chain attest — run Manual sol artifacts for log-tables then decimal-float on each network. Addresses already exist (deterministic Zoltu), so this attests existing pins; deploy fails loudly on any chain missing the tables.
5. 🔒 First sol-v0.1.0 tag → rainix-tag-release publishes rain-math-float-deploy to Soldeer; pin the *_0_1_0 constants (Hard Case E) via the release PR.
6. Verify rain-math-float-deploy published (soldeer registry resolves; a fresh consumer builds).
7. (separate follow-up, not this issue) repoint deploy-pin consumers from rain-math-float to rain-math-float-deploy.
8. 🔒 Land the library-strip — only after step 6 (ordering constraint). Apply Tier 1 + (per step-1 ruling) Tier 2 + the mandatory etch-helper addition; the library republishes without the deploy surface. A DRAFT strip PR should carry blocked-by: rain.math.float.deploy publish and must not be mergeable until then.
9. Verify the library suite green (pure-math coverage intact via the new helper) and the Rust crate builds per the Hard Case A ruling.

Notes are audit inputs, not verdicts — the Hard Case A/E rulings and the Tier-2 shape are the human's.

[thedavidmeister]

Hard Case A — ruled (human, 2026-08-20)

move the rust to rain.math.float.deploy — it is bindings on the concretes not the sol lib

The crates/float Rust crate + @rainlanguage/float npm are bindings over the concrete DecimalFloat (its ABI + DEPLOYED_BYTECODE), so they are deploy surface and move to rain.math.float.deploy with the concrete — NOT rebound onto TestDecimalFloat (my earlier option D) and NOT vendored (option A). This resolves the blocker cleanly and un-gates the Tier-2 library strip.

Plan changes

• rain.math.float (library) becomes pure Solidity: LibDecimalFloat + format/parse/implementation/table + errors + TestDecimalFloat harness + pure-math tests. Publishes only the rain-math-float Soldeer package. No Rust crate, no npm, no CopyArtifacts bridge. Drops crates/**, Cargo.*, package*.json, test_js/**, scripts/*.js, script/CopyArtifacts.sol + script/lib/LibCopyArtifacts.sol + test/script/CopyArtifacts.t.sol, and copy-artifacts.yaml + rainix-rs-*.yaml.
• rain.math.float.deploy gains, alongside the concrete/pins/snapshot/deploy-scripts already staged: crates/float (Rust crate rain-math-float), @rainlanguage/float npm, the CopyArtifacts bridge, Cargo.*, package*.json, test_js/**, scripts/*.js, and the rs/npm publish workflows (rainix-rs-*.yaml + the npm publish wiring the library repo had). It publishes rain-math-float-deploy (Soldeer) and the rain-math-float crate + @rainlanguage/float npm.
• Tier-2 strip is no longer gated — removing the concrete + Rust from the library is decided.

Flag for a human decision (not blocking)

The Rust crate is named rain-math-float and the npm @rainlanguage/float, but they'd now publish from rain.math.float.deploy. Keep those names (crate/npm identity is independent of the source repo) or rename to -deploy? Keeping them avoids a consumer break; noting it so it's a choice, not an accident.

The staged deploy set and the strip plan are being updated to this ruling.

[thedavidmeister]

Staging updated for the Hard Case A ruling — Rust/npm surface moved to rain.math.float.deploy

Per the Hard Case A ruling ("move the rust to rain.math.float.deploy — it is bindings on the concretes not the sol lib"), the crates/float Rust crate + @rainlanguage/float npm + the CopyArtifacts bridge are now staged into the deploy set alongside the concrete.

Staged deploy repo: /home/gildlab/artifacts/mathfloat-deploy-staged/ (durable). 91 regular files + the LICENSE symlink = 92 (the prior comment's 60 → 92; +32 files added), plus edits to flake.nix/foundry.toml/.gitignore/.soldeerignore/REUSE.toml/CLAUDE.md. Still: no repo created, no on-chain deploy, no mergeable strip PR.

1. Added file set (32 files)

Rust crate (crates/**, 13) — rain-math-float + rain-math-float-wasm:
crates/float/{Cargo.toml, src/{lib,evm,error,tables,fuzz_ops,js_api}.rs, abi/{DecimalFloat,TestDecimalFloat}.json, proptest-regressions/{fuzz_ops,lib}.txt}, crates/float-wasm/{Cargo.toml, src/lib.rs}.

Workspace + npm (8): Cargo.toml, Cargo.lock, package.json, package-lock.json, tsconfig.json, .prettierignore, test_js/{float.test.ts, tsconfig.json}.

npm build wiring (2): scripts/{build.js, prepublish.js}.

Rust-ABI bridge (4): script/CopyArtifacts.sol, script/lib/LibCopyArtifacts.sol, test/script/CopyArtifacts.t.sol, and test/concrete/TestDecimalFloat.sol (see open item iii).

CI workflows (5): .github/workflows/{copy-artifacts, rainix-rs-static, rainix-rs-test, rainix-rs-wasm, crate-npm-release}.yaml.

Edited (not counted): flake.nix (restores the test-wasm-build + test-js-bindings tasks the rs/js CI needs), foundry.toml (fs_permissions for ./out + ./crates/float/abi), .gitignore (+target dist temp node_modules .direnv), .soldeerignore + REUSE.toml (rust/js surface), CLAUDE.md (Rust/npm section; 3868 B < 4096 cap).

2. Rewrites applied

• Solidity: test/concrete/TestDecimalFloat.sol import src/lib/LibDecimalFloat.sol → rain-math-float-0.1.7/src/lib/LibDecimalFloat.sol (same rewrite the concrete already carries). CopyArtifacts.sol / LibCopyArtifacts.sol / CopyArtifacts.t.sol use repo-relative paths only — unchanged.
• Rust: none. The crate loads its ABIs via CARGO_MANIFEST_DIR + "/abi/*.json" (crate-relative) and references only crate:: symbols, so it moves wholesale.
• Source-location metadata → the deploy repo (factual move, not a package rename): repository/homepage/bugs in Cargo.toml (root + crate) and package.json now point at rainlanguage/rain.math.float.deploy. Package names left as-is (rain-math-float crate, @rainlanguage/float npm) — see open item (i).

3. Publish wiring

• Soldeer rain-math-float-deploy still publishes via the tag-driven package-release.yaml (rainix-tag-release, sol-v*) — unchanged.
• New crate-npm-release.yaml runs rainix-autopublish on merge-to-main with crate: rain-math-float + npm-package: @rainlanguage/float and no soldeer-package. Kept separate from package-release.yaml on purpose: the crate/npm are ordinary bindings whose version tracks binding-code changes (merge-driven, exactly the library's old flow), whereas the Soldeer deploy package is a frozen artifact that only advances at deploy time (tag, chain-verified). rainix-autopublish takes the three targets independently, so this is a faithful split of the library's single autopublish.

4. Validation (nix develop -c, throwaway copy)

All green:

• forge build → 96 files, Solc 0.8.25, successful (was 92; +4 = CopyArtifacts x3 + TestDecimalFloat).
• CopyArtifacts regenerates the ABIs byte-identical to committed — forge script script/CopyArtifacts.sol --ffi reproduces crates/float/abi/{DecimalFloat,TestDecimalFloat}.json with unchanged sha256. So the crate's committed ABIs already match the deploy repo's build (import rewrite + optimizer_runs = 1_000_000 reproduce them exactly).
• forge test (ex RPC-gated LibDecimalFloatDeployProd) → 59 passed, 0 failed, 1 skipped (36 suites). The +1 vs the pre-ruling run is CopyArtifactsTest.testArtifactsCommitted passing; the skip is the tagged-constants test (nothing published for rain-math-float-deploy yet).
• script/BuildPointers.sol regenerates src/generated/LogTables.pointers.sol byte-identical (fmt-clean) — deterministic.
• cargo build --workspace → ok (rain-math-float + -wasm compile against the local concrete's ABIs).
• cargo test -p rain-math-float → 118 passed, 0 failed (82 + 36; in-memory revm, no RPC). Exercises both the DecimalFloat binding and the #[cfg(test)] TestDecimalFloat binding.
• cargo build --target wasm32-unknown-unknown -r --workspace (the test-wasm-build task / rainix-rs-wasm) → ok.
• npm bindings (test-js-bindings): wasm-bindgen codegen + dist/{cjs,esm} packaging succeed; the build's final tsc --lib ES2022 typecheck fails on wasm-bindgen 0.2.122's Symbol.dispose in the generated .d.ts (TS2550) — see open item (v). Inherited verbatim from the library, not caused by the move; no rainix-rs-* CI workflow runs it.
• cargo fmt --check + cargo clippy --workspace --all-targets (the rainix-rs-static path) → clean, 0 warnings.
• REUSE metadata complete — all 91 repo files carry SPDX headers or REUSE.toml annotations (reuse lint flags only gitignored node_modules deps that the devshell shellHook installs; absent in a real checkout).

Only validatable by a real publish/deploy: the on-chain attest (Manual sol artifacts) + the sol-v* tag → Soldeer publish of rain-math-float-deploy; the rainix-autopublish crate/npm publish; and the LibDecimalFloatDeployProd fork tests (RPC-secret-gated).

5. Revised library-strip plan (written diff; no mergeable PR — boundary)

The library becomes pure Solidity, publishing only the rain-math-float Soldeer package. Tier 2 is no longer gated (the ruling decided it).

• Mandatory add first (Hard Case C): the library-side log-tables etch helper (rebuild combined tables from LibLogTable, deploy via LibDataContract at a create address) + repoint the 8 transcendental tests. Unchanged.
• Tier 1 (Solidity deploy surface): rm test/src/lib/deploy/*.t.sol, test/src/lib/table/LibLogTable.bytes.t.sol, script/Deploy.sol, script/check-published-deploy-constants.sh, .github/workflows/manual-sol-artifacts.yaml; foundry.toml drop rain-deploy + rain-sol-codegen, [rpc_endpoints], [etherscan].
• Tier 2 (concrete — UN-gated): rm src/concrete/DecimalFloat.sol, src/lib/deploy/LibDecimalFloatDeploy.sol, src/generated/LogTables.pointers.sol, script/BuildPointers.sol, script/lib/LibEtchLogTables.sol, test/abstract/LogTest.sol, test/src/concrete/*.t.sol (31); drop the src/generated fs_permissions.
• Rust/npm removal (the ruling's addition): rm crates/**, Cargo.*, package*.json, tsconfig.json, .prettierignore, test_js/**, scripts/*.js, script/CopyArtifacts.sol + script/lib/LibCopyArtifacts.sol + test/script/CopyArtifacts.t.sol, and .github/workflows/{copy-artifacts,rainix-rs-static,rainix-rs-test,rainix-rs-wasm}.yaml. package-release.yaml: drop the crate + npm-package inputs (publish only the rain-math-float Soldeer package). flake.nix: drop the test-wasm-build + test-js-bindings tasks. foundry.toml: drop ffi = true iff no remaining pure-math test uses it (CopyArtifacts + check-published-deploy-constants.sh were the ffi consumers, both moving out — verify against the retained suite).
• Library keeps: the pure-math surface + its 48 tests + the new Hard Case C helper, the TestDecimalFloat harness + its two equivalence tests (per the ruling — see open item iii), and rain-datacontract.
• Ordering: the strip does not LAND until rain-math-float-deploy publishes. A DRAFT strip PR carries blocked-by: rain.math.float.deploy publish.

6. Needs a human decision / open items

• (i) Crate/npm names — rain-math-float (crate) and @rainlanguage/float (npm) now publish from rain.math.float.deploy. Left unchanged in the staging (keeping them avoids a consumer break). Keep, or rename to -deploy? The ruling flagged this as a human choice; nothing here forecloses it.
• (ii) copy-artifacts ↔ Build.sol convention conflict (build gap). The rainix-copy-artifacts reusable (@main) hard-requires script/Build.sol to currency-check any src/generated, but this repo's (and the library's) pointer codegen is script/BuildPointers.sol — a name hardcoded by rain-sol-codegen-0.1.0's filePrefix() in the generated file header. So copy-artifacts fails its gate. The library is red on exactly this right now (run 32284203923, rain.math.float#261). The strip moves this from the library (which drops src/generated + copy-artifacts) to the deploy repo (which gains them). Resolution is a rainix-ecosystem decision, best made once for both: rename the codegen to script/Build.sol and parameterize rain-sol-codegen's hardcoded header, or relax the reusable to accept the repo's actual codegen script. I did not rename unilaterally (it would leave the dep-hardcoded header referencing a non-existent BuildPointers.sol, and diverge from the library + rain.factory.deploy). Everything else in copy-artifacts is proven reproducible above (ABIs + src/generated + fmt all clean) — only this naming gate blocks green.
• (iii) TestDecimalFloat.sol now lives in BOTH repos. The ruling keeps the harness in the library, but the moved crate's #[cfg(test)] path + the CopyArtifacts bridge both need it buildable in the deploy repo, so it is copied here (import rewritten). The deploy copy is authoritative for the crate ABI; the two must stay in sync (or, if the human agrees its only consumers were the Rust crate + its two equivalence tests, drop it from the library post-strip — noted, not assumed).
• (iv) Source-location metadata repointed to rain.math.float.deploy (§2) — confirm that is the intended home for the crate/npm repository fields.
• (v) npm check lib-target mismatch (build gap, inherited). scripts/build.js ends in npm run check = tsc … --lib ES2022, which errors on wasm-bindgen 0.2.122's Symbol.dispose (TS2550, needs --lib esnext/ES2023+). wasm codegen + dist packaging themselves pass; only the typecheck fails. It reproduces identically in the library (verbatim package.json/tsconfig/lockfile) so it is not a split regression, but a real @rainlanguage/float publish via rainix-autopublish would hit it. One-line fix (bump the check --lib to esnext/ES2023) should land with the moved surface.

[thedavidmeister]

Two ruled corrections applied to the rain.math.float.deploy staging

Both open items from the restage comment that the human ruled on are now applied to the staged deploy set (/home/gildlab/artifacts/mathfloat-deploy-staged/). Boundaries unchanged: no repo created, no on-chain deploy, no mergeable strip PR.

Correction 1 — TestDecimalFloat lives in the deploy repo ONLY (was open item iii)

The prior stage kept test/concrete/TestDecimalFloat.sol in both repos. Ruled wrong: the harness exposes LibDecimalFloat.packLossless/unpack "for testing internals from downstream environments, e.g. rust", and its only consumers (the Rust crate + its two equivalence tests) all moved to the deploy repo. So it has a single home here.

Moved into the deploy set (test/concrete/, LibDecimalFloat import repointed src/lib/… → rain-math-float-0.1.7/src/lib/… to match the concrete's own rewrite):

• TestDecimalFloat.unpack.t.sol — moved whole (testUnpackDeployed: deployed TestDecimalFloat.unpack vs direct LibDecimalFloat.unpack).
• DecimalFloat.packLossless.t.sol — moved whole (its only test is testPackDeployed: deployed TestDecimalFloat.packLossless vs direct LibDecimalFloat.packLossless).

TestDecimalFloat.sol was already staged here (the CopyArtifacts bridge + the crate's #[cfg(test)] path need it) — confirmed present, now joined by its two wrapper tests.

Split note: both files are pure deployed-vs-direct equivalence cross-checks — the direct LibDecimalFloat.packLossless/unpack assertions the library must retain were never co-located in them; they live in test/src/lib/LibDecimalFloat.pack.t.sol (e.g. testPackLosslessCoefficientOverflow, testPackLosslessZeroExponentIdentity, testPartsRoundTrip) and across the rest of the pure-math suite. So the "split" resolves to: move both wrapper files whole to the deploy repo; the library's existing direct coverage stands untouched. No carve-out was needed.

Revised library-strip plan (§5 correction): the library drops TestDecimalFloat.sol entirely plus both wrapper test files (test/concrete/{TestDecimalFloat.unpack.t.sol, DecimalFloat.packLossless.t.sol}), and keeps its direct packLossless/unpack coverage via test/src/lib/LibDecimalFloat.pack.t.sol et al. Net: library has no TestDecimalFloat; deploy repo has it once. This supersedes the earlier "library keeps the TestDecimalFloat harness + its two equivalence tests" line.

Correction 2 — script/BuildPointers.sol → script/Build.sol (was open item ii)

rainix-copy-artifacts.yaml (@main) hard-errors when src/generated exists without script/Build.sol ("The codegen script must be script/Build.sol") and then runs forge script ./script/Build.sol. Renamed in the deploy set:

• script/BuildPointers.sol → script/Build.sol, and the contract BuildPointers → Build (every other rainix consumer's script/Build.sol holds contract Build is Script — file↔contract names kept consistent; forge script ./script/Build.sol infers the single contract either way).
• References updated: snapshot-generate-cmd in package-release.yaml, and the README.md / foundry.toml / CLAUDE.md prose that names the codegen script.
• script/CopyArtifacts.sol / LibCopyArtifacts carry no BuildPointers reference (verified) — nothing to change there. No Solidity import of the script exists.

Correction to the ruling's premise — rain-sol-codegen DOES hardcode the name (verified at source). The ruling stated "there is NO rain-sol-codegen hardcoding of the name". That is not true for the pinned rain-sol-codegen = 0.1.0: LibCodeGen.filePrefix() emits a fixed header line // THIS FILE IS AUTOGENERATED BY ./script/BuildPointers.sol into every generated file. The restage agent's hardcoding claim was correct for this version. Consequence:

• The committed src/generated/LogTables.pointers.sol header still reads ./script/BuildPointers.sol and must stay that way — regenerating with the renamed script/Build.sol reproduces that exact header (the string comes from the dependency, not the filename), so editing it by hand would break the copy-artifacts currency check (git-diff gate). I left line 5 untouched; regeneration is byte-identical.
• So after this rename the generated header names a script (BuildPointers.sol) that no longer exists. The only way to make the header follow the rename is to bump rain-sol-codegen to ≥ 0.1.6, where filePrefix() was genericized to // THIS FILE IS AUTOGENERATED BY THE BUILD SCRIPT. DO NOT EDIT BY HAND. — a dependency bump with its own republish-cascade weight, out of scope here. This is a remaining human decision (accept the stale header string under 0.1.0, or bump rain-sol-codegen to 0.1.6+).

Same BuildPointers.sol nonconformance exists in rain.factory.deploy — tracked as a separate follow-up, not touched here.

Validation (nix develop -c, throwaway copy)

• forge build → 98 files, Solc 0.8.25, successful (was 96; +2 = the two moved wrapper tests compile).
• script/Build.sol regenerates src/generated/LogTables.pointers.sol byte-identical — verified the regenerated header line is unchanged (// THIS FILE IS AUTOGENERATED BY ./script/BuildPointers.sol), exactly as rain-sol-codegen 0.1.0 dictates.
• CopyArtifacts.sol --ffi regenerates crates/float/abi/{DecimalFloat,TestDecimalFloat}.json byte-identical.
• forge test (ex RPC-gated LibDecimalFloatDeployProd) → 61 passed, 0 failed, 1 skipped (38 suites; +2 vs the restage's 59). The two moved wrapper tests pass by name: TestDecimalFloatUnpackTest.testUnpackDeployed and DecimalFloatPackLosslessTest.testPackDeployed (2048 runs each). The skip is the tagged-constants test (nothing published for rain-math-float-deploy yet).
• cargo build --workspace → ok; cargo test -p rain-math-float (in-memory revm, no RPC) → green. (No Rust was touched by either correction — crate results are unchanged from the restage baseline.)

Only validatable by a real publish/deploy: the sol-v* tag → Soldeer publish of rain-math-float-deploy; the rainix-autopublish crate/npm publish; the RPC-secret-gated LibDecimalFloatDeployProd fork tests.

Updated counts

Deploy set: 93 regular files + LICENSE symlink = 94 (was 92; +2 wrapper test files). script/ file count unchanged (rename, not add). Library-strip plan: library loses 3 files it was previously slated to keep (TestDecimalFloat.sol + 2 wrapper tests).

[thedavidmeister]

rain-sol-codegen bumped to latest (0.1.36) in the rain.math.float.deploy staging — generic header now, pins held

Per the human ruling ("just use latest codegen"), the staged deploy set (/home/gildlab/artifacts/mathfloat-deploy-staged/) is bumped off the fragile rain-sol-codegen = 0.1.0. This closes open item (ii) from the rename comment: the generated header no longer names the (renamed-away) BuildPointers.sol. Boundaries unchanged: no repo created, no on-chain deploy, no mergeable strip PR.

Version pinned

rain-sol-codegen 0.1.0 → 0.1.36 — verified the newest published revision on the Soldeer registry at run time.

Two forced transitive bumps (codegen 0.1.36's own imports moved to forge-std-1.16.2):

• forge-std 1.16.1 → 1.16.2 — codegen 0.1.36 imports forge-std-1.16.2/...; a Soldeer dep name is single-version, so the repo unifies on 1.16.2 (rewrote all 15 repo .sol forge-std-1.16.1/ import prefixes).
• rain-deploy 0.1.3 → 0.1.7 — rain-deploy-0.1.3's LibRainDeploy imports forge-std-1.16.1; 0.1.7 imports forge-std-1.16.2, so it moves in lockstep with the forge-std unification.

This is exactly the trio rain.extrospection.deploy already ships (forge-std 1.16.2 + rain-sol-codegen 0.1.36 + rain-deploy 0.1.7) — a proven combination, not a new one. Neither forge-std nor rain-deploy is in the deployed-bytecode graph: src/ imports only rain-math-float-0.1.7 (unchanged) + its own generated file, so nothing here can move the Zoltu pins. rain-math-float, rain-datacontract, rain-string, rain-solmem are unchanged (their compiled surfaces carry no forge-std).

API fixes (0.1.0 → 0.1.36 drift)

• script/Build.sol — 0.1.36's LibFs.buildFileForContract (a) always emits bytecodeHashConstantString(instance), which now reverts (CodelessInstance) on the codeless address(0) this build passed, and (b) writes to <Name>.sol, not <Name>.pointers.sol. The log-tables file is pure data with no contract instance behind it, so it was never a codehash-bearing pointers file. Rewrote Build.sol to write the file directly — LibCodeGen.filePrefix() + the five bytesConstantString table constants — at the existing src/generated/LogTables.pointers.sol path. Consequences (all forced by the library, all reproduced by regeneration): the vestigial BYTECODE_HASH = bytes32(0) (grep-confirmed unused outside the generated file) and the circular-dependency comment leave the file, since 0.1.36's filePrefix emits neither.
• script/Deploy.sol — rain-deploy 0.1.7 dropped deployAndBroadcast's trailing depCodeHashes storage-mapping param (9 → 8 args; 0.1.7 checks resolved addresses internally). Dropped that arg from both calls and removed the now-orphaned sDepCodeHashes state var.
• script/CopyArtifacts.sol + script/lib/* — no signature change; only the forge-std import prefix bumped.

Header now generic; pins unchanged

Regenerating src/generated/LogTables.pointers.sol under 0.1.36, the header is now:

// THIS FILE IS AUTOGENERATED BY THE BUILD SCRIPT. DO NOT EDIT BY HAND.

diff vs the old committed file is exactly the header block — the ./script/BuildPointers.sol line + the circular-dependency comment + BYTECODE_HASH = bytes32(0) collapse to that one generic line; the five log/anti-log table constants are byte-identical.

Pins untouched — src/lib/deploy/LibDecimalFloatDeploy.sol was never edited: DecimalFloat 0x799632d282178e770C7465cad54aDA1021A913D6 / codehash 0xdc468883…301f55e; log-tables 0xc51a14251b0dcF0ae24A96b7153991378938f5F5 / 0x2573004a…143420f. And CopyArtifacts regenerates the committed DecimalFloat.json byte-identically, which is a direct proof the creation/deployed bytecode is unchanged — so the deterministic Zoltu address + codehash still hold. optimizer_runs = 1_000_000 kept.

Validation (nix develop -c, throwaway copy)

• forge build → 97 files, Solc 0.8.25, successful.
• forge script ./script/Build.sol regenerates src/generated byte-identical, idempotent, fmt-clean (no --ffi needed).
• forge fmt --check (whole repo) → clean (includes the regenerated file).
• CopyArtifacts.sol --ffi regenerates crates/float/abi/{DecimalFloat,TestDecimalFloat}.json byte-identical.
• forge test (ex RPC-gated LibDecimalFloatDeployProd) → 61 passed, 0 failed, 1 skipped (38 suites) — identical to the pre-bump baseline. The pin-verification tests (deployZoltu address match, the constructor codehash check, checkLogTablesDeployed) are among the 61 green. Skip = the tagged-constants test (nothing published for rain-math-float-deploy yet).
• cargo build --workspace → ok (both crates). cargo test -p rain-math-float (in-memory revm, no RPC) → 118 passed, 0 failed (82 unit + 36 doctests). No Rust was touched; the byte-identical ABIs mean crate results match the baseline.
• soldeer.lock regenerated to the new pins and committed into the staging (the split's precedent deploy repos commit it). CLAUDE.md 3860 B < 4096.

Needs a human decision

None. The bump resolves open item (ii); the forge-std/rain-deploy cascade is forced and proven by the extrospection precedent.

Scope note

This is the deploy staging only. The library rain.math.float (still on codegen 0.1.0, red on the same copy-artifacts BuildPointers gate, run 32284203923) and rain.factory.deploy (the separately-tracked BuildPointers follow-up) are not touched here.