Solo-Engine V4.1 Final Dipilih untuk Mengatasi Ambiguitas V4

Putusan singkat

Pilihan akhir: Solo-Engine v4.1 Final.

V4 sudah berada di arah yang tepat. Ia secara eksplisit menolak pemalsuan tool, hasil kompilasi, hasil pengujian, Git diff, maupun klaim bahwa beberapa agent independen telah berjalan. V4 juga memisahkan fakta, inferensi, asumsi, dan hal yang belum diketahui—fondasi yang penting untuk workflow riset hingga delivery kode.

Namun, V4 tidak sebaiknya dipakai apa adanya sebagai konfigurasi jangka panjang. Masalah intinya bukan kurang ketat, melainkan terlalu banyak aturan yang saling mengulang. Ketika status, verifikasi, dependensi, ADR, dan definisi selesai tersebar di beberapa dokumen, risiko model melewatkan sebagian aturan atau menghasilkan status yang tidak konsisten justru meningkat.

V4.1 Final mempertahankan kerangka utama V4, lalu merapikan arsitekturnya: aturan yang tidak boleh dilanggar ditempatkan di instruksi utama Gem, sedangkan SOP dan template rinci dipindahkan ke knowledge base.

Apa yang sudah benar dari V4

Beberapa keputusan desain V4 patut dipertahankan:

• Memisahkan /ana-solo untuk analisis dan keputusan dari /ana-bmad untuk perencanaan, implementasi, serta verifikasi.
• Mengisolasi bukti ke dalam FACT, INFERENCE, ASSUMPTION, dan UNKNOWN.
• Menolak klaim atas kemampuan yang tidak benar-benar tersedia, termasuk web search, Tavily, code execution, filesystem, Git, deployment, dan multi-agent runtime.
• Memisahkan output kode lengkap dari klaim bahwa kode telah benar-benar dikompilasi atau lolos tes.
• Menambahkan hard gate, preflight, pemeriksaan kecocokan algoritme, backpressure saat gagal, dan state reconcile.
• Menetapkan bahwa file panjang hanya boleh dipaginasi pada batas file, bukan dipotong di tengah lalu disebut selesai.

Pendekatan BMAD juga perlu diposisikan dengan tepat. Dokumentasi BMAD memang mendeskripsikan agent, skill, workflow, serta alur pengujian sebagai mekanisme operasional yang eksplisit.11014 Karena itu, satu Gem dapat memakai perspektif peran ala BMAD—misalnya PM, architect, developer, QA, dan ops—tetapi tidak boleh mengklaimnya sebagai runtime multi-agent BMAD yang benar-benar berjalan.

Lima perbaikan penting pada V4.1

1. Aturan inti harus mandiri di instruksi utama

Aturan mengenai kejujuran tool, batas verifikasi, definisi kode lengkap, dan syarat status COMPLETE tidak boleh hanya mengandalkan retrieval knowledge base. Dokumen knowledge base berguna untuk prosedur detail, tetapi tidak dapat diasumsikan selalu dipanggil utuh pada setiap respons.

Karena itu, V4.1 menaruh hard constraint langsung di instruksi Gem.

2. “Auto loop” dibatasi secara nyata

Prompt tidak dapat menciptakan proses latar belakang, terminal persisten, atau eksekusi lintas sesi. Dalam V4.1, loop otomatis hanya berarti loop yang:

• berlangsung dalam sesi atau respons aktif;
• berada dalam ruang lingkup yang disetujui pengguna;
• memakai tool yang benar-benar tersedia;
• memiliki batas percobaan yang jelas;
• berhenti pada WAITING_VERIFICATION jika tidak ada executor nyata.

Dengan demikian, sistem tidak memberi kesan bahwa pekerjaan akan terus berjalan saat pengguna pergi atau sesi berakhir.

3. “Zero dependency” dipecah menjadi kontrak yang dapat diaudit

Istilah “zero dependency” terlalu kabur jika dipakai sekaligus untuk runtime, paket pihak ketiga, dan modul lokal. V4.1 menggantinya dengan definisi yang lebih operasional:

• tidak ada dependensi yang tidak dideklarasikan;
• secara default tidak menambah paket pihak ketiga;
• semua dependensi lokal baru harus ikut dikirimkan;
• compiler, runtime, SDK, OS, dan host platform adalah prasyarat lingkungan yang harus dinyatakan.

Ini membuat target engineering lebih realistis: bukan “tanpa lingkungan”, tetapi “tanpa dependensi tersembunyi”.

4. Kode lengkap dibedakan antara proyek baru dan proyek lama

Untuk proyek baru, delivery harus mencakup seluruh closure minimum: konfigurasi build, entry point, source file, test, resource yang diperlukan, dan konfigurasi non-rahasia.

Untuk proyek yang sudah ada, semua file baru dan file yang diubah harus diberikan secara utuh. File baseline yang telah diberikan pengguna dan tidak diubah tidak perlu disalin ulang. Tetapi jika interface atau file existing yang penting belum tersedia, sistem harus meminta bahan tersebut—bukan menebak kontrak demi terlihat bisa dikompilasi.

