cucuwang/visual-fix

Visual Fix

Verwandeln Sie ein sichtbares UI-Problem in eine lokalisierte, genehmigte und verifizierte Codeänderung.

Unterstützte Beweise

Akzeptieren Sie jede sinnvolle Kombination von:

• Einem aktuellen Screenshot der Benutzeroberfläche
• Einem annotierten oder beschriebenen Bereich in einem Screenshot
• Einem aktuellen und einem Ziel-Screenshot mit identifizierten Rollen
• Einem Pfad, Viewport, Komponentennamen, sichtbaren String, Selektor oder Test-ID
• Einer einfachen Symptombeschreibung wie „diese Karte wird abgeschnitten" oder „diese Steuerelemente sind nicht ausgerichtet"

Fragen Sie nur nach Beweisen, die eine zuverlässige Lokalisierung blockieren. Ein Pfad plus ein eindeutiger sichtbarer String kann ohne Screenshot ausreichen. Ein Screenshot mit wiederholten Komponenten benötigt möglicherweise dennoch einen Pfad, ein Label oder einen Zustand.

Behandeln Sie jeweils nur ein visuelles Problem. Teilen Sie nicht zusammenhängende Symptome in separate Korrekturen auf.

Workflow

1. Ziel festlegen

Formulieren Sie das abgegrenzte Ergebnis in konkreten Begriffen:

• Was jetzt falsch aussieht
• Was der Benutzer erwartet zu sehen
• Welcher Pfad, Komponente, Zustand und Viewport relevant sind (falls bekannt)
• Welcher sichtbare Anker das Ziel identifiziert

Wenn das gewünschte Ergebnis subjektiv ist oder mehrere Elemente betreffen könnte, stellen Sie die kleinste Frage, die sie unterscheidet.

2. Unveränderliche Baseline einrichten

Vor dem Bearbeiten:

• Finden Sie die Repository-Anweisungen und die Quelle der Wahrheit.
• Überprüfen Sie den Worktree-Status und bewahren Sie vorhandene Benutzeränderungen.
• Identifizieren Sie das Framework, den Routeneintrag, die Komponentenhierarchie, das Styling-System und verfügbare Ausführungs- oder Testbefehle.
• Reproduzieren Sie den Zielpfad und Viewport, wenn die Umgebung dies zulässt.
• Erfassen oder dokumentieren Sie den aktuellen Zustand, bevor Sie ihn ändern.

Bearbeiten Sie keine generierten Ausgaben, wenn eine gepflegte Quelldatei existiert. Bereinigen oder überschreiben Sie keine nicht zusammenhängenden Worktree-Änderungen.

Melden Sie die Baseline kurz:

Kontext
- Pfad/Zustand: /catalog, Filter geöffnet
- Viewport: 390 x 844
- Quelle der Wahrheit: src/routes/catalog.tsx + src/styles/catalog.css
- Vorhandene Benutzeränderungen: keine
- Reproduktion: verfügbar

3. Gerenderte Quelle lokalisieren

Verfolgen Sie Beweise vom gerenderten Element zurück zur gepflegten Quelle. Verwenden Sie den Pfad, zugänglichen Namen, sichtbaren Text, DOM-Selektor, Komponentennamen, Test-ID, Klasse, Style-Token oder Screenshot-Geometrie. Lesen Sie references/locating.md, wenn mehrere Dateien oder Stilebenen betroffen sind.

Identifizieren Sie einen primären Quellspeicherort und höchstens zwei erforderliche verwandte Speicherorte. Datei- und Zeilenbeweise müssen aus dem aktuellen Worktree stammen.

Lokalisiert
- Primär: src/components/ProductGrid.tsx:42, ProductGrid
- Zugehörig: src/styles/products.css:18
- Beweis: `.grid` steuert den wiederholten horizontalen Abstand, der zwischen den Karten sichtbar ist
- Sicherheit: hoch

Wenn zwei ähnliche Elemente plausibel bleiben, erklären Sie die unterscheidenden Beweise und stoppen Sie zur Klärung.

4. Diagnose aus Beweisen

Verbinden Sie das sichtbare Symptom mit dem tatsächlichen Code. Bevorzugen Sie eine unterstützte Ursache. Bieten Sie zwei oder drei Hypothesen nur an, wenn die Beweise mehrdeutig bleiben.

