feat(mcp): expose maintainer-lane triage via gittensory_get_maintainer_lane

[oktofeesh1]

Summary

Tracking / design issue: #1460 — this PR implements it. (Referenced, not auto-closing: a self-authored, unlabeled issue must not carry a Closes keyword here, per the linked-issue hard rule + issueDiscoveryPolicy: discouraged; the issue is closed manually with this PR cited.)

The deterministic maintainer-lane report (buildMaintainerLaneReport, src/signals/engine.ts) synthesizes a repo's lane recommendation in the context of the configured maintainer cut, queue health, config quality, and contributor-intake health — the maintainer's own-lane triage view. It already powers the repo-intelligence response but had no MCP surface, so agents/CLI couldn't pull it (it is also absent from gittensory_get_repo_context, which exposes a different subset).

This adds gittensory_get_maintainer_lane (maintainer-authenticated via the existing requireRepoAccess, advisory only), mirroring the just-merged gittensory_get_maintainer_noise (#1414) and gittensory_get_outcome_calibration (#1174): a thin load-or-compute service (src/services/maintainer-lane.ts) that loads the repo's cached signals + collision report and runs the existing builder, plus the MCP tool registration + output schema + method. Output flows through the existing redactSensitiveForMcp wrapper.

No linked issue: small, self-evident additive MCP surface over a live builder — same shape and scope as the merged maintainer-noise / outcome-calibration tools. No new REST route, no migration, no auth-policy change.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• 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 — codecov/patch: every changed line and branch in src/services/maintainer-lane.ts and the new src/mcp/server.ts lines is covered (verified via lcov, incl. both sides of the cut-configured ternary).
• 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 (0 vulnerabilities)
• New behavior has unit + integration tests: service unit test (test/unit/maintainer-lane.test.ts, incl. cut-not-configured finding + sanitizer boundary + both summary branches), the MCP call-test in test/unit/mcp-output-schemas.test.ts, and the tool-list assertion in test/integration/api.test.ts.

Safety

• No secrets, wallets, hotkeys, raw trust scores, private rankings, or private maintainer evidence are exposed — the report is the same public-safe synthesis already served in the repo-intelligence response, routed through redactSensitiveForMcp; a test asserts no wallet/hotkey/payout/reward/trust score terms leak.
• Public text stays sanitized and low-noise; no compensation/optimization implications.
• No auth/cookie/CORS/session changes — the tool reuses the existing requireRepoAccess maintainer guard (no new auth surface).
• MCP behavior is updated and tested (new tool + output schema + call-test).
• No UI changes.
• No docs/changelog changes needed.

Notes

Second tool in the maintainer-side MCP series after the merged gittensory_get_maintainer_noise (#1414); identical blessed pattern (service + tool + output schema + tests). MCP-tool-only — does not touch the deliberately-consolidated /v1/contributors/:login/* surface.

🤖 Generated with Claude Code

[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 95.49%. Comparing base (c09e348) to head (d1c62bf).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1456   +/-   ##
=======================================
  Coverage   95.48%   95.49%           
=======================================
  Files         202      203    +1     
  Lines       21920    21931   +11     
  Branches     7924     7925    +1     
=======================================
+ Hits        20931    20942   +11     
  Misses        413      413           
  Partials      576      576           

Files with missing lines	Coverage Δ
src/mcp/server.ts	95.66% <100.00%> (+0.04%)	⬆️
src/services/maintainer-lane.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.

[loopover-orb]

Warning

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

⏸️ Gittensory review — held for maintainer review

5 files · 1 AI reviewers · no blockers · readiness 55/100 · CI green · unknown

⏸️ Held for maintainer review — Touches a guarded path — held for manual review

Review summary
Clean, well-scoped additive MCP surface over the existing `buildMaintainerLaneReport` builder — the same load-then-build pattern as `maintainerNoise` and `outcomeCalibration`, with matching auth (`requireRepoAccess`), output schema, and test coverage. The service layer correctly assembles the same four DB projections the repo-intelligence path uses, delegates to the established builder, and the summary function exercises both arms of the `maintainerCutConfigured` ternary with typed (not fabricated) inputs. No schema change, no migration, no auth-policy change — the diff matches the PR description exactly.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewers, synthesized
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Review load	❌ 8/20	Readiness component derived from cached public PR metadata and labels; size label size:M.
Validation evidence	❌ 5/25	Cached preflight status is hold.
Open PR queue	❌ 3/10	22 open PR(s), 9 likely reviewable, 13 unlinked.
Contributor context	✅ Confirmed Gittensor contributor	oktofeesh1; Gittensor profile; 931 PR(s), 5 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Nits — 7 non-blocking

• src/services/maintainer-lane.ts:20 — `maintainerLaneSummary` accesses `report.contributorIntakeHealth.level` without a guard; if `buildMaintainerLaneReport` ever returns a `contributorIntakeHealth` without a `level` field (partial error path or type evolution), this throws a TypeError at the MCP response layer. Confirm `MaintainerLaneReport` guarantees the field is always present, or add `?? "unknown"` as a fallback.
• src/mcp/server.ts:614-623 — `maintainerLaneOutputSchema` uses `z.unknown()` for `lane`, `queueHealth`, `configQuality`, and `contributorIntakeHealth`. This gives MCP clients no structural hints on those nested objects. The peer `maintainerNoiseOutputSchema` likely does the same, but if those types are stable consider at least `z.record(z.string(), z.unknown())` so clients know these are objects and not primitives.
• src/services/maintainer-lane.ts:20 — `maintainerLaneSummary` ignores `report.summary` (the pre-built field from `buildMaintainerLaneReport`) and reconstructs a parallel one-liner that could diverge from the builder's own summary string over time. If the builder already emits a useful `summary`, consider returning it directly or incorporating it rather than maintaining a second string.
• src/services/maintainer-lane.ts:9 — `loadMaintainerLaneReport` is pure compute with no cache-check before hitting the DB. The PR description calls it 'load-or-compute' — if `loadMaintainerNoiseReport` or `loadRepoOutcomePatternsResponse` check a KV/D1 cache within a TTL before recomputing, this tool will be slower and inconsistent on large repos under repeated MCP calls. Align the cache strategy with the peer services or explicitly note there is none.
• src/services/maintainer-lane.ts:20 — consider returning `report.summary` directly from `maintainerLaneSummary` if `buildMaintainerLaneReport` already produces a human-readable summary, to eliminate the divergence risk: `return report.summary ?? \`Gittensory maintainer lane for ${report.repoFullName}: …\`;`
• Pull request duplicates other open work — Check for an existing pull request or issue covering this change and coordinate or consolidate before continuing.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Review context

• Author: oktofeesh1
• 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: 931 PR(s), 5 issue(s).
• Related work: Titles/paths share 9 meaningful terms. (PR #1461)
• Related work: Titles/paths share 5 meaningful terms. (PR #1448)
• Related work: Items reference the same linked issue MCP CLI: add PowerShell shell completion #1452. (issue #1452, PR #1448)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Review top overlaps.
• Add scope summary.
• Fix blocker.
• Expect slower review.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Review load = cached public PR metadata such as size labels, changed paths, and preflight status.
• Open PR queue = repo-wide review pressure; it is not a PR quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Review details

Generated from public PR metadata and the diff. Advisory only; deterministic signals remain authoritative.

Clean, well-scoped additive MCP surface over the existing `buildMaintainerLaneReport` builder — the same load-then-build pattern as `maintainerNoise` and `outcomeCalibration`, with matching auth (`requireRepoAccess`), output schema, and test coverage. The service layer correctly assembles the same four DB projections the repo-intelligence path uses, delegates to the established builder, and the summary function exercises both arms of the `maintainerCutConfigured` ternary with typed (not fabricated) inputs. No schema change, no migration, no auth-policy change — the diff matches the PR description exactly.

Nits (5)

• src/services/maintainer-lane.ts:20 — `maintainerLaneSummary` accesses `report.contributorIntakeHealth.level` without a guard; if `buildMaintainerLaneReport` ever returns a `contributorIntakeHealth` without a `level` field (partial error path or type evolution), this throws a TypeError at the MCP response layer. Confirm `MaintainerLaneReport` guarantees the field is always present, or add `?? "unknown"` as a fallback.
• src/mcp/server.ts:614-623 — `maintainerLaneOutputSchema` uses `z.unknown()` for `lane`, `queueHealth`, `configQuality`, and `contributorIntakeHealth`. This gives MCP clients no structural hints on those nested objects. The peer `maintainerNoiseOutputSchema` likely does the same, but if those types are stable consider at least `z.record(z.string(), z.unknown())` so clients know these are objects and not primitives.
• src/services/maintainer-lane.ts:20 — `maintainerLaneSummary` ignores `report.summary` (the pre-built field from `buildMaintainerLaneReport`) and reconstructs a parallel one-liner that could diverge from the builder's own summary string over time. If the builder already emits a useful `summary`, consider returning it directly or incorporating it rather than maintaining a second string.
• src/services/maintainer-lane.ts:9 — `loadMaintainerLaneReport` is pure compute with no cache-check before hitting the DB. The PR description calls it 'load-or-compute' — if `loadMaintainerNoiseReport` or `loadRepoOutcomePatternsResponse` check a KV/D1 cache within a TTL before recomputing, this tool will be slower and inconsistent on large repos under repeated MCP calls. Align the cache strategy with the peer services or explicitly note there is none.
• src/services/maintainer-lane.ts:20 — consider returning `report.summary` directly from `maintainerLaneSummary` if `buildMaintainerLaneReport` already produces a human-readable summary, to eliminate the divergence risk: `return report.summary ?? \`Gittensory maintainer lane for ${report.repoFullName}: …\`;`

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