feat(mcp): register a gittensory://slop-rules resource enumerating deterministic slop findings

[jeffrey701]

What

gittensory_check_slop_risk returns per-call findings, but there's no discoverable catalog of the deterministic slop rule codes, their point weights, and the score bands the detector emits. This adds a read-only gittensory://slop-rules MCP resource (application/json) so an agent can pre-plan against the detector without triggering a scoring call — mirroring the existing gittensory://finding-taxonomy and gittensory://enrichment-analyzers resources.

Codes and weights are read straight off the SLOP_WEIGHTS and ISSUE_SLOP_WEIGHTS as const maps in src/signals/slop.ts (single source of truth — no duplicated literals; adding a signal there surfaces it here automatically). The band names are typed as SlopBand, so a renamed or removed band fails the build here rather than drifting silently.

Deliverables

• Register a gittensory://slop-rules resource in src/mcp/server.ts (application/json) returning the rule/band catalog.
• Source the codes/weights from the existing exported consts (SLOP_WEIGHTS, ISSUE_SLOP_WEIGHTS) — no duplicated literals.
• Tests: the builder projects every code + weight from both consts; the MCP resource read returns every rule code and all four score bands.

Closes #2237

[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 93.77%. Comparing base (32c9160) to head (c6944fd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4239   +/-   ##
=======================================
  Coverage   93.76%   93.77%           
=======================================
  Files         392      393    +1     
  Lines       36576    36583    +7     
  Branches    13392    13392           
=======================================
+ Hits        34297    34304    +7     
  Misses       1623     1623           
  Partials      656      656           

Files with missing lines	Coverage Δ
src/mcp/server.ts	95.03% <100.00%> (+0.01%)	⬆️
src/review/slop-rules-taxonomy.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]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-08 17:53:49 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This adds a read-only `gittensory:​//slop-rules` MCP resource that projects the existing `SLOP_WEIGHTS`/`ISSUE_SLOP_WEIGHTS` const maps and a static band-range table into JSON, mirroring the established `finding-taxonomy`/`enrichment-analyzers` resource pattern in src/mcp/server.ts. The builder and MCP registration both read data straight from the single-source-of-truth maps in src/signals/slop.ts (no duplicated literals for codes/weights), and the tests exercise the real function and real MCP client/server round-trip rather than fabricating payloads. The PR is narrow, closes #2237, and follows the existing resource-registration convention closely.

Nits — 4 non-blocking

• src/review/slop-rules-taxonomy.ts: the `SLOP_BANDS` range strings (e.g. "1-30", "31-59") are hand-typed and only the band *names* are type-checked against `SlopBand` — if `slopBandFor`'s actual cut-points in src/signals/slop.ts ever change, this document's ranges will silently drift out of sync since nothing derives them from the real thresholds; consider exporting the cut-points from slop.ts (or a comment pointing at the exact line) so a change there forces a review here too.
• The block comment atop `buildSlopRulesDocument` in slop-rules-taxonomy.ts is quite long for a one-function file — consider trimming it to the non-obvious part (why it's derived rather than duplicated) per the repo's comment-brevity convention.
• Consider a single test asserting `doc.bands` fully matches a hardcoded expected array (band+range pairs) rather than only checking band names, to catch accidental range-string typos.
• If feasible, have `SLOP_BANDS`' ranges import/derive from the same constants `slopBandFor` uses internally, closing the drift risk noted above.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2237
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: 107 registered-repo PR(s), 41 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 107 PR(s), 0 issue(s).
Gate result	✅ Passing	No configured blocker found.

Linked issue satisfaction

Addressed
The PR registers a gittensory:​//slop-rules MCP resource in src/mcp/server.ts that returns codes, weights, and the four score bands sourced directly from SLOP_WEIGHTS/ISSUE_SLOP_WEIGHTS in src/signals/slop.ts (no duplicated literals), and adds tests verifying the resource is discoverable and returns every rule code and all bands.

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, Clojure, JavaScript
• Official Gittensor activity: 107 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.

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

[loopover-orb]

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