Commit History
-
[NOTICKET] slow path: don't re-trim a payload the tool already bounded (A30 follow-up)
Rifqi Hafizuddin +1: Claude Opus 5Sofhia's a2089edb caps analyze_anomaly's sample at source (200 -> 50) and reports `anomalies_total` / `anomalies_shown` beside it. That is the right layer for it: my A30 cap protects what reaches the LLM, hers protects what gets persisted to results_snapshot and traced to Langfuse, where the 50k blob was still landing whole. But the two stacked badly. Her cap alone brings the padb payload to 1,180 tokens -- already sane. My generic list trim then cut it to 691 and left anomalies_shown: 36 beside a list of 20 rows + "… (+16 more)" The count is recoverable from the marker, and `anomalies_total` was exact throughout, so nothing was ever wrong -- but a narrative reads straight past that, and "a number in the payload that disagrees with the payload" is the exact class of bug this round has been chasing. Fixed at my end, not hers: `_bound` now leaves a value alone below _MIN_TRIM_CHARS (8,000). The bound exists to stop floods, not to second-guess a tool that already bounded itself …7ffe004