צבירת-הטיעונים מוחקת צד שלם בשקט — 310 טענות עוררים → 0 טיעונים, status ok #458

New Issue

chaim · 2026-08-05T11:01:20Z

chaim commented

2026-08-05 11:01:20 +00:00

What & Why

aggregate_claims_to_arguments שולח את כל טענות צד-העוררים בקריאת-Claude אחת. בתיק 1069-04-26 היו 310, הקריאה החזירה לא-JSON, הקוד רשם warning והחזיר [] — והפעולה דיווחה הצלחה עם 0 טיעונים לצד המרכזי בערר. הדפוס הזה כבר תועד בקוד לגבי respondent ותוקן שם, אך התיקון לא הוחל על appellant.

הקשר ופירוט

שתי תקלות מובחנות — לתקן את שתיהן

תקלה 1 — appellant לא מפוצל, והקריאה גדולה מדי

mcp-server/src/legal_mcp/services/argument_aggregator.py:37

SPLIT_PARTIES = {"respondent", "permit_applicant"}   # appellant חסר

ההערה בשורות 244-250 מתעדת בדיוק את הכשל הזה אצל respondent:

"Splitting the large respondent set per-brief also keeps each Claude call small enough to succeed — a single 100+ proposition call previously returned non-JSON and silently dropped the whole side."

התיקון ההוא לא הוחל על appellant. ב-1069-04-26 הוא ספג 310 פרופוזיציות בקריאה אחת.

הנימוק לאי-פיצול ("Appellant/committee speak with a single voice") נכון סמנטית אך לא פותר את בעיית-הגודל. פיצול לפי party_name/source_document אצל עוררים גם לא יעזור כשכל 310 מגיעות מאותו כתב ערר. נדרש chunking לפי גודל, לא לפי מסמך.

תקלה 2 — בליעה שקטה (הפרת כלל-הנדסה §6)

argument_aggregator.py:174-179

if not isinstance(raw_result, list):
    logger.warning(...)
    return []

צד שלם נעלם והפעולה מחזירה status: ok. הקורא לא יכול להבחין בין "לצד הזה אין טיעונים" ל"הקריאה נכשלה". חייב להחזיר שגיאה או לפחות partial:true + רשימת הצדדים שנכשלו, כמו ש-extract_claims כבר עושה עם partial.

ראיות (2026-08-05, תיק 1069-04-26)

claims.party_role:        appellant=310 · committee=107 · permit_applicant=73 · respondent=5
legal_arguments אחרי:     committee=27 · permit_applicant=24 · respondent=5 · appellant=0
propositions_processed:   495   ← דיווח "עיבד הכל"

