Preuve frontend pour PR

Que fait Preuve frontend pour PR ?

Enregistre la base de fusion et la tête de la PR avec des fixtures identiques, le même viewport et les mêmes interactions, puis poste les deux enregistrements sous forme d'un commentaire sur la PR via gh. La compétence PR du dépôt possède le corps de la PR. $SCRATCH désigne le répertoire scratch de la session. Exécutez les scripts fournis par leur chemin absolu.

Étapes

1. Résoudre les révisions. Lire baseRefName et headRefOid depuis gh pr view PR_URL --json baseRefName,headRefOid. Exécuter git fetch origin BASE_BRANCH pull/PR_NUMBER/head, puis git merge-base origin/BASE_BRANCH HEAD_SHA. Terminé lorsque les deux SHA sont résolus en local.
2. Construire les deux révisions. Terminé lorsque chaque révision possède un dossier de sortie construit ou un serveur de développement en cours d'exécution, et que sa source correspond à son SHA.
3. Écrire le flux dans $SCRATCH, à partir de l'exemple et en respectant l'interface de flux ci-dessous.
4. Capturer avec node scripts/capture.cjs FLOW "$SCRATCH/evidence". En cas d'échec, son erreur nomme la correction : la commande d'installation, une navigation hors de l'application, ou un problème de surbrillance. Les échecs de sélecteur laissent également failure.png et failure-aria.yml dans le dossier de sortie. Corrigez le flux et relancez. Terminé lorsque :
   • la commande se termine avec le code 0 ;
   • chaque entrée manifest.network est expliquée (dans un run simulé, chaque entrée est un appel non simulé) ;
   • comparison.png encadre le changement dans les deux phases ;
   • video-contact-sheet.png montre le curseur atteignant chaque cible et l'état final maintenu.
5. Publier avec node scripts/publish.cjs "$SCRATCH/evidence" PR_URL. Il confirme que les preuves correspondent à la tête et à la base de fusion actuelles de la PR, poste comment.md avec la comparaison et la vidéo jointes, et vérifie que GitHub héberge les deux. Relancer la même capture réutilise ce commentaire. Si gh auth status indique une connexion manquante, demandez cette étape uniquement à l'utilisateur. Si la publication reste bloquée, conservez les artefacts et rapportez l'erreur exacte. Terminé lorsqu'il affiche l'URL du commentaire.
6. Lier l'URL du commentaire depuis la section evidence du corps de la PR. Terminé lorsque le corps de la PR contient le lien vers l'URL imprimée par publish.cjs pour la tête actuelle, en remplaçant tout lien antérieur.
7. Nettoyer les serveurs et les worktrees que vous avez démarrés. Conservez les artefacts, cookies et fichiers d'état de stockage en dehors du contrôle de source.

Interface de flux

Un module de flux exporte :

• description : l'interaction testée et si les données sont simulées ou réelles. Il devient le texte du commentaire.
• phases : deux entrées { label, revision, url | dir, run }, Avant puis Après. dir est un dossier de sortie construit, servi par l'assistant avec repli des routes clientes sur index.html. url pointe vers un serveur de développement en cours d'exécution.
• viewport (optionnel, défaut 1440×900).
• setup(page, phase) (optionnel) : s'exécute avant la première navigation de chaque phase, sur une page avec routes, scripts d'initialisation, cookies et stockage réinitialisés. Enregistrez ici les mocks, seeds et fixtures d'authentification. Les routes correspondent par ordre de nouveauté, donc enregistrez un catch-all abort avant les mocks spécifiques.
• warmup(page, phase) (optionnel) : s'exécute sans enregistrement après le chargement de la page, par exemple pendant la compilation d'un serveur de développement.
• run(page, tools) : effectue l'interaction et vérifie l'état attendu de chaque phase, en utilisant tools.click(locator), tools.point(locator) et tools.highlight(locator, label?). Chaque phase nécessite au moins une surbrillance, encore visible lorsque run se termine.

Sorties : before.png, after.png, comparison.png, comparison.webm, video-contact-sheet.png (la vidéo sous forme d'images horodatées), manifest.json et comment.md.

Applications authentifiées. Le Chromium de l'assistant démarre sans connexions : les sessions de navigateur ailleurs et l'authentification gh ne l'atteignent pas. Reproduisez l'état connecté dans setup ; l'exemple montre deux méthodes. Si des preuves authentifiées en direct sont requises et que le contexte de capture ne peut pas y accéder, signalez la limitation et les vérifications réellement effectuées.

Après avoir modifié les scripts ou mis à jour Playwright, exécutez node scripts/capture.test.cjs. Définissez CAPTURE_TEST_OUTPUT=DIR pour conserver ses artefacts, et PLAYWRIGHT_MODULE=PATH pour tester une autre installation de Playwright.