KI-Anbieter und Vektorspeicher zu einem modularen Rust-KI-Framework hinzufügen

## Nur den gewünschten Umfang ändern und ohne Auftrag nichts committen - Lies vor Codeänderungen die bestehende Implementierung, Manifeste, Tests und öffentliche Dokumentation. - Begrenze jede Änderung auf den vom Benutzer beauftragten Umfang. - Bevorzuge vorhandene Traits, Builder, Module und Fehlertypen gegenüber parallelen Abstraktionen. - Füge keine TODOs, Attrappen, Platzhalterlogik oder spekulativen öffentlichen APIs hinzu. - Erstelle keine Commits, stelle keine Änderungen bereit, pushe nichts, lege keine Zweige an und öffne keine Pull Requests, sofern der Benutzer dies nicht ausdrücklich verlangt. - Bewahre sachfremde Benutzeränderungen und arbeite sicher um einen veränderten Arbeitsbaum herum. - Vermeide sachfremde Umstrukturierungen, auch wenn sich ein benachbartes Design verbessern ließe. - Unterscheide Richtlinien für Mitwirkende von den technischen Regeln des Repositorys und befolge beide. - Halte an, wenn die erforderliche Produktabsicht oder eine externe Genehmigung fehlt. ## Crate-Aufteilung und Feature-Flags im ganzen Arbeitsbereich stimmig halten - Belasse das öffentliche Fassaden-Crate, das Kern-Crate, ergänzende Integrationen, Ableitungsmakros, Beispiele und Tests in ihren festgelegten Rollen. - Die Fassade soll Kern-APIs erneut exportieren und optionale Ergänzungs-Crates über Feature-Schalter bereitstellen. - Prüfe das Arbeitsbereichsmanifest und die Fassadenexporte, bevor du öffentliche Features, Integrationen oder Modulpfade änderst. - Lege Anbieter- und Vektorspeicherintegrationen in Ergänzungs-Crates ab, sofern kein gewichtiger Architekturgrund die Aufnahme in den Kern verlangt. - Trenne Beispiele des Arbeitsbereichs von Crate-spezifischen Beispielen und Integrationstests. - Aktualisiere beim Hinzufügen eines Ergänzungs-Crates nach Bedarf die Wurzelabhängigkeit, das Feature, den Fassadenexport, Beispiele, README und Crate-Dokumentation. - Stelle sicher, dass Feature-Kombinationen kompilieren, ohne nicht verfügbare Module offenzulegen. - Halte die öffentliche Dokumentation zwischen Fassade und betroffenen Ergänzungs-Crates synchron. - Beschreibe einen Modulpfad oder ein Feature erst, nachdem Code und Manifeste es bestätigt haben. ## Auf den gemeinsamen Traits aufbauen statt anbieterspezifische Varianten zu schaffen - Baue Integrationen auf den zentralen Traits des Frameworks für Vervollständigung, Einbettung, Vektorindizes und aufrufbare Werkzeuge auf. - Erstelle keine anbieterspezifischen Alternativen zu einem vorhandenen anbieterübergreifenden Trait. - Befolge für konfigurierbare öffentliche Typen das etablierte Builder-Muster. - Halte die Konstruktion flüssig und typisiert und schließe sie erst nach einem ausdrücklichen Build-Schritt ab. - Verwende eine allgemeine Client-Architektur, die Anbietererweiterungen vom zugrunde liegenden HTTP-Transport trennt. - Deklariere Anbieterfähigkeiten ausdrücklich, damit nicht unterstütztes Verhalten bereits beim Kompilieren scheitert. - Stelle fehlende Fähigkeiten durch einen bewussten Markertyp statt durch Vermutungen zur Laufzeit dar. - Bewahre die Beziehungen der API-key-Typen zwischen Anbieter-Buildern und öffentlichen Client-Aliasen. - Halte anbieterspezifische Anfrage- und Antworttypen hinter Konvertierungsgrenzen. ## Gemeinsamen asynchronen Code auch unter WebAssembly lauffähig halten - Bewahre die WebAssembly-Unterstützung in gemeinsamen Traits, Futures, Fehlern und Integrationen. - Verwende bei unterschiedlichen Zielplattformen die Kompatibilitätsabstraktionen des Frameworks anstelle unvermittelter `Send`- und `Sync`-Schranken. - Verwende für dynamisch zurückgegebene Futures den vorgesehenen plattformübergreifenden boxed-future-Typ. - Wende native Schranken für Threadsicherheit nur auf Zielplattformen an, die sie unterstützen. - Halte gekapselte WebAssembly-Fehler frei von nicht unterstützten, ausschließlich nativen Schranken. - Teste nach Änderungen gemeinsamer Traits sowohl native als auch auf WebAssembly ausgerichtete Typsignaturen. - Füge keine Abhängigkeit oder API hinzu, die eine unterstützte Zielplattform stillschweigend ausschließt. - Begrenze bedingte Kompilierung auf einen engen Bereich und erläutere den Unterschied zwischen Zielplattformen. - Stelle sicher, dass Anbieter-, Vektorspeicher- und Hook-APIs denselben Portabilitätsvertrag verwenden. ## Eindeutige Fehlertypen nutzen und jede neue öffentliche API dokumentieren - Verwende `String` nicht als Fehlertyp für eine neue fallible API. - Definiere ausdrückliche Fehleraufzählungen und bewahre nützliche Einzelheiten der Anbieterantwort über die Fehlerhilfen des Frameworks. - Bevorzuge `?` und aussagekräftige Konvertierungen gegenüber dem manuellen Verlust von Fehlerkontext. - Verwende `unwrap()` oder `expect()` nur, wenn die Unmöglichkeit aus der umgebenden Invariante eindeutig hervorgeht. - Ergänze jedes neue öffentliche Element wie Typ, Funktion, Trait und Methode um Elementdokumentation. - Ergänze jedes neue öffentliche Modul um Moduldokumentation. - Halte Beispiele mit tatsächlichen APIs, Modellkonstanten, Modulpfaden und Feature-Schaltern in Einklang. - Kennzeichne Beispiele als nicht ausführbar, wenn sie externe Zugangsdaten oder Dienste benötigen. - Aktualisiere README-Dateien und Dokumentation auf Crate-Ebene bei jeder Änderung öffentlichen Verhaltens. ## Einen neuen KI-Anbieter nach dem Vorbild des ähnlichsten bestehenden hinzufügen - Untersuche vor der Implementierung oder Änderung eines Anbieters die ähnlichste vorhandene Anbieterimplementierung. - Ergänze Anbietererweiterungs- und Builder-Typen, die Anbieterimplementierung und eine ausdrückliche Fähigkeitsdeklaration. - Unterstütze die Konstruktion aus Umgebungswerten und direkten Werten, wenn das Framework beide Wege bereitstellt. - Halte öffentliche Client- und Builder-Aliase mit dem API-key-Typ des Anbieter-Builders in Einklang. - Verwende ausdrückliche Markertypen für Zugangsdaten oder Authentifizierung und schwärze zugangsdatenhaltige Werte in Debug-Ausgaben. - Konvertiere Framework-Anfragen in das tatsächliche Übertragungsformat des Anbieters und Antworten zurück in Framework-Typen. - Ergänze Streaming nur, wenn der Anbieter es tatsächlich unterstützt, und bewahre Anbieterfehler über die Standardhilfen. - Befolge bestehende Telemetriekonventionen und Erweiterungs-Traits. - Erfinde keine Anfrage- oder Antwortfelder, die in der tatsächlichen Anbieter-API fehlen. - Ergänze zielgerichtete Tests oder Beispiele, die das unterstützte Verhalten belegen. ## Einen Vektorspeicher mit echten Filtern und klaren Suchergebnissen anbinden - Lege eine Vektorspeicherintegration in einem Ergänzungs-Crate ab, sofern die Zugehörigkeit zum Kern nicht begründet ist. - Implementiere sowohl eine ergebnisliefernde als auch eine ausschließlich Kennungen liefernde Suche. - Verwende einen Filtertyp, der die tatsächlichen Filtermöglichkeiten des Backends abbildet. - Gib die Vektorspeicher-Fehlervarianten des Frameworks statt improvisierter Zeichenkettenfehler zurück. - Wende dieselben plattformübergreifenden asynchronen Schranken wie im Kern-Framework an. - Halte Konvertierungen von Bewertung, Dokument, Kennung und Metadaten ausdrücklich. - Definiere Sortierung, Begrenzung, leere Ergebnisse und Verhalten bei Backend-Fehlern. - Teste Filter, Rangfolge, Ergebnisgrenzen, fehlende Datensätze und Konvertierungsfehler. - Dokumentiere benötigte Features, Zugangsdaten, Indizes und externe Einrichtung, ohne Geheimnisse einzubetten. ## Für jedes Hook-Ereignis die erlaubten Aktionen festlegen - Modelliere Hooks als Beobachter und Steuerer eines einzelnen Ausführungslaufs. - Übergib jedem Ereignis einen Laufkontext mit Laufkennung, Runde, Streaming-Modus, Agentenkennung und gemeinsamem Zwischenspeicherzustand. - Gib jedem Ereignis einen eigenen Aktionstyp, damit nicht unterstützte Aktionskombinationen beim Kompilieren scheitern. - Lasse Hooks für Vervollständigungsaufrufe eine Anfrage ändern oder die Verarbeitung stoppen. - Lasse Hooks für Werkzeugaufrufe und -ergebnisse Werte für spätere Hooks umschreiben; definiertes skip oder stop ist dabei eine abschließende Aktion. - Stelle die Behandlung ungültiger Werkzeugaufrufe durch ausdrückliche Optionen für fail, retry, repair, skip und stop dar. - Beschränke rein beobachtende Ereignisse auf continue oder stop. - Registriere Beobachtungshooks vor Steuerungshooks, wenn stop-Aktionen den Stapel vorzeitig beenden. - Dokumentiere, welche Aktionen Daten umformen, ansammeln oder die Verarbeitung beenden. ## Gestapelte Hooks mit und ohne Streaming gleich zusammensetzen - Bewahre ereignisspezifische Zusammensetzungsregeln, wenn Hooks verschachtelt oder gestapelt werden. - Führe Änderungen an Vervollständigungsanfragen in Registrierungsreihenfolge zusammen. - Hänge zusätzlichen Kontext an, führe zusätzliche Parameter flach zusammen und bilde die Schnittmenge aktiver Werkzeuge. - Verwende das Prinzip „letzter Schreiber gewinnt“ nur für dokumentierte Skalar- und Verlaufsfelder und warne bei bedeutsamem Überschreiben. - Begrenze jede Anfrageänderung auf eine Runde; lasse sie niemals versehentlich dauerhaft werden. - Reiche Umschreibungen von Werkzeugaufrufen und -ergebnissen an alle späteren Hooks weiter. - Beende die Stapelauswertung sofort, wenn eine abschließende Aktion dies verlangt. - Lasse Streaming- und Nicht-Streaming-Oberflächen denselben Lebenszyklustreiber verwenden. - Teste identisches Hook-Verhalten über Streaming- und Nicht-Streaming-Einstiegspunkte. - Ergänze Zusammensetzungstests für verschachtelte Stapel, Zusammenführungskonflikte, Umschreibeketten, skip und stop. ## Den kleinsten Regressionstest wählen und Anbieteraufrufe mit aufgezeichneten Kassetten testen - Ergänze Regressionstestabdeckung im kleinsten zuverlässigen Umfang. - Bevorzuge für isolierte Konvertierungs- oder Logikfehler einen Komponententest neben der Implementierung. - Verwende kassettenbasierte Anbietertests, wenn das Verhalten vom Anfrage- und Antwortverkehr des Anbieters abhängt. - Verwende ignorierte Live-Tests nur, wenn eine deterministische Kassettenwiedergabe das Verhalten nicht darstellen kann. - Lies den Testleitfaden des Repositorys, bevor du Anbietertests hinzufügst, aktualisierst, aufzeichnest oder wiedergibst. - Spiele Kassetten standardmäßig ab, damit normale Tests keine Anbieterzugangsdaten benötigen. - Begrenze die Testausführung auf den geänderten Anbieter und das geänderte Verhalten. - Decke Streaming- und Nicht-Streaming-Verhalten ab, wenn beide Oberflächen vorhanden sind. - Bewahre das ursprüngliche Fehlermuster in der Regressionsprüfung. ## Kassetten nur für den Zieltest aufzeichnen und auf Geheimnisse prüfen - Behandle den Aufzeichnungsmodus als externen, zugangsdatenpflichtigen und dateiüberschreibenden Vorgang. - Verlange vor der Aufzeichnung die zugehörigen Anbieterzugangsdaten und gib sie niemals aus. - Zeichne nur den betroffenen Anbietertest auf, um sachfremde Änderungen an Testdaten zu minimieren. - Prüfe jeden Kassetten-Diff manuell, bevor du ihn vorlegst oder committest. - Verwirf Testdaten mit API keys, bearer credentials, cookies, Kontokennungen oder anderen sensiblen Werten. - Entferne sachfremde Anfrage- und Antwortänderungen, statt unübersichtliche Testdaten zu akzeptieren. - Lasse automatische Bereinigungs- und Sicherheitsprüfungen aktiviert, betrachte sie aber nicht als Ersatz für eine Inspektion. - Bewahre deterministische Wiedergabedaten, während du Geheimnisse und instabile Metadaten schwärzt. - Überschreibe Testdaten niemals nur, um einen fehlgeschlagenen Test ohne Erklärung der Verhaltensänderung erfolgreich zu machen. ## Prüfungen von eng nach breit ausführen und Ungeprüftes benennen - Führe zuerst die kleinsten nützlichen Prüfungen aus und erweitere sie danach entsprechend betroffenem Umfang und Risiko. - Formatiere den Arbeitsbereich und führe Lints für alle betroffenen Zielplattformen und Features aus. - Führe zielgerichtete Tests vor umfassenden Arbeitsbereichstests aus. - Erzeuge Dokumentation ohne Abhängigkeiten, wenn sich öffentliche APIs oder Dokumente ändern. - Prüfe native und WebAssembly-Kompatibilität, wenn sich gemeinsame Schranken oder Futures ändern. - Bestätige, dass Übertragungsfelder des Anbieters der tatsächlichen API entsprechen und Kassetten-Diffs keine Geheimnisse enthalten. - Bestätige, dass die Hook-Semantik auf Streaming- und Nicht-Streaming-Oberflächen übereinstimmt. - Melde keinen Abschluss, solange eine erforderliche Prüfung fehlschlägt. - Erkläre bei einem nicht ausführbaren Befehl den Grund und benenne genau, was ungeprüft bleibt. - Berichte über geänderte Bereiche, ausgeführte Prüfungen, beobachtete Ergebnisse, verbleibende Risiken und bewusst ausgeschlossenen Umfang.