טלמטריה מובנית (OpenTelemetry) על שכבת-הסוכנים (השראת Gastown OTel) #449

New Issue

chaim · 2026-08-05T11:01:17Z

chaim commented

2026-08-05 11:01:17 +00:00

What & Why

לפלוט אירועי OTel מובנים על מחזור-חיי הסוכנים (session lifecycle, wake_reason, disposition, mail/comment-routing, recovery-actions) כדי להפוך דיבוג לולאות-recovery מפורנזיקה-ידנית (שאילתות SQL) לנראוּת בזמן-אמת.

הקשר ופירוט

מקור-השראה: Gastown OTel data-model — events over session lifecycle, agent state, bd calls, mail, sling/done, daemon restarts (docs/otel-data-model.md).

הבעיה אצלנו: אבחון לולאות-recovery נעשה ידנית מול Paperclip DB (agent_wakeup_requests, heartbeat_runs, issue_recovery_actions) — ראה reference_paperclip_recovery_loops + reference_recovery_loop_stranded_child. אין ערוץ-נראוּת אחד.

מטרה: instrumentation מובנה בשער-הפלטפורמה (X15) שפולט span/event לכל: wake (reason, issueId, agentId), run-start/end (status), disposition-write (PATCH), comment-routing (sweep hit/coalesced), recovery-action fired, interaction created/reaped.

יעד: OTLP → collector קיים אם יש; אחרת לוגים מובנים JSON קודם, backend אח"כ.
ערך: dashboard/שאילתה "wake_reason=source_scoped_recovery_action פי-N על תיק X" → זיהוי לולאה בזמן-אמת במקום בדיעבד.
זה הזול-מול-תועלת הגבוה ביותר: הופך את 4 המשימות האחרות לנמדדות.
G12: הפליטה מהשער בלבד.
קשור: docs/spec/X16-pipeline-durability.md, project_operations_process_controls.

Acceptance Criteria

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

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

## What & Why לפלוט אירועי OTel מובנים על מחזור-חיי הסוכנים (session lifecycle, wake_reason, disposition, mail/comment-routing, recovery-actions) כדי להפוך דיבוג לולאות-recovery מפורנזיקה-ידנית (שאילתות SQL) לנראוּת בזמן-אמת. ## הקשר ופירוט מקור-השראה: Gastown OTel data-model — events over session lifecycle, agent state, bd calls, mail, sling/done, daemon restarts (docs/otel-data-model.md). הבעיה אצלנו: אבחון לולאות-recovery נעשה ידנית מול Paperclip DB (agent_wakeup_requests, heartbeat_runs, issue_recovery_actions) — ראה reference_paperclip_recovery_loops + reference_recovery_loop_stranded_child. אין ערוץ-נראוּת אחד. מטרה: instrumentation מובנה בשער-הפלטפורמה (X15) שפולט span/event לכל: wake (reason, issueId, agentId), run-start/end (status), disposition-write (PATCH), comment-routing (sweep hit/coalesced), recovery-action fired, interaction created/reaped. - יעד: OTLP → collector קיים אם יש; אחרת לוגים מובנים JSON קודם, backend אח"כ. - ערך: dashboard/שאילתה "wake_reason=source_scoped_recovery_action פי-N על תיק X" → זיהוי לולאה בזמן-אמת במקום בדיעבד. - זה הזול-מול-תועלת הגבוה ביותר: הופך את 4 המשימות האחרות לנמדדות. - G12: הפליטה מהשער בלבד. קשור: docs/spec/X16-pipeline-durability.md, project_operations_process_controls. ## Acceptance Criteria > ⚠️ **טרם הוגדרו.** המשימה הועברה מ-TaskMaster ללא `testStrategy`. > לפני לקיחתה — להגדיר AC ולסמן `status:ready` (כלל התבנית: issue ללא AC אינו pickable). --- <sub>הועבר מ-TaskMaster (tag `legal-ai`, id **219**, status היה `in-progress`) ב-2026-08-05. הפניות `(#219)` בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.</sub>

chaim added the area:agents status:in-progress type:feature priority:p1-high labels 2026-08-05 11:01:17 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#449