Choose the delivery unit for a source

[fveracoechea]

Question

Does an integrated pull request replace the pull request per assignment, or is it an option that each source chooses?

Context

Delta C1 in the flow note.
Today a code submission states an open pull request and its head, and acceptance blocks with pr_authority_missing, pr_head_required, or pr_head_changed (modules/crew-state/submission-input.ts, modules/crew-state/acceptance.ts).
The flow delivered one pull request with one commit per assignment, and each commit closed one issue.

Settle what acceptance of one assignment means when its commit lands in a shared integration branch, which ADR 0007 decision this reopens, and the two glossary terms proposed on the map.
Most other tickets on this map wait on this answer.

[fveracoechea]

Resolution: one integration branch for each source, published as a pull request stack

Resolved through live discussion with the user, in two rounds.
Round 1 answer: "recomendations sound good, we should be able to support one PR of a few stacked PRs as needed depending on the size of the task".
Round 2 answer: "sounds good".
These are human answers, not Operator inferences.

Decisions

1. Replace, not an option. Every source delivers through one integration branch. A source with one code assignment delivers one pull request with one commit, so the former pull request for each assignment is one case of the new shape. A user who wants one pull request for each ticket registers each ticket as its own source.
2. A code result is exactly one commit whose parent is the base commit of its dispatch. operator attempt submit refuses zero commits, more than one commit, or a different parent. The submission has no pull request field.
3. Accepted completion of a code result means that the integration branch holds the reviewed commit as the same patch (equal patch identity), and every existing gate passes. A patch that changed during integration, for example through a conflict resolution, is not the reviewed result, and acceptance refuses it. This replaces the pull request head check and the pr_authority_missing, pr_head_required, and pr_head_changed blockers.
4. Commit order is the landing order. A commit lands only after its dependencies are accepted, so the order is a valid dependency order. Nothing is reordered after review. The pull request body lists the real order.
5. One integration branch for each source, published as a pull request stack. A stack is a set of cut points on the one linear history. The lowest pull request targets main, and each higher one targets the branch below it. A stack of one is the default. A cut falls only between neighbouring commits.
6. The cuts are chosen at publish. The Operator proposes the cut points with a reason for each, and the user approves them as part of the publish approval. An intent stated at registration is input to the proposal, not a fixed split.
7. Existing state. A new state version. The migration refuses while any code submission waits for review or acceptance, and it names each one. The user finishes that work under the earlier release. Accepted submissions keep their recorded pull request as history.

Rejected: an option on each source or project, squash at integration, a separate "integrated" state, dependents that start from unintegrated branches, registration order, delivery groups named at registration, and cut points from a size limit.

ADR outcome

• ADR 0015 is new: "A source delivers one integration branch as a pull request stack".
• ADR 0007 is amended, not superseded. Only its pull request clauses reversed: the patch check replaces the head check. The rest of its review decisions stand.
• ADR 0009 is amended in one line, which stated the old head check.

Glossary

CONTEXT.md adds Integration branch, Integrated pull request, and Pull request stack, and sharpens Accepted completion.
Words to avoid: "delivery group", "pull request per assignment".

Assets

The glossary and ADR text are in the draft pull request docs: record the decisions of the integrated pull request map, commit 16dbf7f.
That draft collects the doc changes of this map, one commit for each decision.

Consequences for other tickets

• Choose who integrates accepted commits owns the recovery when acceptance refuses after a commit is on the integration branch. It also owns the ADR 0008 sentence "Operator does not move a branch or a pull request", which this decision did not change.
• Choose where review looks and Choose who integrates accepted commits decide what happens to a commit whose patch changed during integration.
• Choose how the integrated pull request is opened and linked now covers a stack: the cut-point proposal, the base of each pull request, the body of each one, and the merge method, because a squash merge of the lowest pull request rewrites what the higher ones are based on.