Foremerge: kod yazmadan önce niyet beyan eden coding agent'lar için açık kaynaklı, Git seviyesinde bir protokol

Foremerge'un geliştiricisi, projeye dair otuz bir okuyucu sorusunu bir dev.to yazısında yanıtlayarak, paralel çalışan coding agent'ların birbirini sabote etmesini önlemek için tasarlanmış açık kaynaklı bir koordinasyon protokolünü ayrıntılarıyla tanıttı. Sorular, kodu inceleyen ve bunları bir GitHub tartışmasında gündeme getiren Vedant Madane adlı bir okuyucudan gelmişti; yazar hepsini orada yanıtladı ve şimdi bu soru-cevapları hafif düzenlemelerle yeniden yayınladı, ayrıca ilk kez yanıtlanan üç soruyu da ekledi.

Foremerge nedir

Yazıya göre Foremerge, Git'in üzerinde duran bir koordinasyon katmanı. Apache-2.0 lisansıyla tek bir Rust binary'si olarak geliyor, local-first çalışıyor ve bir CLI, yerel bir JSON API ile bir MCP server sunuyor; hepsi de deponun Git common dizininde saklanan tek bir SQLite veritabanı tarafından destekleniyor. Bir agent, kod yazmadan önce niyetini yayınlıyor ve semantik bir kapsam talep ediyor; bunu yedi öğeli sürümlü bir sözlükten bildirilen bir işlemle etiketliyor: add, extend, modify, replace, remove, rename ve migrate. İki plan aynı anda doğru olamayacaksa, çatışma merge anında değil, paylaşılan depoda yakalanıyor.

Veritabanının Git common dizinine yerleştirilmesi bilinçli bir tercih: bir deponun her worktree'sinin zaten paylaştığı tek konum orası; böylece worktree izolasyonu artı paylaşılan koordinasyon durumu, ek altyapı olmadan geliyor.

Arkasındaki başarısızlık

Yazar, aracın kökenini belirli bir olaya dayandırıyor. Bir agent bir ödeme servisi sınıfını değiştirirken, bir backlog ticket'ı üzerinde çalışan ikinci bir agent aynı sınıfı ek bir sağlayıcıyla genişletmiş. Değişiklikler farklı worktree'lerdeydi, çakışan satırları yoktu ve sorunsuzca merge edildi; oysa ikincisi, birincinin sildiği bir genişletme noktasına bağımlıydı. Kod incelemesi sorunu yakaladı ve CI da bayraklayacaktı, ama yazar, sağlam testler olmadan böyle bir kırılmanın üretime ulaşabileceğini savunuyor. Temizlik bir günlük refactoring'e mal oldu. Aracın dahili bir sürümünü çalıştırdıktan sonra yazar, onu bir dahili araçlar monorepo'sundan ayırdı ve ağustos sonunda açık kaynak yaptı.

Neden niyet koddan önce gelir

Protokolün neden pull request'lerin sonradan yapılan analizine değil de bildirilen niyete dayandığı sorulduğunda, yazar zamanlamaya ve maliyete işaret ediyor: diff tabanlı tespit, bir çarpışmayı ancak her iki agent da token'larını harcadıktan sonra buluyor; geriye kalan en iyi seçenek ise işi çöpe atmak veya refactoring yapmak. Bildirilen bir işlem aynı zamanda bir olgudur; bir diff'ten çıkarılan işlem ise bir tahmindir. Sürüm 0.4.0'da yalnızca bildirilen işlemler HIGH şiddetinde bulgular ileri sürebiliyor; düz metinden çıkarılan eşleşmeler HIGH'nın altında sınırlı, çünkü yüksek şiddette yanlış tahmin eden bir koordinasyon katmanı kullanıcılarının güvenini hızla kaybediyor.

Danışma niteliğinde, deterministik, yerel

