Severity: HIGH
Location: src/db/repositories.ts:8065
Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
extractLinkedPrNumbers (src/db/repositories.ts:8065-8068) scans an ISSUE's own body for any /\b(?:PR|pull request)\s+#(\d+)\b/gi match with NO verification that the referenced PR actually closes/relates to this issue -- unlike its sibling extractLinkedIssueNumbersWithOverflow, it does no keyword-adjacency-to-a-closing-verb check beyond the literal word 'PR'/'pull request'. This feeds IssueRecord.linkedPrs directly (line 6442: linkedPrs: extractLinkedPrNumbers(issue.body ?? "")). Concretely: issue #55's body says '...similar to what we saw in PR #501, unrelated feature'; PR #501 is a real, currently-open PR in the SAME repo about something else entirely, and NO PR actually links/closes issue #55. In buildContributorOpportunities (packages/loopover-engine/src/signals/engine.ts:1447), availableIssues = repoIssues.filter(issue => issue.linkedPrs.length === 0 && ...) excludes issue #55 outright because linkedPrs=[501], even though zero real PRs target it. Separately, resolveLinkedPullRequests (engine.ts:2959-2977) treats PR #501 as 'linked' to issue #55 because byNumber.has(501) is true (it's a real open PR, just for a different topic), so buildIssueQualityReport's linkedWorkCount (engine.ts:3014) becomes >0 and the issue's status is forced to 'do_not_use' (engine.ts:3046-3048), which then drives packages/loopover-engine/src/feasibility.ts:32 to return an 'avoid' verdict for a genuinely open, unclaimed issue.
Impact
Fully available, unclaimed issues silently disappear from the contributor-opportunity recommendation pipeline and get marked do_not_use/avoid in the issue-quality and feasibility-gate surfaces, purely because their body text happens to mention any other real PR number in the repo (a very common thing to do in issue discussion: 'see PR #N', 'regressed after PR #N', 'blocked on PR #N'). This directly shrinks the effective contributor backlog without any visible error -- exactly the kind of silent gap that would explain part of a backlog shortfall.
Severity: HIGH
Location:
src/db/repositories.ts:8065Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
extractLinkedPrNumbers (src/db/repositories.ts:8065-8068) scans an ISSUE's own body for any
/\b(?:PR|pull request)\s+#(\d+)\b/gimatch with NO verification that the referenced PR actually closes/relates to this issue -- unlike its sibling extractLinkedIssueNumbersWithOverflow, it does no keyword-adjacency-to-a-closing-verb check beyond the literal word 'PR'/'pull request'. This feeds IssueRecord.linkedPrs directly (line 6442:linkedPrs: extractLinkedPrNumbers(issue.body ?? "")). Concretely: issue #55's body says '...similar to what we saw in PR #501, unrelated feature'; PR #501 is a real, currently-open PR in the SAME repo about something else entirely, and NO PR actually links/closes issue #55. In buildContributorOpportunities (packages/loopover-engine/src/signals/engine.ts:1447),availableIssues = repoIssues.filter(issue => issue.linkedPrs.length === 0 && ...)excludes issue #55 outright because linkedPrs=[501], even though zero real PRs target it. Separately, resolveLinkedPullRequests (engine.ts:2959-2977) treats PR #501 as 'linked' to issue #55 becausebyNumber.has(501)is true (it's a real open PR, just for a different topic), so buildIssueQualityReport's linkedWorkCount (engine.ts:3014) becomes >0 and the issue's status is forced to 'do_not_use' (engine.ts:3046-3048), which then drives packages/loopover-engine/src/feasibility.ts:32 to return an 'avoid' verdict for a genuinely open, unclaimed issue.Impact
Fully available, unclaimed issues silently disappear from the contributor-opportunity recommendation pipeline and get marked do_not_use/avoid in the issue-quality and feasibility-gate surfaces, purely because their body text happens to mention any other real PR number in the repo (a very common thing to do in issue discussion: 'see PR #N', 'regressed after PR #N', 'blocked on PR #N'). This directly shrinks the effective contributor backlog without any visible error -- exactly the kind of silent gap that would explain part of a backlog shortfall.