Solo-Engine V4.1 Final: Daha Az Tekrar, Daha Net Sınırlar, Daha Denetlenebilir Teslim

Kısa hüküm

V4 doğru yönde önemli bir tasarım. Özellikle araç, test, dosya sistemi ve Git yeteneklerinin yalnızca istemde yazdığı için varmış gibi gösterilemeyeceğini kabul etmesi; ayrıca tam kod teslimini gerçek derleme ve test başarısından ayırması güçlü tarafları.

Ancak V4’ün doğrudan uzun vadeli yapılandırma olarak kullanılmasını önermiyorum. Sorun, güvenlik kapılarının yetersizliği değil; bu kapıların farklı dosyalarda tekrar tekrar tanımlanması. Bu durum uzun istemlerde kural seyreltmesine, birbirinden kopan durum kayıtlarına ve kritik şartların bilgi tabanından her seferinde eksiksiz çağrıldığı varsayımına yol açabilir.

Nihai tercih: Solo-Engine v4.1 Final. Bu sürüm, V4’ün araştırma → karar → mühendislik kapalı çevrimini korurken kritik gerçeklik kurallarını ana Gem talimatında toplar; ayrıntılı SOP’leri, şablonları ve süreç kılavuzlarını bilgi tabanına taşır.

V4’ün doğru yaptığı noktalar

V4’ün en değerli katkısı, bir modelin metin içindeki talimatla gerçek araç yeteneği kazanamayacağını açık biçimde kabul etmesidir. Bu yaklaşım şu riskleri doğrudan ele alır:

• Gerçekte çalıştırılmamış bir arama, derleme veya testin yapılmış gibi sunulması;
• Kod parçalarının tam proje teslimi gibi gösterilmesi;
• Kanıtsız bir ADR’nin kabul edilmiş karar statüsüne yükseltilmesi;
• Birden fazla bağımsız ajan çalıştırılmadığı hâlde bunun olmuş gibi anlatılması.

V4 ayrıca FACT, INFERENCE, ASSUMPTION ve UNKNOWN ayrımıyla kanıt sınırını görünür kılıyor. Bu ayrım, özellikle proje bağlamı eksikken modelin varsayımlarını gerçek arayüz bilgisi gibi göstermesini engellemek açısından önemli.

BMAD tarafında da yaklaşım temelde yerinde: tek Gem içinde PM, mimar, geliştirici, kalite güvence ve operasyon bakış açılarıyla kontrol yapılabilir. Ancak BMAD’ın dokümantasyonu; ajanlar, beceriler ve çok adımlı iş akışlarını ayrı çalışma mekanizmaları olarak tanımlar. Bu nedenle tek bir Gem’in yaptığı iş, gerçek bir çoklu ajan çalışma zamanının eşdeğeri değil, “BMAD esintili rol orkestrasyonu” olarak adlandırılmalıdır.11014

Neden V4 olduğu gibi yayına hazır değil?

1. Kritik kurallar bilgi tabanına bırakılamaz

Bilgi tabanındaki dosyaların her yanıtta eksiksiz ve doğru bağlamda çağrılacağı garanti kabul edilemez. Bu yüzden şu kurallar ana talimatta doğrudan bulunmalıdır:

• Araç ve doğrulama sonuçları uydurulamaz.
• Gerçek yürütme yoksa derleme veya test başarısı iddia edilemez.
• Yeni ya da değiştirilmiş her dosya tam içerikle teslim edilmelidir.
• Tam teslim, mühendislik tamamlanması anlamına gelmez.
• Mevcut proje arayüzleri eksikken arayüz uydurulamaz.

2. Fazla tekrar, uyumu artırmak yerine azaltabilir

V4’te durumlar, ADR kuralları, bağımlılıklar ve tamamlanma şartları birden fazla katmanda yeniden tanımlanıyor. Bu teorik olarak kapsamlı görünse de pratikte modelin yalnızca bazı tekrarları izlemesi, farklı ifadeleri çelişkili yorumlaması veya uzun çıktıda kod bütçesini süreç metniyle tüketmesi riskini yükseltir.

V4.1’in ilkesi basit: değişmez kurallar ana talimatta, yöntem ve şablon ayrıntıları bilgi tabanında.

3. “Otomatik döngü” gerçek çalışma sınırları içinde tanımlanmalı

