Cut release 0.1.1 on the latest rain-metadata, so a consumer can hold both halves

[thedavidmeister]

What

Three commits, in order:

1. rain-metadata 0.1.5 → 0.1.7 — the latest published library half.
2. .soldeerignore — stop shipping the rust crate to solidity consumers.
3. Cut release 0.1.1 — [external.package].version 0.1.0 → 0.1.1 plus the
   frozen src/generated/0_1_1/, in lockstep.

Why

rain.metadata sol-v0.1.6 / sol-v0.1.7 finished the split this repo is the
other half of: src/concrete/MetaBoard.sol and
src/lib/deploy/LibMetaBoardDeploy.sol are gone from there. 0.1.5 was the last
rain-metadata publish still carrying both, and this repo was still pinned to
it — so a consumer wanting the current library half and these deploy pins
needed rain-metadata at two versions at once, which soldeer cannot do (one
version per package name).

Published rain-metadata-deploy 0.1.0 has the same problem baked in: its
src/concrete/MetaBoard.sol imports rain-metadata-0.1.5/…, so anything
reaching the concrete or MetaBoardDeploySuites drags 0.1.5 in behind it.
0.1.1 is the package that does not.

No pin moves

Nothing MetaBoard reaches changed between rain-metadata sol-v0.1.5 and
sol-v0.1.7 — IMetaBoardV1_2, IMetaV1_2, LibIMetaBoardV1_2 and LibMeta
are untouched across both tags. forge script ./script/Build.sol regenerates
src/generated/candidate/MetaBoard.sol byte-for-byte identical, so:

deploy address	0x8fD50fF9Db9835ba1B61394752A26F53D721D2a1 (unchanged)
codehash	0xb7b74d879e97f272145d32ce18bd060f1e9f387696911376191ca10ecf24bed6 (unchanged)

src/generated/0_1_1/MetaBoard.sol is therefore byte-identical to 0_1_0/.
That is the honest record, not a redundancy: release-guard requires
src/generated/<version>/ to be present in the tagged commit and byte-identical
to a freshly regenerated candidate/, so a release cannot be published without
freezing one, and the record is append-only so an existing tag cannot be reused.
0.1.1 records the same live deployment that 0.1.0 does; what it adds is a
package whose own rain-metadata pin is the current one.

Deploy → verify → tag

Deploy is already done and is not part of this PR. MetaBoard is live at
0x8fD50fF9… with the codehash above on all seven supported networks
(arbitrum, base, base_sepolia, ethereum, flare, hyperevm, polygon).
MetaBoardDeployChainTest is green against all seven, and
SubgraphStartBlockTest re-confirms every networks.json start block is the
deploy block (code at startBlock, none at startBlock - 1) on archive
endpoints for each.

Once merged, the release is the tag:

git tag sol-v0.1.1 <merge commit> && git push origin sol-v0.1.1

rainix-static release-guard --version 0.1.1 is green on this branch.

What a consumer imports

Unchanged in shape from 0.1.0 — the alias lib is the stable path and it aliases
candidate/, so which snapshot backs it never leaks into the import:

// foundry.toml
// "rain-metadata-deploy" = "0.1.1"
import {LibMetaBoardDeploy} from "rain-metadata-deploy-0.1.1/src/lib/LibMetaBoardDeploy.sol";

LibMetaBoardDeploy.META_BOARD_DEPLOYED_ADDRESS   // 0x8fD50fF9Db9835ba1B61394752A26F53D721D2a1
LibMetaBoardDeploy.META_BOARD_DEPLOYED_CODEHASH  // 0xb7b74d87…4bed6

That file imports only ../generated/candidate/MetaBoard.sol, which imports
nothing, so putting the board in a DeploySuite.dependencies list pulls in no
rain-metadata at all. A consumer that also wants the interfaces or
LibIMetaBoardV1_2 declares rain-metadata = "0.1.7" alongside, and after this
release the two agree.

Not in this PR

.gas-snapshot is stale on main already (it records
testSnapshotInternallyConsistent at 164250 against an actual 324995 — the
0.1.0 release moved it and the file was not regenerated). Nothing in CI reads or
writes it, and refreshing it here would be unrelated churn in a release cut.

QA

• Discriminating tests: none added — n/a, and deliberately so. This diff adds no
  behaviour: an import-prefix rename, four .soldeerignore lines, a version
  bump and a generated frozen snapshot. Every claim it makes is already
  discriminated by shipped tests, and the mutations below are how that was
  checked rather than asserted. Full suite green on this branch: 20 passed, 0
  failed, both fork suites included (MetaBoardDeployChainTest and
  SubgraphStartBlockTest run against live archive endpoints for all seven
  networks, not skipped). rainix-static release-guard --version 0.1.1 green;
  forge fmt --check green; slither . 0 results; rainix-sol-single-contract
  rc=0.
