feat(miner): wire ContributionProfile eligibility filtering into discover

[luciferlive112116]

Summary

The final link of the AMS contribution-profile epic (#6793) — it closes the loop. loopover-miner discover now filters candidate issues through each target repo's ContributionProfile (the schema/#6795, extraction/#6796, cache/#6797 I landed earlier) before ranking and enqueueing, so it no longer surfaces work a repo's own conventions would reject. Depends on #6796 + #6797, both merged.

The decision lives in a pure module

filterCandidatesByProfiles (contribution-profile-filter.js) partitions candidates into kept + excluded, each excluded entry carrying a reason. Keeping the decision pure and isolated means it's a new file with 100% coverage and zero contention; discover-cli.js only resolves the profiles and renders the result.

Reasons: exclusion_label, missing_eligibility_label, conflicting_signals. Matching is against the candidate's own label names, using the eligibility/exclusion label names the profile recorded in provenance (case-insensitive).

The two behaviors the issue calls out

Safe default — the load-bearing rule. Filtering activates for a repo only when its profile has an explicit eligibility signal (eligibilityLabels.confidence === "explicit"). A repo with no profile, or a low-confidence/empty one — one whose conventions AMS simply couldn't read — keeps every candidate. A weak profile can never silently skip real, eligible work. Second layer: the default resolver does no profile work at all without a github token (it can't read a taxonomy reliably unauthenticated), so the unauthenticated CLI path — and every existing test — is byte-identical to before.

Conflicting signals resolve conservatively. An issue carrying both an eligibility and an exclusion label is excluded (conflicting_signals) — a maintainer marking it off-limits outranks its also being help-wanted. Documented and tested.

Scope note — assignees

The issue lists "excluded assignee" as one fail reason, but the candidate objects flowing through discover carry label names and not assignees (opportunity-fanout.js's normalizeIssue drops them), and ContributionAssigneeRuntimeCheck is deliberately a runtime concern, not a profile field. Threading assignees through the fan-out is a genuine second shared-file change, so this PR scopes filtering to labels — the primary eligibility signal the #6794 inventory found — and documents assignee-exclusion as a follow-up rather than half-wiring it. Flagging that honestly rather than silently dropping a listed requirement.

Tests

The three cases the issue requires, plus the safe-default and both output surfaces:

• A repo whose profile correctly excludes maintainer-only-equivalent issues (only the eligible one is enqueued).
• A low-confidence/empty profile where nothing is filtered.
• Conflicting eligibility+exclusion on one issue → excluded, conflicting_signals.
• Plus: the excluded set in --json and plain-text output, the same filter on --dry-run (nothing enqueued), and the default resolver's no-token/cache-hit/cache-miss paths.

Validation

• Patch coverage 100%, measured on both changed gated files: contribution-profile-filter.js (34/34 statements, 22/22 branches) and the changed lines in discover-cli.js — zero uncovered, zero partial.
• 53/53 in the discover suite (45 existing unchanged + 8 new) and 12/12 in the filter suite. Existing discover tests pass untouched because the no-token default filters nothing.
• npm run typecheck — 0 (after the standard engine rebuild; the new .d.ts declares the option + export). eslint — 0/0 · prettier --check — clean · node --check (added to the miner build list) — ok · rebased on latest main.

One pre-existing failure, not mine: miner-status.test.ts's "resolves the state dir…" fails identically on clean main (Windows \ vs /); it's not in this PR's diff and passes in CI's Linux.

Scope & safety

• Eight files: the filter module + its .d.ts, the discover-cli.js wiring + its .d.ts, the build-list entry, the design-doc update, and two test files. Wanted paths (packages/, test/).
• No hot files: no src/api/routes.ts, src/mcp/server.ts, the MCP CLI bin, or the stdio-tool count pin.
• Behavior-preserving without a token / without a trustworthy profile; read-only filtering, no new write path. No secrets; no changelog/site//CNAME/lovable changes.

Closes #6798

[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 93.73%. Comparing base (bd4c172) to head (324490b).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7024   +/-   ##
=======================================
  Coverage   93.73%   93.73%           
=======================================
  Files         690      691    +1     
  Lines       68591    68654   +63     
  Branches    18748    18748           
=======================================
+ Hits        64293    64356   +63     
  Misses       3302     3302           
  Partials      996      996           

Flag	Coverage Δ
shard-1	43.37% <0.00%> (-0.47%)	⬇️
shard-2	36.86% <50.76%> (+0.02%)	⬆️
shard-3	33.16% <100.00%> (+0.13%)	⬆️
shard-4	34.41% <0.00%> (+0.44%)	⬆️
shard-5	31.64% <0.00%> (-0.63%)	⬇️
shard-6	46.05% <1.53%> (+0.25%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
.../loopover-miner/lib/contribution-profile-filter.js	100.00% <100.00%> (ø)
packages/loopover-miner/lib/discover-cli.js	100.00% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 18:45:43 UTC}

8 files · 1 AI reviewer · no blockers · readiness 95/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The AI review returned non-blocking notes for this change but did not include a separate narrative summary. Review the nits below before deciding this PR.

Nits — 5 non-blocking

• packages/loopover-miner/lib/contribution-profile-filter.js:50 — the exclusion/eligibility/missing branch chain is 4 sequential ifs at depth 5; a small early-return refactor (compute `hasEligibility`/`hasExclusion` then a single reason lookup) would read more clearly.
• discover-cli.js repeats `[...new Set(fanOut.issues.map(i => i.repoFullName))]` plus the resolve+filter dance identically in the dry-run and full-run branches — worth extracting a small `resolveAndFilter(fanOut, ctx)` helper to avoid drift between the two copies.
• The `AMS contribution-profile: wire eligibility filtering into discover #6798` issue-number references sprinkled through comments (discover-cli.js:158 etc.) are fine as traceability but not load-bearing; no action needed.
• docs/contribution-profile.md correctly documents the assignee-exclusion scope gap as a follow-up rather than silently dropping it — good practice, just flagging it's still open.
• Consider extracting the repeated `repoFullNames → resolveProfiles → filterCandidatesByProfiles` sequence (discover-cli.js, dry-run and full-run branches) into one helper to keep the two paths from drifting.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6798
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: 172 registered-repo PR(s), 103 merged, 27 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	luciferlive112116; Gittensor profile; 172 PR(s), 27 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: luciferlive112116
• 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: 172 PR(s), 27 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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://loopover.ai/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