Bir Gem, istemde “otomatik döngü” yazdığı için arka planda çalışmaya, kalıcı terminal kullanmaya veya oturumlar arası görev sürdürmeye başlamaz. V4.1’de otomasyon yalnızca şu sınırlar içinde geçerlidir:

• Mevcut yanıt veya mevcut oturum;
• Kullanıcının açıkça yetkilendirdiği kapsam;
• Gerçekte kullanılabilir araçlar;
• Açık bir tekrar denemesi bütçesi;
• Araç yoksa WAITING_VERIFICATION durumunda durma.

Bu sınır, “otomasyon” sözcüğünün sahte süreklilik veya sahte yürütme anlamına gelmesini engeller.

4. “Sıfır bağımlılık” tek bir ifade olmamalı

“Sıfır bağımlılık” ifadesi genellikle üç farklı anlamı birbirine karıştırır: üçüncü taraf paket kullanmamak, çalışma zamanı gerektirmemek ve teslim edilmeyen yerel dosyalara ihtiyaç duymamak.

V4.1 bunları ayrı sözleşmelere dönüştürür:

• Sıfır bildirilmemiş bağımlılık;
• Varsayılan olarak sıfır yeni üçüncü taraf bağımlılığı;
• Yeni yerel bağımlılıkların tamamının teslim edilmesi;
• Dil çalışma zamanı, SDK, işletim sistemi ve barındırıcı platformun açık çevre önkoşulları olarak kayda geçirilmesi.

Bu yaklaşım, kaynak kodun tek başına bir derleyici, SDK veya hedef platform sağlayamayacağı mühendislik gerçeğini gizlemez.

5. Tam kod teslimi, yeni ve mevcut projelerde farklı ele alınmalı

Yeni bir projede teslim, çalışabilir en küçük proje kapanışını oluşturacak tüm gerekli dosyaları içermelidir: giriş noktası, kaynak dosyalar, yapılandırma, testler, gerekli yerel modüller ve doğrulama giriş noktası.

Mevcut projede ise her yeni veya değiştirilmiş dosya tam olarak verilmelidir. Kullanıcının daha önce sağladığı ve değiştirilmemiş temel dosyaların tekrar basılması gerekmez. Buna karşılık, derlemeyi etkileyecek temel bir arayüz veya yapılandırma dosyası yoksa model bu boşluğu tahmin ederek doldurmamalı; eksik bilgiyi istemelidir.

V4.1’in temel durum modeli

V4.1, “kod yazıldı” ifadesinin tek başına ne anlama geldiğini netleştirmek için üç farklı ekseni ayırır:

Eksen	Soru	Örnek durumlar
DELIVERY_STATUS	Gerekli dosyalar eksiksiz teslim edildi mi?	NOT_STARTED, PARTIAL, COMPLETE
VERIFICATION_STATUS	Gerçek doğrulama kanıtı var mı?	NOT_RUN, STATIC_CHECKED, EXECUTED_PASS, EXECUTED_FAIL
ENGINEERING_STATUS	Mühendislik işi tamamlandı denebilir mi?	DRAFT, WAITING_VERIFICATION, VERIFIED, COMPLETE, BLOCKED

Bu ayrımın kritik sonucu şudur: Bir dosya paketi eksiksiz üretilebilir, fakat gerçek derleme veya davranış testi yapılmadıysa sistem hâlâ WAITING_VERIFICATION durumundadır.

ENGINEERING_STATUS=COMPLETE ancak güncel paket için gerekli doğrulama yapılmışsa, çevre koşulları planla uyumluysa, dosya kapanışı tamamsa ve plan/ADR/doğruluk raporu aynı gerçeği yansıtıyorsa kullanılmalıdır.

Tavily ve araç yeteneği: İstem değil, gerçek bağlantı belirler

Tavily’de search_depth=advanced, ayrıntılı ve yüksek hassasiyet gerektiren sorgular için tanımlanmış gerçek bir seçenektir; daha yüksek alaka düzeyi karşılığında gecikmeyi artırabilir.2411

Fakat bu, Gem’in yalnızca talimat metninde Tavily adı geçtiği için bu parametreyi kullandığını söyleyebileceği anlamına gelmez. V4.1’in kuralı şöyledir:

• Tavily bağlantısı gerçekten varsa ve araç şeması destekliyorsa, karar açısından kritik sorgularda advanced kullanılabilir.
• Araç yoksa, yalnızca mevcut yerel belgeler veya gerçekten erişilebilir arama kaynağı kullanılır.
• Tavily çağrısı, sonuç içeriği, Extract/Crawl çıktısı veya parametre kullanımı asla uydurulmaz.

