PR Guardian

Use this workflow by default after opening a pull request, and when an existing PR needs follow-up after CI, CodeRabbit, Codex, bot, or human review feedback. The goal is to leave the PR merge-ready or report a specific blocker, not to provide a partial status update.

Workflow

0. Delegate passive monitoring to a compatible guardian runner.
   • Read references/guardian-event-contract.md. Require kaizen-loop guardian capabilities --json to advertise schema version 1 and durable completion notification support before monitoring. When the repository is registered with a compatible kaizen-loop, start kaizen-loop guardian run <pr-number> --project <project-slug> --json once through an execution path that can deliver its terminal event without asking Codex to inspect repeated process snapshots.
   • Do not repeatedly call a tool to poll the guardian process, GitHub, CI, review bots, or the stabilization window. Sleeps, gh run watch, GitHub API polling, head-change detection, review-completion checks, and stabilization are passive runner work and must not consume Codex reasoning cycles.
   • If the execution transport yields before completion, use its non-LLM completion notification or detach the durable job and record its job/event location. End the invocation as monitoring delegated; resume only from a terminal event. Do not wake Codex merely to observe that nothing changed.
   • Require one terminal event that passes scripts/validate_guardian_event.py for the expected repo, PR, job, sequence, and head, as well as a successful runner exit, before accepting merge_ready. Confirm the remote head once when consuming that event. Treat missing, stale, mismatched, malformed, or unsupported event output as blocked: incompatible guardian runner, never as success.
   • If no compatible durable runner or completion notification exists, inspect and fix immediately actionable state, but do not reproduce the wait loop with agent tool calls. Report blocked: passive guardian runner unavailable with the missing capability and installation or upgrade action.
   • gh pr checks --watch is only a CI watcher and never satisfies review/thread monitoring by itself.
   • Treat success as a convergence checkpoint, not a permanent terminal state while the PR remains open. The durable runner must re-observe successful jobs and reactivate a same-head PR when late review threads, checks, or merge-gate activity make it non-ready.
   • Run durable jobs in a disposable worktree pinned to the observed head. Before pushing, re-read the remote head SHA; if it changed, stop and reconcile the new head instead of overwriting it.