Review gate blocks every Release Please PR: regeneration force-pushes, which fails the continuity check

[lamemustafa]

Found while trying to merge #337. This blocks all releases, not just v0.6.0.

Symptom

Review gate (scheduled) is a required context and sits at action_required, so #337 is permanently BLOCKED with every other check green and zero unresolved threads.

From the reconcile run log:

Review gate GitHub did not record the prior head, so review continuity cannot be
verified across that rewrite. Re-create the branch as described in #299 before
running the review gate: untraceable force-push discontinuity cannot be verified

Review gate (scheduled) action_required check created for d91447b...

Cause

Release Please updates its release PR by force-pushing the branch, which is normal operation for it. Verified:

$ git merge-base --is-ancestor abdd12b d91447b    # previous #337 head
  -> not an ancestor; the branch was rewritten

scripts/publish-review-gate-check.mjs treats an untraceable rewrite as unverifiable and fails closed — untraceableRewriteError(), the behaviour settled in #318 (4527569, 2026-09-07).

That behaviour is correct for a human branch, where a force-push could replace reviewed code without a trace. It is wrong for a release branch that a bot regenerates from master on every upstream merge.

Timeline supports this reading: v0.5.1 released 2026-08-17; #318 landed 2026-09-07; v0.6.0 is the first release attempt since, and it cannot merge. The discontinuity here was created when #341 merged and Release Please regenerated the branch — before any hand edit — so it is not a consequence of editing the branch.

Why this recurs

Every merge to master regenerates the release PR, so the release branch is rewritten repeatedly by design. Under the current gate, a release PR becomes unmergeable as soon as anything else lands.

Options, none taken

