Aller au contenu

GUIDE PRATIQUE

Review changes and commit

Changes est l’approche de Panolayer en matière de diffs. Au lieu de lire des milliers de lignes d’un diff, comprenez rapidement ce qui a changé et voyez quels fichiers requièrent votre attention, classés du risque le plus élevé au plus faible.

Dernière mise à jour

Lire en Markdown

Voir ce qui doit être relu

Consultez les worktrees de vos agents et leurs modifications non commitées au même endroit. Relisez les modifications à risque, examinez tout ce qui doit être corrigé et commitez votre code depuis la page Changes.

Ce guide utilise l’exemple Twitter de Panolayer, twitter-starter. Si vous avez suivi Corrigez votre premier bug avec Panolayer, utilisez ces étapes pour relire le correctif de suppression.

Les captures d’écran et les courtes vidéos montrent plusieurs modifications dans la même application Twitter, notamment des changements de formatage, de recherche, d’export et de posts enregistrés. Votre liste de fichiers, vos scores de risque et vos ID de commit dépendront du travail que vous relisez. Cliquez sur une capture d’écran pour l’afficher en taille réelle.

Ouvrez Changes dans la barre latérale. À droite, vous voyez les différents worktrees et le code non commité de vos agents. Sélectionnez un worktree pour voir ce que cet agent a modifié, les fichiers étant classés du risque le plus élevé au plus faible.

Passez d’un worktree à l’autre, relisez les modifications de vos agents et commitez le code depuis cette page. Les scores de risque permettent de repérer rapidement les fichiers qui demandent votre attention et qui peuvent nécessiter une correction.

Vous pouvez aussi sélectionner un commit existant dans History pour relire ce qui a été enregistré. Si vous avez déjà fusionné le correctif de suppression, vous le trouverez ici ; sa fusion a déjà enregistré la modification localement.

Relire les modifications du risque le plus élevé au plus faible

Modifications évalue le niveau de risque des fichiers, du plus risqué au non risqué, et explique ce qui a changé. Commencez par les fichiers les plus risqués pour comprendre ce qui doit être examiné et éventuellement corrigé avant votre commit.

Basculez entre Spectre de risque, Barres de risque et Chevauchement pour explorer les mêmes modifications dans trois vues visuelles.

Spectre de risque

Affichez les fichiers modifiés disposés le long d’un spectre horizontal, du risque élevé à gauche au risque faible à droite.

Spectre de risque vous donne un aperçu visuel du risque sur une modification dans l’application Twitter.

Barres de risque

Comparez les fichiers sous forme de barres classées par risque. La vue va de très risqué à non risqué, ce qui permet de voir facilement où les modifications nécessitent votre attention.

Barres de risque montre la même modification Twitter sous forme de série de barres, classées du risque le plus élevé au plus faible.

Chevauchement

Voyez où les modifications d’interface, les modifications de logique et les modifications risquées se chevauchent. Les fichiers regroupés montrent comment ces parties de la modification sont liées les unes aux autres.

Chevauchement montre quels fichiers appartiennent aux groupes Interface, Logique et Risqué dans l’application Twitter.

Inspecter une modification qui nécessite votre attention

La vue d’ensemble des risques indique où concentrer votre revue. Ouvrez un fichier lorsque vous souhaitez comprendre une modification précise plus en détail.

  1. Sélectionnez un fichier dans le graphe ou dans la liste des fichiers modifiés.
  2. Lisez son chemin, le résumé de la modification et l’explication du risque.
  3. Choisissez Côte à côte pour comparer les versions, ou En ligne pour lire les modifications dans une seule vue.
  4. Suivez la modification dans la fonction concernée et ses appelants. Vérifiez aussi les tests, la configuration et les fichiers de dépendances associés.
Cette capture examine une modification de recherche dans app/api/search/route.ts. Le diff montre comment la requête SQL a changé.

Pour le correctif de suppression, ouvrez components/Post.tsx et inspectez handleDelete(). Vérifiez comment la modification traite la condition canDelete signalée, et si la confirmation utilisateur, la requête de suppression et la gestion de la réponse en cas de succès restent cohérentes entre elles.

Lire l’analyse et poser des questions sur les points d’attention

L’analyse approfondie de Panolayer Agent est toujours disponible dans Modifications. Ouvrez le panneau Panolayer Agent – Analyse approfondie pour lire son évaluation, ses points d’attention et ses références aux sources. Suivez un point d’attention dans le fichier concerné pour comprendre ce qui nécessite votre attention.

Regarder : inspecter l’analyse d’une modification d’export Twitter

L’extrait d’analyse existant montre une modification d’export dans l’application Twitter, avec des points d’attention liés aux fichiers concernés.

Utilisez Discussion pour poursuivre la revue avec Panolayer Agent. Posez une question liée au comportement que vous vérifiez, par exemple :

« Comment cette modification corrige-t-elle le problème de suppression, et quels tests couvrent le comportement attendu ? »

Utilisez la réponse pour naviguer dans la modification et examiner tout ce qui n’est pas clair.

Lire la vérification en parallèle de la revue

La section Modifications peut afficher les résultats de vérification sur les fonctions concernées. Lisez les règles en échec et les contrôles encore en attente ou indisponibles, puis suivez leurs explications dans le code.

La vue d’ensemble des risques vous aide à choisir où regarder. L’analyse approfondie vous donne des points d’attention à examiner. La vérification signale des contrôles par rapport aux attentes concernant le comportement du code. Lisez-les avec le diff et les tests concernés.

Pour l’exemple de suppression, confirmez que l’échec sélectionné a été corrigé et examinez les nouveaux échecs séparément des problèmes préexistants. Consultez Comprendre un résultat de vérification pour les champs du résumé et les statuts.

Exécutez l’application lorsque la modification nécessite une vérification à l’exécution. Pour ce correctif, essayez de supprimer une publication et vérifiez que la confirmation ou l’annulation se comporte comme prévu.

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.