Claude Code Merilis Bug. Saya Buat Mustahil Lewat 4 Fix

Claude Code merilis bug penomoran di repo sungguhan, dan empat perubahan yang disetujui membuat bug itu mustahil dirilis lagi. Sesi itu menulis credit note untuk sebuah API faktur kecil, test suite hijau, lalu pengecekan manual yang dijalankan sesudahnya menemukan bahwa satu request yang ditolak telah menghabiskan satu nomor faktur. Kami lalu menjalankan retro pada sesi itu, menyetujui perbaikannya satu per satu, dan menjalankan tugas yang sama lagi: hasilnya bersih.

Retro adalah review yang dilakukan tim setelah sebuah insiden, di sini dijalankan pada log sesi Claude Code sendiri. Retro pertama kami dibuka dengan "This session was smooth", dan tak satu pun temuannya adalah bug itu. Solusinya adalah tujuh langkah, berurutan: install, jalankan tugas, jalankan retro dan beri tahu apa yang gagal, lacak tiap kandidat, setujui tiap yang selamat ke sebuah carrier, commit dan audit, lalu jalankan ulang tugasnya.

/retro adalah skill buatan Matt Pocock yang me-review sesi coding, bukan kodemu. Ia membaca log sesi, yaitu file yang disimpan Claude Code untuk setiap prompt dan setiap pemanggilan tool, lalu mencari kandidat dalam tujuh kategori, misalnya pengecekan yang bisa menangkap sebuah kesalahan. Ia menyajikan kandidat menurut tingkat keparahan dan, menurut dokumentasinya, hanya mengusulkan: tidak ada yang berubah sampai kamu memilih sebuah kandidat.

Meng-install-nya adalah langkah pertama: di repomu, perbarui marketplace resmi, lalu install skills pack di scope proyek agar hanya hidup di repo ini. Marketplace kami terkunci pada rilis lama tanpa retro, jadi pembaruan harus dilakukan lebih dulu. Di sesi baru, ketik garis miring dan perintah retro muncul di daftar.

Satu batasan: sesi cloud tidak bisa membaca log di mesinmu, jadi jalankan retro di tempat sesinya berlangsung.

Langkah kedua adalah yang sudah kamu lakukan setiap hari: ketik tugas nyatamu di sesi biasa, biarkan selesai, dan biarkan sesinya tetap terbuka, karena itulah yang akan dibaca retro.

Kami memakai API faktur kecil dalam Node dan TypeScript, dengan test suite sendiri dan tanpa file instruksi, tanpa pipeline, dan tanpa commit hook di mana pun. Tugasnya singkat, seperti caramu mengetiknya sendiri: tambahkan credit note ke faktur yang sudah dibayar, bernomor berurutan, dan izinkan faktur yang sudah dibayar dibatalkan dengan mengkredit sisanya.

Sesi itu menulis route, sebuah migrasi, dan tes-nya sendiri, lalu menjalankan suite sebelum berhenti. Kemudian kami menjalankan pengecekan yang akan dilakukan finance secara manual, sebuah tes tersembunyi yang ditulis sebelumnya, dan satu persyaratan gagal.

Sinyal	Hasil
Test suite	42 tes lulus
Type check	bersih
Pengecekan finance tersembunyi	gagal: nomor credit note lebih besar dari yang diharapkan

Penyebabnya: handler mengambil nomor berikutnya dari counter sebelum memvalidasi request, dan counter disimpan begitu dibaca. Credit note yang terlalu besar ditolak, dan itu benar, tapi nomornya tetap hilang, dan itu tidak benar. Sesi itu menyalin urutan tersebut dari route issue yang sudah ada, yang membocorkan nomor faktur dengan cara yang sama.

Kami menjalankan tugas ini dua kali dan run yang satunya lagi bersih, jadi inilah yang kadang dilakukan sesi biasa.

Langkah ketiga adalah mengetik perintah retro di sesi yang sama, lalu menjalankannya lagi dengan kegagalan ditulis di belakangnya. Milik kami dibuka dengan: "This session was smooth."

Ia memeringkat beberapa item, tak satu pun adalah bug: guardrail yang hilang, aturan migrasi yang tak dicek siapa pun, dan tidak ada apa pun yang bisa ditegakkan reviewer. Retro membaca log sesi, dan sesi itu tidak pernah tahu bahwa ia gagal.

