Recognize trusted automation actors in merge-train enqueue policy

[cbusillo]

Finish Line

Launchplane merge-train actor classification recognizes the expected agent/bot GitHub identity as trusted automation, so normal helper-created PRs can enter the merge train without requiring a human to recreate the PR under a repo owner account.

Current Status

State: Repro observed in cbusillo/codex-skills while landing a docs-only policy PR.
Next action: Decide the actor-role model and implement/import policy support for trusted automation identities.
Blocked by: No native issue blocker.
Waiting for: Launchplane maintainer decision on whether this is a policy-config change, service actor-classification change, or both.
Last verified: 2026-05-29.

Evidence

The normal codex-skills PR helper created cbusillo/codex-skills#179 as shiny-code-bot. The PR was green, mergeable, and labeled ready-to-merge, but the Launchplane controller dry-run refused to enqueue it:

• Launchplane runner: https://github.com/cbusillo/launchplane/actions/runs/26616418532
• Controller action: idle
• Queue contained PR Type product context cutover store boundary #179
• actor_role: unknown
• eligible: false
• ineligible_reasons: actor role is not allowed to enqueue
• Trace: launchplane_req_98a9050f505d494e987fb9d0ccecad24

To finish the work, the same commit was recreated as cbusillo/codex-skills#180 using the active repo owner account cbusillo. Launchplane then classified the author as repo_owner, admitted the PR, and landed it normally:

• Dry-run/admission runner: https://github.com/cbusillo/launchplane/actions/runs/26616532942
• Queue order: [180]
• Selected PR: Type release tuple store boundary #180
• actor_role: repo_owner
• eligible: true
• Controller action: plan_candidate
• Trace: launchplane_req_15ed27366c3e4caaa80d94769f1693e7
• Landed runner: https://github.com/cbusillo/launchplane/actions/runs/26616621800
• Merge commit: ee509cbcc32c109b7800531f9ab5b6e638da2925

Proposal

Add a first-class trusted automation actor role instead of requiring agents to bypass the helper path or impersonate a repo owner.

Suggested shape:

[policies.enqueue]
label_required = true
allowed_actor_roles = ["repo_owner", "repo_admin", "trusted_automation"]
trusted_automation_logins = ["shiny-code-bot"]

The exact config shape can differ, but the behavior should be explicit and auditable:

• known bot identities are configured per policy, org, installation, or repository
• trusted automation is distinct from repo_owner/repo_admin
• the controller output reports the resolved role and why it was trusted
• unrecognized bot/user identities still classify as unknown and remain blocked

Acceptance Criteria

• A PR authored by the configured automation identity can be eligible when it is otherwise mergeable, green, and labeled with the enqueue label.
• Controller dry-run output distinguishes trusted_automation from unknown and from human owner/admin roles.
• Policy import or repo metadata has a clear way to configure allowed automation identities.
• Existing policies that only allow repo_owner/repo_admin remain unchanged until they explicitly opt into trusted automation.
• Tests cover allowed automation, unknown automation, and existing owner/admin behavior.