Apa itu registri
Setiap kelas bug yang berulang dalam sejarah FlareWatch telah disarikan menjadi safeguard bernomor: aturan satu paragraf, justifikasi, dan penunjuk ke tempat dalam kode yang memberlakukannya. Safeguard baru ditambahkan ketika muncul kelas bug atau pola yang harus dicegah agar tidak terulang.
Registri adalah dokumen kerja, bukan materi pemasaran. Tujuannya adalah menjaga agar tim — dan loop review berbasis audit-first yang digunakan tim — tetap konsisten tentang aturan mana yang berlaku di mana. Registri direferensikan dari komentar kode inline (misalnya, // Safeguard 24) sehingga pembaca file mana pun dapat menemukan aturan yang mengatur baris-baris sekitarnya.
Halaman ini adalah ringkasan publik. Registri lengkap berada di repositori sumber bersama kode yang diaturnya. Tujuan di sini adalah memberikan peneliti keamanan, peninjau grant, atau kontributor prospektif gambaran tentang kategori yang dicakup registri dan jenis disiplin yang diterapkannya.
Mengapa registri
Registri safeguard hanya bermanfaat jika mencegah bug yang sama terjadi dua kali. Rekam jejak registri adalah jawabannya:
- Setiap safeguard menyebutkan bug yang dicegahnya. Aturan tanpa insiden yang diingat di belakangnya bukan safeguard, melainkan preferensi gaya. Preferensi gaya seharusnya ada dalam aturan lint, bukan dalam registri.
- Safeguard direferensikan dari kode, bukan hanya dari dokumen. Perubahan kode yang melanggar safeguard terbaca sebagai tanda peringatan pada waktu review karena nomor safeguard ada di komentar sekitarnya.
- Beberapa safeguard diberlakukan secara otomatis. Sebagian diberlakukan melalui aturan ESLint atau skrip shell yang berjalan di CI. Sisanya mengandalkan disiplin penulis plus pola review berbasis audit-first, yang telah terbukti berhasil dalam praktik.
- Registri dijaga tetap konsisten oleh tes. Beberapa safeguard dikunci oleh tes regresi yang membaca file sumber sebagai string dan menegaskan bahwa anti-pola tidak muncul. Kerapuhan adalah fitur: refactor di masa depan yang kembali ke anti-pola akan gagal tes sebelum regresi mencapai produksi.
Kategori
Registri diorganisir berdasarkan domain. Kategori di bawah ini stabil; safeguard spesifik di dalam masing-masing ditambahkan saat mode kegagalan baru ditemukan.
| Kategori | Apa yang dicakup |
|---|---|
| Autentikasi & otorisasi | Titik kontrol tunggal untuk validasi sesi, pemeriksaan kepemilikan per-dompet pada setiap rute, penolakan lintas-token antara token akses dan refresh, gating rute admin. |
| Integritas data | Normalisasi alamat, kontrak konversi unit di batas produsen/konsumen, disiplin pembuat kunci, dan aturan menentang penyatuan diam-diam kegagalan menjadi nilai nol. |
| Pembacaan on-chain | Aturan implementasi tunggal untuk setiap nilai yang dibaca dari kontrak pintar, resolusi alamat kontrak dari registri on-chain, dan aturan menentang penduplikasian logika reward. |
| Keakuratan tampilan | Format angka, mata uang, dan tanggal terpusat; keamanan null pada setiap tampilan numerik; disiplin pelabelan APR vs. APY; disiplin tingkat pajak-sebagai-efektif. |
| Peringatan & notifikasi | Sumber kebenaran tunggal untuk evaluasi peringatan di klien dan server; daftar izin eksplisit untuk peringatan mana yang tersebar ke dompet yang dipantau; aturan supersesi sehingga peringatan "reward tiba" membatalkan peringatan lama "reward tersedia"; sinkronisasi pemberhentian lintas-perangkat. |
| Persistensi & cache | Aturan untuk kapan penyimpanan kanonis adalah backend kunci-nilai versus localStorage; disiplin migrasi; cache service worker yang terikat deploy; penolakan dinamis eksplisit untuk rute yang membaca status live. |
| UI & siklus hidup | Gerbang kesiapan halaman, lantai monoton yang mencegah nol transien menggantikan saldo yang diketahui, dan aturan untuk rendering skeleton selama jendela cold-fetch. |
| Proses & peralatan | Aturan untuk persetujuan peluncuran fitur eksplisit, menjalankan rangkaian tes lengkap pada perubahan permukaan peringatan, pencatatan terstruktur dalam kode sisi server, dan disiplin tinjauan menentang perbaikan gaya pintas. |
Beberapa aturan representatif
Ini adalah ringkasan yang aman untuk publik tentang perlindungan yang mengilustrasikan karakter registri. Aturan ini diparafrasakan dan disingkat; teks kanonik ada di samping kode.
Sumber kebenaran tunggal untuk pembacaan on-chain
Nilai apa pun yang dibaca dari smart contract — hadiah yang dapat diklaim, saldo, status staking, data epoch, harga — dihitung oleh tepat satu fungsi dalam lapisan layanan. Setiap fitur yang membutuhkan nilai tersebut mengimpor fungsi yang sama. Jika dua fungsi menghitung nilai yang sama, salah satunya salah; aturannya adalah menghapusnya, bukan menambah fungsi ketiga.
Titik hambatan tunggal untuk validasi sesi
Setiap rute terautentikasi di FlareWatch memvalidasi cookie sesi melalui satu pembantu tunggal. Tidak ada pengendali rute yang memverifikasi token sesi secara independen. Invarian ini adalah yang membuat pencabutan sisi server universal — tidak ada pintu samping yang melewati pemeriksaan.
Gating kepemilikan per-dompet, kedua sisinya
Rute per-dompet memverifikasi kepemilikan di sisi server, bukan sisi klien. Audit asli menetapkan aturan karena pekerjaan sebelumnya telah menutup gerbang sisi klien tetapi meninggalkan endpoint sisi server sepenuhnya tanpa gerbang. Kedua bagian sekarang dilacak sebagai deliverable eksplisit terpisah — ditutup di klien, ditutup di server — untuk mencegah mode kegagalan itu berulang.
Gunakan pemformat terpusat, tidak pernah inline
Semua pemformatan angka, mata uang, dan tanggal melalui serangkecil pembantu terpusat. Tidak ada komponen yang memformat inline. Aturan ini tidak ada hubungannya dengan gaya: ketika definisi lokal atau mata uang tunggal berubah, setiap permukaan dalam aplikasi diperbarui dengannya. Penyimpangan antar permukaan bersifat diam dan sulit dideteksi sampai pengguna menyadarinya.
Konversi satuan didokumentasikan di kedua ujung
Ketika dua bagian sistem menukar nilai yang satuannya mungkin ambigu (detik vs. milidetik, desimal vs. persentase, alamat huruf kecil vs. checksummed), konvensi didokumentasikan baik di produsen maupun konsumen. Komentar di hanya satu ujung akan membusuk; hanya kontrak batas yang diklaim di kedua ujung yang bertahan dari refaktor.
Satu implementasi per tindakan pengguna
Setiap tindakan yang dimulai pengguna — menambah dompet yang diawasi, mengubah tarif pajak, menutup peringatan, keluar — memiliki tepat satu implementasi. Aturan ini ada karena tindakan yang dipicu dari bagian UI yang berbeda dulunya berdrift dengan cara yang halus: satu titik masuk akan menghapus cache, yang lain tidak, dan sebuah kelas bug "nilai basi setelah operasi X" akan terjadi.
Mode kegagalan yang harus terlihat jelas
Beberapa mode kegagalan bersifat senyap — reward yang salah klasifikasi, ketidaksesuaian unit yang mengubah notifikasi menjadi no-op, record dismiss yang tidak pernah sampai ke key-value store. Jika memungkinkan, registry mewajibkan bahwa produsen nilai-nilai ini mendeklarasikan kontrak mereka cukup keras sehingga perubahan di masa depan yang melanggarnya gagal dengan berisik, dalam test, sebelum mencapai produksi.
Bagaimana registry berkembang
- Safeguard baru. Ditambahkan ketika suatu kelas bug berulang atau satu bug cukup mahal untuk membenarkan aturan permanen.
- Safeguard yang digantikan. Disimpan dalam registry dengan penanda "superseded" dan pointer ke pengganti, sehingga referensi historis dalam kode tetap dapat ditafsirkan.
- Dipromosikan dari catatan kerja. Beberapa safeguard dimulai sebagai aturan informal dalam dokumen handoff sesi dan dipromosikan ke registry setelah terbukti bobotnya.
- Penyapuan kuartalan. Pengecualian lint sementara dan penanda "to-do by next quarter" diperiksa setiap kuartal. Apa pun yang sudah ketinggalan zaman baik diselesaikan atau secara eksplisit diperpanjang.
Mengapa ini dipublikasikan
FlareWatch mempublikasikan ringkasan ini, daripada registry internal lengkap, karena dua alasan.
- Registry internal berisi detail tingkat kode (path file, nama schema key-value, timestamp insiden) yang berguna untuk tim dan reviewer keamanan dengan akses kode, tetapi tidak sesuai untuk dipublikasikan tanpa akses tersebut.
- Kategori dan disiplin adalah cerita sebenarnya. Reviewer grant atau peneliti keamanan yang mengevaluasi FlareWatch ingin tahu jenis proyek apa itu, seberapa serius ia memperlakukan kebenaran, dan seperti apa loop kerjanya — bukan file mana yang berisi aturan #91.
Peneliti yang ingin membahas safeguard tertentu, mengusulkan yang baru, atau melaporkan kesenjangan diundang untuk menghubungi kami di [email protected].
Bacaan lebih lanjut
- Arsitektur — bagaimana FlareWatch dibangun.
- Fitur Keamanan — autentikasi, otorisasi, header, riwayat audit.