Verify Bilang 0 Fail, Bug Tetap Sempat Lolos ke Live

Dua bug pertama: token kepotong, paragraf pecah

Hari itu artikel baru selesai di-publish, tool verify saya bilang 0 fail, dan pas halamannya dibuka, heading-nya kepotong: "Masalahnya: push ke" doang, sisanya nyasar ke baris baru. Kode inline kayak main kepencet enter di sembarang tempat, tiap potongan dikasih jarak vertikal sendiri. Satu paragraf yang ada lima kode inline bisa pecah jadi belasan blok.

Dugaan pertama saya salah total. Saya kira konten artikelnya yang bikin masalah, HTML yang saya generate kurang rapi. Setelah ditelusuri ke komponen frontend, biang keroknya ada di sana: parser artikel motong HTML di setiap tag <code> inline (memang disengaja, biar token embed di dalam kode nggak jadi widget hidup), tapi renderer-nya menampilkan tiap potongan sebagai div terpisah di dalam container yang otomatis ngasih jarak antar elemen. Perbaikannya cuma dua belas baris: potongan HTML berurutan digabung balik jadi satu div sebelum dirender.

Verify saya nggak nangkep itu sama sekali. Tool-nya ngecek struktur SEO, bentuk code block, token embed. Bukan hasil layout di mata pembaca.

Bukan satu-satunya. Sebelum itu, token diagram Mermaid di artikel strategi branch tampil sebagai teks polos {mermaid:Z3JhcGg... beneran kelihatan di halaman live. Penyebabnya receh: saya merangkai konten pakai f-string Python, dan f-string melahap kurung ganda. %7B%7Bmermaid:%7D%7D (kurung ganda, ditulis ter-escape) yang saya maksud jadi {mermaid:}, dan regex frontend cuma kenal versi kurung ganda. Sekarang tiap artikel lewat placeholder plus assertion regex sebelum push: satu kurung = build gagal, bukan halaman rusak.

Gate yang saya pasang sesudahnya

Dari dua insiden itu saya ubah pipeline jadi kayak CI: dry-run dulu, push sebagai draft, verify wajib 0 fail, baru publish. Terus saya tambah gate-gate baru di tool verify:

Style gate buat artikel Indonesia: frasa template AI standar (yang biasa nongol di draf pertama model bahasa) langsung fail. Em-dash lebih dari tiga, subheading lebih dari tiga buat artikel pendek, bold kebanyakan, jadi warning. Translation gate buat pasangan artikel id/en: struktur code block wajib identik, comment boleh diterjemahkan, jumlah dan posisi baris comment juga wajib sama. Rollback otomatis: verify gagal setelah publish, artikel ditarik ke draft sendiri tanpa nunggu saya bangun. Arsip lokal kesimpen tiap push. Sitemap dicek pakai polling tiap 15 detik, bukan sleep tetap yang bisa kepancungan.

Translation gate itu saya uji dengan matrix empat kasus sebelum dipasang:

# comment boleh beda bahasa, struktur nggak boleh bergeser
compare_code_blocks(a, b_trans)    # (True, '')
compare_code_blocks(a, b_no)       # (False, 'blok #1: 4 vs 3 baris')
compare_code_blocks(a, b_moved)    # (False, 'posisi baris comment bergeser')
compare_code_blocks(a, b_changed)  # (False, 'struktur code non-comment bergeser')

Empat-empatnya jalan sesuai harapan. Saya pikir urusan selesai.

Tiga celah yang bikin saya nggak percaya gate 100 persen

Beberapa jam setelah gate dipasang, saya dapat pertanyaan balik yang bikin saya diem dulu: CSS itu kamu petakan ke comment //? CSS nggak punya //. Saya cek kodenya. Bener. css masuk keluarga bahasa strip // padahal comment CSS pakai /* */. Konsekuensinya dua arah sekaligus: comment CSS terjemahan nggak pernah di-strip jadi dianggap perubahan struktur, dan // yang saya strip di CSS justru bukan sintaks sah di sana.

Perbaikan pertamanya masih bocor. Baris pembuka /* kestrip, tapi baris penutup blok multi-baris masih nyimpen sisa teks comment, dan teks itu dianggap kode. Solusinya bukan regex per baris lagi tapi state machine kecil yang ngikutin kondisi buka-tutup comment lintas baris.

Ada juga php yang saya biarin begitu saja. Comment-nya ambigu: bisa #, bisa //, bisa /* */. Strip salah arah lebih bahaya daripada nggak strip sama sekali, jadi php saya perlakukan fully verbatim. Stack saya FastAPI plus Next.js, kode php hampir pasti nggak akan pernah muncul di konten saya. Nulis parser robust buat bahasa yang nggak pernah dipakai itu kerja sia-sia, menurut saya.

Celah	Kenapa lolos	Perbaikan
Comment code diterjemahkan antar locale	Gate verbatim ketat menandainya fail, tapi aturannya sendiri yang keliru: comment memang sewajarnya ikut bahasa lokal	Rev A: struktur verbatim, comment bebas bahasa, posisi baris wajib sama
CSS dipetakan ke //	Comment CSS (/* */) nggak pernah di-strip	Family comment ketiga plus state machine
Blok /* */ multi-baris	Fix pertama cuma cari pembuka di tiap baris, baris penutup bocor	Strip dengan state buka-tutup lintas baris

Polanya yang bikin saya mikir dua kali: satu celah ketahuan gate tapi aturannya salah, dua celah sisanya lolos total dan cuma ketahuan karena ada yang nanya. Gate itu bagus nangkep masalah yang udah saya kenal. Yang belum saya kenal, tetap butuh manusia.

Jadi cron harian pipeline artikel saya sekarang mode draft-only. Fase riset topik sampai verify jalan otomatis, tapi publish tetap nunggu saya nekan tombolnya. Kapan tombol itu dilepas, udah saya tulis eksplisit: sepuluh artikel beruntun tanpa koreksi apa pun sebelum approve, dan definisi koreksinya tajam, bukan cuma gate merah, plus sudah pernah lewat minimal satu kasus edge dari tiap kategori yang pernah bikin gate keliru. Angka sepuluh aja belum tentu bikin saya nyaman tinggalin checkpoint.

Gate minggu depan mungkin bisa lolos sepuluh artikel beruntun. Keputusan buat mulai percaya itu tetap saya yang ambil, pelan-pelan, dengan bukti.