5. Delivery, verifikasi, dan kelengkapan engineering harus dipisah

V4.1 menggunakan tiga konsep berbeda:

• DELIVERY_STATUS: apakah seluruh file yang wajib dikirim sudah lengkap;
• VERIFICATION_STATUS: apakah kompilasi atau pengujian benar-benar dijalankan dan dengan hasil apa;
• ENGINEERING_STATUS: apakah pekerjaan dapat dinyatakan siap, terverifikasi, atau selesai.

Pemisahan ini mencegah kesalahan umum: kode telah ditulis lengkap lalu langsung diklaim “selesai” meski belum ada bukti build atau test.

Tavily dan BMAD: kemampuan harus mengikuti tool nyata

Tavily search_depth=advanced memang merupakan opsi nyata untuk pencarian yang membutuhkan relevansi dan presisi lebih tinggi, dengan konsekuensi latensi yang meningkat.2411 Tetapi parameter tersebut hanya boleh disebut telah digunakan bila tool Tavily atau koneksi API yang sesuai benar-benar tersedia di sesi.

Jika Tavily tidak tersedia, workflow harus turun kelas secara transparan ke web search native atau bahan yang diberikan pengguna. Ia tidak boleh menulis seolah-olah telah menjalankan advanced search.

Prinsip yang sama berlaku untuk BMAD: gunakan struktur peran sebagai mekanisme review internal, bukan sebagai bukti bahwa beberapa agent, skill, atau workflow independen telah benar-benar dieksekusi.11014

Matriks keputusan

Skor berikut adalah audit konfigurasi berbasis kecocokan desain, bukan hasil benchmark terhadap runtime Gemini Gem.

Dimensi	Bobot	V4	V4.1 Final
Batas runtime Gem dan kejujuran tool	25%	4,0	4,8
Kualitas konvergensi tiga pembacaan, DM, dan DR	20%	4,5	4,8
Pengaman engineering dan backpressure kegagalan	20%	4,6	4,8
Kelengkapan kode dan closure dependensi	15%	4,6	4,9
Kepadatan instruksi dan kemudahan dipatuhi	10%	2,8	4,5
Pemulihan status dan rekonsiliasi bukti	10%	4,2	4,7
Skor tertimbang	100%	84,2	95,5

Rumus normalisasi yang digunakan:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad \sum_{i=1}^{n}w_i=1
$$

Kesimpulannya, peningkatan terbesar V4.1 bukan berasal dari menambah lebih banyak aturan. Nilainya datang dari mengurangi pengulangan, memperjelas batas operasi, dan membuat instruksi utama tetap cukup mandiri saat knowledge base tidak seluruhnya terambil.

Batas pembuktian yang wajib dijaga

Konfigurasi final harus gagal secara jujur pada lima situasi berikut:

1. Tidak ada executor, tetapi sistem mengklaim tes telah lulus.
2. Interface lokal penting tidak tersedia, tetapi sistem mengarang interface dan mengklaim build berhasil.
3. Bugfix mengubah public signature tanpa peningkatan ke preflight struktural.
4. Output berhenti di tengah file, tetapi status delivery ditandai COMPLETE.
5. Tavily tidak tersedia, tetapi sistem mengklaim sudah memakai search_depth=advanced.

Jika salah satu terjadi, masalahnya bukan sekadar pada jawaban individual, melainkan pada kontrak instruksi yang belum cukup kuat.

Rekomendasi implementasi akhir

Paket V4.1 Final sebaiknya dipasang dalam lima lapisan:

File	Penempatan	Fungsi
00-solo-engine-system.md	Instruksi Gem	Routing, hard constraint, dan batas tool nyata
10-ana-solo.md	Knowledge base	Riset, value extraction, decision matrix, deep recon, kristalisasi
20-ana-bmad.md	Knowledge base	Scenario detection, review berbasis peran, loop engineering, dan delivery lengkap
30-artifacts.md	Knowledge base	Plan, ADR, verification record, truth report, resume capsule
40-three-pass-reading.md	Knowledge base	Metode inti tiga tahap pembacaan

Jangan mengunggah versi lama dengan fungsi yang sama secara bersamaan, karena retrieval yang konflik dapat mengembalikan aturan lama dan baru secara tumpang tindih.

Verdict akhir

Adopsi Solo-Engine v4.1 Final.

V4 tetap layak dijadikan basis eksperimen internal karena kerangka riset-ke-engineering-nya sudah kuat. Namun untuk penggunaan berkelanjutan, V4.1 lebih aman dan lebih dapat diaudit karena membatasi klaim kemampuan sesuai tool nyata, memisahkan status yang sebelumnya mudah tercampur, dan menjadikan definisi delivery engineering lebih tegas.

Jika nanti lingkungan berpindah ke managed agent runtime, MCP, code sandbox persisten, atau filesystem yang benar-benar tersedia, tambahkan runtime adapter khusus. Jangan terus menumpuk deskripsi tool ke instruksi utama Gem.