work-items(work): gh pr list --state open transiently omitted an open PR, causing a same-plugin version collision

[kyle-sexton]

Lane: work · Category: operational (cross-lane guard reliability)

Triggering example

While picking work this cycle, the orchestrator ran `gh pr list --repo melodic-software/claude-code-plugins --state open --json number,headRefName --limit 100` to check plugin occupancy before dispatching #661 (review plugin). The returned list did NOT include PR #658 (also review plugin, opened ~1 hour earlier, genuinely still OPEN — verified moments later with `gh pr view 658 --json state,isDraft,mergedAt,closedAt` → `{"closedAt":null,"isDraft":false,"mergedAt":null,"state":"OPEN"}`). Because the occupancy check read review as clear, #661 was dispatched there too, producing a real same-plugin version collision (both #658 and #673 independently bumped `0.14.4` → `0.14.5`; see #464 for the general collision class, now with this concrete instance added).

Re-running the identical `gh pr list` command minutes later correctly returned all 12 open PRs including #658, sorted by number 489→673 with no gaps. The omission was not reproducible on retry — no draft/closed/merged state ever explained the earlier absence.

Observed vs expected

• Observed: a `gh pr list --state open` call transiently omitted a genuinely-open PR from its results, with no error surfaced and no indication of partial/stale data. The cross-lane occupancy guard (rule 3b in this lane's standing rules) trusts this list as ground truth for "is this plugin already occupied" — a silent, unreproducible omission defeats that guard exactly once, with a real (if low-severity — just a routine rebase) consequence.
• Expected: either (a) this is a known `gh` CLI / GitHub API eventual-consistency edge case worth documenting as a standing caveat in the occupancy-check step (e.g. "re-verify with a second call if a dispatch is about to happen and the plugin looked surprisingly clear"), or (b) if reproducible with more investigation, a real bug worth reporting upstream to `cli/cli`.

Category

operational (tooling reliability gap in a safety-relevant check)

Suggested fix direction (not investigated in depth)

Cheapest mitigation: before dispatching to a plugin that the occupancy check reports as clear, do a second confirmatory check (e.g. `gh pr list --search " in:files"` or a second plain `--state open` call) rather than trusting a single read — costs one extra `gh` call per dispatch, buys real protection against this exact failure mode. Not filed as urgent since the actual consequence (a same-plugin CHANGELOG/version rebase) is already a known, cheap, routinely-handled cost per #464.

Related

#464 (the version/CHANGELOG collision class this transient omission triggered a fresh instance of) · #658, #673 (the colliding PRs)

[kyle-sexton]

This was generated by AI during triage.

Folding this into #464 (per-change version bump + CHANGELOG serialize collision class, umbrella-fold rule). This issue's own text already names #464 as the general class it's an instance of, and its consequence (a same-plugin version/CHANGELOG rebase) is one #464 already treats as a known, cheap, routinely-handled cost — no new decision needed on that side.

Kept distinct for visibility: the cause this issue reports — a gh pr list --state open call transiently omitting a genuinely-open PR, defeating the /work-items:work occupancy pre-check — is narrower than #464's scope and worth #464's eventual owner knowing about (see options in this issue's body: document as a known gh/API eventual-consistency caveat + add a confirmatory second check, or investigate reproducibility and report upstream to cli/cli). Riding along as a member rather than a standalone item; no separate fix decision is being deferred by folding.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned.

Transient gh pr list omission is an operational hazard note, not an open engineering deliverable.