Baue eine TypeScript-App für Native und Web nach den Regeln des Repositorys

## Führe Tests, Lint und Builds über die Skripte des Repositorys aus Behandle das Paketmanifest und die Repository-Skripte als maßgebliche Grundlage für unterstützte Versionen und Befehle. Bevorzuge aktuell unterstützte APIs und ersetze veraltete oder nicht mehr empfohlene Muster, wenn dies im betroffenen Bereich sicher möglich ist. Nutze Skripte der Paketverwaltung für: - den Start des Entwicklungsservers und jeder unterstützten Plattform; - Unit-Tests, Lint-Prüfungen, Typprüfungen und Formatierung; - Web-Builds und die Erzeugung nativer Projekte. Rufe die zugrunde liegenden Werkzeuge für Tests, Lint-Prüfungen, Typprüfungen oder Formatierung niemals direkt auf, wenn Repository-Skripte vorhanden sind. Die Skripte können Konfiguration oder Vorbereitungsschritte bereitstellen, die bei direkten Befehlen fehlen. Führe keine Befehle zur Extraktion oder Kompilierung von Lokalisierungen aus, wenn CI für diese Aufgaben zuständig ist. Ergänze oder aktualisiere übersetzbare Zeichenketten im Quelltext und überlasse die Aktualisierung von Katalogen und Laufzeitübersetzungen der geplanten Verarbeitungskette. Bestimme vor einer Codeänderung die Zielplattformen, das verbindliche Skript für die Prüfung und ob die erzeugten Artefakte lokal oder durch die Automatisierung verwaltet werden. ## Lege neue Bildschirme und Komponenten im richtigen Ordner ab Lege gemeinsam genutzte, plattformneutrale UI-Elemente in `components` ab. Lege Routen für vollständige Seiten in `screens` ab. Nutze `features` für größere Funktionsbereiche, die Kontext, Datenzugriff, Komponenten und Hilfsfunktionen über mehrere Ansichten hinweg verbinden. Erstelle für eine komplexe Ansicht mit privaten Komponenten oder eigenem Zustand ein Ansichtsverzeichnis und lege diese Abhängigkeiten dort gemeinsam ab. Verschiebe Code erst dann in einen gemeinsamen Ordner, wenn mehr als eine nutzende Stelle ihn benötigt. Halte Hooks für den Serverzustand, einfache UI-Einstellungen, Sitzungszustand und Persistenz in klar gegliederten Zustandsmodulen oder lege funktionsspezifischen Zustand bei der nutzenden Stelle ab. Vermeide große Dateien, die nicht zusammengehörige Verantwortungsbereiche vermischen. Nutze `lib` für wiederverwendbare Hilfsfunktionen, API-Clients, Formatierer und Konstanten, die keinem Funktionsbereich zuzuordnen sind. Füge keine neuen Quellverzeichnisse auf oberster Ebene hinzu, wenn der Inhalt bereits in einen etablierten Verantwortungsbereich passt. Füge veralteten Ansichtsverzeichnissen keine neuen Arbeiten hinzu. Bewahre bestehenden Altcode, sofern die Migration nicht Teil der Aufgabe ist, aber lege neue Ansichten, Komponenten und Funktionen in der aktuellen Struktur ab. Verwende PascalCase für Komponentennamen und camelCase für gewöhnliche Dateien, Verzeichnisse, Variablen und Funktionen. Ein umfangreiches Modul kann einen Einstiegspunkt `index.tsx` mit danebenliegenden Komponenten, Hooks und Hilfsfunktionen verwenden; belasse eine kleine Komponente in einer Datei. Lege optionale Funktionsdokumentation und Tests bei größeren Modulen ab. Erläutere in Kommentaren, warum eine Entscheidung besteht, nicht was der Code bereits ausdrückt. Verwende Dokumentationsblöcke für benannte Deklarationen, Blockkommentare für mehrzeilige Erläuterungen und Zeilenkommentare nur für kurze Hinweise. ## Baue die UI mit dem Designsystem und vorhandenen Komponenten Nutze das etablierte Designsystem, bevor du direkte Stildefinitionen oder doppelte Komponenten erstellst. Kombiniere themenunabhängige Atome, Themenatome und ausnahmsweise nötige direkte Stildefinitionen in dieser Reihenfolge: 1. Flexbox- und Layout-Atome; 2. Abstandsatome; 3. Typografie-Atome; 4. Themenfarben und -flächen; 5. eng begrenzte direkte Stildefinitionen. Nutze plattformspezifische Stilhilfen für bedingte Gestaltung und Hooks für Umbruchpunkte bei anpassungsfähigen Layouts. Halte Plattformbedingungen innerhalb der Stilzusammenstellung, statt sie über die Komponentenlogik zu verteilen. Suche vor dem Erstellen eines Steuerelements in der gemeinsamen Komponentenbibliothek nach einer geeigneten Schaltfläche, einem Dialog, Menü, Textfeld oder einer typografischen Basiskomponente. Befolge deren Kompositions-API und die vorhandenen verbindlichen Verwendungsweisen. Für Komponentendeklarationen gilt: - Bevorzuge die Fragment-Kurzsyntax, sofern kein Fragment mit Schlüssel erforderlich ist; - bevorzuge Funktionsdeklarationen; - zerlege Props in der Parameterliste; - gib Prop-Typen direkt in der Deklaration an, solange sie lesbar bleiben; - gib optionalen Props sinnvolle Standardwerte; - halte wiederverwendbare Komponenten möglichst plattformneutral. Nutze nicht kontrollierte Textfelder mit `defaultValue`, wenn die Plattformarchitektur bei kontrollierter Eingabe eine schlechte Leistung zeigt. Nutze kontrollierte Werte nur, wenn das Verhalten sie tatsächlich erfordert. Von Nutzern erzeugter Text kann Emojis enthalten, auch wenn die Beispiele keine zeigen. Aktiviere für Nutzerinhalte die Emoji-sichere Darstellung des Typografiesystems und lasse sie nur bei bekanntem statischem Text weg. ## Mache jeden sichtbaren Text übersetzbar Umschließe jede nutzerseitige Zeichenkette mit dem Übersetzungsmakro oder der Übersetzungskomponente des Projekts. Ergänze Hinweise oder Kontext für Übersetzende, wenn ein Wort mehrere Bedeutungen hat, etwa wenn ein Substantiv und ein Verb gleich geschrieben werden. Nutze den modernen, vom Übersetzungsrahmen unterstützten Makro-Einstiegspunkt. Vergib einen Alias für seine Übersetzungsfunktion, wenn ein anderes Teilsystem, etwa die Themengestaltung, bereits denselben kurzen Variablennamen verwendet. Nutze die Pluralisierungsfunktionen des Übersetzungsrahmens für Mengenangaben und dessen Datumsformatierer für Datums- und Zeitangaben. Die Formatierung des Rahmens muss erneut ausgeführt werden, wenn sich die aktive Sprache ändert; eine direkte Formatierung nach Gebietsschema tut dies häufig nicht. Bevorzuge in nutzerseitigem Text typografisch korrekte Unicode-Zeichen. Wende die Zeichensetzungskonventionen des Projekts einheitlich an, einschließlich Anführungszeichen und Abständen bei Gedankenstrichen. Bearbeite erzeugte Lokalisierungsausgaben nicht manuell und führe keine CI-eigenen Extraktions- oder Kompilierungsaufgaben lokal aus. Änderungen am Quelltext müssen die umschlossenen Nachrichten und ausreichend Kontext für eine genaue Übersetzung enthalten. ## Handhabe Serverdaten, Navigation und plattformspezifische Dateien Nutze für entfernte Daten die etablierte Abfragebibliothek für Serverzustand und für einfache UI-Einstellungen einen kontextbasierten Zustand. Stelle Einstellungen über zusammengehörige Lese- und Aktualisierungs-Hooks bereit. Erstelle Abfrageschlüssel mit der gemeinsamen Schlüsselhilfsfunktion und einem Argumentobjekt. Die Wurzel des Schlüssels muss dem Hook-Namen entsprechen. Verwende einheitliche Namen für Abfrage-Hooks, Mutations-Hooks und Hilfsfunktionen für reine Cache-Mutationen. Wähle Gültigkeitszeiten aus gemeinsamen Konstanten. Nutze für Cursor-Paginierung eine Endlosabfrage, gib den Antwortcursor als Parameter für die nächste Seite zurück und führe Seiten nur an der Nutzungsgrenze zu einer flachen Struktur zusammen. Erhöhe bei einer Strukturänderung persistierter Abfragedaten deren persistierte Version, damit veraltete serialisierte Daten verworfen und neu abgerufen werden. Bei fehlgeschlagenen Mutationen: - Informiere Nutzer über erwartete Netzwerkfehler, ohne sie zusätzlich in Fehlerprotokollen zu duplizieren; - behandle typisierte Protokoll- oder API-Fehler ausdrücklich; - sende unerwartete Fehler mit einer sicheren Meldung an die strukturierte Protokollierung. Nutze typisierte Routenparameter und die Navigationshilfsfunktion oder den Navigations-Hook des Projekts. Halte Routenkonfiguration, Routendefinitionen und Routentypen synchron. Kennzeichne Plattformimplementierungen mit Dateinamensendungen wie `.web`, `.native`, `.ios` und `.android`. Importiere den Pfad des Basismoduls und lasse das Bündelungswerkzeug die Implementierung auswählen. Verwende niemals bedingte Laufzeitimporte, um Plattformdateien auszuwählen. Gruppiere Plattformvarianten möglichst hinter einem einzelnen Modulverzeichnis. Verwende Plattformkennzeichen zur Laufzeit nur für das Verhalten, nicht für die Modulauflösung. Nutze den absoluten Importalias des Repositorys statt weit zurückführender relativer Pfade. ## Vermeide Timing-Fehler beim Schließen von Dialogen und unnötige Memoisierung Führe jede Aktion, die nach dem Schließen eines Dialogs stattfinden muss, innerhalb der Schließrückruffunktion der Dialogsteuerung aus. Wird der Dialog zuerst geschlossen und unmittelbar danach navigiert, eine weitere Überlagerung geöffnet, betroffener Zustand aktualisiert oder eine Rückruffunktion der übergeordneten Komponente aufgerufen, kann dies zu einem Wettlauf mit der Schließanimation führen. Die erforderliche Reihenfolge lautet: 1. Rufe die Schließmethode auf; 2. übergib dieser Methode eine Rückruffunktion; 3. führe Navigation, das Öffnen von Überlagerungen, Zustandsaktualisierungen oder Rückruffunktionen der übergeordneten Komponente darin aus. Beachte plattformspezifische zusammengesetzte Komponenten. Ein Bedienelement eines Dialogs oder ein Element eines Menücontainers kann ausschließlich nativ verfügbar sein, während ein Schließelement oder Menütrenner ausschließlich im Web verfügbar sein kann. Prüfe die Plattformen, die den jeweiligen Zweig ausführen. Füge bei aktivierter automatischer Compiler-Memoisierung nicht vorsorglich `useMemo` oder `useCallback` hinzu. Nutze sie nur bei einer konkreten Anforderung an die Referenzstabilität, etwa durch die Abhängigkeit eines Effekts oder den Vertrag einer Bibliothek außerhalb von React. Opfere Lesbarkeit nicht für spekulative Optimierung. Miss ein tatsächliches Problem oder erfülle eine ausdrückliche Stabilitätsanforderung, bevor du manuelle Memoisierung hinzufügst. ## Teste jede betroffene Plattform, bevor du die Arbeit abschließt Vor dem Abschluss: 1. Bestätige, dass jedes interaktive Element eine barrierefreie Beschriftung und bei Bedarf einen hilfreichen Hinweis besitzt; 2. bestätige, dass alle nutzerseitigen Zeichenketten lokalisiert sind und mehrdeutige Nachrichten Kontext enthalten; 3. prüfe, dass die Gestaltung durchgehend Atome des Designsystems, Themenwerte und Plattformhilfen verwendet; 4. prüfe, dass Serverzustand, UI-Einstellungen und Sitzungszustand ihre vorgesehenen Mechanismen verwenden; 5. bestätige, dass keine vorhandene gemeinsame Komponente dupliziert wurde; 6. bestätige, dass Props und Routenparameter ausdrückliche Typen besitzen; 7. stelle stabile Testkennungen dort bereit, wo End-to-End-Tests sie benötigen; 8. führe die Repository-Skripte für Tests, Lint-Prüfungen, Typprüfungen und Formatierung aus; 9. prüfe alle betroffenen Verhaltensweisen auf nativen Plattformen und im Web. Prüfe die Änderungen auf neue Nutzung veralteter Verzeichnisse, bedingte Plattformimporte, direkte Bearbeitung erzeugter Lokalisierungsdateien, Rückschritte zwischen nicht kontrollierter und kontrollierter Eingabe sowie Wettläufe nach dem Schließen von Dialogen. Melde jede Plattform und jedes verbindliche Skript, die nicht ausgeführt werden konnten, einschließlich der fehlenden Voraussetzung. Behaupte nicht, die plattformübergreifende Prüfung sei abgeschlossen, wenn nur eine Plattform geprüft wurde.