jakubkrehel/interface-review

Änderungsüberprüfung

Diese Skill überprüft eine Änderung und nicht einen Bildschirm. Sie ermittelt den Geltungsbereich, erweitert die geänderten Dateien auf die davon betroffenen Oberflächen, liest beide Seiten des Diffs und klassifiziert jeden Befund.

Der Geltungsbereich umfasst alles, was ihr gehört. Domänenregeln gehören zu den better-*-Skills. Schweregrad, Konsolidierung, Abdeckung, die Obergrenze und das Urteil gehören zu better-interface, an das diese Skill die Überprüfung übergibt.

Korrektheit, Tests, Sicherheit und Leistung gehören zum allgemeinen Code-Review des Projekts. Nennen Sie das Anliegen einmal und gehen Sie weiter.

Die Änderung, nicht die Codebasis

Der Autor fragt: "Habe ich das verschlechtert?". Berichten Sie, was die Änderung verursacht hat, und halten Sie sich weitgehend zurück, was sie nur berührt hat. Drei bereits vorhandene Befunde sind eine Höflichkeit; dreißig sind eine andere Überprüfung, um die niemand gebeten hat.

Lesen Sie die Änderung, bevor Sie sich eine Meinung darüber bilden. Die erklärte Absicht entscheidet darüber, was als unvollständig gilt, und ein überflogener Diff erzeugt Befunde über Code, den der nächste Hunk bereits behoben hat.

Kernprinzipien

1. Den Änderungsumfang zuerst ermitteln

Der gesamte Aufruf ist das Ziel, also überprüft /interface-review pr 482 den Pull Request 482. Die Umfangsermittlung enthält die akzeptierten Ziele und wie jedes aufgelöst wird.

Wenn kein Ziel angegeben ist, wird in dieser Reihenfolge aufgelöst und beim ersten Treffer gestoppt:

1. HEAD liegt vor git merge-base origin/<default-branch> HEAD: dieser Bereich plus alle nicht committeten Änderungen, wobei die Anzahl der Commits und die Anzahl der nicht committeten Dateien getrennt angegeben werden.
2. Der Arbeitsbaum ist verschmutzt: die nicht committeten Änderungen.
3. Weder noch: Es gibt keine zu überprüfende Änderung. Stoppen und fragen, gemäß Bei keiner Änderung fragen, anstatt eine zu erfinden.

Die Reihenfolge ist wichtig. Überprüfen Sie zuerst den Arbeitsbaum, und eine einzige versehentliche Formatierungsänderung überschattet einen Zwölf-Commits-Branch, wobei der Bericht dennoch eine vollständige Abdeckung behauptet.

Schließen Sie Sperrdateien, Snapshots, generierte Ausgaben, vendorierten Code und Binärdateien aus und nennen Sie, was Sie ausgeschlossen haben. Ein leerer Geltungsbereich nach Ausschlüssen erreicht denselben Ort auf einem anderen Weg.

2. Bei keiner Änderung fragen, anstatt eine zu erfinden

Ein sauberer Baum mit nichts vor dem Merge-Base bedeutet, dass der Benutzer gebeten hat, eine Änderung zu überprüfen, die nicht existiert. Fallen Sie niemals selbstständig auf HEAD~1..HEAD zurück. Der letzte Commit ist das, was gerade gelandet ist, oft ein Merge, oft die Arbeit eines anderen, und ein Bericht darüber ist nicht von einem Bericht über das zu unterscheiden, was der Benutzer gemeint hat.

Geben Sie die Repository-Fakten an, die Sie gefunden haben, bieten Sie dann die Wege an und warten Sie. Nichts zu überprüfen enthält die zu sammelnden Fakten:

• Der letzte Commit, HEAD~1..HEAD, benannt nach kurzem SHA und Betreff, damit der Benutzer sieht, was er bekommen würde, bevor er sich dafür entscheidet.
• Ein von ihnen benanntes Ziel: pr <n>, ein Branch, ein Ref oder ein Bereich, aufgelöst gemäß Den Änderungsumfang zuerst ermitteln.
• Ein Repository-weites Interface-Audit, das keine Änderungsüberprüfung ist. Übergeben Sie es an better-interface als Repository-weite Überprüfung, ohne den Geltungsbereichsblock, die Status oder den bereits vorhandenen Abschnitt dieser Skill. Ohne Änderung ist jeder Befund bereits vorhanden und die Klassifizierung sagt nichts aus.

Prüfen Sie vor dem Fragen, ob ein offener Pull Request für den aktuellen Branch existiert, und bieten Sie ihn zuerst an. Ein Branch, dessen Commits bereits gelandet sind, wird zu keiner Änderung aufgelöst, während sein Pull Request immer noch genau das ist, was der Benutzer gemeint hat.

Wenn der Geltungsbereich nach Ausschlüssen leer ist, sagen Sie, welche Dateien ausgeschlossen wurden, und fragen Sie auf die gleiche Weise. Melden Sie niemals eine Überprüfung von Nichts als Genehmigen.

