oil-oil/oil-frontend

Oil Frontend

Erst die Benutzeraufgabe, die Geschäftsobjekte und die Datenquelle identifizieren, dann nicht inhaltsrelevante Informationen entfernen. Eine korrekte Zuordnung von Informationen, Zuständen, Code und gemeinsam genutzten Implementierungen aufbauen.

Immer beachten

• Von echten Benutzeraufgaben, Geschäftsobjekten und Ergebnissen ausgehen; sichtbare Inhalte nur so weit erhalten, wie sie zur Identifikation, zum Vergleich, zur Beurteilung, Bedienung oder zum Verständnis des Ergebnisses beitragen.
• Eine Benutzerabsicht wird genau einmal ausgeführt, jede Aktion muss ein echtes Ergebnis liefern; Daten, Operationen, Auslastungszustand und Einreichungsgrenzen müssen konsistent sein. Bei Fehlern das aktuelle Objekt, die Position und bereits eingegebene Inhalte erhalten.
• Bei üblichen Aufgaben an das vorhandene Wissen der Benutzer anknüpfen; Ressourcenübersichten standardmäßig anzeigen, Bearbeitung explizit auslösen, Formulare nur die für die aktuelle Aufgabe notwendigen und zum aktuellen Objekt gehörenden Felder sammeln.
• Symbole, Hervorhebungen und feste Größen müssen stets eine stabile Bedeutung ausdrücken; keine allgemeinen KI-Dekorationen, bedeutungslosen Hervorhebungsrahmen oder nur auf die aktuelle Instanz zugeschnittene Größen zur Hierarchiebildung verwenden.
• Visuelle Anpassungen zuerst an vorhandene Design-Tokens, Komponenten und Dichten des Projekts anlehnen, dann Hierarchie, Abstände, Typografie, Oberflächen und Feedback verbessern; Fallback-Werte aus den Referenzregeln nur verwenden, wenn keine Projektstandards existieren, und diese nicht zu einem neuen Designsystem ausbauen.
• Für dieselben Geschäftsdaten und dieselbe Bedeutung immer nur eine autoritative Quelle vorhalten; Datenflüsse, Elternlayouts und gemeinsam genutzte Implementierungen priorisiert reparieren, nicht an mehreren Stellen im Seitenbereich Flicken anbringen.
• Komponenten, Hooks, Funktionen, Typen, Styles und Tests nach Geschäftszugehörigkeit organisieren; Code einer einzelnen Einheit möglichst nah platzieren, nur bei stabiler, modulübergreifender Wiederverwendung in eine gemeinsame Schicht verschieben.
• Bei komplexer Logik zuerst vorhandene Fähigkeiten und etablierte Bibliotheken des Projekts prüfen; wenn keine geeignete Abhängigkeit vorhanden ist, eine gut gewartete, zum Projekt kompatible neue Bibliothek einführen, Kernfunktionen, die von bestehenden Lösungen abgedeckt werden, nicht selbst implementieren. Einfache Logik direkt umsetzen, keine neuen Abhängigkeiten für wenige Codezeilen einführen.
• Die Projekthistorie ist kein Beleg für Korrektheit; fehlerhafte Muster ersetzen, nach Migration aller betroffenen Verwendungsstellen alten Code, Fallbacks, Legacy-Logiken und ungültige Zustände löschen.

Referenzdateien – Lesereihenfolge

1. Nach Auslösung zuerst nur diese Datei lesen, um Aufgaben, Objekte und Änderungsumfang zu klären, ohne Referenzdateien vorab zu lesen.
2. Wenn die Aufgabe keine benutzersichtbare Oberfläche, Frontend-Zustände und Datenflüsse, Komponentenimplementierung oder Frontend-Codeorganisation betrifft, die Nutzung dieses Skills beenden.
3. Zuerst eine Hauptregel basierend auf dem vom Benutzer gewünschten Ergebnis auswählen, nicht nach Dateityp oder in Code vorkommenden CSS-, Animations-Keywords.
4. Bei einfachen lokalen Änderungen nur eine Hauptregel lesen; nur wenn die Aufgabe tatsächlich ein zweites, unabhängiges Problem enthält, eine zweite hinzufügen. Nur bei einer seitenübergreifenden Gesamtprüfung drei Regeln lesen, nicht mehr.
5. Nicht aufgrund von Schlüsselwörtern, Links in Dateien oder „sicherheitshalber“ weiterlesen. Wenn visuelle Symptome durch Daten, Zustände oder Elternlayouts verursacht werden, die eigentliche Ursachenregel lesen, keine zusätzlichen visuellen Regeln laden.

