ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

P2 (אופציונלי) — resume תוך-פאנל: פירוק הפאנל ל-map per-item #434

New Issue
Open
opened 2026-08-05 11:01:11 +00:00 by chaim · 0 comments
chaim commented 2026-08-05 11:01:11 +00:00
Owner
Copy Link

What & Why

גרעיניות עדינה: פירוק node-הפאנל ל-map מעל ההלכות/הלקחים הממתינים (LangGraph Send), כל פריט = יחידת-checkpoint. קריסה באמצע-פאנל → המשך מפריט N+1 בלי לשפוט מחדש 1..N ברמת-LLM (חיסכון אמיתי בקריאות+דקות). נשען על ה-CSV הקיים כמקור "כבר-נשפט".

הקשר ופירוט

ספ: X16 §3.3 (עדין) + §4 (P2). רלוונטי כשהפאנל ארוך מאוד (תור-pending מלא). לאמת אינטראקציה עם ה-CSV הקיים (reversible, chair-gated) — לא לשבור את שער-היו"ר (INV-G10). אופציונלי — להריץ רק אם P0/P1 מראים שהרצה-חוזרת של הפאנל השלם עדיין יקרה מדי. worktree + PR.
<info added on 2026-06-10T10:00:05.091Z>
אני צריך לבדוק את מבנה הקוד הרלוונטי כדי לוודא שההכרעה מבוססת על ניתוח נכון של המצב הקיים.עכשיו יש לי תמונה ברורה. בהתבסס על הניתוח:

הכרעה 2026-06-10 (אחרי P0/P1 #114/#115 מוזגו): DEFERRED — לא מומש.

ניתוח טכני מאומת: (1) langgraph/durable-runtime טרם מותקנים בקוד הייצור — אין _pipeline_runtime.py, אין SqliteSaver, אין ייבוא langgraph ב-mcp-server/ או scripts/. משימה #114 (P0) סומנה done אך התשתית טרם נקלטה לעץ-הראשי. (2) halacha_panel_approve.py (שורות 170-310): מביא את כל ה-pending (שורה 170), שופט בלולאת fan-out (שורות 196-211), ומחיל UPDATE רק בסוף (שורות 288+). resume "חינם" בין-ריצות קיים (DB review_status מדלג על מה שכבר אושר/נדחה), אבל קריסה תוך-כדי הלולאה מאבדת את כל השיפוט שטרם הוחל. (3) P2 היה מגן על התרחיש הזה ע"י checkpoint per-item.

מיטיגציה פשוטה יותר (לשקול לפני P2): להזיז את ה-UPDATE לתוך הלולאה (apply incremental, שורות 288-310 → לתוך שורות 196-211) — אז ה-DB-status-resume מכסה גם קריסה תוך-פאנל, בלי צורך ב-LangGraph Send/map. שינוי קטן יותר שמשמר את מודל ה-CSV-backup.

תנאי-הפעלה-מחדש: (א) אחרי התקנת durable-runtime בייצור (#114 אמיתי), (ב) אם נצפות קריסות mid-panel על תורים גדולים שגורמות לשיפוט-חוזר יקר. עד אז: אין הצדקה — מונע מורכבות ספקולטיבית (G2). אם תנאי (ב) מתקיים — לשקול קודם את המיטיגציה הפשוטה (incremental apply), ורק אם לא מספיקה → P2 המלא.
</info added on 2026-06-10T10:00:05.091Z>

Acceptance Criteria

kill באמצע-פאנל (אחרי 50% מהפריטים) → resume → אימות שרק הפריטים שנותרו נשפטים (ספירת קריאות-LLM), והתוצאה זהה לריצה רציפה.

תלויות

תלוי ב-TaskMaster #115 — כולן הושלמו לפני המיגרציה (לא נפתח עבורן issue).

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

## What & Why גרעיניות עדינה: פירוק node-הפאנל ל-map מעל ההלכות/הלקחים הממתינים (LangGraph Send), כל פריט = יחידת-checkpoint. קריסה באמצע-פאנל → המשך מפריט N+1 בלי לשפוט מחדש 1..N ברמת-LLM (חיסכון אמיתי בקריאות+דקות). נשען על ה-CSV הקיים כמקור "כבר-נשפט". ## הקשר ופירוט ספ: X16 §3.3 (עדין) + §4 (P2). רלוונטי כשהפאנל ארוך מאוד (תור-pending מלא). לאמת אינטראקציה עם ה-CSV הקיים (reversible, chair-gated) — לא לשבור את שער-היו"ר (INV-G10). אופציונלי — להריץ רק אם P0/P1 מראים שהרצה-חוזרת של הפאנל השלם עדיין יקרה מדי. worktree + PR. <info added on 2026-06-10T10:00:05.091Z> אני צריך לבדוק את מבנה הקוד הרלוונטי כדי לוודא שההכרעה מבוססת על ניתוח נכון של המצב הקיים.עכשיו יש לי תמונה ברורה. בהתבסס על הניתוח: הכרעה 2026-06-10 (אחרי P0/P1 #114/#115 מוזגו): DEFERRED — לא מומש. ניתוח טכני מאומת: (1) langgraph/durable-runtime טרם מותקנים בקוד הייצור — אין `_pipeline_runtime.py`, אין `SqliteSaver`, אין ייבוא langgraph ב-`mcp-server/` או `scripts/`. משימה #114 (P0) סומנה done אך התשתית טרם נקלטה לעץ-הראשי. (2) `halacha_panel_approve.py` (שורות 170-310): מביא את כל ה-pending (שורה 170), שופט בלולאת fan-out (שורות 196-211), ומחיל UPDATE רק בסוף (שורות 288+). resume "חינם" בין-ריצות קיים (DB review_status מדלג על מה שכבר אושר/נדחה), אבל קריסה תוך-כדי הלולאה מאבדת את כל השיפוט שטרם הוחל. (3) P2 היה מגן על התרחיש הזה ע"י checkpoint per-item. מיטיגציה פשוטה יותר (לשקול לפני P2): להזיז את ה-UPDATE לתוך הלולאה (apply incremental, שורות 288-310 → לתוך שורות 196-211) — אז ה-DB-status-resume מכסה גם קריסה תוך-פאנל, בלי צורך ב-LangGraph Send/map. שינוי קטן יותר שמשמר את מודל ה-CSV-backup. תנאי-הפעלה-מחדש: (א) אחרי התקנת durable-runtime בייצור (#114 אמיתי), (ב) אם נצפות קריסות mid-panel על תורים גדולים שגורמות לשיפוט-חוזר יקר. עד אז: אין הצדקה — מונע מורכבות ספקולטיבית (G2). אם תנאי (ב) מתקיים — לשקול קודם את המיטיגציה הפשוטה (incremental apply), ורק אם לא מספיקה → P2 המלא. </info added on 2026-06-10T10:00:05.091Z> ## Acceptance Criteria kill באמצע-פאנל (אחרי 50% מהפריטים) → resume → אימות שרק הפריטים שנותרו נשפטים (ספירת קריאות-LLM), והתוצאה זהה לריצה רציפה. ## תלויות תלוי ב-TaskMaster #115 — כולן **הושלמו** לפני המיגרציה (לא נפתח עבורן issue). --- <sub>הועבר מ-TaskMaster (tag `legal-ai`, id **116**, status היה `deferred`) ב-2026-08-05. הפניות `(#116)` בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.</sub>
chaim added the area:agentspriority:p3-lowstatus:deferredtype:chore labels 2026-08-05 11:01:11 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:agents
סוכני Paperclip, תזמור, שער-הפלטפורמה (X15)
 area:backend
FastAPI web/, endpoints
 area:ci
Gitea Actions, שערי-CI
 area:docs
ספ-המערכת, תיעוד, תכנון
 area:extraction
קליטה, OCR, חילוץ הלכות/מטא/טענות/תכניות
 area:frontend
web-ui/ (Next.js), RTL
 area:infra
Deploy, Coolify, MinIO, אחסון, גיבויים
 area:mcp
שרת ה-MCP וחוזה-הכלים (X9)
 area:retrieval
RAG, חיפוש, קורפוס, גרף-ציטוטים, יומונים
 area:security
אבטחה, סודות, PII, audit
 area:writing
12 הבלוקים, סגנון דפנה, QA, רכישת-סגנון
 priority:p0-blocker
Blocks everything
 priority:p1-high
High priority
 priority:p2-normal
Normal priority
 priority:p3-low
Low priority / nice to have
 size:l
a week+ — consider splitting
 size:m
2-3 days
 size:s
~1 day
 size:xs
< half a day
 status:blocked
Waiting on another issue/decision
 status:deferred
Decided to defer — parked backlog; not auto-picked
 status:good-first-issue
Small, self-contained starting point
 status:in-progress
Being worked on (a branch/worktree exists)
 status:in-review
A PR is open for this issue
 status:needs-decision
Requires a call before proceeding
 status:ready
Scoped + pickable (has acceptance criteria + size)
 type:bug
Something works incorrectly
 type:chore
Infra, deps, refactor, CI, docs
 type:feature
New capability
 type:spike
Time-boxed investigation -> a decision/doc
No Label area:agents priority:p3-low status:deferred type:chore
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chaim
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#434
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?