Befehlsschemata für KI-Agenten aus den echten Befehlen und Flags erzeugen

## Registry und Generatoren ändern, nicht die erzeugten Dateien Behandle die Vorgaben des Repositorys als Vertrag für die Dateien in ihrem Geltungsbereich. Bewahre sachfremde Arbeiten, wende das Formatierungswerkzeug der jeweiligen Sprache auf jede geänderte Quelldatei an und ändere nur die kleinste zuständige Eingabe, die für das verlangte Verhalten erforderlich ist. Ermittle vor der Bearbeitung die maßgeblichen Eingaben. Ein geprüftes Befehlsregister sollte stabile Befehlsidentitäten, Hauptpfade, Aliase und Navigation verwalten. Der ausführbare Befehlsbaum sollte bestimmen, ob ein Pfad vorhanden und ausführbar ist und welche Schalter er annimmt. Erzeugte Kataloge und Agentenmetadaten sind Ausgaben und keine Bearbeitungsflächen; ändere ihre Quelleingaben und Erzeugungswerkzeuge und erzeuge sie danach neu. Führe die vom Repository vorgegebene Kompilierung, alle Prüfungen, die Erzeugung, Abweichungsprüfungen, Richtlinienprüfungen und die gezielten Befehlsprüfungen aus, die die Änderung abdecken. Prüfe den erzeugten Unterschied und lehne sachfremde Umschreibungen ab. ## Schemata in eine Richtung bauen und jeden Befehl einmal binden Halte die Schemaauflösung gerichtet: 1. Erzeuge den tatsächlich ausführbaren Befehlsbaum und seine Schalter. 2. Verbinde das geprüfte Identitätsregister vor der Bindung mit den geprüften Metadatenüberlagerungen. 3. Löse Parametertypen, Zuordnungen, Pflichtzustände, Vorgabewerte und parameterübergreifende Einschränkungen auf. 4. Löse Agentenauswahl, Sicherheit, Schnittstellen und die Bedeutung von Laufzeitschranken nach der erklärten Quellenrangfolge auf. 5. Binde jeden Befehl genau einmal in eine einzige typisierte Werkzeugspezifikation und einen Index. 6. Veröffentliche Kataloge, Gesamtexporte, Zusammenfassungen und erzeugte Metadaten ausschließlich aus dieser typisierten Quelle. Öffne nach der Bindung keine Anmerkungen, Quelldatensätze, früheren Kataloge oder erzeugten JSON-Daten erneut, um Identitäten zu reparieren oder noch einmal aufzulösen. Ein Produktionslader, der eine eingebettete Momentaufnahme dekodiert, ist eine Auslieferungsgrenze und keine zweite Stufe der Quellenauflösung. Er darf niemals Befehle, Schalter, Registereinträge oder spätere Erzeugungseingaben anlegen oder reparieren. Bewahre den veröffentlichten Übertragungsvertrag, sofern keine versionierte Änderung ausdrücklich genehmigt wurde. Die architektonische Angleichung an ein anderes System rechtfertigt keine unversionierte Formatänderung. ## In beide Richtungen prüfen, dass Befehle und Schemata zusammenpassen Die Bindungsstufe muss einen fehlenden oder nicht ausführbaren Befehlspfad, Aliasüberschneidungen und native Identitätszusicherungen ablehnen, die dem wirksamen Register widersprechen. Eine fehlende native Identitätszusicherung kann zulässig sein, wenn Anmerkungen nur der Konsistenzprüfung dienen und keine ersatzweisen Identitätsquellen sind. Erzwinge die Abdeckung in beide Richtungen: 1. Jedes ausgelieferte Schemawerkzeug einschließlich seiner Katalogprojektion muss sich in einen ausführbaren Befehl auflösen lassen. 2. Jeder öffentliche ausführbare Befehlsendknoten muss sich in das Schema auflösen lassen oder in einem genauen, geprüften Ausschluss mit einer nicht leeren Begründung erscheinen. Verwende niemals Präfix- oder Platzhalterausschlüsse, weil sie künftige Befehle verbergen können. Veraltete, ungültige oder doppelte Ausschlüsse müssen die Erzeugung fehlschlagen lassen; ein Ausschluss ist außer Gebrauch zu nehmen, sobald sein Befehl in das Schema aufgenommen wird. Behandle das geprüfte Register als einzige Quelle für stabile Identitäten und Navigation und den ausführbaren Baum als Quelle für Pfade, Ausführbarkeit und Schalter. Führe bei jeder Änderung des Befehlsbaums Prüfungen der umgekehrten Vollständigkeit aus. ## Sicherheitsmetadaten und Auswahltexte für Agenten getrennt halten Trenne von Menschen verfasste Eingaben nach Zuständigkeit. Metadaten verwalten Auswirkungen, Risiko, Bestätigung, Idempotenz, Schnittstellen, Laufzeitschranken und optionale Parameterüberlagerungen. Auswahltexte verwalten Agentenzusammenfassungen, positive und negative Weiterleitungshinweise, Beispiele und Produktweiterleitung. Ein Index sollte Produktkennungen nur diesen Dateien zuordnen. Vermische keine Felder zwischen diesen Blöcken. Jeder verfasste Eintrag muss ausdrücklich geprüft sein, eine konkrete Prüfbegründung und Nachweisverweise enthalten und der kleinste Eintrag sein, der das für Nutzende sichtbare Verhalten ausdrückt. Der Auswahltext sollte Auslöseabsicht, Weiterleitung zwischen verwandten Befehlen und erwartete Ergebnisse erläutern, statt eine Befehlszusammenfassung zu wiederholen. Löse Nachweise nach der erklärten Rangfolge auf: zuerst ausführbare Laufzeittatsachen, dann das laufende Schnittstellenschema, festgeschriebene Schnittstellenmetadaten und zuletzt Fähigkeitsdokumentation nur als Nachweis. Wenn die laufende Ermittlung persönliche Zugangsdaten verwendet, darfst du diese niemals anzeigen oder einchecken. Schlägt die laufende Ermittlung fehl, protokolliere den Fehlschlag, verwende die genehmigten Ersatznachweise und erfinde weder eine Schnittstelle noch ein entferntes Verfahren. Parameterüberlagerungen müssen genau einen öffentlichen ausführbaren Befehlsendknoten und echte Schalter betreffen. Sie dürfen Beschreibungen, Schnittstellenzuordnungen, Pflichtzustände und bedingte Anforderungen präzisieren, aber keine Befehle oder Schalter anlegen, keine Schnittstelle definieren und keine unbekannte Remote-Prozedur ankündigen. ## Alle Ausgaben komplett neu erzeugen und auf Gleichheit prüfen Behandle die Erzeugung als vollständigen deterministischen Neuaufbau der Momentaufnahme und nicht als schrittweise Ergänzung eines früheren Katalogs. Lies jede geprüfte Eingabe erneut, nimm veraltete erzeugte Produktmetadaten außer Gebrauch und schreibe die genauen Ausgabeprojektionen neu. Erzeugte Dateien dürfen niemals zu Zusammenführungseingaben werden; Byte-Schutzprüfungen sollten fehlschlagen, wenn die Erzeugung verfasste Eingaben oder das geprüfte Register verändert. Verwende für jede Projektion dieselbe aufgelöste typisierte Werkzeugspezifikation. Die Nutzlast eines Befehlsendknotens muss seinem Eintrag im Gesamtexport und Katalog entsprechen, während Übersichts- und Gruppenzusammenfassungen der Zusammenfassungsprojektion desselben Werkzeugs entsprechen müssen. Eine Aliassuche darf nur aliasbezogene Ansichtsfelder ändern; sie darf den Befehlsvertrag weder erneut auflösen noch verändern. Bei jedem ausgelieferten Werkzeug- und Parameterfeld muss der ausgewählte Herkunftswert genau dem ausgelieferten Wert entsprechen. Nur den Quellennamen, die Anzahl der Kandidaten, das Vorhandensein des Feldes oder die Prüfsumme zu prüfen, reicht nicht aus. Führe die Erzeugung, Prüfungen der Laufzeitbestätigungswahrheit, Prüfungen der umgekehrten Vollständigkeit, gezielte Befehlsprüfungen und abschließende Prüfungen des eingebetteten Laders aus. Prüfe alle daraus entstehenden Unterschiede, bevor du die Momentaufnahme annimmst. ## Beispiele und Probeläufe ohne Überspringen oder --yes prüfen Speichere höchstens zwei geprüfte Beispiele je Werkzeug. Beispiele müssen einen echten Haupt- oder Aliaspfad, angenommene Schalter, erforderliche Positionsargumente und alle wirksamen Einschränkungen `require-one-of`, `require-together` und `mutual-exclusion` verwenden. Nimm keine Kommandozeilenkommentare oder Bestätigungsumgehungsschalter wie `--yes` auf. Jedes Beispiel muss die Vertragsprüfung anhand seines gebundenen Befehls bestehen. Ein fehlender Pflichtwert, eine verletzte Einschränkung, ein Laufzeitfehler oder ein Fehler bei der Schnittstellenauflösung ist ein Vertragsmangel und kein Grund, das Beispiel zu überspringen. Die Laufzeitausführung von Beispielen ist freiwillig und nur zulässig, wenn das endgültige typisierte Werkzeug eine ausdrücklich geprüfte Probelauffähigkeit veröffentlicht. Risiko- und Bestätigungsmetadaten dürfen keine Vorschaufähigkeit erfinden. Eine geprüfte manuelle Festlegung darf eine bestehende Probelauffähigkeit auf genau einen bei null beginnenden Beispielindex einschränken, muss jedoch einen genehmigten Begründungscode und eine konkrete Begründung verwenden und darf eine gewöhnliche Vertragsprüfung niemals in ein Überspringen verwandeln. Fange niemals einen fehlgeschlagenen Probelauf ab, um ihn dynamisch zu einer reinen Vertragsprüfung herabzustufen. Führe standardmäßig umfassende Vertragsprüfschranken aus; führe mit dem echten Befehl nur die geeignete Probelaufteilmenge aus und verwende dabei einen isolierten Benutzerzustand und gesperrte Vermittlungsserver. Behandle Änderungen stabiler Ausführungsanzahlen als prüfpflichtige Vertragsänderungen. ## Testen, welchen Befehl die KI wählt, ohne ihr die Antworten zu senden Behandle jedes positive Auswahlszenario als Zusicherung, dass sein geprüfter Befehl gewählt werden sollte, und jedes negative Szenario als Zusicherung, dass dieser Befehl nicht gewählt werden darf. Leite deterministische typisierte Prüffälle aus den verfassten Auswahlfeldern ab, verlange eine genaue Werkzeugabdeckung und ausführbare Hauptbefehle und lehne fehlende, doppelte oder widersprüchliche Erwartungen ab. Zeichenkettenabgleich allein beweist kein semantisches Verständnis. Halte Auswahlprüfungen mit einem laufenden Modell ausdrücklich freiwillig. Unterstütze eine kleine Stichprobe, einen vollständigen geprüften Satz und eine genaue Fallliste. Sende nur Fallkennungen, Szenariotext und eine Kandidatentabelle desselben Produkts an das Bewertungsprogramm; behalte erwartete und verbotene Zusicherungen lokal. Nimm eingebaute HTTPS-Bewertungsendpunkte in die Positivliste auf. Jeder andere HTTPS-Anbieter erfordert seine genaue Basis-URL in der genehmigten Positivliste; unverschlüsseltes HTTP ist nur für einen Schleifenrückführungs-Testserver zulässig. Sende API-Zugangsdaten niemals an einen beliebigen unverschlüsselten Endpunkt. Die normale fortlaufende Integration muss deterministisch bleiben und darf kein Modell aufrufen. Ihre sperrenden Prüfschranken sind reproduzierbare Prüffälle, Befehlsbindung, Beispielgültigkeit, Herkunftsnachweise und die Gleichheit der endgültigen Auslieferung. ## Sicherheit und Bestätigung nach dem Vorrang der Quellen festlegen Löse Sicherheits- und Parametermetadaten nach Quellenrangfolge auf und nicht danach, welcher Wert strenger erscheint. Eine höher eingestufte geprüfte Quelle darf Auswirkungen, Risiko, Bestätigung, Idempotenz, Beschreibungen oder Zuordnungen absichtlich erhöhen oder senken. Bewahre alle Kandidaten und die ausgewählte Quelle und lass Konflikte derselben Rangstufe fehlschlagen, statt sie stillschweigend zusammenzuführen. Erforderliche Befehlsschalter sind eine unverrückbare Untergrenze: Eine Überlagerung darf einen optionalen Schalter verpflichtend machen, aber niemals eine vom ausführbaren Befehl erklärte Anforderung abschwächen. Bevorzuge bei Befehlstexten zuerst geprüfte befehlsspezifische Hinweise, dann die Befehlshilfe und danach Schnittstellenmetadaten; allgemeiner Text für entfernte Verfahren darf eine spezialisierte Befehlsbeschreibung nicht überschreiben. Leite kein Sicherheitsfeld aus einem anderen ab. Eine zerstörerische Auswirkung oder ein hohes Risiko schreibt die Bestätigung nicht mechanisch um. Die Bestätigung muss der ausdrücklichen Laufzeitschranke entsprechen; eine erforderliche Nutzerbestätigung muss eingeholt werden, bevor ein Umgehungsschalter wie `--yes` hinzugefügt wird. Wenn ausgelieferte Befehlshilfe und Befehlsendknotenschema voneinander abweichen, übergib nur Schalter, die der ausführbare Befehl annimmt. Widersprechen sich Sicherheitsquellen, verwende die sicherere Auslegung oder halte an und melde die Vertragsabweichung. Prüfe die Bedeutung der Bestätigung über den endgültigen eingebetteten Lader und Abfragepfad und nicht nur in einer Einzelprüfung des Erzeugungswerkzeugs. ## Befehle schrittweise erkunden und Daten mit echten Befehlen holen Halte die gewöhnliche Auffindung schrittweise: zuerst Übersicht, dann Produkt oder Gruppe und schließlich Befehlsendknoten. Reserviere den Gesamtexport als stabilen Verträglichkeitsvertrag und nimm für jedes endgültige Werkzeug vollständige Parameter, Einschränkungen und Sicherheitsbedeutungen auf, einschließlich eines leeren Parameterobjekts für Befehle ohne Schalter. Ein verdichteter Gesamtexport ist keine vollständige Verträglichkeitsgrundlage. Die Befehlshilfe bestimmt, ob ein Pfad vorhanden ist und welche Schalter das ausführbare Programm annimmt. Das Befehlsendknotenschema bestimmt Agentenauswahl, Parameterzuordnung und -einschränkungen sowie die Bedeutung von Sicherheit und Bestätigung. Jede Abweichung ist eine Vertragsabweichung und keine Erlaubnis zum Raten. Schemata und Hilfe beschreiben Befehle; sie liefern keine Geschäftsdaten. Führe nach der Auffindung den passenden echten Lese-, Such- oder Auflistungsbefehl innerhalb seiner bestätigten Berechtigungen aus, um Daten abzurufen. Bestätige vor der Auslieferung, dass Befehlsidentitäten geprüft sind, die ausführbare Abdeckung beidseitig ist, Ausschlüsse genau sind, verfasste Blöcke getrennte Zuständigkeiten behalten, die Quellenrangfolge gewahrt ist, erzeugte Ausgaben ausschließlich Ausgaben bleiben, Beispiele ihre echten Verträge bestehen, die Bestätigung den Laufzeitschranken entspricht und jede Projektion derselben typisierten Quelle gleicht.