YZ incelemesi

Bir incelemenin biçimi

YZ incelemesi, açık bir pull request’e karşı yerleşik pr_review pipeline’ının tek bir çalıştırmasıdır. Pipeline PR’ın inceleme alanını açar, inceleyici ajanları o alanın yalıtılmış checkout’unda diff’i okumak üzere dağıtır, her biri bulgularını yapılandırılmış inceleme düğümleri olarak kaydeder, bir lider ajan bunları bir rehberli anlatımda birleştirir ve bir sonlandırıcı tek bir karar hesaplar: Ship, Hold veya Block. Pipeline’ın hiçbir zaman yapmadığı şey yayınlamaktır — GitHub’a göndermek, bir insanın attığı ayrı ve bilinçli bir adımdır.

Sayfanın geri kalanı parçaları ve neden bu biçimde olduklarını açıklar.

PR başına tek inceleme alanı

Bir PR’ın inceleme bağlamı bir mesajlaşma alanıdır — mod review, tür pr — ve pull request’e bir inceleme alanı ilişkilendirmesi ile bağlanır. İdempotent biçimde oluşturulur: PR sayfası, inceleme pipeline’ı ve sohbet yüzeyleri PR’ın tek arka plan alanını aynı kod yolundan çözer; böylece bir PR’ı inceleyen bir şablon ile onu açan bir insan, iki farklı odada iki farklı checkout’a bakacak şekilde sonuçlanamaz.

Alanın yalıtılmış çalışma ağacında PR, head ref’inde checkout edilmiş olarak durur. Tek oda aynı zamanda tek checkout demektir: her inceleyici, çalışma alanının kendi kopyasını almak yerine aynı alanda çalışır.

Her inceleyici, o tek alanın içindeki kendi adlı akışına yazar; bulgular düz metin yerine review_node mesajlarıdır. Sondaki alan geneli toplama bilinçlidir — tek bir iş parçacığının bulgularından hesaplanan bir karar, sessizce tek bir inceleyici hakkında bir karar olurdu.

İlişkilendirme bir durum merdiveni taşır — requested → in progress → awaiting approval → completed — PR’ın İnceleme sekmesinde GitHub’a yayınla düğmesini kapıya bağlayan şey bu merdivendir.

İnceleme düzeyleri

Bir incelemenin ne kadar derine gideceği, Ayarlar → Çalışma alanı → Genel altındaki Çalışma alanı ilkesi kartında ayarlanan, üç düzeyli bir çalışma alanı ilkesidir:

Düzey	Dağıtılan inceleyiciler	Raporlama
light	Yalnızca mühendis	Yalnızca maddi olarak önemli olanlar
balanced	Mühendis, QA, mimar (varsayılan)	Olağan geçiş
thorough	Güvenlik ve performans dahil beşinin tamamı	Hiçbiri alt sıraya düşürülmez

Düzey aynı anda iki ayarı oynatır: hangi inceleyicilerin dağıtılacağı — bu, prompt ifadesiyle değil pipeline şablonunun runWhen durum kapılarıyla zorlanır; prompt ifadesi yok sayılabilir, bir kapı sayılamaz — ve eşik altı bulguların nerede işleneceği. Hiçbir ayar bir bulguyu asla silmez: daha azını raporlayan bir düzey yine tam olarak aynı miktarı kaydeder ve kalanları gruplar.

Güvenlik ve performans geçişleri, yeni ajanlar devreye sokmak yerine yerleşik mimar ve mühendis ajanlarını yeniden kullanır. Uzmanlık, inceleyicinin gönderilirken aldığı brifingdir; eksen başına ayrı bir ajan değildir — eksen başına bir ajan, her çalışma alanında ek yetenek sağlamadan beş satır daha demek olurdu. İnceleyici seçimi diff’e hiçbir zaman dil veya alan için bakmaz.

İnceleme düğümleri: bulgular düz metin değil, veri

add_review_node ile kaydedilen bir bulgu, PR üzerinde bir inceleme düğümü olur — İnceleme sekmesinin görüntülediği, kararın hesaplandığı ve “GitHub’a yayınla”nın satır içi yoruma dönüştürdüğü şey budur. Yalnızca düz metin döndüren bir inceleyici, başarılı görünen bir pipeline çalıştırması ve boş bir inceleme yüzeyi üretir; yükü taşıyan kısım kaydetmektir.

Her düğüm şunları taşır:

Alan	Değerler
Tür	bug, suggestion, recommendation, question, ticket
Öncelik	P0 (kritik) → P3 (ince ayrıntı)
Triyaj üçlüsü	kategori (security, stability, …), önem derecesi, efor
Çapa	Dosya yolu, satır başlangıcı ve bitişi
Düzeltme taşıma	Önerilen değiştirme satırları, isteğe bağlı bir diff, isteğe bağlı bir düzeltme prompt’u
Güven	[0, 1] arası bir puan
Gerekçe	Bulgudan önce yazılan analiz

