Düzenleme ve onaylar

Neyi sorar, neyi sormaz

Yalnızca okuma yapan bir çağrı hiçbir zaman sormaz: dosya okumak, arama yapmak, listelemek, git'ten okumak, skill yüklemek, bir uzmana iş devretmek. Şunlar ise diyalogda durup sizi bekler:

• bir düzenleme ya da yeni bir dosya (edit_file, write_file, dil sunucusu üzerinden yeniden adlandırma, sembol düzenlemeleri);
• Python çalıştırma ortamı run_python;
• politikanın kendi başına izin vermediği bir shell komutu (Shell komutları);
• git'e yazma işlemleri (stage'leme, commit, branch, revert) ve tek push (Git);
• e-posta ya da sohbet mesajı gibi bir gönderim.

Bu sırada çalıştırma arka planda bekletilir. Diyalogda gösterilen hiçbir şey kırpılmaz: düzenleme, değiştirilen kısmın diff'i olarak, yeni dosya bütünüyle, komut da onu çalıştıracak shell'in okuyacağı şekilde renklendirilerek gösterilir. PageUp, PageDown ve ok tuşlarıyla kaydırabilirsiniz. Terminal boyutu ne olursa olsun cevap seçenekleri ekranda kalır.

Diyalog

Başlıkta ivralo'nun ne yapmak istediği, kimin sorduğu ve değişikliğin boyutu (new file, 90 lines, overwrites, +12 −3) yazar. Altında çağrıyla ilgili bilgiler bulunur:

Ardından cevap seçenekleri gelir. Yalnızca bu çağrı için geçerli olanlar gösterilir:

a tur bitince geçersiz olur. Bir planın dalgasında yalnızca o adımın çalışmasını kapsar, yani yanında çalışan başka bir adım yine sorar.

n diyaloğu hemen kapatmaz. Onun yerine ne yapılması gerektiğini yazabileceğiniz bir satır açar, örneğin "eski dönüş değerini koru, onun yerine bir test ekle". Enter bu notu retle birlikte modele gönderir. İkinci kez Esc'e basarsanız not bırakmadan reddedersiniz.

Bazı çağrılar her zaman sorar. Sözleşmesinde her zaman soracağı yazan araçlarda (gönderim, push) daha geniş cevaplar pasif hâle getirilmez, hiç gösterilmez. Böylece hiçbir tuş o çağrının sormasını kaldıramaz.

Yüksek risk. Yüksek riskli bir çağrıda (gönderim, gh ile GitHub gibi başka bir yerde yapılan bir değişiklik ya da hiçbir sözleşmenin kapsamadığı bir araç) Enter'a hiçbir şey bağlı değildir ve odak "reddet" seçeneğindedir. Onay için bilerek basılmış bir y gerekir.

İzin modları

/accept-edits düzenlemeleri otomatik kabul etmeyi açıp kapatır. /confirm otomatik onayı açıp kapatır. Otomatik onayı kapattığınızda düzenlemeleri kabul etme de kapanır, böylece bütün sorular bir anda geri gelir.

Bekleyen bir job'un sorusu da aynı diyalogda açılır, ama yalnızca üç seçenekle: y, o job'un geri kalanındaki bütün düzenlemeler için s ve n. Çünkü a'nın kapsayacağı bir tur da, p'nin kaydedeceği bir önek de yoktur.

Başında kimse olmayan çalıştırmalar ve allow_tools

Kimsenin izlemediği bir çalıştırmada, örneğin bir pipe içindeki ivralo ask'te, zamanlanmış bir görevde ya da bir job'da diyaloğu gösterecek kimse yoktur. Böyle bir çalıştırmanın Python kodu worker'ın sınırları içinde çalışır (Python worker'ı). Ama düzenleme, git'e yazma ve onay gerektiren bir shell komutu kimse görmeden çalıştırılmaz, reddedilir. Gönderimler de öyle.

Başında kimse olmayan bir çalıştırmanın düzenleme yapabilmesinin tek yolu, bir permissions.json içindeki allow_tools'tur. Bu dosya home dizinindeki ya da repo'nun .ivralo/permissions.json dosyası olabilir:

{
  "allow_tools": ["edit_file", "write_file"]
}

Başka bir ad yazılırsa ivralo doctor bunu raporlar ve o ad yok sayılır. Oturum içinde burada adı geçen bir araç, diyalog yerine bir allowed satırıyla çalışır. Genelde doğru yer repo'nun kendi dosyasıdır: "bu repo başında kimse yokken düzenlenebilir" cümlesi, üzerinde çalıştığınız her repo için nadiren doğrudur. Güvenmediğiniz bir klasörde repo'nun allow_tools'u geçerli olmaz.

İsteğinizde adı geçmeyen bir test

Hata yerinde dururken kırmızı bir suite'i yeşile çevirmenin kestirme yolu testi değiştirmektir. Bu yüzden var olan bir test dosyasının düzenlenmesi, düzenlemeler kabul edilmiş olsa bile onay ister ve diyalogdaki bilgiler arasında edits a test the task did not name gerekçesi yer alır. Başında kimse olmayan bir çalıştırma ise allow_tools'ta edit_file olsa bile bunu reddeder.

Bir dosyanın test olup olmadığı repo'nun kendi isimlendirmesine göre belirlenir: tests, test, __tests__ ya da spec adlı bir klasörün altında olması ya da adının test_*, *_test.*, *.test.*, *.spec.*, FooTest veya FooTests olması. İsteğinizde dosyanın adı, yolu ya da içindeki bir test geçiyorsa bu kural uygulanmaz. Ana ajanın bir uzmana iş devrederken yazdığı metin bu açıdan hiçbir şey saymaz, yalnızca sizin yazdıklarınız sayılır. Yeni bir test dosyası oluşturmak, var olanı düzenlemek sayılmaz.

Dil sunucusu üzerinden yapılan bir yeniden adlandırma ya da organize-imports, değiştireceği bütün dosyalar üzerinden değerlendirilir. Aralarında adı geçmeyen tek bir test bile olsa çağrının tamamı onay ister, başında kimse yokken de reddedilir.

Bir test gerçekten yanlışsa ajana onu değiştirmek yerine durumu söylemesi (hangi test, ne bekliyor, kod onun yerine ne yapıyor) talimatı verilmiştir. Düzenlemesine izin vermek istiyorsanız dosyanın adını isteğinizde geçirin.

Bir coder'ın worktree'sini entegre etmek

Kendi git worktree'sinde çalışan bir Code Engineer (paralel bir coder ya da bir instance olarak) çalışırken çalışma alanınızda hiçbir şeyi değiştirmez. İşi bitince bütün değişikliği tek bir patch olarak döner ve bu patch entegrasyon diyaloğunda bir kez daha onay ister. Diyalogda adım, coder ve her dosya için eklenen ve silinen satırlar gösterilir.

Worktree içindeki her düzenleme yapıldığı anda zaten onay istemişti. Oturum boyunca düzenlemeleri kabul etmek ya da allow_tools'ta edit_file bulunması entegrasyon diyaloğunu da kaldırır. Patch'in nasıl uygulandığı ve çakışma olursa ne olduğu Paralel coder'lar ve worktree'ler sayfasında.