Gate pull request agen mana yang harus memblokir merge?

Agen dapat menghasilkan diff yang rapi, deskripsi meyakinkan, dan kode yang lolos tinjauan singkat, tetapi tetap membuat aplikasi terbuka terhadap serangan atau mustahil dipulihkan. Karena itu, keputusan merge harus bergantung pada bukti yang dapat diukur repository, bukan pada nada yakin agen atau kecilnya patch.

Saya memakai tujuh gate pemblokir: pengujian, CodeQL, tinjauan dependensi, pemindaian rahasia, pemeriksaan otorisasi, simulasi migrasi, dan verifikasi rollback. Masing-masing menjawab jenis kegagalan yang berbeda. Test suite hijau tidak membuktikan package baru aman, dan hasil analisis statis yang bersih tidak menjelaskan apakah migrasi database akan mengunci tabel tersibuk.

Gate ini berlaku sama bagi perubahan manusia dan agen. Agen mengubah volume, kecepatan, dan bentuk kesalahan, tetapi tidak membenarkan jalur terpisah yang lebih lemah. Jika perubahan tidak dapat memberikan bukti yang sama dengan pull request lain, perubahan itu belum siap di-merge.

Gate harus menghasilkan bukti, bukan saran

Gate merge harus memberikan hasil pass atau fail yang dapat direproduksi untuk commit persis yang akan masuk ke branch terlindungi. Komentar yang meminta orang meninjau dependensi adalah saran. Required check yang menyebut package, versi, advisory, dan ambang severity adalah bukti.

Perbedaan ini penting karena banyak fitur keamanan secara default hanya melapor setelah saat pengambilan keputusan. Scanner dapat membuat alert, mengirim email, atau membuka issue saat tombol merge tetap tersedia. Tim lalu menyebut scanning sudah aktif meskipun tidak dapat menghentikan perubahan. Periksa empat sifat pada setiap gate:

• Berjalan pada head commit pull request saat ini.
• Branch protection mewajibkan hasil bernama tersebut.
• Job yang dilewati, timeout, atau crash tidak dianggap pass.
• Hasil mencatat detail yang cukup untuk mereproduksi keputusan.

Simpan kebijakan di repository. Manifest kecil lebih mudah ditinjau daripada sekumpulan pengaturan yang hanya diketahui administrator:

merge_gates:
  tests: required
  codeql: required
  dependency_review: required
  secret_scan: required
  authorization: required
  migration_rehearsal: required_when_changed
  rollback_verification: required

required_when_changed bukan celah. Gate lebih dulu mendeteksi file terkait, lalu menjalankan simulasi atau mencatat hasil not applicable dengan jelas. Jangan biarkan path filter membuat required check terus pending, dan jangan izinkan agen mengecualikan perubahannya sendiri yang berisiko.

Batasi izin workflow pada kebutuhan minimum setiap job. Kode pull request adalah input yang tidak dipercaya, meski branch berada dalam organisasi Anda. Gate yang memberikan write token atau secret produksi kepada kode yang diperiksa dapat menciptakan masalah yang lebih parah daripada masalah yang ingin ditemukan.

Lindungi identitas check sebagaimana Anda melindungi logikanya. Aturan branch biasanya mewajibkan nama status, sehingga dua workflow yang melaporkan nama sama dapat membuat job yang lebih lemah memenuhi aturan. Beri nama unik pada job kebijakan, batasi siapa yang dapat mengubah filenya, dan wajibkan tinjauan dari pemilik file. Saat merge queue membuat merge commit baru, jalankan gate lagi pada commit itu atau ikat hasil ke revisi dalam antrean. Bukti untuk head kemarin bukan bukti untuk merge hari ini.

Perlakukan konfigurasi gate sebagai kode sensitif. Pull request yang mengubah ambang, menghapus path, menurunkan query pack, atau menambah pengecualian mengubah arti setiap hasil hijau berikutnya. Tampilkan diff kebijakan dengan jelas dan minta maintainer yang memahami kontrol tersebut. Agen boleh mengusulkan perubahan, tetapi tidak boleh lebih mudah lolos karena mengedit mekanisme yang menilainya.

Pengujian memblokir regresi yang terlihat

Gate pengujian harus memblokir perubahan yang merusak perilaku yang ditetapkan pada versi runtime dan database yang didukung. Gate harus memakai input build yang sama dengan merge commit, termasuk dependensi terkunci, file hasil generasi, feature flag, dan status schema.

