feat(mcp): classify supported-but-outdated MCP clients as stale

[jimcody1995]

Summary

classifyMcpClientVersion previously treated every MCP client at or above the minimum supported version (0.5.0) as current, even when below the latest recommended version (0.6.0). The type system, operator dashboard, and analytics surfaces already model a stale tier (mcpCompatibilityAdoption.staleEvents, byCompatibilityStatus), but live telemetry never populated it for auto-derived classifications.

This change completes the three-tier compatibility model:

• < 0.5.0 → incompatible
• >= 0.5.0 and < 0.6.0 → stale
• >= 0.6.0 → current

No linked issue — this is a small, self-contained gap fix discovered by tracing MCP telemetry through buildMcpClientTelemetry → classifyMcpClientVersion → analytics rollups.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• 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
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• Full gate run via npm run test:ci (includes all checks above).

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

N/A — backend telemetry classification only; no visible UI changes.

Notes

• Updated unit tests cover the new stale tier, prerelease edge cases, and MCP server telemetry header classification (0.5.0 → stale).
• Avoids overlap with open PRs touching review-enrichment, miner CLI, selfhost, gate, or MCP init-client hosts.

[loopover-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-02 23:28:40 UTC}

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

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The change correctly turns the existing MCP compatibility model into a three-tier classifier: below the minimum is incompatible, between minimum and recommended is stale, and recommended-or-newer is current. The production path is small and coherent, and the updated telemetry tests cover the changed downstream status for real header-derived events. The only notable maintainability issue is the new non-null assertion in the classifier, which is justified today by the constants but slightly brittle if the version constants ever become dynamic.

Nits — 6 non-blocking

• nit: src/services/mcp-compatibility.ts:60 uses a non-null assertion where an explicit null fallback would keep the classifier total if the recommended-version constant ever changes format.
• nit: test/unit/mcp-compatibility.test.ts:14 and test/unit/mcp-compatibility.test.ts:28 duplicate the exact 0.6.0 current assertion, so one of those can be removed or the second test can focus only on newer-than-recommended cases.
• src/services/mcp-compatibility.ts:60 could avoid `!` with `if (recommendedComparison === null) return "unknown";` to preserve the same fail-closed behavior used for the minimum comparison.
• test/unit/mcp-compatibility.test.ts:28 can drop the repeated `classifyMcpClientVersion("0.6.0")` assertion because the boundary is already covered in the main support-window test.
• 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:XS; 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: 8 registered-repo PR(s), 2 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jimcody1995; Gittensor profile; 8 PR(s), 0 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: jimcody1995
• 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: 8 PR(s), 0 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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.04%. Comparing base (6ff084d) to head (5ebf574).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2622   +/-   ##
=======================================
  Coverage   96.04%   96.04%           
=======================================
  Files         234      234           
  Lines       26209    26211    +2     
  Branches     9510     9511    +1     
=======================================
+ Hits        25173    25175    +2     
  Misses        425      425           
  Partials      611      611           

Files with missing lines	Coverage Δ
src/services/mcp-compatibility.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.