Mothership merge orchestration — team-wide PR sequencing and rebase coordination

[aselim31]

Problem

When multiple developers (or multiple drones) submit PRs for concurrent PBIs, they all branch from the same base. Merging them in sequence requires rebasing each onto the previous merge — work that today falls entirely on the developer. At team scale, this becomes a coordination problem: who merges first? Who rebases? How are conflicts surfaced across the team?

The Outpost Work Inbox (#618) solves this for a single developer's queue — it rebases the next item after each local merge. This issue is the team-wide equivalent: Mothership coordinates merge order and rebase across all concurrent PBIs from all developers and all drones.

Proposed solution

Mothership tracks all in-flight PRs across the team and orchestrates the merge sequence when they complete.

PR registration

When a drone or outpost raises a PR, it registers it with Mothership:

{
  "pr_url": "https://github.com/org/repo/pull/42",
  "branch": "feat/proj-123",
  "base": "main",
  "submitted_by": "outpost:carlos",
  "priority": 1,
  "depends_on": []
}

Merge sequencing

Mothership maintains a merge queue ordered by priority and dependency. When a PR is approved and ready to merge:

1. Mothership checks if it is next in sequence
2. If yes → triggers merge
3. Rebases the next PR in sequence onto merged main
4. If rebase produces a conflict → notifies the owning developer via Task failure and stall notifications — notification sink + stuck detector #619 notification sink
5. Developer resolves → Mothership resumes

Dependency-aware ordering

PRs can declare dependencies — if PROJ-124 builds on PROJ-123, Mothership enforces that PROJ-123 merges first regardless of approval order.

Conflict resolution

When a rebase conflict surfaces:

• Mothership pauses that PR in the sequence
• Notifies the owning developer with the conflicting files and a Studio deep-link
• Other independent PRs in the queue continue merging — only the conflicting one is blocked
• On resolution, Mothership re-rebases and resumes

Dashboard surface

Mothership fleet dashboard shows the team's merge queue — which PRs are waiting, which are in conflict, estimated merge order. Developers can see where their PBI sits without asking teammates.

Scope

• Merge queue management on Mothership
• PR registration from outpost and drone on completion
• Dependency-aware sequencing
• Rebase trigger and conflict detection
• Developer notification on conflict (via Task failure and stall notifications — notification sink + stuck detector #619)
• Merge queue panel in Mothership dashboard

Out of scope

• Automatic conflict resolution (AI-assisted merge) — future
• Cross-repo merge coordination — future
• Merge queue for external PRs not raised by dotbot — out of scope

Acceptance criteria

• Outpost and drone register PRs with Mothership on completion
• Mothership maintains merge queue ordered by priority and declared dependencies
• Approved PRs merge in queue order — not first-come-first-merged
• Rebase runs automatically between each merge
• Conflict pauses that PR, notifies developer, allows other PRs to continue
• Merge queue visible in Mothership fleet dashboard
• Developer can reorder or remove their PR from the queue via dashboard

Dependencies

• Outpost Work Inbox — queue, QueueRunner, and rebase orchestration #618 Outpost Work Inbox — individual queue feeds into this team-wide orchestration
• Task failure and stall notifications — notification sink + stuck detector #619 Notification sink — conflict notifications delivered via this
• WorkQueueService (full) + DroneSchedulerService — Mothership-side drone dispatch #593 WorkQueueService — Mothership-side infrastructure
• Decision sync — push outpost decisions to Mothership for cross-project visibility #596 Decision sync — decisions made during drone runs need to be visible before merge
• Event forwarding — outpost-to-Mothership event sink #599 Event forwarding — PR completion events reach Mothership from outpost

Release

v4.3 — requires full drone fleet (#96, #593), event forwarding (#599), and outpost queue (#618) to be in place