Solo-Engine V4.1 Final: Kurangkan Pertindihan Peraturan, Tegaskan Had Operasi

Keputusan semakan

Solo-Engine V4 tidak wajar dilancarkan tanpa pindaan, walaupun hala tujunya sudah betul. Versi ini telah menangani kelemahan yang lazim dalam konfigurasi pembantu pembangunan: mereka-reka penggunaan alat, mendakwa ujian telah lulus tanpa bukti, menyerahkan cebisan kod sebagai produk lengkap, serta menaikkan status ADR tanpa rekod pengesahan.

Namun, masalah V4 bukan kekurangan ciri. Sebaliknya, ia terlalu sarat dengan peraturan yang bertindih. Ini meningkatkan risiko arahan penting tenggelam, status menjadi tidak segerak, dan model mentafsir istilah seperti “zero dependency”, “auto loop”, “kod lengkap” atau “multi-agent BMAD” secara terlalu luas.

Pilihan akhir ialah Solo-Engine v4.1 Final. Prinsipnya mudah: letakkan larangan dan sempadan yang tidak boleh dirunding dalam arahan utama Gem; pindahkan SOP serta templat terperinci ke pangkalan pengetahuan; dan jangan sekali-kali mengaku memiliki alat atau bukti yang sebenarnya tidak tersedia.

Apa yang V4 sudah lakukan dengan baik

V4 membina rantaian kerja yang matang daripada penyelidikan kepada keputusan dan pelaksanaan:

• Membezakan mod /ana-solo untuk analisis daripada /ana-bmad untuk kerja kejuruteraan.
• Mengasingkan FACT, INFERENCE, ASSUMPTION dan UNKNOWN, supaya andaian tidak dipersembahkan sebagai fakta.
• Memisahkan kod yang telah ditulis daripada kod yang benar-benar telah dibina dan diuji.
• Memperkenalkan semakan awal seni bina, semakan kesesuaian algoritma, tekanan balik apabila pembaikan gagal, serta State Reconcile sebelum sesuatu kerja diisytiharkan siap.
• Menetapkan bahawa fail panjang perlu dihantar mengikut sempadan fail, bukan dipotong di tengah-tengah kandungan.

Penggunaan BMAD juga perlu diperjelas. Dokumentasi BMAD memang menerangkan ejen, kemahiran dan aliran kerja sebagai mekanisme tersendiri, termasuk aliran kerja QA yang dipanggil melalui ejen Developer.11014 Tetapi satu Gem tidak patut mendakwa bahawa ia telah menjalankan beberapa ejen bebas secara serentak. Frasa yang lebih tepat ialah “penyelarasan peranan berinspirasikan BMAD”.

Lima pembetulan penting dalam V4.1 Final

1. Arahan utama mesti berdikari

Peraturan seperti larangan mereka-reka alat, syarat kod lengkap, status pengesahan dan syarat “siap” tidak boleh hanya bergantung pada fail pangkalan pengetahuan. Fail tersebut mungkin tidak dipanggil semula secara lengkap dalam setiap respons.

Dalam V4.1, semua peraturan teras kekal dalam arahan utama Gem. Pangkalan pengetahuan digunakan untuk kaedah kerja, jadual semakan dan templat artifak.

2. “Auto loop” bukan proses latar belakang

Arahan tidak boleh mencipta terminal berterusan, tugasan latar belakang atau ingatan merentas sesi. Oleh itu, gelung automatik V4.1 hanya boleh berjalan:

• dalam respons atau sesi semasa;
• dalam skop yang pengguna telah benarkan;
• menggunakan alat yang benar-benar tersedia dalam sesi itu;
• dengan had percubaan yang jelas;
• dan berhenti pada WAITING_VERIFICATION apabila tiada pelaksana sebenar.

Ini mengelakkan dakwaan bahawa sistem terus membina, menguji atau membaiki kod selepas sesi tamat.

3. “Zero dependency” diberi makna yang boleh diaudit

Istilah ini sering terlalu kabur. Ia tidak boleh bermaksud bahawa projek tidak memerlukan runtime, SDK, sistem operasi atau platform hos.

Takrif V4.1 ialah:

• tiada kebergantungan yang tidak diisytiharkan;
• secara lalai, tiada pakej pihak ketiga baharu;
• setiap kebergantungan tempatan baharu mesti dihantar sepenuhnya;
• runtime bahasa, pengkompil, SDK dan platform hos ialah prasyarat persekitaran yang mesti dinyatakan.

Bagi projek baharu, mod STDLIB_ONLY sesuai jika hanya pustaka standard digunakan. Bagi projek sedia ada, mod LOCKED_EXISTING mengehadkan kerja kepada kebergantungan yang sudah disahkan dalam manifest atau lockfile projek.

4. “Kod lengkap” bergantung pada jenis projek

Untuk projek baharu, penghantaran mesti membentuk satu penutupan projek minimum: konfigurasi binaan, titik masuk, fail sumber, ujian, sumber yang diperlukan dan arahan pengesahan.

Untuk projek sedia ada pula:

• setiap fail baharu mesti diberikan sepenuhnya;
• setiap fail yang diubah mesti diberikan sepenuhnya;
• fail asas pengguna yang tidak diubah tidak perlu diulang;
• tetapi fail asas yang hilang dan menjejaskan kompilasi atau kontrak tidak boleh diteka.

Jika antara muka sedia ada tidak disediakan, pembantu mesti meminta fail atau tandatangan yang diperlukan, bukan mencipta API rekaan semata-mata agar kod nampak boleh dibina.

5. Tiga status mesti dipisahkan

V4.1 memisahkan tiga perkara yang sering dicampuradukkan:

