Figma zu Frontend-Seite

Was macht Figma zu Frontend-Seite?

Ergebnis und Umfang

Implementiere das ausgewählte Design im bestehenden Projekt und überprüfe das Ergebnis in einem Browser. Eine Figma-URL ist normalerweise ausreichend, um zu beginnen; leite Projektkonventionen aus dem Repository ab. Akzeptiere bereitgestellte Screenshots oder Exporte als Fallback-Nachweise, wenn das Design nicht zugänglich ist.

Benutzeranweisungen haben Vorrang vor diesen Richtlinien. Bewahre bestehende Änderungen und halte die Bearbeitungen im angeforderten Umfang. Identifiziere, ob es sich um eine neue Seite, eine Aktualisierung einer bestehenden Seite, einen Abschnitt oder eine wiederverwendbare Komponente handelt, bevor du Dateien oder Routen auswählst. Verwandle keine Komponente oder lokale Korrektur in eine neue Seite.

Kernbeschränkungen

• Lies den relevanten Repository-Code vor der Bearbeitung. Verwende dessen Framework, Router, Styling, Tokens, Komponenten, Assets und Datenkonventionen, wenn geeignet.
• Übersetze Design-Geometrie in Layout-Regeln. Bevorzuge normalen Fluss, Flex und Grid; verwende absolute Positionierung für tatsächliche Überlappungen, Dekoration oder Overlays. Figma-Gruppen sind Hinweise, keine zwingenden Komponentengrenzen.
• Verwende identische Assets und geeignete zugeordnete Komponenten wieder. Bewahre charakteristische Bilder und Symbole, anstatt sie durch approximative Symbole zu ersetzen. Rendere keinen gesamten interaktiven Abschnitt als Screenshot.
• Implementiere Verhalten, das durch Anforderungen, Prototypen oder bestehendes Produktverhalten unterstützt wird. Leite keine Sticky-Positionierung, Filtersemantik, API-Verträge oder Navigationsziele allein aus dem Erscheinungsbild ab.
• Bewahre semantische Steuerelemente, zugängliche Namen, Tastaturbedienung und angemessenes Fokusverhalten. Schließe Geräte-Chrome wie eine OS-Statusleiste aus, sofern nicht angefordert.
• Behaupte keine visuelle Gleichheit ohne Vergleich der implementierten Zielseite mit dem Design. Melde blockierte oder nicht verifizierte Anforderungen explizit.

CSS-Kompatibilität

• Verwende margin für Abstände zwischen Flex-, Grid- und wiederholten Elementen. Verwende nicht gap, row-gap oder column-gap. Setze Abstände auf eine benannte Item-Klasse; gib dem ersten oder letzten Item eine explizite Modifikator-Klasse, wenn sich sein Margin unterscheidet. Ersetze gap nicht durch Selektoren wie > * + *, :first-child oder :last-child.
• Schreibe Selektoren gegen explizite Komponentenklassen. Vermeide Universalselektoren und Geschwister-Kombinatoren (+, ~) in Styles, die zu WXSS kompiliert werden könnten. Überprüfe die Selektorunterstützung der Zielplattform, bevor du andere Pseudoklassen oder Kombinatoren verwendest; nimm nicht an, dass Browser-CSS-Unterstützung auch WXSS-Unterstützung impliziert.
• Verwende für Masken und fixierte Panels explizite top, right, bottom und left Deklarationen anstelle von inset. Wenn du env(safe-area-inset-*) verwendest, setze einen Plain-Value-Fallback unmittelbar vor die Deklaration, die env() verwendet. Setze box-sizing: border-box, wo feste Breiten und Padding zusammenpassen müssen.
• In Taro H5 kann der integrierte taro-button-core:active-Style einen gedrückten Button grau färben, selbst wenn seine Hover-Klasse deaktiviert ist. Wenn das Design keine Farbänderung bei Druck vorsieht, überschreibe die aktiven Hintergrund- und Textfarben für die spezifischen Button-Klassen, wobei die normalen Farben jedes Buttons erhalten bleiben. Setze Buttons nicht global zurück oder ändere deaktiviertes Styling.

Nachweise und Entscheidungen