İki ayrıntı bilinçli birer tercihtir. Tek tıkla GitHub önerisi yalnızca inceleyici tam değiştirme satırlarını verdiyse sunulur — bunları birleşik bir diff’ten çıkarsamak sessizce yanlış sonuç verir ve yanlış bir çıkarımın tek tıkla commit edilmesi, hiç düğme olmamasından kötüdür. Ayrıca add_review_node şeması reasoning alanını bulgudan önce sunar; böylece nesneyi şema sırasına göre dolduran bir model analizi önce yazar. Alan isteğe bağlıdır: atlanması düğümü reddettirmez. Yükü bozuk olan bir düğüm, incelemeyi kirletmek yerine kaybolur.

Akran uzlaşması

Bir düğüm open → consensus-ready → resolved ya da dismissed durumlarından geçer. Ortadaki adım modelin kalbidir: bir bulgu ancak bir akran inceleyici onayladığında olgunlaşır ve bir ajan kendi bulgusunu asla onaylayamaz. MCP aracı publish_review_to_github ve RPC varsayılanı hâlâ yalnızca akran onaylı bulguları yayınlar. İnceleme sekmesindeki GitHub’a yayınla düğmesi ise kalan tüm açık bulguları gönderir.

Kural üç bağımsız yerde zorlanır — onaylama aracı, sonlandırıcı ve yayınlayıcı — böylece bunlardan herhangi birindeki hatalı bir çağıran durumunda da ayakta kalır. Durum değişikliklerinin tümü tek bir servisten geçer; bir durumun bir anlam taşımasını sağlayan da budur: ondan önce iki yarım yol, aynı bulgunun çözülüp çözülmediği konusunda anlaşamayabiliyordu.

İnceleyiciler anlaşamadığında — aynı dosya ve satır, iki ya da daha fazla düzey ayrı öncelikler veya biri ona bug derken diğerinin suggestion demesi — bu anlaşmazlık bulgular listesinin üstünde gösterilir. İnceleyicilerin görüşlerinin ayrıldığı ve bir insanın muhakemesinin en değerli olduğu yer orasıdır.

Bir bulguyu yok saymak ayrıca bellek alanına düşük güvenle yumuşak bir bastırma olgusu yazar — tek bir yok sayma bir kural değil, bir tercihtir.

Kohortlar: incelemenin etrafında gruplandığı şey

İnceleme hesaplama geçişi, bir PR’ın değişen dosyalarını kod grafiğinden türetilen kohortlar hâlinde gruplar: değişen dosyalar dokundukları sembollere, semboller bağlantılı bileşenlere eşlenir ve kohortlar etki alanına göre sıralanır. Bir kohort, düz bir dosya listesi olmak yerine rehberli bir okuma sırası, diyagramlar ve içgörüler taşır.

Bunu iki dürüstlük kuralı biçimlendirir. Kohort anahtarları içerikten türetilir ve push’lar arasında kararlıdır; böylece bulgular ve inceleme ilerlemesi bir rebase veya force-push’ta sahipsiz kalmak yerine ayakta kalır. Depoda kod dizini yoksa gruplama düz yollara geri düşer ve bunu söyler — geri düşüş hiçbir zaman anlamsal bir güven taklit etmez.

İnceleme eksenleri ve kapılar

İnceleyicilerin bulgularının yanı sıra bir incelemede eksen sonuçları birikir: iki türden altı eksen.

Eksen	Tür	Kaynağı
correctness, security	Token güdümlü	İnceleyicilerin kendi bulguları
testGap	Token güdümlü	İnceleyicilerin bulguları
visual, apiContract	Deterministik	Token harcamadan hesaplanır
performance	Deterministik	Yalnızca enum — üründe hiçbir şey bir sonuç hesaplamaz

Bir eksen kararı pass, warn, fail, partial ya da unavailable olur — ve bir kapıyı yalnızca pass veya warn açar. fail, partial ve unavailable arasındaki ayrım yük taşır: tamamlanamayan ya da hiç çalışamayan kapıya bağlı bir eksen, genel kararı geçirmek yerine askıda tutar. Kanıt yokluğu asla yeşil bir kapıya dönüşmez.

Bazı eksenler bilerek tavsiye niteliğindedir. Kohortlardan türetilen test açığı ekseni, bağımlılık enjeksiyonu veya fabrika kapsamını göremez — kapsamlı bir test paketine sahip dizinlenmemiş bir depo ile hiç testi olmayan bir depo oradan bakıldığında aynı görünür, dolayısıyla ikisinden birini iddia etmek yalan olurdu; bu eksen kapıya bağlanmadan gösterge panelinde görünür. Token eksenleri tavsiye niteliğindedir çünkü kararı zaten bulgu öncelikleri yönlendirir ve bunlarla yeniden kapı kurmak çift sayım olurdu.

Karar

