Ein großes TypeScript-Repository zur Bewertung von KI-Modellen ändern und testen

## Entscheiden, ob Review oder Fix, und den nächsten Agenten-Leitfaden lesen Ermitteln Sie zuerst das Stammverzeichnis des Repositorys, das gewünschte Ergebnis und das für die Änderung zuständige Teilsystem. Große Repositorys verteilen die Verantwortung häufig auf Kernbibliothek, CLI, Webanwendung, Persistenzschicht, Anbieter, Zeitplaner, Schemas, Hilfsprogramme, Tests, Dokumentation, Beispiele, Migrationen, Automatisierung und Sicherheitswerkzeuge. Lesen Sie vor der Bearbeitung eines Verzeichnisses die nächstgelegene bereichsspezifische Agentenanleitung und alle aufgabenspezifischen Entwurfs- oder Ablaufdokumente. Lokale Vorgaben können die Stammregeln für Tests, erzeugte Dateien, öffentliche Verträge, Datenbankzugriffe oder Veröffentlichungsverhalten präzisieren. Ordnen Sie die Anfrage ein, bevor Sie handeln: - Eine Prüfung oder ein Audit ist schreibgeschützt. Untersuchen Sie aktuellen Branch, Diff, Kommentare und CI, führen Sie bei Bedarf zustandsneutrale Prüfungen aus und berichten Sie Ergebnisse, ohne Dateien zu committen, zu pushen oder umzuschreiben. - Eine Anfrage zur Korrektur, Verbesserung oder Übernahme umfasst den üblichen Umsetzungszyklus auf einem Funktionsbranch: untersuchen, ändern, prüfen, committen, pushen und die betreffende CI verfolgen. - Eine Verhaltensänderung muss im benutzerseitigen Ablauf nachgewiesen werden, nicht nur durch isolierte Unit-Tests. Arbeiten Sie vom richtigen Stammverzeichnis aus und gleichen Sie Laufzeit- und Paketmanager-Versionen an die Angaben des Repositorys an, bevor Sie einen Fehler als maßgeblich ansehen. Führen Sie in einem frischen Checkout die deterministische Installation der Abhängigkeiten durch, bevor Sie fehlende Module als Codefehler einstufen. Beschränken Sie die Änderung auf das betroffene Teilsystem und dessen direkte Verbraucher. Suchen Sie nach bestehenden Implementierungen, Hilfsprogrammen, Abhängigkeiten und benachbarten Mustern, bevor Sie eine weitere Abstraktion erstellen oder ein Paket hinzufügen. ## Änderungen im echten CLI-, API- oder Browser-Ablauf testen Verwenden Sie die im Repository angegebenen Skripte und Wrapper, statt sie durch einen zufälligen Werkzeugaufruf zu umgehen. Übergeben Sie Befehlsoptionen über das Trennzeichen des Paketstarters, wenn der Wrapper dies verlangt, und führen Sie repositoryweite Bewertungen vom Stammverzeichnis aus. Erweitern Sie den Prüfungsumfang schrittweise: 1. Führen Sie den gezielten Test für das geänderte Modul aus. 2. Führen Sie die betreffenden Typ-, Lint- und Formatprüfungen aus. 3. Führen Sie die betroffene Integrations-Testsuite aus. 4. Durchlaufen Sie mit dem lokalen Build den tatsächlichen CLI-, Beispiel-, API- oder Browserablauf. 5. Führen Sie die umfassendere Testsuite nur aus, wenn Risiko oder Repository-Richtlinie dies rechtfertigen. Deaktivieren Sie bei Bewertungsabläufen die Wiederverwendung von Ergebnissen, statt Caches zu löschen. Exportieren Sie maschinenlesbare Ergebnisse und prüfen Sie für jeden Fall Erfolg, Bewertung, Fehler, Anbieterausgabe, Ablaufspur und Sicherheitsbefunde. Ein Exit-Status von null kann lediglich bedeuten, dass ein Gesamtschwellenwert erreicht wurde; er beweist nicht den Erfolg jedes Falls. Laden Sie eine Umgebungsdatei nur, wenn der Ablauf Zugangsdaten benötigt und die Datei vorhanden ist. Lassen Sie Dienste mit einer aktiven Sitzung verbunden, damit Hintergrundprozesse nicht unbemerkt verschwinden. Bestätigen Sie tatsächlich belegte Ports anhand der Startausgabe oder einer Portprüfung, statt Framework-Vorgaben anzunehmen. Starten Sie keinen statischen Produktionsbetrachter oder weiteren Entwicklungsserver, sofern die Anfrage dies nicht verlangt. Prüfen Sie zuerst, ob der erwartete Dienst bereits läuft. Würde ein Start mit der Sitzung des Benutzers kollidieren, fragen Sie vorher nach. Wenn Dokumentation, Schemas, Migrationen oder Quellenangaben erzeugt werden, verwenden Sie deren maßgebliche Generatoren und prüfen Sie die resultierenden Artefakte. Testen Sie Dokumentation über den unterstützten Schnellpfad des Repositorys, sofern vorhanden, ohne für die Änderung wichtige Prüfungen stillschweigend auszulassen. ## Fehler vor dem Debuggen reproduzieren, ohne Caches oder Daten zu löschen Reproduzieren Sie den Fehler mit denselben Eingaben, demselben Zustand und Ausführungspfad, durch die er sichtbar wurde. Aktivieren Sie strukturierte Debug-Protokollierung, deaktivieren Sie Cache-Lesevorgänge für diesen Lauf und grenzen Sie den Fehler ein, bevor Sie Code ändern. Trennen Sie Umgebungsfehler von Produktfehlern: - Eine abweichende Laufzeit- oder Paketmanager-Version ist ein Umgebungsproblem. - Eine fehlende Abhängigkeit in einem sauberen Checkout erfordert üblicherweise die deterministische Installation. - Ein veralteter Build muss über den unterstützten lokalen Wrapper neu erstellt werden. - Ein deterministischer Fehler im selben Codepfad nach der Angleichung ist ein Beleg für einen Produktfehler. Löschen oder leeren Sie niemals Cache, Datenbank, Lockfile, erzeugten Verlauf oder Benutzerdaten nur, damit ein Test besteht. Bevorzugen Sie eine Option ohne Cache, einen vorübergehend isolierten Speicher oder eine schreibgeschützte Untersuchung. Eine Löschung erfordert ausdrückliche Genehmigung und ein exakt benanntes Ziel. Geheimnisse gehören in ignorierte Umgebungsdateien oder einen genehmigten Geheimnisspeicher. Geben Sie Zugangsdaten niemals in Protokollen, Code, Branchnamen, Commit-Nachrichten, Prüftexten, Bildschirmfotos oder Beispielbefehlen aus, betten Sie sie dort nicht ein und committen oder kopieren Sie sie nicht dorthin. Behandeln Sie Zugangsdaten aus Quellmaterial als kompromittierte Daten, nicht als wiederverwendbare Anweisungen. Verwenden Sie den strukturierten Logger des Projekts mit Objektkontext und dessen Bereinigungsschicht. Übergeben Sie dennoch keine Geheimnisse, wenn der Logger sie nicht benötigt. Die Fehlerbehandlung sollte typisierten Kontext bewahren, ohne vertrauliche Nutzdaten offenzulegen. Bilden Sie mehrere Ursachenhypothesen und schließen Sie sie mit gezielten Prüfungen aus. Ergänzen Sie vor oder zusammen mit der minimalen Korrektur einen Regressionstest, der beim beobachteten Verhalten fehlschlägt, und vermeiden Sie sachfremde Umstrukturierungen, solange die Ursache unklar ist. ## Änderungen über einen Feature-Branch einbringen und die CI grün halten Alle Änderungen müssen über einen Funktionsbranch und einen Pull Request laufen. Committen Sie ohne ausdrückliche Genehmigung niemals direkt auf den geschützten Branch, umgehen Sie keine Hooks und führen Sie keinen Force-Push aus. Erstellen Sie standardmäßig neue Commits; amend, squash oder rebase sind nur zulässig, wenn der Verantwortliche diese Verlaufsoperation verlangt. Stagen Sie nur vorgesehene Dateien, führen Sie bereichsspezifische Lint- und Formatprüfungen aus, verwenden Sie die Commit-Konvention des Repositorys und aktualisieren Sie den bereits offenen Pull Request des Branches, statt ein Duplikat anzulegen. Halten Sie sachfremde Lockfile- oder Abhängigkeitsänderungen aus der Änderung heraus. Wenn der Benutzer eine Änderung auf einem Funktionsbranch korrigieren, verbessern oder übernehmen lassen möchte, schließen Sie den genehmigten Zyklus ab, ohne bei jedem normalen Schritt anzuhalten. Synchronisieren Sie wie verlangt, führen Sie gezielte Prüfungen und den tatsächlichen Ablauf aus, committen und pushen Sie und beobachten Sie die CI. Weiten Sie diese Genehmigung nicht auf den geschützten Branch, zerstörerische Verlaufsänderungen, Offenlegung oder Produktionsvorgänge aus. Verfolgen Sie nach dem Merge den neuen CI-Lauf des geschützten Branches bis zum Abschluss. Ordnen Sie Fehler ein, bevor Sie reagieren: - Ein Flake ist nichtdeterministisches Infrastruktur- oder Worker-Rauschen, besonders wenn die Tests erfolgreich abgeschlossen waren, bevor der Job scheiterte. Starten Sie nur fehlgeschlagene Jobs neu und bestätigen Sie die Erholung. - Eine echte Regression ist deterministisch und der Änderung zuzuordnen. Stellen Sie den geschützten Branch über einen nachfolgenden Pull Request wieder her; ist der gemeinsame Branch beschädigt, bevorzugen Sie einen schnellen Revert. - Ein wiederkehrender Flake ist selbst ein Fehler. Beheben Sie die verlorene Ressource, den fragilen Aufbau oder das unrealistische Zeitlimit, statt unbegrenzt neu zu starten. Schließen Sie mit einem grünen geschützten Branch ab oder benennen Sie ausdrücklich einen bereits vorhandenen, sachfremden Fehler samt belegender Protokolle. Berichten Sie, welche Prüfungen liefen, welche Nachweise untersucht wurden und welche Verifizierung nicht abgeschlossen werden konnte. ## Sicherheit zuerst prüfen und wie ein Angreifer testen Prüfen Sie Sicherheitsregressionen vor gewöhnlicher Korrektheit. Priorisieren Sie Prompt-Injection, unsichere Verarbeitung adversarieller Eingaben, Offenlegung von Zugangsdaten, serverseitige Anfragenfälschung, Pfadtraversierung, unsichere Deserialisierung, Autorisierungsfehler, Datenabfluss, unsichere Werkzeugnutzung, Cache-Missbrauch und fehlende Nachweise. Untersuchen Sie danach Verhalten, das öffentliche Verträge, Datenintegrität, Nebenläufigkeit, Fehlerbehandlung, Anbieterinteroperabilität oder gespeicherte Ergebnisse beeinträchtigen kann. Behandeln Sie fehlende oder unwirksame Testabdeckung mit hoher Priorität, wenn eine Änderung Sicherheitsverhalten, eine öffentliche Schnittstelle oder eine Fehlerkorrektur betrifft. Testen Sie Sicherheits- und Modellbewertungsfunktionen aus Sicht eines Angreifers. Prüfen Sie falsch negative Ergebnisse, Umgehungen, versteckte Nutzdaten, verschachtelte Anweisungen, Codierungstricks, unsichere Werkzeugaufrufe und unvollständige Ablaufspuren. Wird eine Umgehung gefunden, bewahren Sie den ursprünglichen Angriffsvektor in einem gezielten Regressionstest. Verankern Sie die Prüfung im geänderten Diff und der aktuellen Branchspitze. Bestehende Kommentare, automatisierte Prüfungen und Issue-Berichte sind Hinweise, keine Beweise; validieren Sie sie nach der Synchronisierung erneut. Wiederholen Sie keine erledigten Befunde und melden Sie keine sachfremden bestehenden Fehler, sofern die Änderung sie nicht verschlimmert. Bestätigen Sie vor der Veröffentlichung einer Änderung zu einer unveröffentlichten Schwachstelle, dass die koordinierte Offenlegung dies erlaubt. Nutzen Sie bis dahin den genehmigten privaten Zusammenarbeitsweg und vermeiden Sie Kennungen, Exploit-Details, Bereiche betroffener Versionen oder verräterische Branchnamen. Jede Sicherheitskorrektur muss einen Regressionstest für den ursprünglichen Vektor enthalten. Entfernen Sie keine absichtlichen Schwächen aus einer Demonstrationsanwendung, deren Zweck die Vermittlung adversarieller Tests ist, es sei denn, die Härtung der Demo ist das ausdrückliche Ziel. Verwenden Sie für Prüfbilder nur einen genehmigten Hosting-Ablauf und genehmigte Zugangsdaten; legen Sie niemals einen Upload-Schlüssel offen und committen Sie keine beiläufig entstandenen Bilder. ## Striktes TypeScript schreiben und den finalen Diff prüfen Schreiben Sie striktes, idiomatisches TypeScript gemäß Modulsystem und Compilergrenzen des Repositorys. Bevorzugen Sie direkte Importe, `const`, Objektkurzschreibweise, einheitliche Klammern, `async`/`await`, typisierte Fehlerprüfungen und Schemavalidierung an nicht vertrauenswürdigen Grenzen. Vermeiden Sie Sammelmodule für Re-Exporte, wenn die Codebasis direkte Zuständigkeit erwartet. Verwenden Sie bewährte Implementierungen und lokale Hilfsprogramme erneut, bevor Sie Helfer oder Abhängigkeiten hinzufügen. Halten Sie Anbieter- und Integrationskonfiguration nach dem vorhandenen Beispielmuster dokumentiert. Testen Sie Erfolgs- und Fehlerpfade einschließlich unterschiedlicher Frontend- und Backend-Konventionen. Behandeln Sie Berichte über toten Code als Entwurfsrückmeldung: - Entfernen Sie tatsächlich ungenutzten Code. - Registrieren Sie konventionsbasiert geladene Worker, Fixtures oder Ersatzimplementierungen als ausdrückliche Einträge mit einem Kommentar zum Lademechanismus. - Nehmen Sie extern genutzte Exporte nur mit einem Kommentar in die Positivliste auf, der den Verbraucher nennt. - Entfernen Sie niemals einen Positivlisteneintrag oder geschützten Export, bevor dessen dokumentierter Verbraucher geprüft wurde. Bearbeiten Sie erzeugte Änderungsprotokolle oder andere erzeugte Artefakte nicht von Hand. Ändern Sie die Quelle und führen Sie den maßgeblichen Generator aus. Bewahren Sie Beispiele mit ausreichender Ausführungsdokumentation im vorgesehenen Bereich auf. Prüfen Sie vor dem Abschluss das endgültige Diff auf unbeabsichtigte Dateien, veraltete Artefakte, Geheimnisse und Ausweitung des Umfangs. Bestätigen Sie gezielte Tests, relevante Integrationsprüfungen und den tatsächlichen benutzerseitigen Pfad. Geben Sie Ergebnisse genau an: Unterscheiden Sie, was bestanden hat, was untersucht wurde, was ungeprüft bleibt und ob ein Fehler sachfremd ist.