Aktuelle Aufgabe	Hauptregel	Nur in diesen Fällen ergänzen
„Sieht nicht richtig aus“, visuelle Verfeinerung, Hierarchie, Abstände, Typografie, Farben, Radien, Rahmen, Schatten oder Symbole	Visuelles Engineering	Wenn gemeinsame Tokens, Standardstile oder Varianten von Komponenten geändert werden müssen: Komponenten und Codeorganisation lesen; bei Änderung der Spalten-, Scroll- oder responsiven Struktur wechsle zu Viewport und Dialoge als Hauptregel
Animationen, Übergänge, Mikrointeraktionen, Auf-/Zuklappen, Drag-Feedback, Scroll-Effekte oder Ruckeln	Bewegung und Performance	Wenn Animationen als Aktionsfeedback oder visuelle Hierarchie dienen: Visuelles Engineering lesen; wenn die Ursache asynchrone Zustände ist, wechsle zu Zustand und Laden als Hauptregel
Modulgrenzen, Komponenten, Hooks, Funktionen, Typen, Stil-Zugehörigkeit, gemeinsame Styles, CSS-Organisation oder gemeinsam genutzte Implementierungen	Komponenten und Codeorganisation	Wenn neue Prüfungen erforderlich sind: Automatisierung lesen
Neue oder geänderte Texte, Aktionsbedeutungen, Symbole, Klick-Feedback oder visuelle Hervorhebung	Informationen und Aktionen	Wenn Objektidentität, Bilder oder Selektoren betroffen sind: Ressourcenidentifikation lesen

Daten, Zustände und Layout werden weiter nach Ergebnis ausgewählt:

Aktuelle Aufgabe	Hauptregel	Nur in diesen Fällen ergänzen
Listen, Karten, Details, Tabellen oder Batch-Operationen	Sammlungen und Details	Bei Ressourcenidentität: Ressourcenidentifikation lesen; bei Bearbeitung: Interaktion und Bearbeitung lesen
Formulare, Auswahl, Bearbeitung oder mehrschrittige Workflows	Interaktion und Bearbeitung	Wenn Speicherbereich und Prozesskontinuität betroffen sind: Daten- und Operationsbereich lesen
Abfrageergebnisse, Paginierung, Kandidatensets, Speicherbereich, Batch-Bereich oder Zugehörigkeit von Anforderungsergebnissen	Daten- und Operationsbereich	Wenn gleichzeitig Darstellungen von loading, refreshing, empty, error oder processing geändert werden: Zustand und Laden lesen
loading, refreshing, empty, filtered-empty, error, queued, processing oder Skeletons	Zustand und Laden	Wenn gleichzeitig Abfrage-Momentaufnahmen, Operationsbereiche oder Zugehörigkeit von Ergebnissen betroffen sind: Daten- und Operationsbereich lesen
Änderung von Seitengröße, Spalten, Scrollen, Dialogstruktur oder responsivem Verhalten	Viewport und Dialoge	Wenn Dropdowns, Menüs, Tooltips etc. als auslösergebundene Overlays betroffen sind: Overlay lesen

In folgenden Fällen kein zusätzliches Lesen auslösen:

• Das Vorhandensein von Tailwind, CSS, transition oder Animationsbibliotheken im Code bedeutet nicht, dass die Aufgabe visuell oder bewegungsbezogen ist.
• Bei Änderung sichtbarer Attribute wie Farben, Abstände, Rahmen, Schatten, Typografie ist die Hauptregel Visuelles Engineering; nur wenn die Aufgabe gleichzeitig eine Anpassung der Stil-Zugehörigkeit, des gemeinsamen Nutzungsmusters oder der Modulgrenzen erfordert, die Komponenten- und Codeorganisationsregel ergänzen.
• Nur Farbvariablennamen, Klassennamen, Typen oder Importfehler korrigieren, ohne das visuelle Ergebnis zu ändern: Keine visuellen Engineering-Regeln lesen.
• Für bestehende Animationen nur Geschäftszustände, Ereignisbindungen oder Datenquellen ändern, ohne Bewegungsart oder Performance zu verändern: Keine Bewegungsregeln lesen.
• Nur bestehende Steuerelemente verschieben, ohne Texte, Aktionsbedeutungen oder Feedback zu ändern: Keine Informations- und Aktionsregeln lesen.
• Nur normale Eltern-Kind-Container-Zugehörigkeit anpassen, ohne Größe, Scrollen, Dialoge oder responsives Verhalten zu ändern: Keine Viewport- und Dialogregeln lesen.
• Links in Referenzdateien zeigen nur die Position der zugehörigen Regeln an, sie bedeuten nicht, dass diese zwingend gelesen werden müssen.

