rig/changelog.d/112.md

### Fixed

- rig's six ceremony CI guards resolve on Forgejo — bare names 404'd through `DEFAULT_ACTIONS_URL`; the two reusable callers stay bare (#112)
fix: rig's ceremony CI guards resolve on Forgejo The six ceremony actions in ci.yml are step `uses:` references, and a bare step reference resolves through FORGEJO__actions__DEFAULT_ACTIONS_URL — which this forge points at code.forgejo.org, where heavy-duty/ceremony does not exist. Measured with a registered runner on the instance: `git clone https://code.forgejo.org/heavy-duty/ceremony` -> 404, so every guard fails the moment rig's own CI runs on the forge. Those six become absolute. The two reusable-workflow callers do NOT move, and this is the correction to the original "make all eight absolute" ruling. A reusable `uses:` never consults DEFAULT_ACTIONS_URL; it resolves against the runner's own instance, so both callers already fetch ceremony from this forge and expand. Absolutising release.yml's would actively break CI: ceremony's docs-sync reads rig's pin out of that one line with a grep anchored to the bare spelling, so the prefix makes the pin invisible and docs-sync exits 1 with "no pin line ... found none". actions/checkout@v4 stays bare in all three places — the mirror serves it, and that is exactly what DEFAULT_ACTIONS_URL is for. The pin stays @0.3.0 throughout; no .ceremony/ edit, no pin bump. test/cli.sh pins all three shapes, including the docs-sync grep verbatim, so ceremony's parser and rig's caller cannot drift apart silently. Refs #112 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-07-29 12:10:38 +00:00			`### Fixed`

			- rig's six ceremony CI guards resolve on Forgejo — bare names 404'd through `DEFAULT_ACTIONS_URL`; the two reusable callers stay bare (#112)