Deploy

Take the branch from "I am happy with it" to delivered and closed out. The user's invocation authorizes the commit and delivery within the repository's configured policy. The default route pushes the branch, opens or updates its change request, merges it, closes out its linked work, and verifies production when workflow.md assigns that to the agent. A human approves every production release, through the deployment system's gate or invocation approval (step 5); deploy only triggers one, through a merge. Load each dependency named below through the available skill invocation mechanism or its installed SKILL.md; when one is not installed, follow the fallback given with it and report the missing skill as a gap.

Once the change request is registered with the harness, tell a pause from a stop. Step 4's wait for the watcher is a pause: keep the registration, end the turn, and resume when the watcher wakes you. A question to the user from step 5 is a pause too: stop watching before you ask, and resume on the answer. Every other stop ends the run, including the final report: stop watching the change request first so control returns to the user.

When any stop leaves an open change request unmerged, remove its agent-merge label, so it reads as awaiting a person; a later run adds it back when step 3's conditions hold.

Read docs/agents/code-host.md for delivery operations, docs/agents/workflow.md for the delivery mode, base branch, merge strategy, actors, closure events, and production verification, and, when the work links tickets, docs/agents/issue-tracker.md for their operations. workflow.md is authoritative for the base branch and merge strategy; take each from code-host.md only when workflow.md does not record it. Reuse their unchanged contents from context. Without them, use the repository's contribution rules, the host CLI, and the host's default merge method.

Choose the delivery route before any remote or change-request operation. Use the hosted change-request route unless the repository explicitly configures local delivery, branch-only delivery, or another review equivalent. For an alternative, record its operation, destination, actor, prerequisites, and completion evidence from the configuration; report missing decisions before delivery. A local destination makes delivery local-only: use local refs and operations throughout, with no fetch, push, or code-host calls. Both routes share steps 1 and 2; alternatives then use Delivery without a change request below instead of steps 3 through 5.

Resolve the delivery base before changing branches: the user's branch argument, then the configured base branch, then the default branch. Record the intended changes: the user's request plus any cleanup or review record, else the batch step 1 finds. Keep cleanup's review base and checked content so its batch can be told from inherited branch history; when committing leaves that content unchanged, reuse its check record.

After a merge. On the hosted route, look up the current branch's change request before step 1. When it is merged, or the user names a merged change request, skip steps 1 through 4: run step 5's Verify and then step 6 for that change request. This route resumes close-out after a human merges on the host, and finishes production verification that was pending when an earlier run ended. When the current branch also holds pending task changes or commits after the merged head, deliver them afterward from step 1, unless the user named the change request; then report them instead. When the user names a change request that is not merged, report its state and stop.