Kurzglossar

Die Kernbegriffe dieser Datei und der Referenzregeln sind wie folgt zu verstehen:

• Ressourcenidentität: Die kleinste Informationskombination, die es dem Benutzer ermöglicht, „welches Objekt ist das“ zu erkennen – Bild + Name + ein Unterscheidungsfeld. Beispiel: Mitgliederliste zeigt „Avatar + Name + Abteilung“, nicht „UUID + Typlabel“.
• Pseudo-Operation: Ein Steuerelement, das scheinbar nutzbar ist, aber kein echtes Ergebnis liefert. Beispiel: „Speichern“ ändert nur den lokalen state, nach Aktualisierung ist er verloren; ein permanent disabled-Löschbutton als Platzhalter.
• Visueller Flicken für einzelne Komponenten: An einer Stelle, die eine gemeinsam genutzte Komponente verwendet, dieser einen spezifischen Stil verpassen. Beispiel: <Dialog className="h-[640px]">, !important-Override, seitenexklusive Selektoren, die in die Komponente hineinregeln. Korrekt wäre, die gemeinsame Komponente selbst zu reparieren oder eine nach Verwendungszweck benannte Variante zu erstellen.
• Nach Verwendungszweck benannte Komponentenvariante (variant): Nach dem „warum anders“ benennen. Beispiel: variant="destructive", size="compact" sind akzeptabel; variant="blue", variant="userListPage" sind es nicht.
• Hauptaktion: Die eine Aktion in einer aktuellen Seite, einem Dialog oder einem Bedienbereich, die die Hauptaufgabe erledigt. In einem Bereich maximal ein stark hervorgehobener Button.
• Einreichungsgrenze: Wann eine Änderung tatsächlich wirksam wird – sofort, automatisch gespeichert, explizit gemeinsam eingereicht oder nur temporäre Vorschau.
• Auslastungsbereich: Der kleinste Bereich, der während einer laufenden Anfrage vor wiederholten Aktionen geschützt werden muss. Nur das einzelne Element sperren, keinen Vollbild-Overlay.
• Übermittelte Abfrage-Momentaufnahme: Die durch eine gemeinsame Antwort bestimmten Abfragekriterien, Liste, Ergebnisanzahl und Paginierungsinformationen. Vor Abschluss einer neuen Abfrage gehört die alte Momentaufnahme weiterhin zu den alten Kriterien.
• Gleichartige Batch-Aufgabe: Aufgabe, bei der für eine Gruppe gleichartiger Objekte wiederholt dasselbe Feld ausgefüllt wird, z. B. Batch-Terminierung, Batch-Preisänderung.
• Bearbeitbares Arbeitsblatt: Eine Tabelle, die für gleichartige Batch-Aufgaben mehrere Zeilen durchgehend im Bearbeitungszustand hält. Im Gegensatz zur Ressourcenliste: Standardmäßig anzeigen, Bearbeitung explizit auslösen.

Entscheidungsreihenfolge

Vor Änderungen nacheinander beantworten.

Aufgabe und Objekte:

1. Welche Aufgabe möchte der Benutzer aktuell erledigen, welches Ergebnis signalisiert Fertigstellung?
2. Welches Kernobjekt verwaltet die Seite, welche Felder gehören zu wem?
3. Handelt es sich um Durchsuchen, Vergleichen, Auswählen oder Bearbeiten? Werden vertraute Strukturen und Begriffe verwendet?

Daten und Bereich:

4. Stammen die Daten aus der vollständigen Sammlung, der aktuell sichtbaren Sammlung oder einem Suchergebnis?
5. Welchen Bereich betreffen Aktion, Auslastungszustand und Einreichungsgrenze? Gehören die Remote-Abfragekriterien und die aktuelle Liste bereits zum selben übermittelten Ergebnis?
6. Anhand welcher Informationen unterscheidet der Benutzer benachbarte Objekte?
7. Können Texte, Schritte, Bestätigungen, wiederholte Eingaben oder bereits vom System bekannte Felder entfernt werden?
8. Welche Informationen gehören zur Sammlung, welche nur zum Detail?

Struktur und Zustände:

9. Was ist die Hauptaktion in der aktuellen Seite, dem Dialog oder dem Bedienbereich?
10. Wer ist für den ersten Bildschirm, den Scroll-Container und die Overlay-Grenzen verantwortlich?
11. Wie schließen sich loading, empty, filtered-empty, queued, processing, error, ready gegenseitig aus?