Status	Maksud
DELIVERY_STATUS	Sama ada semua fail yang perlu telah dihantar: NOT_STARTED, PARTIAL, atau COMPLETE.
VERIFICATION_STATUS	Sama ada semakan statik atau pelaksanaan sebenar telah berlaku.
ENGINEERING_STATUS	Kedudukan projek secara menyeluruh, contohnya BUILDING, WAITING_INPUT, WAITING_VERIFICATION, VERIFIED atau COMPLETE.

Kod boleh lengkap tetapi belum diuji. Ujian boleh lulus untuk bundle lama tetapi tidak membuktikan bundle baharu. Sebab itu, ENGINEERING_STATUS=COMPLETE hanya boleh digunakan apabila penghantaran lengkap, pengesahan yang diperlukan benar-benar lulus, persekitaran sepadan, dan State Reconcile mendapati semuanya konsisten.

Kedudukan Tavily: ikut kemampuan sebenar, bukan ayat arahan

Tavily menyokong search_depth=advanced untuk carian yang memerlukan maklumat khusus dan ketepatan lebih tinggi, dengan pertukaran berupa latensi atau kos yang lebih tinggi.2411

Tetapi parameter itu hanya bermakna jika alat Tavily atau antara muka yang sah memang tersedia dalam sesi. Jika tiada alat tersebut, Gem tidak boleh berkata ia telah menggunakan carian Tavily pada mod advanced. Ia hanya boleh menggunakan bahan yang benar-benar boleh diakses, atau menyatakan bahawa penyelidikan telah diturunkan kepada sumber yang tersedia.

V4.1 juga menukar istilah umum “SEO keluar maklumat bernilai” kepada Value Extraction. Secara lalai, tugasnya ialah menghubungkan bukti kepada makna, nilai pengguna, tindakan dan kaedah pengesahan. Analisis SEO sebenar hanya dicetuskan apabila pengguna meminta perkara seperti kata kunci, niat carian, pengindeksan, ranking atau optimasi kandungan.

Matriks keputusan

Penilaian berikut ialah audit reka bentuk konfigurasi, bukan penanda aras masa jalan Gem.

Dimensi	Wajaran	V4	V4.1 Final
Sempadan operasi Gem dan ketulenan alat	25%	4.0	4.8
Kualiti pembacaan tiga pusingan, DM dan DR	20%	4.5	4.8
Pagar keselamatan kejuruteraan dan tekanan balik kegagalan	20%	4.6	4.8
Kod lengkap dan penutupan kebergantungan	15%	4.6	4.9
Ketumpatan arahan dan kebolehpatuhan	10%	2.8	4.5
Pemulihan status dan penyelarasan bukti	10%	4.2	4.7
Jumlah wajaran	100%	84.2	95.5

Skor dikira dengan formula:

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

Skor ini berguna sebagai alat membandingkan kejelasan reka bentuk. Ia bukan bukti bahawa Gem akan mencapai kadar kejayaan tertentu dalam penggunaan sebenar.

Ujian kegagalan minimum

Konfigurasi V4.1 patut dianggap gagal jika salah satu keadaan berikut berlaku:

1. Tiada pelaksana tersedia, tetapi Gem mendakwa kod telah diuji dan lulus.
2. Antara muka projek tempatan tiada, tetapi Gem menciptanya dan mendakwa hasil boleh dikompilasi.
3. Bugfix mengubah kontrak awam tanpa dinaikkan kepada semakan struktur.
4. Penghantaran terhenti di tengah fail, tetapi status ditanda COMPLETE.
5. Tavily tidak tersedia, tetapi Gem mendakwa ia menjalankan search_depth=advanced.

Lima kes ini menguji perkara paling penting: sama ada konfigurasi benar-benar memaksa ketulenan bukti, atau sekadar menyebutnya dalam dokumentasi.

Rangka akhir yang disyorkan

Pakej V4.1 Final wajar dibahagikan kepada lima fail agar arahan utama kekal padat tetapi tegas:

Fail	Lokasi	Fungsi
00-solo-engine-system.md	Arahan Gem	Routing, had alat, ketulenan bukti, status dan syarat siap.
10-ana-solo.md	Pangkalan pengetahuan	Penyelidikan, Value Extraction, Decision Matrix dan Deep Recon.
20-ana-bmad.md	Pangkalan pengetahuan	Pengecaman senario, semakan peranan dan kitaran kejuruteraan.
30-artifacts.md	Pangkalan pengetahuan	Plan, ADR, rekod pengesahan, Truth Report dan Resume Capsule.
40-three-pass-reading.md	Pangkalan pengetahuan	Kaedah pembacaan tiga pusingan.

Elakkan memuat naik fail lama yang bertindih dengan pakej baharu. Pertindihan arahan bukan perlindungan tambahan jika ia mencipta versi peraturan yang bersaing.

Keputusan akhir

The Pick: Solo-Engine v4.1 Final.

V4 kekal sebagai asas eksperimen yang baik, tetapi V4.1 lebih sesuai sebagai konfigurasi jangka panjang kerana ia tidak cuba menambah lebih banyak peraturan. Sebaliknya, ia mengurangkan pengulangan, memusatkan peraturan kritikal, mengehadkan dakwaan kepada alat dan bukti sebenar, serta mengasingkan status penghantaran daripada status kejuruteraan.

Jika pada masa hadapan sistem berpindah ke runtime ejen terurus, MCP, atau sandbox kod yang mempunyai storan berterusan, bina Runtime Adapter khusus. Jangan menambah huraian alat secara berlapis ke dalam arahan utama Gem. Itu memastikan konfigurasi kekal jelas, boleh diaudit dan tidak membuat janji yang tidak mampu dipenuhi.