Frontend Engineering
Lies anti-ai-writing, bevor du Texte, Kommentare oder Berichte verfasst. Lies die Repository-Anweisungen, vorhandene Bildschirme und Komponenten, Design-Tokens, Framework-/Abhängigkeitsversionen, Routing, Datenverträge und Testkonventionen. Verwende den vorhandenen Stack und die vorhandenen Hilfsprogramme; überprüfe unbekannte APIs anhand der offiziellen Dokumentation dieser Version. Bewahre nicht verwandte Arbeiten und etabliertes Produktverhalten.
Aufgabe des Bildschirms und Design festlegen
Identifiziere die Zielgruppe, die Benutzeraufgabe, die primäre Aktion, die Inhalt hierarchie, die erforderlichen Zustände und die Akzeptanzkriterien. Verwende zuerst die bereitgestellten Designs und vorhandenen Produktmuster. Kläre bei umfangreichen neuen Schnittstellen die daraus resultierenden fehlenden Anforderungen und verwende agent-planning, wenn ein Plan hilfreich ist. Erfordere keine Designzeremonie für eine kleine, verstandene Änderung.
Wenn eine neue visuelle Richtung benötigt wird, studiere relevante Referenzen und übersetze deren nützliche Hierarchie, Dichte, Navigation und Interaktionsprinzipien in die eigene Sprache des Produkts. Kopiere kein proprietäres Branding, keine Texte, keine Assets oder genauen Layouts. Halte genügend Designentscheidungen fest, um die Implementierung zu leiten, ohne ein komplettes Designsystem für einen einzigen Bildschirm zu erfinden.
Verwende kohärente Typografie, Abstände, Farben, Radien und Betonungen aus den Projekt-Tokens. Priorisiere die Aktion und Information des Benutzers, anstatt standardmäßig generische Hero-Bereiche, einheitliche Karten, überdimensionierte Abstände oder dekorative Verläufe zu verwenden. Diese Muster können angemessen sein, wenn das Produkt sie erfordert; verhänge keine ästhetischen Verbote. Verwende realistische Inhalte, einschließlich langer Bezeichnungen und spärlicher/dichter Daten. Entferne nicht verwandte Implementierungsdetails aus Produkttexten. Halte alle exponierten Steuerelemente funktionsfähig oder klar als nicht verfügbar gekennzeichnet; tarne niemals einen Platzhalter als funktionierendes Feature.
Klare Komponenten und Zustände implementieren
Bei geänderten Frontend/Backend-Verträgen verwende api-design und bewahre unterstützte Konsumenten. Leite keinen Backend-Vertrag aus UI-Fixtures ab.
Verwende writing-clean-simple-code für fokussierte Verantwortlichkeiten und gerechtfertigte Abstraktionen. Bevorzuge Komposition und etablierte Komponenten-APIs gegenüber einer großen Matrix nicht verwandter Flags. Teile nach Verantwortung auf, nicht nach willkürlichen Zeilenanzahlen. Halte Daten- und Präsentationsverantwortung klar, ohne für jede Komponente einen separaten Container oder Hook zu erzwingen.
Platziere den Zustand dort, wo er hingehört: lokaler Interaktionszustand, gemeinsamer Zustand, URL-Zustand für navigierbare/teilbare Ansichten und vorhandene Server-Zustands-Tools für entfernte Daten. Vermeide doppelte abgeleitete Zustände und widersprüchliche Booleans. Führe keinen globalen Store nur ein, um ein paar Props zu vermeiden. Bewahre stabile Elementidentität, Verlaufsnavigation, Deep Links und Framework-Rendering/Hydratationsverträge, wo relevant.
Behandle die entsprechenden Lade-, Leer-, Erfolgs-, Fehler-, Deaktiviert-, Ausstehend-, und Berechtigungszustände. Unterscheide zwischen keinen Daten und herausgefilterten Ergebnissen. Bewahre eingegebene Daten nach behebbaren Fehlern, erkläre, wie fortzufahren ist, und verhindere doppelte Übermittlungen. Berücksichtige bei optimistischen Aktualisierungen Fehler, gleichzeitige Änderungen, veraltete Antworten und Abgleich. Verfolge die Abbruchverantwortung, bevor gemeinsame Anfragen abgebrochen werden. Verwende keine versteckten Steuerelemente als Autorisierung; die serverseitige Durchsetzung bleibt erforderlich.
Layout und Interaktion inklusiv gestalten
Lies accessibility and responsive checks. Bevorzuge natives semantisches HTML und getestete barrierefreie Grundelemente. Benutzerdefinierte Interaktion muss ihren vollständigen Tastatur-, Fokus- und Zustandsvertrag implementieren. Beschriftungen, Fehler und Statusrückmeldungen sollten verständlich sein, ohne sich auf Farbe oder Animation zu verlassen.
Wähle Breakpoints dort, wo der Inhalt sie benötigt, und respektiere vorhandene Layout-Tokens. Verwende flexible Layouts, angemessene Breitenbegrenzungen und responsive Assets. Überprüfe schmale und breite Ansichten, Zoom, lange Texte, leere Zustände und Überlauf. Bewahre sinnvolle Inhalte und Aktionen auf kleinen Bildschirmen, anstatt sie zu verstecken, um auf einen Screenshot zu passen.
Sicherheit und Leistung bewahren
Behandle entfernte Inhalte und URLs als nicht vertrauenswürdig. Verwende frameworksicheres Rendering; bereinige nur durch geprüfte Mechanismen, wenn reichhaltiges HTML erforderlich ist. Gib keine Geheimnisse oder privaten Datensätze in Client-Bundles, Telemetrie oder Fehlermeldungen preis. Begrenze zwischengespeicherte Daten auf Identität/Mandant und lösche oder invalidiere sie bei relevanten Kontextänderungen.
Vermeide unnötige Fetch-Wasserfälle, teure wiederholte Arbeit, überdimensionierte Abhängigkeiten und Layout-Verschiebungen. Verwende die Asset-, Rendering- und Ladekonventionen des Frameworks. Optimiere auf der Grundlage gemessener Beweise und Produktbudgets; füge Memoisierung, Virtualisierung oder Code-Splitting nicht mechanisch hinzu. Laborergebnisse und Feldleistung sind unterschiedliche Nachweise und sollten getrennt gemeldet werden.
Das gerenderte Ergebnis überprüfen
Verwende test-authoring für die verhaltensorientierte Abdeckung. Führe relevante Repository-Prüfungen durch und inspiziere die Anwendung in einem verfügbaren Browser mit realistischen Daten. Übe betroffene Aktionen und Zustandsübergänge, Tastaturnavigation, Fokus, Validierung, responsives Layout und relevante Browserziele. Untersuche Konsolen- und Netzwerkfehler, die für die Änderung relevant sind. Screenshots etablieren das Erscheinungsbild, nicht die Korrektheit der Interaktion; automatisierte Barrierefreiheits-Scans etablieren keine Konformität.
Vergleiche die gerenderte Ausgabe mit akzeptierten Designs oder den etablierten Bildschirmen des Projekts. Behebe entdeckte Probleme mit Abschneiden, Abständen, Kontrast oder Interaktion und überprüfe die betroffenen Zustände erneut. Führe keine destruktiven Live-Aktionen nur zur Überprüfung einer UI aus; verwende sichere Fixtures oder eine autorisierte Testumgebung. Wenn Browserzugriff nicht verfügbar ist, gib genau an, was unverifiziert bleibt, anstatt die Schnittstelle als visuell validiert zu bezeichnen.
Melde tatsächliche Änderungen, getestete Abläufe/Viewports und wesentliche Einschränkungen. Verwende code-review, wenn eine unabhängige Überprüfung gerechtfertigt, verfügbar und autorisiert ist. Commit, Push und Veröffentlichung verwenden autorisiertes git-delivery.