Jadi kamu yang memberi tahu: jalankan perintah itu lagi dengan kegagalan sebagai argumennya, yaitu teks setelah perintah. Milik kami berkata bahwa finance telah menguji build-nya, bahwa credit note yang terlalu besar ditolak, bahwa credit note valid berikutnya muncul terlambat, dan bahwa retro tidak boleh memperbaiki apa pun.

Kali ini ia menemukan penyebabnya di kodenya sendiri: ia mengambil nomor dulu dan memvalidasi belakangan, dan ia bilang telah menyalin urutan itu dari handler issue yang ada. Kandidat baru pun muncul: tes yang ia tulis menjalankan urutan yang gagal tetapi hanya memeriksa status code, fungsi counter yang tampak murni padahal tidak, dan sebuah konvensi yang tidak pernah ditulis siapa pun.

Apa pun yang kamu temukan setelah sesi, ketikkan ke argumen, atau retro akan mengaudit sesi yang ia kira berjalan baik.

Langkah keempat adalah yang tidak dilakukan skill ini sendiri: minta retro mengutip momen transkrip di balik tiap kandidat, dan buang setiap kandidat yang tidak bisa ia tunjukkan.

Dokumentasi menjelaskan mengapa daftar berperingkat saja tidak cukup: begitu pekerjaan selesai, model melupakan kesulitan sesinya dan mengarang saran generik. Jadi buang kandidat apa pun yang tidak bisa kamu lacak ke momen tertentu: satu kalimat yang meminta retro mengutip transkrip untuk masing-masing.

Pada retro pertama kami jawabannya lugas: kebanyakan kandidat tidak punya dukungan di transkrip. Ia mempertahankan guardrail yang hilang, karena listing folder hook-nya sendiri tidak mencetak apa pun, dan membuang pengecekan migrasi sebagai hipotetis.

Pada retro kedua, yang sudah tahu soal bug-nya, pelacakan mempertahankan empat kandidat dan membuang satu.

Kandidat	Setelah pelacakan
Tes yang ia tulis (diterima, ditolak, diterima, nomor tak pernah dicek)	dipertahankan, kuat
Fungsi counter tanpa peringatan	dipertahankan, kuat
Konvensi yang tak tertulis	dipertahankan, lebih lemah
Guardrail yang hilang	dipertahankan, meski ia bilang guardrail tidak akan menangkap bug ini
Kandidat terakhir	dibuang: ia menghitung momen yang sama dua kali

Sebuah issue terbuka di repo skill ini menghitung sebagian besar run retro diikuti pengguna yang meminta bukti. Kandidat yang sudah dilacak tetaplah model yang membaca lognya sendiri, jadi baris yang ditandai lebih lemah adalah sebuah penilaian, dan kamulah yang memutuskan mana yang dibawa ke depan.

Langkah kelima adalah tempat loop ini membuahkan hasil: setujui satu yang selamat sekali waktu, masing-masing ke carrier-nya, tempat aturan itu akan tinggal. Skill ini memberimu tangga keputusannya. Pelanggaran mekanis mendapat pengecekan deterministik, titik: aturan di linter, commit hook, atau job di pipeline. Penilaian masuk ke file standar coding yang dibaca reviewer. File instruksimu dipakai, dalam kata-kata dokumentasi, "incredibly sparingly", untuk penunjuk ke file lain.

Kami menyetujui empat perubahan:

• Guardrail yang hilang menjadi commit hook yang dilacak git, yang menjalankan type check dan tes lalu memblokir commit jika salah satunya gagal. Harness menolak membuat file itu executable, jadi kami menjalankan perintah itu sendiri.
• Tes menjadi satu tes vitest yang mengunci aturannya: credit note diterima, credit note ditolak, dan yang valid berikutnya harus membawa nomor berikutnya. Tes itu gagal di run pertamanya, dan itulah intinya: ia menangkap bug yang dirilis sesi tadi.
• Keputusan penilaian menjadi satu baris di CODING_STANDARDS.md baru: ambil nomor urut hanya setelah semua validasi lulus, supaya request yang ditolak meninggalkan urutan tanpa celah.
• Celah navigasi menjadi satu komentar di atas fungsi counter: ia langsung menyimpan counter, jadi nomornya terpakai walau pemanggilnya kemudian gagal, maka panggil hanya setelah validasi.

