creating_pr infinite loop: pr_url frontmatter never recovers from merged PR URL section, and gets evicted on retry

[jodavis-claude]

Symptoms

dev_team.py's fix-issue-plan pipeline for Issue-219 got stuck in an infinite loop at
state: creating_pr. The dev-team:developer agent had already created PR #221
(#221) on branch dev/claude/Issue-219. The
create-pr-from-context skill's step 5 wrote the {"pr_url": "..."} deliverable to the
.pending/Issue-219__PR_URL.md scratch file (the write-scratch-deliverable half of step 5),
and merge_pending_deliverables() merged it into the context file's <!-- section:PR URL -->
body section — but the skill's other step-5 instruction ("Use the use-context-file skill to
write the returned PR URL to the pr_url frontmatter field") was never carried out, so
pr_url: frontmatter stayed empty.

Re-running dev_team.py after that kept re-emitting the exact same creating_pr spawn_agent
descriptor instead of progressing, risking a duplicate gh pr create on retry.

Root cause, confirmed by reading plugins/dev-team/skills/workflow-orchestrate/scripts/dev_team.py
and pipeline_context.py:

1. CreatePrStep.get_actions() (dev_team.py:755-773) gates re-dispatch on if ctx.pr_url: return [] only. ctx.pr_url is a frontmatter-only field populated at PipelineContext.load()
   time from YAML frontmatter (pipeline_context.py:179) — it is never populated from the
   merged PR URL body section at load time (unlike e.g. DebugStep, which correctly gates on
   ctx.debug_report, itself populated straight from the Debug Report section body at load time
   — pipeline_context.py:203). So when the section is merged but the frontmatter write didn't
   happen, get_actions() returns the spawn_agent action again instead of [], and
   DevTeamPipeline._do_get_actions_and_exit() (dev_team.py:1171-1227) exits with that action
   before CreatePrStep.handle_results() — the only place that ever parses the PR URL section —
   gets a chance to run.
2. Worse and more destructive: that same _do_get_actions_and_exit() call, on seeing a non-empty
   actions list, does self.ctx.pending_agent = ...; self.ctx.save(self.context_path)
   (dev_team.py:1225-1226) before exiting. PipelineContext.save()
   (pipeline_context.py:52-134) fully regenerates the context file's body from only the
   dataclass's own tracked fields (debug_report, brief, work_summaries, review_notes,
   etc.) — there is no field at all for the PR URL section's content, so this save() call
   silently evicts the already-merged PR URL section from the file, permanently losing the
   PR URL that was already recorded there. Confirmed directly against the actual Issue-219 context
   file: no <!-- section:PR URL --> block remains in it despite merge_pending_deliverables()
   having merged one in.

Net effect: CreatePrStep can never self-recover from "section merged but frontmatter not yet
extracted" — it just re-spawns create-pr-from-context forever, and each re-entry actively
destroys the evidence needed to recover, not just fails to use it.

Workaround

Verified PR #221 is still open on dev/claude/Issue-219 (gh pr view 221 — matches), then
hand-set the context file's pr_url: frontmatter field directly to
https://github.com/jodavis/agent-plugins/pull/221. On the next dev_team.py invocation,
CreatePrStep.get_actions() sees non-empty ctx.pr_url and returns [] (the designed "recovery
re-entry" path), so control falls through to handle_results(), which sees ctx.pr_url already
set, calls _handle_agent_success(ctx), and returns the pr_created trigger without attempting
to create a second PR. This is safe to reuse any time this exact state is reached again (empty
pr_url frontmatter, state: creating_pr, and a real PR already known to exist for the branch) —
confirm the PR still exists and matches the working branch via gh pr view <n> before hand-editing,
then set pr_url: to its URL.

This does not fix the underlying dev_team.py/pipeline_context.py gap described above, which
will recur on any future run where the frontmatter write step is skipped or races with the
section merge (this same pipeline was noted to need to run again shortly for a stacked Issue-216
fix). A proper fix would mirror the DebugStep/debug_report pattern: add a pr_url_section
(or similarly named) field to PipelineContext, populate it from the PR URL body section at
load() time, serialize it in save() so it's never silently evicted, and have
CreatePrStep.get_actions()/handle_results() gate on and consume it the same way DebugStep
does for debug_report. troubleshooter.can-fix/can-push-fix are both unset in the merged
project configuration for this run, so that fix was not attempted here.

[joedavis-oura]

Second reproduction, on ent-inventory-api's EAC-2781 task pipeline (context file
.dev-team/jouzen/ent-inventory-api/EAC-2781.md).