3. Ein Diff ist keine Oberfläche

Eine geänderte Datei ist ein Beweis, nicht das Überprüfungssubjekt. Ihre Schlagradius ist die Menge der Oberflächen, in denen sie gerendert wird; überprüfen Sie diese.

Erweitern Sie den Schlagradius standardmäßig um einen Schritt: die direkten Importeure und Aufrufer. Erweitern Sie einen zweiten Schritt nur für Design-Tokens, Themenwerte und gemeinsame Primitive, wo eine Zeile das gesamte Produkt erreicht.

Überprüfen Sie höchstens fünf Verbraucher, geordnet nach der Regel in der Umfangsermittlung, und geben Sie dann an, wie viele Sie nicht erweitert haben. Ein Sweep ohne Grenze kann die behauptete Abdeckung nicht stützen, und eine nicht genannte Grenze liest sich als Vollständigkeit.

4. Die entfernten Zeilen lesen

Regressionen sind im Zustand nach der Änderung unsichtbar. Lesen Sie die --Seite jedes Hunks gegen Entfernte Signale.

Ein Signal ist ein Hinweis, kein Befund. Eine Entfernung ist nur dann eine Regression, wenn nichts in der Änderung sie ersetzt, und die Domänen-Skill besitzt dieses Urteil. Leiten Sie jede nicht zugeordnete Entfernung an ihren Besitzer weiter, melden Sie nur das, was diese Skill bestätigt, und setzen Sie den Status auf Regression. Das sagt dem Autor, dass er etwas kaputt gemacht hat, was funktioniert hat, anstatt einen neuen Fehler gemacht zu haben.

5. Jeden Befund klassifizieren

Geben Sie jedem Befund einen Status:

• Eingeführt: Die Änderung hat ihn erstellt.
• Regression: Die Änderung hat etwas zuvor Korrektes geschwächt.
• Bereits vorhanden: Im berührten Code vorhanden, aber nicht durch diese Änderung verursacht.

Status nach dem, was der Diff berührt hat, nicht nach der Datei, in der er sitzt: Eine Zeile, die die Änderung nie berührt hat, ist Bereits vorhanden, selbst drei Zeilen von einem Hunk entfernt. Bestätigen Sie gegen den Basis-Ref, wenn es darauf ankommt:

git blame -L <Zeile>,<Zeile> "$BASE" -- Pfad/zur/Datei

Übergeben Sie jeden Befund mit seinem angehängten Status und lassen Sie better-interface seine Obergrenzen- und Urteilsregeln anwenden.

6. Die Änderung an ihrer erklärten Absicht messen

Lesen Sie den Titel und den Text des Pull Requests, das verknüpfte Issue und die Commit-Nachrichten, und überprüfen Sie dann, ob die Oberfläche das liefert, was sie behaupten.

Dadurch wird die unvollständige Änderung sichtbar. Eine Oberflächenüberprüfung kann sie nicht sehen, weil sie die vorhandenen Zustände inspiziert, und hier geht es um diejenigen, die fehlen:

• Eine neue Variante, Größe oder ein neues Thema, das auf einige Zustände angewendet wird, aber nicht auf alle: Hover, Fokus, Aktiv, Deaktiviert, Laden, Ausgewählt.
• Ein neuer benutzerseitiger String ohne Eintrag im Übersetzungskatalog, den das Projekt pflegt.
• Eine neue Komponente ohne leeren, Lade-, Fehler-, deaktivierten oder schmalen Zustand.
• Ein Steuerelement, das zu einer Oberfläche hinzugefügt wurde, aber nicht zu den Geschwistern, die bereits seine Gegenstücke tragen.

Melden Sie keine Scope-Creep. Ob eine Änderung zu viel tut, ist eine Prozessfrage, keine Oberflächenfrage.

7. Die Überprüfung an better-interface übergeben

Übergeben Sie better-interface den Geltungsbereichsblock, die betroffenen Oberflächen und einen Status für jeden Befund. Es leitet an die Domänen-Skills weiter, wendet Schweregrade an, konsolidiert, setzt die Obergrenze durch und gibt das Urteil ab.

Wenn better-interface nicht verfügbar ist, melden Sie den aufgelösten Geltungsbereich und das Dateiinventar, nennen Sie es als fehlende Skill und stoppen Sie. Erfinden Sie keine Schweregradskala, keine Obergrenze und kein Urteil.

8. Niemals den Arbeitsbaum verändern

Eine Änderungsüberprüfung ist schreibgeschützt, einschließlich des Checkouts. Holen Sie Pull-Request-Refs; checken Sie sie niemals aus. git fetch schreibt nur in .git und ist erlaubt. gh pr checkout, git checkout, git switch und git stash überschreiben die Dateien, die der Autor offen hat. Sie scheitern an lokalen Bearbeitungen oder verwerfen sie, daher sind sie niemals erlaubt.

