Di dalam desain adapter multi-harness

Apothem memateriilkan satu profil bersama menjadi tujuh belas konfigurasi asli-harness. Tujuh belas target, tujuh belas format vendor, tujuh belas lokasi pemasangan — dan satu antarmuka seragam yang diandalkan oleh operator maupun CLI. Tulisan ini menjelaskan bagaimana lapisan adapter menjaga kontrak itu tetap utuh.

Protokol HarnessAdapterCopy Anchor Link

Setiap adapter harness mengimplementasikan protokol struktural HarnessAdapter. Protokol adalah jahitan antara CLI dan detail spesifik-vendor. Ia mendeklarasikan operasi yang dipanggil CLI dan metadata yang dibaca CLI:

• name — pengenal terdaftar dari adapter.
• output_path — tempat konfigurasi yang dimaterialisasikan mendarat di disk.
• install — merender dan menulis konfigurasi native-harness.
• update — merender ulang konfigurasi native-harness setelah profil berubah.
• uninstall — menghapus konfigurasi yang dimaterialisasikan, dengan profil bersama dibiarkan tidak tersentuh.
• is_installed — melaporkan apakah konfigurasi harness ada.
• verify — mendeteksi penyimpangan (drift) antara profil dan konfigurasi di disk.

Karena kontraknya berupa typing.Protocol, sebuah adapter memenuhinya berdasarkan bentuk, bukan pewarisan. Saat runtime, CLI me-resolve setiap adapter dari sebuah registri statis — tabel HARNESS_REGISTRY di src/apothem/lib/harness_registry_data.py, yang dideklarasikan oleh harness_registry.py sebagai otoritatif saat runtime — sehingga sebuah checkout biasa memuat setiap adapter tanpa metadata entry point terpasang apa pun di sys.path. Tabel [project.entry-points."apothem.harnesses"] di pyproject.toml dan sapuan discover_adapters() pada sistem berkas adalah pemeriksaan paritas konformansi, bukan resolver runtime: sebuah pengujian menegaskan bahwa himpunan adapter yang ditemukan setara dengan registri statis, sehingga adapter yang benar-secara-konvensi tetapi tidak terdaftar muncul sebagai regresi cakupan alih-alih ter-resolve secara diam-diam. Oleh karena itu, menambahkan sebuah harness berarti mendaftarkannya di data registri (dan mencerminkannya di tabel entry point demi paritas pengemasan) — pengujian paritas gagal dengan nyaring jika salah satunya terlewat.

Satu subpaket per adapterCopy Anchor Link

Setiap adapter tinggal di subpaketnya sendiri di bawah src/apothem/harnesses/<name>/:

• __init__.py — kelas <Name>Adapter yang mengimplementasikan protokol dan mendelegasikan ke modul aksi sejawat.
• install.py / uninstall.py / update.py / verify.py — implementasi per-aksi yang diimpor dan dipanggil oleh kelas adapter.
• materializer.py — sebuah materialize_native_config(profile) -> str opsional yang merender profil bersama menjadi teks konfigurasi asli-harness.

Memecah setiap aksi ke dalam modulnya sendiri menjaga kelas adapter tetap tipis: ia adalah dispatcher yang menyambungkan metode protokol ke fungsi aksi. Seorang pembaca yang membuka verify.py melihat persis logika deteksi penyimpangan untuk satu harness itu, tanpa derau pemasangan atau pencopotan yang harus diarungi.

Tiga kelas adapterCopy Anchor Link

Tujuh belas harness tidak semuanya mengonsumsi konfigurasi dengan cara yang sama. Apothem mengurutkannya ke dalam tiga kelas menurut seberapa banyak transformasi yang dibutuhkan profil sebelum mencapai harness.

Kelas I — propagasi mentahCopy Anchor Link

Harness mengonsumsi artefak yang sama yang sudah ditulis Apothem — aturan .md datar, agents, hooks — tanpa langkah perenderan. Adapter menyalin templat mentah ke dalam pohon konfigurasi harness. Tidak ada materializer.py, karena tidak ada yang dirender; artefak profil itulah keluarannya.

Kelas II-A — mentah ditambah templat vendorCopy Anchor Link

Harness mengonsumsi artefak mentah Apothem DAN sekumpulan berkas templat spesifik-vendor (berkas pengaturan, manifes, atau scaffold yang dibutuhkan harness). Adapter menyalin artefak mentah dan templat vendor bersama-sama. Templat vendor tinggal di samping adapter di bawah direktori templates/.

Kelas II-B — dirender dari profilCopy Anchor Link

Harness menginginkan satu berkas konfigurasi asli yang dirender dari bidang terstruktur profil bersama. materializer.py adapter membaca profil dan memancarkan teks asli-harness — sebuah config.yaml Hermes, sebuah openclaw.json Open-Claw, sebuah opencode.json OpenCode, atau sebuah settings.json Qwen Code. Kelas II-B adalah tempat pekerjaan rekonsiliasi format terpusat; telaah mendalam konvergensi konvensi membahasnya secara rinci.

claude-code: adapter permukaan-penuhCopy Anchor Link

Adapter claude-code memiliki permukaan konfigurasi terluas — aturan, agents, hooks, output-styles, pengaturan, dan direktori konvensi. Ia termasuk Kelas II-A: ia mempropagasi templat mentah Apothem dan meratakan direktori konvensi, serta mengapalkan templat pengaturan vendor di bawah src/apothem/harnesses/claude_code/templates/. Ia tidak membawa materializer.py — ia tidak merender berkas konfigurasi asli dari profil; ia mempropagasi artefak dan direktori konvensi secara langsung.

Satu batas yang disengaja: adapter claude-code hanya mengelola satu blok yang dibatasi sentinel di dalam CLAUDE.md; prosa di luar blok itu dipertahankan. Sisa berkas tersebut adalah wilayah milik operator. Apothem mematerialisasikan permukaan konfigurasi di sekitarnya — aturan, hook, pengaturan — dan mempertahankan prosa operator di luar blok itu apa adanya. Adapter yang menulis ulang seluruh berkas akan menghapus instruksi yang ditulis tangan pada setiap apothem install; adapter ini hanya menulis ulang blok terkelolanya.

Mengapa keseragaman itu pentingCopy Anchor Link

Protokol memberi operator satu model mental melintasi tujuh belas alat. apothem install, apothem verify, apothem uninstall berperilaku dengan cara yang sama entah targetnya merender satu berkas atau meratakan sebuah pohon direktori. Perbedaan vendor tinggal di dalam subpaket adapter, di balik protokol, di tempat yang semestinya.

Baca rujukan yang ditujukan untuk operator di Harness dan model profil di Konsep.