From 7e34c53224d307619db6ec27a8f85ed631bd7d0e Mon Sep 17 00:00:00 2001 From: Chaim Date: Tue, 2 Jun 2026 11:57:24 +0000 Subject: [PATCH 1/2] =?UTF-8?q?chore(tasks):=20add=20#76-78=20=E2=80=94=20?= =?UTF-8?q?Paperclip=20create-task=20button=20+=202=20precedent-upload=20b?= =?UTF-8?q?ugs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #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) --- .taskmaster/tasks/tasks.json | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/.taskmaster/tasks/tasks.json b/.taskmaster/tasks/tasks.json index 003b0c7..287fd57 100644 --- a/.taskmaster/tasks/tasks.json +++ b/.taskmaster/tasks/tasks.json @@ -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//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": { From d790fb26e0ea9ba1ea2a88602f4146879144dd2b Mon Sep 17 00:00:00 2001 From: Chaim Date: Tue, 2 Jun 2026 11:57:24 +0000 Subject: [PATCH 2/2] docs(lessons): weekly chair-feedback lessons #34-35 (week ending 2026-05-31) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #34 don't manufacture doubt about unambiguous statutes (s.19(ג)(2)); #35 writer/QA two-sources-of-truth sync gap (DB vs drafts/decision.md). Output of the weekly-feedback-analysis job, pending commit. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/legal-decision-lessons.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/legal-decision-lessons.md b/docs/legal-decision-lessons.md index 6c48960..ba72daa 100644 --- a/docs/legal-decision-lessons.md +++ b/docs/legal-decision-lessons.md @@ -446,3 +446,21 @@ The draft's biggest structural error was adding the "נבאר" doctrinal paragra - [ ] Update block-schema.md: block order for 1xxx cases (ט before ז) - [ ] Update daphna-architecture-by-outcome.md: add "bridge planning" analysis for rejections - [ ] Update writer system prompt: mandatory "להלן מתוך" pattern + +--- + +## Lessons from Weekly Feedback (May 31, 2026) + +### Source +- Chair feedback summary for week ending 2026-05-31 +- Case: 8126-03-25 (ערר על חבות בהיטל השבחה - יעקב עמיאל), entries from CMPA-62 + +### 34. Don't Manufacture Doubt About Clear Statutes +- **Lesson:** סעיף 19(ג)(2) לתוספת השלישית קובע באופן חד-משמעי כי תקופת המגורים היא ארבע שנים מגמר הבנייה — אסור להציע "פרשנות חלופית" של שנה אחת או להכניס שאלות פתוחות על נוסח חוק שהוא ברור; הצגת ספק מלאכותי בכלל ברור מערפלת את הניתוח ומחלישה את הכרעה. +- **Rule:** When a statutory provision is unambiguous on its face, the analysis must state it as the binding rule — not as one possible reading among others. Spurious interpretive doubt is a methodology failure, not a sign of intellectual humility. + +### 35. Writer/QA Sync Gap — Two Sources of Truth +- **Problem:** legal-writer updates `decision_blocks` in the DB, but legal-qa reads from `drafts/decision.md` on disk. In CMPA-62 the writer reported updating block headers in DB but the file did not re-sync, causing QA-2 to fail on exactly the same issue twice. +- **Lesson:** Single source of truth is mandatory — either the writer must write to BOTH the DB and the decision.md file in one atomic step, or there must be an automatic `regenerate-draft` hook that runs after every block update so the file always reflects the latest DB state. Two unsynchronized sources will keep producing the same false-fail loop. +- **Owner:** Infrastructure task — not a writer/QA prompt fix. +