fix(enrichment): treat .ruby-version as a Ruby runtime pin for EOL checks

[bohdansolovie]

Summary

The EOL analyzer and its scheduler runtime-pin gate recognized Node (.nvmrc, .node-version) and Python (.python-version) pin files but not rbenv/asdf's .ruby-version. PRs that pin Ruby that way silently skipped EOL analysis.

Scope

• extractVersionPins treats .ruby-version as product ruby (same leading-version format as the other pin files).
• isRuntimePinPath in the scheduler admits .ruby-version so the gate cannot skip a file the analyzer would parse.

Test plan

• extractVersionPins on .ruby-version with 3.2.2 → { product: "ruby", version: "3.2.2" }.
• node --test test/eol-check.test.ts — 11 passed.
• Analyzer metadata check clean.

No linked issue

Self-contained detection-coverage fix; no tracking issue. Touches eol-check.ts, scheduler.ts, and the eol test.

Made with Cursor

[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.

[gittensory-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-04 15:09:33 UTC}

3 files · 1 AI reviewer · no blockers · readiness 73/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This change correctly adds `.ruby-version` to both sides of the EOL path: `extractVersionPins` now emits Ruby pins with the existing leading-version parser, and the scheduler gate now admits the same file so the analyzer is not skipped before parsing. The added parser test exercises the real production parser path, and the scheduler predicate is aligned with the analyzer’s new supported filename. I don’t see a reachable correctness defect in the diff.

Nits — 6 non-blocking

• nit: `review-enrichment/src/analyzers/eol-check.ts:1` still describes the analyzer as parsing only `Dockerfile`, `.nvmrc`, and `go.mod`, so the file-level contract is stale after adding `.node-version`, `.python-version`, and now `.ruby-version`.
• nit: `review-enrichment/src/analyzers/eol-check.ts:55` has the same stale public helper comment, which now understates the set of version-manager files this parser accepts.
• nit: `review-enrichment/src/scheduler.ts:407` gains the `.ruby-version` gate branch, but the visible test addition only covers `extractVersionPins`; add or confirm an existing scheduler planning test that a `.ruby-version`-only PR no longer returns `no_runtime_pin`.
• Update the analyzer header and `extractVersionPins` doc comment in `review-enrichment/src/analyzers/eol-check.ts` to list version-manager pin files generically or include `.ruby-version` explicitly.
• Add a focused scheduler test around `planAnalyzers`/`inputSkipReason` showing `.ruby-version` admits the `eol` analyzer, mirroring the parser test at `review-enrichment/test/eol-check.test.ts:61`.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

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 (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 151 registered-repo PR(s), 73 merged, 10 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bohdansolovie; Gittensor profile; 151 PR(s), 10 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: bohdansolovie
• 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: 151 PR(s), 10 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• Await review-lane availability.
• 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

[gittensory-orb]

Gittensory approves — the gate is satisfied and CI is green.