Rebase-pushed commits get no CI runs under the default GITHUB_TOKEN — rebased PRs end up with run-less heads

[mmcky]

Found while design-reviewing #124, and pre-existing — it applies to the conflict-rebase force-push path that has shipped since rebase mode existed, not only to the new refresh input.

Empirical evidence

Harness run 29793647876 force-push rebased 13 PRs. Checking one:

PR #617 head: c3f5b3ea (committed 2026-07-21T01:39:27Z, by the rebase run)
check runs on that SHA: 0

Zero check runs on the new head. Commits pushed with the default GITHUB_TOKEN do not trigger workflows — GitHub's recursion guard — so every rebased PR's synchronize event fired into the void. The distributed rebase-translations.yml template passes secrets.GITHUB_TOKEN, and so do all five production target repos.

Why this is worse than it sounds

A rebased PR does not merely miss a CI refresh — it goes from stale-but-green to a head with no runs at all. With required status checks, that blocks merging until someone manually re-triggers. And the review workflow also does not re-run, so the force-pushed content (which conflict rebasing regenerates through the sync pipeline!) lands on the PR unreviewed. The re-translated content on those 13 harness PRs was never looked at by the review workflow.

Contrast with sync mode, which passes QUANTECON_SERVICES_PAT precisely so its PRs trigger the review workflow — the rebase template never adopted the same reasoning.

Options

1. Template change: rebase-translations.yml passes the machine-user PAT (or a GitHub App token) as github-token, mirroring the sync workflows. One-line change per repo; the org secret already exists. Recommended.
2. Action-side warning: rebase mode logs a prominent warning when it detects it pushed with a token that cannot trigger workflows (not directly detectable — it can at best note the caveat unconditionally).
3. Documentation only — #124 already adds the caveat to the action reference and the template comment. That is the floor, not the fix.

Note option 1 has a real trade-off to weigh: the machine-user PAT grants broader rights to the rebase workflow than GITHUB_TOKEN does, and rebase runs on pull_request: closed events in target repos. Worth a deliberate decision rather than a reflex adoption.

Relationship to #123 / #124

#124's rebase-stale-siblings refresh has the same property (its whole purpose is re-running checks, so under GITHUB_TOKEN it is a no-op with extra commits). The docs/template caveat shipped there; this issue tracks the actual token decision and the estate rollout, since the same choice governs both paths.

[mmcky]

Both halves of the token claim are now validated empirically on the harness, same repo, same day:

Token	Rebase pushes	Workflow runs on the new heads
GITHUB_TOKEN (run 29793647876)	13 force-push rebases, all succeeded	0 — every head run-less
QUANTECON_SERVICES_PAT (run 29799241099)	1 refresh via update-branch	1 — Review Translations triggered on the pull_request event

Two operational facts for the production rollout, both learned the useful way:

1. The org secret's repository visibility is a rollout step, not a given. The first validation attempt failed with Input required and not supplied: github-token because QUANTECON_SERVICES_PAT was not visible to test-translation-sync.zh-cn — the secret exists org-wide but is scoped to selected repos. Visibility has now been granted to both harness targets; the five production edition repos (.fr, .fa, programming.zh-cn, intro.zh-cn, python.zh-cn) will each need the same grant before their rebase workflows can switch. A missing grant fails loudly, not silently, which derisks the rollout.

2. Public repos do not change the exposure analysis. Secrets are withheld from pull_request workflows triggered from forks regardless of repo visibility, so a fork branch named resync/x merged by a maintainer still runs the workflow with no secrets. The residual risk is supply-chain only (a compromised action in a trusted-branch run).

The harness rebase workflow now carries the PAT in steady state as the model configuration. Remaining scope for this issue: the org-secret grants + one-line workflow edits across the five production repos, once the maintainer signs off on option 1.

[mmcky]

2026-07-21 — option 1 executed and verified. Closing.

The rollout

Step	Who	Status
Org-secret grants: QUANTECON_SERVICES_PAT → harness targets	maintainer	✅ (validated the same day by the #124 harness run)
Org-secret grants → five production edition repos	maintainer	✅
Token switch in each rebase workflow	PRs .fr#17, .fa#139, programming.zh-cn#74, intro.zh-cn#273, python.zh-cn#187	✅ all merged; verified on origin/main of all five

Each workflow carries the rationale inline (with the validation date and a pointer here), so the why survives in the file — the estate's rebase workflows now match the harness steady-state configuration that validated the approach.

What this closes

Rebase-pushed commits (both conflict force-pushes and v0.19.0's refresh path) now trigger CI and review on the branches they touch. Before this, force-pushed re-translated content merged unreviewed and refreshed heads sat run-less — the empirical A/B is in this issue's history: 13 GITHUB_TOKEN heads with zero runs vs the PAT head triggering normally.

Rode along

• Copilot's review of the wave produced one accepted hardening — the rebase job now requires a same-repo head branch (template: #130, merged; harness: direct; estate: python.zh-cn in Reviewer grades out-of-diff prose on code/metadata-only sync PRs, forcing false editor routing #187, four follow-up PRs in flight) — plus three pushed-back suggestions (date removal, preflight secret check, SHA-pinning), each answered with reasoning in-thread.
• The two rebase copies that predated docs: the CLI command is 'translate forward --github' #127 picked up the translate forward --github wording fix, closing that loose end.

Residual, accepted

The PAT is a classic machine-user credential; a fine-grained PAT or GitHub App token scoped to contents + pull-requests on the edition repos would bound the blast radius further. Worth doing if the org ever standardises on fine-grained credentials — not tracked here.