README tells consumers to write script/BuildPointers.sol, which rainix CI rejects outright — plus three more stale claims

[thedavidmeister]

The README tells a consumer to name its codegen script script/BuildPointers.sol. rainix's shared CI matches script/Build.sol exactly and hard-fails on anything else, so a consumer following this README reds its own CI.

Verified against rainlanguage/rainix@main, .github/workflows/rainix-copy-artifacts.yaml:

# `script/Build.sol`, matched exactly: a repo that renames or drops it
if [ -d src/generated ] && [ ! -f script/Build.sol ]; then
  echo "::error::src/generated/ is committed but script/Build.sol was not found, so the committed sources cannot be currency checked here. The codegen script must be script/Build.sol."

README line 11:

script/BuildPointers.sol is an example implementation;

This repo's own script is script/Build.sol, so the repo is correct and only the README is wrong — which is the shape that makes it costly: nothing here goes red, and the failure lands on whoever copies the instruction.

Three more stale claims in the same file, verified against the tree

README says	repo has
.github/workflows/git-clean.yaml is the example CI guard	.github/workflows/build-pointers.yaml
Publish to Soldeer delegates via .github/workflows/publish-soldeer.yaml	.github/workflows/package-release.yaml
"This repo has no forge test suite"	4 suites, 9 tests, before the coverage work now in flight

Separately, build-pointers.yaml's own comment says the reusable "runs BuildPointers.sol"; it runs Build.sol. Wrong but harmless, since nothing reads a comment to decide a filename.

Triage framing

BuildPointers.sol may be a historical name from before rainix pinned Build.sol, in which case this is drift rather than a decision. If the intent is that consumers may choose their own script name, then the disagreement is with rainix's exact match and belongs there instead — but the two cannot both stand as written.