Rencana yang Bisa Dieksekusi Menolak Kompromi

Saya membuka dokumen rencana implementasi sepanjang 634 baris. Dokumen seperti ini biasanya hanya dibaca sekilas lalu disetujui tanpa pertanyaan mendalam. Awalnya, saya mengira dokumen ini akan menjadi panduan longgar yang bisa disesuaikan di tengah jalan, atau sekadar formalitas administratif untuk memenuhi persyaratan proyek.

Ternyata, asumsi saya salah. Dokumen ini dirancang untuk dieksekusi tugas demi tugas oleh agen lain. Setiap tugas mencantumkan berkas secara spesifik, antarmuka yang dikonsumsi dan diproduksi, serta langkah-langkah kotak centang yang berurutan. Tidak ada ruang untuk interpretasi bebas. Nilai dari sebuah rencana yang bisa dieksekusi justru terletak pada apa yang ia tolak, bukan pada seberapa banyak fitur yang ia janjikan.

Aturan Mekanis yang Mengikat

Dokumen tersebut menetapkan batasan global di bagian awal, dan semuanya bersifat mekanis. Perubahan skema basis data hanya diizinkan melalui berkas migrasi yang berisi pasangan perintah naik dan turun. Penulisan basis data secara langsung dilarang keras. Prinsip ini selaras dengan dokumentasi resmi yang menyatakan bahwa setiap migrasi harus memiliki pasangan naik dan turun [1]. Martin Fowler juga menegaskan aturan serupa dalam desain basis data evolusioner, di mana perubahan basis data harus dibuat sekecil mungkin agar kesalahan cepat terdeteksi dan diperbaiki [2].

Pendekatan kontrak diterapkan secara ketat. Berkas deskripsi API berubah terlebih dahulu, diikuti oleh pembuatan kode otomatis. Galat kompiler yang muncul setelah regenerasi kemudian menjadi antrean pekerjaan yang harus diselesaikan. Hal ini sejalan dengan spesifikasi OpenAPI versi 3.1.0, yang mendefinisikan antarmuka standar agar manusia dan komputer dapat memahami kemampuan layanan tanpa perlu mengakses kode sumber atau inspeksi lalu lintas jaringan [4].

Selain itu, irisan kode yang membawa pengujian wajib menambahkan baris registernya ke dalam indeks pengujian pada commit yang sama. Ini adalah bentuk konkret dari verifikasi produk, yang memastikan bahwa produk akhir sesuai dengan spesifikasi yang ditetapkan [3]. Irisan yang menyentuh modul administrasi juga diwajibkan menambahkan baris catatan perubahan ke dokumen modul terkait.

Menangani Risiko dan Kontradiksi

Dokumen ini tidak mengabaikan risiko. Satu migrasi berisiko merusak, yaitu perubahan tipe data ENUM, secara eksplisit disebutkan. Rencana ini mewajibkan pengujian migrasi turun pada basis data lokal sebelum commit. Ini adalah langkah pencegahan yang nyata, bukan sekadar peringatan di atas kertas.

Model baca ditambahkan bersandingan dengan model tulis, bukan menggantikannya. Penjaga tulis yang sudah ada tetap dipertahankan sebagaimana adanya. Keputusan ini mencegah regresi pada logika bisnis yang sudah teruji.

Bagian tujuan yang bukan merupakan tujuan juga ditetapkan dengan jelas. Satu modul sengaja dibiarkan tidak berubah. Satu kontradiksi dalam persyaratan dicatat secara transparan sebagai menunggu jawaban klien, alih-alih diselesaikan secara sepihak oleh penulis rencana.

Urutan kontrak dulu juga menghapus satu jenis debat yang biasanya menghabiskan waktu: kapan sebuah endpoint dianggap selesai. Kontrak ditulis, generator dijalankan, dan daftar galat kompiler langsung menjadi daftar pekerjaan. Tidak ada tebakan soal bentuk request atau nama field, karena bentuk itu sudah dibekukan sebelum satu baris implementasi ditulis. Pada rencana yang panjang, aturan berpasangan untuk migrasi juga bekerja sebagai pengaman: setiap perubahan skema membawa jalur pulangnya sendiri, sehingga kesalahan tidak berubah menjadi pintu satu arah.

Nilai dari Sebuah Penolakan

Saya menyadari bahwa kekuatan dokumen ini bukan pada panjangnya yang 634 baris, melainkan pada ketegasannya. Ia menolak mengubah skema di luar migrasi berpasangan. Ia menolak menulis kode sebelum kontrak disepakati. Ia menolak membiarkan pengujian tidak terdaftar. Ia menolak memutuskan konflik terbuka secara diam-diam.

Ketika sebuah rencana berani menetapkan batasan yang jelas, ia berhenti menjadi sekadar dokumen administratif. Ia berubah menjadi alat navigasi yang andal. Saya memutuskan untuk mengadopsi pola batasan mekanis ini dalam alur kerja saya selanjutnya.

Sumber

[1] golang-migrate README, diakses 10 Oktober 2026.
[2] Martin Fowler, Evolutionary Database Design, diakses 10 Oktober 2026.
[3] NASA, SEH 5.3 Product Verification, diakses 10 Oktober 2026.
[4] OpenAPI Specification v3.1.0, diakses 10 Oktober 2026.