Araç uyarır ama asla kilitlemez. Bir kilit, beyan eden agent'ın haklı olduğunu ve işini bitireceğini varsayar; oysa agent'lar işleri sürekli yarıda bırakıyor, dolayısıyla tek bir bayat kilit bir filoyu kilitliyebilir. Yazar ayrıca semantik bir kilidin filesystem yazmalarını araya girmeden uygulanamayacağını, aracın da bunu bilinçli olarak yapmadığını belirtiyor. Yaptırım yerine kabul aşamasında gerçekleşiyor: bir ChangeSet kabul etmek, çözülmemiş HIGH bulgusu olmamasını artı tam aday parmak izine (fingerprint) karşı doğrulama gerektiriyor ve defter geçersiz kılmaları kaydediyor; böylece bir uyarıyı görmezden gelmek sessiz bir karar değil, görünür bir karar oluyor.

Çatışma dedektörü deterministiktir ve LLM yargıcı içermez, çünkü dedektör güven çekirdeğidir; yeniden üretilebilir, test edilebilir, ücretsiz, çevrimdışı ve her kullanıcı için özdeş olmalıdır. Saf kurallar, tam metin değil anlam önemli olduğunda — eş anlamlılar, bildirilmemiş yeniden adlandırmalar ve dosyalar arası sözleşme kayması gibi durumlarda — zorlanıyor; bu yüzden daha bulanık eşleştirme hiçbir zaman HIGH'nın üstünde bulgu öneremeyecek. CRDT'ler elendi çünkü bunlar eşzamanlı düzenlemelerin yakınsamasını ve çatışmaların yok olmasını sağlamak için tasarlanmıştır; oysa Foremerge'un tüm işi uyumsuzlukları gün yüzüne çıkarmaktır. Git notes, sorgulanabilirliği zayıf olduğu için reddedildi. Sert kilitler, bir merge kuyruğu ve editör buffer eşitlemesi ise hepsi amaç-dışı (non-goals) listesinde; her biri aracın gerçekte elinde tutamayacağı bir otorite talep ederdi.

Yol haritası ve açık sorular

Bugünkü birincil kullanıcılar, tek bir makinede iki veya daha fazla agent çalıştıran bireysel geliştiriciler; yazar, filo ölçeğinde kullanımın hâlâ doğrulanmaya ihtiyacı olduğunu söylüyor. Sürüm 1.0, protokol kararlılığı sözü vermeyi hedefliyor; bunu ham verili koordine edilmiş ve koordine edilmemiş karşılaştırmalı testlerle, protokol yüzeyi için sürümlü JSON Schema'larla, sembol kapsamlarının dizge olarak değil yapısal olarak çözülmesini sağlayacak en az bir dil adaptörüyle ve bulguları gerçek çatışmalarla ilişkilendiren kalibrasyon kanıtıyla destekleyerek. Sürüm 0.4.1, istemcilerin boş bir çatışma sonucunun ne kadar bayat olduğunu anlamasını sağlayan bir as_of dizisi ekliyor; bildirilen ile gerçekte düzenlenen arasındaki kayma (drift) tespiti ise 0.5.0 için planlanıyor. Yazar ayrıca, agent'ların gerçekte ne sıklıkla niyet yayınladığı anlamındaki gerçek dünyadaki uyumun, ekibin kendi kullanımının ötesinde bilinmediğini kabul ediyor ve projenin bunun için izler (trace) istediğini belirtiyor.

Neden önemli

Paralel worktree'lerde birden fazla coding agent çalıştırmak rutin hale geliyor ve Git'in satır seviyesi modeli, iki temiz merge semantik olarak uyumsuz olduğunda bunu fark etmiyor. Foremerge tam olarak metinsel ile semantik çatışma arasındaki bu boşluğa odaklanıyor; danışma niteliğindeki uyarılar, deterministik tespit ve local-first depolama tercihleri, bir koordinasyon katmanının meşru olarak neyi dayatabileceğine dair düşünülmüş bir duruş oluşturuyor. 1.0 kriterleri dikkat çekici biçimde ölçülü: karşılaştırmalı testleri ve kalibrasyon kanıtını, pazarlama gereği değil, bir kararlılık sözünün ön koşulları olarak ele alıyor. MCP üzerinden çok agent'lı iş akışlarını deneyen ekipler için bu, izlemeye değer bir proje; soru-cevap formatı da gerekçelerini alışılmadık ölçüde erişilebilir kılıyor.