ac9cb3ec9e
Ruling B15 (coordinator correction on top of 37a970b): B11's "4
priority rows per code" cap was engaging as a default trim rather than
a budget safety net, which regressed the g2064-g2065 golden entry —
G2064 legitimately has 6 priority-kind lineage rows (replaced_by x3,
created, disappeared) and the cap silently dropped 2 of them even
though the question's whole lineage selection had plenty of room under
the hard cap.
llm.lineage._select_for_prompt now computes the unrestricted selection
(every priority row kept, exactly as before B11) first; only when that
would exceed the hard cap (2 * max_rows) does the per-code cap engage
as a fallback. Under budget, every priority row for every code
survives regardless of count.
Tests: replaced the single "always caps at 4" case with two — 6
priority rows for one code all survive under a generous max_rows (hard
cap 50), the same 6 rows trim to 4 under a tight one (hard cap 4).
Re-ran g2064-g2065-to-99424-99426-rate and ccm-history in-process
against the live replica: both PASS (g2064's missing anchor,
JE7KYBW3 p1111, is back).
60 KiB
60 KiB