chore(tasks): add #76-78 — Paperclip create-task button + 2 precedent-upload bugs

#76 צור-משימה button (enabled but submit no-ops), #77 committee-upload
field mapping (citation→case_number, case_number uneditable), #78 silent
extraction wakeup failure. Discovered while debugging precedent 8027-25.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-02 11:57:24 +00:00
parent 77ed0361b7
commit 7e34c53224

View File

@@ -2481,6 +2481,42 @@
"priority": "high",
"subtasks": [],
"updatedAt": "2026-06-01T04:43:40.474Z"
},
{
"id": "76",
"title": "תיקון כפתור \"צור משימה\" ב-Paperclip — מאופשר אך submit חוזר בשקט",
"description": "במודאל \"משימה חדשה\" של Paperclip, הקלדת כותרת בעברית מציגה את הטקסט והכפתור \"צור משימה\" שחור/מאופשר (לא disabled) — אך לחיצה לא שולחת שום בקשה ואין שגיאה בקונסול. אומת מול access-log: אין POST ל-.../issues. כלומר ה-onChange כן נורה (b=true, הכפתור מאופשר), אבל ה-onClick handler חוזר מ-guard פנימי לפני ה-mutate. חוסם יצירת משימה ידנית לכל סוכן/לוח, לא רק לתור החילוץ.",
"details": "Paperclip צד-שלישי (PM2, לא Docker). bundle: ~/.npm/_npx/*/node_modules/@paperclipai/server/ui-dist/assets/index-*.js. אבחנה מהבדיקה: submit handler בנוסח `function xi(){ const je=m.current.trim(); if(!ee||!je||He.isPending) return; He.mutate({...}) }` — הטקסט (je) קיים, אז ה-guard שנכשל הוא `ee` (ערך נדרש נוסף — לזהות מהו: company/board/project/agent target). שלב 1: לאתר ב-bundle את ה-handler המדויק ומה `ee` מייצג, ולמה הוא falsy במודאל הזה (אולי target company/project לא נקבע כש-prefill מגיע מתוך לוח \"תור חילוץ\"). שלב 2: תיקון קבוע דרך מנגנון ההזרקה הקיים — shim ב-~/.paperclip/hebrew/translate-he.js (נטען בכל טעינה, שורד restart דרך start-paperclip.sh wrapper) שמשלים את הערך החסר / מאזין לאירוע ה-submit. שלב 3: apply דרך `bash ~/.paperclip/hebrew/apply-hebrew.sh` + Ctrl+Shift+R, ולבדוק יצירת משימה. עוקף זמני שתמיד עובד: API ישיר — `~/legal-ai/scripts/pc.sh POST /companies/<cid>/issues '{...}'`. הערה: בזרימה הרגילה מניעים סוכנים בעיקר דרך תגובה על issue (CEO מנתב) — להחליט אם המודאל בכלל נחוץ.",
"testStrategy": "לאחר ה-shim: לפתוח \"משימה חדשה\", להקליד כותרת עברית, ללחוץ \"צור משימה\" → לוודא POST /issues ב-access-log + ה-issue מופיע בלוח. לבדוק גם בלוח רגיל (לא תור חילוץ) ובשתי החברות.",
"status": "pending",
"dependencies": [],
"priority": "high",
"subtasks": [],
"updatedAt": "2026-06-02T00:00:00.000Z"
},
{
"id": "77",
"title": "תיקון מיפוי שדות בהעלאת פסיקת ועדת-ערר — מראה-מקום נדחס ל-case_number; case_number לא ניתן לעריכה",
"description": "בטופס העלאת פסיקה (precedent-upload-sheet), עבור החלטות ועדת-ערר ה-frontend ממפה את שדה \"מראה המקום\" אל case_number (`case_number: citation.trim()`), כך שהמזהה הייחודי מקבל את המראה-מקום הארוך במקום מספר תיק נקי (למשל '8027-25'). בנוסף case_number כלל לא קיים ב-PrecedentUpdateRequest — אז מסך העריכה לא יכול לתקן אותו בדיעבד. citation_formatted נשאר ריק בהעלאה (מתמלא רק בחילוץ מטא). תוצאה ב-8027-25: case_number=מראה-מקום, case_name=מראה-מקום, מראה-מקום ריק עד החילוץ.",
"details": "קבצים: web-ui/src/components/precedents/precedent-upload-sheet.tsx:121-123 (committee path ממפה citation→case_number); web/app.py:5147-5163 (PrecedentUpdateRequest חסר case_number); mcp-server/.../internal_decisions.py (id_field=case_number, display_name_fallback=case_number); precedent_metadata_extractor.py:247-253 (guard: case_name מתוקן רק אם ריק או ==case_number, לכן לא תיקן). תיקון מוצע: (1) בטופס committee — שדה נפרד \"מספר תיק (מזהה ייחודי)\" שממפה ל-case_number, ולמפות \"מראה המקום\" ל-citation (→citation_formatted), במקום לדחוס הכל ל-case_number; (2) להוסיף case_number ל-PrecedentUpdateRequest כדי שהעריכה תוכל לתקן בדיעבד (update_case_law כבר מתיר אותו); (3) להריץ `npm run api:types`. ראה כללי השם שהוגדרו: מזהה ייחודי = שם הקובץ/מספר תיק; מראה-מקום בשדה שלו; שם קצר = שם הצד.",
"testStrategy": "להעלות פסיקת ועדת-ערר עם מספר תיק + מראה-מקום נפרדים → לוודא case_number=מספר התיק, citation_formatted=מראה-מקום, case_name=שם קצר. לפתוח עריכה ולוודא שניתן לתקן case_number.",
"status": "pending",
"dependencies": [],
"priority": "high",
"subtasks": [],
"updatedAt": "2026-06-02T00:00:00.000Z"
},
{
"id": "78",
"title": "כשל שקט ב-wakeup לחילוץ פסיקה — חילוץ אוטומטי לא רץ והתיק נתקע ב-pending",
"description": "אחרי העלאת פסיקה, הבקאנד מסמן metadata+halacha כ-pending וקורא ל-pc_wake_for_precedent_extraction להעיר את ה-CEO. הקריאה נבלעת בשקט (try/except 'non-fatal') — אם PAPERCLIP_BOARD_API_KEY חסר מחזיר {ok:false,skipped:no_api_key}, או שה-wakeup API נכשל — והתוצאה: ה-CEO לא מתעורר, לא רץ חילוץ מטא ולא חילוץ הלכות, וה-UI מציג 'ממתין לחילוץ' לנצח. קרה ב-8027-25 (תוקן ידנית עם precedent_process_pending). זה גם הסיבה ששדות המטא (תקציר/headnote/תגיות/citation) היו ריקים.",
"details": "קבצים: web/app.py:5250-5262 (wakeup best-effort, exception נבלעת); web/paperclip_client.py:816-820 (skip שקט כש-no api key) ו-~905-907 (כשל API נבלע). תיקון מוצע: (1) להציף את הכשל למשתמש — סטטוס מובחן (extraction_wakeup_failed / 'ממתין-לעיבוד-ידני') ב-UI במקום 'pending' אילם; (2) fallback אוטומטי — אם ה-wakeup נכשל, או job מתוזמן (כמו sync-case-status) שמנקז את התור עם precedent_process_pending, או retry; (3) לאמת אם PAPERCLIP_BOARD_API_KEY מוגדר בקונטיינר (Coolify env) — אם לא, להוסיף. עיין reference: project_precedent_auto_extraction. לא לבלוע exceptions בשקט (feedback_silent_swallow).",
"testStrategy": "להעלות פסיקה חדשה ולוודא שחילוץ מטא+הלכות רץ אוטומטית (CEO מתעורר), או שבכשל wakeup מופיע סטטוס שגיאה ברור + מסלול ניקוז אוטומטי. לבדוק שאין 'pending' אילם.",
"status": "pending",
"dependencies": [],
"priority": "high",
"subtasks": [],
"updatedAt": "2026-06-02T00:00:00.000Z"
}
],
"metadata": {