Sonlandırıcı, kararı durumu open veya consensus-ready olan bulgular üzerinden hesaplar:

• güveni ≥ 0.7 olan herhangi bir P0 bulgusu → Block
• aksi halde, herhangi bir P0 (düşük güvenli) veya herhangi bir P1 → Hold
• aksi halde → Ship

Karar, katkıda bulunan güvenlerin yayılımından türetilen bir toplam güven taşır — anlaşma onu yükseltir, ayrışma düşürür.

Lider (CEO) ajanın birleştirmesi editoryal bir geçiştir, bulguların yeniden listelenmesi değil: elle yazılmış ikinci bir bulgu kopyası, gerçeğinden tam da sapacak olan şeydir. Yinelenen bulgular tekrarlanmak yerine alt sıraya düşürülür — birkaç inceleyici, bilinçli olarak örtüşen görev alanlarıyla tek bir diff’e yönlendirilir; dolayısıyla aynı kusurun sonlandırıcıya üç kez ulaşması sistemin çalıştığını, onu üç kez yayınlamak ise sistemin kendi mimarisini okuyucunun gelen kutusuna sızdırdığını gösterir. Yeniden incelemede bulguların parmak izi alınır ve önceki turla diff’i çıkarılır; yüzeye çıkan şey farktır.

Son olarak eksenler devreye girer ve kararı yalnızca daha ağır yapabilirler: kapıya bağlı ve başarısız bir eksen Block’u zorlar — bulgular onu oyla geçemez — ve tamamlanamayan kapıya bağlı bir eksen en azından Hold’u zorlar.

Yayınlama sizde kalır

Pipeline bilinçli olarak GitHub’a göndermez; yayınlama kullanıcı kapısına bağlıdır, böylece bir inceleme asla iki kez yayınlanamaz. GitHub’a yayınla düğmesine bastığınızda:

• Tek bir GitHub incelemesi gönderilir. Zaten çözülmüş veya yok sayılmış bulgular atlanır. Düğme, kalan tüm açık bulguları yayınlar (selection: all_open). MCP aracı publish_review_to_github ise varsayılan olarak hâlâ yalnızca akran onaylı bulguları kullanır (consensus).
• Bir dosyaya ve satıra çapalanmış bulgular satır içi yorumlara dönüşür; geri kalan her şey özet gövdesine katlanır ve her biri, kaynağın belirsiz kalmaması için bir “— Control Center AI review” alt bilgisi taşır.
• Çapalar, yayınlama anında PR’ın güncel diff’ine karşı yeniden doğrulanır. Zaten yeniden yazılmış kod üzerine bırakılan bir yorum, bir inceleyicinin bırakabileceği en güven yıkıcı şeydir; GitHub satır içi bir çapayı yine de reddederse, hiçbir şey sessizce düşmesin diye tüm inceleme, her bulgu gövdeye katlanarak yeniden gönderilir.
• Block kararı REQUEST_CHANGES; Hold COMMENT; Ship ise düğmeden APPROVE olarak gönderilir (approve_on_ship: true). MCP aracı, siz approve_on_ship vermediğiniz sürece Ship’i COMMENT olarak bırakır.
• İnceleme, sunucunun uygulama kimliği altında yayınlanır. Yayınla’ya kimin bastığı rol kapısı ve denetim günlüğü için kaydedilir; GitHub yazarı o değildir.

Yayınlama, prPublish eylem sınıfını bildirir; bu yüzden koruma darboğazı onu diğer tüm değiştirici eylemler gibi kapıya bağlar — varsayılan olarak sorar ve bağlı bir onaylayıcı yoksa kapalı yönde başarısız olur. Bkz. Korumalar.

İnceleyici neler yapabilir

İnceleyici ajanlar review modunda çalışır: salt okunur bir sandbox ve bulguları, yorumları, biletleri ve akran incelemesini kapsayan, özenle seçilmiş bir araç izin listesi — ama mutasyon yok. Bir inceleyici, eleştirdiği kodu düzeltemez; bir insanın uygulayacağı önerilen bir düzeltmeyi iliştirebilir. Modun ret mesajı, yine de eylemde bulunmaya çalışan bir ajana incelemeyi sonlandırmasını ve kullanıcının yayınlanan özet üzerinden hareket etmesini söyler.

İlgili kavramlar

• Korumalar — yayınlamayı kapıya bağlayan ilke motoru
• Modlar — review modunun bir ajan için değiştirdiği şeyler
• Pipeline’lar ve otomasyon — incelemenin üzerinde çalıştığı motor
• Ajan gönderim yaşam döngüsü — yalıtılmış çalışma ağacının nereden geldiği

İlgili kılavuzlar

• YZ destekli inceleme kullanma — bir inceleme çalıştırın ve yayınlayın
• İnceleyici ajanları gönderme — inceleyicileri kendiniz seçin
• İnceleme hesaplaması — kohortlar, eksenler ve diff’ler