Veilig Melden

Masalah

Saluran pelaporan hanya berguna kalau orang yang memakainya percaya pada saluran itu. Dari situ muncul batasannya: tidak ada kata sandi yang bisa lupa atau dipakai ulang oleh pelapor, garis yang jelas antara apa yang dilihat karyawan dan apa yang dilihat HR perusahaan, dan notifikasi yang benar-benar sampai; laporan yang gagal terkirim diam-diam lebih buruk daripada tidak ada fitur pelaporan sama sekali.

Masalah kedua: jaring pengamannya belum ada. Commit pertama di proyek ini justru yang memasang Playwright, jadi semua yang dirilis sebelumnya hanya lewat pemeriksaan manual. Membangun jaring itu tidak mudah karena sasarannya terus bergerak: aplikasinya sedang ditulis ulang dari SPA Vue ke Nuxt, dan selama itu layout serta komponen landing berpindah folder lebih dari sekali dan kode locale-nya diganti nama. Spec yang ditulis di atas tanah yang lama rusak berlapis: pertama soal selector yang tidak pernah disepakati, lalu soal timing, dan satu spec dashboard akhirnya disentuh delapan belas kali. Setup-nya tersebar di setiap berkas sampai akhirnya disentralkan, ada dua berkas duplikat atau salah nama, dan Firebase Admin diinisialisasi ulang di setiap test worker paralel, kegagalan yang datangnya berisik.

Solusi

Aplikasinya adalah SPA Vue 3 di Firebase Hosting. Rutenya dipisah per pengguna (landing, employee, company, login), dan guard autentikasi mewajibkan alamat email terverifikasi sebelum apa pun di balik halaman login bisa diakses. State-nya terikat langsung ke Firestore lewat VueFire, bukan lewat library store: tidak ada state klien di sini yang layak disentralkan. Foldernya diorganisir per domain (company, employee, landing) alih-alih per jenis berkas, dan validasinya memakai skema Zod yang sama di kedua sisi. Semua yang keluar dari browser melewati empat Cloud Function bertipe HTTPS callable, bukan trigger database: tautan login, pengiriman laporan, serta alur kontak dan permintaan penghentian. Email dikirim lewat Amazon SES dengan template HTML yang ditulis sendiri dan BCC ke kotak masuk platform, jadi selalu ada salinan yang tersimpan di luar tenant pelanggannya.

Frontend-nya sedang ditulis ulang dengan Nuxt 4, satu halaman demi satu halaman, sementara aplikasi lama tetap jalan. Karena palet warna, Raleway, dan skala tipografinya berada di preset UnoCSS bersama (bukan di dalam salah satu aplikasi), kedua frontend tetap tampil identik selama masa perpindahan. Keduanya tersedia dalam bahasa Belanda dan Inggris.

Agar perpindahan itu aman, test-nya perlu sesuatu yang stabil untuk dipegang. Selector dipindahkan keluar dari class CSS dan teks yang terlihat, masuk ke atribut data-testid di komponennya sendiri, termasuk satu testid yang di-generate per opsi, sehingga satu opsi dropdown bisa ditarget lewat slug-nya alih-alih lewat labelnya yang diterjemahkan. Seluruh spec lalu ditulis ulang memakai getByTestId, dan penamaannya diseragamkan. Berikutnya flakiness: penantian statis diganti assertion atas kondisi yang nyata (toBeVisible dengan timeout, .or() saat salah satu dari dua state sama sahnya, dan penantian domcontentloaded pada navigasi), lalu sisa-sisa debug dihapus. Setup pindah ke beforeEach dan test.use, skenarionya dikelompokkan dengan test.step, dan nama berkasnya dirapikan. Firebase Admin yang paling menggigit: guard di sekitar getApps() menghentikan inisialisasi ganda, dan cache instance Auth di level modul membuatnya hanya sekali per proses di antara worker paralel. Form kontaknya lalu selesai dari ujung ke ujung: composable, plugin, emulator beserta aturan Firestore dan Storage, dan endpoint server yang merender template email lalu mengirimkannya lewat SES.

Satu hal masih tersisa, dan layak disebut: ID tiket dan satu kata kerja commit masih bertypo di riwayat. Perbaikan yang tahan lama untuk itu adalah hook pesan commit, bukan kehati-hatian tambahan.