Pathrule zor iddiaları nasıl kanıtlar

Pathrule'un teknik standardı basittir: bir ürün iddiası sınırlı bir girdi, kanıt eksik olduğunda tanımlı bir davranış ve bağımsız olarak test edilebilen bir sonuç gerektirir.

Bu sayfa, bilginin Pathrule'a nasıl girdiğine, nasıl seçildiğine ve nasıl iletildiğine dair bu sözleşmeleri bir araya getirir. Remote MCP bağlantısının iletim sınırı farklıdır: hook kurmaz, dolayısıyla bilgi ajan Pathrule'un araçlarını çağırdığında gelir.

Bilgi kalitesi birden fazla denetimden geçer

Pathrule her Markdown dosyasını her prompt'a koymaz. Bilgi birbirinden bağımsız denetimlerden geçer:

1. Seçici keşif. Ajanınız proje taramasını çalıştırdığında etkin talimat dosyaları, bunların içe aktarma zinciri, araç kuralları ve karar kayıtları genel dokümantasyondan ayrılır. Geniş kapsamlı dokümantasyon varsayılan olarak canlı talimat diye içe aktarılmaz, incelemeye sunulur.

2. Kalıcı hale gelmeden önce inceleme, istisnaları açıkça belirtilerek. Çıkarımla elde edilen bilgi bir kişinin onayını bekler: proje taraması adayları yalnızca onaylandığında eklenir, Team Intelligence önerileri ancak bir kişi doğruladıktan sonra ajanlara ulaşır, eskimiş bilgiye yönelik düzeltmeler bir yenileme görevi çözülene kadar hiçbir şeyi değiştirmez ve bir ajanın bir kural için önerdiği çalıştırılabilir kısıt öneri olarak saklanır, bir kişi onaylayana kadar uygulanmaz. Bir asistanın kendi yazdıkları Pathrule'un yazma araçlarından geçer, asistana ait olarak işaretlenir, sürümlenir ve geri alınabilir. Proje öğrenimi bulguları inceleme adımı olmadan paylaşılır, ancak kural olarak değil, her zaman doğrulanması gereken tavsiye olarak. Yalnızca iki şey sorulmadan yazılır, sadece Cloud çalışma alanında ve yalnızca bir ajan ilk kez derin bağlam istediğinde: hangi dosyaların birlikte değiştiğini besleyen, yakın tarihli git geçmişinden okunan dosya yolu çiftleri ve dosya adlarından tanınan, çalışma alanı kökündeki kısa teknoloji hafıza kayıtları. Bunların hiçbiri için dosya içerikleri, diff'ler veya commit mesajları okunmaz. Bkz. Bilgi nasıl katlanarak büyür.

3. Yol sahipliği. Bir kayıt, onu sahiplenen en dar çalışma alanı yoluna aittir. O yolun dışındaki çalışmalar, kayıt sadece aynı depoda bulunduğu için onu almaz.

4. İsteğe uygunluk. Bir kaydın her seferinde mevcut istek için yine de uygun olması gerekir. Uygunluk ve öncelik ayrı ayrı belirlenir ve asla yer değiştirmez: biri bir kaydın uygun olup olmadığına karar verir, diğeri zaten uygun olanlar arasındaki önceliğe karar verir. Öğrenme yalnızca önceliği etkiler. Kendini kanıtlamış bir hafıza kaydını dördüncü sıradan birinciye taşıyabilir; ama hiçbir şeyi uygun değilken prompt'a taşıyamaz. Hacim de sınırlıdır: iletim prompt başına bir bütçeye sığar, dolayısıyla iletilen miktar bilgi tabanının büyüklüğüyle birlikte artmaz.

   Sakin bir prompt için disiplinli yazımın ön koşul olmamasının nedeni budur. Belirsiz ya da kötü yazılmış bir kayıt gürültüye dönüşmez; ilgisi olmayan bir istek için hiçbir zaman uygun hale gelmez. Zayıf bir hafıza kaydının görünür bedeli, karşınıza çıkmamasıdır.

5. Ölçülen iletim ve kullanım. Pathrule neyi ilettiğini ve asistanın neye başvurduğunu kaydeder. Türetilmiş katmanlar en son ne zaman veri aldıklarını bildirir, böylece sessiz bir sistem bağlantısı kopmuş bir sistemden ayırt edilebilir.

   Aynı disiplin, bir kaydın neden iletilmediği için de geçerlidir. "Hiçbir şey uygun değildi", "önceliklendirme çağrısı zaman aşımına uğradı", "yanıt bozuktu" ve "önceliklendirilecek bir şey yoktu" tek bir kelimeyle değil, ayrı sonuçlar olarak kaydedilir; çünkü bunlar farklı düzeltmeler gerektiren farklı durumlardır. Yavaş bir an yavaş bir an olarak bildirilir, böylece hiçbir zaman boş bir bilgi tabanıyla karıştırılmaz.

   İlgili bilgi bütçeye sığmadığında ya da gövdesi makinede zaten bulunmadığında atılmaz, başlığıyla sunulur; böylece asistan onu bilinçli olarak getirebilir. Doğru bir cevabı elverişsiz bir yerde durduğu için çöpe atmak, bu tasarımın önlemek istediği sonuçtur.

6. İncelenebilir bakım. Bir ajanın eskimiş, kodla çelişen, yinelenen ya da belirsiz bulduğu bilgi bir yenileme görevi olarak incelemeye çıkarılır ve bu görev çözülene kadar hiçbir şey değiştirilmez. Yazmalar sürümlenir, çakışmalar açıkça görünür ve silme işlemi geri alınabilir.

Bu denetimler paylaşılan bilgiyi bir depo için küçük, incelenebilir bir işletim sistemine dönüştürür. Bir projenin, tüm dokümantasyon arşivini varsayılan bağlama çevirmeden kararlarını biriktirebilmesinin nedeni bunlardır. Bkz. Bilgi nasıl katlanarak büyür ve Öneriler ve öz denetim.

Tarihli doğrulama

23 Ağustos 2026'da bu sözleşmelere yönelik odaklı otomatik kontroller ana Pathrule ürün deposunda başarıyla geçti; bunlar arasında bilgi keşfi, içe aktarma sırası ve gürültülü kaynakların dışarıda bırakılması da vardı.

Herkese açık bağlam iletimi benchmark'ı github.com/pathrule/benchmarks adresinde ayrıca yeniden üretilebilir. Nasıl ölçüyoruz sayfası yöntemini, ham çıktılarını ve karışık sonuçlarını yayımlar. Ölçülen sonuçlar, ölçüldükleri kurulumları tanımlar; sizin deponuz için garanti değildir.

İşe yarar bir değerlendirme kuralı

Herhangi bir Pathrule iddiası için üç soru sorun:

1. Karara hangi kanıt giriyor?
2. Bu kanıt eksik ya da belirsiz olduğunda ne oluyor?
3. İşi değiştirmesine ya da engellemesine hangi sonucun izin veriliyor?

Yukarıdaki sözleşmeler bu üç soruyu da yanıtlar. Bir özellik tanımıyla bir mühendislik iddiası arasındaki fark budur.