feat: add churn-hotspot + bug-density scorer analyzer

[Daedalus-Icarus]

Summary

Adds a REES (review-enrichment service) analyzer that flags changed files which are statistical churn hotspots — high commit frequency AND a high fraction of fix/revert commits in the last 90 days. Defects cluster in such files, so the reviewer scrutinizes harder. This is heavy/historical git-log analysis the no-checkout headless claude --print reviewer cannot perform; the REES returns it as a brief block the engine splices into the review prompt.

The analyzer fetches up to 100 commits per changed file via the GitHub REST commits-by-path endpoint (GET /repos/{owner}/{repo}/commits?path=<file>&since=<90d>&per_page=100) and classifies each commit subject locally (Conventional Commit fix: / revert / bugfix / hotfix). A file is flagged when it carries ≥10 commits AND ≥30% fix/revert — the two together keep the signal high-precision (a busy file with few fixes is just active; a quiet file with two fixes is not a cluster).

Follows the established analyzer pattern end-to-end: finding type → pure analyzer (inject fetch for tests) → brief registry → public-safe render block → node:test units against dist/. Fail-safe: returns [] on any network error; one file's fetch failure does not abort the rest. Abort propagates as analyzer_aborted → degraded. Distinct from #1478 (author-track-record), which grades the submitter; this grades the file.