הצבירה הורצה פעמיים: פעם דרך MCP (נקטעה ב-timeout של 30 דק') ופעם ישירות מהמארח בלי timeout — שתיהן החזירו 0 עוררים, כלומר זה לא timeout אלא כשל-גודל.

למה זה מסוכן במיוחד

analyze_protocol דורש טיעונים מאוגדים כתשתית להשוואה. בלי צד-העוררים הוא משווה את הפרוטוקול לצד אחד בלבד — ומחזיר תוצאה שנראית תקינה. גם validate_decision (כיסוי-טענות) מחשב מול נתון חסר.

המצב הנוכחי גרוע מלפני הניקוי: קודם היו 104 טיעונים עם תגית שגויה אחידה; עכשיו 56 עם צד-העוררים נעדר לגמרי.

מה לא הסיבה

לא באג פיצול-המשיבים (#224) — הוא דווקא עבד: הצדדים התפזרו נכון ל-committee/permit_applicant/respondent עם party_name.
לא ניקוי נספח 7 — 16 הטענות שסומנו skip שוליות.
לא timeout — אומת בהרצה ישירה מהמארח בלי הגבלה.

אחרי התיקון

להריץ מחדש aggregate_claims_to_arguments("1069-04-26", force=true) ולאמת שכל ארבעת הצדדים מיוצגים, ואז validate_decision לקבלת מדד-כיסוי אמיתי לטיוטה שכבר נכתבה.

Acceptance Criteria

רגרסיה: לצבור תיק עם >150 טענות בצד יחיד ולאמת שכל צד מיוצג. מבחן-בליעה: להזריק כשל בקריאת-Claude ולוודא שהפעולה מחזירה שגיאה/partial ולא status ok עם 0. בדיקת-שפיות מהירה: select party, count(*) from legal_arguments where case_id=... group by 1 — כל צד שיש לו claims חייב להופיע.

_{הועבר מ-TaskMaster (tag legal-ai, id 233, status היה pending) ב-2026-08-05. הפניות (#233) בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.}

## What & Why aggregate_claims_to_arguments שולח את כל טענות צד-העוררים בקריאת-Claude אחת. בתיק 1069-04-26 היו 310, הקריאה החזירה לא-JSON, הקוד רשם warning והחזיר [] — והפעולה דיווחה הצלחה עם 0 טיעונים לצד המרכזי בערר. הדפוס הזה כבר תועד בקוד לגבי respondent ותוקן שם, אך התיקון לא הוחל על appellant. ## הקשר ופירוט ## שתי תקלות מובחנות — לתקן את שתיהן ### תקלה 1 — appellant לא מפוצל, והקריאה גדולה מדי `mcp-server/src/legal_mcp/services/argument_aggregator.py:37` ```python SPLIT_PARTIES = {"respondent", "permit_applicant"} # appellant חסר ``` ההערה בשורות 244-250 מתעדת בדיוק את הכשל הזה אצל respondent: > "Splitting the large respondent set per-brief also keeps each Claude call small enough to succeed — a single 100+ proposition call previously returned non-JSON and silently dropped the whole side." **התיקון ההוא לא הוחל על appellant.** ב-1069-04-26 הוא ספג 310 פרופוזיציות בקריאה אחת. הנימוק לאי-פיצול ("Appellant/committee speak with a single voice") נכון **סמנטית** אך לא פותר את בעיית-הגודל. פיצול לפי `party_name`/`source_document` אצל עוררים גם לא יעזור כשכל 310 מגיעות מאותו `כתב ערר`. **נדרש chunking לפי גודל**, לא לפי מסמך. ### תקלה 2 — בליעה שקטה (הפרת כלל-הנדסה §6) `argument_aggregator.py:174-179` ```python if not isinstance(raw_result, list): logger.warning(...) return [] ``` צד שלם נעלם והפעולה מחזירה `status: ok`. הקורא לא יכול להבחין בין "לצד הזה אין טיעונים" ל"הקריאה נכשלה". **חייב להחזיר שגיאה או לפחות `partial:true` + רשימת הצדדים שנכשלו**, כמו ש-`extract_claims` כבר עושה עם `partial`. ## ראיות (2026-08-05, תיק 1069-04-26) ``` claims.party_role: appellant=310 · committee=107 · permit_applicant=73 · respondent=5 legal_arguments אחרי: committee=27 · permit_applicant=24 · respondent=5 · appellant=0 propositions_processed: 495 ← דיווח "עיבד הכל" ``` הצבירה הורצה פעמיים: פעם דרך MCP (נקטעה ב-timeout של 30 דק') ופעם ישירות מהמארח בלי timeout — **שתיהן החזירו 0 עוררים**, כלומר זה לא timeout אלא כשל-גודל. ## למה זה מסוכן במיוחד `analyze_protocol` דורש טיעונים מאוגדים כתשתית להשוואה. בלי צד-העוררים הוא משווה את הפרוטוקול לצד אחד בלבד — ומחזיר תוצאה שנראית תקינה. גם `validate_decision` (כיסוי-טענות) מחשב מול נתון חסר. **המצב הנוכחי גרוע מלפני הניקוי:** קודם היו 104 טיעונים עם תגית שגויה אחידה; עכשיו 56 עם צד-העוררים נעדר לגמרי. ## מה לא הסיבה - **לא** באג פיצול-המשיבים (#224) — הוא דווקא עבד: הצדדים התפזרו נכון ל-committee/permit_applicant/respondent עם party_name. - **לא** ניקוי נספח 7 — 16 הטענות שסומנו `skip` שוליות. - **לא** timeout — אומת בהרצה ישירה מהמארח בלי הגבלה. ## אחרי התיקון להריץ מחדש `aggregate_claims_to_arguments("1069-04-26", force=true)` ולאמת שכל ארבעת הצדדים מיוצגים, ואז `validate_decision` לקבלת מדד-כיסוי אמיתי לטיוטה שכבר נכתבה. ## Acceptance Criteria רגרסיה: לצבור תיק עם >150 טענות בצד יחיד ולאמת שכל צד מיוצג. מבחן-בליעה: להזריק כשל בקריאת-Claude ולוודא שהפעולה מחזירה שגיאה/partial ולא status ok עם 0. בדיקת-שפיות מהירה: `select party, count(*) from legal_arguments where case_id=... group by 1` — כל צד שיש לו claims חייב להופיע. --- <sub>הועבר מ-TaskMaster (tag `legal-ai`, id **233**, status היה `pending`) ב-2026-08-05. הפניות `(#233)` בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.</sub>

chaim added the area:extraction area:mcp status:ready priority:p1-high type:bug labels 2026-08-05 11:01:20 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#458