Policy: code review before publishing, on by default - #47
Merged
Conversation
Every release now gets a code review of everything that landed since
the last published version, before publishing. Applies to mob,
mob_dev, and mob_new. Skipped only when the user says so.
Scoped at the release, not the PR. What a user pulls from Hex is the
accumulated diff since the last published version, which is rarely the
shape of any one PR that went into it — per-PR review misses what only
shows up at the seam: a fix landing on top of an earlier one and partly
undoing it, two individually-fine PRs interacting badly, and work that
merges after a version bump and so never reaches the release that bump
produced.
That last one is not hypothetical. It just happened twice:
- mob master carried the MOB-102 frame-registry fix merged *after* the
0.7.29 bump, with 0.7.29 already published — so the fix could not be
in any published artifact.
- mob_new merged the entire Android Sheet renderer on top of an
already-published 0.4.23 with no bump at all, leaving published
mob_new generating apps with no Sheet renderer while published mob
0.7.29 shipped Mob.UI.sheet/2.
So the gate also carries two version-sanity checks: confirm the version
you are about to publish is not already published, and confirm nothing
you intend to ship is sitting in commits after the bump. Plus the
cross-repo note that mob and mob_new ship in lockstep for anything
spanning a runtime change and its generator template.
Canonical text lives in mob/RELEASE.md ("Review gate" + a new step 1 in
the step-by-step, remaining steps renumbered); mob_dev and mob_new
reference it from their own CLAUDE.md as they do the rest of the
release flow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Makes code review before publishing the default across
mob,mob_dev, andmob_new.Why release-scoped, not per-PR
What a user pulls from Hex is the accumulated diff since the last published version, which is rarely the shape of any one PR that went into it. Per-PR review misses what only shows up at the seam: a fix landing on top of an earlier one and partly undoing it, two individually-fine PRs interacting badly, and work that merges after a version bump and so never reaches the release that bump produced.
That last one just happened twice:
mobmaster carried the MOB-102 frame-registry fix merged after the 0.7.29 bump, with 0.7.29 already published — the fix cannot be in any published artifact.mob_newmerged the entire Android Sheet renderer on top of an already-published 0.4.23 with no bump at all, leaving publishedmob_newgenerating apps with no Sheet renderer while publishedmob0.7.29 shipsMob.UI.sheet/2.Both are live right now and neither was caught by per-PR review, because each PR was individually fine.
What the gate adds
v<last-published>..HEADbefore publishing. Findings block unless explicitly accepted, and an accepted one gets recorded indecisions/rather than left in a review thread.mobandmob_newship in lockstep for anything spanning a runtime change and its generator template.Skipped only when explicitly requested.
Layout
Canonical text is in
mob/RELEASE.md— a new "Review gate" section plus step 1 of the step-by-step, with the remaining steps renumbered.mob_devandmob_newreference it from their own CLAUDE.md, matching how they already reference the rest of the release flow.Docs only, no code or version changes.
🤖 Generated with Claude Code