Ixe1/ui-from-image

Auftrag

Behandeln Sie die bereitgestellten Referenzbilder als visuelle Quelle der Wahrheit.

Genauigkeit ist wichtiger als Geschwindigkeit. Hören Sie nicht bei "ungefähr richtig" auf. Die Aufgabe ist nicht abgeschlossen, wenn die Seite einfach nur funktioniert; sie ist abgeschlossen, wenn das gerenderte Ergebnis eine enge visuelle Übereinstimmung darstellt und keine offensichtlichen Abweichungen mehr vorhanden sind.

Bevorzugen Sie mehr Validierungsdurchläufe anstelle von weniger. Wenn eine realistische Chance besteht, dass Text falsch ist, ein Bedienelement zu gedrängt ist, Abstände fragil sind oder ein Layout-Fehler durch einen Viewport verdeckt wird, iterieren Sie weiter.

Beschreiben Sie das Ergebnis nicht als "gut genug", "bereit zur Veröffentlichung" oder ähnlich, es sei denn, alle obligatorischen Validierungs- und Berichtsschritte dieser Fähigkeit sind abgeschlossen und es verbleibt keine bekannte sichtbare Abweichung über eine klar benannte geringfügige Unsicherheit hinaus.

Standard-Ausgabe

Sofern das Repository nicht bereits eine andere Struktur vorgibt, verwenden Sie:

• index.html
• styles.css
• script.js

Wenn Sie ein vorhandenes Frontend/Framework anpassen, folgen Sie der Dateistruktur des Repositorys, während Sie Markup, Styling und Verhalten so sauber trennen, wie es das Framework zulässt.

Betriebsmodus

• Verwenden Sie für eigenständige Arbeiten standardmäßig reines HTML/CSS/JS, es sei denn, die Umgebung enthält bereits ein Styling-System, das der Benutzer beibehalten möchte.
• Verwenden Sie das vorhandene Tailwind/DaisyUI-Setup des Repositorys, falls vorhanden.
• Wenn das Repository bereits ein anderes etabliertes Styling-System hat, führen Sie Tailwind/DaisyUI nicht als konkurrierendes zweites System ein, es sei denn, der Benutzer bittet ausdrücklich darum.
• Wenn Tailwind/DaisyUI bereits verfügbar sind oder ausdrücklich angefordert werden, behandeln Sie sie als Implementierungswerkzeuge und nicht als Design-Autorität. Überschreiben Sie die Standardwerte, wenn der Screenshot abweicht.
• Erzielen Sie zuerst die Fidelität bei den exakten Referenzabmessungen des primären Screenshots.
• Für Desktop-Webseiten arbeiten: Behandeln Sie einen schmalen Mockup- oder POC-Screenshot nicht als endgültige reale Desktop-Breite der Seite. Nach dem Referenzgrößen-Durchlauf passen Sie das Layout bevorzugt an einen echten Desktop-Viewport von etwa 1900px Breite an, wobei Sie etwa 1900px anstelle von 1920px verwenden, um Platz für eine Scrollleiste und normale Browser-Chrome zu schaffen.
• Leiten Sie Tablet-/Mobilverhalten erst ab, nachdem die referenzgrößenbasierte Version visuell nahe ist.
• Wenn der Benutzer einen neueren oder überarbeiteten Screenshot bereitstellt, wird der neueste Screenshot zur Quelle der Wahrheit.

Regeln für hohe Fidelität

• Passen Sie Layout, Abstände, Typografie, Zeilenhöhe, Buchstabenabstand, Farben, Rahmen, Rahmenopazität, Schatten, Farbverläufe, Rahmenradius, Bildzuschnitt/Seitenverhältnis und visuelle Hierarchie so genau wie möglich an.
• Verwenden Sie explizite Werte für Breiten, Höhen, maximale Breiten, Abstände, Ränder, Lücken, Rahmenradius, Schriftgröße, Zeilenhöhe, Buchstabenabstand und Schatten, wenn die Standardwerte nicht nahe genug sind.
• Behandeln Sie Texttreue sowohl als Layout- als auch als Inhaltsproblem. Wenn Text abgeschnitten, überfüllt, abgeschnitten, falsch umbrochen ist oder nahegelegene Bedienelemente aus der Ausrichtung bringt, ist die Seite nicht fertig.
• Behandeln Sie jedes sichtbare Detail als erforderlich, einschließlich Mikro-Details:
  • kleine Logos und Schaltflächensymbole
  • Suchsymbole
  • Dropdown-Carets
  • Paginierungspfeile
  • aktive Nav-Unterstreichungen/Leuchteffekte
  • Statuspunkte
  • Aufzählungspunktfarben
  • Kartensymbole
  • Stern-/Favoritensymbole
  • Trennlinien
  • subtile Unterschiede im Eckradius
  • Textopazitätsänderungen
