Frontend PR evidence

Frontend PR-Belege

Zeichne die Merge-Basis und den aktuellen Stand des PRs mit identischen Fixtures, Viewport und Interaktionen auf und poste beide Aufnahmen als einen PR-Kommentar über gh. Das PR-Skill des Repositories besitzt den PR-Body. $SCRATCH ist das Scratch-Verzeichnis der Sitzung. Führe die gebündelten Skripte über ihre absoluten Pfade aus.

Schritte

1. Revisionen ermitteln. Lese baseRefName und headRefOid aus gh pr view PR_URL --json baseRefName,headRefOid. Führe git fetch origin BASE_BRANCH pull/PR_NUMBER/head aus, dann git merge-base origin/BASE_BRANCH HEAD_SHA. Abgeschlossen, wenn beide SHAs lokal aufgelöst sind.
2. Beide Revisionen bauen. Abgeschlossen, wenn jede Revision entweder einen gebauten Ausgabeordner oder einen laufenden Dev-Server hat und die Quelle mit ihrem SHA übereinstimmt.
3. Den Flow schreiben unter $SCRATCH, beginnend mit dem Beispiel und nach dem untenstehenden Flow-Interface.
4. Aufnehmen mit node scripts/capture.cjs FLOW "$SCRATCH/evidence". Wenn es fehlschlägt, gibt der Fehler die Lösung vor: den Installationsbefehl, eine Navigation weg von der App oder ein Highlight-Problem. Selektionsfehler hinterlassen zusätzlich failure.png und failure-aria.yml im Ausgabeordner. Korrigiere den Flow und führe es erneut aus. Abgeschlossen, wenn:
   • der Befehl mit Exit-Code 0 endet;
   • jeder Eintrag in manifest.network erklärt ist (in einem gemockten Durchlauf ist jeder Eintrag ein nicht gemockter Aufruf);
   • comparison.png die Änderung in beiden Phasen darstellt;
   • video-contact-sheet.png zeigt, wie der Cursor jedes Ziel erreicht und den Endzustand hält.
5. Veröffentlichen mit node scripts/publish.cjs "$SCRATCH/evidence" PR_URL. Es bestätigt, dass die Belege mit dem aktuellen Head und der Merge-Basis des PRs übereinstimmen, postet comment.md mit dem Vergleich und dem angehängten Video und überprüft, dass GitHub beide hostet. Ein erneutes Ausführen für denselben Capture verwendet denselben Kommentar. Wenn gh auth status eine fehlende Anmeldung anzeigt, frage den Benutzer nur nach diesem Schritt. Wenn das Veröffentlichen blockiert bleibt, behalte die Artefakte und melde den genauen Fehler. Abgeschlossen, wenn die Kommentar-URL ausgegeben wird.
6. Verlinken der Kommentar-URL aus dem Belege-Abschnitt des PR-Bodys. Abgeschlossen, wenn der PR-Body die URL verlinkt, die publish.cjs für den aktuellen Head ausgegeben hat, und dabei einen vorherigen Belege-Link ersetzt.
7. Aufräumen der von dir gestarteten Server und Worktrees. Behalte Artefakte, Cookies und Storage-State-Dateien außerhalb der Versionskontrolle.

Flow-Interface

Ein Flow-Modul exportiert:

• description: die getestete Interaktion und ob Daten gemockt oder live sind. Es wird zum Kommentartext.
• phases: zwei Einträge { label, revision, url | dir, run }, Vorher und Nachher. dir ist ein gebauter Ausgabeordner, der vom Helfer bedient wird, wobei Client-Routen auf index.html zurückfallen. url zeigt auf einen laufenden Dev-Server.
• viewport (optional, Standard 1440×900).
• setup(page, phase) (optional): wird vor der ersten Navigation jeder Phase ausgeführt, auf einer Seite mit Routen, Init-Skripten, Cookies und zurückgesetztem Storage. Registriere hier Mocks, Seeds und Auth-Fixtures. Routen werden nach neuestem zuerst gematcht, also registriere vor den spezifischen Mocks einen Catch-All-Abbruch.
• warmup(page, phase) (optional): wird unaufgezeichnet nach dem Laden der Seite ausgeführt, z. B. während ein Dev-Server kompiliert.
• run(page, tools): führt die Interaktion durch und bestätigt den erwarteten Zustand jeder Phase, unter Verwendung von tools.click(locator), tools.point(locator) und tools.highlight(locator, label?). Jede Phase benötigt mindestens ein Highlight, das noch sichtbar ist, wenn run zurückkehrt.

Ausgaben: before.png, after.png, comparison.png, comparison.webm, video-contact-sheet.png (das Video als zeitgestempelte Bilder), manifest.json und comment.md.

Authentifizierte Apps. Der Chromium des Helfers startet ohne Anmeldungen: Browsersitzungen an anderer Stelle und gh-Authentifizierung erreichen ihn nicht. Stelle den eingeloggten Zustand in setup nach; das Beispiel zeigt zwei Wege. Wenn ein authentifizierter Live-Beleg erforderlich ist und der Capture-Kontext ihn nicht erreichen kann, melde die Einschränkung und die tatsächlich durchgeführten Prüfungen.

Nachdem du die Skripte geändert oder Playwright aktualisiert hast, führe node scripts/capture.test.cjs aus. Setze CAPTURE_TEST_OUTPUT=DIR, um seine Artefakte zu behalten, und PLAYWRIGHT_MODULE=PFAD, um eine andere Playwright-Installation zu testen.