[BUG] /ultrareview: three back-to-back runs produced no usable findings across different diff shapes (Dedupe crash → silent empty → silent empty)

Summary

I burned all 3 free /ultrareview runs on the same codebase across three different diff shapes/sizes to find a configuration that would produce reliable findings. Result: 1 partial crash with visible findings, 2 silent empty [] returns. None of the runs produced usable structured findings. Adds to the data in #50029, #49882, #49905, #51428, #53010, #53252.

Environment

• Claude Code: latest (CLI, Windows 11)
• Repository: private, ~390 tracked files, mostly TypeScript (SPFx web parts) + Node.js (Azure Functions API)
• Git auth: healthy locally (gh auth status ✓, git push --dry-run ✓ — verified before each run)

Three runs, three shapes

| # | Branch shape | Base | Files | Lines | Result |
|---|---|---|---|---|---|
| 1 | Orphan empty base, full repo as single delta | empty-tree commit | 390 | +117,522 | Crashed at Dedupe. UI showed Setup ✓, Find (17 candidates) ✓, Verify (10 confirmed, 6 refuted) ✓ — then Review failed at Dedupe with [heartbeat] log. The 10 confirmed findings were visible in the UI but not in the task-notification payload, which returned {"error":"Review crashed before producing findings. See session logs for details."} |
| 2 | Orphan empty base, spfx/ subset only | empty-tree commit | 39 | +31,655 | Silent empty [] |
| 3 | Real merge base, last 25 commits on master | real commit (master~25) | 45 | +3,441 / −445 | Silent empty [] |

Run 3 was deliberately PR-shaped (real history, mid-size, code-heavy mix of SPFx + API + Bicep + workflows + scripts) — exactly the kind of diff /ultrareview is documented for. Still empty.

Notable behaviors

1. Run 1 actually found bugs. I captured the 10 confirmed Verify findings from the UI screenshot — they're real, specific, line-numbered (e.g. \"render-markdown allows protocol-relative URLs in shared HTML\", \"createShareLink default fallback (168h) disagrees with declared default (720h)\"). The Dedupe stage failed AFTER finding real signal. Whatever Dedupe does, it's catastrophically failing instead of just dropping duplicates.

1. The empty [] runs (2 and 3) gave no UI signal at all — no candidates, no confirmed/refuted counts, just empty. Without the screenshot from run 1 I'd have no idea if Find produced 0 candidates, or Find produced candidates and Verify rejected them all, or Dedupe collapsed everything as duplicates.

1. Misleading error categories. Run 4 (which I aborted before quota was consumed) hit \"GitHub repository access check failed — re-authorize GitHub in settings\". I verified my GitHub auth was fine (gh CLI logged in with all needed scopes; SSH key works; git push works). The actual issue was that the repo lives in a GitHub Organization (AdEx-Partners) that hasn't approved the Anthropic OAuth app at the org level. The error message blamed user auth instead of pointing at the org-policy gate.

Asks

1. Don't consume quota on silent empty [] returns. Issues #50029, #49882, and #51428 already raise this. Three runs out of three with nothing actionable feels like it should auto-credit.

1. Surface the failure stage in the task-notification payload. The UI knew Run 1 crashed at Dedupe — the payload should say so too instead of just \"Review crashed before producing findings\". Same for empty results: tell the caller whether Find/Verify/Dedupe produced 0, vs. produced N then collapsed.

1. Distinguish org-OAuth-approval errors from user-auth errors. The current message sent me down a 30-minute false trail re-checking my CLI/SSH credentials. A message like \"This repository belongs to organization X. Anthropic's OAuth app needs to be approved by an org owner: https://github.com/organizations/X/settings/oauth_application_policy\" would have unblocked me immediately.

1. Consider documenting practical scope limits. Issue #50029 found silent empty on 3,318 files / +500k lines. My Run 1 crashed at 390 files / +117k. Run 2 was empty at 39 files / +31k. Run 3 was empty at 45 files / +3.4k. There is clearly some envelope, but the docs at code.claude.com/docs/en/ultrareview specify only \"5–10 min typical\" with no scope guidance. Even rough thumb-rules would help.

Reproducibility

The three branch shapes were trivially reproducible from any non-trivial repo — happy to share more detail or capture a session if useful. The pattern feels like a service-side issue (Dedupe stage instability, plus a Find/Verify path that can return 0 candidates without explanation) rather than a user-config issue.