Agen sangat pandai memuaskan assertion terdekat. Agen dapat menambah fallback yang membuat satu test hijau tetapi merusak penanganan error, pagination, concurrency, atau kontrak API di sebelahnya. Wajibkan test baru atau yang diubah saat perilaku berubah, tetapi jangan mengukur kualitas dari jumlah baris test. Pastikan test gagal jika implementasi dihapus atau dikembalikan.

Gate pengujian yang berguna memiliki lapisan dengan nama terpisah:

• Unit test untuk logika lokal dan kasus batas.
• Integration test untuk kontrak database, queue, cache, dan layanan eksternal.
• Contract test untuk bentuk request dan response publik.
• Smoke test kecil pada artefak hasil build.

Perbaiki test yang tidak stabil, jangan mengulangnya otomatis sampai hijau. Satu retry boleh mengumpulkan bukti diagnosis, tetapi status akhir harus menunjukkan kegagalan pertama. Jika tidak, agen dapat me-merge kode yang hanya terbukti kadang bekerja.

Smoke test harus memulai artefak, menguji health endpoint dan satu jalur tulis yang bermakna, lalu menghentikannya dengan bersih. Menguji source tanpa memulai aplikasi terkemas melewatkan file yang hilang, default environment buruk, migrasi rusak, dan panic saat startup. Hasil layanan web dapat berbentuk ringkas:

{"commit":"abc123","build":"pass","startup_ms":842,"health":200,"write_read_cycle":"pass"}

Jangan jadikan persentase coverage universal sebagai gate utama. Coverage dapat menunjukkan perubahan yang belum diuji, tetapi repository bisa mendapat angka tinggi dengan assertion lemah. Gunakan suite wajib dan perilaku yang berubah sebagai gate, lalu pakai perubahan coverage sebagai bukti tinjauan.

Lindungi test dari implementasi yang dinilainya. Jika pull request mengubah aturan sekaligus menulis ulang assertion agar menerima hasil baru, suite dapat pass sementara kontrak bergeser diam-diam. Reviewer harus membandingkan test yang berubah dengan API publik, issue, atau aturan penerimaan. Untuk parser, validator, billing, dan akses, tambahkan mutation testing atau input yang sengaja salah. Pertanyaan yang berguna adalah apakah suite menolak implementasi salah yang masuk akal.

Simpan artefak test ketika gate gagal. Simpan seed yang gagal pada test acak, image database yang tepat, log layanan tanpa secret, dan perintah reproduksi. Status tanpa data reproduksi membuat agen atau engineer berikutnya menebak lagi. Batasi retensi sesuai aturan data repository dan jangan mengunggah snapshot produksi hanya agar kegagalan mudah diulang.

CodeQL memblokir jalur kode menuju kerentanan

Gate CodeQL harus memblokir temuan baru dengan confidence tinggi pada bahasa dan artefak generasi yang benar-benar dianalisis CodeQL. Hasil bersih tidak membuktikan seluruh aplikasi aman.

GitHub menjelaskan CodeQL sebagai sistem yang mengompilasi kode menjadi database yang dapat di-query lalu menjalankan query di atasnya. Model ini mengikuti data melalui kode, bukan sekadar mencocokkan teks mencurigakan. Cakupannya tetap dibatasi dukungan bahasa, keberhasilan build, pilihan query, dan kode saat analisis. Jika build database diam-diam mengecualikan sebuah layanan, hasil hijau mencakup lebih sedikit daripada dugaan reviewer.

Gunakan workflow dengan bahasa eksplisit dan kebijakan query tetap:

name: codeql
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  analyze:
    strategy:
      matrix:
        language: [javascript-typescript, go]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

Di repository nyata, pin action pihak ketiga ke digest commit yang sudah ditinjau. Tag membuat contoh mudah dibaca, tetapi tag yang dapat berubah memperluas batas kepercayaan job keamanan wajib.

Tentukan apa yang memblokir sebelum alert pertama muncul. Biasanya saya memblokir temuan baru pada ambang severity dan precision yang disepakati, sementara utang lama tetap terlihat dalam baseline. Memblokir semua temuan historis pada hari pertama mendorong dismissal massal. Mengabaikannya selamanya membuat titik buta. Tetapkan pemilik dan tenggat baseline.

Periksa kumpulan file yang dianalisis ketika layanan, bahasa, atau perintah build berubah. Client mobile baru, resolver hasil generasi, atau backend terpisah mungkin membutuhkan analyzer atau langkah build lain. “CodeQL pass” hanya bermakna jika reviewer dapat menyebut apa yang diperiksa.

