Prześledź przykład Twitter
Ten przewodnik omawia błąd usuwania postów w przykładzie Twitter w Panolayer. Przeczytasz zgłoszenie, prześledzisz jego wyjaśnienie aż do kodu i zrozumiesz podsumowanie weryfikacji, zanim zdecydujesz, czy scalić zmiany.
Aby śledzić przewodnik, otwórz Twitter Clone w sekcji Wypróbuj przykładową aplikację. Otwiera się jako twitter-starter. Pełny opis konfiguracji i naprawy znajdziesz w Napraw swój pierwszy błąd z Panolayer. Zrzuty ekranu pokazują jeden zarejestrowany przebieg; kolejność i liczba zgłoszeń mogą się różnić.
Zacznij od sekcji Problemy
Po otwarciu bazy kodu Panolayer verification engine uruchamia się. Analizuje bazę kodu aż do poziomu funkcji, symboli i zależności, buduje wizualną architekturę i sprawdza kod pod kątem błędów.
Otwórz Problemy. W tym przykładzie przebieg się zakończył, a status wskazuje Weryfikacja zakończona. Problemy wymagające zbadania pojawiają się w sekcji Wymaga uwagi.
Weryfikacja zakończona opisuje przebieg. Oznacza, że przebieg się zakończył; przeczytaj wyniki, aby sprawdzić, czy wykryto niepowodzenia.
Przeczytaj problem dotyczący usuwania
Pierwszy problem w przykładzie informuje, że warunek może zablokować potwierdzone usunięcie:
Dodatkowy warunek ochronny
canDeletemoże uniemożliwić usunięcie mimo potwierdzenia przez użytkownika, wbrew opisanemu zachowaniu usuwania bieżącego posta.
Reguła to oczekiwanie dotyczące zachowania funkcji: co powinna zwracać, jakie działanie powinna wykonywać lub czego oczekuje od niej inny kod. Tutaj oczekiwanie dotyczy usunięcia bieżącego posta po potwierdzeniu przez użytkownika.
Przeczytaj łącznie plik, funkcję, status i wyjaśnienie problemu:
| Co widzisz | Co to oznacza |
|---|---|
components/Post.tsx | Plik zawierający funkcję do zbadania. |
handleDelete() | Funkcja, której zachowanie sprawdzono. |
| Niepowodzenie | Sprawdzone zachowanie nie spełniło reguły. |
| Ważność 3 · Funkcjonalność | Ważność i kategoria problemu pomagają ustalić priorytet badania. |
| Szczegóły | Wyjaśnienie i lokalizacja źródła pomagają zrozumieć, dlaczego zgłoszono problem. |
Kliknij Szczegóły. Wyjaśnienie mówi, że funkcja może zakończyć się wcześniej, gdy canDelete ma wartość false, przed ukończeniem usunięcia opisanego przez regułę. Odwołanie do źródła wskazuje odpowiedni kod.
Sprawdź, czy reguła odpowiada zamierzonemu zachowaniu, zanim zdecydujesz, co zmienić. Jeśli oczekiwanie jest błędne, popraw regułę. Jeśli kod jest błędny, popraw kod. Zmiana może też wpłynąć na wywołujących w innych plikach, więc prześledź wywołujących, których dotyczy zmiana, pokazanych w wyniku.
Co oznaczają statusy?
Odczytuj status wraz z jego wyjaśnieniem i kodem, którego dotyczy.
| Wynik | Jak go odczytać |
|---|---|
| Zaliczone | Oceniana reguła została spełniona dla sprawdzonego kodu. Opisuje ona tę regułę, a nie każde możliwe zachowanie aplikacji. |
| Niepowodzenie | Oceniana reguła nie została spełniona. Przeczytaj wyjaśnienie i sprawdź kod źródłowy, aby ustalić, co wymaga poprawy. |
| Oczekuje lub trwa | Wynik nie jest gotowy. Poczekaj na zakończenie sprawdzenia, zanim wyciągniesz wniosek. |
| Niedostępne | Sprawdzenie nie mogło się zakończyć. Przeczytaj dołączony komunikat i rozwiąż zgłoszony problem przed ponownym sprawdzeniem. |
| Nie sprawdzono | Oczekiwanie nie zostało ocenione. To nie jest wynik zaliczony. |
Jeśli weryfikacja nie może się zakończyć, postępuj zgodnie ze zgłoszonym błędem i zobacz Rozwiązywanie problemów z konfiguracją i agentami.
Napraw błąd i pozwól weryfikacji uruchomić się ponownie
W przypadku problemu z usuwaniem kliknij Napraw, a następnie wybierz Panolayer Agent. Panolayer przekazuje kontekst problemu agentowi, więc nie musisz pisać promptu wyjaśniającego błąd.
Panolayer Agent jest wbudowany. Po zainstalowaniu możesz też użyć innego obsługiwanego agenta; zobacz Obsługiwani agenci.
Agent pracuje we własnym worktree Git, dzięki czemu jego zmiany są oddzielone od Twojej gałęzi. Śledź zadanie w Moi agenci lub kliknij Otwórz na karcie uruchomienia, aby sprawdzić jego aktywność i zmiany.
Gdy kod się zmienia, Panolayer ponownie sprawdza zmienione funkcje i powiązany kod, w tym wywołania w innych plikach. Pomaga to wychwycić regresje poza wierszami edytowanymi przez agenta.
Regresja to nowy problem wprowadzony przez zmianę. Jeśli weryfikacja wykryje ją podczas poprawki, agent może ją naprawić i ponownie uruchomić weryfikację przed zgłoszeniem scalenia. Zadanie może więc mieć kilka uruchomień weryfikacji, zanim będzie gotowe do Twojego przeglądu.
Przeczytaj podsumowanie weryfikacji przed scaleniem
Gdy ten przebieg się zakończy, Panolayer wyświetla Panolayer Agent jest gotowy do scalenia. Okno dialogowe podsumowuje, co weryfikacja sprawdziła i naprawiła podczas zadania.
| Pole podsumowania | Ten przebieg | Co to oznacza |
|---|---|---|
| Naprawione błędy | 1 | Praca naprawiła błąd, który istniał już przed rozpoczęciem zadania. |
| Zaliczone reguły | 14 z 21 | Czternaście z 21 reguł zostało zaliczonych w zmienionym kodzie. Czytaj to razem z komunikatem o stanie i osobnym wierszem wcześniej istniejących błędów. |
| Przebiegi weryfikacji | 1 | Jeden przebieg weryfikacji osiągnął wynik podczas tej pracy. Liczy przebiegi weryfikacji, a nie pojedyncze testy lub reguły. |
| Zmienione pliki | 4 | Zadanie zmieniło cztery pliki. Przejrzyj pełny zestaw zmian, w tym wszelkie testy i pliki zależności. |
Komunikat o stanie mówi: Brak nowych błędów, ostrzeżeń i niesprawdzonych reguł. Czytaj ten komunikat razem z liczbami: opisuje wynik tej pracy, a następny wiersz wyjaśnia błędy pozostałe sprzed jej rozpoczęcia.
Co jeśli pojawi się „Wykryte regresje”?
Niektoré przebiegi pokazują też Wykryte regresje. Raportuje nowe problemy wykryte przez weryfikację podczas pracy, pomagając nie dopuścić ich do gałęzi docelowej. Przeczytaj najnowszy wynik, aby zobaczyć, co nadal wymaga uwagi; licznik opisuje wykrycia podczas pracy, a nie liczbę obecnie nierozwiązanych błędów.
Tego pola nie ma na tym zrzucie ekranu. Przykład usuwania pokazuje jeden naprawiony wcześniej istniejący błąd; nie pokazuje regresji wykrytej podczas poprawki.
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.