Bump version to 0.1.3: 0.1.2 published, bump push-back rejected again

[thedavidmeister]

Same repair as #55, one publish later: the run for the #47 merge successfully published 0.1.2 to Soldeer (registry timestamp 2026-08-19T13:35:45Z, verified via api.soldeer.xyz), then had its post-publish bump commit rejected by branch protection (GH006). Main and registry both say 0.1.2, so the next content-changing merge would gate-fail. This is the byte-equivalent of the push the workflow attempted: [external.package].version 0.1.2 → 0.1.3.

This repair recurs after every publish until the branch-protection question is ruled (unprotect main like rain.solmem / keep protection and accept this PR each publish / move the bump to a PR in rainix-autopublish).

QA

• Discriminating tests: n/a - release-metadata-only diff; suite behavior unchanged.
• Mutations applied: n/a - no code changed.
• Oracle: Soldeer registry API (0.1.2 present, uploaded 13:35:45Z) + the failed run's GH006 log + the rainix-autopublish bump semantic (version = next unpublished).
• Category check: restore gate invariant after published-but-unbumped state; covered exactly.

🤖 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: 37 minutes

Limit details: You’ve used the included review currently available.

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 within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 170fea72-b2e5-4ec8-87c5-fffad910abd0

📥 Commits

Reviewing files that changed from the base of the PR and between 01e329a and 2888ccc.

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

[thedavidmeister]

Closing per human ruling (2026-08-19): superseded by rainlanguage/rainix#333 (registry-derived publish version, no push-back). Until that lands, publish runs will gate-fail on local==published by design — no manual bump PRs in the interim.