• Mutations applied:
  • src/generated/0_1_1/MetaBoard.sol:12 → DEPLOYED_ADDRESS retargeted to the
    old v1 board 0xfb8437Ae…6928 → killed by 3:
    MetaBoardDeploySnapshotTest::testSnapshotInternallyConsistent
    (StoredAddressMismatch("metaboard@0_1_1", …)),
    MetaBoardDeploySnapshotTest::testEveryFrozenSnapshotIsReleased
    (FrozenSnapshotNotReleased("src/generated/0_1_1/MetaBoard.sol")),
    SubgraphDeployRecordTest::testEveryReleasedDeployIsIndexedOnEveryNetwork.
  • src/generated/candidate/MetaBoard.sol:16 → one byte flipped in
    CREATION_CODE (…5f80fd5b50 → …5f80fd5b51) → killed by 4:
    testSnapshotMatchesSource (CandidateSourceMismatch),
    testSnapshotInternallyConsistent (StoredAddressMismatch),
    LibMetaBoardDeployCandidateTest::testCandidateCreationCodeMatchesSource,
    LibMetaBoardDeployCandidateTest::testCandidateReproducesItsDeployment.
    This is the mutant that matters here: it is exactly the shape the
    rain-metadata bump would take if it HAD moved the bytecode, and the suite
    reds on it. The bump regenerating candidate/ unchanged is therefore a
    checked result, not an assumption.
  • Both restored; worktree clean and the suite back to 20/20 before pushing.
• Oracle: outside this repo in every case. The address and codehash come from
  eth_getCode against seven independent public RPCs, hashed with cast keccak
  — arbitrum, base, base_sepolia, ethereum, flare, hyperevm, polygon all return
  0xb7b74d879e97f272145d32ce18bd060f1e9f387696911376191ca10ecf24bed6 at
  0x8fD50fF9…. Start blocks come from the same call at startBlock and
  startBlock - 1 on archive endpoints (note: rpc.hyperliquid.xyz/evm is NOT
  archive — it answers historical reads with current state; hyperevm was
  confirmed on two other archive endpoints instead). "0.1.7 is the latest
  rain-metadata" comes from the Soldeer registry API, and "nothing MetaBoard
  reaches changed" from the upstream sol-v0.1.5...sol-v0.1.7 compare, which
  touches none of IMetaBoardV1_2, IMetaV1_2, LibIMetaBoardV1_2, LibMeta.
• Category check: no issue to cover — n/a. There is no filed issue; the ask was
  the release itself (get this repo onto the latest rain-metadata and publish
  a version raindex can depend on). The .soldeerignore commit is the one thing
  here nobody asked for: it is a §8 conformance gap this release would otherwise
  re-publish, and it is split into its own commit so it can be dropped without
  touching the release.

Summary by CodeRabbit

• New Features

  • Added the frozen MetaBoard 0.1.1 release to the list of available deployments.
  • Included deployment metadata for the new release.

• Chores

  • Updated the project release version to 0.1.1.
  • Updated the Rain metadata integration to version 0.1.7.
  • Excluded Rust project files and directories from package tracking.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4fb821cb-c3ca-4258-8c27-c698776068ba

📥 Commits

Reviewing files that changed from the base of the PR and between 03c05df and 4a1ac44.

⛔ Files ignored due to path filters (2)

• soldeer.lock is excluded by !**/*.lock
• src/generated/0_1_1/MetaBoard.sol is excluded by !**/generated/**

📒 Files selected for processing (7)

• .soldeerignore
• foundry.toml
• src/concrete/MetaBoard.sol
• src/lib/LibMetaBoardReleased.sol
• test/src/concrete/MetaBoard.t.sol
• test/src/concrete/MetaBoardLibEquivalence.t.sol
• test/src/concrete/TestLibIMetaBoardV1_2.sol

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

Walkthrough

The project updates its rain-metadata dependency to 0.1.7, updates Soldeer release metadata to 0.1.1, and registers the frozen metaboard@0_1_1 deployment suite.

Changes

MetaBoard release update

Layer / File(s)	Summary
rain-metadata 0.1.7 alignment foundry.toml, src/concrete/MetaBoard.sol, test/src/concrete/*	Project and test imports now use rain-metadata-0.1.7.
MetaBoard 0.1.1 release registration src/lib/LibMetaBoardReleased.sol, foundry.toml, .soldeerignore	The release library registers metaboard@0_1_1 with its generated deployment artifacts and dependencies. Soldeer metadata and ignore rules are updated.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 4a1ac

The package updates its rain-metadata dependency, excludes the rust crate, and freezes the 0.1.1 release snapshot without changing deployed behavior; no actionable merge-blocking risk remains.

Suggested reviewers: claude

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the release 0.1.1 cut and the rain-metadata dependency update.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (7 skipped: 7 unsupported.)
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 2026-08-23-cut-release-0.1.1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}