cmd: let implicit pr reopen target the current branch's closed PR #454

New issue

Closed

opened 2026-04-27 02:25:44 +00:00 by barrettruth · 1 comment

barrettruth commented

2026-04-27 02:25:44 +00:00

Problem

reopen is the only obvious branch-relative PR toggle action that still cannot participate in the implicit command model.

Today:

the picker already models PR state transitions as open/opened -> close, closed -> reopen, and merged -> nil
:Forge pr reopen still requires an explicit PR number

That makes the branch-relative workflow feel inconsistent. If I close a PR and remain on the branch, reopening that same PR still requires me to look up or remember the PR number.

Proposed solution

Allow :Forge pr reopen with omitted {num} to resolve the unique closed PR for the current branch.

This should be implemented on top of a broader branch-relative PR resolver rather than by broadening the existing open-only current_pr() semantics.

Behavioral expectations:

if there is exactly one closed PR for the current branch, reopen it
if there are multiple candidate PRs, require repo= / head= disambiguation
if the matching branch PR is merged, do not offer reopen and fail cleanly
keep explicit {num} behavior unchanged

Acceptance criteria

:Forge pr reopen accepts omitted {num} when the current branch resolves to a unique closed PR
merged PRs remain non-reopenable
omitted-subject reopen supports repo= / head= disambiguation
explicit {num} reopen remains unchanged
command specs and vimdoc cover the new implicit behavior

depends on a broader branch-relative non-open PR resolver
complements #450 rather than duplicating it

## Problem `reopen` is the only obvious branch-relative PR toggle action that still cannot participate in the implicit command model. Today: - the picker already models PR state transitions as `open/opened -> close`, `closed -> reopen`, and `merged -> nil` - `:Forge pr reopen` still requires an explicit PR number That makes the branch-relative workflow feel inconsistent. If I close a PR and remain on the branch, reopening that same PR still requires me to look up or remember the PR number. ## Proposed solution Allow `:Forge pr reopen` with omitted `{num}` to resolve the unique closed PR for the current branch. This should be implemented on top of a broader branch-relative PR resolver rather than by broadening the existing open-only `current_pr()` semantics. Behavioral expectations: - if there is exactly one closed PR for the current branch, reopen it - if there are multiple candidate PRs, require `repo=` / `head=` disambiguation - if the matching branch PR is merged, do not offer reopen and fail cleanly - keep explicit `{num}` behavior unchanged ## Acceptance criteria - `:Forge pr reopen` accepts omitted `{num}` when the current branch resolves to a unique closed PR - merged PRs remain non-reopenable - omitted-subject reopen supports `repo=` / `head=` disambiguation - explicit `{num}` reopen remains unchanged - command specs and vimdoc cover the new implicit behavior ## Related - depends on a broader branch-relative non-open PR resolver - complements #450 rather than duplicating it

barrettruth commented

2026-04-27 17:21:22 +00:00

Tracking note: I’m implementing #453 first as the shared resolver/backend layer. This issue should then consume it with a closed-only implicit branch-relative resolver for :Forge pr reopen, while still rejecting merged PRs.

Tracking note: I’m implementing #453 first as the shared resolver/backend layer. This issue should then consume it with a closed-only implicit branch-relative resolver for `:Forge pr reopen`, while still rejecting merged PRs.