Define merge train repo policy

[cbusillo]

Objective

Define the per-repo policy Launchplane needs before it can safely run a sequential merge train.

Finish Line

Repo/base branch merge train policy is explicit and testable

Current Status

State: Needed before implementing the sequential merge train MVP.
Next action: Decide the initial policy shape and where it should live in Launchplane configuration.
Blocked by: None.
Last verified: 2026-05-07 while planning #410.

Scope

• Repo/base branch opt-in configuration.
• Enqueue label and blocked-state labels.
• Merge method and actor/token expectations.
• Failure policy: pause train vs continue after marking one PR blocked.
• Safety gates that Launchplane must check before attempting merge.

Acceptance Criteria

• Policy supports at least repository, base_branch, enqueue_label, blocked_label, merge_method, and failure_policy.
• Policy defines who/what may enqueue a PR, initially by label presence plus repo owner/admin action.
• Policy states whether Launchplane should continue to the next queued PR after one PR is blocked.
• Policy identifies which GitHub token/identity is allowed to update branches and merge PRs.
• Policy is discoverable by both CLI/dry-run and service/worker code.
• SellYourOutboard has an initial opt-in policy for main that can be used as the first live smoke target.

Relationships

Blocks #410.

Validation

• Unit tests for loading valid/invalid merge-train policy.
• Dry-run output shows the resolved policy for cbusillo/sellyouroutboard main.

Decisions

• Keep native GitHub required checks as the source of truth for merge safety.
• Do not implement global auto-merge defaults without explicit repo/base opt-in.

Open Questions

• Should failure pause the whole train by default, or mark one PR blocked and continue?
• Should merge method default to merge commit, or be required in policy?