docs: drop the false "AddressRegistry is the only concrete" premise

[thedavidmeister]

Closes #75

What was wrong

MigrationRegistry is a second concrete in src/concrete/, declared as a candidate in RegistryDeploySuites and carrying its own generated snapshot under src/generated/candidate/. Every doc that justifies itself with "AddressRegistry is the only concrete/creation code in this repo" is therefore asserting something false.

Departure from the issue's proposed wording — please read

The issue proposes replacing the false premise with a chain-safety rationale: the second address must be a freely-etchable mock "rather than a second real registry whose pinned address the chain matrix also asserts about".

I did not use that wording, because it would have replaced one false statement with another. Two sibling files argue at length for the opposite, and they are right:

• test/src/abstract/RainDeployVerifyChain.t.sol:52-55 — "Pointing the fixture at a mock nobody deploys would move that dependency rather than remove it: the Zoltu factory is permissionless, so no address is structurally unoccupiable. Etching the state the assertion is about is what removes it."
• test/src/abstract/RainDeployVerifyChainCandidate.t.sol:75-80 — makes the same argument for the candidate's absence.

So a mock is not structurally safer than a real registry here; the etch is what makes either safe. The proposed rationale also does not distinguish the two entries, since the fixture's first entry is already a real deployed address (AddressRegistry) that the fixtures etch and empty. And RegistryDeployChainTest reads releasedSuites(), which is empty — this repo has released nothing — so "the real chain group asserts about it too" is not true of any address today.

Restated instead as the reason that actually holds and is checkable from the code: this is a fixture for the abstracts, not a copy of RegistryDeploySuites, so what the abstracts are tested against is written in the file rather than tracking whatever src/concrete/ currently holds. That is what makes swapping MockDeployableV2 for MigrationRegistry the wrong move — the thing the paragraph exists to prevent.

Scope: three instances, not one

The issue cites one line; the same falsehood appears three times, so this covers the category.

1. test/abstract/ExampleDeploySuites.sol:28-30 — the cited one, and the one that matters: it argued for a change that would collapse the "loop does not stop at the first entry" coverage.
2. test/src/abstract/RainDeployVerifyChain.t.sol:63-64 — called MockDeployableV2 "the only other creation code in this repo". Restated as the load-bearing fact: it is the same derivation ExampleDeploySuites declares, which is why the setUp etch lands on the address the matrix reads.
3. .github/workflows/package-release.yaml:2-3 — named a single deployed concrete. Its sibling manual-sol-artifacts.yaml already names both.

QA

• Discriminating tests: n/a — the diff changes only comment text and a YAML comment. There is no behaviour to discriminate: no test can fail on base and pass here, because nothing this repo executes reads a comment. The relevant assertion is factual accuracy of the prose, checked against source below rather than by a test.
• Mutations applied: n/a — a docs-only diff has no executable line to mutate. Mutating any comment character produces an identical build and an identical 215-test result, which is the definition of no mutable surface.
• Oracle: the repo's own source, read independently of the comments being fixed. ls src/concrete/ returns AddressRegistry.sol and MigrationRegistry.sol; ls src/generated/candidate/ returns snapshots for both; RegistryDeploySuites.candidateSuites() builds a length-2 array from addressRegistryCandidate() and migrationRegistryCandidate(); CLAUDE.md names both as ordinary deployed contracts. That is what falsifies "the only concrete". For the replacement text, the oracle is the sibling reasoning quoted above (RainDeployVerifyChain.t.sol:52-55, RainDeployVerifyChainCandidate.t.sol:75-80) plus migrationRegistryCandidate()'s dependencies: new address[](0) — which is why the issue's proposed chain-safety rationale has no mechanical basis and was not used.
• Category check: the issue asks for one line (ExampleDeploySuites.sol:28-30). The category is "docs asserting AddressRegistry is the repo's only concrete/creation code". grep -rn "only concrete\|only other creation code" --include=*.sol finds 2 hits, both fixed; a sweep for single-concrete claims in workflows/docs found a 3rd in package-release.yaml, also fixed. Covered: all 3. Not covered: nothing in this category remains — the same greps return only the corrected text.

Verification

Documentation only — no behavioural change, no deployed bytecode touched.

• forge fmt --check — clean
• forge build — clean
• forge test with all five fork RPCs configured — 215 passed, 0 failed, 0 skipped across 17 suites, including the chain/fork suites that consume both edited Solidity files
• pre-commit (yamlfmt, no-consumer-prettier) — passed on the workflow edit

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 22 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: fe198621-8704-49c2-9817-9a2f908d8033

📥 Commits

Reviewing files that changed from the base of the PR and between 86f8d96 and cb2c9a8.

📒 Files selected for processing (3)

• .github/workflows/package-release.yaml
• test/abstract/ExampleDeploySuites.sol
• test/src/abstract/RainDeployVerifyChain.t.sol

---

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.}

[thedavidmeister]

Reviewed 7e2c845: ready — Closes #75. Comments only, and both corrections are factually right: this repo carries TWO deployed concretes, AddressRegistry and MigrationRegistry, so the workflow comment's singular was stale and ExampleDeploySuites' "AddressRegistry is the only concrete in this repo" was simply false.

The replacement is better than a count fix. It says why the second address comes from a mock rather than from the other real concrete — the fixture borrows ONE real snapshot to keep the released and candidate paths real, and derives everything else inline, so what the abstracts are tested against does not move when src/concrete/ gains or loses a contract. That is a reason a reader can act on.

CI green, 0 unresolved threads — vacuous, CodeRabbit reports Review rate limited.