Pisahkan kegagalan analisis dari analisis bersih. Jika autobuild gagal mengompilasi package, job harus melaporkan kegagalan infrastruktur atau konfigurasi, bukan nol temuan. Simpan log pembuatan database dan jumlah source yang dianalisis per bahasa. Bandingkan dengan base branch dan tandai penurunan besar tanpa penjelasan. Ini menangkap kegagalan biasa: edit build mengeluarkan modul rentan lalu check menjadi cepat dan hijau karena melihat lebih sedikit kode.

Tinjau dismissal sebagai perubahan kebijakan, bukan pembersihan. False positive perlu penjelasan konkret yang terkait jalur kode dan query. Komentar suppression harus sempit, memiliki pemilik, dan terlihat di diff. Pengecualian seluruh repository untuk file hasil generasi mungkin tepat, tetapi pastikan tidak ada template atau input generator yang dirawat manual di sana.

Tinjauan dependensi menghentikan risiko sebelum instalasi

Tinjauan dependensi harus memblokir pull request bila diff menambah package atau versi yang melanggar kebijakan eksplisit. Kebijakan dapat mencakup severity advisory, lisensi terlarang, sumber package tidak terduga, dan dependensi langsung tanpa pemilik.

Gate ini berbeda dari alert kerentanan repository. Alert mengatakan dependensi rentan ada di branch. Tinjauan dependensi menanyakan apakah pull request membuat graph lebih buruk. Tinjauan GitHub membandingkan manifest dan lockfile sehingga keputusan tepat waktu dan dapat dikaitkan ke perubahan.

Wajibkan konsistensi lockfile. Jika agen mengedit package.json tanpa lockfile, atau mengedit lockfile tanpa perubahan manifest yang cocok, job harus gagal. Perintah instalasi yang me-resolve versi baru di CI membuat hasil tidak deterministik dan dapat menguji graph berbeda dari yang dilihat reviewer.

Kebijakan ringkas dapat berbentuk:

dependency_policy:
  fail_on_severity: high
  deny_licenses:
    - AGPL-3.0
  allow_sources:
    - registry.npmjs.org
    - proxy.golang.org
  require_owner_for_direct_additions: true

Daftar lisensi yang tepat adalah keputusan hukum dan produk, bukan nilai yang layak disalin begitu saja. Yang penting, repository menyatakannya dan check mencetak package pemicunya.

Jangan menyetujui package otomatis karena namanya mirip library yang disarankan. Agen dapat mengarang nama, memilih fork terbengkalai, atau menambah client besar untuk helper kecil. Output harus menunjukkan package langsung dan transitif baru, registry, versi resolved, lisensi, dan status advisory. Reviewer dapat bertanya apakah kode yang ada atau dependensi lebih kecil sudah cukup.

Fail closed jika layanan tidak dapat membuat diff. Feed advisory yang tidak tersedia dapat menjadi alasan menahan merge, bukan mengubah ketidakpastian menjadi hijau. Prosedur darurat dapat memberi override terdokumentasi oleh maintainer bernama, dengan alasan melekat pada commit.

Periksa perilaku instalasi dalam job terisolasi dengan akses jaringan hanya ke registry yang disetujui. Lifecycle script dan build plugin menjalankan kode saat instalasi, jadi package bisa berbahaya meski aplikasi tidak mengimpornya. Catat script instalasi, binary native, atau registry asing yang baru. Jangan beri credential publishing, token cloud, atau cache tulis yang dibagi dengan build terpercaya.

Kode vendored dan container image masuk dalam keputusan yang sama meski tinjauan manifest biasa melewatkannya. Bandingkan digest image, nama base image, Git submodule, dan arsip yang disimpan. Wajibkan digest tetap untuk input release. Tag seperti latest membuat reproduksi nanti mustahil karena byte dapat berubah tanpa diff baru.

Pemindaian rahasia harus memeriksa diff dan riwayat

Pemindaian harus memblokir saat pull request menambah pola credential atau secret aktif yang terverifikasi, meski string berada dalam fixture test, file terhapus, bundle generasi, atau commit sebelumnya.

Push protection dan pemindaian pull request memecahkan masalah terkait tetapi berbeda. Push protection dapat menghentikan secret sebelum mencapai remote. Gate pull request memeriksa yang sudah tiba dan dapat mencakup contributor atau tipe token yang terlewat. Alert tanpa branch protection tidak memblokir merge.

