feat(upstream): hold fork pull requests while an intake candidate lands

[incognitojam]

Note

While an intake branch runs Fork CI or waits for promotion, open pull requests into main get a pending Intake landing hold status. Once it is a required check, they cannot move main under the candidate, and auto-merge lands them when the hold lifts. Nobody sets or releases it; each run works it out from workflow runs.

Problem

An intake candidate lands by fast-forwarding main to the exact SHA Fork CI tested. Any fork pull request that merges while the candidate runs Fork CI or waits for approval makes promotion fail, and the branch has to be rebased, tested and promoted again. #926 removed the manual dispatch, but not this race. The runbook's answer was a manual landing hold: find the agent threads with open PRs, ask the maintainer, message each thread, then message them all again after promotion. It did not cover PRs the maintainer merges, threads started later, or work outside styal.

Change

A new Intake landing hold workflow runs scripts/upstream/landing-hold.ts, which sets the Intake landing hold commit status on every open pull request into main:

• Pending, "Waiting for intake/… to land" with a link to the run, while any intake branch has a Fork CI push run in progress, a promotion run that has not finished (including one waiting for approval), or a Fork CI run that passed in the last 15 minutes whose promotion run has not appeared yet.
• Success otherwise. The hold lifts when Fork CI fails or the promotion run ends, however it ends. To lift it for a candidate that will not land, cancel its Fork CI run or reject its promotion.

The candidate commit itself gets a success status, so promotion's push still satisfies main's required checks.

The workflow runs on pull request updates, when Fork CI starts or finishes on an intake branch, when a promotion starts or finishes, and on dispatch. Every run recomputes the hold from workflow runs, and all runs share one queue, so a missed event is corrected by the next one and there is no hold to forget. It reads current statuses in one GraphQL query and writes only the ones that changed. Its pull_request_target job checks out main's script and never pull request code.

The runbook's manual landing-hold coordination is replaced by a description of the hold.

Pushes that do not go through a pull request, such as the nightly mobile version bump and Mobile EAS Production, are not held.

Rollout

After merge:

1. Dispatch Intake landing hold once, so every open pull request has the status.
2. Add Intake landing hold (source: GitHub Actions) to the Required CI ruleset. Until then the status is informational.

Verification

• landing-hold.test.ts covers the decision: Fork CI in progress on an intake push holds; Fork CI on pull requests and main does not; a promotion waiting for approval holds; the gap between Fork CI passing and its promotion run appearing holds; a finished promotion releases whether it succeeded, failed or was cancelled; failed Fork CI and old passed runs without a promotion release. All 142 scripts/upstream tests pass and the scripts package typechecks.
• landing-hold.ts --dry-run against this repository read the real Fork CI and promotion runs and open pull requests, found no candidate landing (correct at the time), and listed the 15 open pull requests it would mark success, with their current status read through GraphQL.
• Not verified before merge: workflow_run and pull_request_target run only from main's workflow file, so the first real run is the post-merge dispatch, and the first hold is the next intake push.

---

Written by an agent (Claude Code, claude-opus-5-5).

[github-actions]

Upstream divergence

Both sides are compared with upstream at the in-order tip 0ecb25a8d4. Excludes .repos/ and pnpm-lock.yaml.

Measure	Base	This PR	Change
Upstream files the fork changes	1,505	1,505	0
Lines changed in them	78,248	78,248	0
Upstream files the fork removes	42	42	0
Fork-only files	549	552	+3
Fork-only lines	100,759	101,179	+420

No upstream file changes how much it differs from upstream.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	4.9 KiB	5.0 KiB	+23 B (+0.5%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	+23 B (+1.9%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.8 KiB	20.9 KiB	+41 B (+0.2%)	29.3 KiB	✅
Codex	Live turn messages	1	2	+1 (+100.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 503b919 · PR result: 418460b · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.