fix(notifications): wire maintainer-recap's top-contributors section builder into the actual digest output

[phamngocquy]

Summary

Mirror this precedent exactly: #8372, which fixed the identical bug shape for four sibling section
builders (buildCalibrationRecapSection, buildGateOutcomesRecapSection, buildPerRepoRecapSection,
buildDriftRecapSection) — "shipped fully implemented + unit-tested but never composed into the delivered
digest." src/services/maintainer-recap-top-contributors.ts is the fifth sibling in that same family and it
fell through #8372's sweep untouched.

src/services/maintainer-recap-top-contributors.ts exports buildTopContributorsRecapSection (line 42),
described in its own header comment as: "Maintainer-recap TOP-CONTRIBUTORS section (#2244, content slice of
the #1963 recap digest)." It is fully implemented (dedup/rank/cap/public-safe-gate logic complete) and fully
unit-tested (test/unit/maintainer-recap-top-contributors.test.ts).

grep -rn "buildTopContributorsRecapSection" src/ (excluding test/) shows it is imported and called
nowhere — confirmed the same way #8372 confirmed its four siblings were dead code. formatMaintainerRecap
(src/services/maintainer-recap.ts, the function that renders a RecapReport into the Discord/Slack digest
body) now calls all four of #8372's siblings (see the #8372 comment block at src/services/maintainer-recap.ts
lines 17-22 and their unconditional call sites around lines 177-217) but never calls
buildTopContributorsRecapSection, and the emitted digest never contains a "## Top contributors" heading.

Unlike #8372's four siblings, this section needs data RecapReport does not currently carry: a per-login
tally of merged PRs across the scan window. That data source already exists and is already used for an
almost-identical per-login tally elsewhere in this codebase — mirror
buildMaintainerQualityDashboard's contributorTotals pattern
(src/services/maintainer-quality-dashboard.ts lines 93, 142-153): it iterates a repo's pull requests,
tallies a Map<string, {...}> keyed on pr.authorLogin ?? "unknown", then sorts/caps at line 156-160 — the
exact same shape buildTopContributorsRecapSection already expects as its TopContributor[] input.

The raw per-repo merged-PR data to tally already exists via
listRecentMergedPullRequests(env, fullName): Promise<RecentMergedPullRequestRecord[]>
(src/db/repositories.ts line 5090), whose records carry authorLogin and mergedAt
(src/types.ts line ~2081-2091) — no new D1 query or schema change is needed.

runMaintainerRecapJob (src/review/maintainer-recap-wire.ts, around lines 170-215) already loops
repoNames once per digest run and loads two aggregators per repo (loadGatePrecisionReport,
buildRepoOutcomeCalibration) into MaintainerRecapRepoInput[]. This is the natural place to also call
listRecentMergedPullRequests per repo (same loop, same try/catch-per-repo fail-safe pattern already there)
and fold the results into a window-filtered (mergedAt within windowDays), login-tallied contributor list.

Deliverables

• RecapReport/MaintainerRecapInputs (src/types.ts, src/services/maintainer-recap.ts) carry a
  per-login merged-PR contributor tally for the window.
• runMaintainerRecapJob (src/review/maintainer-recap-wire.ts) populates that tally from
  listRecentMergedPullRequests, window-filtered by mergedAt, with the same per-repo fail-safe
  try/catch pattern as its sibling aggregator loads in the same loop.
• formatMaintainerRecap unconditionally renders buildTopContributorsRecapSection's output as a
  ## Top contributors section, using the existing redactRecapLine/recapSectionLines helpers.
• A unit test in test/unit/maintainer-recap-format.test.ts (or maintainer-recap.test.ts) asserting a
  formatMaintainerRecap output now DOES contain ## Top contributors with the expected ranked
  login/merged lines for a report with contributor data, and DOES contain the section's empty-state
  fallback line when the window has zero contributors.
• A unit test in test/unit/maintainer-recap-wire.test.ts (or equivalent) asserting
  runMaintainerRecapJob/buildMaintainerRecap correctly aggregates merged-PR counts by login across
  multiple repos in the window, and that a per-repo listRecentMergedPullRequests failure is
  swallowed/skipped rather than aborting the whole digest (mirroring the existing
  maintainer_recap_repo_error fail-safe test coverage for the other two aggregators).

