Summary
consult --type integration pr <N> can produce a huge diff (10k+ lines) that overflows a reviewer model's context, in repos that maintain a long-lived integration branch ahead of the default branch (e.g. an ci/integration branch well ahead of main). The integration review has no way to anchor the diff on the integration branch — it always inherits whatever base the PR targets on the host.
Verified root cause (the reported "diffs against main" is one level off)
Traced through packages/codev/src/commands/consult/index.ts (source + installed dist agree):
--type integration → buildPRQuery(prId) → fetchPRDiff(prId) → the pr-diff forge concept → gh pr diff <N> (GitHub) / glab mr diff (GitLab). That's the only diff source for this path — no local git diff, no resolveDefaultBranch, no hardcoded main.gh pr diff <N> is anchored on the PR's base branch as recorded on the host (merge-base of base↔head). So the diff balloons when the PR's base is the trunk (main) while the head was branched from an integration branch (ci) that is well ahead of trunk: "changes vs main" then legitimately swallow the entire ci-over-main delta.
So the literal claim "consult diffs against main instead of ci" is a symptom: consult diffs against the PR's base, which in this workflow is main, when the meaningful comparison is against the integration branch the work actually forked from.
The buildPRQuery path already writes the diff to a temp file and points the model at the path (not inlined), so this is not an inlining problem — the diff is genuinely too large because it's anchored on the wrong branch.
Precedent (why integration is the odd one out)
The impl review type was already hardened for exactly this diff-base class:
impl now computes the diff locally as git diff origin/<baseRefName>...origin/<headRefName> (three-dot, merge-base anchored on the PR's actual base), with both refs verified up front. The integration path never received this treatment — it still leans on gh pr diff with no base control.
Prescribed fix (BUGFIX scope — design choice is specified, no plan gate needed)
Give the integration review path a diff-base override, reusing the verified machinery the impl path already has:
- Add an explicit base override for
--type integration — a --base <ref> flag (and/or read an integration-branch from .codev/config.json, e.g. consult.integrationBranch).
- When a base override is provided, compute the diff locally as
git diff origin/<base>...origin/<head> (three-dot, merge-base anchored), mirroring the impl path — verify both refs up front and fail loudly with an actionable git fetch hint if either is unresolvable (do not silently fall back to reviewing the checked-out tree — that's the cmap-3 degradation guarded against in the impl path).
- Default behavior unchanged: with no override, keep
gh pr diff <N> (the PR's host base) for back-compat.
- Reuse the existing escaped-ref / three-dot helpers from the impl path rather than duplicating; keep the on-disk diff-file handoff (don't inline).
This lets a repo with a ci-ahead-of-main topology point integration reviews at ci and get a small, correct diff, while everyone else is unaffected.
Out of scope (note as follow-ups, do not implement here): auto-detecting the integration branch without configuration; changing the default base; GitLab parity beyond passing the override through the pr-diff concept if trivial.
Repro
In a repo with an integration branch (ci) well ahead of main, with a PR whose head was branched from ci but which targets main:
consult --type integration pr <N>
→ the diff balloons to the full ci-over-main delta and overflows the reviewer model.
Acceptance
consult --type integration pr <N> --base <ci-ref> (or the configured integration branch) computes origin/<ci-ref>...origin/<head> three-dot and produces only the PR's actual change.- Unresolvable base/head refs fail loudly with a
git fetch hint — no silent degradation to the local checkout.
- No
--base / no config → behavior identical to today (gh pr diff).
- A test covers the override path (small diff) and the no-override default (unchanged).
Reported via an adopter project running a ci-ahead-of-main integration workflow.
Summary
consult --type integration pr <N>can produce a huge diff (10k+ lines) that overflows a reviewer model's context, in repos that maintain a long-lived integration branch ahead of the default branch (e.g. anci/integrationbranch well ahead ofmain). The integration review has no way to anchor the diff on the integration branch — it always inherits whatever base the PR targets on the host.Verified root cause (the reported "diffs against main" is one level off)
Traced through
packages/codev/src/commands/consult/index.ts(source + installed dist agree):--type integration→buildPRQuery(prId)→fetchPRDiff(prId)→ thepr-diffforge concept →gh pr diff <N>(GitHub) /glab mr diff(GitLab). That's the only diff source for this path — no localgit diff, noresolveDefaultBranch, no hardcodedmain.gh pr diff <N>is anchored on the PR's base branch as recorded on the host (merge-base of base↔head). So the diff balloons when the PR's base is the trunk (main) while the head was branched from an integration branch (ci) that is well ahead of trunk: "changes vs main" then legitimately swallow the entireci-over-maindelta.So the literal claim "consult diffs against main instead of ci" is a symptom: consult diffs against the PR's base, which in this workflow is
main, when the meaningful comparison is against the integration branch the work actually forked from.The buildPRQuery path already writes the diff to a temp file and points the model at the path (not inlined), so this is not an inlining problem — the diff is genuinely too large because it's anchored on the wrong branch.
Precedent (why integration is the odd one out)
The
implreview type was already hardened for exactly this diff-base class:<base>..HEADdiff semantics; over-includes when branch is behind on rebases #784 (CLOSED) — two-dot over-includeimplnow computes the diff locally asgit diff origin/<baseRefName>...origin/<headRefName>(three-dot, merge-base anchored on the PR's actual base), with both refs verified up front. Theintegrationpath never received this treatment — it still leans ongh pr diffwith no base control.Prescribed fix (BUGFIX scope — design choice is specified, no plan gate needed)
Give the
integrationreview path a diff-base override, reusing the verified machinery theimplpath already has:--type integration— a--base <ref>flag (and/or read an integration-branch from.codev/config.json, e.g.consult.integrationBranch).git diff origin/<base>...origin/<head>(three-dot, merge-base anchored), mirroring theimplpath — verify both refs up front and fail loudly with an actionablegit fetchhint if either is unresolvable (do not silently fall back to reviewing the checked-out tree — that's the cmap-3 degradation guarded against in the impl path).gh pr diff <N>(the PR's host base) for back-compat.This lets a repo with a
ci-ahead-of-maintopology point integration reviews atciand get a small, correct diff, while everyone else is unaffected.Out of scope (note as follow-ups, do not implement here): auto-detecting the integration branch without configuration; changing the default base; GitLab parity beyond passing the override through the
pr-diffconcept if trivial.Repro
In a repo with an integration branch (
ci) well ahead ofmain, with a PR whose head was branched fromcibut which targetsmain:→ the diff balloons to the full
ci-over-maindelta and overflows the reviewer model.Acceptance
consult --type integration pr <N> --base <ci-ref>(or the configured integration branch) computesorigin/<ci-ref>...origin/<head>three-dot and produces only the PR's actual change.git fetchhint — no silent degradation to the local checkout.--base/ no config → behavior identical to today (gh pr diff).Reported via an adopter project running a
ci-ahead-of-mainintegration workflow.