19 uç · /api/callcenter/v1/watch
İstek örnekleri ucun GERÇEK metodu ve yolundan üretilir. 19 ucun elle doğrulanmış gövde örneği henüz yok; o uçlarda iskelet gövdesizdir — uydurma bir alan yazmıyoruz.
idEskiden yalnız "hepsini geri al" vardı: AI üç şey yaptıysa ve biri yanlışsa, doğru olan ikisini de feda etmek gerekiyordu. Denetim ancak düzeltme kalem kalem yapılabildiğinde işe yarar.
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/actions/<id>/revert" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}harcar, yani okuma değil operasyonel bir eylemdir.
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/chat" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idÖn-koşullar onay ANINDA yeniden çalışır (`sweeper::approve_pending`): öneri üretildiğinden bu yana hedef silinmiş ya da kaynak kuyruk kritikleşmiş olabilir. Onay bir zaman makinesi değildir — o andaki dünyaya karşı doğrulanır.
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/approve" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idolayları nöbetçi kendisi kapatır, bkz. `incident::close_orphaned`; bu uç genel amaçlıdır ve elle kapatacak bir uç olmadığı için önceden HİÇ yoktu). Sıra: önce KOŞULLU kapat (aynı zamanda 404 kontrolü), SONRA geri al — `actions::apply`ın durum-kapısı (`state not in ('resolved','closed')`, bkz. actions.rs) sayesinde `state` 'closed'a geçtiği ANDAN itibaren yeni müdahale yazılamaz; kapanışı önce yazmak eşzamanlı bir AI turunun geri almadan SONRA yeni bir müdahale sokup onu asılı bırakmasını engeller — aynı desen `sweeper.rs::sweep_tenant` adım (1)'de zaten kullanılıyor (kapat → sonra geri al).
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/close" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idPlanlama ve uygulama nöbet turunda yürür; uzun iş HTTP isteğini bloklamaz.
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/delegate" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idcurl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/own" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idcurl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/reject" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idcurl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/incidents/<id>/revert" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}L3 öncesinde oluşturma ucu YOKTU (yalnız tohumlanan 8 kural vardı) — hedefler ancak elle SQL ile yazılabilirdi, yani özellik fiilen kullanılamazdı.
curl -X POST "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/rules" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}idyeni kural yazılır (geçmiş olaylar hangi kuraldan doğduğunu kaybetmesin).
curl -X PATCH "https://{slug}.call.blesyum.app/api/callcenter/v1/watch/rules/<id>" \
-H "Authorization: Bearer <oturum-token>" \
-H "Accept: application/json"{
"data": "…",
"trace_id": "01JC…"
}