#Combined PR qualification

integration/current is the shared candidate for testing the PRs selected in integration/prs.json. A full refresh starts from the current main, merges the integration tooling, then merges the selected PR heads in dependency order. The original PRs retain their bases and reviews. The selected batch excludes archived branches and unrelated drafts. Explicitly authorised drafts are listed in draft_exceptions, each with its relevance to issue #1123 or acceptance PR #1132. A selected PR becoming a draft needs either removal or an authorised exception before rebuilding.

Run the helper from a dedicated clean worktree. It requires Git, Python 3, an authenticated gh and an origin pointing at this repository. The helper creates a new integration/build-* branch in that worktree. Preserve any active build before starting another.

python3 scripts/pr_integration.py status
python3 scripts/pr_integration.py refresh

For additions and descendant-only source changes against the same main, use python3 scripts/pr_integration.py update. It starts from the published candidate, retains its supplemental MCP source and recorded qualification corrections, and merges new or advanced PR heads in dependency order. Updated pinned patches apply only their new source delta. The command refuses rewritten sources, removed PRs, a changed main, changed patch bases or replacement rules; these require refresh. Publication still uses publish, an immutable snapshot and a lease. Every updated candidate starts with qualification pending.

Same-repository open PRs use their actual Git branch heads. When GitHub's PR metadata lags behind the branch, the manifest preserves the reported older SHA separately. Fetching and publication recheck the actual source.

status compares the committed manifest with the selected PR heads, their bases and states, the latest main and the tooling branch. A changed source reports STALE and exits 1. New PRs require an explicit addition to the selection. Update the selection and helper on chore/pr-integration-tools, push that branch, then refresh. Builds include its exact commit.

A source update, rebase or selection change requires a new candidate. A full refresh after a rebase or removal avoids retaining removed commits or a dropped PR from an earlier candidate. A closed, unmerged PR requires removal from the selection. A merged PR's source remains in the manifest; Git recognises commits already present in the base.

When a category aggregate supersedes a stacked PR's base, base_replacements maps that base branch name to the selected aggregate PR number. The builder requires the aggregate to contain the base's current commit and merges it before the dependent PR. The manifest records the replacement and exact base commit; changes to either make the candidate stale.

For a PR based on a deployed integration snapshot, patch_bases pins its base branch to an exact commit. The builder verifies that the pinned commit is an ancestor of the PR head, then applies the base-to-head patch with three-way conflict handling. This preserves the PR's own changes without importing the older snapshot's complete selection. The manifest records the original head, base, patch hash and resulting commit. Resolve a patch conflict by staging the complete resolution and running continue; let the helper commit it. A changed source base requires an explicit selection update. The moving integration target may be rebuilt independently; its latest SHA does not replace the original source base.

Use pr_patch_bases to pin an individual PR when several PRs share a moving target but started from different snapshots. Its PR-number keys override patch_bases for those PRs. A stacked follow-up to a patched PR can likewise pin its parent's source head, applying only the follow-up. update accepts pins for new selections; changing an existing PR's effective pin requires refresh.

#Conflicts

The build stops at the first unresolved merge. The shared integration branch still points at its previous complete build. Resolve the files in the candidate worktree, stage the resolution and continue:

git add <resolved-paths>
python3 scripts/pr_integration.py continue

The helper records resolutions in Git's local rerere cache and reuses matching resolutions during later builds. A fresh clone may need those conflicts resolved again. Every rebuilt candidate still needs qualification. Keep feature corrections in their owning PR; record combination-specific resolutions in the merge commit.

Local progress is stored in ignored .local/pr-integration/build.json. Retain this file and the candidate branch when investigating a failure. continue checks the pending PR identity and refuses unrelated, aborted or incompletely staged merges.

#Publishing and checking

python3 scripts/pr_integration.py publish

Publication first checks that the sources still match the manifest. It atomically pushes an immutable integration/snapshots/<build-id> branch and replaces only integration/current, using a lease to reject a competing update. It then dispatches ci.yml against the immutable snapshot. If workflow dispatch fails after publication, retry it explicitly against that snapshot:

gh workflow run ci.yml --ref integration/snapshots/<build-id>

The manual workflow runs the full CI suites during the temporary fast-CI period. See the verification policy. The manifest records the base, tooling and PR commits and their merge order. The published snapshot and CI run provide the resulting commit and test outcome. A successful older run remains evidence for that snapshot when a source subsequently changes.

Publishing a candidate does not qualify a live deployment. Deploy the tested snapshot to the selected dev box and run the applicable infrastructure and acceptance journeys, recording the deployed commit separately. Land original PRs individually after review and explicit merge authorisation, then refresh the remaining combination.

Reserve the dev box for the whole delivery and acceptance session, and use an exclusive test account and Project. The delivery lock protects a reconcile; it does not reserve the target while browser and native Run tests continue. Check each Argo Application's desired revision, applied revision, sync and health before and after a suite. Retain deployment history with the results. If another delivery changes the target, preserve the observations and repeat the affected scenarios once the selected snapshot is stable.