Einem schemageprüften Katalog KI-Anbieter und -Modelle hinzufügen

## Vor dem Abschluss den Validator und die Build-Befehle des Repositorys ausführen Vor Änderungen an Katalogdaten sind die dokumentierten Prüf-, Erstellungs- und Entwicklungsbefehle des Projektarchivs zu prüfen. Verwenden Sie den paketspezifischen Befehl für den betroffenen Arbeitsbereich und die bereits vom Projekt gewählte Laufzeitumgebung. - Führen Sie den kanonischen Konfigurationsprüfer aus, bevor eine Katalogänderung als abgeschlossen gilt. - Erstellen Sie nur die betroffene Benutzeroberfläche oder das betroffene Paket und auch das nur, wenn die Aufgabe eine Erstellung verlangt. - Wenn das Projektarchiv über kein eigenes Testsystem verfügt, erfinden Sie keine Testbefehle; verwenden Sie die tatsächlich bereitgestellten Prüf- und Erstellungsschranken. - Starten Sie keinen Entwicklungsserver, sofern die Aufgabe dies nicht ausdrücklich verlangt. Begrenzen Sie die Validierung angemessen auf das geänderte Paket, ohne eine vom Projektarchiv vorgeschriebene Schranke auszulassen. ## TypeScript-Typen aus den Schemata ableiten, statt sie doppelt zu schreiben Behandeln Sie strikte Validierungsschemata als maßgebliche Quelle. Leiten Sie TypeScript-Typen aus diesen Schemata ab, statt parallele Schnittstellen zu pflegen, und weisen Sie unbekannte Felder zurück, wenn das aktive Schema strikt ist. - Halten Sie das festgelegte Modulformat des Projektarchivs und die lokalen Regeln zu Dateiendungen bei Importen ein. - Exportieren Sie bei Bedarf Schnittstellen für öffentliche API-Verträge, leiten Sie die Typen validierter Daten jedoch aus exportierten Schemakonstanten ab, statt die Schemaformen zu duplizieren. - Verwenden Sie die vorgeschriebenen Benennungskonventionen für Werte, Funktionen, Typen und Schemata; kennzeichnen Sie absichtlich ungenutzte Werte nach der Unterstrichkonvention des Projektarchivs. - Bevorzugen Sie eine sichere Auswertung, die strukturierte Fehler zurückgibt, und bewahren Sie die zugrunde liegende Ursache, wenn der Fehlervertrag dies unterstützt. - Behandeln Sie `undefined` bei Vergleichen und Sortierungen ausdrücklich; verwenden Sie optionale Verkettung und Nullwert-Zusammenführung, sofern dadurch die beabsichtigte Bedeutung erhalten bleibt. - Verwenden Sie für Dateioperationen `async`/`await` und asynchrone Iteration sowie die nativen APIs der Laufzeitumgebung für Mustersuche, Dateien und Schreibzugriffe, wenn dies im Projektarchiv vorgesehen ist. Duplizieren Sie Schemaangaben nicht in handgeschriebenen Typen und umgehen Sie die strukturierte Validierung nicht durch ungeprüfte Typumwandlungen. ## Katalogdaten im zuständigen Paket des Monorepos ändern Ermitteln Sie vor einer Bearbeitung, welcher Arbeitsbereich für die Kernvalidierung, die Benutzeroberfläche und bereitstellbare Funktionen zuständig ist. Belassen Sie die Katalogquellen in ihrem maßgeblichen Verzeichnis und nehmen Sie Änderungen in dem Paket vor, das sie verwendet. - Bewahren Sie die festgelegten Beziehungen zwischen der Kernerzeugung, der statischen Ausgabe der Benutzeroberfläche und dem Code bereitgestellter Funktionen. - Halten Sie die Wahl der Laufzeitumgebung und Module in allen Arbeitsbereichspaketen einheitlich. - Validieren Sie zuerst das betroffene Paket und führen Sie eine paketübergreifende Erstellung nur aus, wenn der geänderte Vertrag diese Grenze überschreitet. - Verschieben Sie die Zuständigkeit für die Konfiguration nicht nur, um einen einzelnen Beitrag zu vereinfachen. Verallgemeinern Sie Architekturentscheidungen nach Verantwortungsbereich und nicht nach einem bestimmten Bereitstellungsanbieter, Rahmenwerk oder Verzeichnisnamen. ## Für neue Anbieter ein an das Theme anpassbares Logo verlangen und bei passender Quelle synchronisieren Behandeln Sie erforderliche Anbieterressourcen als Zusammenführungssperren. Jeder neue Anbieter muss in seinem eigenen Verzeichnis ein regelkonformes Vektorlogo enthalten. - Verwenden Sie ein skalierbares Vektorformat, an das Erscheinungsbild angepasste Füllungen oder Konturen mit `currentColor` und vorzugsweise ein quadratisches `viewBox`. - Verwenden Sie keine festen Abmessungen oder fest eingetragenen Farben, die nicht sowohl mit heller als auch mit dunkler Darstellung funktionieren. - Fügen Sie ein Synchronisierungsmodul hinzu, wenn eine maßgebliche API oder ein maßgeblicher Katalog die erforderlichen Daten eintragen oder nicht mehr angebotene Einträge zuverlässig erkennen kann. - Pflegen Sie inhaltsarme oder unvollständige Quellen manuell, wenn sie weder erforderliche Felder ausfüllen noch eine maßgebliche Entfernung stützen können. Ist die Quelle ausreichend vollständig, stellt das Synchronisierungsmodul eine dringende Empfehlung dar; fehlt eine maßgebliche Quelle, ist es keine Sperre. Automatisieren Sie niemals die Entfernung anhand einer Quelle, die die Vollständigkeit des Katalogs nicht belegen kann. ## Gemeinsame Modelldaten von einem Basismodell erben, statt sie zu kopieren Wenn ein kanonischer Eintrag für Modellmetadaten vorhanden ist, müssen anbieterspezifische Datensätze die anbieterunabhängigen Angaben über das Basisverweisverfahren des Projektarchivs daraus erben. Kopieren Sie gemeinsam genutzte Angaben nicht direkt in den Datensatz. - Verwenden Sie eine vollständige eingebettete Definition nur, wenn kein passender kanonischer Metadateneintrag vorhanden ist. - Verlangen Sie, dass jeder Verweis über `base_model` auf eine tatsächlich vorhandene Metadatendatei aufgelöst werden kann. - Belassen Sie anbieterspezifische Werte wie Preisgestaltung, Anbieterkennung, Versuchsstatus, Steuerungsmöglichkeiten für Schlussfolgerungen, Verzahnungsverhalten und Lebenszyklusstatus bei Bedarf im Anbieterdatensatz. - Stellen Sie sicher, dass die aufgelöste Ausgabe die zusammengeführten Angaben enthält, jedoch nicht die ausschließlich für die Erzeugung verwendeten Anweisungen `base_model` oder `base_model_omit`. Die Vererbung soll Duplikate verringern, ohne Werte zu verbergen, die tatsächlich je nach Anbieter abweichen. ## Reasoning-Einstellungen nur so angeben, wie die Anbieter-API sie wirklich bietet Jeder als Schlussfolgerungsmodell gekennzeichnete Datensatz muss `reasoning_options` angeben, die den tatsächlich über die API angebotenen Steuerungsmöglichkeiten des Anbieters entsprechen. - Stellen Sie verifizierte Umschalter, Budgets oder andere Steuerungen mit genau dem vom Schema erwarteten Optionstyp dar. - Halten Sie die genaue Syntax der API-Anfrage in einem nahe gelegenen TOML-Kommentar fest, wenn ein Anbieter eine besondere Anfragestruktur verwendet. - Erfassen Sie verifizierte Mindest- und Höchstgrenzen für Budgetsteuerungen; leiten Sie Grenzen nicht von einem anderen Anbieter ab. - Verwenden Sie `reasoning_options = []`, wenn das Modell Schlussfolgerungen zieht, aber keine verifizierte Steuerungsmöglichkeit für Benutzer bereitstellt. Erfinden Sie nicht allein deshalb einen Umschalter, weil ein Modell Schlussfolgerungen unterstützt. Der Katalog muss zwischen der Fähigkeit zum Schlussfolgern und steuerbarem Schlussfolgerungsverhalten unterscheiden. ## Beim Erben von Modelldaten Objekte tief zusammenführen und Arrays ersetzen Setzen Sie die Vererbung von Metadaten genau nach dem Auflösungsvertrag des Projektarchivs um. - Führen Sie einfache Objekte wie Grenzwerte und Modalitäten in der Tiefe zusammen. - Ersetzen Sie Arrays und primitive Werte vollständig durch den Wert des untergeordneten Eintrags. - Erben Sie jedes Anbieterfeld, das der untergeordnete Eintrag auslässt. - Wenden Sie `base_model_omit` nach der Zusammenführung an, ignorieren Sie nicht vorhandene Pfade und entfernen Sie übergeordnete Objekte, die dadurch leer werden. - Lassen Sie die Validierung fehlschlagen, wenn die referenzierte Datei mit den Basismetadaten nicht vorhanden ist. Fügen Sie eine gezielte Testabdeckung für das Ersetzen von Arrays, das tiefe Zusammenführen von Objekten, ausgelassene Pfade und das Entfernen leerer Objekte hinzu. Gehen Sie niemals davon aus, dass Objekte, Arrays und primitive Werte auf die gleiche Weise zusammengeführt werden. ## Modell-IDs aus Dateinamen ableiten und geprüfte Preise je Region eintragen Leiten Sie Kennungen aus Dateinamen ab, wenn dies der Vertrag des Projektarchivs vorsieht; duplizieren Sie niemals eine automatisch eingefügte Kennung in der Datendatei. Bewahren Sie die anbieterspezifische Namensgrammatik einschließlich datierter Endungen, Aliasnamen für die jeweils neueste Version, Regionspräfixe, Versionskennzeichnungen und Trennzeichen. Unterscheiden Sie anhand des aktiven strikten Schemas zwischen erforderlichen menschenlesbaren Metadaten, erforderlichen booleschen Fähigkeitsangaben, erforderlichen Kosten-, Grenzwert- und Modalitätsobjekten sowie optionalen Feldern für Familie, Wissen, Temperatur, strukturierte Ausgabe oder Lebenszyklus. Weisen Sie zusätzliche Felder zurück, statt sie stillschweigend anzunehmen. Stellen Sie die Schwellenpreisgestaltung mit dem verschachtelten Kostenobjekt des Schemas dar, wenn der Kontext 200K überschreitet. Nehmen Sie nicht an, dass die üblichen Preisverhältnisse für Cache-Lese- und Schreibzugriffe von 10%/125% auch für regionale Varianten gelten, für die 30%/375% dokumentiert sind; bilden Sie das verifizierte Verhalten des Anbieters und der Region ab. ## Quellenangaben dort ablegen, wo die Synchronisierung sie behält Beiträge, die Daten ändern, sollten maßgebliche Preisseiten, Modelldokumentationen oder API-Referenzen anführen. Fehlende Quellenangaben sind nicht automatisch eine Sperre, erfordern jedoch eine strengere Prüfung und unabhängige Verifizierung. Platzieren Sie Quellenangaben und Begründungen in einem einleitenden Kommentarblock vor dem ersten Schlüssel, wenn die Synchronisierung Katalogdateien auswertet und erneut serialisiert. Platzieren Sie dauerhaft benötigte Kommentare nicht zwischen Abschnitten oder über einzelnen Schlüsseln, wenn sie bei der Synchronisierung verworfen werden. Behandeln Sie die Position von Kommentaren als Beständigkeitsbedingung und nicht als Frage des Erscheinungsbilds. Prüfen Sie, ob der nächste Synchronisierungslauf jede Quelle beibehält, die später zur Prüfung der Daten benötigt wird. ## Bei der Prüfung von Katalogänderungen Blocker von Empfehlungen trennen Unterscheiden Sie bei der Prüfung zwischen harten Sperren und Empfehlungen. Fehlende erforderliche Ressourcen, ungültige Basisverweise, fehlende vorgeschriebene Schlussfolgerungssteuerungen, Schemaverstöße oder eine fehlgeschlagene Validierung müssen die Annahme verhindern; ein empfohlenes Synchronisierungsmodul oder eine Quellenangabe ist nach dem dokumentierten Verbindlichkeitsgrad zu beurteilen. Vor dem Abschluss: - Führen Sie den kanonischen Katalogprüfer aus. - Erstellen Sie nur bei Bedarf das betroffene Paket. - Bestätigen Sie erforderliche Ressourcen, Vererbung, Schlussfolgerungssteuerungen, Benennung, Preisgestaltung und Lebenszyklusfelder. - Prüfen Sie, ob Quellenangaben die Synchronisierung überstehen. - Prüfen Sie die abschließenden Änderungen auf sachfremde oder duplizierte Daten. Berichten Sie, welche Prüfungen ausgeführt wurden, welche Prüfungen bewusst außerhalb des Prüfbereichs lagen und welche Empfehlung weiterhin ungeklärt ist. Stellen Sie eine Empfehlung nicht als Sperre dar und schwächen Sie eine Sperre nicht zu einem bloßen Hinweis ab.