Pindai seluruh rentang commit terhadap base branch, bukan hanya filesystem akhir. Agen dapat menambah token dalam satu commit lalu menghapusnya pada commit berikutnya; token tetap ada di Git dan mungkin sudah masuk log atau cache. Anggap terekspos. Cabut atau rotasi credential, bersihkan riwayat yang diajukan, dan ulangi check.

Gunakan fixture sintetis yang tidak dapat melakukan autentikasi. Fixture harus jelas menyatakan dirinya sebagai test dan cocok dengan pola lokal, bukan meniru bentuk cloud key asli. Allowlist luas berbahaya karena kesalahan dan penyerang pada akhirnya menemukan direktori yang diabaikan. Buat pengecualian spesifik, ditinjau, dan dekat dengan konfigurasi detector.

Gabungkan pattern detector dengan entropy check dan, bila provider mendukung dengan aman, verifikasi credential. Pattern matching punya risiko jaringan dan pengungkapan lebih kecil tetapi melewatkan token khusus. Verifikasi mengurangi ketidakpastian, namun mengirim bagian calon secret ke layanan lain dan tidak boleh memakai endpoint tidak tepercaya dari pull request. Dokumentasikan detector yang memverifikasi, yang tetap lokal, dan data yang keluar dari CI.

Pindai encoding umum dan output generasi tanpa menganggap setiap string acak sebagai credential. Base64, URL encoding, dan bundle minified dapat menyembunyikan secret yang muncul polos pada langkah source. Atur ambang dengan fixture teruji dan tinjau update detector sebagai perubahan kebijakan. Scanner bising melatih dismissal, scanner diam menimbulkan rasa aman palsu.

Output gate perlu lokasi tanpa mengungkap nilainya:

{"result":"fail","detector":"generic-api-token","commit":"abc123","path":"config/dev.env","line":7,"fingerprint":"sha256:8f2c..."}

Jangan cetak kecocokan lengkap ke log CI atau komentar pull request. Masking setelah scanner mengeluarkan data mungkin terlambat karena sistem log, notifikasi, dan artefak dapat menyalinnya.

Pemindaian secret tidak menggantikan tinjauan izin repository. Workflow dapat membaca secret produksi tanpa menaruhnya di diff, dan agen dapat mengubah job deployment untuk mengirimkannya keluar. Jauhkan secret dari job pull request, batasi izin workflow, dan wajibkan tinjauan manusia pada definisi CI.

Pemeriksaan otorisasi menjaga tindakan terlarang tetap terlarang

Gate otorisasi harus membuktikan setiap operasi terlindungi menolak aktor yang salah dan mengizinkan aktor yang benar pada batas layanan. Test login saja tidak menguji otorisasi.

Tim sering mencampur autentikasi, otorisasi, dan visibilitas UI. Autentikasi menetapkan siapa pengirim request. Otorisasi memutuskan apakah identitas itu boleh melakukan tindakan pada objek tersebut. Menyembunyikan tombol admin di React tidak mengubah keputusan API Go. Jika backend menerima request, aplikasi tetap terbuka.

Buat matriks izin untuk endpoint dan tindakan bisnis yang berubah, termasuk kepemilikan dan batas tenant:

read_private_project:
  anonymous: deny
  member: deny
  other_tenant: deny
  owner: allow
  admin: allow
update_project:
  anonymous: deny
  other_tenant: deny
  owner: allow

Hasilkan test dari matriks atau tulis kasus table-driven dalam bahasa layanan. Setiap kasus deny harus memanggil handler asli dengan identifier realistis. Mock yang mengganti middleware otorisasi dapat membuktikan route bekerja sambil melewatkan kontrol yang hendak diuji.

Uji akses pada tingkat objek, bukan hanya role. Dua user dapat sama-sama memiliki role member tetapi berada di organisasi berbeda. Ubah identifier resource dan tenant secara terpisah untuk menangkap insecure direct object reference. Uji juga bulk endpoint, export, background job, dan resolver GraphQL yang sering melewati check pada handler REST biasa.

Gagalkan gate saat route terlindungi baru tidak punya pemetaan kebijakan. Otorisasi yang hilang berubah dari firasat reviewer menjadi cacat terukur. Default server harus deny. Aturan allow eksplisit lebih mudah diaudit daripada kode tersebar yang menolak beberapa kasus buruk.

