AnswersPublished14 sources
V4.3’e geçiş için önce sürüm değil, dağıtım zinciri netleşmeli
Dışarıya dönük sürüm numaralarında v4.3, v4.4 gibi iki bileşenli bir biçim öneriliyor; mevcut inceleme, deponun v4.3’e hazır olduğunu göstermiyor. Kurulum ve dağıtımda kirli çalışma ağacını koruyan kontroller var; ancak bağımlılık ön denetimi, kaynak doğrulaması ve ana makine seçimi eksik.
YayımlayanGörseller GPT Image 2 ile oluşturuldu
Research answer
Key takeaways
- Dışarıya dönük sürüm numaralarında v4.3, v4.4 gibi iki bileşenli bir biçim öneriliyor; mevcut inceleme, deponun v4.3’e hazır olduğunu göstermiyor.
- Kurulum ve dağıtımda kirli çalışma ağacını koruyan kontroller var; ancak bağımlılık ön denetimi, kaynak doğrulaması ve ana makine seçimi eksik.
- CI, iki bileşenli sürüm kuralını veya beceri paketlerinin bütünlüğünü henüz doğrulamıyor.
- Cline, Roo ve Gemini için dosyaların depoda bulunması, ilgili uygulamada doğru yüklendiklerini kanıtlamıyor.
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W](https://d15bya8fi85z1v.cloudfront.net/chat/JRtyWXL5XMODkxxCStM9mCCPWvd2/images/A169BDCC1EF49A4CC481/92E7045358C209E36272.png)
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"建议将本仓库对外版本统一为 v4.3，采用轻量发布管理；但目前不能认定工作树已经是“干净且完整可部署的 v4.3”。本轮完成的是只读审查，没有更新仓库、修改版本、删除历史、运行测试或执行部署。\n\n 版本与历史清理\n\n 对外使用 v4.3、v4.4 这样的两段版本；内部套件身份继续保留 V4，不必为了展示版. Topic tags: general web, llm, agents, ai, automation. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts wit
V4.3’e geçişte asıl mesele yalnızca sürüm etiketini güncellemek değil. Depodaki inceleme; sürüm kaynağı, CI kontrolleri ve Cline, Roo ile Gemini gibi farklı ana makinelerdeki dağıtım yollarının henüz birbiriyle tam örtüşmediğini gösteriyor.
Öneri, dışarıya dönük sürüm numaralarını v4.3, v4.4 gibi iki bileşenli tutmak; iç paketin V4 kimliğini ise korumak. Ancak bu, mevcut deponun temiz ve dağıtıma hazır bir v4.3 olduğu anlamına gelmiyor. Yapılan çalışma yalnızca salt okunur bir incelemeydi: depo güncellenmedi, sürüm değiştirilmedi, geçmiş kayıtlar silinmedi, test veya dağıtım çalıştırılmadı.
Sürüm sadeleşebilir; tek bir doğru kaynak gerekli
README’deki sürüm bilgisi hâlâ README.md:3 konumunda v4.2.0 olarak görünüyor; mühendislik giriş noktası olan bmad-suite-v4/skills/bmad/SKILL.md:11 ise V4.2 diyor. scripts/suite_versions.py:28 dosyası V4 kimliğini tanıyor, ancak küçük sürüm numarasını bütün yüzeylerde besleyen tek bir kaynak bulunmuyor.
Bu nedenle ilk adım; dokümantasyon, kurulum mesajları ve CI kontrollerinin kullanacağı tek bir sürüm kaynağı belirlemek olmalı. Depo adını baştan aşağı değiştirmek, geçmişi yeniden yazmak veya kapsamlı bir sürüm yönetim sistemi kurmak gerekli görünmüyor. Commit kimliği ve dosya özetleri de kaynağı izlemek ve kullanıcı varlıklarını korumak için kullanılmaya devam etmeli.
Eski sürüm önbelleği .versions/v4.0.0/ olası bir temizlik adayı. Ancak silmeden önce etkin dağıtımların veya bağlantıların bu dizine dayanmadığı doğrulanmalı. scripts/tag-cache.py:109 içindeki önbellek girişi, eski etiket adlarının otomatik olarak yeniden kullanılmasını zaten engelliyor.
Öte yandan, geçmişe ait her dizin gereksiz sayılmaz. verification/legacy-bmad-output/, docs/adrs/ADR-20261012-bmad-solo-anti-bureaucracy-and-programmatic-guards.md:232 belgesinde anılıyor. _bmad-solo-source/legacy-skills/ ise üst kaynak becerileriyle ilgili inceleme için önemli. Bu materyallerin hiçbiri bu çalışma sırasında silinmedi.
Kurulum korumaları var, fakat ilk kontroller eksik
Kurulum ve dağıtım zincirinde korunması gereken kontroller mevcut. install.sh:50, kirli çalışma ağacının üzerine yazılmasını reddediyor. bs.sh:298, güncellemede ileri yönlü birleştirme (fast-forward) istiyor ve yeni betiğe geçiş yapıyor. scripts/deploy-managed-cli.py:104 ise yazma işleminden önce çakışmaları denetliyor. Daha yalın sürüm numaraları, bu korumaları kaldırmak için gerekçe değil.
Eksikler daha çok kurulum öncesinde ve farklı ana makinelerle entegrasyonda görülüyor. install.sh:14 şu anda yalnızca V4 uyumluluğuyla ilgili parametreleri alıyor; ana makine seçimi, salt okunur ön inceleme veya mod hedefi gibi seçenekleri aktarmıyor. Bağımlılıklar README’de açıklanmış olsa da kurulum girişinde ortak bir bağımlılık denetimi bulunmuyor (README.md:30). Ayrıca mevcut kurulum yerel depo girişini kullanırken güncellemeler yapılandırılmış uzak kaynağa yöneliyor (bs.sh:305); incelenen giriş noktalarında bu kaynağın beklenen depo olduğu doğrulanmıyor.
Sorumlulukları basit tutmak daha uygun: kurulum girişi güvenilir kaynağı almalı, ön koşulları kontrol etmeli ve parametreleri aktarmalı. Dağıtım girişi ise ana makine uyarlaması, ön inceleme, güncelleme, kaldırma ve kullanıcı varlıklarının korunmasını üstlenmeli. Bunların üzerine ayrı bir sürüm orkestrasyonu katmanı eklemek gerekmiyor.
CI, önerilen sürüm kuralını henüz uygulamıyor
.github/workflows/ci.yml:3 iş akışı ana dala yapılan gönderimlerde ve birleştirme isteklerinde çalışıyor; sürüm etiketiyle tetiklenen bir yayın denetimi görünmüyor. .github/workflows/ci.yml:41 içindeki eklenti kontrolü yapı ve adlandırmaya bakıyor, sürüm biçimine değil.
scripts/suite_versions.py:99 içindeki etiket doğrulaması da yalnızca ana sürüm işaretlerini kontrol ediyor. tests/roo_distribution/test_suite_versions.py:80 testleri üç bileşenli sürümlere ve sürüm biçiminde olmayan etiketlere açıkça izin veriyor. Dolayısıyla mevcut CI’nin iki bileşenli sürüm kuralına uyduğu söylenemez.
En azından yeni yayın etiketlerinin v4.sayı biçiminde olması, etiketin tek sürüm kaynağıyla eşleşmesi ve kullanıcıya gösterilen sürüm metinlerinin tutarlı kalması doğrulanmalı. Bunun için geçmiş etiketleri topluca değiştirmek veya üçüncü taraf bağımlılıkların sürümlerini aynı kurala bağlamak gerekmiyor.
Beceri paketlerinin bütünlüğü de CI’ye eklenmeli. bmad-suite-v4/skills/bmad/scripts/validate-solo-package.py:5 doğrulama aracı mevcut, ancak iş akışında çağrılmıyor (.github/workflows/ci.yml:55). Kontroller yalnızca depo içindeki bağlantılarla sınırlı kalmamalı; dağıtım sonrasında oluşan dosya referanslarını da sınamalı.
Üst kaynak becerileriyle canlı bağlantı yok
Mevcut yönlendirme bu deponun kendi iş akışlarına gidiyor (bmad-suite-v4/skills/bmad/references/capability-map.md:3). scripts/deployment_source.py:64 paketleme sırasında takım dizinini topluyor, geçmiş beceri kaynak dizinini toplamıyor. İncelenen etkin kaynaklarda üst becerileri canlı biçimde denetleyen veya güncelleyen bir hat da bulunmadı.
Bu, üst kaynak becerilerinin yerel giriş noktalarının doğrudan çalışma bağımlılığı olmadığı anlamına geliyor. Ancak üst kaynağın güncellenmesi, daha önce çıkarılıp uyarlanmış yerel iş akışlarını kendiliğinden güncellemiyor. Bu nedenle burada otomatik bir uyumluluk garantisinden değil, zamanla oluşabilecek bakım ve sürüm sapması riskinden söz ediliyor.
Geçmiş becerileri doğrudan geri eklemek de yeterli değil. Örneğin _bmad-solo-source/legacy-skills/bmad-help/SKILL.md:25, yapılandırma, dizin envanteri ve ayrıştırıcı bileşenlere dayanıyor. _bmad-solo-source/legacy-skills/bmad-build-auto/SKILL.md:6 ise bir işleme programına ihtiyaç duyuyor. Sadece açıklama dosyalarını kopyalamak bu becerileri çalışır hâle getirmez.
Daha güvenli yol, kararlı yerel analiz ve mühendislik girişlerini koruyup onaylanan üst kaynak becerilerini yetenek haritasına göre bağlamak. Her bağlantıda kaynak commit’i ve gereken yardımcı varlıklar kaydedilmeli; güncelleme öncesinde ekleme, silme ve bağımlılık değişiklikleri denetlenmeli. Devam eden görevleri sık değişen bir üst kaynak dalına doğrudan bağlamak önerilmiyor. Güncelleme bildirimi ile otomatik, anlık değiştirme de ayrı konular: kurulum veya güncelleme sırasında kontrol ve ayrıca isteğe bağlı hatırlatma yeterli olabilir; sürekli çalışan bir izleyici varsayılan olmamalı.
Cline: CLI ve eklenti var, depo uyarlaması tamamlanmamış
Cline hem komut satırı arayüzü (CLI) hem de IDE eklentisi sunuyor. Belgeleri ayrıca uygulamalar genelinde geçerli küresel yapılandırmayla yalnızca geçerli çalışma alanına uygulanan proje yapılandırmasını ayırıyor. 4
1
Bu depoda bulunan bmad-suite-v4/cline/templates/bmad-router.md:3, etkin olmayan ince bir yönlendirme şablonu. tests/roo_distribution/test_host_adaptation.py:85 içindeki gerileme testi, şablonun etkin Cline kural girişine yazılmamasını bekliyor. Dolayısıyla dosyanın varlığı, Cline entegrasyonunun dağıtıma hazır olduğunu göstermiyor.
Öneri, ortak yöntem içeriğini koruyup CLI ve eklenti için ayrı, ince uyarlamalar üretmek. Analiz ve mühendislik görevleri Cline’ın Plan/Act yaklaşımına eşlenebilir; kullanıcıların beceri komutlarını ezberlemesi veya Roo mod yapılandırmasının doğrudan içe aktarılması gerekmemeli. Ayrıca şablondaki yöntem yolları depo köküne göre çözümleniyor (bmad-suite-v4/cline/templates/bmad-router.md:8); başka projelere kopyalandıklarında yeniden çözümlenmeden çalışacakları varsayılmamalı.
Roo ve Gemini’de dosyanın bulunması, yüklemenin kanıtı değil
Roo için dağıtım haritasında küresel kurallar ve belirli modlar yer alıyor (scripts/deployment_source.py:86). Ancak dosyaların diskte bulunması, ana makinenin onları yüklediğini kanıtlamıyor. Ayrıca iki özel modda MCP izinleri tanımlı değil (bmad-suite-v4/roo/settings/custom_modes.yaml:5); doğrulayıcı ise izin gruplarını sabit kabul ediyor (scripts/validate-roo-contracts.py:158). Damıtma araçları eklenecekse yalnızca yönergeleri değil, mod yapılandırmasını ve doğrulama kodunu da gözden geçirmek gerekiyor.
Gemini tarafında mevcut yöntem, eklenti ve kural dizinlerinin fiziksel bir kopyasını oluşturuyor (scripts/deployment_source.py:81). Bu, Gemini CLI’nin yerel eklenti mekanizması üzerinden kurulup doğrulanmış bir entegrasyonla aynı şey değil. Gemini’nin yerel eklentileri becerileri ve MCP sunucularını paketleyebiliyor; kurulum kaynak içeriğin bir kopyasını oluşturuyor ve güncelleme ayrı bir komutla yapılıyor. 11
9 Bu nedenle var olan kopyalama hattı ile yerel eklenti hattı ayrı destek hedefleri olarak ele alınmalı.
Dağıtım sonrası referanslarda da bir boşluk saptandı. Küresel temel kural bmad-suite-v4/rules/bmad-core.md:38 içinde becerilere göreli bir yol kullanıyor. Ancak scripts/deployment_source.py:83 kural kopyasıyla becerileri farklı yerlere yerleştiriyor. Bu yol dosyanın bulunduğu konuma göre çözümlendiğinde dağıtılan beceriye doğrudan ulaşmıyor.
Proje yönetimi tarafında da eski ve yeni yaklaşımlar yan yana. Proje girişi specs/tasks/_active.md:10 tek bir odak işaretçisi kullanıyor; dağıtılan temel kural ise hâlâ eski etkin planı arıyor (bmad-suite-v4/roo/rules/02-bmad-core.md:8). Analiz modunun düzenleme kapsamı da yeni proje belgesi alanlarını içermiyor (bmad-suite-v4/roo/settings/custom_modes.yaml:8). Sınır net olmalı: küresel kurulum yeniden kullanılabilir yöntem, beceri ve ana makine uyarlamalarını; proje düzeyi kurulum ise o projeye ait giriş noktası, alan kuralları, kararlar ve görevleri taşımalı. scripts/deployment_source.py:64 kaynak toplarken depo proje belgelerinin tamamını dağıtıma almıyor; bu ayrım korunmalı.
Damıtma aracı bağımsız bir yerel MCP hizmeti olmalı
solo-distill-mcp için önerilen varsayılan, ana makinenin bağımsız bir yerel MCP hizmetini çağırması. Hizmet, izin verilen projeyi okuyup aday materyalleri oluşturabilir; onaylanmış bir belge yayımlama adımı bunları proje içine aktarabilir. Yöntem paketi hizmetin tüm kaynak kodunu içine almak yerine bağlantı uyarlamasını ve gereken yetenekleri tanımlamalı.
Hizmetin gerçekten kullanılabilir olup olmadığı özelliklerine bakılarak belirlenmeli. Mevcut kahverengi alan yönetişim süreci; sürüm, araç bildirimi, dil kapsamı, tüketiciler ve içerik parçalama desteğinin kontrol edilmesini zaten istiyor (bmad-suite-v4/skills/bmad/references/procedures/brownfield-distill-governance.md:22). Ancak bu incelemede hizmetin güncel kaynak kodu okunmadı; dolayısıyla belirli bir arayüzün veya otomatik kaydın çalıştığı söylenemez.
MCP, günlük analiz ve kodlama için güçlendirici bir yetenek olmalı. Damıtma motorunu açıkça gerektiren bir başlatma akışında ise zorunlu ön koşul sayılabilir. Hizmet yoksa yalnızca ona bağlı adım durmalı; bütün yöntem paketi kullanılamaz hâle gelmemeli. Normal dosya okumayı, damıtma motorunun doğrulandığı gibi sunmak da doğru değil.
Çevrimdışı tarama, kaynak doğrulama ve isteğe bağlı model desteği ayrı katmanlar olarak ele alınmalı. Model kullanılamadığında yapısal kanıtlar ve belirsizlikler korunabilir; fakat tam anlamsal damıtma performansı vaat edilemez. Bu sınır, süreçteki çevrimdışı kullanım ilkesiyle de uyumlu (bmad-suite-v4/skills/bmad/references/procedures/brownfield-distill-governance.md:24).
GitHub ve SSH tünelini varsayılan çalıştırma mimarisi yapmak önerilmiyor. Kaynağın nerede yayımlandığıyla hizmetin nerede çalıştığı birbirinden ayrılmalı. Uzak hizmet yalnızca açık bir ihtiyaç varsa seçenek olmalı; veri aktarımı, kimlik doğrulama, proje izolasyonu, bağlantı kesintileri ve model hizmeti bağımlılıkları ayrıca yönetilmeli. SSH tüneli bu kontrollerin yerine geçmez.
V4.3 öncesi önerilen sıra
- Gerçek v4.3 kaynağını belirleyin, tek bir sürüm kaynağı oluşturun ve silinebileceklerle korunması gereken varlıkları ayırın.
- Dağıtım sonrası referansları, eski ve yeni proje girişlerini, ayrıca belge yazma izinlerinin kapsamını düzeltin.
- CI’ye iki bileşenli sürüm etiketi ve beceri paketi bütünlüğü denetimlerini ekleyin.
- Cline, Roo ve Gemini’yi ayrı ayrı uyarlayıp küresel yükleme, proje geçersiz kılmaları, izinli ve reddedilen davranışlar, güncellemeler ve üçüncü taraf varlıkların korunmasını doğrulayın.
- Bağımsız yerel damıtma hizmetini en son bağlayın; hizmetin çalıştığı, eksik olduğu veya uyumsuz kaldığı durumların yanı sıra model kullanılamadığında ve işlem yarıda kesildiğinde ne olduğunu sınayın.
Bunlar tamamlanmış değişiklikler değil, önerilen sonraki mühendislik adımlarıdır. İncelemenin ana sonucu şu: sorun sürüm numarasının fazla karmaşık olması değil; kaynak, dağıtım yolu, ana makine yüklemesi ve proje yönetimi bileşenlerinin henüz uçtan uca doğrulanmaması. V4.3 tamamlandı demek için yalnızca sürüm metnini değiştirmek değil, gerekli kontrolleri de çalıştırıp doğrulamak gerekiyor.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "V4.3’e geçiş için önce sürüm değil, dağıtım zinciri netleşmeli"?
Dışarıya dönük sürüm numaralarında v4.3, v4.4 gibi iki bileşenli bir biçim öneriliyor; mevcut inceleme, deponun v4.3’e hazır olduğunu göstermiyor.
What are the key points to validate first?
Dışarıya dönük sürüm numaralarında v4.3, v4.4 gibi iki bileşenli bir biçim öneriliyor; mevcut inceleme, deponun v4.3’e hazır olduğunu göstermiyor. Kurulum ve dağıtımda kirli çalışma ağacını koruyan kontroller var; ancak bağımlılık ön denetimi, kaynak doğrulaması ve ana makine seçimi eksik.
What should I do next in practice?
CI, iki bileşenli sürüm kuralını veya beceri paketlerinin bütünlüğünü henüz doğrulamıyor.