Lies design-evidence.md beim Sammeln oder Aktualisieren von Design-Nachweisen. Führe eine prägnante Arbeitszusammenfassung des Ziels, der Projektkonventionen, des Asset-Mappings, der anwendbaren Fähigkeiten und der Ungewissheiten. Kontextnotizen sind für kleine Aufgaben ausreichend; generiere keine Spezifikationsdatei, es sei denn, es ist nützlich oder angefordert.

Klassifiziere Entscheidungen:

• Bestätigt: explizite Benutzeranforderungen, ausgewählte Designeigenschaften, Prototypverhalten oder relevante bestehende Produktverträge.
• Abgeleitet: gewöhnliche Layout-Anpassung, Umbruch und lokale Komponentengrenzen, die mit dem Projekt konsistent sind. Wähle die kleinste vernünftige Implementierung und lege materielle Annahmen offen.
• Unbekannt: fehlende Übermittlungsverträge, mehrdeutige Ziele, widersprüchliche Ziel-Frames oder folgenreiche Geschäftslogik. Untersuche zuerst verfügbare Nachweise; stelle eine gezielte Frage, falls weiterhin erforderlich. Setze die unabhängige Arbeit fort, während du auf eine Antwort wartest.

Ein sichtbares Steuerelement allein begründet noch nicht sein Geschäftsverhalten. Fälsche keine erfolgreichen Übermittlungen, erfinde keine Endpunkte oder ersetze stillschweigend Mock-Verhalten. Verwende Fixtures nur, wenn die Aufgabe oder die bestehende Vorschaukonvention sie unterstützt, und kennzeichne diese Einschränkung.

Ausführung

Befolge Abhängigkeiten, anstatt eine feste Reihenfolge zu wiederholen. Verwende für eine lokale Korrektur noch gültige Nachweise und inspiziere den geänderten Bereich plus betroffenes gemeinsames Verhalten. Unabhängige Repository- und Design-Lesevorgänge können gebündelt werden.

1. Ziel und Projekt identifizieren

Parst den Datei-Schlüssel und die Knoten-ID. Untersuche den Typ, die Abmessungen und den umgebenden Kontext des ausgewählten Knotens. Wenn die Knoten-ID fehlt, inspiziere Kandidaten auf oberster Ebene; wähle nur aus, wenn das Ziel klar ist.

Verwende gezielte Such- und Lesevorgänge, um festzustellen:

• anwendbare Repository-Anweisungen und aktuelle Änderungen;
• Paketmanager, Entwicklungs- und Verifikationsbefehle;
• wahrscheinliche Zieldateien und die nächstgelegene bestehende Implementierung;
• Router, Styling, Tokens, Schriftarten, Viewport/Unit-Handhabung und Komponentenkonventionen;
• bestehende Design-to-Code-Mappings und Assets, falls verfügbar.

Bei der Arbeit an einer bestehenden Seite oder Komponente, bewahre deren Einstiegspunkt. Bei einer neuen Seite, folge der bestehenden Routenfamilie und Parameterkonventionen und überprüfe auf Konflikte. Verwende den Frame-Namen nur als Fallback-Namenshinweis; erzwinge keine generische Detailroute.

2. Ausreichende Design-Nachweise beschaffen

Bevorzuge verfügbare Figma-Tools für Metadaten, Screenshots, Variablen, Komponentenmappings und Assets. Befolge alle erforderlichen toolspezifischen Skill-Voraussetzungen, bevor du diese Tools aufrufst. Wenn der Zugriff fehlschlägt, versuche einen verfügbaren authentifizierten Browser, dann bereitgestellte Screenshots oder Exporte. Verwende keine Websuche als Ersatz für das tatsächliche Design.

Beginne mit dem Ziel-Screenshot und der strukturellen Übersicht, rufe dann Details für relevante Unterbäume ab. Inspiziere Inhalte unter dem Falz. Rufe nicht wiederholt die gesamte Datei oder nicht verwandte Frames ab. Nenne nicht verfügbare Messungen oder Zustände als Ungewissheit, nicht als genaue Fakten.

3. Mappen und implementieren

Ordne das Design in sinnvolle Module zu und wähle bestehende Komponenten aus, wo deren Verhalten und Erscheinungsbild passen. Extrahiere eine Komponente, wenn Wiederverwendung, unabhängiges Verhalten oder Komplexität dies rechtfertigen; teile nicht jeden Wrapper auf oder erstelle ein Designsystem für eine Seite.

