Zum Inhalt springen

ANLEITUNG

Review changes and commit

Changes ist Panolayers Interpretation von Diffs. Statt Tausende Zeilen eines Diffs zu lesen, siehst du schnell, was sich geändert hat, und welche Dateien deine Aufmerksamkeit brauchen – bewertet von höchstem bis niedrigstem Risiko.

Zuletzt aktualisiert

Als Markdown lesen

Sehen Sie, was geprüft werden muss

Sehen Sie die Worktrees Ihrer Agents und ihre Änderungen ohne Commit an einem Ort. Prüfen Sie die riskanten Änderungen, untersuchen Sie alles, was behoben werden muss, und erstellen Sie auf der Seite Änderungen einen Commit für Ihren Code.

Diese Anleitung verwendet Panolayers Twitter-Beispiel twitter-starter. Wenn Sie Ihren ersten Bug mit Panolayer beheben durchgeführt haben, verwenden Sie diese Schritte, um den Fix für das Löschen zu prüfen.

Die Screenshots und kurzen Videos zeigen mehrere Änderungen in derselben Twitter-App, darunter Formatierungs-, Such- und Exportänderungen sowie Änderungen an gespeicherten Beiträgen. Ihre Dateiliste, Risikobewertungen und Commit-IDs hängen von der Arbeit ab, die Sie prüfen. Klicken Sie auf einen Screenshot, um ihn in voller Größe anzuzeigen.

Öffnen Sie Änderungen in der Seitenleiste. Auf der rechten Seite sehen Sie die verschiedenen Worktrees und den Code Ihrer Agents ohne Commit. Wählen Sie einen Worktree aus, um zu sehen, was dieser Agent geändert hat; die Dateien sind vom höchsten bis zum niedrigsten Risiko bewertet.

Wechseln Sie zwischen den Worktrees Ihrer Agents, prüfen Sie deren Änderungen und erstellen Sie von dieser Seite aus Commits. Die Risikobewertungen zeigen schnell, welche Dateien Ihre Aufmerksamkeit benötigen und möglicherweise einen Fix erfordern.

Sie können auch einen vorhandenen Commit in Verlauf auswählen, um zu prüfen, was aufgezeichnet wurde. Wenn Sie den Fix für das Löschen bereits zusammengeführt haben, finden Sie ihn dort; die Zusammenführung hat die Änderung bereits lokal aufgezeichnet.

Änderungen vom höchsten zum niedrigsten Risiko prüfen

Die Seite Änderungen bewertet Dateien von riskant bis nicht riskant und erklärt, was sich geändert hat. Beginnen Sie mit den Dateien mit dem höchsten Risiko, um zu verstehen, was vor einem Commit geprüft und möglicherweise behoben werden muss.

Wechseln Sie zwischen Risikospektrum, Risikobalken und Überlappung, um dieselben Änderungen in drei visuellen Ansichten zu erkunden.

Risikospektrum

Sehen Sie die geänderten Dateien entlang eines horizontalen Spektrums angeordnet, von hohem Risiko links bis niedrigem Risiko rechts.

Das Risikospektrum bietet einen visuellen Überblick über das Risiko einer Änderung in der Twitter-App.

Risikobalken

Vergleichen Sie Dateien als nach Risiko geordnete Balken. Die Ansicht reicht von sehr riskant bis nicht riskant und macht es leicht zu erkennen, wo die Änderungen Aufmerksamkeit benötigen.

Risikobalken zeigt dieselbe Twitter-Änderung als Reihe von Balken, vom höchsten zum niedrigsten Risiko sortiert.

Überlappung

Sehen Sie, wo sich UI-Änderungen, Logikänderungen und riskante Änderungen überschneiden. Die gruppierten Dateien zeigen, wie diese Teile der Änderung zueinander in Beziehung stehen.

Überlappung zeigt, welche Dateien in der Twitter-App in die Gruppen UI, Logik und Riskant fallen.

Eine Änderung mit Handlungsbedarf prüfen

Die Risikoübersicht zeigt, worauf Sie Ihre Prüfung konzentrieren sollten. Öffnen Sie eine Datei, wenn Sie eine bestimmte Änderung genauer verstehen möchten.

  1. Wählen Sie eine Datei im Graph oder in der Liste der geänderten Dateien aus.
  2. Lesen Sie ihren Pfad, die Änderungszusammenfassung und die Risikoerklärung.
  3. Wählen Sie Split für einen Side-by-Side-Vergleich oder Inline, um die Änderungen in einer Ansicht zu lesen.
  4. Verfolgen Sie die Änderung durch die relevante Funktion und ihre Aufrufer. Prüfen Sie auch zugehörige Tests, Konfigurations- und Abhängigkeitsdateien.
