docs: correct six stale README claims, one of which reds a consumer's CI

[thedavidmeister]

Closes#42

Docs-only. Every claim in README.md was checked against the tree at af4e5a9, not just the four the issue named, and two more were wrong.

The one that costs a consumer

The README told consumers to name their codegen script script/BuildPointers.sol. rainix's rainix-copy-artifacts.yaml regenerates from script/Build.sol matched by that exact path, and hard-errors when src/generated/ is committed without it. This repo's own script is correctly Build.sol, so nothing here goes red and the whole cost lands on whoever copies the instruction.

The rewrite does not just swap the filename — it says the name is not a free choice and why, so the next reader does not "improve" it back.

Everything corrected

README said	tree has
script/BuildPointers.sol	script/Build.sol
.github/workflows/git-clean.yaml	.github/workflows/build-pointers.yaml
.github/workflows/publish-soldeer.yaml, named Publish to Soldeer	.github/workflows/package-release.yaml, named Package Release
"This repo has no forge test suite"	15 suites, 84 tests, all passing
Tasks rainix-sol-static, rainix-sol-legal	neither exists — not on PATH in the pinned shell, and not a package in rainix main's flake either
"Tag v<x.y.z> on main" to publish	publishing is push-to-main autopublish; tags are sol-v<x.y.z> and are cut by the workflow
the reusable "derives the package name from the repo name"	package-release.yaml passes soldeer-package: rain-sol-codegen explicitly
REUSE 3.2	reuse lint in this repo's own shell reports 3.3
interfaces for "interpreter, sub-parsers, externs"	IIntegrityToolingV1, IOpcodeToolingV1, IParserToolingV1, ISubParserToolingV1 — "externs" is an implementer, not an interface

The last four are the two the issue did not have, plus the two the issue framed only as a filename swap but which were wrong about the mechanism as well. nix develop -c rainix-sol-legal, the command the License section told a reader to run to verify compliance, was one of the non-existent tasks — it fails outright.

The five dangling git-clean.yaml references across the four interface NatSpecs are repointed at build-pointers.yaml. Those ship to Soldeer consumers, so a dead path there travels further than the README's.

build-pointers.yaml's own comment claimed the reusable "runs BuildPointers.sol"; it runs script/Build.sol. Corrected, and the two sentences of history in it dropped, per comments describing current behaviour only.

Decisions

No test count in the README. The false claim was "no forge test suite"; the fix is that there is one and here is how to run it. A number would be stale by the next PR — the claim this issue exists to kill was itself a count-shaped assertion that rotted.

Checks are listed as the tools, not as wrappers.forge test, forge fmt --check, slither ., reuse lint are exactly what rainix's rainix-sol-{test,static,legal} reusables run, and all four work in the shell today. The old rainix-sol-* task names were the failure mode being fixed, so the replacement points at the workflow file for the org-wide checks rather than re-enumerating names that can be renamed again.

The Publish section states the next-version invariant.[package].version is 0.1.7 while Soldeer holds 0.1.6; a reader who assumes the manifest is the last publish will bump it by hand and break the gate. This is current behaviour of rainix-autopublish.yaml as wired here — it does not pre-empt #24, which is about whether that lifecycle should live here at all.

No sibling files touched. The stale-reference grep is clean of LibFs.sol, LibCodeGen.sol, LibHexString.sol and foundry.lock; nothing here needs to land in another agent's PR.

Verified

All four run against this branch, in the repo's own pinned shell:

• forge test — 84 passed, 0 failed, 0 skipped, 15 suites
• forge fmt --check — clean
• slither . — 9 contracts, 98 detectors, 0 results
• reuse lint — 43/43 files, compliant with REUSE 3.3
• pre-commit run --all-files — all hooks pass
• forge script script/Build.sol — runs clean and leaves src/generated/CodeGennable.sol byte-identical, so the currency check the README now describes is the one that actually holds

QA

