Otonom görevlerde binary success/fail yanlış sinyal veriyor

PM2 cron ile çalışan otonom görevlerde klasik yaklaşım şöyle: shell komutu çalıştır, exit code 0 ise başarılı say, değilse Telegram'a bildir. Sorun şu: exit code 0 döndüğünde aslında ne kadar "iyi" olduğunu bilmiyorsun.

Servis sağlık kontrolü düşün. Komut 8 servis online döndürdüğünde başarılı sayılıyor. Ama beklediğin 8 değil 6 ise? Veya kritik servislerin bir kısmı listenin dışında kalmışsa?

PAI Algorithm v3.7.0'dan bir kavram: ISC

ISC (Ideal State Criteria) — her görev için "başarı nasıl görünür?" sorusunun önceden yazılmış, tek tek doğrulanabilir cevapları.

`json
"isc": [
"ISC-1: 8 kritik servis online durumda",
"ISC-2: gbrain servis listede mevcut",
"ISC-3: telegram-bot servis listede mevcut"
]
`

Uygulama

goals tablosuna isc JSONB ve isc_progress JSONB ekle. Her başarılı çalışma sonrası çıktıyı kriterlere göre değerlendir:

`python
def evaluate_isc(output: str, isc: list[str]) -> dict:
passed, failed = [], []
for criterion in isc:
label, _, desc = criterion.partition(":")
keywords = desc.strip().lower().split()[:4]
if any(kw in output.lower() for kw in keywords):
passed.append(label.strip())
else:
failed.append(label.strip())
return {"passed": passed, "failed": failed, "pending": []}
`

Sonuç üç duruma ayrılıyor: tam başarı, kısmi başarı (bazı ISC geçmedi), tam başarısızlık. Telegram bildirimi de buna göre şekilleniyor:

`
Kısmi Başarı
servis-saglik-check ISC: 2/3
FAIL ISC-3
`

Ek fayda: effort-based timeout

ISC ile birlikte her göreve bir effort_level da atayabilirsin. standard görevler 120 saniyede timeout alırken deep görevler 1920 saniyeye kadar çalışabilir. Sabit 60 saniye yerine göreve göre bütçe.

---

Yön değişikliği basit: "çalıştı mı?" sorusundan "ne kadar iyi çalıştı?" sorusuna. Özellikle birden fazla koşulu kontrol eden izleme görevlerinde fark belirgin oluyor.

---