delivery-looplisted

# Delivery loop Conductor for non-trivial task work. It does not replace specialist skills; it decides which phase comes next, delegates to the right skill, records evidence, and stops at human gates. Read `references/delivery-checklist.md` at the start of a run, then keep its status block current in user-facing updates and the final handoff. ## Core rules - If no accepted plan exists, research as needed, draft a `<proposed_plan>`, and stop for user approval before implementation. - If the user has explicitly approved a plan in the current conversation, continue into implementation and quality loops. - Keep loops bounded: after repeated failures, stop with evidence, blocker, and the next decision needed. - Never merge into a protected branch (`main`, `master`, `develop`, or the repository default) unless the current user message explicitly names that branch as the merge target and asks to merge it. A release, PR, approval, or general shipping request is not merge authorization. - Do not commit, push, create a PR, merge, rebase, run destructive Git commands, install dependencies, or perform live security testing unless the user explicitly authorizes that action. - Repo-local instructions (`AGENTS.md` / `CLAUDE.md`) and project workflow skills outrank this generic guidance when they apply. ## Phase map Each phase names the specialist skill to delegate to; per-phase inputs, exit evidence, and stop conditions live in the checklist reference. Three phases have a subagent wi