• Das Fehlen eines kleinen Symbols oder Logos in einem Bedienelement ist ein Fidelitätsfehler, keine geringfügige Auslassung.
• Entwerfen Sie die Benutzeroberfläche nicht neu, vereinfachen Sie sie nicht, verzieren Sie sie nicht und "verbessern" Sie sie nicht, es sei denn, dies ist für die Reaktionsfähigkeit erforderlich oder die Referenz ist wirklich mehrdeutig.
• Verlassen Sie sich nicht stillschweigend auf DaisyUI-Typografie, Schaltflächenstile, Eingabestile oder Abstandsskalen, wenn diese nicht mit der Referenz übereinstimmen.

Modus zur Anpassung vorhandener Frontends

Wenn Sie innerhalb eines vorhandenen Frontends oder Designsystems arbeiten:

• Überprüfen Sie die aktuelle Codebasis, bevor Sie neue Strukturen erstellen.
• Verwenden Sie vorhandene Layout-Shells, gemeinsam genutzte Komponenten, Dienstprogrammmuster, Typografie-Tokens, Abstandsskalen, Haltepunkte, Symbolkonventionen und Themenvariablen, wo immer sie die Referenz originalgetreu ausdrücken können.
• Bevorzugen Sie die Anpassung einer nahegelegenen vorhandenen Seite oder eines Abschnitts gegenüber der Erstellung einer parallelen Implementierung von Grund auf.
• Führen Sie keine doppelten Komponenten, widersprüchlichen Design-Tokens oder ein zweites Styling-System ein, es sei denn, der Benutzer bittet ausdrücklich darum.
• Wenn der Screenshot mit dem etablierten Designsystem in Konflikt steht, bewahren Sie die Seitenkomposition des Screenshots, während Sie so konsistent wie möglich mit den aktuellen Tokens/Komponenten bleiben, es sei denn, der Benutzer sagt ausdrücklich, dass der Screenshot die aktuelle Designsprache überschreiben soll.

Referenzaufnahme und Breakpoint-Handhabung

• Notieren Sie die genauen Abmessungen jedes Referenzbildes, bevor Sie mit dem Codieren beginnen.
• Rendern Sie die Seite nach Möglichkeit bei der exakten Referenz-Viewportgröße in CSS-Pixeln.
• Wenn das Desktop-Referenzbild erheblich schmaler ist als ein moderner Desktop-Viewport, behandeln Sie diese Breite als Kompositions-/Stilreferenz und nicht als endgültige reale Desktop-Breite der Seite. Bewahren Sie die Struktur, Hierarchie, Abstandsabsicht und visuelle Sprache des Screenshots, erweitern Sie dann die tatsächliche Desktop-Implementierung auf etwa 1900px Viewportbreite und validieren Sie sie.
• Wenn mehrere Referenzbilder für Desktop/Tablet/Mobil bereitgestellt werden, behandeln Sie jedes als maßgeblich für seinen Breakpoint.
• Wenn nur eine Desktop-Referenz existiert, leiten Sie Tablet-/Mobil-Layouts ab, indem Sie Hierarchie, Reihenfolge und visuelles Gleichgewicht bewahren, ohne neue Abschnitte oder Interaktionen zu erfinden.
• Wenn Text lesbar ist, reproduzieren Sie ihn genau, einschließlich Satzzeichen und kleiner Hilfsbeschriftungen.
• Wenn Text unklar ist, verwenden Sie die nächstbeste vernünftige Annäherung und melden Sie die Unsicherheit.
• Wenn der Screenshot einen beschnittenen Bereich einer Seite zeigt und nicht die gesamte Seite, passen Sie zuerst den sichtbaren Bereich an.

Viewport-Ehrlichkeit und Skalierungssicherheit

