The README narrates rainix's workflow internals in four places, so it drifts whenever rainix changes and nothing here can catch it

[thedavidmeister]

The README restates how rainix's reusable workflows behave, in four places. Each
is a second copy of a fact rainix owns, and a copy that drifts independently of
the thing it describes.

This is filed as a property, not a list of four edits: the README documents
this package's own facts and choices; it does not restate the behaviour of the
third-party systems it uses. The four below are the instances that exist
today, not the boundary of the rule. A fifth added tomorrow is the same defect.

Precedent, same rule applied elsewhere in the org: shared CI lives in rainix's
reusables rather than being re-implemented per consumer; the mutation-scan
ledger format lives in the skill that writes it
(rainlanguage/adversarial-mutation-test#25) rather
than in each repo holding a ledger. PR #117 and issue #82 were closed under this
same rule for soldeer's install semantics — how soldeer resolves dependencies,
what remappings it writes and how a missing prefix fails are soldeer's to
document, identical for every package it serves.

The instances

1. README.md:14-18 — "rainix's rainix-copy-artifacts.yaml reusable
regenerates from script/Build.sol exactly, and hard-fails any repo that
commits src/generated/ without one."

2. README.md:38-42 — "rainix-copy-artifacts regenerates, runs
forge fmt, then git diff --exit-code, so that reflow is committed as the new
baseline instead of being reported." A step-by-step of the reusable's internals.

3. README.md:76-80 — the acute one. It enumerates rainix-sol.yaml's
fan-out and names six specific gates out of rainix-sol-static.yaml: no ignored
tests, no git submodules, an agent context cap, append-only frozen snapshots, no
custom NatSpec, one contract per .sol file. That is a transcription of another
repo's workflow file, and it is wrong the day rainix adds a seventh, drops one,
or renames one. (Landed by PR #120, which was correct against rainix at the time
— the problem is structural, not a defect in that PR's accuracy.)

4. README.md:86-94 — the Publish section's account of what
rainix-autopublish.yaml does: pushes the version to Soldeer, tags
sol-v<x.y.z>, bumps [package].version.

This is already biting

rainlanguage/rainix HEAD 7f223b4: rainix-copy-artifacts.yaml runs
forge script ./script/Build.sol exactly once, inside a plain
if [ -f ... ] guard. There is no loop, no max-codegen-passes input (0 hits
for the string across the whole rainix repo), no default of 5 and no
did not reach a fixed point failure — the only failure it can emit is
Committed artifacts are stale. rainlanguage/rainix#319, which would add the
bound, is still open.

Open PR #136 documents that bound in this README as though it exists. It is not
a careless PR; it is what this pattern produces. A README that narrates another
repo's CI will eventually narrate a version of it that is not deployed, and
nothing in this repo's CI can catch it — there is no check that any sentence
here still matches rainix.

What is genuinely this repo's, and must survive

Do not strip these while cutting. Each is a fact about this package or a
consequence a consumer must act on:

• Consumers need line_length = 120 and tab_width = 4, because LibCodeGen
  wraps against MAX_LINE_LENGTH / NEWLINE_DUE_TO_MAX_LENGTH and this repo
  states those in [fmt] rather than inheriting them. The requirement is
  this repo's; the account of how rainix-copy-artifacts enforces it is not.
• A consumer's build script must live at script/Build.sol. The constraint on
  the consumer is worth stating; the description of what the reusable does with
  it is not.
• [package].version in foundry.toml is the next, unpublished version
  rather than the last published one, and neither version nor tag is set by
  hand. That is surprising, it is about this repo's foundry.toml, and a reader
  editing that file needs it.
• This repo passes soldeer-package: rain-sol-codegen explicitly.
• The four local checks (forge test, forge fmt --check, slither .,
  reuse lint) and that CI also runs them.
• src/generated/ and meta/ are test scratch here, created on demand and
  committed empty-handed.

Proposed fix

For each instance, keep the consequence and drop the mechanism, linking to the
workflow that owns it rather than transcribing it. A reader who needs rainix's
internals should be sent to rainix, in one link, once.

Concretely for instance 3, something of the shape: rainix.yaml runs the four
checks above in CI via rainix's rainix-sol.yaml, and adds org-wide gates with
no local equivalent — see
rainix-sol-static.yaml
— so a green local run is necessary but not sufficient. The reader gets the
actionable fact (local green is not enough) and the authoritative source, and
the six-item list stops being this repo's to maintain.

The same treatment for 1, 2 and 4: state the requirement or the consequence,
link the workflow, delete the narration.

Related

• PR docs: state the fixed-point bound and how a non-converging build reports #136 adds a fifth instance and should be resolved against this rather than
  merged as-is.
• The published package is never compiled as published, and ships a file whose import it excludes #76 — the published package is never compiled as published. Separate and
  still live.