Lewati ke konten

Mode

Sebuah mode adalah properti sebuah space, yang disimpan sebagai satu kolom pada baris space. Setiap percakapan di dalam sebuah space berbagi mode itu, termasuk thread — sebuah thread mewarisi mode space-nya seperti percakapan lain. Agen yang sama karena itu dapat berada dalam mode berbeda di space berbeda pada saat yang sama, dan mengganti mode sebuah space mengubah apa yang terjadi pada giliran berikutnya tanpa menyentuh agennya.

Jumlahnya tepat empat: chat, review, plan, orchestrate. Enum itu sendiri tidak membawa kebijakan apa pun. Semua yang dijamin oleh sebuah mode dideklarasikan sekali, dalam sebuah profil kemampuan, yang menjadi sumber proyeksi setiap lapisan penegakan:

  1. Permukaan alat — alat mana yang ada sama sekali dalam mode itu, dinyatakan sebagai tingkat persetujuan maksimum, daftar izin, daftar tolak, dan sekumpulan kelas efek yang ditolak.
  2. Verb keluaran yang diwajibkan — apa yang harus dipanggil oleh run agar telah menyerahkan sesuatu.
  3. Kelas efek yang ditolak — apa yang ditolak mentah-mentah oleh pagar pengaman tindakan.
  4. Postur worktree — apakah worktree boleh ditulisi. Ini ditegakkan dengan mencabut alat-alat pemutasi dari permukaan, dan itulah yang membuatnya berlaku di setiap host. Jika host punya sandbox OS, postur yang sama juga mengukir aturan penulisan sistem berkas — mode hanya-baca memasang worktree sebagai hanya-baca — tetapi itu salinan kedua dari jaminan tersebut, bukan yang menjalankan tugasnya.
  5. Blok prompt sistem — prakata kemampuan yang dihasilkan dari daftar alat yang benar-benar diwujudkan, plus panduan yang ditulis tangan.

Setiap lapisan penegakan memproyeksikan dari profil tunggal itu, sehingga permukaan alat, pagar, postur worktree, dan prompt tidak dapat berselisih.

Mode bawaan dan satu-satunya mode tanpa batasan tambahan: permukaan alat penuh hingga tingkat eksekusi, worktree yang dapat ditulisi, tanpa kelas efek yang ditolak, dan tanpa kontrak penyelesaian. Gunakan untuk implementasi, perbaikan bug, pertanyaan tentang basis kode, dan apa pun yang bersifat ad hoc.

Perhatikan labelnya: di penyusun pesan, mode ini ditampilkan sebagai “Agent”, bukan “Chat”.

Mode rencana membuat worktree menjadi hanya-baca dan mencabut alat tulis dari permukaannya sepenuhnya, sehingga batasannya bersifat struktural, bukan sekadar diinstruksikan. Agen membaca, mencari, dan meneliti lalu menyerahkan tepat satu hal: panggilan submit_plan yang membawa graf dependensi bertipe — sebuah tujuan plus node dengan key, judul, deskripsi, dan key node yang menjadi dependensi tiap node.

Rencana itu dirender sebagai baris ringkas di percakapan dan membuka Plan Studio di tab di sebelahnya. Menyetujuinya mengompilasi graf menjadi sebuah orkestrasi, menjalankan pekerjaan yang dihasilkan, dan mengembalikan space tempat rencana disusun ke mode agen.

Jika sebuah run mode rencana berakhir tanpa pernah memanggil submit_plan, loop mula-mula menyisipkan dorongan yang menyatakan bahwa rencana itu belum ada sampai panggilan tersebut berhasil. Dorongan itu secara eksplisit mengizinkan jalan keluar yang jujur berupa “di sini tidak perlu rencana”, karena mode rencana adalah pengaturan space dan pertanyaan biasa yang diajukan di dalamnya tidak seharusnya memaksakan rencana yang palsu.

Ada jalan keluar kedua yang terpisah: exit_plan_mode. Itu adalah gerbang persetujuan keras, bukan verb keluaran — agen yang memanggilnya alih-alih submit_plan tidak menyerahkan apa pun. Panggilan pertama membuka persetujuan plan_exit yang tahan lama dan mengembalikan pending, sementara space tetap hanya-baca; panggilan berulang tetap pending alih-alih membuka gerbang kedua. Baru setelah persetujuan diberikan, panggilan berikutnya mengalihkan space ke chat. Penolakan memungkinkan agen membuka permintaan baru untuk rencana yang direvisi.

Untuk keluar dari mode rencana sendiri, ganti dropdown penyusun pesan (atau Shift+Tab). exit_plan_mode diputuskan dengan alat MCP decide_approval. Baris “persetujuan agen” di Kotak masuk adalah hal yang berbeda: prompt konfirmasi per giliran dari agen yang sedang berjalan.

Mode tinjauan adalah untuk tinjauan PR. Ia membuat worktree menjadi hanya-baca, membatasi permukaan alat di bawah tingkat eksekusi, dan menerapkan daftar izin yang dikurasi berisi alat tinjauan, tiket, dan komunikasi. Space yang dibuka untuk sebuah pull request dibuat dalam mode tinjauan secara otomatis.

Keluaran agen berupa temuan terstruktur — node tinjauan — dan, saat sebuah tinjauan difinalkan, sebuah putusan. Sebuah node membawa jenis (bug, suggestion, recommendation, question, atau ticket), prioritas dari P0 (menghambat rilis) sampai P3 (bagus kalau ada), keyakinan hasil penilaian sendiri, anchor opsional (berkas plus rentang baris; catatan seluas repositori tidak punya anchor), dan status siklus hidup yang bergerak dari open ke consensusReady begitu rekan setim — bukan penulisnya — mengonfirmasinya. Temuan yang prioritas atau keyakinannya hilang atau di luar rentang dijatuhkan di batas baca alih-alih mencemari putusannya.

