720057bc72834049aa6279d054104d39a1404c24
בתיק 1069-04-26 נשלחו 310 טענות עוררים בקריאת-Claude אחת. הקריאה החזירה לא-JSON, הקוד רשם warning והחזיר [], והפעולה דיווחה status=completed עם אפס טיעונים לצד המרכזי בערר. 495 propositions_processed — כלומר "עיבדתי הכל". שתי תקלות מובחנות, שתיהן מתוקנות: 1. **הקריאה גדולה מדי.** הפיצול הפר-כתב-טענות שנוסף למשיבים (#224) הסתיר את זה במקרה — הוא שמר על קריאות קטנות — אבל עוררים וּועדה מדברים בקול אחד ואינם מפוצלים לעולם, כך שערר גדול יוצא בקריאה אחת ענקית. ההערה בקוד כבר תיעדה בדיוק את הכשל הזה אצל המשיבים; התיקון פשוט לא הוחל על העוררים. עכשיו כל צד מעל MAX_PROPS_PER_CALL=80 נצבר בכמה קריאות ומשורשר. הפיצול הוא trade-off ולא רווח חינם: כל chunk מקובץ בבידוד, ולכן צד שמתפצל עלול לקבל יותר טיעונים (וחופפים במקצת) מאשר במעבר יחיד. לאבד ליטיגנט שלם גרוע יותר, והחלופה — פרומפט קטן יותר לכל פרופוזיציה — הייתה מנוונת כל תיק כדי לתקן את הגדולים. הסדר נשמר בחיתוך, כי טענות מגיעות ממוינות לפי claim_index ושכנות שייכות בד"כ לאותו ראש-טיעון. 2. **הכשל נבלע.** החזרת [] על תשובה לא-רשימה אינה ניתנת להבחנה מ"לצד הזה אין טיעונים". עכשיו נזרקת AggregationFailed, הקורא רושם אותה ב-errors, והסטטוס יורד ל-completed_with_errors (כלל-הנדסה §6). ההודעה נוקבת בשם הצד ובמספר הפרופוזיציות, אחרת מפעיל שרואה completed_with_errors לא יודע איזה ליטיגנט נעלם. מבחני רגרסיה: chunking לא מאבד ולא מסדר-מחדש (310→4 קריאות, רצף נשמר); תשובה לא-רשימה זורקת ומזכירה את שם הצד. אם המבחן השני יחזור אי-פעם לטעון == [] — באג הבליעה הוחזר. invariants: כלל-הנדסה §6 — אין בליעה שקטה. G1 — תיקון במקור (גודל הקריאה) ולא בקריאה. G2/G12 — לא נגועים; שני השערים ירוקים. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
AI Legal Decision Drafting System — MCP server, web upload, RAG search
Languages
Python
66.1%
TypeScript
31.8%
JavaScript
1.1%
Shell
0.7%
CSS
0.2%