resolver: add branch-relative non-open PR lookup beside current_pr() #453

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

current_pr() is intentionally open-PR-only today.

That is the right semantic model for flows like:

:Forge pr
:Forge review
open-PR mutators such as merge/close/draft/ready

But it leaves no principled branch-relative resolver for workflows that may want to recover a non-open PR for the current branch, such as:

implicit :Forge pr reopen
implicit :Forge pr ci fallback on closed or merged PRs (tracked separately in #450)

Broadening current_pr() globally would blur the difference between “current open PR” and “the latest/unique PR for this branch regardless of state”, which are not the same concept.

Proposed solution

Add a second branch-relative PR resolver instead of broadening current_pr().

The new resolver should be able to search selected PR states for the current branch context while preserving the same repo/head disambiguation semantics as the current open-PR resolver.

Examples of the policy space it should support:

open-only
closed-only
merged-only
open first, then closed/merged fallback
exact ambiguity errors when multiple PRs match

The exact public/internal shape is flexible, but it should make the distinction between “current open PR” and “current branch PR under a broader state policy” explicit.

Acceptance criteria

current_pr() remains open-PR-only
a separate resolver can resolve a unique PR for the current branch across configurable state policies
the new resolver supports the same branch-context + repo= / head= disambiguation model as the open-only resolver
no-match and ambiguity errors stay explicit and actionable
the new resolver is reusable by follow-up features such as implicit pr reopen and #450

Alternatives considered

broaden current_pr() globally to include closed/merged PRs
keep closed/merged branch-relative flows explicit-number-only forever

## Problem `current_pr()` is intentionally open-PR-only today. That is the right semantic model for flows like: - `:Forge pr` - `:Forge review` - open-PR mutators such as merge/close/draft/ready But it leaves no principled branch-relative resolver for workflows that may want to recover a non-open PR for the current branch, such as: - implicit `:Forge pr reopen` - implicit `:Forge pr ci` fallback on closed or merged PRs (tracked separately in #450) Broadening `current_pr()` globally would blur the difference between “current open PR” and “the latest/unique PR for this branch regardless of state”, which are not the same concept. ## Proposed solution Add a second branch-relative PR resolver instead of broadening `current_pr()`. The new resolver should be able to search selected PR states for the current branch context while preserving the same repo/head disambiguation semantics as the current open-PR resolver. Examples of the policy space it should support: - open-only - closed-only - merged-only - open first, then closed/merged fallback - exact ambiguity errors when multiple PRs match The exact public/internal shape is flexible, but it should make the distinction between “current open PR” and “current branch PR under a broader state policy” explicit. ## Acceptance criteria - `current_pr()` remains open-PR-only - a separate resolver can resolve a unique PR for the current branch across configurable state policies - the new resolver supports the same branch-context + `repo=` / `head=` disambiguation model as the open-only resolver - no-match and ambiguity errors stay explicit and actionable - the new resolver is reusable by follow-up features such as implicit `pr reopen` and #450 ## Alternatives considered - broaden `current_pr()` globally to include closed/merged PRs - keep closed/merged branch-relative flows explicit-number-only forever

barrettruth commented

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

Starting implementation here next.

Planned shape:

keep current_pr() open-only
add a second internal branch-relative PR resolver with explicit state policy
preserve the existing repo/head disambiguation and push-repo-first + collaboration fallback semantics
leave user-visible consumers to follow-up issues (#450, #454, #455)

This will be the resolver/backend foundation for the rest of the stack.

Starting implementation here next. Planned shape: - keep `current_pr()` open-only - add a second internal branch-relative PR resolver with explicit state policy - preserve the existing repo/head disambiguation and push-repo-first + collaboration fallback semantics - leave user-visible consumers to follow-up issues (#450, #454, #455) This will be the resolver/backend foundation for the rest of the stack.