task-landlisted

# Land a task (merge the PR) The last mile of the daily loop: `task-new → task-start → task-finish → **task-land**`. One deterministic recipe call does the whole landing — undraft, then merge. **Never fall back to `gh pr merge` / `az repos pr update`.** Baron has the primitives, and going around it means the merge happens outside the run the user can audit. If Baron refuses, the refusal is the answer — report it, don't route around it. ## Steps 1. **Identify the work item**: parse the current branch (`git rev-parse --abbrev-ref HEAD`) as `<prefix>/<id>-<slug>`. If the branch doesn't match, ask which item to land — never merge a PR you inferred. 2. **Check before you merge** — call `baron_scm_read op=pr_for_branch`, then `baron_scm_read op=pr_status` on the PR it returns. Read three things and say them out loud: - **checks** (`rollup`) — `failed` or `pending` means STOP and ask, rather than merging red or unfinished. `unknown` means the view was incomplete, and `checks.unreadable` names exactly which sources did not contribute — quote it. `['check-runs', 'actions-runs']` means the credential lacks **Actions: Read** (a fine-grained GitHub token can never hold the Checks permission, so Actions is the way in); `['policy-evaluations']` is Azure, which Baron does not read yet. This matters: an unexplained `unknown` looks like a broken integration, and someone will go hunting. It is NOT `none` — that one means the provider was asked and