ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

תשובת-interaction/הערה על issue בבעלות-אדם לא מעירה את ה-CEO — לנתב דרך פרימיטיב CEO-child (#227) #454

New Issue
Open
opened 2026-08-05 11:01:19 +00:00 by chaim · 0 comments
chaim commented 2026-08-05 11:01:19 +00:00
Owner
Copy Link

What & Why

כשהיו"ר עונה על ask_user_questions (או מגיב) על ה-issue הראשי שמצב-ו in_review ומשויך-לאדם (assignee_user_id=chaim), Paperclip מנסה "wake_assignee" ומוצא אדם → אף סוכן לא מתעורר; והתשובה נשארת תלויה. ניסיון wakeup ידני על ה-issue הזה מבוטל מיד עם issue_assignee_changed. התוצאה: היו"ר מרגיש שההוראה "בוטלה". התיקון הקבוע: לנתב תשובת-interaction/הערה על issue בבעלות-אדם דרך פרימיטיב ה-CEO-child הקיים (wake_ceo_for_action / יצירת issue-ילד בבעלות CEO ואז wakeup עליו) — בדיוק כפי ש-#227 עשה לכפתורי הפקת-המסמכים. כרגע מטופל ידנית לתיק 1027-04-26.

הקשר ופירוט

רקע: #218 (Gastown escalation) הוסיף את escalate_issue שמחנה issue אצל האדם (in_review+assignee_user_id) כדי לעצור recovery-loops — זה הכיוון סוכן→אדם. הכיוון ההפוך (אדם עונה→מעיר CEO) מעולם לא חובר. #227 (PR#398/#399) יצר את פרימיטיב ה-CEO-child (paperclip_client.wake_ceo_for_action, POST /api/issues/{main}/children עם assigneeAgentId=CEO ואז /wakeup) אך חיווט אותו רק לכפתורי "הפקת מסמכים". טווח-התיקון: (1) interaction-response ב-web/app.py /agents/interaction-response — כשה-issue משויך-לאדם, במקום להסתמך על wake_assignee, ליצור CEO-child עם תוכן-התשובה ולהעיר; (2) /agents/comment — כנ"ל כשה-target משויך-לאדם. לשמור G12 (דרך ה-Port). לאמת מול reference_paperclip_recovery_loops (לא ליצור לולאה חדשה: ה-child חייב לסיים ב-disposition). מקרה-מבחן: 1027-04-26 — interaction fdda4b8d נענה 15:15, לא עורר; טופל ידנית ע"י CEO-child CMP-201.

Acceptance Criteria

⚠️ טרם הוגדרו. המשימה הועברה מ-TaskMaster ללא testStrategy.
לפני לקיחתה — להגדיר AC ולסמן status:ready (כלל התבנית: issue ללא AC אינו pickable).

הועבר מ-TaskMaster (tag legal-ai, id 228, status היה pending) ב-2026-08-05. הפניות (#228) בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.

## What & Why כשהיו"ר עונה על ask_user_questions (או מגיב) על ה-issue הראשי שמצב-ו in_review ומשויך-לאדם (assignee_user_id=chaim), Paperclip מנסה "wake_assignee" ומוצא אדם → אף סוכן לא מתעורר; והתשובה נשארת תלויה. ניסיון wakeup ידני על ה-issue הזה מבוטל מיד עם issue_assignee_changed. התוצאה: היו"ר מרגיש שההוראה "בוטלה". התיקון הקבוע: לנתב תשובת-interaction/הערה על issue בבעלות-אדם דרך פרימיטיב ה-CEO-child הקיים (wake_ceo_for_action / יצירת issue-ילד בבעלות CEO ואז wakeup עליו) — בדיוק כפי ש-#227 עשה לכפתורי הפקת-המסמכים. כרגע מטופל ידנית לתיק 1027-04-26. ## הקשר ופירוט רקע: #218 (Gastown escalation) הוסיף את escalate_issue שמחנה issue אצל האדם (in_review+assignee_user_id) כדי לעצור recovery-loops — זה הכיוון סוכן→אדם. הכיוון ההפוך (אדם עונה→מעיר CEO) מעולם לא חובר. #227 (PR#398/#399) יצר את פרימיטיב ה-CEO-child (paperclip_client.wake_ceo_for_action, POST /api/issues/{main}/children עם assigneeAgentId=CEO ואז /wakeup) אך חיווט אותו רק לכפתורי "הפקת מסמכים". טווח-התיקון: (1) interaction-response ב-web/app.py /agents/interaction-response — כשה-issue משויך-לאדם, במקום להסתמך על wake_assignee, ליצור CEO-child עם תוכן-התשובה ולהעיר; (2) /agents/comment — כנ"ל כשה-target משויך-לאדם. לשמור G12 (דרך ה-Port). לאמת מול reference_paperclip_recovery_loops (לא ליצור לולאה חדשה: ה-child חייב לסיים ב-disposition). מקרה-מבחן: 1027-04-26 — interaction fdda4b8d נענה 15:15, לא עורר; טופל ידנית ע"י CEO-child CMP-201. ## Acceptance Criteria > ⚠️ **טרם הוגדרו.** המשימה הועברה מ-TaskMaster ללא `testStrategy`. > לפני לקיחתה — להגדיר AC ולסמן `status:ready` (כלל התבנית: issue ללא AC אינו pickable). --- <sub>הועבר מ-TaskMaster (tag `legal-ai`, id **228**, status היה `pending`) ב-2026-08-05. הפניות `(#228)` בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.</sub>
chaim added the type:bugpriority:p1-higharea:agents labels 2026-08-05 11:01:19 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:agents
סוכני Paperclip, תזמור, שער-הפלטפורמה (X15)
 area:backend
FastAPI web/, endpoints
 area:ci
Gitea Actions, שערי-CI
 area:docs
ספ-המערכת, תיעוד, תכנון
 area:extraction
קליטה, OCR, חילוץ הלכות/מטא/טענות/תכניות
 area:frontend
web-ui/ (Next.js), RTL
 area:infra
Deploy, Coolify, MinIO, אחסון, גיבויים
 area:mcp
שרת ה-MCP וחוזה-הכלים (X9)
 area:retrieval
RAG, חיפוש, קורפוס, גרף-ציטוטים, יומונים
 area:security
אבטחה, סודות, PII, audit
 area:writing
12 הבלוקים, סגנון דפנה, QA, רכישת-סגנון
 priority:p0-blocker
Blocks everything
 priority:p1-high
High priority
 priority:p2-normal
Normal priority
 priority:p3-low
Low priority / nice to have
 size:l
a week+ — consider splitting
 size:m
2-3 days
 size:s
~1 day
 size:xs
< half a day
 status:blocked
Waiting on another issue/decision
 status:deferred
Decided to defer — parked backlog; not auto-picked
 status:good-first-issue
Small, self-contained starting point
 status:in-progress
Being worked on (a branch/worktree exists)
 status:in-review
A PR is open for this issue
 status:needs-decision
Requires a call before proceeding
 status:ready
Scoped + pickable (has acceptance criteria + size)
 type:bug
Something works incorrectly
 type:chore
Infra, deps, refactor, CI, docs
 type:feature
New capability
 type:spike
Time-boxed investigation -> a decision/doc
No Label area:agents priority:p1-high type:bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chaim
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#454
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?