fix(review): fetch truncated modified-file grounding

[JSONbored]

Motivation

• Guard against a truncated GitHub patch misclassifying a large modified file as fully covered by its single visible hunk and skipping the full-file grounding fetch.
• The previous heuristic used whole-file additions/deletions counts that can include omitted hunks, allowing a false-positive skip.

Description

• Change diffFullyCoversFile to require that the observed hunk +/- counts parsed from file.patch match the file-level additions/deletions before treating a modified file as fully covered.
• Add countObservedHunkChanges(patch) to compute observed additions and deletions from the patch and use those observed counts in the coverage math.
• Update the skip condition to use observed values instead of trusting file.additions/file.deletions when deciding to skip the fetch.
• Add regression tests in test/unit/review-grounding.test.ts covering truncated modified patches, the fetch fallback when the visible patch omits later hunks, and an ambiguous trailing-context case on the post-change side.

Testing

• Ran git diff --check (no whitespace/conflict issues) which passed.
• Ran the unit suite for the changed file with npm test -- test/unit/review-grounding.test.ts, and all tests passed.
• Ran TypeScript typecheck with tsc --noEmit, which passed.
• Ran coverage for the unit file (npm run test:coverage -- test/unit/review-grounding.test.ts), which exercised the new tests but the coverage remapping step failed with TypeError: jsTokens is not a function (coverage remapping error).
• Attempted the full local gate (npm run test:ci); the run progressed through several checks but was interrupted/failed in the longer coverage/CI stage and npm audit --audit-level=moderate returned a registry error (403), so the end-to-end gate was not fully completed in this environment.

---

Codex Task

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.63%. Comparing base (9ba80b6) to head (ecfe74b).
⚠️ Report is 6 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4087   +/-   ##
=======================================
  Coverage   93.63%   93.63%           
=======================================
  Files         384      384           
  Lines       35822    35830    +8     
  Branches    13146    13149    +3     
=======================================
+ Hits        33543    33551    +8     
  Misses       1618     1618           
  Partials      661      661           

Files with missing lines	Coverage Δ
src/review/review-grounding.ts	94.87% <100.00%> (+0.58%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-08 00:14:13 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR closes a real gap in diffFullyCoversFile: previously the function trusted file.additions/file.deletions to validate the hunk-header math even though those file-level totals can include changes from hunks GitHub omitted from the visible patch (truncation), letting a partially-shown modified file be misclassified as fully-covered-by-diff and skip the full-file grounding fetch. The fix adds countObservedHunkChanges to independently tally the +/- lines actually present in the single visible hunk and requires that count to equal file.additions/file.deletions before trusting the coverage math, correctly falling back to fetch on mismatch. The new tests (review-grounding.test.ts:299-344) exercise the mismatch-triggers-fetch path and the fetch-fallback path against fetchFullFileContents, both hitting the real production code path (not fabricated), and the diff is small, single-purpose, and self-contained with no schema/migration surface.

Nits — 5 non-blocking

• src/review/review-grounding.ts:184-188: once `observed.additions === file.additions && observed.deletions === file.deletions` passes, `observed` and `file.additions`/`file.deletions` are provably equal, so the final `return` could use `file.additions`/`file.deletions` directly instead of `observed` — purely a clarity nit, not a behavior difference.
• src/review/review-grounding.ts:190-197: `countObservedHunkChanges` does `patch.split("\n").slice(1)` allocating a full array copy; fine at this scale (single hunk, bounded patch size) but a `for (let i = 1; i < lines.length; i++)` avoids the slice if you want to micro-optimize.
• The PR description doesn't link an open issue — worth confirming this traces back to a filed bug/incident (e.g. a real truncated-patch case seen in production) rather than being self-motivated hardening, per the repo's issue-linkage expectation for contributor PRs.
• Consider also asserting the hunk-header oldCount/newCount against the actual line counts in the patch body (not just against file.additions/deletions) to close the residual edge case where a mid-hunk truncation coincidentally trims equal numbers of adds/dels, keeping observed==file totals despite real omitted content — currently unhandled but very low probability.
• test/unit/review-grounding.test.ts:352-359 (ambiguous-tail test) isn't actually exercising the new observed-vs-file-totals check (observed matches file.additions/deletions there); consider a comment noting it's regression coverage for the pre-existing DIFF_CONTEXT_LINES boundary, not the new mismatch guard, so future readers don't assume it tests the new logic.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 496 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 496 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 51 PR(s), 496 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review