Agen sering menggunakan ulang handler di dekatnya, mempertahankan happy path, dan kehilangan pemeriksaan kepemilikan. Matriks membuat kelalaian terlihat dan memberi kontrak stabil saat role atau aturan tenant berubah.

Uji otorisasi setelah normalisasi input. Perbedaan huruf, format identifier lain, parameter query ganda, dan referensi objek bertingkat dapat mengirim request setara melalui jalur kode berbeda. Uji endpoint langsung dan jalur batch atau import yang mencapai tindakan sama. Jika background worker menulis hasil akhir, teruskan konteks aktor dan tenant ke job, jangan memperlakukannya sebagai user tepercaya dengan kuasa penuh.

Catat keputusan yang diharapkan dan aturan yang menghasilkannya, tanpa membuka data objek privat. Kegagalan yang baik menyebut kelas aktor, tindakan, kelas objek, dan status harapan. Jangan mencetak access token atau record lengkap. Bukti ini membantu membedakan fixture rusak dari perubahan privilege nyata.

Simulasi migrasi mengukur lock dan kemampuan balik

Gate migrasi harus menerapkan setiap perubahan schema pada salinan yang menyerupai produksi, menjalankan probe kompatibilitas, serta mencatat durasi, lock, dan rollback sebelum merge. Migrasi yang berhasil di database kosong hanya membuktikan sedikit.

Gunakan snapshot yang sudah disanitasi atau data generasi dengan ukuran tabel, index, constraint, dan distribusi serupa. Data produksi persis tidak boleh berada di infrastruktur pull request. Tujuannya meniru tekanan operasional tanpa menyalin record pribadi atau rahasia.

Simulasikan urutan deployment sebenarnya. Jika instance lama tetap berjalan selama migrasi, uji kode lama pada schema baru dan kode baru pada schema transisi. Menambah kolom nullable biasanya kompatibel. Mengganti nama kolom dalam satu langkah dapat merusak semua instance lama yang masih menerima traffic.

Catat bukti yang dapat dibaca mesin:

{"migration":"20260727_add_project_state","apply_ms":18420,"max_lock_ms":310,"old_app_probe":"pass","new_app_probe":"pass","down":"pass"}

Tentukan ambang per database dan kelas tabel. Lock 300 milidetik dapat aman untuk satu tabel dan mengganggu tabel lain. Reviewer harus melihat batas terpilih di samping hasil pengukuran dan versi database rehearsal.

Untuk PostgreSQL, periksa operasi yang menulis ulang tabel, memvalidasi constraint, atau membangun index sambil memblokir write. Pilih pola expand lalu contract: tambah bentuk baru, deploy kode yang memahami dua bentuk, backfill dalam batch terkendali, alihkan read, lalu hapus bentuk lama pada perubahan berikutnya. Pull request tambahan lebih murah daripada improvisasi saat outage.

Tidak semua migrasi memiliki operasi down yang aman. Menghapus kolom menghilangkan data, dan membalik transformasi mungkin ambigu. Dalam kasus itu, wajibkan forward recovery dan titik restore backup yang sudah diuji. Menyebut migrasi irreversible sebagai aman hanya karena ada file down adalah tidak jujur.

Uji retry dan kegagalan parsial. Deployment dapat berhenti setelah membuat index tetapi sebelum menandai migrasi selesai, dan upaya berikutnya tidak boleh merusak state atau gagal selamanya. Hentikan rehearsal pada batas terkendali, jalankan lagi, dan pastikan schema serta ledger cocok. Backfill panjang harus melanjutkan dari cursor tercatat dan menjalankan batch dua kali tanpa menduplikasi atau menghapus data.

Periksa efek disk dan replikasi selain waktu. Penulisan ulang tabel dapat memakai ruang sementara, memperbesar write ahead log, dan menunda replica setelah operasi utama tampak selesai. Gate tidak perlu membuat ramalan produksi sempurna, tetapi harus mencatat nilai pada data rehearsal dan membandingkannya dengan limit pemilik database. Tanpa itu, migrasi lokal yang cepat dapat memenuhi volume produksi.

Verifikasi rollback harus menjalankan jalur pemulihan

Gate rollback harus men-deploy kandidat ke environment terisolasi, membuat state representatif, menjalankan metode rollback yang didukung, dan membuktikan versi sebelumnya masih dapat membaca serta menulis dengan benar. Rencana tertulis bukan verifikasi.

