fix: fetch closed PRs in reconcile so merged-PR issue closing works

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.

[joryirving]

Summary

reconcile/route.ts documents purpose #1 as "Detects merged PRs that fix issues → closes them on GitHub", and its comment says it fetches "all PRs (open and merged)." But it only calls fetchPullRequests(), which hits ?state=open. Open PRs always have merged_at = null, so:

• the if (pr.merged_at) branch never fires → mergedPrsMap is always empty
• → mergedFixingIssues is always empty
• → reconcileIssue(..., mergedFixingIssues, ...) never emits a close_issue action

This is the only code path that closes issues on PR merge (close_issue → closeIssue), so it has been silently dead. (Reported by @joryirving.)

Fix

• Add fetchClosedPullRequests() — ?state=closed&sort=updated&direction=desc, bounded to the most recently updated PRs so old repos don't pull unbounded history.
• Reconcile now fetches open + closed PRs in parallel and feeds both in; merged PRs come from the closed set.
• fetchPullRequests() keeps its open-only semantics — the automation/scheduled sync routes rely on it for current board state, so its behavior is intentionally unchanged.

⚠️ Behavior change to be aware of

This revives a dormant feature. After deploy, the next reconcile run will, for any open issue whose merged PR's branch name encodes the issue number (issue-123, issue_123, issue/123), post a close_issue to GitHub. If issues have been piling up open because this never worked, expect a batch of auto-closes on the first run. That's the intended behavior, but flagging it since the volume could be surprising the first time.

Test plan

• tsc --noEmit clean
• vitest run — 1048 pass (merged-close logic is covered in issue-reconciliation.test.ts at the reconcileIssue level, which takes the merged map directly)
• eslint clean
• Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: Approve

This PR correctly fixes a long-standing bug where merged PRs that should auto-close their fixing issues were silently never detected.

Change-by-Change Findings

src/lib/github.ts — Added fetchClosedPullRequests():

• New function fetches PRs with ?state=closed&sort=updated&direction=desc
• Bounded to 100 items by default via maxItems param passed to fetchPaginated
• Proper JSDoc documents the rationale: open-only fetch never returns merged_at, so merged PRs require a separate closed-state query
• Consistent with existing fetchPullRequests() pattern and reuses fetchPaginated<GithubPR>

src/app/api/issues/reconcile/route.ts — Updated reconcile logic:

• Added fetchClosedPullRequests to imports
• Replaced single fetchPullRequests() call with Promise.all([open, closed]) for parallel fetching
• Combines results: const allPrs = [...openPrsList, ...closedPrsList]
• Updated comment explains why both fetches are needed and that open-only never carries merged_at

Root Cause Correctly Addressed

The PR body accurately diagnoses the bug: fetchPullRequests() hits ?state=open, so merged_at is always null. The if (pr.merged_at) branch never fires → mergedPrsMap is always empty → close_issue actions never emit. The fix adds the missing state=closed query so merged PRs are actually retrieved.

Behavior Change Flagged Appropriately

The PR appropriately warns that this revives a dormant feature. After deploy, the next reconcile run will auto-close open issues whose merged PR branch names encode the issue number (issue-123, issue_123, issue/123). This could produce a batch of auto-closes on first run — the PR calls this out explicitly so operators are not surprised.

Standards Compliance

✅ Follows TypeScript patterns (fetchPaginated generic reuse, proper type inference from allPrs[number])
✅ Error handling not needed (GitHub API failures propagate naturally)
✅ No secrets exposed
✅ Bounded fetch prevents unbounded history pull on large repos

Linked Issue Fit

No linked issues. The PR body serves as both description and self-contained bug report.

Evidence Provider Findings

None configured.

Tool Harness Findings

None configured.

Unknowns / Needs Verification

• The manual test plan item ("Trigger reconcile against a repo with a merged issue-NNN PR and confirm the open issue is closed") is unchecked. While unit tests at the reconcileIssue level cover the merged map logic, a full integration test against a live repo with merged PRs would provide end-to-end confidence. This is flagged in the PR and is acceptable given the test coverage at the reconciliation logic level.