CEO: move issue to in_review while waiting on chaim
All checks were successful
Build & Deploy / build-and-deploy (push) Successful in 3m7s

Paperclip auto-blocks any in_progress issue without a live execution path
within ~1 minute of the run finishing. When the CEO ends a run with an
@chaim question pending, the main case issue was staying in_progress and
getting auto-blocked, flooding the case timeline with "automatically
retried continuation" system comments (7 occurrences on 2026-04-16).

Add an explicit status protocol to the CEO instructions:
- in_review at the end of any run that leaves a pending @chaim question
- in_progress when resuming from user_commented (also at start of comment routing)
- done only after final export

Applied at all three @chaim waiting points (stages B/C) and at the top
of comment routing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-04-19 05:52:21 +00:00
parent c619c22a51
commit e88e5f3849

View File

@@ -120,6 +120,18 @@ python3 /home/chaim/legal-ai/scripts/notify.py \
## תהליך אינטראקטיבי — שלב אחר שלב
### כלל קריטי: ניהול סטטוס issue בנקודות המתנה לחיים
ה-issue הראשי של התיק (כותרת `[ערר NNNN-NN] ...`) חי לאורך כל הליך ההחלטה.
Paperclip חוסם אוטומטית כל issue ב-`in_progress` שאין לו run פעיל — תוך דקה ממתי שה-run מסתיים. אם תשאיר issue כ-`in_progress` בזמן שאתה ממתין לתגובה מחיים, המערכת תפרסם system comment `automatically retried continuation` ותעביר ל-`blocked`. זה רעש ובלבול.
**הכלל:**
1. **בכל run שמסתיים עם `@chaim — ...` ממתין לתגובה** → עדכן את ה-issue הראשי ל-`status=in_review` לפני סיום ה-run.
2. **בכל run שמתעורר עם `wake_reason=user_commented`** (או כל המשך עבודה אחרי תגובת חיים) → החזר את ה-issue הראשי ל-`status=in_progress` בתחילת הטיפול.
3. **רק כשהשלב הסופי (export) הסתיים** → סגור עם `status=done`.
**יוצא מהכלל:** issues קצרי-מועד שאתה יוצר לסוכנים אחרים (מנתח/כותב/QA) — סוכן היעד מטפל בסטטוס שלהם, לא אתה.
### שלב 0: בדוק למה התעוררת
**לפני כל דבר אחר** — בדוק את סיבת ההתעוררות (`$PAPERCLIP_WAKE_REASON`):
@@ -211,6 +223,8 @@ python3 /home/chaim/legal-ai/scripts/notify.py \
@chaim — הגב עם מספר (1/2/3) + הערות אם יש
```
**אחרי פרסום ה-comment:** עדכן את ה-issue הראשי ל-`status=in_review` (ראה "כלל קריטי: ניהול סטטוס issue" בראש הסעיף).
לאחר שחיים בחר תוצאה, שאל אותו לסמן טיפול בכל טענה:
```
@@ -233,12 +247,15 @@ python3 /home/chaim/legal-ai/scripts/notify.py \
@chaim — סמן בטבלה והחזר
```
**אחרי פרסום ה-comment:** עדכן את ה-issue הראשי ל-`status=in_review`.
**מתי לחזור אחורה:** אם הסיכום לא מצליח לנסח שאלות כסילוגיזמים מכווצים — ייתכן שחסר מידע עובדתי או נורמטיבי. חזור למנתח/חוקר להשלמה.
### שלב C: קליטת תוצאה וכיוונים סילוגיסטיים
**מתי:** חיים הגיב עם מספר תוצאה + טיפול בטענות
0. **החזר את ה-issue הראשי ל-`status=in_progress`** (קיבלת קלט והמשכת לעבוד).
1. קרא את ה-comment של חיים
2. זהה את הבחירה (1=rejected, 2=partial, 3=accepted)
3. הרץ `set_outcome(case_number, outcome, reasoning)`
@@ -307,12 +324,15 @@ python3 /home/chaim/legal-ai/scripts/notify.py \
אפשר גם לשלב כיוונים או להוסיף הערות.
```
**אחרי פרסום ה-comment:** עדכן את ה-issue הראשי ל-`status=in_review`.
**מתי לחזור אחורה:** אם לא ניתן לבנות סילוגיזם מלא (חסר כלל, חסרות עובדות, או המסקנה לא נובעת) — חזור לחוקר תקדימים או למנתח להשלמת החסר.
### שלב D: אישור כיוון והפעלת כתיבה
**מתי:** חיים הגיב עם בחירת כיוון
0. **החזר את ה-issue הראשי ל-`status=in_progress`** (קיבלת קלט והמשכת לעבוד).
1. קרא את ה-comment של חיים
2. זהה כיוון (1/2/3) + הערות נוספות
3. **אימות שלמות chair_directions** — לפני שליחה לכותב, ודא:
@@ -519,6 +539,8 @@ case_prefix="${case_number:0:1}"
כשאתה מתעורר בגלל תגובה חדשה (reason מכיל "user_commented"):
0. **החזר את ה-issue הראשי ל-`status=in_progress`** — אם ה-issue ב-`in_review` (כי המתנת לחיים) או ב-`blocked` (כי Paperclip חסם אוטומטית), הראשון דבר: עדכן ל-`in_progress` כדי לסמן שאתה עובד עליו.
1. **קרא את ה-comments האחרונים** על ה-issue שצוין ב-prompt:
```bash
curl -s -H "Authorization: Bearer $PAPERCLIP_API_KEY" \