הג'וב sync-case-status כתב על כל issue מקושר-לתיק שסטטוסו שונה מהיעד — השומר היחיד היה 'issue.status !== targetStatus'. לכן הוא החזיר sub-tasks שנסגרו (done) ל-in_progress, כפי שתועד ב-CMPA-140 / תיק 8125-09-24. בחירת-היעד חולצה ל-src/sync-target.ts: נבחר שורש יחיד (parentId === null) שאינו done/cancelled ואינו in_review/blocked; אפס או יותר-מאחד → לא נכתב דבר, ונרשם לוג עם הסיבה. שני הקבועים מובחנים בכוונה — CLOSED_ISSUE_STATUSES הוא ההגדרה היחידה של 'סגור' (מראה של legal-ai/web/paperclip_client.py:561), ו-NON_WRITABLE_STATUSES הוא 'מצב בבעלות Paperclip/בהמתנה-לאדם': כתיבת in_progress על issue ב-in_review מזמינה auto-block תוך דקה (legal-ai/docs/paperclip-quirks.md §3) וגונבת אותו מתור-הביקורת של היו"ר. הלולאה הכפולה הוחלפה במעבר אחד + קיבוץ למפת case_number→מועמדים; הקיבוץ נדרש כדי לבחור 'השורש היחיד', וכתוצר-לוואי O(NxM)→O(M) קריאות state.get. מבחן-רגרסיה (node --test, ללא תלויות חדשות) משחזר את 11 ה-issues שנמדדו לתיק 8125-09-24 ומוכיח את הדלתא: הכלל הישן היה כותב על CMPA-140, החדש לא. בבעלות ריפו זה בהחלטת פאנל — העברת הלוגיקה ל-legal-ai נפסלה כי היא מוסיפה UPDATE ישיר ל-DB של Paperclip, בהפרת INV-INT4 (GAP-24/25).
Description
Paperclip plugin for Legal AI integration — case management, semantic search, workflow tracking
Languages
TypeScript
90%
JavaScript
10%