Mengukur perubahan, lalu membuktikannya
Perubahan diklasifikasikan lebih dulu, dan klasifikasi itulah yang menentukan seberapa banyak pembuktian yang wajib.
Ringkas dulu
- Apa ini?
- Cara menilai besar dampak sebuah perubahan, lalu menyesuaikan besar pembuktiannya.
- Mengapa penting?
- Kalimat "ini cuma perubahan kecil" adalah alasan paling umum sebuah rilis tidak pernah diverifikasi.
- Bagaimana cara kerjanya?
- Perubahan diberi kelas L0 sampai L4 berdasarkan apa yang bisa terdampak, lalu kelas itu memilih jalur dan tingkat buktinya.
- Contoh konkretnya?
- Mengubah satu baris yang mengatur URL adalah perubahan struktural, bukan suntingan kecil, walaupun jumlah barisnya sama dengan memperbaiki salah ketik.
- Berikutnya baca apa?
- "Merilis tanpa menebak", karena pembuktian berakhir di gerbang rilis.
L0 sampai L4 dengan bahasa biasa
Setiap perubahan diberi kelas sebelum dikerjakan. Kelas ini menggambarkan luas dampak, bukan tingkat kesulitan atau lamanya pengerjaan.
L0 Micro Edit
Perbaikan kecil dan terbatas yang tidak menyentuh perutean, skema, maupun perilaku.
L1 Content / Asset Change
Perubahan isi atau aset pada halaman yang sudah ada, dengan cakupan jelas.
L2 Content Growth
Penambahan isi faktual baru: layanan, artikel, FAQ, atau cakupan maksud pencarian.
L3 Functional / Structural Change
Perubahan perutean, perilaku, pembuatan skema, navigasi, atau tata letak yang signifikan.
L4 Release / Infrastructure Change
Perubahan deployment, server, keamanan, caching, pengalihan, hosting, runtime, atau proses rilis.
Kelas ditentukan oleh apa yang bisa terdampak, itulah sebabnya ia diputuskan sebelum pekerjaan dimulai, bukan dibenarkan setelahnya.
Jalur cepat atau jalur rekayasa penuh
Ada dua jalur rekayasa. Pekerjaan yang kecil, terbatas, dan mudah dibatalkan menempuh Fast Path. Pekerjaan yang berdampak material menempuh Full Engineering Path, beserta perencanaan dan bukti yang mengikutinya.
Kelas perubahan yang memilih jalur. Bukan kenyamanan, bukan tenggat, bukan rasa percaya diri. Satu aturan ini yang menghentikan "ini cuma perubahan kecil" berubah menjadi alasan sebuah rilis tidak pernah diverifikasi.
| Aspek | Memperbaiki salah ketik | Mengubah aturan URL |
|---|---|---|
| Kelas | L0 — Micro Edit | L3 — Functional / Structural Change |
| Yang bisa terdampak | Satu kalimat di satu halaman | Seluruh alamat halaman dan cara mesin pencari menemukannya |
| Jalur | Fast Path | Full Engineering Path |
| Bukti bawaan | Targeted Evidence | Release Evidence |
Bukti secukupnya, tidak kurang
Pembuktian bersifat proporsional. Usaha verifikasi mengikuti luas dampak, tingkat ketidakpastian, dan seberapa mudah perubahan dibatalkan — bukan memilih audit penuh untuk segalanya, atau pemeriksaan sekilas untuk segalanya.
- Targeted EvidenceBukti terarah pada bagian yang berubah dan yang bersinggungan langsung.
- Release EvidenceBukti setingkat rilis, termasuk kesiapan pulih dan jalur yang melayani publik.
- Full Health EvidenceBukti kesehatan menyeluruh, dipakai saat ada pemicu nyata.
Verifikasi luas disediakan untuk pemicu nyata, bukan untuk rutinitas. Pemeriksaan ulang menyeluruh dibenarkan ketika dampaknya luas, bukti sebelumnya sudah basi secara material, muncul anomali atau regresi, ada perubahan dependensi atau runtime yang material, ada perubahan lingkungan produksi yang material, pemilik memintanya secara eksplisit, atau berlaku aturan domain berisiko tinggi.
Ketika sebuah pemeriksaan tidak bisa dijalankan
Kadang pemeriksaan yang seharusnya membuktikan sesuatu tidak tersedia: tidak ada runner, tidak ada peramban, atau tidak ada akses ke lingkungan yang relevan. Situasi ini diperlakukan sebagai keadaan kelas utama, bukan sebagai alasan.
Aturannya: pemeriksaan yang tidak tersedia tidak pernah berubah menjadi lulus. Pekerjaan mencatat substitusi yang bisa dipertanggungjawabkan beserta keterbatasan yang ditinggalkannya. Substitusi tetap harus aman, bisa dibatalkan, bisa diaudit, sebanding dengan risiko, dan didukung bukti.
Contoh konkret
Sebuah pemeriksaan tampilan seharusnya dijalankan di peramban, tetapi peramban tidak tersedia. Yang dicatat bukan "tampilan aman", melainkan: pemeriksaan peramban tidak tersedia, digantikan pemeriksaan struktur keluaran dan pengukuran kontras dari token warna, dengan keterbatasan bahwa hasil visual sesungguhnya belum dilihat. Kalimat itu tetap bisa ditindaklanjuti; klaim "aman" tidak.
Contoh substitusi yang diakui
- repository connector
- CI or runner
- operator-assisted shell
- artifacts
- HTTP probes
- browser smoke
- screenshots
- structured logs
- deterministic scripts
Kekosongan bukti yang jujur masih bisa dipulihkan. Kelulusan yang dikarang tidak, karena semua yang dibangun di atasnya ikut mewarisi karangan itu.
Sumber kanonik yang dijelaskan halaman ini
Halaman ini menjelaskan berkas-berkas berikut. Kalau isinya berbeda, berkas itu yang berlaku — bukan tulisan di sini.
docs/product/DEV-WEB-PRODUCT-REQUIREMENTS.mdkernel/core/adopter-workflow.contract.jsonkernel/core/foundation.contract.json