Visuelle Aspekte und Bewegung, nur beantworten, wenn die Aufgabe dies erfordert:

12. Welche Tokens, Komponenten und benachbarten Seiten definieren im aktuellen Projekt Hierarchie, Dichte und Bewegungssprache? Welche sichtbare Eigenschaft ist tatsächlich inkonsistent?
13. Dient die Bewegung dem Feedback, der Erklärung räumlicher Beziehungen oder der Dekoration? Kann sie nur mit transform, opacity oder vorhandenen Komponentenfähigkeiten umgesetzt werden?

Umsetzung:

14. Gibt es bereits korrekt zugeordnete Module, Komponenten, Hooks, Funktionen, Typen, einheitliche Designvariablen oder Styles – was ist die endgültige Quelle, die repariert werden muss (Datenquelle, Elternlayout oder gemeinsam genutzte Implementierung)?

Wenn keine klare Antwort möglich ist, zuerst aufhören, neue Oberflächenelemente hinzuzufügen: dem Benutzer die 1–2 wichtigsten Fragen stellen; falls keine Frage möglich ist, im kleinstmöglichen verifizierbaren Umfang umsetzen und im Output die getroffenen Annahmen deklarieren.

Ausführungsprozess

1. Tatsachen wiederherstellen

• Vorhandene Module, Komponenten, Hooks, Funktionen, Typen, einheitliche Designvariablen und Styles des Projekts durchsuchen, prüfen, ob dieselbe Bedeutung bereits korrekt implementiert ist.
• Alle Seiten und Komponenten identifizieren, die gemeinsame Komponenten verwenden, sowie andere Einstiegspunkte für dieselben Daten.
• Review-Anfragen liefern nur Beweise und Empfehlungen; erst umsetzen, wenn der Benutzer eine Änderung anfordert.

2. Umfang klären

• Kernobjekt, Feldinhaber, Datensammlung, Operationsbereich, Auslastungsbereich und Einreichungsgrenze klären.
• Seitenstrukturprobleme, Standardverhalten von Komponenten, fehlerhafte Seitenverwendung und Datenflussfehler unterscheiden.
• Visuelle Probleme nur die Unterschiede notieren, die auf ein konkretes Element, Attribut, vorhandene Begründung und Code-Stelle verweisen; wenn der korrekte Wert nicht bestimmbar ist, zuerst vorhandene Projekt-Tokens oder benachbarte gleichartige Komponenten verwenden, keine präzisen Werte aus ästhetischem Empfinden erfinden.

3. Zuerst löschen

• Inhalte entfernen, die die Beurteilung nicht beeinflussen, doppelte Zustände, doppelte Einstiegspunkte, doppelte Bestätigungen und visuelle Flicken für einzelne Komponenten.
• Pseudo-Operationen ohne echte Zustandsänderung oder Speichermöglichkeit entfernen.
• Alte Komponenten, alte Funktionen, alte Typen, alte Zustände, Fallbacks, Legacy-Logiken, alte Styles und ungültige Referenzen entfernen, die durch neue Implementierungen ersetzt wurden.

4. Struktur wählen

• Zuerst die etablierte Verwendung gleichartiger Aufgaben und gemeinsamer Container-Komponenten im Projekt prüfen; nur wenn das bestehende Muster dieser Spezifikation entspricht, übernehmen, sonst basierend auf der tatsächlichen Aufgabe neu wählen.
• Je nach Aufgabe (Durchsuchen, Vergleichen, Auswählen, Batch-Konfiguration oder Tiefenbearbeitung) Liste, Tabelle, Arbeitsblatt, Selektor, Dialog oder vollständigen Arbeitsbereich wählen.
• Listen für Identifikation und Vergleich, Details für vollständige Inhalte, Editoren für Änderungen zuständig machen.
• Visuelle Anpassungen in der Reihenfolge „Informationsebene → Raum und Ausrichtung → Typografie → Oberfläche → Steuerelementzustand → Bewegung“ durchführen; stoppen, sobald die vorherige Ebene das Problem löst, keine weiteren dekorativen Ebenen hinzufügen.

5. Die tatsächliche Fehlerursache reparieren