Bu ayrım hem doğruluk hem maliyet yönetimi için önemlidir. Tavily dokümantasyonu, advanced modunu daha yüksek alaka düzeyi ve yüksek hassasiyetli sorgular için konumlandırırken gecikme-maliyet dengesine de işaret eder.2411

Değerlendirme matrisi

Aşağıdaki puanlar bir çalışma zamanı benchmark’ı değil, bu yapılandırmaların gereksinimlere uyumu üzerine yapılan statik tasarım denetimidir.

Boyut	Ağırlık	V4	V4.1 Final
Gem çalışma sınırı ve araç gerçekliği	%25	4,0	4,8
Üç geçişli okuma, karar matrisi ve Deep Recon	%20	4,5	4,8
Mühendislik emniyet valfleri ve başarısızlık geri basıncı	%20	4,6	4,8
Tam kod ve bağımlılık kapanışı	%15	4,6	4,9
Talimat yoğunluğu ve uygulanabilirlik	%10	2,8	4,5
Durum kurtarma ve kanıt mutabakatı	%10	4,2	4,7
Ağırlıklı toplam	%100	84,2/100	95,5/100

Hesaplama:

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

Buradaki temel iyileşme daha fazla kural eklemek değildir. Asıl kazanım; aynı kuralları daha az tekrar etmek, gerçek araç sınırını netleştirmek ve ana talimatı kendi başına güvenli hâle getirmektir.

V4.1 Final için korunması gereken çekirdek ilkeler

V4.1 Final paketi aşağıdaki unsurları korumalıdır:

1. İki net giriş noktası: /ana-solo analiz ve karar için, /ana-bmad planlı mühendislik teslimi için.
2. Kanıt ayrımı: FACT, INFERENCE, ASSUMPTION, UNKNOWN etiketleri.
3. Araç gerçekliği: Arama, yürütme, dosya yazma, Git ve dağıtım yalnızca gerçek araç kanıtıyla ifade edilir.
4. Sert mühendislik kapıları: Algoritma uygunluğu, mimari ön kontrol, sözleşme değişikliği denetimi ve başarısızlık geri basıncı.
5. Tam dosya teslimi: Çıktı sınırına gelindiğinde yalnızca dosya sonunda durmak; yarım dosya bırakmamak.
6. Doğrulama dürüstlüğü: Statik inceleme ile gerçek araç zinciri başarısını ayırmak.
7. ADR yaşam döngüsü: PROPOSED, ACCEPTED, SUPERSEDED gibi statülerin yalnızca uygun kanıtla değiştirilmesi.
8. Doğruluk raporu: “Mutlak hakikat” iddiası değil, mevcut kanıtın desteklediği durum fotoğrafı.

En güçlü itiraz ve yanıtı

İtiraz: V4 zaten titiz; yeniden düzenleme biçimsel bir iyileştirme olabilir.

Yanıt: Risk, kuralların teorik eksikliği değil, gerçek yanıtta uygulanma oranıdır. Aynı durumların ve koşulların ana talimat, süreç kılavuzu ve artefakt şablonlarında tekrar edilmesi; kısmi eşleşme, durum tutarsızlığı ve aşırı uzun yanıtlar üretme olasılığını artırır. V4.1’in amacı güvenlikten taviz vermek değil, güvenliği daha kısa, daha merkezî ve daha denetlenebilir hâle getirmektir.

Son karar

• Tercih: Solo-Engine v4.1 Final.
• İkinci seçenek: V4; iç deneme için kullanılabilir, ancak uzun süreli ana yapılandırma olarak önerilmez.
• Geçiş şartı: Gelecekte kalıcı kod çalışma alanı, MCP, Gemini API Managed Agent ya da gerçek bir yürütme ortamı eklenirse, ana talimata yeni araç yetenekleri yığmak yerine ayrı bir Runtime Adapter katmanı eklenmelidir.

V4.1 Final’in ana mesajı nettir: Modelin yapabileceğini genişletiyormuş gibi görünen ifadeler yerine, gerçekten yapabildiği şeyi açıkça sınırlayan; teslimi, doğrulamayı ve tamamlanmayı ayrı ayrı kaydeden bir mühendislik sistemi kurmak gerekir.