OpenRig ile takım kurarken çalışma alanına kim güveniyor?

Bir ekip iki kodlama ajanıyla küçük bir değişiklik denemek istiyor. Bir ajan uygulama koduna bakacak, diğeri sonucu inceleyecek. Takımı başlatmak birkaç komutluk iş gibi görünüyor. Ancak denemenin yapılacağı makinede başka projeler de var. Aynı kullanıcı hesabıyla açılan oturumlar, sağlayıcıların yapılandırma dosyalarına ve çalışma alanı güven kayıtlarına dokunabiliyor. Ajanlar henüz tek satır kod yazmadan, ekibin yanıtlaması gereken soru değişiyor: Takımın sınırı nerede başlıyor, makinenin geri kalanından nerede ayrılıyor?

OpenRig, Claude Code ve Codex gibi kodlama ajanlarını birlikte çalıştırmak için açık kaynak bir sistem. Yerel servis, tmux oturumları, SQLite durum kaydı, komut satırı ve terminal arayüzüyle takımın oturumlarını yönetiyor. Takım yapısı YAML ile tanımlanabiliyor; kalıcı seat adresleri sayesinde iş, yalnızca bir terminal penceresinin adına bağlı kalmıyor. Önceki OpenRig yazısında mesaj ile sahiplenilmiş görev arasındaki farkı işlemiştik. Bu kez iş daha başlamadan oluşan yapılandırma etkisine bakıyoruz.

Takım tanımı ile makine ayarı farklı şeyler

Bir RigSpec, takımın kimlerden oluştuğunu ve koltuklar arasındaki ilişkiyi tarif eder. Fakat takımın işlemesi için kodlama ajanlarının gerçekten açılması, projeyi güvenilir çalışma alanı sayması ve OpenRig ile haberleşmesi de gerekir. Projenin README dosyası bu nedenle kurulum, servis başlatma ve seat açma aşamalarını ayrı ayrı anlatıyor. Özellikle sağlayıcı ayarlarının yalnızca OpenRig’in kendi durum dizininde kalmadığını açıkça belirtiyor.

Örneğin servis açıldığında Codex tarafına etkinlik kancaları ve güven kayıtları yazılabiliyor. Seat açılırken çalışma alanına güven kaydı ekleniyor. Claude Code tarafında da çalışma alanı ayarları, durum satırı ve seçilen kaynaklara bağlı bağlantılar değişebiliyor. Bu, uygulamanın gizlice her dosyaya sınırsız erişim verdiği anlamına gelmez. Ama “yalnızca yeni bir terminal açtık” demek de doğru olmaz. Bir ekip OpenRig’i değerlendirirken yapılan değişikliklerin adreslerini ve kapsamını önceden görmeli.

rig setup --dry-run kurulum planını incelemek için yararlı. Yine de resmî açıklama bunun daha sonra gerçekleşen bütün servis ve seat açılışı etkilerini önceden göstermediğini söylüyor. Sadece kuru çalıştırmanın temiz çıkması, tüm kullanıcı hesabı yapılandırmasının değişmeden kalacağına dair garanti değildir. Ortak bir geliştirme sunucusunda veya birden fazla müşteriye ait depoların bulunduğu makinede bu ayrım önem kazanır.

Küçük bir denemede sınır nasıl çizilir?

Şöyle bir deneme düşünelim: Bir ekip iç kullanım panelinin arama sonucundaki boş durum metnini düzeltecek. Kod değişikliği dar kapsamlı. Bir owner seat kodu yazacak, bir checker seat sonucu görecek. İlk karar hangi modelin daha hızlı olduğundan önce gelir. Bu iki seat hangi kullanıcı hesabında açılacak, o hesabın hangi depolara erişimi var, sağlayıcı yapılandırması hangi diğer işlerle paylaşılıyor?

Bu sorular özellikle incelemeci rolü için önemli. İncelemeci yalnızca ilgili değişiklik ve test çıktısını görmeli diye tasarlanmış olabilir. Ama aynı işletim sistemi hesabıyla çalıştırılıyorsa başka bir proje dizinine teknik olarak erişebiliyor olabilir. Seat adı bir niyet beyanıdır; dosya sistemi yetkisi değildir. İki rolü ayrı adlandırmak tek başına ayrı güvenlik bölgeleri oluşturmaz. Ekip, makine hesabını ve çalışma dizinlerini seçerken bunu açıkça hesaba katmalı.

