test(mcp): cover find-opportunities searchQuery, goal-spec, and token-fallback paths

[davion-knight]

Closes #5847.

runFindOpportunities (src/mcp/find-opportunities.ts) was at 79.34% branch coverage (96/121) — the lowest of any src/mcp/** file — because test/unit/find-opportunities.test.ts only ever called it with targets. This adds the missing cases.

Test-only change — no src/** modified, so codecov/patch has nothing to gate.

New coverage

• searchQuery path + the post-search canAccessRepo re-filter (stubs the /search/issues endpoint the same way the existing tests stub per-repo fetches; asserts a returned repo is dropped by the re-filter).
• buildGoalSpecsByRepo both arms — a lane-only spec (preferredLabels arm) and a languages-only spec (wantedPaths arm), plus the no-goalSpec early return.
• appliedLane / appliedMinRankScore — asserted present when a lane/min-rank-score is supplied, omitted when absent.
• validated.ok === false exercised through runFindOpportunities (not just the validator directly).
• resolveDiscoveryGithubToken installation-token fallback — skip-uninstalled (continue), success, and the swallowed createInstallationToken failure — via runFindOpportunities with a seeded installed repo and a stubbed createInstallationToken (only that one src/github/app export is mocked; the rest stay real).

Result

find-opportunities.ts is now 100% branch and 100% statement covered (verified locally with vitest --coverage); the full find-opportunities.test.ts suite passes (22 tests).

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.30%. Comparing base (0760e1f) to head (784fc82).
⚠️ Report is 23 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6106      +/-   ##
==========================================
+ Coverage   95.24%   95.30%   +0.06%     
==========================================
  Files         595      595              
  Lines       47035    47046      +11     
  Branches    15015    15015              
==========================================
+ Hits        44797    44839      +42     
+ Misses       1493     1476      -17     
+ Partials      745      731      -14     

Flag	Coverage Δ
shard-1	43.95% <ø> (-0.06%)	⬇️
shard-2	36.63% <ø> (+<0.01%)	⬆️
shard-3	31.98% <ø> (-0.08%)	⬇️
shard-4	32.16% <ø> (-0.97%)	⬇️
shard-5	32.66% <ø> (+0.44%)	⬆️
shard-6	44.84% <ø> (+0.34%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-15 09:48:48 UTC}

1 file · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Test-only PR that adds coverage for find-opportunities.ts's searchQuery path, canAccessRepo post-search re-filter, buildGoalSpecsByRepo's two arms, appliedLane/appliedMinRankScore presence/absence, the invalid_request early-return, and the resolveDiscoveryGithubToken installation-token fallback (skip, success, swallowed failure). The mocking approach is targeted — only createInstallationToken is stubbed while the rest of src/github/app stays real — which matches the stated goal of closing a specific branch-coverage gap without touching src/**. Each new test asserts an outcome tied to a specific branch (e.g. searchItem repo removed by canAccessRepo, appliedLane omitted vs present) rather than just checking status, which is good targeted coverage work.

Nits — 4 non-blocking

• The four new tests that stub near-identical per-repo fetch sequences (AI-USAGE.md 404 / CONTRIBUTING.md content / issues list) could share a small helper to reduce duplication, per the DRY convention in this suite.
• test/unit/find-opportunities.test.ts: the inline comments explaining which branch each test exercises are helpful but verging on narrating the diff itself rather than the code — fine here given the coverage-focused PR intent, but worth trimming if it becomes a pattern across other coverage PRs.
• Consider extracting a `stubAllowedRepoFetch(owner, repo, issues)` helper for the repeated fetch-stub blocks across the new appliedLane/appliedMinRankScore/languages-only tests.
• If resolveDiscoveryGithubToken's installation-token loop ever iterates multiple installed repos, a follow-up test asserting createInstallationToken is called once per distinct installationId (not per target) would round out the fallback coverage.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5847
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 (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 142 registered-repo PR(s), 94 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 142 PR(s), 0 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal · LLM: minor

Linked issue satisfaction

Addressed
The PR adds test cases directly mapping to all five requirement groups: searchQuery path with post-search canAccessRepo re-filter, goalSpec lane/languages coverage for buildGoalSpecsByRepo, appliedLane/appliedMinRankScore presence/omission assertions, the installation-token fallback loop (skip/success/swallowed-failure), and validated.ok===false exercised through runFindOpportunities. The descript

Review context

• Author: davion-knight
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 142 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.