Land the rain.math.float.deploy split: fix npm publish, green CI, library-strip, Soldeer tag

[thedavidmeister]

Tracking issue for landing the rain.math.float → rain.math.float.deploy split. This repo was created and pushed on 2026-08-20; several steps are done, some are broken, some remain. Any session can pick this up from here.

Done (verified)

• Repo created + initial push. Local forge build (97 files) and cargo check (float + float-wasm) were green before push.
• rain-math-float v0.1.11 published to crates.io by this repo's autopublish (crate-npm-release.yaml → rainix-autopublish, which runs on every push to main). This is the intended end state of the split (the crate now publishes from the deploy half), but it fired on the initial push rather than a deliberate release.
• Autopublish bumped versions and pushed a Package Release npm-v0.0.14 commit + tags rain-math-float-v0.1.11 and npm-v0.0.14 to main.
• Staged source: /home/gildlab/artifacts/mathfloat-deploy-staged/ (pristine); work clone /home/gildlab/code/mathfloat-deploy-land.

Broken / in progress

• npm publish FAILED. @rainlanguage/float did NOT publish (still 0.0.0-alpha.40); the Publish to NPM step in the autopublish run errored while Publish to crates.io succeeded. Exact error not yet isolated from the CI log — diagnose the NPM step (candidates: NPM_TOKEN missing/insufficient via org secrets: inherit, a version/dist-tag conflict, or package config). The npm-v0.0.14 tag was created despite the failure.
• rs-static FAILED on a vm.skip(true) in test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol (org no-skips gate rejects it textually). Fixed on branch fix-vmskip-tagged-constants (assertion accepts OK or SKIP, no skip) — NOT merged, because merging re-triggers autopublish.

Remaining

