fix(review): scan patch-less PR files for leaked secrets

[RealDiligent]

Problem

The unconditional secret_leak hard blocker scans only + lines from buildSecretScanDiff. GitHub omits inline patch for binary/large changed files (>~1 MB), so those files produced header-only entries with no scannable body. A PR could commit a concrete credential (ghp_…, AKIA…, private key block, etc.) in a patch-less file and pass the gate.

Modified patch-less files were especially invisible: secretLeakFinding excludes (modified) headers from its scan corpus, so even filename-based detection did not run.

Root cause

buildSecretScanDiff only includes GitHub's inline patch when present. maybeAddSecretLeakFinding never recovered file body content for patch-less files, even though the grounding path already has a GitHub Contents FileFetcher (makeGithubFileFetcher).

Fix

When headSha is available at gate time:

1. For each changed file with no inline patch (excluding removed):
   • added/renamed: fetch head content and synthesize + lines for the full file.
   • modified: fetch base + head and synthesize + lines for multiset-added lines only (same "additions only" semantics as the existing diff scan).
2. Pass enriched files through the existing buildSecretScanDiff → secretLeakFinding path.

Fetch failures degrade to prior behavior (fail-safe; never destabilizes the gate).

Why this solution

• Closes a deterministic bypass of an unconditional security hard blocker.
• Reuses the existing Contents API fetcher (no new dependencies).
• Preserves "scan only additions" semantics for modified files via multiset line diff.
• Minimal, focused diff (+186 lines, mostly tests).

Testing

• addedLinesForSecretScan unit test (multiset line diff).
• enrichSecretScanFilesWithPatchFallback tests: patch-less added file with secret → secret_leak; patch-less modified with baseSha → secret_leak; modified without baseSha → no false scan of full head.
• All existing parseSlopOpinion / buildSecretScanDiff / secretLeakFinding tests unchanged.
• IDE TypeScript diagnostics clean. CI will run the full suite.

Risks

• Extra GitHub Contents API reads for patch-less files at gate time (bounded at 512 KB/file, only when patch absent). Acceptable for a security hard blocker.
• Modified files without baseSha still cannot be body-scanned (unchanged conservative behavior).

[codecov]

Codecov Report

❌ Patch coverage is 98.73418% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 96.01%. Comparing base (17fd0c7) to head (68808b6).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/queue/processors.ts	98.73%	0 Missing and 1 partial ⚠️

❌ Your patch check has failed because the patch coverage (98.73%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2821   +/-   ##
=======================================
  Coverage   96.00%   96.01%           
=======================================
  Files         258      258           
  Lines       28251    28329   +78     
  Branches    10275    10303   +28     
=======================================
+ Hits        27123    27200   +77     
  Misses        491      491           
- Partials      637      638    +1     

Files with missing lines	Coverage Δ
src/queue/processors.ts	92.84% <98.73%> (+0.19%)	⬆️

🚀 New features to boost your workflow:

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

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - fixes required

_{Review updated: 2026-07-04 01:35:28 UTC}

3 files · 1 AI reviewer · no blockers · readiness 73/100 · CI failing · unstable

🛑 Suggested Action - Fix Blockers

• Touches a guarded path — held for manual review

Review summary
The change correctly routes patch-less PR files through a bounded Contents API fallback before the existing additions-only secret scan, and it fails closed with a `secret_leak` finding when eligible content cannot be fully recovered. The multiset diff preserves the existing modified-file semantics and the tests cover added, modified, renamed, fetch failure, size cap, and wiring paths. The most notable maintainability concern is that the gate wiring creates the fetcher before checking whether enrichment has any eligible patch-less files, but that is not a correctness break.

Nits — 7 non-blocking

• nit: `src/queue/processors.ts:6229` calls `makeGithubFileFetcher` whenever `args.headSha` is any non-empty string, even when every file already has an inline patch or is otherwise ineligible; filter for eligible patch-less files first so a token/fetcher setup failure cannot produce noisy logging on a path that needs no fallback.
• nit: `src/queue/processors.ts:6229` checks the raw `args.headSha` while `enrichSecretScanFilesWithPatchFallback` trims it; use `args.headSha?.trim()` in the caller too so whitespace-only input skips the fetcher consistently.
• nit: `src/queue/processors.ts:5557` puts every incomplete path into one finding detail, which can get very large on broad PRs; cap the displayed list and include a remaining count to keep advisory output bounded.
• In `maybeAddSecretLeakFinding`, compute whether any file has no inline patch and is eligible under `shouldAttemptPatchLessSecretScan` before constructing the GitHub file fetcher.
• Normalize `headSha` once in `maybeAddSecretLeakFinding` and pass the trimmed value down to `enrichSecretScanFilesWithPatchFallback`.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

CI checks failing

• codecov/patch — 98.73% of diff hit (target 99.00%)

Signal	Result	Evidence
Code review	✅ No 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	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 109 registered-repo PR(s), 8 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 109 PR(s), 0 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 109 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• 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

[loopover-orb]

Gittensory is closing this pull request on the maintainer's behalf (CI is failing (codecov/patch)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs are re-reviewed automatically, so an inaccurate close may be reopened, but that does not guarantee it can merge (e.g. if conflicts or failing CI remain).