chore(pr-gate): avoid repeated latest-dev resync churn on active PRs #4443

Area

Other

What are you trying to accomplish?

Avoid repeated no-op resync churn on active pull requests when dev advances with unrelated commits after a PR has already been validated against a recent base.

The goal is to keep contributors on current development history without requiring them to continuously chase the exact latest dev tip while a PR is waiting for review.

What prevents this today?

The current review-readiness checklist requires contributors to attest:

I pushed my PR to the latest dev commit.

On a fast-moving dev branch, this creates a loop where an otherwise review-ready PR is repeatedly resynced only because unrelated commits landed after its last successful validation.

Each resync changes the PR head, invalidates previous exact-head verification, triggers another CI/review cycle, and can create extra sync/backup branches without materially reducing merge risk.

This is especially noticeable on longer-lived PRs such as #4042 and #4062, where dev may advance again shortly after a successful sync even when the intervening changes do not overlap the PR's feature files.

The PR quality gate already has an ancestry concept with a bounded behind-base threshold, while the checklist wording is stricter and effectively encourages exact-tip synchronization. Those two requirements currently pull contributors in slightly different directions.

What should OpenCodex do?

Treat exact-tip synchronization as a review/merge boundary rather than a continuously maintained condition.

A PR should remain review-ready when it was synced to a recent dev revision, newer dev changes have been checked for relevant overlap, and the existing ancestry/staleness gate is still satisfied.

A maintainer can still request an exact-tip sync when the PR is about to merge, or whenever newer upstream changes overlap the affected files or behavior.

This should not weaken CI, review, target-branch, or ancestry requirements; it should only avoid repeated exact-tip chasing caused by unrelated upstream changes.

Example usage or interface

Current checklist wording:

I pushed my PR to the latest dev commit.

Possible replacement:

I synced this PR to a recent dev revision and reviewed newer dev changes for relevant overlap.

The ancestry gate could continue rejecting materially stale branches. A final exact-tip sync could still be requested at the merge boundary or when overlapping upstream changes appear.

Alternatives or workarounds

• Continuously merge/rebase every new dev tip into the feature branch. This repeatedly invalidates exact-head CI and review evidence even when upstream changes are unrelated.
• Leave the branch behind and wait for a maintainer to ask for a sync. This avoids churn but conflicts with the current checklist wording.
• Keep the current wording but enforce exact-tip synchronization only at a defined review/merge transition. This would also solve the main problem.

Additional context

The issue was originally filed freeform and was automatically closed by the issue-quality workflow. This edit reformats the same proposal using the repository's Feature proposal template.

Related examples: #4042 and #4062 have both experienced repeated dev movement while waiting for review, including validation reruns after otherwise unrelated upstream changes.

The request is specifically about the contribution workflow and does not ask to relax CI or branch freshness checks.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.