Die gerenderte Überprüfung ist optional. Markieren Sie visuelle und Laufzeitbehauptungen als Nicht überprüft, es sei denn, das Projekt bietet eine kostengünstige Vorschau oder der Benutzer bittet um eine gerenderte Überprüfung. Wenn sie dies tun, verwenden Sie einen isolierten Worktree (git worktree add /tmp/review-<n> refs/remotes/pr/<n>) und entfernen Sie ihn, wenn Sie fertig sind.

Bevor Sie fertig sind

Fehler	Behebung
Eine einzelne versehentliche Bearbeitung anstelle des Branches überprüft	Überprüfen Sie merge-base vor dem Arbeitsbaum und melden Sie beide Zählungen
Der letzte Commit überprüft, weil es keine Änderung gab	Geben Sie die Fakten an und bieten Sie den letzten Commit, ein benanntes Ziel oder ein Repository-Audit an
Hunks überprüft ohne ihre Verbraucher	Erweitern Sie einen Schritt, zwei für Tokens und Primitive, und nennen Sie, was Sie übersprungen haben
Nur die +-Seite des Diffs gelesen	Durchsuchen Sie die --Seite nach entfernten Barrierefreiheits-, Fokus-, Bewegungs- und Textsignalen
Ein äquivalenter Ersatz als Regression gemeldet	Leiten Sie die Entfernung an ihren Besitzer weiter; melden Sie nur das, was sie bestätigt
Eine Entfernung als neuer Fehler gemeldet	Setzen Sie den Status auf Regression, damit der Autor weiß, dass es früher funktioniert hat
Eine Zeile in der Nähe eines Hunks als Eingeführt eingestuft	Status nach dem, was der Diff berührt hat, bestätigt mit git blame gegen den Basis-Ref
Ein Pull Request zum Überprüfen ausgecheckt	Holen Sie den Ref und überprüfen Sie ihn an Ort und Stelle
Zeilennummern genannt, die im überprüften Ref nicht existieren	Zitieren Sie gegen den im Geltungsbereichsblock genannten Head-Ref
Die Schweregradskala oder die Befundobergrenze hier wiederholt	Delegieren Sie an better-interface
Korrektheits-, Test- oder Sicherheitsbefunde im Bericht	Nennen Sie das Anliegen einmal, verweisen Sie auf das Code-Review des Projekts und lassen Sie es fallen

Ausgabeformat der Überprüfung

Beginnen Sie mit dem Geltungsbereichsblock:

Feld	Wert
Ziel	branch, working, staged, pr 482 oder der eingegebene Bereich
Basis-Ref	origin/main bei a1b2c3d
Head-Ref	refs/remotes/pr/482 bei e4f5g6h
Commits	7 committet, 2 Dateien uncommittet
Dateien im Geltungsbereich	12 nach Ausschlüssen
Ausgeschlossen	pnpm-lock.yaml, src/__snapshots__/: Sperrdatei und Snapshots
Erweiterte Oberflächen	CheckoutPage, SettingsPanel; 3 weitere Button-Verbraucher nicht erweitert

Die Abdeckungstabelle folgt unverändert. Eine Domäne ohne Nachweise im Änderungsumfang ist Nicht überprüft: keine Nachweise im Änderungsumfang, was eine Abdeckungsaussage und keine Lücke ist.

Dann die Befunde, mit einer Status-Spalte gemäß Jeden Befund klassifizieren:

Schweregrad	Domäne	Status	Ort	Vorher	Nachher	Grund
HOCH	Barrierefreiheit	Regression	src/Dialog.tsx:42	aria-label="Close" in dieser Änderung entfernt	aria-label="Close" auf dem symbolbasierten Steuerelement wiederherstellen	Das Schließen-Steuerelement hatte vor dieser Änderung einen zugänglichen Namen und hat jetzt keinen mehr

Wenn es keine Eingeführt- oder Regression-Befunde gibt, lassen Sie die Tabelle weg und geben Sie an: "Keine umsetzbaren Oberflächenbefunde in dieser Änderung."

Dann Bereits vorhanden-Befunde, höchstens drei, zuerst den höchsten Schweregrad, klar als nicht die Verantwortung dieser Änderung benannt. Lassen Sie den Abschnitt weg, wenn es keine gibt.

Schweregrad	Domäne	Ort	Problem
MITTEL	Typografie	src/Toolbar.tsx:7	Numerische Badges verwenden proportionale Ziffern; stammt aus der Zeit vor dieser Änderung

Die Obergrenze und das Urteil decken nur Eingeführt und Regression ab. Bereits vorhanden-Befunde liegen außerhalb der Obergrenze, sodass das Berühren einer Legacy-Datei nicht zu einem vollständigen Datei-Audit werden kann. Sie liegen auch außerhalb des Urteils, sodass eine Änderung, deren einzige Befunde bereits vorhanden sind, ein Genehmigen ist.

Enden Sie mit Blockieren, wenn ein HOCH übrig ist, andernfalls mit Genehmigen, und lassen Sie die verbleibenden Befunde in der Tabelle als zu erledigende Arbeit stehen. Wenn better-interface verfügbar ist, stammen die Schweregradskala und die Obergrenze von dort.