• Behandeln Sie Browser-Zoom, OS-DPI-Skalierung und Gerätepixelverhältnis als Umgebungsfaktoren, die die Implementierung tolerieren muss, nicht als Ausreden, um das Layout zu verzerren.
• Wenn Playwright oder eine ähnliche Browser-Automatisierung verfügbar ist, behandeln Sie automatisierungsgesteuerte Screenshots, die bei einer expliziten Viewportgröße aufgenommen wurden, als primäre Fidelitätsreferenz für den Vergleich.
• Behandeln Sie ein Browserfenster mit Kopf nicht als Quelle der Wahrheit für Pixelfidelität, wenn OS-DPI-Skalierung, Browser-Zoom, Fenster-Chrome oder Desktop-Compositor-Verhalten beeinflussen können, was der Mensch auf dem Bildschirm sieht.
• Gehen Sie insbesondere unter Windows von nicht standardmäßiger Desktop-Skalierung oder Browser-Zoom aus, die einen Browser mit Kopf visuell irreführend machen können, selbst wenn das zugrunde liegende Seitenlayout in CSS-Pixeln korrekt ist.
• Wenn Playwright meldet, dass es einen chrome- oder msedge-Browser/-Kanal geöffnet hat, handelt es sich immer noch um eine Playwright-gesteuerte Validierung. Beschreiben Sie dies nicht als "Wechsel weg von Playwright", es sei denn, die Browser-Automatisierung wurde tatsächlich aufgegeben.
• Verwenden Sie nicht CSS zoom, transform: scale(...) auf Stammebene, synthetische Wrapper-Skalierung oder ähnliche Viewport-Tricks, um den Implementierungs-Screenshot näher an die Referenz zu bringen.
• "Beheben" Sie nicht Abweichungen bei Breite, Überfüllung oder Position von Abschnitten, indem Sie die gesamte Seite verkleinern oder die Leinwand aufblähen.
• Lösen Sie Screenshot-Abweichungen mit echten Layout-Änderungen:
  • korrekte Container-Breiten
  • korrekte Grid- und Flex-Größen
  • korrekte Lücken und Auffüllungen
  • korrekte Schriftgrößen und Zeilenhöhen
  • korrekte Steuerelementhöhen und intrinsische Breiten
  • korrekte responsive Haltepunkte
• Wenn eine browserspezifische Abweichung auftritt, vermuten Sie zuerst ungültige Layout-Annahmen, Überlauf oder Skalierungstricks in der Implementierung, bevor Sie die Umgebung des Benutzers beschuldigen.
• Wenn es eine Abweichung zwischen einem Browserfenster mit Kopf und einem Playwright-Screenshot gibt, der beim kalibrierten Viewport aufgenommen wurde, vertrauen Sie zuerst dem Screenshot für Fidelitätsarbeiten und untersuchen Sie die Implementierung mit zusätzlichen Screenshot-Durchläufen, bevor Sie die Abweichung dem Rechner des Benutzers zuschreiben.
• Unterscheiden Sie bei der Meldung des Fidelitätsstatus zwischen:
  • erwarteten Reflyß-Unterschieden, die durch Benutzer-/Browser-Zoom-Präferenzen verursacht werden, und
  • echten Layout-Fehlern wie horizontalem Überlauf, falschen Breitenberechnungen, defektem Umbruch oder fragwürdigem Breakpoint-Verhalten.

Preflight-Checkliste

Prüfen und inventarisieren Sie vor der Implementierung explizit:

1. Seitenabschnitte und deren Reihenfolge
2. Grid-/Spaltenstruktur und ungefähre Breitenverhältnisse
3. Große Container und Kartengrenzen
4. Alle Textblöcke und Beschriftungen
5. Alle sichtbaren Bedienelemente und interaktiven Zustände
6. Alle Symbole, Logos, Abzeichen, Chips, Statuspunkte, Trennzeichen und dekorative Markierungen
7. Alle Bild-Assets und Hintergrundgrafiken
8. Typografie-Gruppierungen (Helden-Titel, Fließtext, Pillen, Schaltflächen, Tabellenköpfe, Tabellenzeilen, Seitenkarten, Hinweise usw.)
9. Primäre, sekundäre, dezent aktivierte, Erfolgs-, Warn-, Gefahren- und Akzentfarben
10. Wahrscheinliche responsive Absicht
11. Alle Bereiche, in denen Kopienlänge, Chip-Anzahl oder Steuerelementdichte Überfüllung wahrscheinlich machen
12. Alle Zeilen oder Panels, die beim Referenz-Breakpoint in einer Zeile bleiben müssen

