fix(miner): correct usedDefaultGoalSpec for non-matching goal specs

[james3773]

Summary

• Fix rankCandidateIssuesWithSummary so usedDefaultGoalSpec reflects whether ranked repos actually matched a supplied goal spec, not merely whether any goal spec map was present.

Problem

When callers passed goalSpecsByRepo entries for repos that did not appear in the ranked candidate list, the summary incorrectly reported usedDefaultGoalSpec: false even though every ranked issue fell back to DEFAULT_MINER_GOAL_SPEC.

Validation

• Added regression tests for non-matching and matching goal-spec repos.
• Full CI gate on push.

Safety

• Pure local ranker change only — no network, no persistence, no secrets.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.02%. Comparing base (02af6c1) to head (275e599).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2873   +/-   ##
=======================================
  Coverage   96.02%   96.02%           
=======================================
  Files         259      259           
  Lines       28350    28350           
  Branches    10306    10306           
=======================================
  Hits        27223    27223           
  Misses        491      491           
  Partials      636      636           

🚀 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-04 03:13:19 UTC}

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

⏸️ Suggested Action - Manual Review

Review summary
The change correctly moves `usedDefaultGoalSpec` from “was any spec map supplied” to “did any ranked issue lack a matching repo spec,” and the added tests cover the reported non-matching and matching repo cases. The implementation is small and stays local to the miner ranker, with no schema or API shape changes. The only notable rough edge is that repo-key normalization is repeated inside a nested scan instead of being centralized, but that does not break behavior for the visible inputs.

Nits — 3 non-blocking

• nit: `packages/gittensory-miner/lib/opportunity-ranker.js:87` normalizes every spec repo inside the ranked-issue loop; precomputing a normalized `Set` would make the matching rule clearer and avoid repeated trim/lowercase work.
• In `packages/gittensory-miner/lib/opportunity-ranker.js:87`, replace `specRepos.some(...)` with a normalized `Set` lookup to make the repo matching semantics explicit.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

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: 906 registered-repo PR(s), 642 merged, 38 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jony376; Gittensor profile; 906 PR(s), 38 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: jony376
• 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: 906 PR(s), 38 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 approves — the gate is satisfied and CI is green.