JSON Config: Menjinakkan Config Hell Claude Code

Lo ngedit file json config. Satu koma kurang, dan CLI dibuka tanpa pesan error atau peringatan apa pun. Cuma tool yang tiba-tiba tidak muncul di terminal.

Lo cek ulang berkasnya. Kurung kurawalnya seimbang. Kutipnya tutup. Path-nya benar. Tapi agen tetap tidak melihat server itu, dan tidak ada pesan yang bilang kenapa.

Jam dua pagi, lo mulai curiga ke semua hal kecuali berkas yang baru lo sentuh.

Kenapa Masalah json config Selalu Menjebak Developer

Masalahnya bukan karena JSON sulit. Masalahnya karena konfigurasi agen tersebar di banyak permukaan, dan tidak satu pun dari permukaan itu memberi umpan balik yang berguna.

Empat sumber penderitaan yang berulang di setiap repo:

• Banyak berkas, satu kebenaran. Model tier ada di satu tempat, API key di tempat lain, hook di berkas ketiga, MCP server di berkas keempat. Mengubah satu hal berarti lo harus ingat semua tempat yang terpengaruh.
• Kegagalan senyap. JSON yang tidak valid sering tidak menghasilkan error. Parser berhenti, tool tidak termuat, dan CLI jalan seolah tidak ada apa pun. Lo baru tahu ada yang salah ketika fiturnya hilang.
• Tidak ada validasi silang. Tidak ada yang memeriksa apakah path yang lo tulis benar, apakah binernya ada, apakah port-nya sudah dipakai. Kegagalan baru muncul saat runtime.
• Duplikasi lintas mesin. Konfigurasi yang jalan di laptop lo belum tentu jalan di mesin tim. Path absolut, versi biner, dan lokasi home direktori berbeda, dan tidak ada yang memverifikasi perbedaan itu.

Bedanya konfigurasi dan kendali

Analoginya paling dekat: panel listrik. Konfigurasi manual itu seperti menyambung kabel satu per satu di belakang dinding, lalu berharap lampunya menyala. Kendali visual itu seperti sakelar di dinding: lo lihat statusnya, lo tahu mana yang hidup, dan lo bisa mematikannya tanpa membongkar tembok.

Yang lo butuhkan bukan berkas konfigurasi yang lebih rapi. Lo butuh melihat status sistem dan mengubahnya tanpa harus mengedit teks.

The Unfair Advantage: ACS Dashboard di Port 20130

ACS Core memindahkan seluruh permukaan konfigurasi ke satu dashboard lokal. Bukan editor JSON dengan warna-warni, tapi tampilan status yang membaca dan menulis konfigurasi yang sama dari satu tempat.

Yang bisa lo kendalikan dari dashboard:

• Empat tier model resmi. Opus dan Fable untuk pekerjaan arsitektur yang butuh penalaran panjang, Sonnet dan Haiku untuk eksekusi kilat. Pengaturannya berlaku global atau per-proyek, dan lo bisa lihat tier mana yang aktif untuk sesi mana.
• API key dan kredensial. Disimpan terpisah dari berkas repo, jadi tidak ikut ter-commit dan tidak bocor lewat git history.
• Hook dan tool profile. Aktif, nonaktif, atau diganti tanpa menyentuh settings.json.
• Status server MCP. Server mana yang hidup, port mana yang dipakai, dan transport mana yang aktif. Kalau stdio mati, lo lihat sebelum agen kehilangan tool.
• Status memori dan sesi. Berapa entri memori aktif, berapa sesi berjalan, dan sesi mana yang mengklaim package mana.

Dashboard berjalan di http://127.0.0.1:20130 dan dilayani oleh biner Go yang sama dengan CLI. Tidak ada server web terpisah yang harus lo hidupkan, tidak ada proses Node yang bisa mati diam-diam.

# Buka dashboard lokal
acs dashboard

# Cek status dari terminal tanpa membuka browser
acs doctor

Yang penting: dashboard bukan pengganti CLI. Keduanya membaca dan menulis konfigurasi yang sama. Lo bebas pilih sakelar atau terminal, hasilnya identik.

Kenapa port 20130, dan kenapa bukan port acak

Port ini bukan angka yang dipilih sembarangan. Ia adalah jalur REST fallback terakhir dalam hierarki empat tier yang dipakai ACS:

1. Tier 1, MCP stdio in-process. Jalur utama untuk agen. Kembali di bawah 2 milidetik karena tidak ada lapisan jaringan.
2. Tier 2, CLI fastpath. Subcommand acs untuk operasi yang lebih cocok dari terminal.
3. Tier 3, akses database langsung. Query SQLite WAL in-process untuk pembacaan yang tidak butuh server.
4. Tier 4, REST fallback di :20130. Dipakai hanya ketika transport stdio benar-benar mati.

Urutannya penting. REST bukan jalur normal, melainkan pemutus sirkuit darurat. Selama Tier 1 dan 2 hidup, memanggil HTTP adalah pelanggaran, bukan pilihan.

Port itu sendiri tidak pernah di-hardcode di dalam logika backend. Selalu dibaca dari environment, supaya dev, staging, dan prod tidak saling bentrok.

Resep Mapping Tier dan Aturan Drift Config

Bagian ini berisi pemetaan tier ke workload, aturan deteksi drift, dan urutan migrasi yang kami pakai saat pindah dari konfigurasi manual ke dashboard.

Arsitektur Validasi JSON Config dan Pemetaan Tier

Kapan Dashboard Tidak Perlu

Kalau lo pakai satu editor, satu proyek, dan konfigurasi yang tidak berubah, dashboard menambah lapisan yang tidak lo pakai. Konfigurasi tunggal sudah cukup.

Sebaliknya, kalau lo menjalankan beberapa CLI agen, beberapa proyek, dan beberapa mesin, konfigurasi manual berubah jadi utang yang bertambah tiap minggu. Di situ dashboard bukan kemewahan, ia satu-satunya cara melihat status sistem tanpa membongkar tembok.

Untuk melihat bagaimana kendali visual ini duduk bersama fitur lain, buka seksi fitur ACS. Di sana ada Universal Tier Relay, Sovereign Cognitive Buffer, dan Governance Citadel dalam satu tampilan.

Untuk paket dan cara mengaktifkannya, buka halaman harga. Satu lisensi membuka seluruh resep di artikel ini plus pembaruan dashboard saat format konfigurasi CLI agen berubah. Pelajari standar pertukaran data resmi di RFC 8259 JSON Specification ↗.