ops-integrate

name

ops-integrate

description

Land an approved PR. Owns every piece of merge policy — the gates (landing label, CI green, mergeable, and a base the branch model accepts), the release-base skip, and the merge itself — and returns a structured outcome the caller reports on. A caller hands it a PR and reads back what happened; it never holds a branch name or a merge strategy. Called by name with (action, context-json) by a framework loop. NOT for direct use — never select it from a description match.

ops-integrate

The service that answers one question: may this PR land, and if so, land it.

Visibility: service. A framework loop may command it. It is the only thing ops-merge-loop commands.

Why it exists. The gates used to live in the merge loop, alongside the sweep, the poll cadence and the caps. That put merge policy in the same place as merge scheduling, and made the loop resolve base branches and merge strategies itself — the leak ops-branching's privacy rule exists to close. Split the two: policy here, scheduling in the loop.

It is PR-generic. Nothing below asks who wrote the PR or which issue produced it. Every gate is a machine-verifiable property of the PR itself, which is why dependabot PRs and human-authored PRs land through the same path as loop-authored ones.

Invocation

ops-integrate land '<context-json>'

Action	Context	Returns
land	{ pr: { repo, number } }	{ ok, outcome, detail, merge_commit, line }

An absent context is {}. Reject any other action — do not guess.