All deliverables above are required in this one PR — there is no narrower intentionally-deferred scope.

Test plan

99%+ Codecov patch coverage (branch-counted) on every changed/added line in src/**, measured unsharded via
npm run test:coverage. This is a bug fix (dead code that was supposed to be live output, same class as
#8372/#6636) — include a regression test that fails against the pre-fix behavior (asserting ## Top contributors is present in the rendered digest) and passes after the fix.

Fixes #9291

[superagent-security]

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-27 17:13:52 UTC}

7 files · 1 AI reviewer · no blockers · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR wires the previously-dead `buildTopContributorsRecapSection` into `formatMaintainerRecap`, adds a new per-login merged-PR tally sourced from `listRecentMergedPullRequests` in `maintainer-recap-wire.ts`, and threads `contributors`/`generatedAt` through `buildMaintainerRecap`/`runMaintainerRecap`. The wiring is complete end-to-end: `RecapReport.contributors` is populated, the fold/convert helpers are pure and unit-tested with real-window/out-of-window/null-login edge cases, and the section render is unconditionally composed with a proper empty-state fallback, matching the #8372 precedent this PR claims to mirror. All touched call sites (report builders, format tests, notify-discord fixture) were updated to carry the new required `contributors` field.

Nits — 4 non-blocking

• src/review/maintainer-recap-wire.ts:187 — the `24 * 60 * 60 * 1000` day-to-ms conversion duplicates a pattern likely already named elsewhere in the codebase (e.g. a MS_PER_DAY constant); consider reusing/naming it for consistency.
• The console.warn in the new per-repo merged-PR fold error path (src/review/maintainer-recap-wire.ts) duplicates the exact same warn call already present in the outer catch block a few lines below — could be factored into one shared logger call to avoid the near-duplicate log shape.
• Consider extracting `resolvedWindowDays * 24 * 60 * 60 * 1000` into a shared `daysToMs` helper if this pattern recurs elsewhere in the codebase (e.g. loadRoutingRecapSection already computes a similar sinceIso window).
• The two near-identical console.warn blocks in the per-repo loop (src/review/maintainer-recap-wire.ts) could share a single catch-and-log helper to reduce duplication.

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	#9291
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: 14 registered-repo PR(s), 7 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	phamngocquy; Gittensor profile; 14 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds a MaintainerRecapContributor/contributors field to RecapReport, wires runMaintainerRecapJob to tally listRecentMergedPullRequests per repo (window-filtered, per-repo try/catch fail-safe mirroring the existing aggregators), threads it through buildMaintainerRecap, and makes formatMaintainerRecap unconditionally call buildTopContributorsRecapSection with redactRecapLine/recapSectionLin

Review context

• Author: phamngocquy
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Java, Python, Lua, Jupyter Notebook, C, Dockerfile, JavaScript, Shell
• Official Gittensor activity: 14 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://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Decision record

• action: hold · clause: ai_review_inconclusive
• config: 3a11e758c1d06c94e4465835facf8a89ce3f3ed2b9ca3455dd868f766674aa26 · pack: oss-anti-slop · ci: passed
• record: 84179bf592d6f741a51d5e15b1a04ddcce87006b5b8b25b980a8b8b581d03408 (schema v5, head 2a34136)

_{🟩 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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.44%. Comparing base (9f56b2a) to head (2a34136).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9394      +/-   ##
==========================================
- Coverage   75.46%   75.44%   -0.02%     
==========================================
  Files         275      278       +3     
  Lines       58030    58168     +138     
  Branches     6199     6219      +20     
==========================================
+ Hits        43790    43883      +93     
- Misses      13970    14012      +42     
- Partials      270      273       +3     

Flag	Coverage Δ
backend	97.95% <100.00%> (?)

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

Files with missing lines	Coverage Δ
src/review/maintainer-recap-wire.ts	98.33% <100.00%> (ø)
src/services/maintainer-recap.ts	97.67% <100.00%> (ø)
src/types.ts	100.00% <ø> (ø)

... and 2 files with indirect coverage changes