Same shape as the original: create-pr-from-context ran and succeeded — PR #68
(https://github.com/jouzen/ent-inventory-api/pull/68, head joedavis-oura/task/EAC-2781, base
joedavis-oura/EAC-2051-spec, confirmed open with the expected diff of 8 files) — but the
step's frontmatter write-back (pr_url:) did not persist; state stayed at creating_pr with
an empty pr_url: and no <!-- section:PR URL --> block at all in the file (the section had
apparently never been merged in this occurrence, unlike the original report where it was merged
and then evicted on retry — same net symptom either way: CreatePrStep.get_actions() keeps
re-emitting the creating_pr spawn_agent descriptor because ctx.pr_url is the only thing it
gates on).

Applied the documented workaround: confirmed PR #68 still exists and matches the working branch
via gh pr view 68, then hand-set pr_url: in the context file's frontmatter to
https://github.com/jouzen/ent-inventory-api/pull/68 (and added a <!-- section:PR URL -->
block with the equivalent {"pr_url": ...} JSON, for consistency with what the skill would have
merged). This confirms the workaround still applies. troubleshooter.can-fix/can-push-fix are
both unset in this run's merged project configuration, so the underlying dev_team.py/
pipeline_context.py fix proposed above was not attempted here either.

Written by Claude Opus 5

[jodavis-claude]

Third reproduction, on agent-plugins's ADR-393 task pipeline (context file
/home/vscode/.dev-team/jodavis/agent-plugins/ADR-393.md).

Same shape again: create-pr-from-context (invoked via workflow-worker with
--write-section 'PR URL' --skill create-pr-from-context --skill-args ADR-393) ran and reported
success — PR #244 (#244, head
dev/claude/ADR-393, base feature/ADR-336-proposal-detailed-design-split) confirmed open,
with headRefOid 73f6309283e18dd05b6bf5c5877e664ee8aa5aed matching the branch's known HEAD —
but state stayed at creating_pr with an empty pr_url: frontmatter field and no
<!-- section:PR URL --> block anywhere in the file, so dev_team.py kept re-emitting the same
creating_pr spawn_agent descriptor.

Applied the documented workaround: verified PR #244 still exists and matches the working branch
via gh pr view 244, then hand-set pr_url: in the context file's frontmatter to
https://github.com/jodavis/agent-plugins/pull/244 and added a
<!-- section:PR URL --> block with the equivalent {"pr_url": ...} JSON. This confirms the
workaround still applies. troubleshooter.can-fix/can-push-fix are both unset in this run's
merged project configuration, so the underlying dev_team.py/pipeline_context.py fix proposed
above was not attempted here either.

[jodavis-claude]

Fourth reproduction, on agent-plugins's ADR-394 task pipeline (context file
/home/vscode/.dev-team/jodavis/agent-plugins/ADR-394.md).

Same shape again — and notably the immediate next task in the same epic/stack right after the
third reproduction (ADR-393) above: create-pr-from-context (invoked via workflow-worker with
write_section: "PR URL", skill: create-pr-from-context, args ADR-394) ran and reported
successful — PR #245 (#245, head
dev/claude/ADR-394, base dev/claude/ADR-393) confirmed open (draft), with headRefOid
82d7a6901d51b00d506181b675b9a34df33172e8 matching the branch's known HEAD via git ls-remote origin dev/claude/ADR-394 — but state stayed at creating_pr with an empty
pr_url: frontmatter field and no <!-- section:PR URL --> block anywhere in the file, so
dev_team.py kept re-emitting the same creating_pr spawn_agent descriptor.

Applied the documented workaround: verified PR #245 still exists and matches the working branch
via gh pr list --head dev/claude/ADR-394, then hand-set pr_url: in the context file's
frontmatter to https://github.com/jodavis/agent-plugins/pull/245 and added a
<!-- section:PR URL --> block with the equivalent {"pr_url": ...} JSON. This confirms the
workaround still applies. troubleshooter.can-fix/can-push-fix are both unset in this run's
merged project configuration ("troubleshooter": null), so the underlying dev_team.py/
pipeline_context.py fix proposed in the original report was not attempted here either.