• Priorisiert Datenbereiche, Operationsbereiche, Elternlayouts, Standardverhalten gemeinsamer Komponenten und bedeutungsstabile Komponentenvarianten reparieren.
• Wiederholt auftretende Ressourcenidentitäten, Menüs, Overlays, Ladezustände, Dialoge und Aktionsleisten als gemeinsame Komponenten implementieren.
• Nur abstrahieren, wenn sich Verantwortlichkeit, Ein-/Ausgabe und Verhalten stabil wiederholen; Komponenten nicht aufgrund lokaler struktureller Ähnlichkeit kopieren und keine Allzweck-Komponente durch viele Seiten-Schalter erzeugen.
• Wenn bestehende gemeinsame Komponenten, Funktionen, Styles oder Datenflüsse selbst fehlerhaft sind, im autorisierten Rahmen die tatsächlich fehlerhafte gemeinsame Implementierung direkt reparieren oder ersetzen und alle betroffenen Verwendungsstellen anpassen; keine neuen fehlerhaften Implementierungen hinzufügen, um Altes zu kompatibilisieren.
• Wenn nicht alle betroffenen Stellen im aktuellen Umfang repariert werden können, keine alten Muster weiter ausdehnen; klar berichten, wie viele alte Verwendungsstellen noch bestehen und wie weit die aktuelle Änderung reicht. Nicht behaupten, dass bereits alles vereinheitlicht ist.
• Bei der Reparatur wiederholt prüfbarer Probleme beurteilen, ob das Projekt tatsächlich eine neue Lint-, Test- oder Prüfregel benötigt; falls ja, gemäß Routingtabelle Automatisierung ergänzend lesen und zur Anzahl der ergänzten Regeln hinzuzählen. Kleine Änderungen erfordern keine vorgelagerte Automatisierung.
• Keine irrelevanten Bereiche ändern.

6. Validieren

• Die vorhandenen Typprüfungen, Lint, Tests oder Builds des Projekts ausführen, die für die Änderung relevant sind.
• Einfache lokale Änderungen nur die geänderte Stelle, das direkte Verhalten und die jüngsten Verwendungsstellen prüfen, nicht die vollständige Zustandsmatrix aufspannen.
• Wenn die Änderung gemeinsame Komponenten, Datenbereiche, asynchrone Zustände, Formularabläufe, Scrollen, responsives Verhalten oder mehrere Seiten betrifft: die betroffenen Zustände, Datenbereiche, repräsentativen Viewports und alle Verwendungsstellen prüfen.
• Visuelle Änderungen an echten Inhalten, wichtigsten Zuständen und betroffenen Viewports prüfen; Bewegungsänderungen nur nach Typ auf anwendbare Unterbrechung, Wiederholungsauslösung, Austritt, Entladen oder Scrollverhalten prüfen. Nur bei komplexen Animationen oder echten Ruckelproblemen Performance-Aufzeichnungen verwenden, nicht jeden Übergang zu einem Performance-Spezialthema aufwerten.
• Nur validierte Punkte, nicht validierte Punkte und blockierende Gründe melden.

Unabhängige Selbstprüfung

Nur eine unabhängige Selbstprüfung ohne Kontext durchführen, wenn die Frontend-Überprüfung mehrere Seiten, alle Verwendungsstellen gemeinsamer Komponenten, mehrere Viewports oder Zustände oder eine großflächige Regelanpassung umfasst. Einzelne Seiten, einzelne Komponenten, einzelne Screenshots und lokale Abweichungen prüft der Haupt-Agent direkt.

Die unabhängige Selbstprüfung erhält nur das Prüfobjekt, den Umfang und oil-frontend, keine Gesprächshistorie, vorgefassten Schlussfolgerungen, Fragenvermutungen, erwarteten Antworten oder Reparaturvorschläge.

Ausgabeanforderungen

Zuerst die Schlussfolgerung, dann die Beweise liefern. Nur Folgendes ausgeben:

1. Konkrete Probleme;
2. Zu löschende Inhalte;
3. Korrekte Informations-, Aktions- und Raumstruktur;
4. Zu ändernde Module, gemeinsame Komponenten oder Datenflüsse;
5. Validierte und nicht validierte Punkte.

Beschreibungen wie „bessere Benutzererfahrung“, „moderner“, „intuitiver“, die keine Implementierung anleiten, sind verboten.

Keine eigenständige Erweiterung zu einer umfassenden Barrierefreiheitsprüfung. Bei der UI-Umsetzung native Interaktionselemente verwenden, vorhandene Fokus-, Tastatur-, Label- und ARIA-Verhaltensweisen nicht beeinträchtigen; nur erweitert prüfen, wenn der Benutzer dies explizit verlangt oder die aktuelle Änderung die Aufgabenerfüllung direkt verhindert.