Löse Schriftarten und Haupt-Assets frühzeitig auf. Bewahre das Seitenverhältnis der Assets, Transparenz und angemessene Auflösung; verwende Repository-Speicherkonventionen und semantische Dateinamen. Überprüfe, dass Laufzeit-Assets von einem dauerhaften Ort geladen werden, der vom Projekt unterstützt wird.

Leite fließende Größen, maximale Breiten, Umbruch und Breakpoints aus bereitgestellten Varianten und bestehendem Projektverhalten ab. Bei einer einzigen Designgröße implementiere eine konservative Anpassung und unterscheide sie von einem vom Designer festgelegten responsiven Layout. Teste die angeforderte Plattform; erstelle kein nicht angefordertes Desktop- oder Mobile-Redesign.

Überprüfe für Taro-Projekte, die Styles zwischen H5- und Mini-Programm-Builds teilen, sowohl das generierte WXSS als auch das Quell-Stylesheet. Verifiziere Abstände und Drückzustände auf jeder angeforderten Laufzeit, wenn verfügbar.

Aktiviere nur relevante Verhaltenszweige:

• Navigation: verwende etablierte Ziele und Routing-Verhalten.
• Formulare und Sammlungen: verwende bestehende Datenverträge; implementiere erforderliche Validierungs-, Lade-, Leer-, Fehler- und Erfolgszustände.
• Tabs und Filter: stelle die Zustandsverwaltung und Auswahlsemantik aus Nachweisen her. Draft/Commit-Verhalten gilt nur, wenn unterstützt.
• Tabellen: bewahre Ausrichtung und angezeigte Rahmen; sorge für Überlauf, der zum Ziel-Viewport passt.
• Overlays oder Sticky-UI: lies overlays-and-sticky.md.
• Bewegung oder Medien: reproduziere bestätigtes Verhalten und handhabe Lade- und Reduzierte-Bewegung, wo anwendbar.

4. Verifizieren und iterieren

Verwende einen geeigneten laufenden Server oder starte den dokumentierten Entwicklungsbefehl auf einem verfügbaren Port. Verwende eine verfügbare Browser-Automatisierungsoberfläche, bevorzuge den In-App-Browser, wenn geeignet, dann einen authentifizierten externen Browser oder die Browser-Tooling des Projekts. Untersuche die relevante Route oder die vorhandene Komponentenvorschau.

Lies acceptance-checklist.md für visuellen Vergleich, anwendbare Interaktionsprüfungen und Abschlusskriterien. Behebe große strukturelle Unterschiede vor lokaler Feinarbeit. Überprüfe nach jeder Änderung den betroffenen Bereich; führe eine abschließende gesamte Zielprüfung durch.

Führe relevante Repository-Prüfungen durch, inspiziere das endgültige Diff und unterscheide bereits bestehende Fehler von eingeführten. Vermeide das Hinzufügen von Abhängigkeiten oder breiten Refactorings nur zur Durchführung der Verifikation. Bewahre bestehende Serversitzungen und mache den Zustand eines für diese Aufgabe gestarteten Servers beabsichtigt.

Wiederherstellung und Abschluss

Wenn der Zugriff oder die Laufzeitverifikation fehlschlägt, inspiziere den konkreten Fehler und versuche eine verfügbare relevante Alternative. Wiederhole keine unveränderten Fehler ohne neue Nachweise. Setze die Arbeit fort, die unabhängig abgeschlossen werden kann, melde dann den genauen Blocker, was implementiert wurde und was unverifiziert bleibt. Fehlende Tools oder Anmeldeinformationen sind keine Nachweise für erfolgreiche Verifikation.

Schließe ab, wenn das angeforderte Ziel implementiert ist, anwendbare Prüfungen bestanden werden und kein bekannter erforderlicher Fehler verbleibt. Kleinere Rendering-Unterschiede können dokumentiert werden; ungelöste Layout-Fehler, fehlendes erforderliches Verhalten oder blockierte Browser-Prüfungen dürfen nicht als vollständiger Abschluss präsentiert werden.

Berichte prägnant:

• implementiertes Ziel und Einstiegspunkt, einschließlich einer Route nur wenn zutreffend;
• bedeutende Verhaltens- und Komponentenänderungen;
• Vorschauort und tatsächlich durchgeführte Prüfungen;
• materielle Annahmen, ungelöste Unterschiede oder Blocker.