İnceleme hesaplaması (kohortlar, eksenler ve deterministik diff'ler)

PR’ın İncele sekmesi, inceleme pipeline’ı çalışırken onun canlı ilerlemesidir; işini bitirdiğinde ise yayınladığı yapıt ve üzerindeki eylemlerdir. Tek sekme, iki durum — çünkü ikisi aynı şeyin iki farklı andaki hâlidir. Varsayılan bir sekme değildir: bir PR’ın incelemesi, biri istemedikçe yoktur; dolayısıyla onu açan şey AI’ya sor’dur.

Bu sekmenin arkasında cc_server dosya kohortları oluşturur, deterministik eksenleri çalıştırır ve bunları review_studio.* RPC işlemleri üzerinden sunar (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute ve bunların watch* ikizleri). Hâlâ pr.reviewStudio adını taşıyan kalıcı bir düzen, aynı İncele sekmesini açar.

İncele sekmesinde:

Birleştiren ajan, publish_artifact ile sıradan bir konuşma yapıtı yayınlar; böylece sekme onu, bir sohbet balonunun açtığı aynı yapıt görüntüleyicisi üzerinden gösterir — yapıt sisteminin incelemeye özel bir kopyası yoktur.
Bulgular yanındaki bir şeritte durur; karar ise bir gösterge paneli başlığı yerine yapıtın üstündeki ince bir çubukta yer alır.
PR’ın head’i incelemenin ardından ilerlediğinde, incelemenin güncel olmadığını belirten bir banner görünür.

Akış için bkz. YZ destekli inceleme kullanma, sonucu üzerine işlem yapmak için bkz. Bir PR’ı inceleme ve birleştirme.

Kohortlar

Kohortlar, PR’ın değişen dosyalarını anlamca birbirine ait olan, içerikten türetilmiş dosya gruplarına ayırır ve en riskli grup önce okunacak şekilde etkiye göre sıralar. Her head-SHA değişiminde yeniden hesaplanır ve tümüyle değiştirilirler; her kohortun push’lar arasında kararlı bir anahtarı vardır, böylece bir özet ve inceleme ilerlemesi bir rebase’i atlatır.

Depoda kod dizini yoksa kohortlar yol gruplamasına geri düşer. Bir depoyu indekslemek için Ayarlar → Çalışma alanı → Depolar’ı kullanın — her depo satırında, index_code pipeline’ını çalıştıran ve ilerlemeyi olduğu yerde bildiren bir Kodu indeksle eylemi bulunur.

Kod grafiği yalnızca birlikte gelen bir dil bilgisine sahip dilleri ayrıştırır (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Başka bir dildeki bir depo, onu ne kadar sık indekslerseniz indeksleyin asla anlamsal kohort üretemez.

Bir ajan, set_cohort_summary ile bir kohort için markdown özeti kaydedebilir ve add_review_diagram ile yapılandırılmış bir anlatım diyagramı ekleyebilir — tipli bir dizi, varlık-ilişki ya da durum makinesi nesnesi; asla mermaid metni değil. Her kenar gerçek kod grafiğine karşı çapraz kontrol edilir ve grafiğin doğrulayamadığı bir kenar, gerçek olarak çizilmek yerine doğrulanmamış olarak işaretlenir.

API sözleşmesi ekseni

Sözleşme ekseni yalnızca açıkça belirtilmiş spesifikasyon dosyalarının diff’ini alır. Altı varsayılan adı — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — ve adında openapi ya da swagger geçip .yaml, .yml veya .json ile biten değişmiş dosyaları eşleştirir. Handler kodundan çıkarılan bir sözleşme kapsam dışıdır ve GraphQL şemalarının diff’i alınmaz.

Her değişiklik sınıflandırılır — endpoint, parametre, şema ve yanıt eklemeleri, kaldırmaları ve değişiklikleri — ve bir önem derecesi taşır: breaking (kaldırılan endpoint ya da parametre, sıkılaştırılmış tür, yeni zorunlu parametre), non-breaking (eklemeli) ya da bilgilendirici. Reddedilen bir değişiklik sözleşme kapısında başarısız olur; karara bağlanmadan bırakılan bir breaking değişiklik de öyle. Breaking olup onaylanan uyarı verir; hiç breaking değişiklik yoksa kapı geçilir. Bir diff türetilmiş (tavsiye niteliğinde) olarak işaretlendiyse hiçbir zaman kapı oluşturmaz.

Bir değişikliği onaylamak ya da reddetmek review_studio.setContractDecision işlemidir.

Görsel eksen

PR, Widgetbook uygulaması olan bir Flutter deposunda UI bileşenlerini değiştiriyorsa, hesaplama geçişi değişen bileşenleri PR’ın base ve head çalışma ağaçlarında headless bir flutter test golden geçişiyle öncesi ve sonrası olarak render eder, ardından piksellerin diff’ini alır.

changed ya da removed olarak işaretlenen anlık görüntüler onaylanana kadar görsel kapıyı tutar; unchanged, added ve approved anlık görüntüler kapıyı açar. Kullanılamamanın dört nedeni vardır: sunucu ana makinesinde Flutter SDK olmaması, depoda Widgetbook uygulaması olmaması, golden ile test edilebilir kullanım senaryosu olmaması ya da bir golden harness hatası.

Amaçlanan bir değişikliği onaylamak review_studio.approveVisual işlemidir.

Eksenler ve karar

Eksen	Yönlendiren
Doğruluk	İnceleyici ajanlar (token)
Güvenlik	İnceleyici ajanlar (token)
Test açığı	İnceleyici ajanlar (token)
Görsel	Deterministik (golden harness)
API sözleşmesi	Deterministik (spesifikasyon diff’i)

Üç token ekseni, bir lider ajan finalize_review çağırdığında kaydedilir; iki deterministik ekseni ise hesaplama geçişi kaydeder.

Her eksen şunlardan birini bildirir:

Durum	Anlamı
Pass	Çalıştı, engelleyici bir şey bulunmadı
Warn	Çalıştı, engelleyici olmayan kaygılar var
Fail	Çalıştı, engelleyici bir sorun buldu
Partial	Çalıştı ama tamamlanamadı; sonuçlar eksik
Unavailable	Hiç çalışamadı

Kapıya bağlı bir ekseni yalnızca pass ve warn açar. Partial ve unavailable bilinçli olarak fail’den ayrıdır ve ikisi de bir kapıyı açmaz.

Eksenler Ship, Hold ya da Block kararına dönüşür ve kararı yalnızca daha ağır yapabilirler — asla hafifletilmez. Kapıya bağlı bir eksen başarısız olduğunda Block’u zorlar; partial ya da unavailable olan bir eksen en azından Hold’u zorlar. Yani çalışamayan engelleyici bir eksen kararı askıda tutar: kanıt yokluğu asla yeşil bir kapıya dönüşmez.

İncele sekmesindeki karar, finalize_review işleminin yayınladığı karardır.