Pisahkan rollback aplikasi dari rollback data. Mengembalikan traffic ke binary sebelumnya mungkin hanya beberapa detik, sedangkan membalik schema destruktif atau transformasi data bisa mustahil. Gate harus melaporkan keduanya. Jika aplikasi lama tidak berjalan pada schema baru, tandai kandidat nonreversible dan wajibkan deployment bertahap.

Urutan yang praktis:

1. Deploy commit main saat ini dan buat record representatif.
2. Upgrade ke artefak pull request dan jalankan jalur yang berubah.
3. Buat record baru pada state hasil upgrade.
4. Pulihkan artefak atau snapshot sebelumnya dengan kontrol terdokumentasi.
5. Jalankan probe read, write, queue, dan background job.

Check harus menyimpan identifier artefak, identifier snapshot, timestamp, dan hasil probe. Jangan simpan credential atau salinan data pelanggan. Ukur waktu pemulihan sebagai bukti target operasi sendiri, bukan janji universal.

Snapshot hanya membantu jika seseorang membuktikan isinya mencakup semua kebutuhan aplikasi. File, object storage, state queue, perubahan schema, dan efek eksternal mungkin berada di luar snapshot server. Daftarkan batas itu dalam hasil. Pembayaran, email, atau webhook yang sudah dikirim tidak dapat ditarik kembali dengan restore database.

Buat probe rollback lebih kuat daripada health check. Baca satu record yang dibuat sebelum upgrade dan satu setelahnya, update keduanya jika kompatibel, dan proses queued job dari masing-masing versi. Bandingkan output yang dilihat user, bukan hanya status code. Server yang mengembalikan 200 sambil menghilangkan field baru atau salah membaca enum belum pulih.

Uji kontrol yang dipakai petugas on-call. Jika rollback produksi membutuhkan pemilihan artefak, restore snapshot, atau pengalihan traffic, rehearsal harus memakai interface dan jalur izin yang sama. Script privat di laptop satu engineer bukan kontrol operasional. Bukti harus menunjukkan role operator dapat memulihkan tanpa akses admin permanen.

Koder.ai mendukung ekspor source, deployment dan hosting, snapshot, serta rollback, jadi aplikasi yang dibuat di sana dapat memakai artefak nyata itu dalam gate alih-alih menjadikan recovery sekadar paragraf pull request. Aturan pada platform lain sama: jalankan kontrol pemulihan dan probe aplikasi yang sudah dipulihkan.

Satu required check harus merangkum ketujuhnya

Keputusan merge terakhir harus mewajibkan satu check kebijakan stabil yang memverifikasi tujuh hasil untuk head commit persis. Nama job berubah, matrix job bertambah, dan path opsional melewatkan kerja. Aggregator kecil mencegah branch protection menyimpang dari kebijakan.

Minta setiap gate menghasilkan result bertanda tangan atau terattestasi platform yang berisi commit, versi kebijakan, outcome, dan lokasi bukti. Aggregator menolak hasil yang hilang, lama, netral, atau dibatalkan. Jangan pernah menyimpulkan sukses dari job yang tidak melapor.

{
  "commit": "abc123",
  "policy": "merge-gates-v3",
  "results": {
    "tests": "pass",
    "codeql": "pass",
    "dependency_review": "pass",
    "secret_scan": "pass",
    "authorization": "pass",
    "migration_rehearsal": "not_applicable",
    "rollback_verification": "pass"
  },
  "decision": "allow"
}

Tetapkan jalur override sempit untuk keadaan darurat. Wajibkan maintainer bernama, approver kedua, alasan tertulis, kedaluwarsa, dan issue tindak lanjut. Agen tidak boleh meminta atau menyetujui pengecualiannya sendiri. Laporkan override di tempat yang sama dengan hasil gate biasa agar tetap terlihat setelah insiden.

Check ini menambah beberapa menit pada pull request dan lebih lama pada migrasi. Itu wajar jika waktunya membeli bukti spesifik. Jalankan gate murah lebih dulu, batalkan commit yang sudah tergantikan, cache input build tepercaya, dan lakukan rehearsal penuh hanya untuk path terkait. Jangan melemahkan gate agar dashboard lebih cepat hijau.

Mulailah dengan membuat perilaku saat ini terlihat. Letakkan tujuh nama dalam satu file kebijakan, hubungkan masing-masing ke required result, dan paksa kerja yang dilewati menjelaskan dirinya. Pull request agen pertama yang tidak dapat menghasilkan catatan itu menemukan lubang dalam sistem delivery sebelum lubang itu mencapai produksi.