land

Load mahou:basics first. Then read `.mahou/land.md` if present. # Land Coordinates the plugin's skills into one process, from open branches to merged pull requests. It merges no pull request and picks no order on its own. ## Step 1: Check the release Run mahou:release-check on the repositories in scope. Present its release order and wait until the user confirms it or changes it. A change can break no boundary when it touches one repository and changes no request, response, schema or event that crosses a service boundary. When both hold, say so with the facts that show it, propose skipping mahou:release-check, and give the one-step order. The user confirms the skip and the order together, or asks for the check. ## Step 2: Open the pull requests Run mahou:create-pull-request once per repository, all together. Report every PR URL. ## Step 3: Babysit the pull requests Start one background loop per PR that polls at a fixed interval and exits on the first of these: - an unresolved review thread appeared, or the review body has a finding without a thread - the branch fell behind its base - a check failed - the PR was merged ``` gh pr view <number> --repo <owner>/<repo> --json state,mergeStateStatus,statusCheckRollup ``` plus the review threads through the GraphQL API (`gh api graphql`, the `reviewThreads` connection of the pull request, reading `isResolved` per thread). `gh pr checks --watch` blocks on checks, but nothing in `gh` blocks on reviews or merges, so the loop polls. When a loop exits, handle that PR and start its loop again: - **Review.** Run mahou:address-pr-review on that PR. It settles the findings with the user, applies what they approve, commits, pushes and resolves the threads. - **Behind its base.** Run mahou:rebase, which never pushes. Report what moved and push once the user confirms. - **Failed check.** Report the check with its URL and stop for the user. - **Merged.** Record it. The user merges the pull request, either in GitHub or by asking you to merge it. ## Step 4: Merge in order Walk the confirmed order. The release follows each project's own process once its pull request merges; usually the CI publishes the tag on its own. For each repository: 1. Wait until its pull request is merged and the user has confirmed that every repository before it in the order works in production. 2. Watch the CI run the merge triggers: ``` gh run watch <run-id> --repo <owner>/<repo> --exit-status ``` Report the jobs, their conclusions, and the tag when the run publishes one. A failed job stops everything until the user decides. 3. Stop. The next repository starts when the user confirms this one works in production. ## Step 5: Clean up the local checkout Once every repository has merged and the user has confirmed the last one, clean up each repository's local checkout: 1. Switch to the base branch its pull request merged into, and pull it. 2. Delete the merged local branch with `git -C <repo-path> branch -d <branch>`. `-d` refuses a branch that is not merged. When git refuses, report it and do not force-delete the branch. Report the branch each repository is on and its new head. ## Step 6: Report One line per repository: PR, merge, the CI result, and the tag when the project's automation published one. Then stop.