Before a fork's pull merges, its preview runs the combined build, and conflicts are resolved in a branch on our side with the decisions written for the author #9027

When main has moved past a kept fork's head (a fork a person owns, opened by a person), the forge now merges main into that head on a branch in the base repository, combined/N. The author's branch is never written. The preview builds that branch, the pull page explains it in a note for the author, and merging lands it, so the author's head stays an ancestor of main.

• src/git/combined.ts (new): combine runs merge-tree of main against the head. When there are conflicts it reruns with -X ours, so every conflicting block keeps main's side. It then writes a merge commit (parents: head, main) to refs/heads/combined/N. The commit message is the note: each conflicted file, how many blocks it had, and whether main's side was kept or the file is left open (for example a modify/delete conflict). Commits a writer pushes on top of combined/N survive the next combining, as long as the branch still carries the head. If main is already in the head, the branch just points at the head and no commit is written.
• When it runs: when the pull is opened (core/pulls.ts createPull), on every push to the fork (core/following.ts refreshPullHead), and again just before landing. Sealed pulls and crew pulls are left out; it only applies to fromKeptFork pulls.
• Mergeability and landing: pullStatus judges whether a cross-repo pull can merge using its combined tip, so a conflicting fork pull with a combined branch reads as mergeable. landPull merges the combined commit. A clean merge gives the same tree as before, so the merge queue's expected tree still matches.
• Preview: previewHead/previewCommit pick the combined tip in both apps/runtime.ts and actions/apps.ts. The runtime maps a combined commit back to the head it carries, so the preview runs under that head's approval.
• Pull page: a "Combined with main" card (web/pages/pull-combined.ts) appears on the studio pull page and the files page. It names combined/N, its commit, and the note. It is hidden when the combined tip is the head itself.
• Test: test/combined-fork.test.ts opens a conflicting fork pull and checks:

- the branch exists, with parents head then main, and main's side kept; - the note says "one.txt: 1 block, main's side kept"; - the author's branch is untouched; - the preview commit is the combined tip, and the page shows the note; - the merge lands with the author's head as an ancestor of main.

docs/features/upstream-landing.md describes the new branch.

What to look at:

• No crew run yet: no agent run is started to improve on main's side; the conflict sweep still skips person-authored pulls. The automatic resolution is main's side, written down for the author. Anything finer has to be pushed onto combined/N by a writer, since agents cannot push to the base repository.
• Check runs on the head: the pull's check still runs on the head, not on the combined commit.
• Main moving alone doesn't recombine: a push to main with no fork push and no landing attempt does not rebuild combined/N, so the preview stays at the last combining.

Before pushing I ran bun x tsc --noEmit, bun scripts/gate.ts, bun scripts/design-lint.ts, and the covering test files (fork, cross-repo, landing, merge, following, preview approval, pull page and timing). All pass. scripts/fast.ts named 1671 files, so I chose those test files myself.

Try: on a preview, open a pull from a kept fork whose head conflicts with main. The pull shows the "Combined with main" card listing each conflicted file, and the deployed preview commit is the tip of combined/N.

🤖 Generated with Claude Code

Closes #9012

When main has moved past a kept fork's head (a fork a person owns, opened by a person), the forge now merges main into that head on a branch in the base repository, combined/N. The author's branch is never written. The preview builds that branch, the pull page explains it in a note for the author, and merging lands it, so the author's head stays an ancestor of main.

• src/git/combined.ts (new): combine runs merge-tree of main against the head. When there are conflicts it reruns with -X ours, so every conflicting block keeps main's side. It then writes a merge commit (parents: head, main) to refs/heads/combined/N. The commit message is the note: each conflicted file, how many blocks it had, and whether main's side was kept or the file is left open (for example a modify/delete conflict). Commits a writer pushes on top of combined/N survive the next combining, as long as the branch still carries the head. If main is already in the head, the branch just points at the head and no commit is written.
• When it runs: when the pull is opened (core/pulls.ts createPull), on every push to the fork (core/following.ts refreshPullHead), and again just before landing. Sealed pulls and crew pulls are left out; it only applies to fromKeptFork pulls.
• Mergeability and landing: pullStatus judges whether a cross-repo pull can merge using its combined tip, so a conflicting fork pull with a combined branch reads as mergeable. landPull merges the combined commit. A clean merge gives the same tree as before, so the merge queue's expected tree still matches.
• Preview: previewHead/previewCommit pick the combined tip in both apps/runtime.ts and actions/apps.ts. The runtime maps a combined commit back to the head it carries, so the preview runs under that head's approval.
• Pull page: a "Combined with main" card (web/pages/pull-combined.ts) appears on the studio pull page and the files page. It names combined/N, its commit, and the note. It is hidden when the combined tip is the head itself.
• Test: test/combined-fork.test.ts opens a conflicting fork pull and checks:

- the branch exists, with parents head then main, and main's side kept; - the note says "one.txt: 1 block, main's side kept"; - the author's branch is untouched; - the preview commit is the combined tip, and the page shows the note; - the merge lands with the author's head as an ancestor of main.

