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.
Bir YZ incelemesi başlatın
Bölüm başlığı “Bir YZ incelemesi başlatın”- PR’ı açın ve Genel bakış sekmesine gidin
- 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:
- 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
- Ç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
- Lider (CEO) ajana bulgularını bir rehberli anlatımda birleştirtir
- Sonlandırır: bulguları uzlaşma gruplarına ayırır ve kararı hesaplar.
İlişkilendirme
awaiting approvaldurumuna 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.
Bulguları okuyun
Bölüm başlığı “Bulguları okuyun”İ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.
Anlaşmazlıklar panelini kontrol edin
Bölüm başlığı “Anlaşmazlıklar panelini kontrol edin”İ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.
Kararı okuyun
Bölüm başlığı “Kararı okuyun”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.
İncelemeyi GitHub’a yayınlayın
Bölüm başlığı “İncelemeyi GitHub’a yayınlayın”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.
- İncele sekmesinde GitHub’a yayınla görünene kadar bekleyin
- 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.
İnceleyicileri kendiniz gönderin
Bölüm başlığı “İnceleyicileri kendiniz gönderin”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.
İlgili kılavuzlar
Bölüm başlığı “İlgili kılavuzlar”- Bir PR’ı inceleme ve birleştirme
- İnceleyici ajanları gönderme
- İnceleme hesaplaması (kohortlar ve eksenler)