Suivez l’exemple Twitter
Ce guide suit le bug de suppression de post dans l’exemple Twitter de Panolayer. Vous allez lire le problème, suivre son explication jusqu’au code et comprendre le résumé de vérification avant de décider si vous devez fusionner.
Pour suivre, ouvrez Twitter Clone sous Essayer une application d’exemple. Il s’ouvre sous le nom twitter-starter. Pour la procédure complète de configuration et de correction, consultez Corriger votre premier bug avec Panolayer. Les captures d’écran montrent une exécution enregistrée ; l’ordre et le nombre de vos problèmes peuvent différer.
Commencez par Problèmes
Lorsque vous ouvrez une base de code, le moteur de vérification Panolayer démarre. Il analyse la base de code jusqu’au niveau de ses fonctions, symboles et dépendances, construit l’architecture visuelle et vérifie le code pour identifier les bugs.
Ouvrez Problèmes. Dans cet exemple, l’exécution est terminée et le statut indique Vérification terminée. Les problèmes nécessitant une investigation apparaissent sous Nécessite votre attention.
Vérification terminée décrit l’exécution. Cela signifie que l’exécution est terminée ; lisez les résultats pour voir si des échecs ont été détectés.
Lire le problème de suppression
Le premier problème de l’exemple signale qu’une condition peut empêcher une suppression confirmée :
La garde supplémentaire
canDeletepeut empêcher la suppression malgré la confirmation de l’utilisateur, contrairement au comportement de suppression de la publication actuelle indiqué.
Une règle est une attente concernant le comportement d’une fonction : ce qu’elle doit renvoyer, quelle action elle doit effectuer ou ce que d’autre code attend d’elle. Ici, l’attente concerne la suppression de la publication actuelle après confirmation de l’utilisateur.
Lisez ensemble le fichier, la fonction, le statut et l’explication du problème :
| Ce que vous voyez | Ce que cela vous indique |
|---|---|
components/Post.tsx | Le fichier contenant la fonction à examiner. |
handleDelete() | La fonction dont le comportement a été vérifié. |
| Échec | Le comportement vérifié ne respectait pas la règle. |
| Gravité 3 · Fonctionnalité | La gravité et la catégorie du problème vous aident à prioriser l’examen. |
| Détails | L’explication et l’emplacement source vous aident à comprendre pourquoi le problème a été signalé. |
Cliquez sur Détails. L’explication indique que la fonction peut effectuer un retour anticipé lorsque canDelete vaut false, avant d’achever la suppression décrite par la règle. La référence source pointe vers le code concerné.
Vérifiez que la règle correspond au comportement attendu avant de décider quoi modifier. Si l’attente est erronée, corrigez la règle. Si le code est erroné, corrigez le code. Une modification peut aussi affecter des appelants dans d’autres fichiers ; suivez donc les appelants concernés indiqués dans le résultat.
Que signifient les statuts ?
Lisez le statut avec son explication et le code auquel il s’applique.
| Résultat | Comment l’interpréter |
|---|---|
| Réussi | La règle évaluée a été satisfaite pour le code vérifié. Cela décrit cette règle, et non l’ensemble des comportements possibles de l’application. |
| Échec | La règle évaluée n’a pas été satisfaite. Lisez l’explication et inspectez la source pour déterminer ce qu’il faut corriger. |
| En attente ou en cours | Le résultat n’est pas prêt. Attendez la fin de la vérification avant de conclure. |
| Indisponible | La vérification n’a pas pu se terminer. Lisez le message associé et résolvez le problème signalé avant de vérifier à nouveau. |
| Non vérifié | L’attente n’a pas été évaluée. Ce n’est pas un résultat réussi. |
Si la vérification ne peut pas se terminer, suivez l’erreur signalée et consultez Résoudre les problèmes de configuration et d’agent.
Corrigez le bug et laissez la vérification s’exécuter à nouveau
Sur le problème de suppression, cliquez sur Corriger, puis sélectionnez Panolayer Agent. Panolayer transmet le contexte du problème à l’agent, vous n’avez donc pas besoin de rédiger un prompt expliquant le bug.
Panolayer Agent est intégré. Vous pouvez aussi utiliser un autre agent pris en charge après l’avoir installé ; voir Agents pris en charge.
L’agent travaille dans son propre worktree Git, ce qui garde ses modifications séparées de votre branche. Suivez la tâche dans Mes agents, ou cliquez sur Ouvrir sur la carte d’exécution pour inspecter son activité et ses modifications.
À mesure que le code change, Panolayer vérifie à nouveau les fonctions concernées et le code connecté, y compris les appelants dans d’autres fichiers. Cela aide à détecter les régressions au-delà des lignes modifiées par l’agent.
Une régression est un nouveau problème introduit par la modification. Si la vérification en détecte une pendant une correction, l’agent peut la réparer et relancer la vérification avant de demander une fusion. Une tâche peut donc comporter plusieurs exécutions de vérification avant d’être prête pour votre revue.
Lire le résumé de vérification avant de fusionner
Lorsque cette exécution se termine, Panolayer affiche Panolayer Agent est prêt à être fusionné. La boîte de dialogue résume ce que la vérification a contrôlé et corrigé pendant la tâche.
| Champ du résumé | Cette exécution | Signification |
|---|---|---|
| Échecs corrigés | 1 | Le travail a corrigé un échec déjà présent avant le début de la tâche. |
| Règles validées | 14 sur 21 | Quatorze règles sur 21 ont été validées sur le code modifié. Lisez ce chiffre avec le message d'état et la ligne distincte des échecs préexistants. |
| Exécutions de vérification | 1 | Une exécution de vérification a produit un résultat pendant ce travail. Ce compteur recense les exécutions de vérification, et non les tests ou règles individuels. |
| Fichiers modifiés | 4 | La tâche a modifié quatre fichiers. Passez en revue l'ensemble des modifications, y compris les tests et les fichiers de dépendances. |
Le message d'état indique Aucun nouvel échec, avertissement ni règle non vérifiée. Lisez ce message avec les compteurs : il décrit le résultat de ce travail, tandis que la ligne suivante explique les échecs qui subsistent depuis avant son démarrage.
Que se passe-t-il si « Régressions détectées » apparaît ?
Certaines exécutions affichent aussi Régressions détectées. Il signale les nouveaux problèmes détectés par la vérification pendant le travail, ce qui aide à les tenir à l'écart de la branche cible. Consultez le dernier résultat pour voir ce qui nécessite encore votre attention ; le compteur décrit les détections effectuées pendant le travail, et non le nombre d'échecs actuellement non résolus.
Ce champ n'apparaît pas dans cette capture d'écran. L'exemple de suppression montre un échec préexistant corrigé ; il ne démontre pas une régression détectée pendant le correctif.
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.