Ein Full-Stack-TypeScript-Monorepo ändern und seine LLM-Funktionen nach Bedeutung testen

## Nur die paketbezogenen Befehle und Prüfungen der CI ausführen Ermittle vor jeder Ausführung die im Repository dokumentierten Befehle für Entwicklung, Erstellung, statische Prüfung, Formatierung, Tests, Integrationstests und Bewertungen. Verwende den paketspezifischen Befehl für den betroffenen Arbeitsbereich, statt ihn durch ein Werkzeug für das gesamte Stammverzeichnis zu ersetzen. - Führe einen einzelnen Test über den unterstützten Pfad oder Namensfilter aus. - Führe KI-Bewertungen vom Stammverzeichnis des Repositorys aus mit dem dafür vorgesehenen Bewertungsbefehl des KI-Pakets durch. - Verwende die CI-gerechte Erstellung oder Typprüfung der Anwendung; führe keine nicht unterstützte Typprüfung für das gesamte Stammverzeichnis aus, die unbeteiligte technische Schulden des Monorepositorys offenlegt. - Installiere Abhängigkeiten vor Tests oder Erstellungen nur, wenn sie im Arbeitsbereich noch nicht installiert sind. - Starte weder Entwicklungsserver noch vollständige Erstellungen, sofern die Aufgabe dies nicht ausdrücklich verlangt. Die Prüfung muss zum geänderten Paket und zu den von der CI verwendeten Prüfungen passen. ## Testen, was der Code tut, nicht wie er geschrieben ist Lies den Testleitfaden des Repositorys, bevor du Tests erstellst oder änderst. Nutze bei Fehlerkorrekturen im Kern nach Möglichkeit den Ablauf Rot–Grün–Überarbeitung: Reproduziere zuerst den Fehler, nimm dann die kleinste Korrektur vor und verbessere anschließend die Struktur, ohne das Verhalten zu ändern. Lege Modultests bei den zugehörigen Quelldateien ab. Lege Integrations-, Ende-zu-Ende- und KI-Bewertungstests in den dafür vorgesehenen Testverzeichnisbäumen ab. Verwende die echte Protokollierungsimplementierung, sofern der Test nicht ausdrücklich eine Protokollierergrenze betrifft. Bevorzuge Tests, die eine bedeutsame Verhaltensregression erkennen. Vermeide wenig wertvolle Zusicherungen, die lediglich private Implementierungsdetails wiederholen. Änderungen an Modellanweisungen und Modellverhalten benötigen zusätzlich zu gewöhnlichen Codetests semantische Bewertungen oder Tests eines strukturierten Vertrags. ## Abhängigkeiten im Workspace installieren, der sie nutzt Installiere eine Abhängigkeit in dem Arbeitsbereich, der sie verwendet, nicht im Stammverzeichnis des Monorepositorys. Aktualisiere beim Hinzufügen eines neuen Arbeitsbereichspakets alle Produktions- und lokalen Container-Erstellungsmanifeste, die vor der Installation von Abhängigkeiten Paketmetadaten kopieren. Halte die Umgebungsvariablen in der Beispiel-Umgebungsdatei, im Laufzeitprüfungsmodul und in der Erstellungskonfiguration des Monorepositorys synchron. Versehe Variablen, die für Browsercode sichtbar sind, mit dem dafür vorgesehenen Präfix für öffentliche Variablen des Repositorys. Lies bei versionsabhängigem oder unklarem Verhalten eines Rahmenwerks vor einer Codeänderung die mit der installierten Abhängigkeit gelieferte Dokumentation. Verlasse dich weder auf dein Gedächtnis noch auf die Dokumentation einer anderen installierten Version. ## Direkt aus der definierenden Datei importieren und Typen aus Schemas ableiten Nutze strenge null-Prüfungen und leite TypeScript-Typen aus Prüfungsschemata ab, statt Schnittstellen zu duplizieren. Exportiere keinen Typ, der nur in seiner Definitionsdatei verwendet wird. - Halte jeden Import am Anfang der Datei; füge keine dynamischen Importe in der Dateimitte hinzu. - Importiere aus der ursprünglichen Quelle, statt Wiederausfuhrketten oder Sammeldateien anzulegen. - Importiere einzelne Hilfsfunktionen statt einer vollständigen Hilfsbibliothek. - Verwende für anwendungsinterne Importe den konfigurierten Alias des Projektstammverzeichnisses. - Lege Hilfsfunktionen am Ende einer Datei ab. - Beschränke jede API-Routendatei auf eine Ressource. Direkte Verantwortlichkeit macht Abhängigkeiten, das Entfernen ungenutzter Exporte und die Auswirkungen von Änderungen leichter verständlich. ## Hilfsfunktionen nur auslagern, wenn sie den Code klarer machen Bette Logik standardmäßig direkt an ihrer Verwendungsstelle ein und lege sie dort ab. Kleine doppelte Ausdrücke sind häufig klarer als eine verfrühte Hilfsfunktion. Lagere keine Funktion aus, die Parameter lediglich umbenennt und weiterleitet. Lagere eine Hilfsfunktion aus, wenn sie ein bedeutsames Domänenkonzept benennt, den umgebenden Kontrollfluss leichter lesbar macht oder korrektheitskritisches Verhalten über mehrere Abläufe hinweg konsistent hält. Zentralisiere umfangreiche doppelte Logik frühzeitig, wenn ihre Kopien zur Fehlervermeidung synchron bleiben müssen. Vermeide große oder verschachtelte ternäre Ausdrücke. Bevorzuge einen geradlinigen Kontrollfluss, eine gezielte Hilfsfunktion oder eine Nachschlagetabelle. Erläutere in Kommentaren, warum eine Entscheidung besteht, nicht was selbsterklärender Code tut. Bevorzuge die einfachste lesbare Änderung. Bewahre Abwärtskompatibilität nur, wenn die Anforderung sie verlangt; aktualisiere andernfalls zusammengehörige Aufrufstellen direkt, statt einen ungenutzten Migrationspfad darüberzulegen. ## Personenbezogene Daten aus breiten Log-Stufen heraushalten Wiederhole keine Kontextfelder des Protokollierers, die weiter oben in der Aufrufkette bereits angefügt wurden. Schreibe personenidentifizierende Felder wie Absender, Empfänger oder Nachrichtenbetreff ausschließlich auf der am stärksten eingeschränkten Ablaufverfolgungsstufe des Repositorys. Eine ausdrücklich dokumentierte Ausnahme darf die eigene Kennung des authentifizierten Benutzers auf breiter zugänglichen Stufen zulassen; weite diese Ausnahme jedoch nicht auf Daten Dritter aus. Verwende in Tests den echten Protokollierer, damit Datenschutzfilter, Kontextweitergabe und Formatierung weiterhin geprüft werden. Bestimme vor dem Hinzufügen eines Protokolleintrags seine Zielgruppe, Aufbewahrungsdauer und Vertraulichkeit sowie, ob der vorhandene Kontext den Wert bereits bereitstellt. ## UI-Zustand aus Daten ableiten und gemeinsame Komponenten nutzen Spiegele abgerufene Eigenschaften oder Serverdaten nicht über einen Effekt in den lokalen Zustand. Nutze abgeleitete Werte für schreibgeschützte Ansichten und einen ausdrücklichen Bearbeitungszustand für vom Benutzer gesteuerte Entwürfe. Verwende die freigegebene Komponentenbibliothek des Repositorys, bevor du ein eigenes Grundelement erstellst. Stelle asynchrone Inhalte über die gemeinsame Lade- und Fehlerhülle dar, damit Lade-, Fehler- und Erfolgszustände einheitlich bleiben. Lege routenspezifische Seitenkomponenten neben ihrer Routeneinstiegsdatei ab, ohne verschachtelte Komponentenverzeichnisse hinzuzufügen. Lege seitenübergreifend verwendete Komponenten im gemeinsamen Komponentenverzeichnis der Anwendung ab. ## Datenänderungen über Server-Actions und gemeinsame Validierungsschemas ausführen Wähle die Routen-Middleware nach Zugriffsstufe aus: öffentliche Fehlerbehandlung, Zugriff für authentifizierte Benutzer oder kontobezogener Zugriff. Exportiere Antworttypen, indem du sie aus der Datenfunktion ableitest, statt Antwortschnittstellen zu duplizieren. Nutze für Datenänderungen im Web Serveraktionen über die abgesicherte Aktionsschicht des Repositorys. Reserviere POST-API-Routen für Integrationen, die einen stabilen externen HTTP-Vertrag benötigen, etwa native Clients. Definiere Prüfungsschemata für Datenänderungen in den dafür vorgesehenen Prüfungsmodulen und leite daraus Eingabetypen ab. Nutze für Lesevorgänge den etablierten clientseitigen Zwischenspeicher und mache den betroffenen Schlüssel nach einer Datenänderung ungültig. Erstelle Formulare mit der freigegebenen Formularbibliothek und dem Aktions-Einhängepunkt und leite Fehler an den gemeinsamen Formatierer für Aktionsfehler weiter. Nutze für gewöhnliche Anwendungslogik Anbieterabstraktionen. Prüfe einen konkreten Anbietertyp nur an einer echten Integrationsgrenze. Vermeide rückrufbasierte dynamische Datenbanktransaktionen, wenn das Repository sie verbietet. ## LLM-Funktionen nach Bedeutung testen, nicht mit Stichwortlisten Behebe allgemeine Fehlermuster des Modells, nicht den Wortlaut eines einzelnen Bewertungsfalls. Füge Modellanweisungen, Bewertungen oder Tests keine Schlüsselwort- oder Ausdrucks-Sperrlisten hinzu, nur um die aktuelle Formulierung des Modells zu erfassen; Textprüfungen sind sprachübergreifend besonders anfällig. Prüfe semantische Ergebnisse mit einem Beurteilungskriterium oder strukturierten Vertrag, etwa ob das Modell unnötige Rückfragen oder unbelegte Statusbehauptungen vermeidet. Mache Kontexteinfügung oder Werkzeugverhalten niemals von fallweiser Übereinstimmung mit Benutzertext abhängig. Nutze strukturierten Zustand, Metadaten oder ausdrückliche Ereignisse. Gestalte jede Werkzeugbeschreibung in sich vollständig: Zweck, Bedeutung der Parameter, Auswahlhinweise, Voraussetzungen und werkzeugspezifische Sicherheitsbeschränkungen. Belasse nur bereichsübergreifende Richtlinien zu Identität, Bestätigung, Sicherheit und Formatierung in der Systemanweisung; lege werkzeugspezifische Hinweise in der Werkzeugbeschreibung ab. ## Den Diff prüfen und melden, welche Prüfungen liefen Prüfe vor der Fertigmeldung die endgültige Änderungsübersicht und führe die kleinste CI-gerechte Prüfmenge aus, die das betroffene Verhalten belegt. Erweitere sie um Integrations- oder Bewertungstests, wenn der Vertrag diese Grenzen überschreitet. Bestätige Folgendes: - Jede Abhängigkeit und Umgebungsvariable gehört dem richtigen Arbeitsbereich. - Tests decken das Verhalten ab und neue Testdateien werden erkannt. - Importe, schemabasierte Typen, Hilfsfunktionen und Abstraktionen entsprechen den Repository-Konventionen. - Protokolle erweitern nicht die Offenlegung personenbezogener Daten. - UI-Zustand, Datenänderungen, Prüfung, Zwischenspeicherinvalidierung und Ladezustände nutzen etablierte Muster. - LLM-Verhalten wird semantisch statt anhand anfälliger Formulierungen getestet. - Ohne Genehmigung wurden weder eine nicht unterstützte Prüfung des gesamten Stammverzeichnisses noch ein Entwicklungsserver oder eine vollständige Erstellung ausgeführt. Berichte, welche Prüfungen ausgeführt wurden und welche umfassenderen Prüfungen bewusst außerhalb des Umfangs blieben.