1. Fix the npm publish (above), get rs-static + all CI green.
2. Merge fix-vmskip-tagged-constants (note: every merge to main re-bumps + republishes the crate — this is the design, expect a new rain-math-float version per merge).
3. Library-strip on rain.math.float — remove the deploy surface (concrete, src/generated, deploy scripts/tests) AND the Rust/npm surface (crates/**, Cargo.*, package*.json, test_js/**, scripts/*.js, CopyArtifacts bridge, copy-artifacts.yaml, rainix-rs-*.yaml, crate-npm-release), leaving pure Solidity that publishes only the rain-math-float Soldeer package. This STOPS the library from also publishing the rain-math-float crate/npm (right now BOTH repos publish it). Plan is in the handoffs + rain.math.float#262. Must not land until this deploy repo has published its Soldeer package (below) so consumers can repoint. Keep the Hard-Case-C etch helper for the transcendental tests.
4. Tag sol-v* on this repo to publish rain-math-float-deploy to Soldeer (package-release.yaml → rainix-tag-release; regenerates the pointers snapshot, verifies live chains against the pins, publishes). The deploy pins already reproduce the live Zoltu deployment (optimizer_runs = 1_000_000), so no new on-chain broadcast is required.

Hazards / notes

• Autopublish on every merge to main publishes the crate/npm — work via PRs, and expect a crate version bump per merge.
• Do NOT change optimizer_runs = 1_000_000 — it reproduces the live pins.
• Naming was ruled keep-as-is (rain-math-float crate / @rainlanguage/float npm) to avoid a consumer break.
• Source ruling + plan: rain.math.float#262 and its comments. Handoffs: /home/gildlab/code/amt-datacontract-2026-08-19/handoff-mathfloat-*.md.

[thedavidmeister]

npm failure diagnosed: npm error code E404 on PUT https://registry.npmjs.org/@rainlanguage%2ffloat — "'@rainlanguage/float@0.0.14' is not in this registry." The package exists (latest 0.0.0-alpha.40, published from the library repo), so E404-on-publish means the NPM token available here (via org secrets: inherit) lacks publish rights to @rainlanguage/float — npm returns 404 rather than 403 for permission denial on scoped packages. Likely human/infra: grant the org NPM_TOKEN publish access to @rainlanguage/float (or configure the secret for this repo). The crate publish (crates.io) uses a different token and succeeded. crates.io rain-math-float is now at 0.1.11.

[thedavidmeister]

Current state + ordered next actions (authoritative — a background agent does NOT survive a session cap; drive from here)

Durable handoffs on disk (a fresh session with this filesystem):

• Library-strip work order: /home/gildlab/code/amt-datacontract-2026-08-19/handoff-mathfloat-library-strip.md (I dispatched an agent for this but it will die at cap — RE-DRIVE from this file).
• Split plan + restage: handoff-mathfloat-split.md, handoff-mathfloat-restage.md in the same dir. Source of truth: rain.math.float#262 (issue + comments).
• Work clone: /home/gildlab/code/mathfloat-deploy-land; vm.skip fix committed on local branch fix-vmskip-tagged-constants (NOT pushed).

Ordered next actions:

1. Soldeer publish — git tag sol-v0.1.0 && git push origin sol-v0.1.0 on this repo. Trigger is sol-v* (package-release.yaml → rainix-tag-release); [external.package].version = 0.1.0. This regenerates the pointers snapshot, verifies live chains against the pins, and publishes rain-math-float-deploy to Soldeer. Pins reproduce the live Zoltu deploy (optimizer_runs=1_000_000) so no new broadcast needed. (I am attempting this now — if the run is red, diagnose the tag-release job, do NOT just retag.)
2. vm.skip fix — push branch fix-vmskip-tagged-constants + merge (greens rs-static). Every merge to main re-bumps+republishes the crate — expected.
3. npm publish — E404/token issue, likely human/infra (see prior comment): grant org NPM_TOKEN publish rights to @rainlanguage/float. crates.io already at 0.1.11.
4. Library-strip — land the draft from handoff Land the rain.math.float.deploy split: fix npm publish, green CI, library-strip, Soldeer tag #1 above ONLY AFTER the Soldeer publish (step 1) succeeds, so consumers can repoint. Draft-only until then.

Done: repo live; crate rain-math-float 0.1.11 on crates.io; tags rain-math-float-v0.1.11/npm-v0.0.14 + bump commit on main.

[thedavidmeister]

Update:

• Soldeer publish IN PROGRESS: tag sol-v0.1.0 pushed → package-release run 32392777470 running GitHub-side. Check its result; if red, diagnose the rainix-tag-release job (live-chain verify / pointer regen) — do NOT blindly retag.
• vm.skip fix pushed to remote branch fix-vmskip-tagged-constants (open a PR + merge to green rs-static; merge republishes the crate).
• Once the Soldeer publish (above) succeeds, the library-strip draft (handoff-mathfloat-library-strip.md) can land.

[thedavidmeister]

Library-strip staged as DRAFT PR (step 3): rainlanguage/rain.math.float#263 — pure-Solidity strip of the deploy + Rust/npm surface, green locally (forge build/test 444-pass, slither 0, reuse clean); blocked-by this repo's rain-math-float-deploy Soldeer publish (step 4) before it can land.

[thedavidmeister]

⛔ Soldeer publish FAILED — root cause: DecimalFloat is not deployed on-chain

Run 32392777470 failed at "Verify live chain matches the fresh pins":

[FAIL: arbitrum: DecimalFloat not deployed] testProdDeploymentArbitrum()
[FAIL: base: DecimalFloat not deployed] testProdDeploymentBase()
[FAIL: base_sepolia: DecimalFloat not deployed] testProdDeploymentBaseSepolia()
[FAIL: flare: DecimalFloat not deployed] testProdDeploymentFlare()
[FAIL: polygon: DecimalFloat not deployed] testProdDeploymentPolygon()

Log-tables verify PASS; the fresh pins are internally consistent (testDeployAddress / testExpectedCodeHash pass). The DecimalFloat concrete simply has no code at its deterministic Zoltu address on any prod chain — the "pins reproduce a live deploy" assumption does not hold for DecimalFloat (its bytecode differs from any prior monolithic-repo deploy because it now compiles against the rain-math-float 0.1.7 Soldeer dep, giving a new deterministic address).

Corrected next-action order (this supersedes step 1 in the earlier comment)

1. On-chain deploy FIRST (human-dispatched, needs deployer key): run the Manual sol artifacts workflow (workflow_dispatch, decimal-float suite) on each target chain to CREATE2-deploy DecimalFloat at its Zoltu address. Zoltu is permissionless, so this only needs a funded deployer key. Log-tables are already deployed.
2. Re-tag sol-v0.1.0 (delete + re-push the tag, or bump) → package-release re-runs; live-chain verify now passes → rain-math-float-deploy publishes to Soldeer.
3. Then land the strip draft PR Strip deploy + Rust/npm surface: the library half is Solidity only rain.math.float#263 (ready: draft, all CI green, 77 files removed, 444 tests pass — correctly blocked on this publish).

Also still open

• npm E404 (token perms, human) and the fix-vmskip-tagged-constants PR+merge (greens rs-static) — both independent of the deploy blocker above.

[thedavidmeister]

On-chain deploy dispatched: Manual sol artifacts (decimal-float suite) → run 32394528758. Deploys DecimalFloat at its Zoltu address across the configured chains (log-tables already live). When green: re-tag sol-v0.1.0 → Soldeer publish → land strip PR #263.

[thedavidmeister]

Which repo owns the crate and the npm package: the library is the stale claimant

Both repos currently claim the same two artifacts, and both trigger on push to
main:

	crate	npm	soldeer
rain.math.float.deploy → crate-npm-release.yaml	rain-math-float	@rainlanguage/float	—
rain.math.float → package-release.yaml	rain-math-float	@rainlanguage/float	rain-math-float

The soldeer names do not collide (rain-math-float vs
rain-math-float-deploy). Only the crate and npm names do.

The deploy half should keep both, and the library's claim is the one to
remove. Evidence, in order of weight:

1. crates.io already says so. rain-math-float 0.1.11 was published by
   this repo's autopublish; the registry's updated_at is
   2026-08-20T16:20:40Z, this repo's initial push. The library repo's
   crates/float/Cargo.toml is still on 0.1.10 — it is behind the version this
   repo shipped. Same on npm: package.json is 0.0.14 here, 0.0.13 there.
2. The issue body already ruled it. "the crate now publishes from the
   deploy half" is called the intended end state of the split.
3. Remaining item 3 already schedules the removal on the library side —
   the strip removes crates/**, Cargo.*, package*.json, test_js/** and
   crate-npm-release from rain.math.float, and says in as many words that
   this is what "STOPS the library from also publishing the crate/npm".
4. The code only builds here. crates/float is alloy::sol! bindings over
   the concrete DecimalFloat's committed ABI and deployed bytecode, and the
   concrete only exists in this repo. After the strip the library cannot
   produce the crate at all.

So nothing was changed in rain.math.float.deploy for this. Removing the claim
here would hand the crate back to a repo that is about to lose the source for
it.

The de-claim can land now, ahead of the blocked strip

rain.math.float#263 is the full strip and is correctly blocked on this repo's
Soldeer publish, which is in turn blocked on the on-chain deploy. But the
race does not need to wait for any of that. Deleting two lines from
rain.math.float's .github/workflows/package-release.yaml:

     with:
-      crate: rain-math-float
-      npm-package: "@rainlanguage/float"
       soldeer-package: rain-math-float

leaves the library publishing only its Soldeer package — which it must keep —
and stops two workflows racing to bump and publish the same crate and the same
npm package on every push to either main. It touches no consumer and does not
depend on the deploy. It is strictly a subset of what #263 does later.

I have not made that change: rain.math.float is owned by another agent.

npm E404 — this issue's "not yet isolated" is out of date

Split out to #7 with the full diagnosis. Short version: it is a token
permission problem on @rainlanguage/float, NPM_PUBLISH_PRIVATE_TOKEN is
visible to this repo (checked against the org-secrets API, not inferred from
secrets: inherit), and it has been failing since long before the split — the
registry has 41 0.0.0-alpha.N versions, no 0.0.x at all, and nothing newer
than 2025-12-01, while package.json has walked to 0.0.14 because
rainix-autopublish pushes the bump commit at step 326 and only attempts the
publish at step 345.

It does not block the Soldeer release. Publish to Soldeer is step 261 in
rainix-autopublish.yaml; npm is 345. Soldeer goes first, so the Solidity
packages can ship with npm still red.