fix(services): report eligible:true when no linked issue was required

[shin-core]

What

deriveEligibilityPlan's eligible boolean (src/services/eligibility-plan.ts) was:

const eligible = result.linkedIssueMultiplier.eligible && branchConfirmed;

ScorePreviewInput.linkedIssueMode defaults to "none", and for that mode decideLinkedIssueMultiplier returns { status: "not_required", eligible: false }. So branchConfirmed is true but eligible = false && true = false — always false whenever no linked issue was required, the common case for any contribution that doesn't reference one.

This contradicts the plan's own publicSummary ("...not required for this contribution type") and the file's own eligibilityStatusKey helper, which already special-cases not_required correctly (line 64). Any client reading the structured boolean — the loopover_get_eligibility_plan MCP tool, the POST API route, and buildLocalBranchAnalysis — was told an otherwise-clean branch/PR is ineligible.

Fix

Apply the same special case eligibilityStatusKey already uses, to the eligible boolean:

const eligible =
  linkedIssueStatus === "not_required"
    ? branchConfirmed
    : result.linkedIssueMultiplier.eligible && branchConfirmed;

When no linked issue was required, linkedIssueMultiplier.eligible is meaningless, so a confirmed branch (eligible or not_required) is eligible. All other modes are unchanged.

Tests

• test/unit/eligibility-plan.test.ts's "no linked issue + non-required branch" test now asserts plan.eligible === true (matching its sibling tests), plus a new case for not_required + an eligible branch.
• The three consumer tests that asserted the old (buggy) eligible: false for the mode=none case — in eligibility-scenarios.test.ts, mcp-eligibility-plan.test.ts, and mcp-output-schemas.test.ts — are updated to the corrected value.

The fix is proven to fail against the pre-fix &&. linkedIssueMultiplier.eligible: false assertions in scoring.test.ts are a different field and are unaffected.

Validation

• Full eligibility-plan consumer sweep — 167/167; scoring.test.ts 88/88. npm run typecheck — exit 0. git diff --check clean.

Closes #7809

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[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 88.58%. Comparing base (ea7da0c) to head (3ac810e).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7813      +/-   ##
==========================================
  Coverage   88.57%   88.58%              
==========================================
  Files         725       84     -641     
  Lines       76409    20701   -55708     
  Branches    22762     3663   -19099     
==========================================
- Hits        67682    18338   -49344     
+ Misses       7681     2184    -5497     
+ Partials     1046      179     -867     

Flag	Coverage Δ
shard-1	97.29% <100.00%> (+41.89%)	⬆️
shard-2	97.29% <100.00%> (+44.71%)	⬆️
shard-3	75.67% <50.00%> (+28.29%)	⬆️

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

Files with missing lines	Coverage Δ
src/services/eligibility-plan.ts	97.29% <100.00%> (+0.07%)	⬆️

... and 641 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-21 13:59:13 UTC}

5 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · unknown

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a narrowly-scoped bug fix to `deriveEligibilityPlan` in src/services/eligibility-plan.ts:112-121: previously `eligible = linkedIssueMultiplier.eligible && branchConfirmed`, which was always false whenever `linkedIssueMode` was `"none"` (the common case) because `linkedIssueMultiplier.eligible` is `false` under `not_required` status. The fix mirrors the existing `not_required` special case already used by `eligibilityStatusKey` (line 64), computing `eligible` from `branchConfirmed` alone when `linkedIssueStatus === "not_required"`. I traced the change through `eligibilityStatusKey` too — with the corrected `eligible=true`, a `not_required` link + `eligible` (not `not_required`) branch now correctly falls into the `eligible` status key instead of the prior always-false `unvalidated_link` fallback, which is consistent with the stated intent. All four consumer test files (eligibility-plan.test.ts, eligibility-scenarios.test.ts, mcp-eligibility-plan.test.ts, mcp-output-schemas.test.ts) are updated to the corrected value and a new direct test case is added for the not_required+eligible-branch combination, giving good real-path coverage of both branches of the new ternary.

Nits — 2 non-blocking

• The failing 'Contributor trust — Contributor flagged for review' check is unrelated to code correctness and its cause can't be verified from what's provided here — flagging for visibility only, not as a defect.
• Confirm the PR is linked to a maintainer-tracked issue (deriveEligibilityPlan's eligible boolean is always false when no linked issue was required, contradicting its own publicSummary text #7809 is referenced throughout the diff/tests, but I can't independently verify issue eligibility/authorization from the diff alone).

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

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	#7809
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: 86 registered-repo PR(s), 46 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 86 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff applies exactly the special case requested: eligible now resolves to branchConfirmed when linkedIssueStatus is 'not_required', matching eligibilityStatusKey's semantics, and updates the previously-gapped test plus dependent consumer tests to assert eligible:true.

Review context

• Author: shin-core
• 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: 86 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.

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