Dem Twitter-Beispiel folgen
Diese Anleitung folgt dem Bug nach dem Löschen eines Beitrags im Twitter-Beispiel von Panolayer. Sie lesen das Issue, folgen der Erklärung zurück zum Code und verstehen die Verifikationszusammenfassung, bevor Sie entscheiden, ob Sie mergen.
Um mitzufolgen, öffnen Sie Twitter Clone unter Beispiel-App ausprobieren. Die App öffnet sich als twitter-starter. Die vollständige Einrichtung und den Durchlauf zur Fehlerbehebung finden Sie unter Beheben Sie Ihren ersten Bug mit Panolayer. Screenshots zeigen einen aufgezeichneten Lauf; Reihenfolge und Anzahl Ihrer Issues können abweichen.
In Issues beginnen
Wenn Sie eine Codebasis öffnen, beginnt die Panolayer-Verifikations-Engine mit der Ausführung. Sie parst die Codebasis bis hinunter zu ihren Funktionen, Symbolen und Abhängigkeiten, erstellt die visuelle Architektur und prüft den Code, um Bugs zu identifizieren.
Öffnen Sie Issues. In diesem Beispiel ist der Lauf abgeschlossen und der Status lautet Verifikation abgeschlossen. Issues, die untersucht werden müssen, erscheinen unter Erfordert Aufmerksamkeit.
Verifikation abgeschlossen beschreibt den Lauf. Das bedeutet, dass der Lauf abgeschlossen ist; lesen Sie die Ergebnisse, um zu sehen, ob Fehler gefunden wurden.
Das Issue zur Löschung lesen
Das erste Issue des Beispiels meldet, dass eine Bedingung eine bestätigte Löschung verhindern kann:
Der zusätzliche
canDelete-Guard kann die Löschung trotz Benutzerbestätigung verhindern, entgegen dem angegebenen Verhalten beim Löschen des aktuellen Beitrags.
Eine Regel ist eine Erwartung an das Verhalten einer Funktion: was sie zurückgeben soll, welche Aktion sie ausführen soll oder was anderer Code von ihr erwartet. Hier betrifft die Erwartung das Löschen des aktuellen Beitrags, nachdem der Benutzer bestätigt hat.
Datei, Funktion, Status und Erklärung des Issues gemeinsam betrachten:
| Was angezeigt wird | Was es bedeutet |
|---|---|
components/Post.tsx | Die Datei, die die zu untersuchende Funktion enthält. |
handleDelete() | Die Funktion, deren Verhalten geprüft wurde. |
| Fehlgeschlagen | Das geprüfte Verhalten erfüllte die Regel nicht. |
| Schweregrad 3 · Funktionalität | Schweregrad und Kategorie des Issues helfen bei der Priorisierung der Untersuchung. |
| Details | Erklärung und Quellcodeverweis helfen zu verstehen, warum das Issue gemeldet wurde. |
Auf Details klicken. Die Erklärung besagt, dass die Funktion vorzeitig zurückkehren kann, wenn canDelete false ist, bevor die von der Regel beschriebene Löschung abgeschlossen wird. Der Quellcodeverweis zeigt auf den relevanten Code.
Vor der Entscheidung, was geändert werden soll, prüfen, ob die Regel dem beabsichtigten Verhalten entspricht. Ist die Erwartung falsch, die Regel korrigieren. Ist der Code falsch, den Code korrigieren. Eine Änderung kann auch Aufrufer in anderen Dateien betreffen; daher allen betroffenen Aufrufern folgen, die im Ergebnis angezeigt werden.
Was bedeuten die Statusangaben?
Lesen Sie den Status zusammen mit seiner Erklärung und dem Code, auf den er sich bezieht.
| Ergebnis | So lesen Sie ihn |
|---|---|
| Bestanden | Die ausgewertete Regel wurde für den geprüften Code erfüllt. Dies beschreibt diese Regel und nicht jedes mögliche Verhalten der Anwendung. |
| Fehlgeschlagen | Die ausgewertete Regel wurde nicht erfüllt. Lesen Sie die Erklärung und prüfen Sie den Quellcode, um zu entscheiden, was behoben werden muss. |
| Ausstehend oder läuft | Das Ergebnis ist noch nicht bereit. Warten Sie, bis die Prüfung abgeschlossen ist, bevor Sie eine Schlussfolgerung ziehen. |
| Nicht verfügbar | Die Prüfung konnte nicht abgeschlossen werden. Lesen Sie die zugehörige Meldung und beheben Sie das gemeldete Problem, bevor Sie erneut prüfen. |
| Nicht geprüft | Die Erwartung wurde nicht ausgewertet. Das ist kein bestandenes Ergebnis. |
Wenn die Verifikation nicht abgeschlossen werden kann, folgen Sie dem gemeldeten Fehler und sehen Sie sich Setup- und Agent-Probleme beheben an.
Beheben Sie den Fehler und lassen Sie die Verifikation erneut laufen
Auf dem Löschproblem klicken Sie auf Beheben und wählen Sie dann Panolayer Agent aus. Panolayer übergibt den Kontext des Problems an den Agent, sodass Sie keinen Prompt schreiben müssen, der den Fehler erklärt.
Panolayer Agent ist integriert. Sie können nach der Installation auch einen anderen unterstützten Agent verwenden; siehe Unterstützte Agents.
Der Agent arbeitet in seinem eigenen Git-Worktree und hält seine Änderungen von Ihrem Branch getrennt. Verfolgen Sie die Aufgabe in Meine Agents, oder klicken Sie auf der Ausführungskarte auf Öffnen, um seine Aktivität und Änderungen zu prüfen.
Während sich der Code ändert, prüft Panolayer die betroffenen Funktionen und den verbundenen Code erneut, einschließlich Aufrufern in anderen Dateien. So lassen sich Regressionen auch außerhalb der vom Agent bearbeiteten Zeilen erkennen.
Eine Regression ist ein neues Problem, das durch die Änderung eingeführt wird. Wenn die Verifikation während einer Fehlerbehebung eine erkennt, kann der Agent sie reparieren und die Verifikation erneut ausführen, bevor er einen Merge anfordert. Eine Aufgabe kann daher mehrere Verifikationsläufe haben, bevor sie für Ihre Prüfung bereit ist.
Lesen Sie die Verifikationszusammenfassung vor dem Merge
Wenn dieser Lauf abgeschlossen ist, zeigt Panolayer Panolayer Agent ist bereit zum Mergen an. Der Dialog fasst zusammen, was die Verifikation während der Aufgabe geprüft und repariert hat.
| Zusammenfassungsfeld | Dieser Lauf | Bedeutung |
|---|---|---|
| Behobene Fehler | 1 | Die Arbeit hat einen Fehler behoben, der bereits vor dem Start der Aufgabe vorhanden war. |
| Bestandene Regeln | 14 von 21 | Vierzehn von 21 Regeln wurden für den geänderten Code bestanden. Lesen Sie dies zusammen mit der Statusmeldung und der separaten Zeile zu bereits vorhandenen Fehlern. |
| Verifikationsläufe | 1 | Ein Verifikationslauf hat während dieser Arbeit ein Ergebnis erreicht. Gezählt werden Verifikationsläufe, nicht einzelne Tests oder Regeln. |
| Geänderte Dateien | 4 | Die Aufgabe hat vier Dateien geändert. Prüfen Sie den vollständigen Änderungssatz, einschließlich aller Tests und Abhängigkeitsdateien. |
Die Statusmeldung lautet Keine neuen Fehler, Warnungen oder ungeprüften Regeln. Lesen Sie diese Meldung zusammen mit den Zahlen: Sie beschreibt das Ergebnis dieser Arbeit, während die nächste Zeile die Fehler erläutert, die bereits vor dem Start vorhanden waren.
Was ist, wenn “Erkannte Regressionen” angezeigt wird?
Einige Läufe zeigen außerdem Erkannte Regressionen an. Das meldet neue Probleme, die die Verifikation während der Arbeit erkannt hat, und hilft, sie aus dem Ziel-Branch herauszuhalten. Lesen Sie das neueste Ergebnis, um zu sehen, was noch Aufmerksamkeit erfordert; der Zähler beschreibt die während der Arbeit erkannten Fälle, nicht die Anzahl der aktuell ungelösten Fehler.
Dieses Feld wird in diesem Screenshot nicht angezeigt. Das Löschbeispiel zeigt einen behobenen, bereits vorhandenen Fehler; es zeigt keine während der Fehlerbehebung erkannte Regression.
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.