Satu agent, satu tugas, satu bukti.

Kenapa tangkapan layar lemah sebagai bukti

Tangkapan layar dipotong oleh orang yang membuat klaim. Ia menunjukkan bahwa sesuatu pernah tampak berhasil, dan berhenti di situ. Yang tidak bisa ia bawa: versi paket yang dipasang, konfigurasi yang aktif, hasil yang gagal, dan apa pun yang tidak dicoba.

Ia juga tidak bisa dijalankan ulang. Pembaca berikutnya — termasuk kamu, dua minggu kemudian — tidak bisa membedakan “tool menolak menulis” dari “tool tidak pernah diminta menulis”. Dua keadaan itu terlihat sama di gambar, dan artinya berlawanan.

Ini bukan alasan untuk merekam video atau membangun harness. Cukup tulis apa yang tidak terlihat di gambar.

Sembilan baris yang cukup

Urutannya mengikuti perjalanan percobaan, dari yang dipasang sampai yang masih gelap.

1. Versi dan paket. Nama paket, versi, dan kalau ada hash integritasnya.
2. Tugas. Satu kalimat: apa yang seharusnya berubah atau terbukti.
3. Input. Fixture atau data yang dipakai, dan alasan datanya aman dipakai.
4. Akses yang diizinkan. Folder, akun, atau credential yang benar-benar terbuka.
5. Tindakan yang dijalankan. Perintah atau tool call, bukan ringkasan hasilnya.
6. Output. Artefak yang bisa dibuka lagi: file, JSON, log.
7. Review manusia. Siapa yang membaca hasilnya, kapan, dan apa yang diperiksa.
8. Cleanup. Apa yang dihapus, apa yang sengaja disimpan, dan di mana.
9. Belum diketahui. Batas yang tidak diuji, ditulis eksplisit.

Kalau salah satu baris tidak bisa kamu isi, itu bukan tanda rekamannya kurang lengkap. Itu tanda ada bagian percobaan yang belum kamu periksa.

Contoh nyata: satu percobaan, sembilan baris

Rekaman di bawah ini berasal dari uji Filesystem MCP yang kami jalankan, bukan contoh yang dibuat supaya rapi. Nilai yang bisa dibaca mesin — versi, hash integritas, daftar direktori yang diizinkan, jumlah pemeriksaan, dan transport — dibaca dari evidence.json yang ikut dipublikasikan. Sisanya, yaitu deskripsi tugas, pilihan fixture, dan batas yang belum diuji, tetap kalimat tulisannya kami.

Yang membuat rekaman ini berguna bukan panjangnya, tetapi tiga hal: hash paket dan lockfile ikut dicatat, penolakan ikut dicatat sebagai hasil, dan ada satu baris scope yang menyebut apa yang tidak diuji. Tiga hal itu tidak muat di tangkapan layar.

Satu detail lagi yang mudah hilang: hasil tool yang gagal belum tentu berupa crash. Protokol MCP membedakan error protokol dari error eksekusi tool, dan yang kedua tetap merupakan hasil yang sah untuk dicatat. “Gagal” punya dua bentuk; keduanya perlu masuk rekaman.

Versi paling kecil untuk proyekmu

Kamu tidak perlu harness, CI, atau skema JSON. Satu file Markdown di folder kerja sudah cukup, asalkan sembilan baris di atas terisi. Untuk percobaan yang lebih besar, file hasil seperti evidence.json lebih baik karena bisa dibaca mesin dan dibandingkan antar-versi.

Yang perlu dijaga hanya satu: jangan menulis ulang rekaman lama ketika percobaan baru berbeda. Tambahkan sesi baru dengan tanggal baru. Rekaman yang ditimpa berhenti menjadi bukti dan berubah jadi cerita.

Baris “Review manusia” mengikuti aturan yang sama. Kalau seseorang benar-benar membaca ulang rekaman ini secara manual, catatlah sebagai sesi baru: siapa reviewer, kapan, dan apa yang diperiksa. Tanggal eksekusi bukan tanggal review, dan menambalnya ke rekaman lama hanya menyamarkan keduanya.

Langkah berikutnya

Unduh satu salinan, isi sembilan barisnya untuk percobaan yang sedang kamu jalankan, lalu simpan di sebelah hasil kerjanya.

Unduh agent review notes →

Kalau kamu ingin melihat bagaimana rekaman seperti ini dipakai untuk membantah klaim “read-only”, bacanya ada di studi kasus Filesystem MCP.