Beginnen Sie nicht mit dem Codieren, bis Sie eine funktionierende mentale Karte jedes visuell bedeutenden Elements haben.

Typografie-Audit

Typografie ist ein erstklassiges Fidelitätsziel.

• Überprüfen Sie zuerst das Repository auf vorhandene Schriftartenquellen:
  • globales CSS
  • Tailwind-Konfiguration
  • DaisyUI-Theme-Konfiguration
  • Design-Tokens
  • vorhandene Seitenkomponenten
  • lokale Schriftartdateien
• Wenn eine vorhandene Projekt-Schriftart mit der Referenz übereinstimmt, verwenden Sie sie.
• Wenn die Referenz eine benutzerdefinierte oder nicht standardmäßige Schriftart zu verwenden scheint und die genaue Schriftart nicht verfügbar ist, wählen Sie die nächstgelegene verfügbare Option und melden Sie diese Einschränkung explizit.
• Verwenden Sie nicht standardmäßig generische DaisyUI/Text-Typografie, ohne zu prüfen.
• Legen Sie die Typografie für jede visuelle Gruppe explizit fest:
  • Logo-Text
  • Navigationslinks
  • Pillen / Abzeichen
  • Helden-Überschrift
  • Einleitender Absatz
  • Statistik-Beschriftungen
  • Statistik-Werte
  • Hilfstext
  • Filter-Chips
  • Formularbeschriftungen
  • Tabellenkopf
  • Tabellenzeilen
  • Seitenleisten-Überschriften
  • Benachrichtigungen / Zeitstempel
  • primäre und sekundäre Schaltflächen
• Überprüfen Sie nicht nur die Schriftfamilie, sondern auch:
  • Größe
  • Gewicht
  • Zeilenhöhe
  • Buchstabenabstand
  • Groß-/Kleinschreibung
  • Farbe / Opazität
• Validieren Sie Textumbruch und Zeilenumbrüche bei der Referenzbreite. Wenn eine Überschrift oder ein Absatz anders umbricht als im Screenshot, beheben Sie es.
• Validieren Sie die Textintegrität für Bedienelemente und dichte UI:
  • keine unbeabsichtigte Abschneidung
  • keine abgeschnittenen Ober-/Unterlängen
  • keine vertikale Stauchung durch falsche Zeilenhöhe oder Steuerelementhöhe
  • keine Kollisionen zwischen Beschriftung und Hilfstext
  • kein Überlauf von Platzhaltertext aus seinem Feld

Symbol- und Vollständigkeits-Audit

Bevor Sie die Seite für fertig erklären, überprüfen Sie, dass jedes visuell bedeutende Symbol oder jede Markierung aus der Referenz im DOM repräsentiert ist.

Dies beinhaltet:

• Logo-Markierungen
• Markensymbole in Schaltflächen
• Suchsymbole
• Dropdown-Carets
• Statistik-Karten-Symbole
• Statusindikatoren
• Karten-/Benachrichtigungspunkte
• Tabellen-Favoriten-Symbole
• Paginierungspfeile
• Schließen-/Zurücksetzen-/Filter-Symbole
• subtile Inline-Symbole

Regeln:

• Kleine UI-Symbole zählen als Assets und dürfen nicht weggelassen werden.
• Bevorzugen Sie vorhandene Repository-Symbole oder einfache Inline-SVGs für kleine UI-Symbole.
• Fügen Sie keine neue Symbolbibliothek hinzu, es sei denn, das Repository verwendet bereits eine oder der Benutzer bittet ausdrücklich darum.
• Verwenden Sie für häufige Markenmarkierungen, die in UI-Steuerelementen verwendet werden (z.B. Discord), ein sauberes Inline-SVG oder eine vorhandene Symbolkomponente, es sei denn, das Repository verfügt bereits über ein geeignetes Asset.

Layout-Anpassungs- und Überfüllungsregeln

Für den Referenz-Breakpoint:

