fix(review): stop silently dropping blockers/nits past 12 in the unified comment

[shin-core]

What & why

The unified review comment's dedupeLines helper defaulted to a hard cap of 12, and both the blockers and nits lists were passed through it before the disclosed truncation stage (truncateFindingsForDisplay). That produced three user-visible defects:

1. Silent overflow. A review with 13+ blockers (or nits) had items 13+ dropped with no "+N more" footer — the overflow looked like it simply didn't exist.
2. Incomplete AI-context block. The "📋 Copy for AI agents" block promises every blocker, but it was built from the already-capped list, so a contributor's agent never saw findings 13+.
3. Inflated counts. The changedFiles status chip and the code-review signal row counted the raw, un-deduped input.blockers, so a case-insensitive duplicate could make the chip claim a higher number (e.g. `3 blockers`) than the rendered "Why this is blocked" section actually lists.

The fix

• dedupeLines is now un-capped by default (cap = Number.POSITIVE_INFINITY); callers that want a genuine hard cap (e.g. actionReasonBullets' dedupeLines(reasons, 8)) still pass one explicitly.
• The 12-item display cap now lives at the truncateFindingsForDisplay call site (?? DEFAULT_FINDINGS_DISPLAY_CAP) — the disclosed-truncation stage — so an unset maxFindingsCaps still caps the human list, but now with a real "+N more" footer instead of silent loss, while buildAiContextBlock receives the full deduped set.
• The status chip's and the code-review row's blocker counts derive from the deduped set (dedupeLines(input.blockers ?? []).length), so duplicates can no longer inflate them past what the section renders.

Behavior is unchanged when a list already fits within the cap (verified byte-identical), and explicit maxFindingsCaps values still win.

Tests

Added a #9670 sub-suite to test/unit/unified-comment.test.ts:

• 13 blockers, caps unset → human list stops at the 12th with a +1 more footer, while the AI-context block lists all 13.
• 13 nits, caps unset → list stops at the 12th with a +1 more footer and the section label counts all 13.
• Case-insensitive duplicate blockers → chip shows the deduped count (`2 blockers`, never `3 blockers`).

Each new test fails against the un-patched source (regression-proven), and the whole renderUnifiedReviewComment diff is at 100% line and branch coverage locally.

Validation

• npm run test:ci green (unified-comment + full suite).
• git diff --check clean; no generated-artifact, schema, wrangler, or migration changes — nothing to regenerate.
• Diff is two files: src/review/unified-comment.ts + its unit test.

Closes #9670

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-29 07:27:54 UTC}

2 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This PR moves the display-truncation cap (default 12) from dedupeLines to the truncateFindingsForDisplay call site, so overflow beyond 12 blockers/nits is now disclosed via a '+N more' footer instead of silently vanishing, and the AI-context block plus the status-chip/code-review-row counts now derive from the full deduped set rather than the pre-truncated one. The trace checks out: dedupeLines' cap default is now Infinity, DEFAULT_FINDINGS_DISPLAY_CAP=12 is applied only at the two truncateFindingsForDisplay call sites, and the new #9670 test suite exercises the 13th-item overflow, footer, and deduped chip count end-to-end. This closes linked issue #9670 and is a narrow, well-targeted correctness fix to the review-comment rendering path.

Nits — 3 non-blocking

• src/review/unified-comment.ts:497 in the new test uses a bare `13` for the overflow count — a named constant (e.g. `DEFAULT_FINDINGS_DISPLAY_CAP + 1`) would make the intent self-documenting and resilient to a future cap change.
• The 'Contributor trust' CI check failed with no detail provided; per the base-branch-behind note this is plausibly unrelated to this diff's content, but confirm it's not a genuine trust-gate issue before merging.
• Consider importing `DEFAULT_FINDINGS_DISPLAY_CAP` in the test file and using it to compute the overflow count instead of the hardcoded `13`, so the test stays correct if the default cap value changes.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9670
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	❌ 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: 38 registered-repo PR(s), 26 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 38 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff uncaps dedupeLines by default, moves the 12-item cap to the disclosed truncateFindingsForDisplay call for both blockers and nits, derives blockerCount for statusChips and codeReviewRow from the deduped set, and adds named tests covering the 13-item overflow with footer, AI-context completeness, and duplicate-driven chip count divergence.

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is registered but has no active allocation in the current snapshot.
• Public profile languages: not available
• Official Gittensor activity: 38 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Await review-lane availability.
• Then work through the remaining 2 steps in the Signals table above.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Decision record

• action: hold · clause: success
• config: aa97b1f1ebc65a0236589a1c3880182415815f71e8001229937e793dbf0096c4 · pack: oss-anti-slop · ci: passed
• record: d0477cd73842fd75ba613db5d71fd620135606b8a783c9dbaece861ce997a636 (schema v5, head 8ed4f57)

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[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 76.68%. Comparing base (e95afc0) to head (8ed4f57).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #9766       +/-   ##
===========================================
- Coverage   90.27%   76.68%   -13.59%     
===========================================
  Files         904      283      -621     
  Lines      113213    59689    -53524     
  Branches    26859     8593    -18266     
===========================================
- Hits       102202    45773    -56429     
- Misses       9680    13630     +3950     
+ Partials     1331      286     -1045     

Flag	Coverage Δ
backend	98.14% <100.00%> (+2.60%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/review/unified-comment.ts	98.14% <100.00%> (-0.37%)	⬇️

... and 755 files with indirect coverage changes

[loopover-orb]

Held for manual review: the gate and required CI are green, but GitHub reports this pull request's mergeable state as unstable because a non-required check or status is not passing, so LoopOver will not auto-merge. A maintainer can resolve the failing check or review and merge manually. This is an automated maintenance action.