docs/features/upstream-landing.md describes the new branch.

What to look at:

• No crew run yet: no agent run is started to improve on main's side; the conflict sweep still skips person-authored pulls. The automatic resolution is main's side, written down for the author. Anything finer has to be pushed onto combined/N by a writer, since agents cannot push to the base repository.
• Check runs on the head: the pull's check still runs on the head, not on the combined commit.
• Main moving alone doesn't recombine: a push to main with no fork push and no landing attempt does not rebuild combined/N, so the preview stays at the last combining.

Before pushing I ran bun x tsc --noEmit, bun scripts/gate.ts, bun scripts/design-lint.ts, and the covering test files (fork, cross-repo, landing, merge, following, preview approval, pull page and timing). All pass. scripts/fast.ts named 1671 files, so I chose those test files myself.

Try: on a preview, open a pull from a kept fork whose head conflicts with main. The pull shows the "Combined with main" card listing each conflicted file, and the deployed preview commit is the tip of combined/N.

🤖 Generated with Claude Code

A fork's pull now shows its combined/N branch the same way on the page and on the terminal's pull screen. Both render one view, src/core/combined_view.ts, built from facts stored as data in the combined commit, not from the note's wording. The gate, tsc, design-lint and 11 covering test files (91 tests) pass locally. scripts/fast.ts named 1672 files, so I picked the ones that cover this change.

Each review point:

1. Both doors: the terminal pull screen (src/tui/screens/pull.ts) has a "Combined with main" section. It uses the same gate as the page: a fork's pull that is open, not merged, and whose combined tip is not the head itself. test/combined-fork.test.ts checks it.
2. Stale preview: the card marks itself stale instead of recombining. Recombining when main moves would add work on every main push, which goes against point 7. The combined commit records the main commit it was built on (a Combined-Base trailer). When main has moved past it, the page and terminal say "stale", name that commit, and say that merging recombines before it lands.
3. Checks: the check still runs on the head. The card says so: "Checks run on the pull's head, not on this combined commit." Running the check on the combined commit is listed under "Not yet" in the docs.
4. Wording: each file kept on main's side reads "your side was dropped from the landed tree". The note then says how to get it back: merge main into your branch, resolve, push. A head that already has main is its own combined build.
5. Tests:

- A push to the fork recombines: the fork's new head becomes combined/N's first parent. - Stale is shown on both the page and the terminal. - Landing carries the newer main. - test/combined-git.test.ts covers a writer's commit on combined/N surviving a recombine, a modify/delete conflict left open, and headUnder.

1. Housekeeping:

- readCombined returns the kept files as data, read back from Combined-Kept trailers. - The combinedHeads map is gone. The approval check calls headUnder, which reads git directly: the commit runs under pull.headOid only when it is the tip of combined/N and still carries that head. - I did not walk first parents as suggested, because a writer's commit on top of combined/N breaks that chain. - mayRun is synchronous and sits under requestDeploy, so headUnder uses Bun.spawnSync. It only runs for a fork pull whose commit is not its head. - Imports sit with their neighbours. muted small is named in docs/design/areas/text.md and mb in docs/design/areas/layout.md; design-lint is clean.

1. Load: a branch pull's path is unchanged. One git merge-tree runs only when a kept fork's pull opens, and pullStatus adds one ref read plus a merge-base for fork pulls. I kept the combine at open so the first preview already builds the combined tree.

Not done: recombining when main alone moves, a check on the combined commit, and a crew run that improves on main's side. They are listed under "Not yet" in docs/features/upstream-landing.md.

To try it: open a pull from a fork whose change conflicts with main, then look at the pull page and at the terminal's pull screen. Push to main and both show "stale".

🤖 Generated with Claude Code

When a fork's pull is kept, it is now combined with main on our side in combined/N. The preview builds that combined commit, the pull shows what was kept, and landing merges it.

• Combined preview: it runs under its head's approval. If the head already contains main, the head is its own combined build.
• On the pull: it shows both ways in, and says when the combined commit is stale or hasn't passed its check yet. The kept facts are stored as commit trailers.
• Where to look: start with src/git/combined.ts. previewCommit picks what the preview builds, and the function above it gives a combined tip whose head is already ancestry-checked back to that head.

The last commit fixes the red check. "every spawn that pipes is listed with the reason it reads the pipe" failed because the new Bun.spawnSync in src/git/combined.ts keeps stdout piped. It does read that output: spawnSync buffers the rev-parse result, and stderr is ignored. So the code is right, and the fix is a new entry for the file in the list in test/spawn-pipes.test.ts.

To check it: bun test test/spawn-pipes.test.ts, bun scripts/gate.ts and bun x tsc --noEmit all pass locally; the full suite was not run here and runs on push. To try it, open a fork's pull, keep it, and check that its preview at https://lab--9027--forge-trevato-apps.open-platform.sh builds the combined/N commit.

🤖 Generated with Claude Code