bug: develop opens a second PR instead of continuing the issue's existing open PR

[ellen-goc]

Summary

askcc develop on an issue that already has an open PR ignores that PR's branch, cuts a new branch from main, and opens a second PR re-implementing the feature from scratch. The issue is then left with two competing implementations and one action:review label.

This is distinct from #116 (label flips with no PR at all): here a PR is produced, but it is a duplicate rather than a continuation.

Reproduction

1. Issue weyucou/vblock#205 had an open PR (#210, branch feature/205-manual-court-landmark-labeling) that had been reviewed with changes requested.
2. The four review findings were posted to the issue as a checklist comment, the label was set back to action:develop, and the board item to planned.
3. askcc --cwd ~/projects/vblock develop -g https://github.com/weyucou/vblock/issues/205

Expected: the run continues on the existing branch and pushes commits addressing the requested changes.

Actual: the run created branch feature/205-court-landmark-labeling-ui off main and opened PR #211 — 3,138 additions re-implementing all six phases of the plan. PR #210's head commit was untouched. It then transitioned action:develop → action:review as normal.

Why it matters

The rebuild reproduced two defects the review had already found and that the existing PR's reviewer had written up in detail:

• a loopback HTTP server guarded by a Host check only, so a cross-origin text/plain POST from a hostile page still writes to disk;
• int(self.headers.get("Content-Length") or 0) unguarded, so a malformed header raises instead of answering 400.

Review effort spent on PR N is silently discarded, and the same defects ship again on PR N+1. Both PRs pass CI, so nothing surfaces the duplication except a human noticing two open PRs on one issue.

Notes on where the instruction went

The fix list was in an issue comment, not the issue body. If the DEVELOP prompt reads only the body's plan, that alone explains the rebuild — but it does not explain cutting a new branch while an open PR for the issue exists. Two independent things would help:

1. Detect the open PR for the issue before branching. If one exists, check out its head branch and continue on it (or stop and ask, as with the missing-assignee gate) rather than branching from main.
2. Read the linked PR's review comments as part of DEVELOP's context when a PR exists, so "address the review" is expressible at all.

Either one alone prevents the duplicate PR; the first is the smaller change.

Environment

• askcc v0.2.15
• Repo weyucou/vblock, issue #205, PRs #210 (superseded, now closed) and #211
• Run date 2026-08-27, ~09:16–10:01 JST