Itu empat file berubah dan nol baris di CLAUDE.md, karena kedua retro menolak menulisnya. Yang pertama bilang penunjuk di steering file akan memakan konteks di setiap giliran dan menjadi usang; yang kedua bilang simpan sebagai komentar di fungsinya. Dokumentasi mendukung mereka: Claude memperlakukan file-file itu sebagai konteks, bukan konfigurasi yang ditegakkan, dan untuk memblokir sebuah aksi kamu memakai hook.

Dua batasan: hook hanya melindungi commit, dan komentar itu, dalam kata-kata retro sendiri, adalah taruhan pada pemanggil berikutnya, bukan perbaikan yang terbukti.

Langkah keenam adalah commit, dan langkah terakhir adalah menjalankan tugas yang sama lagi, di sanalah kamu tahu apakah loop-nya bertahan.

Saat kami men-stage file yang disetujui dan commit, hook berjalan lebih dulu dan menolak commit. Type check lulus, lalu tes penomoran yang baru gagal, menerima nomor yang lebih besar dari yang diharapkan. Hook memeriksa file sebagaimana adanya di disk, dan disk masih berisi kode yang bermasalah.

Jadi kembali ke sesinya dan minta perbaikannya saja: ambil nomor setelah validasi lulus, jalankan pengecekan, jangan commit. Lalu commit lagi, hook berjalan hijau, dan kamu mendapat dua commit: perubahan retro, lalu fitur beserta perbaikannya. Retro sendiri tidak meng-commit apa pun, hal yang dijelaskan persis kata demi kata oleh sebuah issue terbuka di repo-nya, jadi kamu yang commit.

Berikutnya, jalankan /doctor prompt-audit, pengecekan bawaan Claude Code atas file instruksimu untuk baris yang usang. Ada jebakan di sini: tanpa path, ia mengaudit file global-mu, bukan repo. Dengan path, ia menyebut file standar baru itu bersih, dan menandai bahwa route issue yang lebih lama melanggar aturan, yaitu bug kode dan bukan masalah prompt.

Langkah terakhir adalah sesi baru dengan tugas yang sama. Sesi kami membaca file standar coding, readme, hook, dan tes penomoran yang merah sebelum menulis kode apa pun, lalu menulis di ringkasannya sendiri bahwa nomor diambil hanya setelah semua pengecekan itu lulus, sehingga request yang ditolak tidak meninggalkan celah di urutan.

	Sesi pertama	Sesi baru setelah loop
Tes lulus	42	hijau
Pengecekan finance tersembunyi	gagal	5 dari 5
Nomor setelah request ditolak	terbuang, ada celah	tanpa celah

Satu catatan jujur: sesi baru ini diberi pelajarannya berupa tes merah dan satu baris standar, jadi ini adalah run setelah loop, bukan benchmark.

Retro membaca sesi, jadi apa yang tidak dilihat sesi harus kamu tulis ke argumen. Itulah bagian yang akan membuatmu tersandung.

Jalankan retro setelah sesi yang berjalan salah, sebelum kamu membersihkannya, atau pada log sesi lama. Jangan jalankan secara otomatis atau menyambungkannya ke hook: penulis skill ini sendiri bilang begitu dengan kata-katanya, kamu tidak ingin mengotomatiskan ini. Dokumentasi menambahkan batasan: ia tidak mengaudit pengecekan yang ia usulkan bulan lalu, jadi kamu tetap harus memangkasnya sendiri.

Satu aturan yang perlu diingat adalah kalimat dari dokumentasi sendiri: perlakukan file instruksimu seperti kode, tinjau saat ada yang salah, pangkas secara rutin, dan uji perubahan dengan mengamati apakah perilaku Claude benar-benar bergeser. Loop ini tidak membuat agen menjadi benar, ia membuat kesalahan yang sama lebih cepat tertangkap, dan pengecekan yang kamu tambahkan adalah kode yang kini harus kamu rawat.

Paket gratis untuk video ini berisi checklist retro dengan setiap langkah, pertanyaan pelacakan dan para carrier, plus skrip commit hook dan tes penomoran dari run kami, sehingga kamu bisa mulai dari milik kami.