chore(tasks): research-backed decisions to close open tasks (#71/#42/#14/#76/#70)
Per chaim's directive — for decisions not requiring Dafna/chaim, decide after >=3 authoritative open sources. #71 DONE — resolved by #15's weight fix (measured: all multi-relevant docs now in top-10, the rank-15/16 weak queries fixed). Research (6 sources) said enable rerank; tested empirically → it HURT (nDCG@5 0.879 vs 0.960, MRR 0.867 vs 0.954) because recall is saturated and the cross-encoder demotes exact known-item matches. Measurement overrides theory: no rerank, no limit change. #42 CANCELLED — obviated by BM25 hybrid (already on; handles abbreviation tokens lexically); 0 abbrev queries in eval, recall ~0.99, no measured gap. #14 DEFERRED (reviewed) — no current blocker; YAGNI; trigger documented. #76 CANCELLED — upstream Paperclip bug (ee=companyId), not safely fixable our side; workaround + #78 documented. #70 — research-backed normalization (ECLI/Akoma Ntoso/ELI/OpenCitations + Christen). Applied 3 deterministic mechanical fixes to cited_only (whitespace + missing prefix-space); 0 malformed remain. 4 ambiguous items (2 garbled, 'ערר אדלר', 1 combined citation) flagged for chair — NOT auto-guessed, per the entity-resolution false-merge guardrail. #80 stays pending — human-gated (Dafna value-labeling + chaim cost). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1161,13 +1161,13 @@
|
||||
"id": "14",
|
||||
"title": "Upgrade: speed up halacha+metadata extraction",
|
||||
"description": "Halacha extraction on long rulings is slow (5-15 min for typical court ruling, 30-50 min for a 207-chunk appeals committee decision). Root cause: each chunk spawns a separate `claude -p` subprocess (5-10 sec startup overhead each), Hebrew prompts on cold cache run 30-90 sec, and there's no prompt-cache sharing between chunks. Acceleration options to evaluate later when speed becomes a real blocker.\n\nOptions (each can be combined):\n\n1. Concurrency 3 -> 6 in halacha_extractor.CHUNK_CONCURRENCY. ~2x faster wall-clock. Cost: 6x ~300MB RSS = 1.8GB peak — verify on Nautilus headroom.\n\n2. Larger chunks 12K -> 18-25K chars (CHUNK_TARGET_CHARS in claims_extractor.py / halacha_extractor.py). Fewer waves. Risk: timeout on cold cache (currently 1800s ceiling), and may degrade extraction precision for very long sections.\n\n3. Anthropic SDK direct with 5-min ephemeral prompt caching on the static instruction prefix (already wired the parameter as system= in claude_session.query). Estimated 5-10x faster because cache reads are ~10% of cold cost. Costs ~$0.30-2 per long ruling on Sonnet 4.6. Chair previously rejected this path for ALL traffic ('we work only with claude session'). Compromise: SDK only for the precedent-library corpus build (static, one-time), claude session for live decision drafting (interactive, frequent).\n\n4. Two-tier prompt: a short 'classification' pass with claude -p deciding which chunks contain halachot, then deep extraction only on positive chunks. Could cut total LLM time by 40-60% on rulings with lots of factual chapters.\n\n5. Already implemented (Apr 3, 2026): skip non-extractable sections — only run on chunks where section_type IN (legal_analysis, ruling, conclusion); fallback to all chunks when chunker labels nothing. So that win is already banked.\n\nRe-evaluate when: a chair drops a 200K+ char ruling into the queue and the wait becomes painful, OR when the precedent-library has 50+ pending entries and bulk processing matters.",
|
||||
"details": "",
|
||||
"details": "נסקר 2026-06-03 — אין blocker נוכחי. הרצתי reindex ל-73 תקדימים + חילוצים מרובים בלי שמהירות הייתה כאב. YAGNI: לא מבצעים אופטימיזציה מוקדמת. נשאר deferred עם trigger ברור: פסק-דין 200K+ תווים שתוקע את התור, או 50+ פריטים ממתינים. ה-win הזול (concurrency 3→6) דורש אימות headroom של 1.8GB RSS ב-Nautilus לפני — לא עכשיו.",
|
||||
"testStrategy": "",
|
||||
"status": "deferred",
|
||||
"dependencies": [],
|
||||
"priority": "low",
|
||||
"subtasks": [],
|
||||
"updatedAt": "2026-05-03T16:03:07.222Z"
|
||||
"updatedAt": "2026-06-03T00:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"id": "15",
|
||||
@@ -1783,15 +1783,15 @@
|
||||
"id": "42",
|
||||
"title": "[שלב B] Query expansion via Claude Haiku — 2-3 variants per query",
|
||||
"description": "שאילתות עם abbreviations משפטיות ('בל\"מ'/'בקשה להארכת מועד') חוטפות recall. LLM expansion: שאילתה → 2-3 variants → union retrieval. +10-15% recall.",
|
||||
"details": "להוסיף שכבה ב-search_precedent_library_semantic: אם query מכיל abbreviations נפוצים (mapping פנימי) — להריץ Haiku להרחבה. cache תוצאות לפי query hash (Redis TTL 24h).",
|
||||
"details": "בוטל 2026-06-03 — obviated. BM25_HYBRID_ENABLED=true כבר פעיל ותופס קיצורים לקסיקלית (בל\"מ כ-token). ב-gold-set (86 שאילתות) 0 שאילתות-קיצורים, ו-recall כללי ≈0.99 — אין gap נמדד. Query-expansion דרך LLM מוסיף latency+עלות לכל שאילתה ללא צורך מוכח (YAGNI). re-open trigger: אם eval ייעודי על שאילתות-קיצורים יראה recall<0.9.",
|
||||
"testStrategy": "Eval על 20 שאילתות עם abbreviations: לפני/אחרי recall@10. צפוי +10-15%.",
|
||||
"status": "deferred",
|
||||
"status": "cancelled",
|
||||
"dependencies": [
|
||||
"41"
|
||||
],
|
||||
"priority": "medium",
|
||||
"subtasks": [],
|
||||
"updatedAt": "2026-05-26T08:08:27.953285Z"
|
||||
"updatedAt": "2026-06-03T00:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"id": "43",
|
||||
@@ -2410,7 +2410,7 @@
|
||||
"id": "70",
|
||||
"title": "[FU-2c-b] תיאום + dedup של cited_only (49 רשומות) + אהוד שפר cross-source",
|
||||
"description": "המשך ל-FU-2c (#68). ה-dry-run של תיאום-המזהים החיצוני חשף 49 רשומות source_kind='cited_only' (הפניות-ציטוט שחולצו מהחלטות) שלא היו בהיקף #68. דורשות נרמול נפרד: צורות-ועדה כמו 'ערר 1093-19' (NNNN-NN) שה-extractor הנוכחי לא תופס (NO_DOCKET), 'בש\"א 2487-14', dups, ו-'ערר אדלר' בלתי-פתיר (ללא מספר). בנוסף: dedup חוצה-source של אהוד שפר — external_upload 'עע\"מ 317/10 אהוד שפר' מול cited_only קיים 'עע\"מ 317/10' (אותו תיק; ה-collision-guard מנע התנגשות ב-uq_case_law_external_number, ה-external_upload נשאר עם case_number מנופח עד הכרעה).",
|
||||
"details": "מקור: dry-run FU-2c 2026-05-31 (data/audit/fu2c-reconciliation-20260531T140632Z.{csv,md}). 73 רשומות <> internal_committee = 24 external_upload (טופלו ב-#68) + 49 cited_only. מתוך ה-cited_only: ~17 will_change (refs בצורת בית-משפט), 6 NO_DOCKET (ערר NNNN-NN + ערר אדלר), 5+ DUP_CHECK. דרוש: (1) הרחבת _DOCKET_RE לצורת-ועדה NNNN-NN; (2) הכרעה אם cited_only refs מקבלים נרמול מלא או נשארים כ-display; (3) dedup חוצה-source (cited_only שהפך ל-external_upload → מיזוג/הסרה, ראה precedent_link_cases/precedent_unlink_cases); (4) 'ערר אדלר' — סגירה ידנית. severity: Medium. סוג: data-migration + chair. הסקריפט scripts/fu2c_reconcile_external_case_numbers.py כבר מסנן apply ל-external_upload בלבד ומשאיר cited_only בשדה-ראייה לזיהוי-dup. [עדכון 2026-05-31 — בוצע חלקית]: dedup חוצה-source של אהוד שפר הושלם — ה-stub cited_only 65a3a143 (עע״מ 317/10) מוזג ל-external_upload 9024da7b, 7 ציטוטים מופו-מחדש, case_number נורמל ל-עע״מ 317/10 (גיבוי data/audit/shafer-merge-backup.json). סריקת-קורפוס מלאה (128 רשומות): 0 stubs עם ציטוטים תקועים נותרו — כל 32 ה-cited_only עם ציטוטים לגיטימיים (אין רשומת-תוכן מקבילה). נמחקו 2 stubs ריקים מיותרים מעל/כפול תוכן: 1071-25 (3dce0689) ו-1009-02-24 (d05c771c) — גיבויים data/audit/stub-cleanup-*.json. נותר פתוח: (א) 1083-24 — ציטוט-משולב 'ערר (ירושלים) 1078+1083/24' (שני תיקים ב-stub אחד) → דורש טיפול combined-citation ב-citation_extractor (פיצול ל-1078-24 + 1083-24), לא מחיקת-נתונים; (ב) ~49 ה-cited_only הרחבים (_DOCKET_RE לצורת NNNN-NN, 'ערר אדלר') בהיקף המקורי.",
|
||||
"details": "[2026-06-03] נרמול מבוסס-מחקר (4 מקורות: ECLI work-level id, Akoma Ntoso FRBR Work/Manifestation, ELI canonical+alias, OpenCitations OMID + Christen data-matching). מדיניות: צורה קנונית אחת + alias; cited_only stub = אותו Work כמו ה-doc → merge על התאמה-מדויקת בלבד; un-resolvable = display+flag, לא למחוק; merge = re-point edges + dedup, שמרני (false-merge בגרף-ציטוט יקר). בוצע: 46 רשומות cited_only סווגו; 3 תיקונים מכניים-דטרמיניסטיים הוחלו (ערר \\n316/10→ערר 316/10; עע\"מ65/13→עע\"מ 65/13; עע\"מ9057/09→עע\"מ 9057/09). 0 malformed (whitespace/no-space) נותרו. **נותר לשיקול יו\"ר (לא ננחש, לפי המשמר)**: (1) 2 garbled — 'ערר 1078/0724' (4a38c202), 'ערר 1083/0724' (6682f9cb); (2) 'ערר אדלר' (863a7bf8) ללא docket → keep+flag; (3) combined 'ערר (ירושלים) 1078+1083/24' (e7f6fd06) → פיצול ל-1078/24+1083/24 מתנגש עם stub קיים 'ערר 1083/24' → entity-resolution ידני. תוספת קוד עתידית: טיפול '+' ב-citation_extractor. הדדאפ הקודם (shafer + stub cleanup) כבר הושלם. אלה chair-domain — לא הכרעת-מהנדס.",
|
||||
"testStrategy": "אחרי תיקון: 0 NO_DOCKET ב-cited_only (פרט ל-ערר אדלר המתועד); אין case_number כפול בין external_upload ל-cited_only; אהוד שפר עע\"מ 317/10 = רשומה אחת.",
|
||||
"status": "pending",
|
||||
"dependencies": [
|
||||
@@ -2418,21 +2418,21 @@
|
||||
],
|
||||
"priority": "medium",
|
||||
"subtasks": [],
|
||||
"updatedAt": "2026-05-31T14:11:27.861937+00:00"
|
||||
"updatedAt": "2026-06-03T00:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"id": "71",
|
||||
"title": "[FU-5 follow-up] כוונון עומק-אחזור/rerank — recall רב-תקדימי לסוגיות רחבות",
|
||||
"description": "ה-eval harness (#63) חשף: לשאלות משפטיות רחבות (5 תקדימים רלוונטיים) חלק מהתקדימים ה-co-relevant מדורגים 15–16 ונופלים מ-top-10. אבחון 2026-05-31: התקדימים *מאוחזרים* (recall תקין, ≈1.0 ב-rank 20) — זו בעיית עומק-חיתוך/דירוג, לא כשל-recall. לשקול בזהירות: העלאת limit ברירת-מחדל של search_precedent_library (10→15/20) ו/או כוונון rerank depth/diversity, ולמדוד ΔR@10 מול רגרסיה ב-known-item (MRR≈1.0 כיום).",
|
||||
"details": "מקור: baseline FU-5 על 9 שאילתות-יו\"ר מהותיות (S1-S9). שאילתות חלשות: S2 נטרול תמ\"א 38 (R@10=0.60, הבית שמעוני@16), S8 שמאי מכריע (0.50), S4 (ב.דייניש@15), S7 (גבעת האירוסים@15). חשוב: שינוי limit משפיע על web-ui (תצוגה), סוכני-כתיבה (כמות תקדימים ל-LLM, עלות-tokens), ולכן דורש שיקול מוצר + מדידה. תהליך: env VOYAGE/POSTGRES → scripts/eval_retrieval.py לפני/אחרי כל שינוי, להשוות מול data/eval/baseline.json. severity: Medium. סוג: retrieval-tuning + מדידה. תלוי ב-#63 (harness).",
|
||||
"description": "נפתר ע\"י תיקון ה-weight של #15 (multimodal 0.5→0.65). מדידה 2026-06-03: כל 11 השאילתות הרב-תקדים/יו\"ר מחזירות את כל התקדימים הרלוונטיים ב-top-10 (רובם top-6; גרוע ביותר rank 9). השאילתות החלשות מהבייסליין (S2 הבית-שמעוני@16, S4 ב.דייניש@15, S7@15, S8) כולן תוקנו. recall@10≈1.0.",
|
||||
"details": "החלטה מבוססת-מדידה+מחקר (6 מקורות: Cormack RRF, Drowning-in-Documents 2411.11767, ReFIT, MMR, Elastic, Pinecone). המחקר המליץ להפעיל rerank (fetch_k=50,return_k=10); בדקתי אמפירית — VOYAGE_RERANK_ENABLED=true דווקא הזיק: nDCG@5 0.879 מול 0.960, MRR 0.867 מול 0.954, R@5 0.966 מול 0.994 (כל המדדים שליליים). הסיבה: recall כבר רווי, וה-cross-encoder הכללי מוריד את ההתאמה המדויקת ב-known-item. **המדידה גוברת על התיאוריה — לא מפעילים rerank, לא מעלים limit, RRF_K=60 נשאר.** אין שינוי-קוד נדרש.",
|
||||
"testStrategy": "לפני/אחרי כל שינוי: eval_retrieval.py באותו retrieval_config; הוכחה ש-R@10 הרב-תקדימי עולה בלי ירידה ב-MRR/known-item recall.",
|
||||
"status": "pending",
|
||||
"status": "done",
|
||||
"dependencies": [
|
||||
"63"
|
||||
],
|
||||
"priority": "low",
|
||||
"subtasks": [],
|
||||
"updatedAt": "2026-05-31T16:05:35.071261+00:00"
|
||||
"updatedAt": "2026-06-03T00:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"id": "72",
|
||||
@@ -2486,14 +2486,14 @@
|
||||
{
|
||||
"id": "76",
|
||||
"title": "תיקון כפתור \"צור משימה\" ב-Paperclip — מאופשר אך submit חוזר בשקט",
|
||||
"description": "כפתור \"צור משימה\" במודאל \"משימה חדשה\" של Paperclip: הטקסט מופיע, הכפתור שחור/מאופשר, אך לחיצה לא שולחת בקשה ואין שגיאה. אובחן סופית (2026-06-02).",
|
||||
"description": "בוטל 2026-06-03 — באג upstream של Paperclip, לא ניתן לתיקון בטוח אצלנו (ee=companyId; הכפתור מאופשר לפי כותרת בלבד אך submit דורש חברה שלא אותחלה). אומת ע\"י chaim שעובד מהקשרי-חברה רגילים. Workaround: לבחור חברה במודאל / לפתוח מתוך לוח. מסלול אמין: pc.sh POST /companies/{id}/issues. תיקון יסודי = upstream. #78 מסיר את הצורך בזרימת הפסיקה.",
|
||||
"details": "אבחנה סופית מתוך הבאנדל (index-BWGhimVr.js): ה-submit הוא `function xi(){const je=m.current.trim();if(!ee||!je||He.isPending)return;...He.mutate({...companyId:ee...})}`. `je`=כותרת (קיים), `He`=mutation. ה-guard שנכשל הוא **`ee`**, ש-`ee` משמש כ-`projects.list(ee)` וכ-`companyId:ee` במוטציה — כלומר **`ee` = מזהה החברה**. השורש: הכפתור מאופשר לפי הכותרת בלבד (`disabled:!b`, b=כותרת), אבל ה-submit דורש גם חברה (`!ee`). כשהמודאל נפתח בהקשר שבו החברה לא אותחלה, המשתמש לוחץ כפתור 'מאופשר' וה-handler חוזר בשקט — בלי POST, בלי שגיאה. בחירת הסוכן (callback Ro) לא מגדירה את החברה — היא נקבעת רק דרך בורר חברה נפרד (pr/oe). ההזרקה שלנו (translate-he.js) זוכתה: reverseComments נוגע רק ב-[id^='comment-'], לא במודאל; isUserContent מדלג על contentEditable. **לא ניתן לתקן בבטחה דרך injection**: אי-אפשר לכתוב ל-state של React מבחוץ; shim שמגרד DOM ויוצר issue דרך API הוא שביר (צריך IDs מה-DOM) ועלול ליצור משימות פגומות — גרוע מהבאג. **Workaround**: לוודא שהחברה נבחרה במודאל (בורר החברה) לפני לחיצה על 'צור משימה'; או לפתוח 'משימה חדשה' מתוך הקשר חברה/לוח. מסלול אמין תמיד: API ישיר `pc.sh POST /companies/{id}/issues`. **תיקון יסודי = upstream Paperclip** (הכפתור צריך להיות disabled כשאין חברה, או החברה צריכה להיגזר מהלוח/סוכן הנבחר). הערה: #78 (חילוץ פסיקה אוטומטי) מסיר את הצורך במודאל הזה בזרימת חילוץ-הפסיקה; הזרימה הרגילה מניעה סוכנים דרך תגובות (CEO מנתב).",
|
||||
"testStrategy": "לאחר ה-shim: לפתוח \"משימה חדשה\", להקליד כותרת עברית, ללחוץ \"צור משימה\" → לוודא POST /issues ב-access-log + ה-issue מופיע בלוח. לבדוק גם בלוח רגיל (לא תור חילוץ) ובשתי החברות.",
|
||||
"status": "deferred",
|
||||
"status": "cancelled",
|
||||
"dependencies": [],
|
||||
"priority": "high",
|
||||
"subtasks": [],
|
||||
"updatedAt": "2026-06-02T00:00:00.000Z"
|
||||
"updatedAt": "2026-06-03T00:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"id": "77",
|
||||
|
||||
Reference in New Issue
Block a user