fix(cursor-review): collapse catalog-drift review-me list to one row per family (BE-6911) - #147
fix(cursor-review): collapse catalog-drift review-me list to one row per family (BE-6911)#147mattmillerai wants to merge 1 commit into
Conversation
…per family (BE-6911) The weekly catalog-drift check listed 178 unpinned same-lab ids and then head-truncated each lab group at 25 rows in Cursor's raw print order, so the two genuinely new families in the 2026-08-10 catalog — gpt-5.6-terra-* and gpt-5.6-luna-* — landed inside the hidden "… and 57 more" while the visible rows were spent on gpt-5.2 and eight gpt-5.3-codex-* ids that are strictly older than the current pin. The rows are noise because the panel pins ONE reasoning/speed tier per family, so every other tier of every pinned family is an unpinned "candidate" forever. Collapse them: one row per (lab, family) naming the family, how many tiers the catalog offers and which (strongest first), plus one member's catalog note reproduced verbatim. Order rows newest-family-version first, ties broken by catalog order, so MAX_FAMILY_IDS drops the oldest families rather than an arbitrary tail of the print order. Against the catalog captured in #144 this renders 37 rows instead of 178, both new families sit at the top of the gpt group, and no group needs a "… and N more" line at all. Rendering only — analyze(), the JSON report, urgent / has_findings, the NO-ZDR handling on pins, and the unpinned-families fold are untouched.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Comment |
There was a problem hiding this comment.
🔍 Cursor Review — Consolidated panel
Triggered by @mattmillerai.
Every reviewer in the matrix failed to contribute — see the panel summary for which cells errored, and the run logs for the underlying cause.
Panel: 0/8 reviewers contributed findings.
Reviewers that did not contribute: claude-opus-5-thinking-max:adversarial (error), gemini-3.1-pro:adversarial (error), gpt-5.6-sol-max:adversarial (error), kimi-k3-max:adversarial (error), claude-opus-5-thinking-max:edge-case (error), gemini-3.1-pro:edge-case (error), gpt-5.6-sol-max:edge-case (error), kimi-k3-max:edge-case (error)
ELI-5
Every Monday a robot compares the four AI models our PR-review panel uses against Cursor's live model list, and files a report saying "here's everything you're not using — worth a look?". Cursor sells each model at half a dozen effort levels (
-low,-high,-max, each optionally-fast), and we pin exactly one level per model — so the report was listing every other effort level of every model we already use, forever. Last Monday that came to 178 lines, cut off at 25 per vendor in whatever order Cursor happened to print them. The two brand-new models that actually shipped that week were on lines 26+, invisible. This groups the effort levels back into one line per model and puts the newest models first, so the report is 37 lines and the new stuff is at the top.What changed
.github/cursor-review/catalog-drift.py, rendering only:TIER_SUFFIXES(none/minimal/low/medium/high/extra-high/xhigh/max, each optionally-fast, plus a bare-fast) andfamily_of()split an id into(family, tier). The same-lab review-me list now renders one row per(lab, family): the family, how many tiers the catalog offers and which, and one member's catalog note reproduced verbatim.collapse_tiers()sorts rows by_family_version()descending (every digit run in the family id, in order — labs write versions as5.6,4-8andk3, so anything smarter would need a per-lab table), ties broken by catalog order.MAX_FAMILY_IDSnow drops the oldest families instead of an arbitrary tail of Cursor's print order.MAX_TIERS_PER_ROW = 8keeps a collapsed row at roughly the char cost of the single id row it replaces, so the section's worst-case budget is unchanged and the raw catalog fold keeps its room. A truncated tier list still states the full count and drops the weakest tiers.MAX_FAMILY_IDScomment (the one claiming "a few dozen models" and "every list leads with its highest-signal rows" — neither of which was true of this list) is rewritten to describe the shipped behaviour.README.md's catalog row gains a clause on the per-family rendering.Untouched on purpose:
analyze(), the JSON report,summary_line(),urgent/has_findings, the NO-ZDR handling on pins, and the unpinned-families fold (still one row per id in catalog order — it's short and already collapsed).Result against the 2026-08-10 catalog (#144)
178 unpinned same-lab ids → 37 rows. The
gptgroup goes from 25 shown + "… and 57 more" to 11 rows with nothing hidden, and reads:claude87 → 21 rows,gemini6 → 3,kimi3 → 2. No group emits a "… and N more" line. Rendered body drops from ~44 KB to ~16 KB.Tests
python3 -m unittest discover -s .github/cursor-review/tests -p 'test_*.py'— 175 pass (159 before + 16 new). The other three Python suites (agents-md-integrity, groom, refresh-reviewers) are green too.New
TierCollapseTestcovers: the family/tier split (longest-tier-wins forextra-high, bare-fast, no-suffix ids joining their family), version ordering including the catalog-order tie-break and a version-less family, tier collapse in the rendered body, verbatim notes on a collapsed row, the capped-rows message, a synthetic brand-new family printed below the pre-change cut, the worst-case char budget, and the real #144 catalog.The #144 catalog is committed verbatim as
.github/cursor-review/tests/fixtures/catalog-2026-08-10.txtso the acceptance case is asserted against the real thing rather than a hand-built approximation. It's inside the suite's existing path filter.Judgment calls
-thinkingis deliberately NOT a collapsible suffix. It reads like a reasoning knob, but the panel pins on it (claude-opus-5-thinking-maxvsclaude-opus-5-maxare different products for this purpose), so collapsing them would hide the distinction a promotion decision turns on. Consequence:claude-4.6-opus-high-thinking(suffixes in the reverse order) stays a row of its own. Cosmetic.minimalandextra-highwere added to the ticket's named suffix set — both appear in the live catalog (gemini-3.6-flash-minimal,gpt-5.5-extra-high) and are plainly the same kind of tier.MAX_FAMILY_IDS(catalog-drift.pyline ~713). Same underlying noise, but it's the urgent path that gets read carefully and the ticket scopes only the review-me list. Happy to follow up.Not done (out of scope per the ticket)
No pin is bumped — all four were re-derived against this catalog and none warrants a change; that stays a human call.
urgent/has_findings/ sticky-issue lifecycle, the family→lab alias table (still derived from the pins),cursor-review.yml's pin list, and the unpinned-families fold are all untouched.