Permission risk register Claude Code: tentukan batas sebelum agen bertindak

Mengapa perlu artifact sendiri

Artikel ini membuat permission risk register untuk tim yang berpindah dari pemakaian Claude Code solo ke aturan approval bersama. Kegagalan umum sangat sederhana: tim baru membahas permission setelah agen sudah mengedit, deploy, atau meminta command berisiko. Workflow Claude Code tidak boleh berhenti pada jawaban yang terdengar yakin. Harus ada artifact yang bisa diperiksa orang lain. Dalam kasus ini artifact-nya adalah register kecil berisi action, keputusan default, proof, dan owner.

Anggap artifact sebagai kontrak antara prompt, command line, dan halaman publik. Ia harus menunjukkan apa yang dibaca Claude Code, apa yang diubah, command mana yang membuktikan hasil, dan revenue path apa yang dilihat pembaca berikutnya. Karena itu topik ini terkait harness engineering, getting started, dan permissions.

Loop operasi

Jalankan loop dalam lima langkah: definisikan action, pilih proof, biarkan Claude Code melakukan pekerjaan terkecil yang berguna, verifikasi output, lalu catat action revenue berikutnya. Proof di sini bukan hanya “kode jalan”. Pantau jumlah approval, command ditolak, rollback note, bukti deploy, dan niat konsultasi. Saat field ini terlihat, perbaikan tidak bergantung pada tebakan.

1. Read-only repo mapping bisa default allow jika final note mencatat area yang dibaca.

2. Edit konten bisa diizinkan saat diff review, build, dan public URL verification wajib.

3. Secrets, billing, customer data, dan force push tetap owner approval meskipun agen akurat.

Starter yang bisa disalin

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

Tiga contoh lapangan

Contoh 1. Read-only repo mapping bisa default allow jika final note mencatat area yang dibaca.

Contoh 2. Edit konten bisa diizinkan saat diff review, build, dan public URL verification wajib.

Contoh 3. Secrets, billing, customer data, dan force push tetap owner approval meskipun agen akurat.

Checklist self-review

Sebelum workflow ini menjadi kebiasaan, review artikel seperti release note. Check pertama adalah scope: pembaca harus tahu kapan memakai permission risk register dan kapan checklist kecil sudah cukup. Check kedua adalah proof: setiap rekomendasi harus menunjuk ke command, URL, diff, atau metric. Check ketiga adalah routing: free PDF, Gumroad guide, dan konsultasi tidak boleh saling bersaing, tetapi menjawab tingkat urgensi yang berbeda.

Tambahkan ownership rule kecil. Satu orang memiliki artifact, satu orang memiliki verifikasi, dan satu orang memiliki eksperimen CTA berikutnya. Dalam workflow solo mungkin orangnya sama, tetapi nama role tetap ditulis. Ini mencegah Claude Code menganggap publishing, measuring, dan selling sebagai satu tugas kabur. Run berikutnya juga tahu dari mana harus lanjut.

Pertanyaan paling praktis adalah: apa yang membuat artikel ini lebih mudah diverifikasi besok pagi? Jika jawabannya screenshot, simpan. Jika jawabannya prompt yang lebih kuat, masukkan ke prompt pack. Jika jawabannya boundary lebih jelas, masukkan ke setup notes. register kecil berisi action, keputusan default, proof, dan owner hanya berguna jika masih bisa dipakai pada sesi berikutnya.

Kegagalan umum

Kegagalan pertama adalah menjadikan pageviews satu-satunya skor. Kedua, menyetujui perubahan tanpa proof command. Ketiga, mengirim semua pembaca ke produk berbayar yang sama, padahal free PDF atau konsultasi lebih cocok. Tulis routing rule sebelum mengubah CTA.

Rute revenue

Arahkan pembaca berdasarkan bottleneck. Jika butuh command fluency, kirim ke PDF gratis atau cheatsheet gratis Gumroad. Jika pekerjaan yang sama berulang tiap minggu, gunakan 50 Prompt Templates atau Setup Guide. Jika masalahnya rollout, risk, atau revenue design, gunakan konsultasi. Untuk artikel ini, Setup Guide memberi baseline policy, sedangkan konsultasi membantu saat approval menyentuh produksi atau revenue.

Metrik verifikasi

Setelah publish, HTTP 200 saja tidak cukup. Periksa h1, canonical, hero image, pembuka body, link CTA, mobile layout, dan bahasa. Lalu pantau jumlah approval, command ditolak, rollback note, bukti deploy, dan niat konsultasi. Jika metrik datar, perbaiki CTA di dekat contoh konkret pertama sebelum rewrite seluruh artikel.