feat(review): per-category inline-comment cap (#2159)

[bohdansolovie]

Summary

• Add pure inline-comments-select.ts with priority-ordered selection and an optional per-category sub-cap before the hard total inline-comment limit
• Wire review.inline_comments_per_category through the focus manifest, review prompt overrides, and inline-comment publish path
• When unset, inline selection stays byte-identical (first-seen order + total cap only); when set, blockers and higher-priority categories (security → style) survive trimming

Fixes #2159

Test plan

• inline-comments-select.test.ts — priority ordering, per-category trimming, total cap
• inline-comments.test.ts — default-off parity + capped selection through selectInlineComments
• focus-manifest.test.ts + config-templates.test.ts — parse/round-trip/docs for inline_comments_per_category
• npx tsc -p tsconfig.json --noEmit passes locally
• CI green including codecov/patch ≥99%

[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.54%. Comparing base (daef526) to head (ab1a4f6).
⚠️ Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3874   +/-   ##
=======================================
  Coverage   93.54%   93.54%           
=======================================
  Files         338      339    +1     
  Lines       33335    33368   +33     
  Branches    12192    12204   +12     
=======================================
+ Hits        31182    31215   +33     
  Misses       1528     1528           
  Partials      625      625           

Files with missing lines	Coverage Δ
src/queue/processors.ts	94.53% <100.00%> (+<0.01%)	⬆️
src/review/inline-comments-select.ts	100.00% <100.00%> (ø)
src/review/inline-comments.ts	100.00% <100.00%> (ø)
src/signals/focus-manifest.ts	99.13% <100.00%> (+<0.01%)	⬆️

🚀 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-07 05:57:35 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR extracts inline-comment selection into a new pure module (inline-comments-select.ts) and adds an optional per-category sub-cap that trims lower-priority findings (blockers first, then security→...→style) before the existing total inline-comment cap. The refactor of selectInlineComments/rightSideLinesFromPatch preserves behavior byte-identically when perCategoryCap is unset, and the manifest/prompt-override/processor wiring for review.inline_comments_per_category is threaded consistently through parse, JSON round-trip, and resolveReviewPromptOverrides. Test coverage is thorough for the new selection logic (ordering, dedup, anchor validation, zero-cap, total-cap interaction). One notable regression: the config example docs drop the finding_categories explanation without adding a description for the new field.

Nits — 5 non-blocking

• `.gittensory.yml.example:456` and `config/examples/gittensory.full.yml:469` replace the `finding_categories` description line ("When true, inline findings are tagged with a category label...") with a bare `# inline_comments_per_category: 3` line that has no explanatory sentence — restore the finding_categories description and add a one-line description for the new field, e.g. `# Cap findings per category so one category (e.g. style) can't crowd out others (requires inline_comments).`
• `src/review/inline-comments-select.ts` duplicates `rightSideLinesFromPatch` verbatim from the old `inline-comments.ts` (now just re-exported) — worth double-checking no other module still imports the old local copy directly instead of the re-export.
• `inlineFindingCategory` falls back to `classifyFindingCategory(finding)` when `finding.category` is absent; consider a short comment noting AI-provided categories are trusted as-is (no re-classification) to make the precedence explicit for future readers.
• Add the missing descriptive comment line for `inline_comments_per_category` in both yml examples to match the documentation convention used for every other `review.*` toggle (file:line noted above).
• Consider extracting the magic numeric example `3` in the yml comment to match a documented sane default, or note in the docstring why 3 was chosen as the example value.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2159
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: 371 registered-repo PR(s), 212 merged, 7 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bohdansolovie; Gittensor profile; 371 PR(s), 7 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 is configured for direct PR review.
• Public profile languages: Python, C++, JavaScript
• Official Gittensor activity: 371 PR(s), 7 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.