chukaofili/agent-plugins

UI überprüfen

Die Bildschirme zu bauen ist die erste Hälfte. Eine UI-Änderung ist erst dann abgeschlossen, wenn sie in einem echten Browser getestet wurde und ihre Screenshots im PR sind. Ein sauberer Typcheck, Lint-Durchlauf und Unit-Suite sagen, dass der Code kompiliert und seine Logik stimmt. Keiner von ihnen sagt, ob das Panel rendert oder ob der Footer an der vom Design vorgesehenen Stelle sitzt. Reviewer, die den Branch nie ausführen, beurteilen die Arbeit anhand der Screenshots – oder gar nicht.

1. In einem echten Browser mit echten Daten testen

Verwenden Sie eine laufende App mit einer echten (geseedeten) Datenbank, keine Mocks, und nicht nur einen Screenshot des Happy Paths. Gehen Sie jeden Zustand durch, den das Design nennt, plus die, die es nicht nennt:

• Beide Themes. Handgeschriebene Farben sind der Ort, an dem Dark-Mode-Varianten vergessen werden.
• Mobil und Desktop. Layouts ordnen sich an Breakpoints neu, und Footers und Toolbars können die Hälfte ihres Inhalts verwaist lassen.
• Leere, Lade-, Limit- und Fehlerzustände, nicht nur den befüllten Zustand.
• Jede Übergabe, bei der ein Dialog oder eine Ansicht geschlossen und eine andere geöffnet wird.
• Öffnen Sie jedes Menü, Popover und Dropdown, das Sie hinzugefügt haben. Ein Menü, das Sie nie öffnen, sieht identisch aus wie eines, das die Seite beim Öffnen zum Absturz bringt.
• Überprüfen Sie die Browserkonsole und das Netzwerkpanel auf Fehler, während Sie vorgehen.

2. Eine Review-Überprüfung durchführen

Überprüfen Sie die Änderung gegen die Design- und Framework-Richtlinien, die das Repo verwendet (Designsystem, Barrierefreiheit, Framework-Best Practices). Wenn Ihr Agent Subagenten erstellen kann, führen Sie einen Reviewer pro Richtlinie parallel auf einem günstigeren Modell aus. Es ist Mustererkennungsarbeit, kein Urteilsvermögen.

• Geben Sie den Reviewern die eigenen Regeln des Repos. Ein Reviewer, der sie nicht gelesen hat, meldet dokumentierte Entscheidungen als Verstöße.
• Sagen Sie ihnen, sie sollen nur melden. Beurteilen Sie dann jeden Befund selbst nach realer Wahrscheinlichkeit. Lehnen Sie Befunde ab, die für ein anderes Produkt zutreffen würden, wie z. B. Virtualisierungsempfehlungen für eine Liste, die auf ein Dutzend Zeilen begrenzt ist.

3. Screenshots für den PR erfassen

Keine Beschreibung der Bildschirme: die Bildschirme selbst. Das Erfassen ist auch der günstigste Weg, einen Zustand zu erwischen, den Sie nicht wirklich angesehen haben.

• Die echte App testen. Ein Einweg-Browser-Skript, das jeden Zustand erreicht, ist in Ordnung. Verwenden Sie die Seed-Helfer des E2E-Harnesses, um Zustände zu erreichen, die kein UI-Flow produziert, und löschen Sie dann das Skript, sobald die Bilder existieren. Es behauptet nichts und ist keine Coverage.
• Vor dem Erfassen neu bauen. Sonst screenshoten Sie möglicherweise den Bug, den Sie gerade behoben haben.
• Vor dem Auslösen auf Animationen warten. „Sichtbar“ wird aufgelöst, wenn ein Element layoutet ist, nicht wenn seine Eingangstransition endet, daher zeigt eine naive Aufnahme halb ausgeblendete Dialoge ohne Hintergrund. Warten Sie auf endliche Animationen (filtern Sie unendliche wie Skelett-Pulse aus), mit einem Timeout.
• Jeden Zustand so erreichen, wie ein Benutzer es tun würde, wo möglich. Das Erzwingen eines Flags überspringt das Rennen, das einen Bug aufdecken könnte.
• Committen Sie sie in docs/screenshots/<topic>/, neben dem Design, das sie implementieren, falls vorhanden.
• Referenzieren Sie sie per Commit-SHA, nicht per Branch, z. B. https://github.com/<org>/<repo>/blob/<sha>/<path>?raw=true. Eine Branch-URL stirbt, wenn der Branch beim Merge gelöscht wird, und hinterlässt den PR voller kaputter Bilder.

Kein Browser verfügbar

Wenn die Umgebung die UI wirklich nicht ausführen kann (keine Browser-Tools, fehlende Credentials, Infrastruktur, die Sie nicht kontrollieren), sagen Sie das im Testing-Abschnitt des PRs. Nennen Sie, was es blockiert hat und was Sie stattdessen überprüft haben. Schweigen wird als „überprüft“ gelesen.

Review-Fixes als Stage oben drauf versenden

Fixes, die bei diesem Durchlauf gefunden werden, gehen in einen neuen gestapelten PR oben auf dem Feature, sodass der Build und der Review-Durchlauf separat überprüfbar bleiben (siehe stacked-prs).

Was dieser Durchlauf abfängt

Keiner dieser Fehler stammt von einem Typprüfer, Linter oder Unit-Suite:

• Ein Lade-Skelett, das nicht zu seiner Seite passte. Es skeletonte eine Toolbar, die die Seite nicht hat, sodass jede Navigation zwischen zwei Layouts sprang. Spiegeln Sie das echte Layout Zeile für Zeile, oder liefern Sie kein Skelett aus.
• Zwei gleichzeitig gemalte Dialoge bei einer Übergabe, weil jeder Dialog gemountet war und nur sein open-Flag umgeschaltet wurde. Versteckt ist nicht unmountet.
• Ein kurzer Identitätsfehler: Die eigene Zeile des Benutzers bot an, ihn für einen Paint zu entfernen, weil der Client die Sitzung nach dem ersten Rendern las. Die Identität, die der Server bereits kennt, sollte mit der Seite herunterkommen.
• Ein falscher leerer Zustand: „Keine Ergebnisse gefunden“ wurde für einen Frame vor der Auflösung der Abfrage gerendert, weil null Zeilen sowohl „Laden“ als auch „Leer“ bedeuteten.
• Ein Design-Token gegen ein ähnlich aussehendes ausgetauscht, sichtbar unterschiedlich in einem der Themes.
• Ein hartcodiertes Label neben vier anderen Aufrufstellen, die dasselbe Label aus einem gemeinsamen Katalog lesen.
• Ein Menü, das die Seite beim Öffnen abstürzen ließ, weil eine Unterkomponente ein Elternteil erforderte, das sie nicht hatte. Ein manueller Klick-Durchlauf verpasste es zweimal, weil niemand das Menü öffnete.
• Ein Spezifikationspunkt leise übersprungen, und ein anderer aus gutem Grund fallengelassen, aber undokumentiert. Jede Abweichung vom Design braucht einen Hinweis, warum.
• Ein sich widersprechender Dialog, gefunden durch das Anschauen des Screenshots: Ein Hinweis sagte „alle Plätze sind belegt“, während der Footer daneben immer noch „2 Plätze frei“ anbot.