Fix 12 of 15 pipeline gaps found in 1130-25 test run
Test run on case 1130-25 revealed critical gaps. This commit fixes: HEARTBEAT.md (#1, #11): - Agents MUST wake CEO after completing any task (wakeup request) - New "blocked" status option — agents cannot mark "done" if something failed - Fallback: direct DB insert if API wake doesn't work legal-analyst.md (#2): - New step 6: completeness checks BEFORE finishing - Verify all appeal/response documents extracted successfully - Verify all extracted documents produced claims - Verify classification is correct (no claims from committee) - If any check fails → status = "blocked", not "done" legal-ceo.md (#3, #6, #7, #12, #13, #14, #15): - Step A rewritten with 3 sub-checks: A1: extraction completeness (no missing documents) A2: negative checks (wrong classification, abnormal counts, missing parties) A3: methodology compliance (syllogisms, CREAC prep, steel-man, etc.) - Any failure blocks progress to step B legal-qa.md (#6 reinforcement): - New step 2b: negative checks on the written decision - Missing issues, bare quotes, empty formulas, mixed findings/conclusions Also: - Synced all agent files to /home/chaim/legal-ai/ (Paperclip reads from there) - Synced methodology + lessons + corpus docs - Fixed claim classification in DB: 20 committee/applicant claims → response (#5) Remaining gaps (3): - #4: Paperclip cache may need restart to pick up new definitions - #7: Matmon document retry (25K words, 0 claims extracted) - #9: 53 appellant claims may need synthesis (high but not blocking) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -43,7 +43,7 @@ curl -s -X POST -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
|
||||
**לפני שאתה מסיים, תמיד:**
|
||||
|
||||
פרסם comment על ה-issue:
|
||||
### 4א. פרסם comment על ה-issue
|
||||
```bash
|
||||
curl -s -X POST -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
@@ -51,7 +51,9 @@ curl -s -X POST -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-d '{"body": "סיכום העבודה..."}'
|
||||
```
|
||||
|
||||
עדכן סטטוס issue:
|
||||
### 4ב. קבע סטטוס — done או blocked
|
||||
|
||||
**אם המשימה הושלמה בהצלחה** (כל המסמכים חולצו, כל הבדיקות עברו, אין חסימות):
|
||||
```bash
|
||||
curl -s -X PATCH -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
@@ -59,6 +61,37 @@ curl -s -X PATCH -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-d '{"status": "done"}'
|
||||
```
|
||||
|
||||
**אם המשימה נכשלה או חסומה** (מסמך לא חולץ, timeout, חוסר מידע, שגיאה שלא ניתנת לפתרון):
|
||||
```bash
|
||||
curl -s -X PATCH -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
"$PAPERCLIP_API_URL/api/issues/{issue-id}" \
|
||||
-d '{"status": "blocked"}'
|
||||
```
|
||||
**אסור** לסיים issue כ-"done" אם יש כשל שלא טופל. "done" = הכל הושלם בהצלחה. אם משהו נכשל — "blocked".
|
||||
|
||||
### 4ג. העֵר את העוזר המשפטי (CEO) — חובה!
|
||||
אחרי כל סיום משימה (done או blocked), **העֵר את העוזר המשפטי** כדי שיבדוק תוצאות ויחליט על הצעד הבא:
|
||||
```bash
|
||||
curl -s -X POST -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
"$PAPERCLIP_API_URL/api/agents/752cebdd-6748-4a04-aacd-c7ab0294ef33/wake" \
|
||||
-d '{"reason": "סוכן [שמך] סיים משימה [issue-id] בסטטוס [done/blocked]. נדרשת בדיקה והחלטה על הצעד הבא."}'
|
||||
```
|
||||
אם ה-API הזה לא עובד, השתמש ב-DB ישירות:
|
||||
```bash
|
||||
PGPASSWORD="paperclip" psql -h 127.0.0.1 -p 54329 -U paperclip -d paperclip -c "
|
||||
INSERT INTO agent_wakeup_requests (company_id, agent_id, source, reason, status, requested_by_actor_type)
|
||||
VALUES (
|
||||
(SELECT company_id FROM agents WHERE id = '$PAPERCLIP_AGENT_ID'),
|
||||
'752cebdd-6748-4a04-aacd-c7ab0294ef33',
|
||||
'agent_completion',
|
||||
'סוכן סיים משימה — נדרשת בדיקה והחלטה על הצעד הבא',
|
||||
'pending',
|
||||
'agent'
|
||||
);"
|
||||
```
|
||||
|
||||
## 5. התראת מייל — כשנדרשת תשובה אנושית
|
||||
|
||||
**כשהתוצאה דורשת החלטה או תשובה של חיים**, שלח מייל:
|
||||
|
||||
@@ -154,7 +154,34 @@ tools:
|
||||
- `find_similar_cases` — תיקים דומים
|
||||
הוסף תוצאות רלוונטיות תחת כל סוגיה כ-"תקדימים מהקורפוס הפנימי".
|
||||
|
||||
## שלב 6: שמירה ודיווח — חובה!
|
||||
## שלב 6: בדיקת שלמות — לפני שמסיימים!
|
||||
|
||||
**לפני סיום, בצע את הבדיקות הבאות. אם בדיקה נכשלת — אל תסיים כ-"done".**
|
||||
|
||||
### 6א. שלמות חילוץ מסמכים
|
||||
בדוק: **האם כל מסמך מסוג appeal/response/reply חולץ ויצר טענות?**
|
||||
```
|
||||
query: SELECT d.title, d.doc_type, d.extraction_status,
|
||||
(SELECT count(*) FROM claims WHERE source_document LIKE '%' || d.title || '%' AND case_id = d.case_id) AS claim_count
|
||||
FROM documents d WHERE d.case_id = '{case_id}' AND d.doc_type IN ('appeal', 'response', 'reply')
|
||||
```
|
||||
- אם יש מסמך עם extraction_status != 'completed' → **נסה שוב** (retry עם timeout ארוך, או פצל לחלקים)
|
||||
- אם יש מסמך עם extraction_status = 'completed' אבל 0 טענות → **נסה לחלץ טענות שוב**
|
||||
- אם ניסיון חוזר נכשל → **סטטוס issue = "blocked"**, לא "done". דווח מה נכשל ולמה.
|
||||
|
||||
### 6ב. בדיקת סיווג
|
||||
בדוק: **האם הסיווג הגיוני?**
|
||||
- אם יש claims (claim_type='claim') מצד ועדה מקומית או מבקשי היתר → **שגיאת סיווג**. תקן ל-response.
|
||||
- אם יש יותר מ-30 טענות (claim_type='claim') מעורר אחד → **ייתכן חוסר סינתוז**. בדוק: האם טענות חוזרות? האם אפשר לאחד?
|
||||
|
||||
### 6ג. בדיקת צד חסר
|
||||
בדוק: **האם כל צד מיוצג בטענות?**
|
||||
- אם אין אף claim מהעוררים → חריגה
|
||||
- אם אין אף response מהמשיבים → חריגה
|
||||
|
||||
## שלב 7: שמירה ודיווח — חובה!
|
||||
|
||||
**רק אם כל בדיקות שלב 6 עברו:**
|
||||
|
||||
1. **שמור** את הפלט המלא:
|
||||
```
|
||||
@@ -162,7 +189,8 @@ tools:
|
||||
```
|
||||
|
||||
2. **פרסם comment** ב-Paperclip עם סיכום:
|
||||
- כמה טענות, תשובות ותגובות חולצו
|
||||
- כמה טענות חולצו (מפורט: X טענות עוררים, Y תשובות משיבים, Z תגובות)
|
||||
- **האם כל המסמכים חולצו בהצלחה** (כן/לא — אם לא, פרט מה נכשל)
|
||||
- הסוגיות המרכזיות (3-5 כותרות)
|
||||
- כמה שאלות מחקר הופקו
|
||||
- המלצה לשלב הבא
|
||||
@@ -176,6 +204,8 @@ tools:
|
||||
"סיכום: X סוגיות זוהו, Y שאלות מחקר הופקו. נדרשת ביקורתך לפני המשך."
|
||||
```
|
||||
|
||||
**אם בדיקות שלב 6 נכשלו** — סטטוס issue = "blocked", פרסם comment עם פירוט מה נכשל, שלח מייל לחיים.
|
||||
|
||||
## מבנה הפלט המלא — analysis-and-research.md
|
||||
|
||||
```markdown
|
||||
|
||||
@@ -58,21 +58,38 @@ tools:
|
||||
|
||||
## תהליך אינטראקטיבי — שלב אחר שלב
|
||||
|
||||
### שלב A: בדיקת מצב + אימות איכות פלט מנתח
|
||||
### שלב A: בדיקת מצב — שלמות, בדיקות שליליות, תאימות מתודולוגיה
|
||||
|
||||
בכל heartbeat:
|
||||
1. בדוק תיקים פעילים (`case_list`)
|
||||
2. לכל תיק — בדוק סטטוס + מה כבר בוצע:
|
||||
- יש טענות מחולצות? (`get_claims`)
|
||||
- יש comments מחיים שממתינים לתגובה?
|
||||
3. **אימות איכות פלט מנתח** — לפני מעבר לשלב B, ודא שפלט המנתח תואם את המתודולוגיה:
|
||||
- טענות מסווגות לפי claim/response/committee
|
||||
- עובדות שאינן שנויות במחלוקת מזוהות
|
||||
- מסמכים נורמטיביים (תכניות, חוקים) מצוינים
|
||||
- אם הפלט חסר — צור issue למנתח לתיקון לפני שממשיכים
|
||||
4. פעל לפי מפת הסטטוסים למטה
|
||||
2. בדוק אם יש issues ב-"blocked" — אם כן, טפל בהם קודם
|
||||
3. בדוק comments מחיים שממתינים לתגובה
|
||||
4. **לפני מעבר לשלב B — בצע את כל הבדיקות למטה. אם בדיקה נכשלת — עצור.**
|
||||
|
||||
**מתי לחזור אחורה:** אם פלט המנתח חסר טענות מרכזיות, לא מזהה מסמכים נורמטיביים, או לא מבחין בין עובדות שנויות/לא שנויות במחלוקת — החזר למנתח עם הנחיה ספציפית.
|
||||
#### A1. בדיקת שלמות חילוץ
|
||||
- **כמה מסמכים בתיק?** (`document_list`) — ספור.
|
||||
- **האם כל המסמכים מסוג appeal/response/reply חולצו?** — בדוק extraction_status. אם יש מסמך שנכשל → **עצור**. צור issue למנתח לתיקון.
|
||||
- **האם כל מסמך שחולץ ייצר טענות?** — אם מסמך מסוג appeal/response ייצר 0 טענות → **עצור**. אין להמשיך עם מידע חלקי.
|
||||
|
||||
#### A2. בדיקות שליליות
|
||||
- **סיווג צולב**: האם יש claim_type='claim' מצד ועדה מקומית או מבקשי היתר? → שגיאת סיווג. החזר למנתח.
|
||||
- **כמות חריגה**: האם יש צד עם >30 טענות (claim_type='claim')? → ייתכן חוסר סינתוז. בדוק ודווח.
|
||||
- **צד חסר**: האם יש צד שאין לו אף טענה? → חריגה.
|
||||
- **מסמך ריק**: האם יש מסמך appeal/response עם טקסט שלא ייצר טענות ולא דווח ככשל?
|
||||
|
||||
#### A3. אימות תאימות מתודולוגיה
|
||||
קרא את `analysis-and-research.md` ובדוק:
|
||||
- [ ] סוגיות מנוסחות כסילוגיזם (כלל + עובדות + שאלה)?
|
||||
- [ ] ממצאים עובדתיים מופרדים ממסקנות משפטיות?
|
||||
- [ ] לכל סוגיה יש "סוג ניתוח" (כלל ברור / איזון / מידתיות)?
|
||||
- [ ] לכל סוגיה יש "הכנה ל-CREAC" (כלל, עובדות, תקדים)?
|
||||
- [ ] יש steel-man (הנקודה החזקה של הצד החלש)?
|
||||
- [ ] יש סעיף "טיפול בטענות" (bundle/skip)?
|
||||
- [ ] היררכיית מקורות: חקיקה לפני תקדימים?
|
||||
|
||||
**אם בדיקה כלשהי נכשלת → אל תמשיך לשלב B.** צור issue למנתח עם הנחיה ספציפית, ופרסם comment שמסביר מה חסר.
|
||||
|
||||
**עיקרון מנחה:** עדיף לעכב את התהליך מאשר לייצר החלטה על בסיס חלקי או פגום.
|
||||
|
||||
### שלב B: הכנת סיכום, סיווג, ושאלת תוצאה
|
||||
|
||||
|
||||
@@ -85,11 +85,19 @@ tools:
|
||||
2. הרץ בדיקת איכות (`validate_decision`)
|
||||
3. קבל מדדים (`get_metrics`)
|
||||
|
||||
### שלב 2: בדיקה ידנית
|
||||
### שלב 2: בדיקה ידנית — חיובית
|
||||
1. קרא את בלוק ו — בדוק ניטרליות
|
||||
2. השווה טענות בבלוק ז מול דיון בבלוק י — בדוק כיסוי
|
||||
3. בדוק מספור רציף
|
||||
|
||||
### שלב 2ב: בדיקות שליליות — מה חסר? מה לא הגיוני?
|
||||
1. האם יש סוגיה מה-analysis-and-research.md שלא קיבלה מענה בדיון?
|
||||
2. האם יש ציטוט ארוך ללא סנדוויץ' (הקדמה + ציטוט + ניתוח)?
|
||||
3. האם יש "נוסחאות ריקות" — משפטים שמחיקתם לא משנה כלום?
|
||||
4. האם יש פסקה בדיון ללא משפט נושא (פתיחה שלא מודיעה על הנקודה)?
|
||||
5. האם יש ממצא עובדתי ומסקנה משפטית מעורבבים באותו משפט?
|
||||
6. האם יש אנלוגיה לתקדים ללא הסבר מדיניות (למה הדמיון רלוונטי)?
|
||||
|
||||
### שלב 3: דיווח — חובה!
|
||||
פרסם comment ב-Paperclip עם:
|
||||
- תוצאת כל בדיקה (pass/fail)
|
||||
|
||||
Reference in New Issue
Block a user