Diese Aufnahme prüft eine Suchänderung in app/api/search/route.ts. Der Diff zeigt, wie sich die SQL-Abfrage geändert hat.

Öffnen Sie für die Behebung des Löschproblems components/Post.tsx und untersuchen Sie handleDelete(). Prüfen Sie, wie die Änderung die gemeldete canDelete-Bedingung adressiert und ob Benutzerbestätigung, Löschanforderung und Behandlung erfolgreicher Antworten weiterhin zusammenpassen.

Analyse lesen und Bedenken ansprechen

Die Deep Analysis von Panolayer Agent ist in Changes immer verfügbar. Öffnen Sie das Panel Panolayer Agent – Deep Analysis, um die Bewertung, Bedenken und Quellenverweise zu lesen. Gehen Sie einem Bedenken in die relevante Datei nach, um zu verstehen, was beachtet werden muss.

Ansehen: Analyse einer Twitter-Exportänderung prüfen

Der vorhandene Analyse-Clip zeigt eine Exportänderung in der Twitter-App, wobei Bedenken mit den betroffenen Dateien verknüpft sind.

Verwenden Sie Chat, um die Prüfung mit Panolayer Agent fortzusetzen. Stellen Sie eine Frage zum Verhalten, das Sie prüfen, z. B.:

„Wie behebt diese Änderung das Löschproblem, und welche Tests decken das erwartete Verhalten ab?“

Nutzen Sie die Antwort, um durch die Änderung zu navigieren und alles Unklare zu untersuchen.

Verifikation parallel zum Review lesen

Änderungen können Verifikationsergebnisse für die betroffenen Funktionen anzeigen. Lesen Sie fehlgeschlagene Regeln und alle Prüfungen, die noch ausstehen oder nicht verfügbar sind, und folgen Sie deren Erläuterungen in den Code.

Die Risikoübersicht hilft Ihnen bei der Auswahl, wo Sie nachsehen sollten. Die Tiefenanalyse liefert Ihnen Ansatzpunkte zur Untersuchung. Die Verifikation meldet Prüfergebnisse im Abgleich mit Erwartungen an das Codeverhalten. Lesen Sie sie zusammen mit dem Diff und den relevanten Tests.

Bestätigen Sie im Löschbeispiel, dass der ausgewählte Fehler behoben wurde, und prüfen Sie neue Fehler getrennt von bereits bestehenden Problemen. Unter Ein Verifikationsergebnis verstehen finden Sie die Zusammenfassungsfelder und Statusangaben.

Führen Sie die Anwendung aus, wenn die Änderung eine Laufzeitprüfung erfordert. Versuchen Sie für diese Korrektur, einen Beitrag zu löschen, und prüfen Sie, ob Bestätigen oder Abbrechen wie erwartet funktioniert.

Merge the agent’s work when you’re satisfied

When the agent requests a merge, review the verification summary and confirm the target branch. Choose Not now to keep reviewing, or Merge into main to bring the work into the sample’s main branch.

This is the deletion fix’s verification summary. You decide whether the reviewed work reaches your branch.

The Merged into main confirmation shows the commit ID. This workflow records the agent’s change in local Git history; you do not need to commit that same change again.

Commit any uncommitted edits

Use this step for your own edits or other uncommitted work in the current workspace. If the agent’s merge already saved the change and you have no further edits, continue to History.

  1. Check the full changed-file list.
  2. Review the suggested commit message. Use Edit message if it needs to describe the change more clearly.
  3. Choose Commit to save the changes to the local branch. Choose Commit & Push if you also want to send the commit to a configured remote.
The existing toolbar capture shows a search fix awaiting a commit. The same controls apply to uncommitted changes in your active workspace.

A Panolayer commit includes every changed file in the workspace. Use Git directly if you need to stage only part of the change. Read any reported check failures before deciding to commit; a commit can still be created when checks fail.

Confirm the result in History

Open History and find the new commit using its message, author, and commit ID. Select it to inspect the recorded change, then return to Working tree to check for remaining uncommitted edits.

Watch: Confirm a Twitter saved-post change in merge confirmation and History

This existing clip follows a saved-post change in the Twitter app. Use the commit ID from your own merge confirmation to find your change.

For the deletion fix, you should be able to find its recorded change and inspect the files that landed. Check that no unexpected uncommitted edits remain.

Push when you’re ready to share the commit

A merge or commit saves work locally. To send an existing local commit to your Git remote, open Git and choose Push.

Pushing requires a configured remote and permission to write to it. If the sample has no remote, the local commit completes this walkthrough. If a push reports an error, read it and resolve the remote or sign-in problem before trying again.

Use your Git host for pull requests and team review.