fix(signals): dedupe overlapping label sources in contributor dominantLabels

[galuis116]

Summary

Both contributor-profile builders computed registeredRepoActivity.dominantLabels by concatenating labels from two overlapping views of the same activity and frequency-ranking the combined list with topItems(..., 8):

• cached authored PR/issue records, and
• the contributor's pre-aggregated repoStats.dominantLabels (built during backfill) for the same repos.

So for any repo the contributor has both cached records and a stat row in — the normal case — that repo's labels were counted twice. Every other field in the same function already reconciles these two sources as overlapping: reposTouched uses new Set([...]) (dedupe), unlinkedOpenPullRequests uses Math.max(...), statPullRequests/statMergedPullRequests use the stats only. dominantLabels was the lone outlier that summed them. Closes #417.

This is scoring, not just display: dominantLabels becomes labelHistory (decision-pack.ts, buildContributorOpportunities) and drives labelFit (+5 per matching label in opportunity scores and repo-decision reasoning). Because labelHistory is the top-8 set, double-counting shifts which labels survive the cutoff — a low-frequency repo-dominant label can displace a higher-effort single-source label, perturbing the rankings surfaced to miners.

Scope

• src/signals/engine.ts:
  • buildContributorProfile — only fold repoStats.dominantLabels for repos that have no cached authored records (cachedLabelRepos guard).
  • buildGittensorContributorProfile — only fold repoStats.dominantLabels for repos not present in snapshot.repositories.
  • Both preserve complementary coverage (stats still fill in repos the cached/snapshot data does not have) while removing the overlap double-count, consistent with how the sibling fields reconcile the same sources.
• test/unit/signals-coverage.test.ts — fail-on-revert: a stat-only-label for a repo that already has cached records must not appear in dominantLabels (old code included it), while an uncached-label for a repo with no cached records still contributes.

Validation

• npx tsc --noEmit — clean.
• npx vitest run (full suite) — 1132 passed, 1 skipped; no other assertions affected.
• Branch coverage 97.04% (above the 97% gate); engine.ts 98.05% branch (the new filter branches in both builders are covered).

Safety

• Behavior is unchanged for contributors whose cached records and repoStats cover disjoint repos (the common-repo overlap is exactly what was being double-counted). No public schema/API surface change; dominantLabels keeps its type and topItems(..., 8) shape.
• Purely a deduplication of an already-computed overlap; stat-derived labels for repos without cached records are still included.

Notes

The fix mirrors the existing reposTouched (dedupe) / unlinkedOpenPullRequests (max) treatment of the same two sources, so the whole function now reconciles cached records and repoStats consistently.

[gittensory]

Important

Gittensory found maintainer review notes

Scoped related-work signals were found for this PR. They are advisory unless the gate reports a blocker.

Signal	Status	Action
Linked issue	#417	Ready for issue-scoped review.
Duplicate risk	2 scoped related-work signals	Advisory review only.
Review burden	High	Estimated from public PR metadata.
Repo queue	Critical	Repo-wide context only; this does not block the gate.
Contributor context	Confirmed Gittensor contributor	Official public API confirmed this GitHub user.
Gate result	Passing	No configured blocker found.

Review context

• Author: galuis116
• 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: 85 PR(s), 85 issue(s).
• PR-specific overlap: Items reference the same linked issue [Bug]: Contributor profile dominantLabels double-counts labels by folding repoStats dominant labels into the same-activity raw labels, inconsistent with every sibling aggregation — biasing labelFit scoring #417. (issue [Bug]: Contributor profile dominantLabels double-counts labels by folding repoStats dominant labels into the same-activity raw labels, inconsistent with every sibling aggregation — biasing labelFit scoring #417)
• PR-specific overlap: Open PR work references issue [Bug]: Contributor profile dominantLabels double-counts labels by folding repoStats dominant labels into the same-activity raw labels, inconsistent with every sibling aggregation — biasing labelFit scoring #417. (issue [Bug]: Contributor profile dominantLabels double-counts labels by folding repoStats dominant labels into the same-activity raw labels, inconsistent with every sibling aggregation — biasing labelFit scoring #417)

Maintainer notes

• Possible duplicate or overlapping work: 2 related open work cluster(s) were detected.

Contributor next steps

• Review the scoped related-work signal before deep review; it is not a merge blocker by itself.
• Check active issues and PRs before submitting.

---

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers. Learn more about Gittensor contribution workflows.