1. Exempt the release-please branch from the continuity check. The branch is bot-generated and its diff is mechanically derived from master, so there is no prior reviewed state a rewrite could smuggle past — the property the check exists to protect. Narrowest change, but it weakens a security-relevant gate and needs a deliberate decision.
2. Treat a rewrite as traceable when the new head contains the base branch tip and the diff is regenerable. More precise, more code, and it is the kind of "verify the grammar you do not own" work that has cost this repo repeatedly (Page-reference checking needs a parser, not another special case #197, chore(deps): keep @types/node on the runtime's major #331).
3. Re-create the branch per docs(gst): record filing-profile discovery hold #299 before each merge. Works once; the next regeneration reproduces the block.

Related complication

Correcting generated release notes requires hand commits on the release branch (#337 carries two, for a reverted entry and for source-only full-year flows). Those are lost on the next regeneration. Whatever fix is chosen should say where release-note corrections are supposed to live, because right now the only place they can exist is a branch that is rewritten without warning.

Not fixing this unilaterally: it changes a gate whose fail-closed posture was chosen deliberately in #318 after seven review rounds.

[lamemustafa]

Attempt 1 withdrawn (#343) — what it established

Option 1 from the original write-up ("exempt the release-please branch") was implemented and withdrawn on review. Recording the outcome so the next attempt does not restart from the same premise.

The exemption argument does not hold. It rested on: a bot-regenerated branch has no reviewed history for a rewrite to smuggle past. That is false. The durable review state is the reviewed history, and it is independent of whether the branch content is regenerable. If the scheduled check recorded an open finding against a prior head and that comment is later deleted, a null before_commit_id leaves the old state unreachable — the gate seeds empty and publishes success, dropping the ask. Regeneration proves nothing about whether a prior finding was fixed, stale, or dispositioned.

So option 1 should be struck from the list. It is not a narrow fix with a stated trade-off; it silently converts a fail-closed gate into one that can report success while losing a finding.

A separate defect worth keeping, if any actor-based check is ever written: pr.user.type is the pull request's creator, not the actor of a later force-push. Anyone with push access can rewrite a bot-created PR's generated-named branch. The head_ref_force_pushed timeline event does carry actor.login / actor.type — verified on #337, where both untraceable rewrites show github-actions[bot]. Authenticate the rewrite, never the PR author.

Where that leaves the options

• 1. Exempt the release-please branch. Struck — see above.
• 2. Give generated PRs a continuity mechanism. Now the only sound direction. Durable state would need to survive a rewrite — keying it to the pull request rather than the head looks plausible, since the state already carries prNumber. This is close to the continuity-override protocol fix(review-gate): recover untraceable force-pushes #318 descoped after seven rounds, so it deserves a deliberate design rather than an incremental patch.
• 3. Re-create the branch per docs(gst): record filing-profile discovery hold #299 before each merge. Still works once; the next regeneration reproduces the block.

Current cost

Release pull requests cannot merge. #337 (v0.6.0) is blocked on this with every other check green, a clean Codex review at its head, and all review threads resolved. The last release was v0.5.1 on 2026-08-17.

Related: correcting generated release notes still has nowhere to live — #337 carries two such commits and both were destroyed by a regeneration triggered by an unrelated dependency merge, which is demonstrated in that PR's history rather than hypothetical.

[lamemustafa]

Investigation: the rewrites are traceable after all

Two findings from reading the mechanism rather than the symptom. Both change what a fix should look like, and neither was visible when option 1 was proposed.

1. head_ref_force_pushed carries commit_id even when before_commit_id is null

Every force-push on #337:

before: null   commit_id: abdd12b…   actor: github-actions[bot]   2026-09-08T19:09:23Z
before: null   commit_id: f59d877…   actor: github-actions[bot]   2026-09-08T21:04:37Z
before: null   commit_id: 79161c9…   actor: github-actions[bot]   2026-09-09T06:54:56Z

commit_id is the head after each push — confirmed by ordering: the reviewed event immediately following the first force-push is at abdd12b, and committed/referenced events bracket the others consistently.

So the sequence of heads is recoverable: abdd12b → f59d877 → 79161c9 → dfeb9d1. loadForcePushedPriorShas reads only before_commit_id, sets hasUntraceableRewrite, and discards the event — including the SHA sitting in the same object.

This matters because the discontinuity is not actually untraceable. The check runs carrying durable state are addressable by SHA, and those SHAs are in the timeline. Widening discovery to include commit_id from force-push events (and reviewed event SHAs) would let the existing walk find state that is currently unreachable.

Crucially this preserves the fail-closed posture rather than bypassing it: it recovers the chain instead of declaring the gap acceptable. It also directly answers the objection that sank #343 — a finding published on an orphaned head is found again rather than lost, because the orphaned head is discoverable.

2. The lock is self-perpetuating, and #337 has no state to protect

Review gate (scheduled) on every head of #337 — a16d8836, abdd12b, f59d877, 79161c9, dfeb9d1 — has output.text: null. No durable state has ever been published for this pull request.

That follows from #318's design: on detecting an untraceable rewrite the gate publishes the terminal error without state. A generated pull request is force-pushed on its first regeneration, so it hits the error before it ever publishes state, and can never publish state afterwards. The gate is failing closed to protect state that does not exist, and its own failure is what prevents the state existing.

That is not an argument for bypassing — the gate cannot know the state is empty without looking, and looking is exactly what it refuses to do. It is an argument that the fix belongs in discovery, not in exemption.

Proposed direction

Extend loadForcePushedPriorShas so a null before_commit_id falls back to the event's own commit_id, treating the recovered SHAs as additional prior heads for the existing walk. Keep hasUntraceableRewrite for the case where neither field is usable, so genuinely untraceable rewrites still fail closed.

What must be verified before implementing

I am proposing this rather than writing it, because two designs of mine on this gate have already been withdrawn.

1. Is commit_id reliably the post-push head? Three samples on one pull request is thin, and the field is generic across timeline event types. Needs confirmation against another force-pushed PR, ideally a human one — this repository has no recent example.
2. Does the walk actually find state once given the SHA? Unprovable on chore(master): release 0.6.0 #337, which has no state anywhere. Needs a PR that published state and was then force-pushed.
3. Does recovering prior heads reintroduce anything fix(review-gate): recover untraceable force-pushes #318 closed? That PR spent seven rounds on this code and settled on failing closed deliberately; the recovered-SHA path must not become a way to seed state across a rewrite the gate cannot actually verify.

Point 2 is the one that decides it. If the walk cannot find state even when handed the orphaned SHA, this direction is wrong and the answer really is a storage redesign.