feat(scoring): surface branch eligibility in the score breakdown

[andriypolanski]

Summary

explainScoreBreakdown explains linked-issue multiplier eligibility via issueMultiplierBreakdown, but branch eligibility — a separate upstream gate modeled in src/scoring/preview.ts (BranchEligibilityResult, #90 / #178) — can block the standard linked-issue multiplier even when issue metadata looks plausible. Today that shows up only in blockedBy, gateDeltas, and free-text recommendation.actions, not as a dedicated component miners can scan in gittensory_explain_score_breakdown.

Contributors targeting issue-solving PRs on protected default branches routinely hit invisible branch/base mismatches; this closes the last major eligibility dimension missing from the breakdown surface (after #1453 open-issue, #1801 merged-history, #1874 issue-discovery, #1877 time-decay).

What this adds

A branchEligibilityBreakdown component keyed off preview.branchEligibility:

• neutral when branch eligibility is not_required (no linked-issue mode that requires branch proof).
• full when required and status is eligible with fresh, verified evidence.
• blocked when status is ineligible — lever mirrors existing recommendation copy (use an eligible branch or drop linked-issue assumptions).
• reduced when status is unknown, evidence is missing, metadata is stale, or source is user_supplied — each branch gets distinct summary/lever text matching branchEligibilityFailureReason semantics in preview.ts.

Purely additive explanation; no scoring behavior change.

Files touched (estimated)

File	Change
src/services/score-breakdown.ts	Add branchEligibilityBreakdown, wire into explainScoreBreakdown
test/unit/score-breakdown.test.ts	Cover not-required, eligible, ineligible, unknown/missing/stale/user-supplied branches

~70–100 lines total (size S).

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage — aim for 100% statements/branches on changed lines in src/services/score-breakdown.ts
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate

Targeted test run:

npx vitest run test/unit/score-breakdown.test.ts --coverage --coverage.include='src/services/score-breakdown.ts'

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed (include forbidden-term assertion in tests).
• Summaries/levers run through sanitizePublicComment; do not leak raw branch names that contain forbidden terms (use existing sanitizer boundaries).
• No auth, cookie, CORS, GitHub App, Cloudflare, or session changes.
• No UI changes.
• No docs/changelog changes.

[gittensory-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-06-30 22:24:26 UTC}

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

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The change adds a dedicated branch eligibility component to the score breakdown and wires it into the component list without changing scoring behavior. The implementation maps not-required, verified eligible, ineligible, and uncertain metadata states into the same band/lever structure as the existing multiplier explanations, and the visible tests cover the main state matrix plus highest-leverage ordering. I do not see a reachable correctness break in the provided post-change file; the main maintainability cost is the duplicated user-supplied branch in the nested summary expression.

Nits — 6 non-blocking

• nit: src/services/score-breakdown.ts:243 repeats the same user-supplied summary in two branches, which makes the nested ternary harder to audit than the neighboring breakdown helpers.
• nit: test/unit/score-breakdown.test.ts:123 packs many branch eligibility states into one large test, so a failure will require extra scanning to identify the broken case.
• src/services/score-breakdown.ts:235 could be clearer as ordered early returns or a small helper for the reduced-state summary, with the single user-supplied message shared once.
• test/unit/score-breakdown.test.ts:123 should consider splitting the neutral/full/blocked/reduced cases into table-driven rows so each branch eligibility state has a focused assertion label.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

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 (size label size:M; no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR; address the blocker before review.
Contributor workload	✅ 10/10	Author activity: 96 registered-repo PR(s), 66 merged, 5 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	andriypolanski; Gittensor profile; 96 PR(s), 5 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: andriypolanski
• 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: 96 PR(s), 5 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• Fix the blocker.
• Triage stale or unlinked PRs.
• 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

[JSONbored]

Moving forward, please fix your PR titles to follow this repos conventional commit naming scheme.

[andriypolanski]

Moving forward, please fix your PR titles to follow this repos conventional commit naming scheme.

Hi, @JSONbored
I just fixed pr title, could you please review again?

[JSONbored]

Review mentions a small blocker:

the main maintainability cost is the duplicated user-supplied branch in the nested summary expression.