Status Done di tracker cuma klaim, buktinya ada di Git
Kartu Done tanpa bukti itu kata-kata. Sekarang work item cuma boleh Done kalau hash commit di baris Buktinya beneran resolve di Git.
Ringkasan
Awalnya gue kira status Done di board udah paling bener, ternyata cuma klaim kosong kalau nggak ada bukti commit-nya. Makanya gue bikin gate yang ngunci, kartu baru boleh Done kalau baris "Bukti: hash" di deskripsi beneran ke-resolve di Git. Soalnya hash Git itu nggak bisa bohong, tanggal selesainya juga ngambil dari aktivitas tracker bukan timestamp commit.
Saya lagi ngecek board tracker pagi itu. Satu kartu kerja statusnya udah bergeser ke Done, tapi pas saya buka detailnya: nggak ada link commit, nggak ada tag rilis, kosong melompong. Pertanyaan jujur yang langsung muncul sederhana: apa buktinya kerjaan ini beneran kelar?
Waktu itu saya masih percaya status di tracker adalah sumber kebenaran utama. Logikanya, kalau developer udah repot-repot geser kartu ke kolom selesai, berarti tugasnya beres. Tracker adalah otoritas tunggal yang menentukan progres.
Ternyata anggapan itu salah besar. Status di tracker hanyalah sebuah klaim. Buktinya hidup di repositori Git.
Jadi saya bangun mekanisme pengunci: sebuah work item cuma boleh pindah ke Done kalau bukti pendukungnya, berupa hash commit atau tag yang ditulis sebagai baris teks kelihatan "Bukti: <hash> — <apa> (<tanggal>)", beneran bisa di-resolve di Git. Sejak gate ini jalan, kartu Done di board saya nggak lagi cuma kata-kata.
Hash Git itu bukti yang nggak bisa ditawar
Alasan teknisnya mendasar banget. Git adalah content-addressable filesystem, identitas objeknya diturunkan langsung dari konten itu sendiri [5]. Sifat ini persis jadi alasan kenapa hash yang bisa di-resolve adalah bukti valid: kalau hash-nya resolve, byte-byte kodenya beneran ada di repo, verbatim, dan nggak bisa dipalsukan lewat manipulasi metadata.
Tantangan berikutnya: bukti ini ditulis di mana biar kebaca sistem? Deskripsi work-item di Plane ujung-ujungnya teks biasa yang kelihatan setelah sanitasi sisi server. API-nya otomatis ngasilin field description_stripped [1], dan kontennya dibersihkan lewat sanitizer berbasis allowlist [4]. Konsekuensinya jelas: baris bukti harus teks biasa yang kelihatan mata, bukan disembunyiin di komentar HTML yang bakal dibuang bersih.
Mekanisme di balik layar
Langkah-langkah protokol kayak list, classify, comment, activity, dan relation saya jalanin sebagai panggilan tool MCP [2]. Bukan script nyelip di cron job, tapi alur kerja yang nempel langsung ke siklus hidup tugas.
Pas sesi mulai, sistem ngelompokkan catatan mirror keluar dari penghitungan WIP dan pemilihan tugas aktif, pakai modul Docs Mirror dan label docs-mirror. Batas keras WIP di angka dua, dan rantai blocked_by selalu dilaporin apa adanya, jadi nggak ada tugas yang nyangkut di dependensi yang nggak keliatan.
Ada aturan ketat juga pas porting tugas dari plan: start_date dan target_date format ISO harus eksplisit dua-duanya. Saya nolak keras inferensi tanggal dari jam sistem atau timestamp commit, karena itu gampang meleset gara-gara zona waktu. Porting-nya sendiri idempoten lewat back-link plan-path, jadi dijalanin berkali-kali pun nggak bikin duplikat.
Inti penguncian ada di verify_git_refs. Gate Done jalanin extract_evidence_refs dulu ke deskripsi dan komentar bukti, lalu ngoper hasilnya ke verifikasi Git. Ini satu-satunya batas subprocess di seluruh modul, dan read-only. Satu aja referensi yang gagal resolve, perpindahan ke Done diblokir otomatis, dan sistem nyebutin persis hash mana yang gagal.
Tanggal beneran, bukan tanggal asumsi
Hal yang sering salah dipahami: ngandelin timestamp commit sebagai tanggal selesainya tugas. Di sistem ini, tanggal mulai dan selesai aktual cuma dibaca dari timestamp aktivitas work-item di tracker, bukan dari metadata Git. Commit bisa aja di-push minggu depan buat kode yang ditulis bulan lalu, tapi aktivitas tracker nyatat momen keputusan dan validasinya yang sebenarnya.
Biar logikanya bener-bener kokoh, saya nulis 59 tes fokus yang ngetes helper tersebut lawan repositori scratch beneran. Bukan mock yang dipoles, tapi repo sungguhan yang nyimulasi berbagai skenario gagal resolve. Puncaknya pas sesi Task 7: seluruh rangkaian skill docs-mirror ini diverifikasi live, end-to-end, dan jalan sesuai ekspektasi.
Saya pribadi memang milih jalan yang ketat kayak gini. Nulis hash commit di deskripsi tiap kali nuntutin tugas itu biaya kecil yang kerasa tiap hari. Tapi ketenangan pas tahu tiap kartu Done adalah fakta yang bisa diverifikasi, jauh lebih mahal harganya daripada ilusi produktivitas di board tracker.