Fügen Sie für jede Hypothese ein:

• Die beteiligte Eigenschaft, den Selektor, Token oder die Komponente
• Den Code oder sichtbaren Nachweis, der sie stützt
• Die beabsichtigte Korrekturrichtung
• Eine Beobachtung, die sie widerlegen würde

Erfinden Sie keine CSS-Werte aus dem Screenshot. Überprüfen Sie zuerst den aktuellen Wert und das umgebende Design-System.

5. Genauen Änderungsplan vorlegen

Zeigen Sie den vorgeschlagenen Patch vor der Bearbeitung:

Änderungsplan
- Dateien: src/components/ProductGrid.tsx:42
- Aktuell: gap: 8px
- Vorgeschlagen: bestehenden space-4-Token verwenden (16px)
- Umfang: ProductGrid auf /catalog und /search
- Erhalten: Kartenabstände, mobile Spaltenanzahl, nicht zusammenhängende Routen
- Verifikation: gezielter Test, Lint, Screenshots bei 390 x 844 und 1280 x 800
- Risiko: mittel; die Komponente wird von zwei Routen gemeinsam genutzt

Warten Sie auf explizite Genehmigung dieses Plans. Die Wahl einer Diagnose genehmigt keine Codeänderung. Wenn der Plan später auf eine andere Datei, Abhängigkeit, Lockdatei, generiertes Artefakt oder Route erweitert wird, legen Sie den überarbeiteten Plan vor und holen Sie erneut die Genehmigung ein.

6. Genehmigten Patch anwenden

Nehmen Sie die kleinste Änderung vor, die den Plan umsetzt. Halten Sie Änderungen innerhalb der genehmigten Dateien und des Umfangs. Überprüfen Sie dann sofort den Diff:

• Führen Sie git diff --check aus, wenn das Projekt Git verwendet.
• Bestätigen Sie, dass der Diff nur die geplante Änderung enthält.
• Bewahren Sie bereits vorhandene Änderungen und vermeiden Sie nicht zusammenhängende Formatierungsänderungen.
• Committen, pushen, installieren Sie keine Abhängigkeiten und ändern Sie keine externen Dienste, sofern nicht gesondert autorisiert.

7. Ergebnis verifizieren

Lesen Sie references/verification.md, bevor Sie den Erfolg behaupten.

Verwenden Sie den stärksten verfügbaren Nachweis:

1. Führen Sie gezielte Tests, Formatierungen, Typprüfungen oder einen Build durch, der für den geänderten Code relevant ist.
2. Rendern Sie denselben Pfad, Zustand und Viewport, der für die Baseline verwendet wurde.
3. Vergleichen Sie optisch den Vorher- und Nachher-Zustand.
4. Überprüfen Sie einen nahegelegenen Viewport oder eine gemeinsame Route, wenn die geänderte Quelle einen größeren Umfang hat.

Melden Sie genau einen Verifikationsstatus:

• Visuell verifiziert, wenn vergleichbare Vorher- und Nachher-Renderbeweise vorliegen
• Statisch verifiziert, wenn Code-Checks bestanden sind, die UI aber nicht gerendert werden konnte
• Kann nicht visuell verifiziert werden, wenn der Umgebung der Pfad, Browser, Fixture oder Startpfad fehlt
• Verifikation fehlgeschlagen mit dem fehlschlagenden Befehl oder der beobachteten Regression

Wenn die Verifikation fehlschlägt, kehren Sie zur Diagnose zurück. Stapeln Sie keine nicht genehmigte zweite Korrektur auf die erste.

Abschlussbericht

Halten Sie die Übergabe kompakt und evidenzbasiert:

Behoben
- Ziel: Kartenabstand im Katalog bei mobiler Breite
- Quelle: src/components/ProductGrid.tsx:42
- Änderung: gap verwendet jetzt space-4
- Verifikation: Visuell verifiziert bei 390 x 844; Unit-Test und Lint bestanden
- Breitere Prüfungen: /search bei 390 x 844 und /catalog bei 1280 x 800

Erwähnen Sie etwaige verbleibende visuelle Unsicherheiten. Beschreiben Sie niemals einen Code-Diff als visuellen Beweis.