docs(planning): capture the release-PR changelog deadlock (RELTRUTH-01) - #87
Merged
Merged
Conversation
The root release PR (#57, 0.2.0 -> 0.2.1) has 9 failing checks and cannot be made green from inside itself. `release_boundaries_test.exs:128` derives "current version" from mix.exs via `Application.spec(:crosswake, :vsn)`. Inside a release PR that version is already bumped, so the PREVIOUS version is treated as stale and CHANGELOG.md:20-22,36 get flagged `[stale_latest_hex]` — even though those lines are true. 0.2.0 genuinely is the published release; 0.2.1 is not out yet. And because the root package sets `skip-changelog: true`, release-please never writes CHANGELOG.md in its own release PR, so nothing inside the PR can clear the flag. Root cause: the gate conflates "version in mix.exs" with "latest published Hex release". Those are deliberately different during a release PR. Captured rather than fixed in this pass, deliberately: * The fix changes the semantics of a merge-blocking release-honesty gate — the same class of gate that just caught the rulestead/rindle publish overclaim. Weakening it wrongly would let real overclaims through. * The principled fix follows precedent already in the repo — check_release_as_ staleness.sh establishes that the git tag, not the local manifest, is the authoritative already-released signal — but proof workflows check out without `fetch-tags`, so it needs a CI checkout change across many workflows too. * #57 additionally needs version-bump fixture regeneration (release-status mirror ref, phase52_publish_readiness.json, native_evidence_drift, doctor_threadline, phase43), which only makes sense alongside a real decision to publish 0.2.1 — an irreversible Hex + Maven Central + SwiftPM mirror push. #57 is not blocking anything today: main is green and the PR simply sits open. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
szTheory
enabled auto-merge
July 28, 2026 17:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The finding
Root release PR #57 (
0.2.0→0.2.1) has 9 failing checks and — for one of them — cannot be made green from inside itself.test/crosswake/guides/release_boundaries_test.exs:128derives "current version" frommix.exs:Inside a release PR that version is already bumped, so the previous version is treated as stale and
CHANGELOG.md:20-22,36get flagged[stale_latest_hex]:But those lines are true.
0.2.0genuinely is the published release;0.2.1isn't out. And the root package sets"skip-changelog": true, so release-please never writesCHANGELOG.mdin its own release PR — nothing inside the PR can clear the flag.Root cause: the gate conflates "version in
mix.exs" with "latest published Hex release." Those are deliberately different during a release PR.Why captured, not fixed
script/check_release_as_staleness.sh— the git tag, not the local manifest, is the authoritative already-released signal. Applying that here is correct, but proof workflows check out withoutfetch-tags, so it needs checkout changes across many workflows.release-statusmirror ref,phase52_publish_readiness.json,native_evidence_drift,doctor_threadline,phase43) only makes sense alongside a real decision to publish0.2.1— an irreversible Hex + Maven Central + SwiftPM mirror push you deliberately deferred this pass.Impact today
None.
mainis green; #57 simply sits open as a standing publish gate, exactly asdocs/MILESTONE-BOUNDARY-HYGIENE.md§4 prescribes. This lands the diagnosis so the next person doesn't re-derive it.🤖 Generated with Claude Code