This boundary governs a full loop the user chose. Simple work instead follows explicit user integration authority and repository policy: route selection alone never authorizes a push, an agent pushes directly to an integration branch only when the user explicitly authorizes it and permissions allow it, and a repository may impose stricter rules.
Every full change branches from the current tip of main, never from unaccepted work. Each initiating author takes one full Cliewen change to its ready PR before starting another; independent authors may work in parallel from main, and simple work does not consume this slot. Reviewing or helping update an existing PR does not mint another change or create a global lock. If work must build on an unmerged change, record a blocking open question and stop unless the human explicitly authorizes it. Keep its answered question committed until digest, naming the unmerged base, the authorization, and the meaning the dependent merge would bind; repeat the same disclosure in the ready acceptance brief. That record does not make the base accepted or permit an agent to merge either change. When accepted main advances while the change is open, incorporate it by merging main into the change branch with a normal push, never by rewriting hosted history, then repeat verification and review.
For a full Cliewen change, the human accepts the ready pull request with a merge commit. Configure the protected default branch to allow merge commits and disable squash and rebase-and-merge: the merge commit keeps the proposal, implementation, digest, and durable corpus commits reachable from main, while the other modes can discard or rewrite that reviewed chain. Because publication begins with the first commit, there is no unpublished branch to rebase: hosted history is never rewritten. A forge that cannot enforce the merge-commit boundary is outside the supported full-change adoption path.
Inside the full loop, this rule applies. Push is durability, never a signal. Every working turn that changed anything ends by committing and pushing the change branch, whatever state the work is in: an agent's local worktree is private memory, no handoff survives it, and a turn that ends without pushing has parked the work where no human, agent, or hosted check can see it. Committing and pushing claim nothing about readiness — the branch simply always holds the work as far as it got. A turn that changed nothing commits and pushes nothing, so a reviewed commit stays exactly as reviewed.
The PR exists from first publication and starts as a draft: a full change opens it right after the proposal commit. The draft is where unfinished work lives and is visible; it claims nothing and cannot be merged. Marking the PR ready for review is the explicit act that claims a candidate, taken only when local verification and the automatic agentic review loop have passed on the current commit and the hosted head equals it. The PR is the completed proposal's authorization and protected-integration boundary, not a demand for duplicate human code review: the agent may prepare and publish the candidate, but only a human-controlled PR merge accepts it. A substantive edit to a ready PR returns it to draft until its new head has earned the same binding. Inside this boundary, an agent never merges its own PR, creates a local merge commit into main, or pushes to main.
A PR alone displays hosted CI but does not enforce it. Where hosting supports enforcement, the PR triggers CI, branch protection makes its required status check a merge precondition, and the agent cannot silently skip the gate. On a draft, the checks that judge a completed candidate — the digest gate and the acceptance-brief requirement — do not yet apply; they bind when the PR is marked ready and on main, and because the forge cannot merge a draft, the merge gate stays whole. Never weaken the workflow or required-check policy to make a change pass.
Every review of an existing hosted PR is bound to its observed head SHA. A clean result applies only to that commit; every substantive edit invalidates it. An advisory from a pass with no blocking findings stays in the verification handoff for a later change rather than editing the clean commit: the bounded loop is over, and an edit would create a new candidate that this exact-commit rule requires reviewing. A blocking finding is actionable durable PR state, not private agent memory: where the host supports resolvable review conversations, publish the finding there and leave it unresolved until a hosted commit contains the reviewed repair. Advisories do not become repair-required conversations. If the reviewer cannot publish a resolvable finding, report the PR as not merge-ready and disclose that the host cannot enforce the finding; this fail-safe applies to blocking findings, while advisories stay in the handoff; never claim a chat-only finding has equivalent protection.
Any agent that edits an existing PR becomes the updater for that turn. Before editing, fetch the PR and record its hosted head; push only normal fast-forward updates, never force. If the head changed underneath the turn or a push is rejected as non-fast-forward, fetch and reconcile without overwriting remote work, then rerun verification and review on the resulting commit. A repair pushed to a ready PR returns it to draft until the repaired head has its own verification and clean review pass. If the PR merged or closed, stop without pushing — the one case where a turn ends unpushed — report the work and where it stands, and never create a follow-up change without explicit human scope.
Ready means the hosted PR contains the exact locally reviewed and verified state, and marking it ready is the only claim of readiness. Before marking a change ready, commit every intended edit, run the applicable local verification and a clean agentic review pass against that commit, require git status --porcelain to be empty, push, and confirm that the hosted PR's head branch and SHA equal the current local branch and HEAD; then mark the PR ready and perform the hosted check again immediately after. Resolve satisfied review conversations only after the hosted head contains their reviewed repair. If either side differs, apply the updater rule above, rerun verification and review on the resulting commit, and check again. Stopping anywhere else is ordinary, not an exception: the branch is pushed, the PR is a draft, and no claim of readiness exists — say where the work stands rather than that a ready PR exists.
After marking its initiated full PR ready and confirming its hosted head, an agent stops before initiating another full Cliewen change; simple work may still proceed under explicit user authority, and the agent may review or help update an existing PR under the handoff above. Review fixes stay on the same branch and PR and repeat the complete updater handoff before the PR is ready again. A follow-up full change exists only when a human has accepted this one and explicitly scoped the follow-up.