Putusannya adalah Ship, Hold, atau Block dan putusan itu hanya pernah dibuat lebih berat oleh hasil per sumbu yang dilipat ke dalamnya: sumbu bergerbang yang gagal memaksa block dan sumbu bergerbang yang tidak dapat dijalankan memaksa setidaknya hold. Ketiadaan bukti tidak pernah menghijaukan sebuah gerbang.

Berbeda dari rencana dan orkestrasi, tinjauan tidak membawa kontrak penyelesaian. Temuan menumpuk melalui add_review_node dan diterbitkan oleh finalize_review, dan keduanya sah-sah saja dipanggil nol kali — agen pipeline yang berjalan dalam mode tinjauan mungkin ada di sana justru untuk menuntaskan sebuah tiket.

Mode orkestrasi mengubah satu tujuan menjadi rencana satu tim utuh. Seperti mode rencana, ia hanya-baca dan tidak dapat menulis berkas; di atas permukaan riset ia punya satu verb istimewa, propose_orchestration, yang memancarkan proposal terstruktur: peran, pohon sub-tiket, langkah sintesis, dan anggaran. Prompt hanya menyebut alat yang ada di permukaan, sehingga model tidak menghabiskan giliran untuk menarasikan pekerjaan perekrutan atau tiket yang tidak dapat dipanggilnya.

Tidak ada apa pun dalam proposal yang dijalankan sebelum Anda menyetujuinya. Saat disetujui, materializer deterministik merekrut para agen, membuat tiket-tiketnya dan sebuah proyek, lalu menjalankan pipeline yang dihasilkan. Menyetujui adalah hak operator semata: tidak ada alat MCP untuknya, sehingga agen dapat mengusulkan tetapi tidak pernah menyetujui rencananya sendiri. Proposal ulang yang diprakarsai agen dibatasi lajunya oleh jeda dua menit, sehingga perencanaan ulang berturut-turut ditolak dan diminta untuk digabung. Lihat Orkestrasi.

Verb keluaran milik mode itu sendiri tidak pernah dapat ditolak. submit_plan dan propose_orchestration dipaku ke dalam permukaan alat dan disetujui lebih dulu, melewati filter alat, gerbang persetujuan, dan pagar pengaman tindakan sekaligus, sehingga dial otonomi per space tidak dapat membungkam hasil kerja sebuah mode. ask_user milik harness dipaku karena alasan yang sama: itulah cara sebuah run menjangkau operator, jadi menggerbanginya akan membuat run yang perlu bertanya menemui jalan buntu. Ia berada di tingkat baca, sehingga setiap mode hanya-baca tetap memilikinya, dan ia dibebaskan dari pembungkus persetujuan — gerbang di depan sebuah prompt gagal secara tertutup saat tidak ada penyetuju yang terhubung, yang justru akan menghalangi agen melakukan tindakan bertanya.

Mode hanya-baca tidak menolak akses jaringan atau rahasia. Kelas efek yang ditolak oleh tinjauan, rencana, dan orkestrasi adalah kelas yang mengubah dunia: penghapusan berkas, penulisan di luar worktree, commit, push, pembuatan dan publikasi PR, penulisan sinkronisasi vendor, pemasangan paket, pemunculan proses, mutasi ruang kerja, dan kontrol enclosure. Egress jaringan dan akses rahasia memang sengaja dibiarkan pada defaultnya — riset adalah inti dari mode hanya-baca.

Dropdown mode di penyusun pesan menawarkan tiga opsi: Agent (chat), Plan, dan Orchestrate. review tidak dapat dipilih pengguna — ia ditetapkan oleh sistem saat space tinjauan PR dibuat dan oleh langkah pipeline.

Sebuah node pipeline yang membuka space dapat memaku mode ruangan itu dengan key extras['mode'] (chat, review, atau plan). Key tersebut harus cocok persis: ejaan lain apa pun — termasuk orchestrate — diabaikan diam-diam dan ruangan itu mendapat default dari bodinya (review pada body create-space). Langkah agen bergabung ke ruangan yang tidak dibuatnya dan tidak mengubah izinnya.

Resolusinya sendiri sederhana. Dispatcher membaca kolom mode milik space; pengiriman tanpa space — sebuah one-shot, pemanggilan CLI, atau id space dari ruang kerja lain, yang memang tidak ada di berkas basis data ruang kerja ini — diselesaikan menjadi chat. Mengganti mode berlaku mulai giliran berikutnya.

Permukaan alat sebuah mode dibangun dan ditegakkan oleh harness bawaan. Ia satu-satunya transport yang dapat membuat sebuah alat tidak terlihat alih-alih sekadar ditolak, menggerbangi setiap panggilan sebelum berjalan, dan mengamati kontrak penyelesaian.

Pada transport Claude Code, mode non-chat diteruskan sebagai --permission-mode plan. Claude mematuhinya secara konvensi; alat baca, tulis, dan edit miliknya sendiri berjalan tanpa terlihat, dan perintah shell-nya hanya diperiksa oleh hook yang membaca baris perintah. Untuk transport itu, mode hanyalah panduan, bukan batas Control Center — lihat Model agen.

Daftar izin membatasi alat dengan tingkat tulis ke atas. Tingkat baca harness bawaan tetap menjangkau alat yang tidak disebut daftar mana pun; pada Claude Code, alat yang dihilangkan dari daftar izin ditolak terlepas dari ada atau tidaknya di server.