Twitter örneğini takip edin
Bu kılavuz, Panolayer'in Twitter örneğindeki gönderi silme hatasını ele alır. Sorunu okuyacak, açıklamasını kodda takip edecek ve birleştirip birleştirmeyeceğinize karar vermeden önce doğrulama özetini anlayacaksınız.
Takip etmek için Örnek bir uygulamayı deneyin altındaki Twitter Clone'u açın. twitter-starter olarak açılır. Kurulumun ve düzeltmenin tam anlatımı için Panolayer ile ilk hatanızı düzeltin bölümüne bakın. Ekran görüntüleri kaydedilmiş tek bir çalıştırmayı gösterir; sorun sıranız ve sayılarınız farklı olabilir.
Sorunlar ile başlayın
Bir kod tabanı açtığınızda, Panolayer verification engine çalışmaya başlar. Kod tabanını işlevlerine, sembollerine ve bağımlılıklarına kadar ayrıştırır, görsel mimariyi oluşturur ve hataları belirlemek için kodu denetler.
Sorunlar'ı açın. Bu örnekte çalışma tamamlanmıştır ve durum Doğrulama tamamlandı olarak görünür. İncelenmesi gereken sorunlar Dikkat gerekiyor altında görünür.
Doğrulama tamamlandı ifadesi çalışmayı tanımlar. Çalışmanın bittiği anlamına gelir; hata bulup bulmadığını görmek için sonuçları okuyun.
Silme sorununu okuyun
Örneğin ilk sorunu, bir koşulun onaylanmış bir silme işlemini durdurabileceğini bildirir:
Ek
canDeletekoruması, belirtilen mevcut gönderi silme davranışının aksine, kullanıcı onayına rağmen silmeyi engelleyebilir.
Bir kural, bir fonksiyonun davranışına ilişkin bir beklentidir: ne döndürmesi gerektiği, hangi eylemi gerçekleştirmesi gerektiği veya diğer kodun ondan ne beklemesi gerektiği. Burada beklenti, kullanıcı onayladıktan sonra mevcut gönderinin silinmesiyle ilgilidir.
Sorunun dosyasını, fonksiyonunu, durumunu ve açıklamasını birlikte okuyun:
| Ne görürsünüz | Size ne anlatır |
|---|---|
components/Post.tsx | İncelenecek fonksiyonu içeren dosya. |
handleDelete() | Davranışı kontrol edilen fonksiyon. |
| Başarısız | Kontrol edilen davranış kuralı karşılamadı. |
| Önem 3 · İşlevsellik | Sorunun önem derecesi ve kategorisi, incelemeye öncelik vermenize yardımcı olur. |
| Ayrıntılar | Açıklama ve kaynak konumu, sorunun neden bildirildiğini anlamanıza yardımcı olur. |
Ayrıntılar'a tıklayın. Açıklama, fonksiyonun canDelete false olduğunda, kural tarafından tanımlanan silme işlemini tamamlamadan erken dönebileceğini söyler. Kaynak referansı ilgili koda işaret eder.
Ne değiştireceğinize karar vermeden önce kuralın amaçlanan davranışla eşleştiğini kontrol edin. Beklenti yanlışsa kuralı düzeltin. Kod yanlışsa kodu düzeltin. Bir değişiklik diğer dosyalardaki çağıranları da etkileyebilir; bu nedenle sonuçta gösterilen etkilenen çağıranları izleyin.
Durumlar ne anlama gelir?
Durumu, açıklaması ve uygulandığı kodla birlikte okuyun.
| Sonuç | Nasıl okunur |
|---|---|
| Geçti | Değerlendirilen kural, denetlenen kod için geçti. Bu, uygulamanın olası tüm davranışlarını değil, söz konusu kuralı açıklar. |
| Başarısız | Değerlendirilen kural sağlanmadı. Açıklamayı okuyun ve neyin düzeltilmesi gerektiğine karar vermek için kaynağı inceleyin. |
| Beklemede veya çalışıyor | Sonuç hazır değil. Bir sonuca varmadan önce kontrolün tamamlanmasını bekleyin. |
| Kullanılamıyor | Kontrol tamamlanamadı. Eşlik eden iletiyi okuyun ve yeniden kontrol etmeden önce bildirilen sorunu çözün. |
| Denetlenmedi | Beklenti değerlendirilmedi. Bu, geçen bir sonuç değildir. |
Doğrulama tamamlanamazsa bildirilen hatayı izleyin ve Kurulum ve ajan sorunlarını çözme bölümüne bakın.
Hatayı düzeltin ve doğrulamayı yeniden çalıştırın
Silme sorununda Düzelt'e tıklayın, ardından Panolayer Agent'ı seçin. Panolayer sorun bağlamını ajana iletir; bu nedenle hatayı açıklayan bir istem yazmanız gerekmez.
Panolayer Agent yerleşiktir. Desteklenen başka bir ajanı da yükledikten sonra kullanabilirsiniz; bkz. Desteklenen ajanlar.
Ajan kendi Git worktree'sinde çalışır ve düzenlemelerini dalınızdan ayrı tutar. Görevi Ajanlarım bölümünde takip edin veya etkinliğini ve değişikliklerini incelemek için çalıştırma kartındaki Aç'a tıklayın.
Kod değiştikçe Panolayer etkilenen işlevleri ve bağlantılı kodu, diğer dosyalardaki çağıranlar dahil olmak üzere yeniden denetler. Bu, ajanın düzenlediği satırların ötesindeki regresyonların yakalanmasına yardımcı olur.
Regresyon, değişiklikle ortaya çıkan yeni bir sorundur. Doğrulama bir düzeltme sırasında regresyon yakalarsa ajan bunu onarabilir ve birleştirme istemeden önce doğrulamayı yeniden çalıştırabilir. Bu nedenle bir görev, incelemeniz için hazır olmadan önce birkaç doğrulama çalıştırmasına sahip olabilir.
Birleştirmeden önce doğrulama özetini okuyun
Bu çalıştırma tamamlandığında Panolayer Panolayer Agent birleştirmeye hazır gösterir. İletişim kutusu, görev sırasında doğrulamanın neleri denetlediğini ve onardığını özetler.
| Özet alanı | Bu çalıştırma | Ne anlama gelir |
|---|---|---|
| Onarılan hatalar | 1 | Çalışma, görev başlamadan önce zaten var olan bir hatayı onardı. |
| Geçen kurallar | 21'den 14 | Değiştirilen kodda 21 kuraldan on dördü geçti. Bunu sağlık iletisiyle ve ayrı önceden var olan hatalar satırıyla birlikte okuyun. |
| Doğrulama çalıştırmaları | 1 | Bu çalışma sırasında bir doğrulama çalıştırması bir sonuca ulaştı. Bu, tek tek testleri veya kuralları değil, doğrulama çalıştırmalarını sayar. |
| Değişen dosyalar | 4 | Görev dört dosyayı değiştirdi. Testler ve bağımlılık dosyaları dahil olmak üzere tam değişiklik kümesini inceleyin. |
Sağlık iletisi Yeni hata, uyarı veya denetlenmemiş kural yok. diyor. Bu iletiyi sayılarla birlikte okuyun: bu çalışmanın sonucunu açıklar, sonraki satır ise başlamadan önce kalan hataları açıklar.
“Regresyonlar yakalandı” görünürse ne olur?
Bazı çalıştırmalar ayrıca Regresyonlar yakalandı gösterir. Çalışma sırasında doğrulamanın algıladığı yeni sorunları bildirir ve bunların hedef daldan uzak tutulmasına yardımcı olur. Neyin hâlâ ilgi gerektirdiğini görmek için en son sonucu okuyun; sayı, şu anda çözülmemiş hataların sayısını değil, çalışma sırasındaki yakalamaları açıklar.
Bu alan bu ekran görüntüsünde gösterilmez. Silme örneği, onarılmış bir önceden var olan hatayı gösterir; düzeltme sırasında yakalanan bir regresyonu göstermez.
Why can it be ready to merge when failures remain?
Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.
- A new failure was introduced by the change and needs investigation before you accept the work.
- A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
- A repaired failure was present before the task and was fixed during the work.
In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.
The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.
You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.
Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.
Decide what reaches your branch
You control the merge. Before accepting the result:
- Check that the repaired issue matches the bug you asked the agent to fix.
- Read the verification summary, including any new failures, warnings, or checks that could not finish.
- Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
- Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.
Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.