Başlangıç için ayrı bir deneme ortamı seçmek daha anlaşılır olabilir. Ortamın sağlayıcı oturumu, erişilebilir depoları ve dış ağ bağlantıları bilinir. Ekip önce neyin değiştiğini kaydeder, sonra yalnızca belirlenmiş depoda takımı açar. rig ps --nodes ile seat’lerin hazır olup olmadığına bakılabilir; fakat hazır görünmeleri izin sınırlarının doğru olduğu anlamına gelmez. Doğrulama, ayrıca dosya erişiminin ve beklenen sağlayıcı ayarlarının incelenmesini gerektirir.

Bir başka nokta da sağlayıcı maliyeti. OpenRig açık kaynak ve kendi ortamınızda çalışıyor olabilir; ajanların kullandığı modellerin bedeli bundan ayrı. Birden fazla seat açmak, her birinin hangi hesap üzerinden çalıştığını ve hangi limitleri tükettiğini görünür kılma ihtiyacını artırır. Bu nedenle yetki envanterine hesap ve harcama sorumluluğunu da eklemek gerekir.

Kolaylık ile yetki arasındaki fark

OpenRig’in takım kurma kolaylığı değerli. Birkaç komutla terminal oturumlarını, rollerin adreslerini ve koordinasyon ekranını düzenlemek, ajanın kim olduğunu hatırlamak için sohbet geçmişi arama yükünü azaltır. Sorun bu kolaylığı doğrudan kurum politikasına eşitlemekte. Bir seat’in kodu değiştirebilmesi, ana dala birleştirme veya üretime dağıtma yetkisi olduğu anlamına gelmez. Bir takımın çalışma alanına güvenmesi, o depodaki bütün dosyaların talimat olarak güvenilir olduğu anlamına da gelmez.

Depodaki README, harici bir bağlantı veya üçüncü taraf paketinin döndürdüğü metin, ajanın çalışma sırasında karşılaştığı veri olabilir. Bu tür içeriklere iş tanımını değiştirme yetkisi vermemek gerekir. İnsan tarafından verilen görevin kapsamı ile araçtan gelen metnin kaynağı birbirine karışırsa, doğru kurulmuş bir terminal takımı bile yanlış işi hızlıca yapabilir. Kontrol listesinde yalnızca makine ayarları değil, ajanın hangi kaynağı talimat sayacağı da olmalı.

OpenRig’in belgeleri, izinleri seçerken daha geniş erişimin ayrıca ve bilinçli olarak tercih edilmesi gerektiğini anlatıyor. Bu iyi bir başlangıç noktası. Yine de ekip kendi kabul ölçütlerini yazmalı: Ajan yerelde hangi dosyaları değiştirebilir? Başka bir depoya geçebilir mi? Ağ üzerinden nereye yazabilir? Birleştirme veya dağıtım için kim karar verir? Bu kararlar sözlü kalırsa bir sonraki takım aynı makinede daha geniş yetkiyle başlayabilir.

Uygulanabilir kontrol

İlk deneme için tek depo ve küçük bir değişiklik seçin. Başlatmadan önce kullanıcı hesabında zaten bulunan sağlayıcı yapılandırmasını ve çalışma alanı güven kayıtlarını güvenli biçimde envantere alın; gizli değerleri kopyalamayın. Kurulum planını inceleyin, sonra servis ve seat açılışı sonrasında ilgili ayarların nasıl değiştiğini karşılaştırın. Takımın gerçekten ihtiyaç duymadığı izinleri kaldırın veya denemeyi daha dar bir hesapta tekrarlayın. Bunu üretim deposu üzerinde ilk kez keşfetmeyin.

İş bittiğinde iki ayrı sonuç arayın. Birincisi, kod değişikliğinin doğrulanmış olması: hangi sürüm incelendi, hangi test çalıştı, kim kabul etti? İkincisi, deneme ortamının beklenen sınırlar içinde kalması: hangi yapılandırma değişti, ne geri alındı, ne bilinçli olarak bırakıldı? İlk sonucu bir kod incelemesi, ikincisini ortam incelemesi verir. İkisini aynı “ajan işi tamamladı” cümlesine sıkıştırmak, sonraki denemeyi güvenilir kılmaz.

OpenRig kodlama ajanlarının bir takım olarak başlatılması ve gözlenmesi için somut bir zemin sağlıyor; makine güveni ve kurumsal yetki ise ayrıca tanımlanmalı. Ajanların şirkette hangi role, beceriye ve politikaya bağlı olduğunu dosyalar üzerinden görünür kılmak için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye yönelik self-hosted, dosya tabanlı bir platform sunuyor.