Move soldeer release metadata under foundry's [external] section

[thedavidmeister]

Closes #122

Verified against main first

The issue was filed weeks ago; main has moved a lot. Re-measured on
7620643 (main at branch point):

• foundry.toml still opens with a bare [package], and
  nix develop -c forge config still prints, on every invocation:

  Warning: Found unknown config section in foundry.toml: [package]
  This notation for profiles has been deprecated and may result in the profile not being registered in future versions.
  Please use [profile.package] instead or run `forge config --fix`.
  

• The repo does call rainix's autopublish: .github/workflows/package-release.yaml
  is rainix-autopublish.yaml@main with soldeer-package: rain-solmem, so
  version is the next, unpublished slot and is rewritten by the release.

• The issue also says to fix prose naming [package].version. This repo's
  README does not name it — grep -rn '\[package\]\|package\.version' over
  *.md/*.toml/*.yaml/*.nix hits foundry.toml:1 and nothing else. So
  this PR is one file.

Changed

[package] → [external.package], with a comment saying what the section is.
[external.*] is the section foundry reserves for another tool's config and
ignores (foundry-rs/foundry#5866), and it is excluded from forge config --fix
(#12723).

Publishing is provably untouched

rainix-static soldeer-gate at the SHA rainix-autopublish.yaml pins
(53e96a7d), run with only foundry.toml differing:

before: remote=0.1.16 publish=0.1.17 next=0.1.18 OLD=9e5cb50b… NEW=81e4a496…
after:  remote=0.1.16 publish=0.1.17 next=0.1.18 OLD=9e5cb50b… NEW=81e4a496…

Byte-identical content hash, same version/next, same changed=true (main
has content changes vs the published 0.1.16 from today's other merges; this
diff contributes none — foundry.toml is in .soldeerignore). The gate runs
forge soldeer push --dry-run internally, so the dry-run also succeeds on the
new section. Autopublish's bump step
(sed -i -E "0,/^version[[:space:]]*=.*/s//version = \"$NEXT\"/" foundry.toml)
applied to the new file rewrites line 7 to 0.1.18 and touches nothing else —
the four comment lines contain the word version but are # -prefixed, so they
do not match the ^version anchor.

Mutation table

There is no executable line in the diff, so the mutants are of the changed TOML
region and the oracles are the three tools that read it: forge config,
rainix-static soldeer-gate (what autopublish reads), and the bump sed.
Baseline first, so a "killed" is not a tool that errors on everything.

#	Mutant	Oracle	Result
—	baseline ([external.package])	forge config	0 warnings
—	baseline	soldeer-gate	exit 0, version=0.1.17 next=0.1.18 NEW=81e4a496…
1	[external.package] → [package] (revert)	forge config	killed — 1 warning: Found unknown config section in foundry.toml: [package]
2	[external.package] → [profile.package] (forge config --fix's suggestion)	forge config	killed — 2 warnings: Found unknown 'name' config for profile 'package', same for version
3	indent the version line by two spaces	soldeer-gate	killed — exit 1, ::error::foundry.toml has no [package].version
4	version = "0.1.17" → "0.1.15"	soldeer-gate	killed — exit 1, ::error::foundry.toml [package].version (0.1.15) is not ahead of the published revision (0.1.16)

Mutants 3 and 4 are the ones that prove the rename did not detach the reader
from the value: the gate still finds that exact line under the new section
header, reports its value, and fails loudly on it. Mutants 3 and 4 both pass
forge config with 0 warnings, and mutants 1 and 2 both pass the gate — neither
oracle alone kills all four, so neither is a rubber stamp.

Checks

• nix develop -c forge config: warning before, silent after; the 209-line
  config body is otherwise identical.
• nix develop -c forge test: 353 passed / 0 failed / 34 suites.
• nix develop -c forge fmt --check: exit 0. taplo (pre-commit) passes on the
  new TOML.

Not done here

• The README's ## Publish section is fiction on main — it names a
  .github/workflows/publish-soldeer.yaml that does not exist and describes
  tag-triggered publishing, while the repo publishes from main via autopublish.
  That is already filed as
  [A36] [MEDIUM] The README's release section is fiction, and the semantics of [package].version are undocumented #98, which also covers
  documenting the version semantics; whoever takes it should write
  [external.package].version.
• rainix's own text still says [package].version — the soldeer-package input
  description in rainix-autopublish.yaml and soldeer-gate's failure messages
  (visible in mutants 3 and 4 above). Behaviourally correct, since the reader is
  a line scan with no section awareness; it is a rainix change, not this repo's.

QA

• Discriminating tests: n/a — no Solidity behaviour changes, so there is no
  test/src/** mirror position this belongs in (the tree mirrors src/** by
  subject and release metadata has no src/ counterpart), and a test asserting
  a config file's prose is the kind of doc-binding test that is not written
  here. The discriminating check is a command, run both ways: nix develop -c forge config prints Warning: Found unknown config section in foundry.toml: [package] on origin/main (7620643) and prints no warning on this branch.
• Mutations applied: the four in the table above — section header →
  [package] and → [profile.package], both killed by forge config; version
  line indented and version value lowered below the published revision, both
  killed by rainix-static soldeer-gate at the pinned rainix SHA 53e96a7d.
  Every mutant was run against a recorded unmutated baseline (0 warnings, gate
  exit 0), and each oracle passes two of the four mutants, so neither is
  vacuously green.
• Oracle: not the warning text — the tools that actually consume the section.
  foundry's treatment of [external.*] (feat: support external sections in foundry.toml foundry-rs/foundry#5866, #12723) is
  measured through forge config at the nix-pinned toolchain;
  rainix-static/src/soldeer_gate.rs (read_local_version / is_version_line)
  and rainix-autopublish.yaml's bump sed at the SHA that workflow pins are
  what autopublish reads and writes, exercised directly rather than reasoned
  about.
• Category check: the issue asks for one change — rename [package] to
  [external.package], keep the version line unindented and first, add a
  comment naming the section as another tool's metadata, and fix any prose that
  names [package].version. All four covered; the prose clause is vacuous here
  because no file in the repo names it (grep evidence above). The issue's
  explicit non-goals — running forge config --fix, raising anything upstream —
  are not done, and mutant 2 reproduces in this repo the measurement the issue
  gives for why --fix is worse.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 10 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: 23e20543-8bad-48a8-8a73-6b1daaff797d

📥 Commits

Reviewing files that changed from the base of the PR and between 7620643 and bc13327.

📒 Files selected for processing (1)

• foundry.toml

---

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