İçeriğe geç

YZ destekli inceleme kullanma

Bu kılavuz, inceleyici ajanların bir pull request’i nasıl inceleyeceğini ve sonucu GitHub’a nasıl yayınlayacağınızı gösterir.

  1. PR’ı açın ve Genel bakış sekmesine gidin
  2. Eylem satırındaki ⋯ taşma menüsünü açın ve AI’ya sor seçeneğini seçin

Bu öğe yalnızca PR açıkken görünür — bu, birleştirme öncesi bir eylemdir. Aynı düğme, henüz hiçbir inceleme yokken İncele sekmesinin boş durumunda da AI’ya sor olarak sunulur.

Control Center, yerleşik pr_review pipeline’ını başlatır ve izleyebilmeniz için PR’ın İncele sekmesini açar. Pipeline şunları yapar:

  1. PR’ın kendi inceleme alanını açar; bu alanın yalıtılmış çalışma ağacında PR, head’inde checkout edilmiş olarak durur
  2. Çalışma alanının inceleme düzeyine göre inceleyicileri dağıtır — varsayılan olarak üç (yerleşik qa, architect ve engineer ajanları, paralel olarak). Dil veya alan tespiti yoktur
  3. Lider (CEO) ajana bulgularını bir rehberli anlatımda birleştirtir
  4. Sonlandırır: bulguları uzlaşma gruplarına ayırır ve kararı hesaplar. İlişkilendirme awaiting approval durumuna ulaştığında, İncele sekmesinde GitHub’a yayınla görünür

İncelemenin ne kadar derine gideceği çalışma alanının inceleme düzeyidir — light (tek inceleyici), balanced (üç, varsayılan) veya thorough (beşin tamamı, güvenlik ve performans uzmanlarını da ekler) — ve Ayarlar → Çalışma alanı → Genel altındaki Çalışma alanı ilkesi kartında ayarlanır. Daha hafif bir düzey de tam olarak aynı sayıda bulgu kaydeder; bunların daha azını ön planda raporlar.

Tüm inceleyiciler PR’ın tek inceleme alanına yazar; bulgularını karşılaştırılabilir kılan da budur. Parçaların birbirine nasıl oturduğunu YZ incelemesi sayfasında görebilirsiniz.

pr_review yalnızca elle tetikleme ile gelir. Yayınlanan her PR’da çalışmasını istiyorsanız kendiniz bir tetikleyici ekleyin — bkz. İnceleyici ajanları gönderme. GitHub’ın kendisinden de başlatabilirsiniz; pipeline tetikleyicisi gerekmez: PR’da sunucunun botundan bahsedin veya ai-review etiketini ekleyin — bkz. Bir GitHub PR’ından Control Center ile konuşma.

Bir bildirim, bu pull request için zaten bir incelemenin çalıştığını söylüyorsa bir inceleme çoktan yoldadır; onu bulmak için İncele sekmesinde kalın veya Pipelines’ı açın.

İnceleyiciler bulguları inceleme alanına inceleme düğümleri olarak kaydeder. Her biri şunları taşır:

Alan Açıklama
Tür bug, suggestion, recommendation, question veya ticket
Öncelik P0 (kritik) → P3 (ince ayrıntı)
Kategori security, stability, data_integrity, correctness, performance veya maintainability
Dosya ve satır Bulgunun çapalandığı yer
Özgün kod Bulgunun konusu olan kod
Önerilen kod Önerilen düzeltme
Güven İnceleyicinin ne kadar emin olduğu
Durum open → consensus-ready → resolved veya dismissed

Bir bulgu, ancak bir akran inceleyici onayladığında consensus-ready durumuna ulaşır. Bir ajan kendi bulgusunu onaylayamaz; bu yüzden tek bir inceleyicinin görüşü kendi başına asla olgunlaşmaz.

İncele sekmesi, bulgular listesini tür ve duruma göre filtrelenebilir biçimde, yoksayılan bulgular için bir anahtarla birlikte, birleştiren ajanın yayınladığı yapıtın yanında gösterir. Deterministik görünüm — kohortlar, çok eksenli pano, sözleşme ve görsel diff’ler — sunucu tarafında hesaplanır ancak uygulamada bir yüzeyi yoktur; geçişin neler ürettiğini İnceleme hesaplaması sayfasında görebilirsiniz.

İki inceleyici bulguları aynı dosyaya ve satıra çapalayıp bunları çok farklı derecelendirdiğinde — öncelikler arasında iki veya daha fazla düzey fark olduğunda ya da biri buna bug derken diğeri suggestion dediğinde — bulgular listesinin üzerinde bir anlaşmazlık paneli görünür. Önce bunları okuyun: inceleyicilerin görüşlerinin ayrıldığı ve sizin yargınızın en değerli olduğu yer burasıdır.

Lider ajan sonlandırdığında bir karar hesaplar:

Karar Anlamı
Ship Engelleyici hiçbir şey bulunmadı
Hold Birleştirmeden önce ele alınması gereken sorunlar
Block Düzeltilmesi gereken kritik sorunlar

Karar, toplu bir güven puanı ve öncelik başına bulgu sayıları taşır.

Ardından inceleme eksenleri buna katılır ve kararı yalnızca daha ağır hâle getirebilirler. Kapıya bağlı bir eksen başarısız olursa Block’u zorlar; kapıya bağlı bir eksen tamamlanamazsa (partial) ya da hiç çalışamazsa (unavailable) en azından Hold’u zorlar. Kanıt yokluğu hiçbir kapıyı asla geçirmez.

Yayınlama ayrı ve bilinçli olarak kullanıcı kapısına bağlanmış bir adımdır. pr_review pipeline’ı incelemeyi Control Center’da tutar; GitHub’a göndermez.

  1. İncele sekmesinde GitHub’a yayınla görünene kadar bekleyin
  2. GitHub’a yayınla düğmesine basın

Control Center tek bir GitHub incelemesi gönderir. Zaten çözülmüş veya yoksayılmış bulgular atlanır. Düğme, kalan tüm açık bulguları içerir ve Ship durumunda APPROVE gönderir. (MCP aracı publish_review_to_github yine de varsayılan olarak yalnızca akran onaylı bulguları alır ve approve_on_ship vermediğiniz sürece onaylamaz.) Dosya ve satır çapası taşıyanlar satır içi yoruma dönüşür; geri kalan her şey, kaynağın belirsiz olmaması için her biri bir “— Control Center AI review” altbilgisiyle özet gövdesine katılır. Block kararı REQUEST_CHANGES olarak; Hold COMMENT olarak; Ship ise bu düğmeden APPROVE olarak gönderilir. Ardından bir bildirim Yayınlandı yazar. İnceleme, sunucunun uygulama kimliği altında yayınlanır.

GitHub bir satır içi çapayı, satır diff’in parçası olmadığı için reddederse, tüm inceleme her bulgu gövdeye katılarak yeniden gönderilir; böylece hiçbir şey sessizce düşürülmez.

Diğer yerleşik pipeline’lar doğrudan GitHub’a gönderir: cross_review, pr_triage, ticket_to_pr ve pre_merge_gate her biri bir yorum adımıyla biter. Yalnızca pr_review çıktısını sizin için geride tutar.

PR’ı hangi rollerin inceleyeceği ve her birinin hangi dosyalara bakacağı üzerinde kontrol sahibi olmak için, mevcut bir inceleme alanında dispatch_reviewers MCP aracını kullanın veya bir pipeline’a inceleyici düğümleri ekleyin. Aracın tam imzasıyla birlikte her iki yol da İnceleyici ajanları gönderme sayfasındadır.