• Discriminating tests: n/a — the diff is comments and prose, and adds no branch a test can discriminate. The claims are instead each executed: the four check commands, the build script's no-op regeneration and command -v for the two task names are run above, and every filename in the diff is a path that exists in the tree.
• Mutations applied: n/a on a docs-only diff — there is no line whose inversion a test could kill. The equivalent adversarial pass was run against the documentation instead: every claim in the file was treated as suspect and falsified against the tree rather than only the four the issue named, which is what turned up the rainix-sol-* tasks, the tag-vs-merge publish trigger, the derived-package-name claim and REUSE 3.2.
• Oracle: the tree at af4e5a9 and rainix main — rainix-copy-artifacts.yaml's exact-match error, rainix-autopublish.yaml's soldeer-package input and sol-v tag, rainix's flake.nix package list for the task names, git ls-remote --tags for the tag shape, and each tool's own output for the counts. Not any prior statement of the counts: the issue body's "4 suites, 9 tests" predates the coverage work, and audit: record the adversarial mutation-test scan of sol-v0.1.6 #49's body puts the post-coverage suite at 102 tests, but forge test on main reports 84 across 15 suites and grep -c 'function test' over test/ independently agrees at 84. Flagging that separately; nothing in this diff rests on it, since the README now carries no count.
• Category check: the issue names four claims and one comment; the category is "a claim in this file that the tree contradicts", so the whole file was swept. Six wrong claims found, all six fixed, plus the five NatSpec references and the workflow comment. grep for git-clean, BuildPointers and publish-soldeer across the repo returns nothing.

[coderabbitai]

Warning

Review limit reached

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

Next review available in:59 minutes

Limit details: You’ve used all 1 included review currently available under your plan.

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: 1859fe13-8ea9-4353-b764-a5280c022fa0

📥 Commits

Reviewing files that changed from the base of the PR and between af4e5a9 and 9bc140e.

📒 Files selected for processing (6)

• .github/workflows/build-pointers.yaml
• README.md
• src/interface/IIntegrityToolingV1.sol
• src/interface/IOpcodeToolingV1.sol
• src/interface/IParserToolingV1.sol
• src/interface/ISubParserToolingV1.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 9bc140e: ready — Closes #42.

The issue named four false claims. The sweep found six, and two are worse than a stale filename:

rainix-sol-static and rainix-sol-legal do not exist — not on PATH in the pinned shell, and not packages in rainix main's flake. The License section told a reader to run nix develop -c rainix-sol-legal, which fails outright. And the Publish section was wrong about the MECHANISM rather than a name: it told a human to hand-tag v<x.y.z> on main, when rainix-autopublish.yaml does both the tagging and the version bump, and the tags are sol-v<x.y.z>.

The original four stand: script/BuildPointers.sol against rainix's exact script/Build.sol match, git-clean.yaml against build-pointers.yaml, publish-soldeer.yaml against package-release.yaml, and "no forge test suite" against 15 suites. Plus REUSE 3.2 where reuse lint reports 3.3, and an interface list naming interpreter/sub-parsers/externs where the tree has IIntegrityToolingV1/IOpcodeToolingV1/IParserToolingV1/ISubParserToolingV1.

Two decisions I agree with. Checks are listed as the tools that actually run — forge test, forge fmt --check, slither ., reuse lint — rather than wrapper names, since non-existent wrapper names were the defect and a name can be renamed out from under the doc again. And the count-shaped claim is replaced with the command rather than a new number: "no forge test suite" rotted because it asserted a count, and "84 tests" would rot the same way.

That correction also lands on me. I told this agent the suite was 102 tests across 13 suites. It is 84 across 15, which I have since confirmed by running forge test on main at af4e5a9 — I had summed three branch totals that each included the original 9. The scan record in audit/mutation-test-scans.json carries the same wrong figure and needs a one-field fix.

Also fixed: build-pointers.yaml's comment claimed the reusable runs BuildPointers.sol; it runs Build.sol.

All four checks green, and the diff is disjoint from #50 which landed since. CodeRabbit reports Review rate limited — a green check with no review behind it, so its zero threads is not coverage.