• Erstellen Sie die Komposition des Screenshots nach, bevor Sie responsive Anpassungen vornehmen.
• Lösen Sie Überfüllung nicht durch vorzeitiges Umgestalten, Löschen, Verkleinern oder Reflyßen großer Gruppen.
• Lösen Sie Überfüllung nicht durch Skalieren der gesamten Seite mit CSS oder durch Annahmen über den Browser-Zoom.
• Schöpfen Sie zuerst die fidelitätsbewahrenden Optionen aus:
  • Passen Sie die Referenz-Viewportgröße an
  • Korrigieren Sie Container-Breiten und Seitenbreiten
  • Ziehen Sie Lücken auf die gemessenen Werte an oder lockern Sie sie
  • Verwenden Sie die korrekte Schriftgröße und Zeilenhöhe
  • Verwenden Sie korrekte Steuerelementbreiten und minimale Breiten
  • Verwenden Sie die korrekte Spurbreite für jede Grid-Spalte anstatt alles gleichmäßig zu verteilen
  • Geben Sie dichten Steuerelementen die Breite, die sie tatsächlich benötigen, bevor Sie benachbarte Elemente verkleinern
  • Verwenden Sie Umbruch nur, wo der Screenshot bereits Umbruch impliziert
  • Überprüfen Sie, ob die Referenz tatsächlich mehrere Zeilen verwendet
• Verschieben Sie Steuerelemente nur dann in zusätzliche Zeilen beim Referenz-Breakpoint, wenn:
  • der Screenshot explizit mehrere Zeilen zeigt, oder
  • der Benutzer einen überarbeiteten Screenshot bereitstellt, der die aktualisierte Struktur zeigt.
• Wenn sich Steuerelemente nach einem Durchlauf immer noch überfüllt anfühlen, gehen Sie davon aus, dass die Proportionen immer noch falsch sind, und iterieren Sie weiter. Normalisieren Sie Überfüllung nicht als "gut genug".
• Für schmalere Breakpoints fühlen Sie sauber um, während Sie Hierarchie und visuelles Gleichgewicht bewahren.

Farb-, Oberflächen- und Effekt-Audit

• Passen Sie primäre Oberflächen, sekundäre Oberflächen, dezent aktivierte Oberflächen, Rahmen, Leuchteffekte, Schatten, Farbverläufe und Textopazitäten so genau wie möglich an.
• Entnehmen oder schätzen Sie Farben nach Möglichkeit aus der Referenz, anstatt neue Werte zu erfinden.
• Achten Sie auf:
  • Hintergrundverläufe
  • subtile Rahmen-Alpha
  • Panel-Transparenz
  • Hover/Aktiv-Betonung, die in der Referenz sichtbar ist
  • Kontrastunterschiede zwischen Hauptinhalt und Seitenleistenkarten
  • Akzentfarbkonsistenz über Abzeichen, Live-Indikatoren, Schaltflächen und Hervorhebungen hinweg

Arbeitsablauf für Asset-Behandlung

Inventarisieren Sie zuerst jedes sichtbare Asset, das von der Seite benötigt wird:

• Logos
• Heldenbilder
• Thumbnails / Karten
• Karten
• Avatare
• Symbole
• Illustrationen
• Hintergrundgrafiken
• alle anderen nicht-textuellen visuellen Elemente

Wählen Sie für jedes Asset genau einen Pfad.

1) Vom Benutzer bereitgestelltes Asset

• Überprüfen Sie es vor der Verwendung visuell.
• Verwenden Sie es wo angemessen.
• Beschneiden, skalieren, polstern, trimmen oder maskieren Sie es nach Bedarf, um die Referenzkomposition abzugleichen.
• Bewahren Sie das Seitenverhältnis; verzerren Sie es niemals.
• Verwenden Sie object-fit: cover oder contain je nach Bedarf.
• Wenn das Asset eine niedrige Auflösung hat oder anderweitig unvollkommen ist, kommen Sie so nah wie möglich und notieren Sie die Einschränkung.

2) Asset fehlt und der Benutzer hat nicht gebeten, es zu generieren

• Verwenden Sie einen klar gekennzeichneten Platzhalter mit den korrekten ungefähren Abmessungen, dem Seitenverhältnis, dem Rahmenradius, der Platzierung und dem visuellen Gewicht.
• Wenn Sie selbst ein temporäres Ersatz-Asset erstellen oder synthetisieren, anstatt einen Platzhalter zu verwenden,… [für die Übersetzung abgeschnitten]