הג'וב 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).
18 lines
384 B
JSON
18 lines
384 B
JSON
{
|
|
"compilerOptions": {
|
|
"target": "ES2022",
|
|
"module": "ESNext",
|
|
"moduleResolution": "bundler",
|
|
"outDir": "dist",
|
|
"rootDir": "src",
|
|
"strict": true,
|
|
"esModuleInterop": true,
|
|
"skipLibCheck": true,
|
|
"declaration": true,
|
|
"jsx": "react-jsx",
|
|
"lib": ["ES2022", "DOM", "DOM.Iterable"]
|
|
},
|
|
"include": ["src"],
|
|
"exclude": ["src/**/*.test.ts"]
|
|
}
|