Einen Programmieragenten-Dienst bauen, der Anfragen aus Chat und Vorgangsverwaltung annimmt

## Jeder Laufzeitrolle eine Aufgabe geben und die Prüfrolle nur lesen lassen Weise jeder Laufzeitrolle genau eine klare Verantwortung zu: - Ein Hauptgraph für Programmieragenten erstellt für jeden Thread einen neuen Agenten, während der dauerhafte Zustand in der threadbezogenen Ausführungsumgebung und den Metadaten verbleibt. - Ein Prüfgraph führt ausschließlich lesende Codeprüfungen mithilfe eines Feststellungsmodells und einer eigenen Veröffentlichungsaktion durch, ohne Werkzeuge zum Ändern, Erstellen von Commits, Übertragen oder Eröffnen von Prüfungen. - Ein Analysegraph erstellt im Erstaufbau und beim fortlaufenden Lernen repositoriespezifische Prüfleitlinien und speichert sie mit einem einzigen dafür vorgesehenen Werkzeug. - Eine Webanwendung empfängt Webhooks der Codeplattform, Vorgangsverwaltung und Chatdienste, bestimmt einen stabilen Thread und startet oder überträgt den zugehörigen Graphlauf fortlaufend. - Eine Verwaltungsoberfläche verwaltet Anmeldung, Benutzerprofile, Teamvorgaben, aktivierte Repositories, die Verwaltung des Prüfstils und die von der Oberfläche verwendete Thread-API. Stelle Analyseverfahren als versionierte, schreibgeschützte virtuelle Fähigkeiten bereit, statt sie in jede Ausführungsumgebung zu kopieren. Registriere die geplante fortlaufende Verfeinerung erst nach Abschluss des Erstaufbaus. Fasse alle Grapheinstiegspunkte und Anwendungsrouten in einem Laufzeitmanifest zusammen, erlaube aber sowohl eine vollständige Entwicklungslaufzeit als auch einen eingeschränkteren, ausschließlich für das Web bestimmten Prozess. ## Einen festen Satz Entwicklungswerkzeuge wählen und zuerst den kleinsten Test ausführen Lege genau einen Abhängigkeitsmanager, ein Testausführungssystem, ein Prüfwerkzeug, ein Formatierungswerkzeug, eine Typprüfung, eine Mindestversion der Programmiersprache und eine Version der bereitgestellten Laufzeit fest. Das Repository muss sowohl für die unterstützte Mindestversion als auch für jede neuere Version gültig bleiben, die in den Bereitstellungsmetadaten festgeschrieben ist. Dokumentiere Befehle für: 1. die Installation der Entwicklungsabhängigkeiten; 2. den Start der vollständigen Graph- und Weblaufzeit; 3. den ausschließlichen Start der Webanwendung; 4. die Ausführung des vollständigen Verzeichnisses der Modultests; 5. die Ausführung einer einzelnen Testdatei oder eines einzelnen Testfalls; 6. die Prüfung von Stil und Formatierung ohne Änderungen; 7. die Anwendung des Formatierungswerkzeugs und sicherer automatischer Korrekturen; 8. die Typprüfung von Produktions- und Testcode. Verwende standardmäßig Modultests. Reserviere ein eigenes Verzeichnis für Integrationstests und behandle das Fehlen einer Integrationssammlung als ausdrücklich festgelegten Leerlauf statt als mehrdeutigen Fehler. Führe während der Entwicklung vor umfassenden Repository-Prüfungen zunächst einen einzelnen Test oder die kleinste relevante Testsammlung aus. ## Pro Thread eine Sandbox halten und sie bei Fehlern neu anlegen Halte einen prozessinternen Zwischenspeicher für Ausführungsumgebungen vor, der über die Threadkennung indiziert wird, und speichere die Kennung der Ausführungsumgebung in den Threadmetadaten. Behandle den Lebenszykluszustand ausdrücklich: 1. Wenn eine Ausführungsumgebung zwischengespeichert ist, prüfe ihre Erreichbarkeit; erstelle sie neu, wenn die Prüfung fehlschlägt, und erneuere bei einem fehlerfreien Zustand ihren authentifizierten Netzwerkproxy. 2. Wenn die Metadaten einen Markierungswert für die Erstellung enthalten, aber keine Ausführungsumgebung zwischengespeichert ist, entferne den veralteten Markierungswert, bevor du einen Ersatz erstellst. 3. Wenn keine Ausführungsumgebung vorhanden ist, schreibe den Markierungswert für die Erstellung, erstelle die Ausführungsumgebung und ersetze den Markierungswert durch die tatsächliche Kennung. 4. Wenn die Metadaten eine Kennung enthalten, der Prozesszwischenspeicher aber leer ist, stelle die Verbindung erneut her und weiche auf eine Neuerstellung aus, falls die Wiederverbindung fehlschlägt. Beschaffe bei Anbietern, die einen authentifizierten Proxy unterstützen, bei jeder Erstellung oder Erneuerung neue, kurzlebige Installationszugangsdaten. Lasse den Proxy die Authentifizierung für Codeplattform und API einfügen, damit Befehle in der Ausführungsumgebung einen harmlosen Platzhalter verwenden können, statt die echten Zugangsdaten zu speichern. Anbieter ohne diese Möglichkeit müssen den Proxypfad ausdrücklich überspringen. Wende die Identitätskonfiguration der Automatisierung bei jedem Lauf erneut an. Wiederverwendete oder erneut verbundene Umgebungen können globale Einstellungen verlieren, und nachgelagerte Bereitstellungsprüfungen können Commits ablehnen, deren Urheberidentität nicht erkannt wird. ## Die Middleware um Modellaufrufe in fester Reihenfolge ausführen Führe Zwischenschichten um Modellaufrufe herum in einer bewusst festgelegten Reihenfolge aus: 1. Werkzeugeingaben bereinigen und vereinheitlichen; 2. die Zahl der Modellaufrufe begrenzen und beim Erreichen der Grenze geordnet beenden; 3. Werkzeugausnahmen in Werkzeugmeldungen umwandeln; 4. zutreffende Anweisungen übergeordneter Verzeichnisse einmal je Lauf an Dateilesevorgänge anhängen; 5. während des Laufs eingegangene Vorgangs- oder Chatnachrichten vor dem nächsten Modellaufruf einfügen; 6. externe Statusanzeigen des Assistenten aktualisieren; 7. eine leere Modellantwort durch einen künstlich erzeugten Werkzeugaufruf zum Fortsetzen oder Bestätigen des Abschlusses ersetzen; 8. den Ursprungskanal benachrichtigen, wenn die Gesamtgrenze für Arbeitsschritte erreicht ist; 9. nach wiederholten Ausfällen der Ausführungsumgebung einen Schutzschalter auslösen; 10. nur dann ein Ersatzmodell hinzufügen, wenn ein davon verschiedenes Ersatzmodell konfiguriert ist; 11. fehlerhafte anbieterspezifische Schlussfolgerungsblöcke unmittelbar vor Anbieteraufrufen entfernen. Verbinde die Systemanweisung zum selbstständigen Weiterarbeiten mit der Absicherung gegen leere Antworten, damit die Arbeit nicht stillschweigend endet. Halte die Zwischenschichten des Prüfers schlanker, wenn er keine bereichsbezogenen Dateianweisungen, keine Einfügung aus der Nachrichtenwarteschlange, kein Ersatzmodell und keine Wiederherstellung der Ausführungsumgebung benötigt. Das bloße Vorhandensein einer ungenutzten Zwischenschicht aktiviert sie nicht; registriere neue Zwischenschichten ausdrücklich an der richtigen Position. ## Jeder Rolle nur die Werkzeuge geben, die sie braucht Pflege ein kleines, flaches Register eigener Werkzeuge. Der Hauptagent darf genehmigte Netzwerkanfragen, Suche, Aktionen in der Vorgangsverwaltung, Prüfanforderungen, geplante Wiederaufnahmen und Chatantworten erhalten. Der Prüfer darf ausschließlich lesende Netzwerkwerkzeuge sowie Werkzeuge zum Erstellen, Aktualisieren und Auflisten von Feststellungen und zum Veröffentlichen von Prüfungen erhalten. Der Analysegraph darf ausschließlich die Aktion erhalten, die zum Speichern von Prüfleitlinien erforderlich ist. Lasse das Agentenrahmenwerk allgemeine Werkzeuge für Dateien, Befehlszeile, Suche, Aufgaben und Planung bereitstellen. Dupliziere diese Werkzeuge nicht im eigenen Register. Verlasse dich nicht auf ein nachgelagertes Sicherheitsnetz, um Arbeit zu veröffentlichen. Der Arbeitsablauf des Agenten muss jeden autorisierten Commit, jeden Push, jede Eröffnung oder Aktualisierung einer Prüfung und jede Antwort an den Ursprungskanal ausdrücklich ausführen. Ein ausschließlich lesender Prüfer darf diese Änderungsfähigkeiten niemals erben. ## Das Modell in fester Reihenfolge wählen und Zugangsdaten verschlüsseln Bestimme Modell und Schlussfolgerungsaufwand für jeden Lauf in dieser Reihenfolge: 1. die durch das auslösende Ereignis oder die Oberfläche bereitgestellte threadbezogene Konfiguration; 2. die Überschreibung im Profil des ermittelten Benutzers; 3. die Teamvorgabe. Fasse unterstützte Modellkennungen, Regeln für den Schlussfolgerungsaufwand, Anbieterargumente, Modellerstellung und Auswahl des Ersatzmodells zentral zusammen. Lege Verhaltensschalter, etwa die Erlaubnis zum automatischen Erstellen von Prüfungen, im Benutzerprofil ab, statt sie über den Webhook-Code zu verstreuen. Verschlüssele die Autorisierungszugangsdaten der Benutzer im Ruhezustand und speichere sie während eines Laufs nur prozessintern zwischen. Wenn keine Benutzerzugangsdaten verfügbar sind, weiche auf kurzlebige Installationszugangsdaten der Anwendung aus. Verwende dieselben Anwendungszugangsdaten zur Konfiguration eines authentifizierten Proxys für die Ausführungsumgebung, speichere die unverschlüsselten Zugangsdaten jedoch niemals innerhalb der Ausführungsumgebung. Prüfe die Echtheit eines Webhooks, bevor du das Ereignis weiterleitest. Belasse Signaturprüfungen der Codeplattform, Chatverifizierung, Verifizierung der Vorgangsverwaltung und die Anmeldeverarbeitung der Verwaltungsoberfläche jeweils in ihrem zuständigen Modul. ## Folgenachrichten zum selben Thread und zur selben Sandbox zurückleiten Leite stabile Threadkennungen aus der externen Gesprächsidentität ab, damit jede Folgenachricht zu demselben Vorgang, Chatthread, Zweig oder derselben Prüfung in denselben Agentenzustand und dieselbe Ausführungsumgebung zurückkehrt. Weise Prüfläufen einen eigenen deterministischen Namensraum zu und kennzeichne ihre Threadart in den Metadaten. Wenn während eines Laufs Nachrichten eingehen, lege sie in der Threadwarteschlange ab und füge sie vor dem nächsten Modellaufruf ein. Dadurch bleibt der Zusammenhang erhalten, ohne den aktuellen Lauf abzubrechen oder einen konkurrierenden Agenten zu erstellen. Richte Statusaktualisierungen an den Grenzen der Modellaufrufe aus, damit externe Benutzer zwischen aktiver Arbeit, Abschluss und Beendigung wegen der Arbeitsschrittgrenze unterscheiden können. ## Die automatische CI-Reparatur nur laufen lassen, wenn sie eingeschaltet ist Ein automatisierter Reparaturablauf darf auf fehlgeschlagene Prüfungen, Zusammenführungskonflikte oder umsetzbare Rückmeldungen zu einer von einem Agenten verfassten Prüfung reagieren. Ermittle den Ursprungsthread über dauerhafte Prüfmetadaten und starte anschließend im Hauptgraph des Agenten einen durch eine Vertrauensschwelle abgesicherten Reparaturlauf. Verlange eine mehrstufige Aktivierung: - eine benutzerbezogene Automatisierungskennzeichnung; - die ausdrückliche Teilnahme des Repositories; - eine prüfungsbezogene Ein- oder Ausschaltüberschreibung. Fasse Regeln zum Überspringen zentral zusammen: Fehler, die bereits im Basiszweig vorhanden sind, von Menschen verfasste Commits, wiederholte Verarbeitung derselben Kopfversion, Bündelung während eines bereits aktiven Reparaturlaufs und eine feste Schleifengrenze. Verwende eine regelmäßige Überwachung nur als Rückfalllösung, die offene, von Agenten verfasste Prüfungen nach verpassten Ereignissen durchsucht. ## Neue Anbieter und Werkzeuge in ihren Registern ergänzen und den Code asynchron halten Füge einen Anbieter für Ausführungsumgebungen in dessen Integrationsmodul hinzu und registriere ihn in der Fabrikzuordnung der Anbieter. Füge ein eigenes Werkzeug im Werkzeugpaket hinzu, exportiere es genau einmal und nimm es ausschließlich in die rollenbezogene Werkzeugliste auf, die es benötigt. Füge eine Zwischenschicht in einem eigenen Modul hinzu, exportiere sie und platziere sie bewusst im geordneten Stapel. Füge Endpunkte der Verwaltungsoberfläche dem eingebundenen Router und neue Graphen dem Laufzeitmanifest hinzu. Halte eine ausschließlich asynchrone Anwendung durchgängig asynchron. Erstelle keine parallelen synchronen Implementierungen. Lasse die synchrone Methode weg, wenn die Schnittstelle dies erlaubt; wenn ein abstrakter Vertrag sie verlangt, stelle nur eine minimale Methode bereit, die einen Fehler für nicht unterstützte Vorgänge auslöst. Verwende standardmäßig Modultests, nutze den eigenen Integrationstestbereich für echte Integrationen und setze Kommentare sparsam ein. Kommentare sollen einen nicht offensichtlichen Grund oder eine Reihenfolgebedingung erklären, nicht die Implementierung wiederholen.