A trunk update evaluates standing work instead of erasing it

The gap

Updating trunk today erases whatever was standing on it. An applied patch is gone with the worktree reset and its record is cleared — correctly, because keeping the record would be a lie, but the honesty is the honesty of a demolition notice. A ticket branch behind trunk fares little better: the offered remedy is to save a copy of the work, unlink the ticket, delete the branch, and start again. In both cases the app knows that trunk moved but never finds out what that means for the work — whether it still fits, and if not, where it stopped fitting.

The idea

An update becomes fetch plus evaluation. After trunk moves, each piece of standing work — a pull request being tried (#290), eventually a ticket branch — is put through the merge engine (#351) against the new trunk, and the answer drives what the contributor is offered:

• It still fits → offer to bring it forward, as an explicit act the contributor chooses. The app's existing principle survives intact: it never silently rebases anyone. The difference is that "bring it forward" now exists as a button instead of as a funeral.
• It conflicts → the merge lands the markers in the tree (#352 takes over from there), and the words are the important part: trunk moved underneath this work; it no longer fits as written. For a pull request, that has a name every Git user knows — it needs a rebase — and knowing that is itself valuable (the follow-up issue on telling the author picks this up).
• Step back → declining is always available and always safe: the work stays on its branch, correct against the trunk it was written on, exactly as today.

The order of operations matters and is part of the design: evaluation happens on the standing work's own terms, never by force-resetting first and apologising after. Nothing in this flow may destroy what it set out to evaluate.

Deliberately not proposed

Automatic bring-forward, even when clean. A clean three-way merge is strong evidence, not proof, and the contributor saying "yes" is what turns a mechanical result into their decision about their work.

Related

• #350 — the contract
• #351 — the engine that answers "does it still fit"
• #352 — the state that holds the conflicted answer safely
• #290 — the first kind of standing work this protects

Start at the trunk update flow and read the related contract and merge-engine issues (#350 and #351), plus the conflicted-state issue (#352) and standing-work example (#290). Done means an update evaluates standing work without destroying it, offers an explicit bring-forward choice when it still fits, preserves conflicts safely, and always allows declining.