Salvor ekip koşullarında: birleştirmeler, Windows ve ayrıntılar

Aynı anda açık pull request'ler: 9 çakışmadan 2'ye

Salvor her pull request'ten değişiklik günlüğüne bir satır, sürüm geçmişine bir satır, L1'e bir satır ve L2'ye bir kayıt eklemesini istiyor. Her pull request bunları aynı yerlere eklediği için açık olan herhangi iki pull request çakışıyor.

Bunu ölçmek için açık pull request'lerimden dördünü geliştirme dalının üzerine üst üste koydum. Reponun bugünkü hâliyle 3 birleştirmede 9 dosya çakışması çıktı. Sonra .gitattributes dosyasına üç satır ekledim:

CHANGELOG.md                     merge=union
VERSION.md                       merge=union
.salvor/active_state_verbose.md  merge=union

Bu satırlarla aynı birleştirmelerde yalnızca 2 çakışma kaldı, ikisi de L1'de. Olması gereken yer de orası: Salvor'un kuralına göre L1 satır satır birleştirilmez, baştan yeniden yazılır ve bunu zorlayan şey çakışmadır. Birleştirilmiş değişiklik günlüğünde tekrarlanan başlık yoktu, her sürüm satırı ve her L2 kaydı korunmuştu.

Hafızayı yanlış bırakan sorunsuz bir birleştirme

Tersi durumu fark etmek daha zor. Statik sitemde bir özellik dalını birleştirdim ve git, L1'i hiç çakışma olmadan birleştirdi. Ama birleşmiş L1 "yerel dal, yayında değil" diyordu ve bu, yeni geldiği dalda doğru değildi. Bir sonraki yayın kaydı üzerine yazana kadar iki commit boyunca yanlış kaldı. Hiçbir şey çakışmadığı için yeniden yazmayı tetikleyen bir şey de olmadı.

Windows

Claude Code eklentisini Windows 10'a kurdum ve repolarımdan birinin yeni bir kopyasında çalıştırdım. Bu kopyada git her dosyayı Windows satır sonlarına çevirmişti.

• Gerçek bir görev sorunsuz çalıştı. Hafıza denetiminin zamanının gelip gelmediğini sordum ve denetimi yapmasını istedim. 137 saniye ve 21 tur sürdü, 0,53 dolar tuttu. Denetim doğruydu, L1 ve L2 güncellendi ve dokunduğu her satırda Windows satır sonları korundu: bir dosyada 8 satırın 8'inde, diğerinde 34 satırın 34'ünde. Kuralların istediği gibi commit etmedi, bana sordu.
• Sağlık kontrolü önce betikten çalışmadı. Bir betikten çalıştırıldığında 6 denemenin 6'sında 0 tur ve boş bir sonuçla bitti. Başka bir katkıcı bir düzeltme önerdi (pull request #30, hâlâ açık). Aynı Windows kurulumunda test ettim: 36 tur, 116 saniye ve eksiksiz bir rapor. Durum komutu iki durumda da çalıştı.
• Bir kod analizi sunucusu repoma dosya yazdı. İsteğe bağlı yardımcı sunuculardan biri, sormadan reponun içinde kendi ayar ve hafıza klasörünü oluşturdu. Bir şey bozulmadı, ama ilk çalıştırmadan sonra git status çıktısına bakın.

Kuralları dikkatle okumak

Davranışı test etmek bir yere kadar bilgi veriyor. Bu yüzden kuralları satır satır da okudum. İki örnek:

• Silinsin mi, hiç silinmesin mi? Bir kural, düzeltilen ertelenmiş bulgunun silinmesini söylüyor. Bir başkası, başvurular kırılmasın diye hiçbir kimliğin silinmemesi gerektiğini söylüyor. "closes deferred:x" diyen bir commit tam da böyle bir başvuru. Bunu bildirdim ve kayıtları silmek yerine kapatmayı önerdim.
• Belgeler. Yalnızca okuma yetkisi olan dört ajan, reponun birer bölümünü denetledi: belgeler, eklenti, kural metni ve kıyaslama kodu. Önemli iddiaları kendim kontrol ettim. Bütün göreli bağlantılar ve çapalar çalışıyordu, kırık bağlantı sayısı 0'dı. Buldukları küçük sorunlar, örneğin katkı rehberinin geliştirme dalının adını vermemesi, pull request'e dönüştü.

Pull request'lerim ve bildirimlerim

Aşağıdakilerin hepsi bu serideki testlerden çıktı. Pull request'lerin hepsi açık ve incelenmeyi bekliyor.

Pull request'ler:

• #25: pull request hedefi olarak dev dalını belirtmek ve birim testlerinden önce Chromium'u kurmak.
• #26: bir onay sorusundan önce her seçenek için sade dille tek satırlık açıklama. Böylece uzun bir inceleme formaliteye dönüşmüyor.
• #27: web sunucusundan yayınlanan repolar için yönergeler. Kurulum notlarından çıktı.
• #28: içindeki bilgiyi kaybetmeden Salvor'u kaldırmak.
• #33: oturum başında durum notunu tazeleyen isteğe bağlı kancalar.
• #34: kod analizi sunucusunun sürümünü sabitlemek ve onu çalışma dizinine bağlamak.
• #35: ertelenmiş bulguları silmek yerine kapatmak.

Bildirimler (issue):

• #32: ertelenmiş bulgu kuralları birbiriyle çelişiyor.
• #36: betikten çalışan sağlık kontrolü her seferinde izin sorularına takılıyor.
• #37: kör soru testi ve kapatılması gereken açık olarak eskiyen hafıza.
• #40: bir ajanın mevcut bir öğrenilmiş hata kaydında neyi değiştirebileceği.