Closes #1513.

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 ≥97% coverage of the lines AND branches you changed (aim for 98%+ 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:

• The PR is entirely inside review-enrichment/ (a standalone package with its own tsconfig.json, node:test runner, and package.json — see review-enrichment/package.json). It is outside the worker's src/**/*.ts Codecov scope (codecov.yml measures src/** only) and outside the worker's vitest scope (vitest.config.ts include: ["test/**/*.test.ts"] is repo-root-relative and does not match review-enrichment/test/**). So the worker-side checks above (test:coverage, test:workers, build:mcp, test:mcp-pack, ui:*) are structurally unable to exercise or regress from this change — the checklist is reproduced unchecked only because the form is shared with worker PRs.
• The change IS validated by the REES package's own gate: npm test (= npm run build && node --test) inside review-enrichment/ → 70/70 pass (56 original + 14 new), tsc -p tsconfig.json → exit 0.
• On the contributor's Windows host, the worker test:ci chain has pre-existing environmental failures unrelated to this diff (Windows libuv UV_HANDLE_CLOSING assertion in mcp-cli-* subprocess tests, spawn claude ENOENT in selfhost-ai, bundled-YAML drift in gittensory-focus-manifest). Verified by stashing the diff and re-running: identical vitest totals (266 files / 4754 tests) with and without these changes. These pass on the upstream Linux CI (Node 22, provisioned toolchain).

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.

Notes

• The analyzer is fail-safe by construction (mirrors the codeowners.ts precedent): any network error or non-ok response yields []; one file's failure does not abort the rest; only an abort signal propagates as analyzer_aborted so the orchestrator marks the brief partial.
• The finding is public-safe by construction: it carries only a file path + integer commit counts + a rate. No commit messages, authors, or dates ever leave the analyzer. The render block routes the file path through safeCodeSpan (the same path-forgery guard the other render blocks use).
• Thresholds (MIN_COMMITS=10, MIN_FIX_REVERT_RATE=0.3, MAX_FILES_REPORTED=15, LOOKBACK_DAYS=90) are committed as named constants at the top of the analyzer, matching how every other analyzer exposes its tuning knobs.
• The commit-subject classifier is a flat anchored regex (/^\s*(?:fix\b|revert\b|bugfix\b|hotfix\b)/i) — linear-time, no backtracking risk on adversarial input (the same ReDoS discipline secret-log.ts documents). Verified against 14 positive/negative cases including body-only mentions and prefix-in-word false positives.

[loopover-orb]

Warning

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

⏸️ Gittensory review — held for maintainer review

5 files · 1 AI reviewer · no blockers · readiness 55/100 · CI green · dirty

⏸️ Held for maintainer review

Review summary
This adds a REES analyzer for recent per-file commit history, wires it into the brief registry, and renders a public-safe churn-hotspot section. The implementation follows the existing analyzer pattern and has reasonable fail-safe behavior for token/network issues, with aborts propagated through the orchestrator. The main review concern is precision: the first-15 scan cap can silently miss the actual hotspot files in larger PRs, and the classifier is broader than the documented Conventional Commit shape.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#1513
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:L.
Validation evidence	❌ 5/25	Cached preflight status is hold.
Open PR queue	❌ 3/10	15 open PR(s), 9 likely reviewable, 6 unlinked.
Contributor context	✅ Confirmed Gittensor contributor	EtoileAI; Gittensor profile; 56 PR(s), 4 issue(s).
Gate result	✅ Passing	No configured blocker found.

Nits — 6 non-blocking

• nit: review-enrichment/src/analyzers/churn-hotspot.ts:15 names the cap MAX_FILES_REPORTED, but scanChurnHotspots uses it as a scan cap before it knows which files are reportable, so the name and comment overstate what is happening.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:24 classifies any subject beginning with bare words like `fix tests` or `revert docs` as a defect-fix/revert signal; tighten the regex or document that broader heuristic explicitly.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:57 includes `ScanLimits.signal`, but scanChurnHotspots only reads `options.signal`, so remove the unused nested signal field or support it consistently.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:76 assumes GitHub returns an array from `resp.json()`; a defensive `Array.isArray` guard would keep malformed or rate-limit-shaped bodies from degrading this analyzer unexpectedly.
• review-enrichment/src/analyzers/churn-hotspot.ts:96 should rename `MAX_FILES_REPORTED` to something like `MAX_FILES_SCANNED`, or scan all changed files and cap only the returned findings after sorting.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Review context

• Author: EtoileAI
• 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: 56 PR(s), 4 issue(s).
• Related work: Items reference the same linked issue feat(enrichment): Churn-hotspot + bug-density scorer #1513. (issue #1513)
• Related work: Open PR work references issue feat(enrichment): Churn-hotspot + bug-density scorer #1513. (issue #1513)
• Related work: Items reference the same linked issue feat(enrichment): Typosquat & dependency-confusion detector #1501. (issue #1501, PR #1704)
• 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.
• 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.

This adds a REES analyzer for recent per-file commit history, wires it into the brief registry, and renders a public-safe churn-hotspot section. The implementation follows the existing analyzer pattern and has reasonable fail-safe behavior for token/network issues, with aborts propagated through the orchestrator. The main review concern is precision: the first-15 scan cap can silently miss the actual hotspot files in larger PRs, and the classifier is broader than the documented Conventional Commit shape.

Nits (5)

• nit: review-enrichment/src/analyzers/churn-hotspot.ts:15 names the cap MAX_FILES_REPORTED, but scanChurnHotspots uses it as a scan cap before it knows which files are reportable, so the name and comment overstate what is happening.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:24 classifies any subject beginning with bare words like `fix tests` or `revert docs` as a defect-fix/revert signal; tighten the regex or document that broader heuristic explicitly.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:57 includes `ScanLimits.signal`, but scanChurnHotspots only reads `options.signal`, so remove the unused nested signal field or support it consistently.
• nit: review-enrichment/src/analyzers/churn-hotspot.ts:76 assumes GitHub returns an array from `resp.json()`; a defensive `Array.isArray` guard would keep malformed or rate-limit-shaped bodies from degrading this analyzer unexpectedly.
• review-enrichment/src/analyzers/churn-hotspot.ts:96 should rename `MAX_FILES_REPORTED` to something like `MAX_FILES_SCANNED`, or scan all changed files and cap only the returned findings after sorting.

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

[Daedalus-Icarus]

hi, @JSONbored. I wanted to contribute to this project based on your suggestion (I've already contributed to metagraphed-ui). Could you please review my PR?

[JSONbored]

There are merge conflicts that should be fixed before resubmitting this PR - please note, the analyzer issues/PRs can be high-churn as they touch similar files, so be careful of trying to submit without proper preparation and thought/planning, since reviews are one-shot (no change requests, it's either merge or close on first review).

This branch has conflicts that must be resolved
Use the [web editor](https://github.com/JSONbored/gittensory/pull/1706/conflicts) or the command line to resolve conflicts before continuing.

review-enrichment/src/brief.ts
review-enrichment/src/render.ts
review-enrichment/src/types.ts
review-enrichment/test/enrichment.test.ts