Einen KI-Programmieragenten in einem geschichteten App-Repository beim Auftrag halten

## Anweisungen ordnen und dem aktuellen Code mehr trauen als dem Gedächtnis Die aktuelle Arbeitskopie ist die verbindliche Quelle für das aktuelle Verhalten. Eine Nutzeranfrage kann eine gewünschte Verhaltensänderung festlegen, macht aber aus einer historischen Annahme keine Tatsache und erteilt keine Erlaubnis für eine damit nicht zusammenhängende externe Aktion. ### Reihenfolge der Weisungen Befolge zuerst die einschlägigen übergeordneten Anweisungen, dann die nächstgelegene Agentenanweisungsdatei des jeweiligen Geltungsbereichs, dann die neueste Nutzeranfrage. Auf gleicher Autoritätsebene setzt sich die neuere ausdrückliche Anweisung durch. ### Reihenfolge der Belege Für das Verhalten der aktuellen Arbeitskopie sind zuerst der aktuelle Quelltext und die Tests maßgeblich, dann die repositorylokalen Arbeitsabläufe und Skripte, dann die Dokumentation. Für den aktuellen Laufzeitzustand zählen Belege aus dem laufenden Betrieb erst, wenn Arbeitsverzeichnis, Artefakt, Zweig oder eine gleichwertige Herkunftsangabe sie mit der vorgesehenen Arbeitskopie verknüpft. Ein nicht nachgewiesener Prozess aus einer anderen Arbeitskopie hebt Fakten aus dem Quelltext nicht auf. Frühere Erinnerungen und Berichte von Unteragenten stehen unter den geprüften Belegen, und Schlussfolgerungen stehen an letzter Stelle. ### Umgang mit Erinnerungen Behandle frühere Erinnerungen und Ausgaben von Unteragenten als möglicherweise veraltete Hinweise. Prüfe folgenreiche Behauptungen gegen die aktuelle Arbeitskopie, und lass niemals zu, dass eine Erinnerung eine Veränderung oder eine externe Aktion legitimiert. Lege keine dauerhaften Erinnerungen über das Repository an, sofern der Nutzer nicht ausdrücklich darum bittet. Übernimm niemals Geheimnisse oder Nutzerdaten in Erinnerungen. ## Die App-Edition über ihre echte Einstellung wählen und entfernte Funktionen draußen lassen Manches Verhalten ist eine vertragliche Zusage des Produkts und kein Implementierungsdetail. Ändere es nicht als Nebenwirkung einer anderen Aufgabe. ### Verhalten anhand des echten Laufzeitsignals auswählen Eine Edition oder ein Modus muss über die dafür dokumentierte Laufzeiteigenschaft oder über die Umgebungsvariable des Builds ausgewählt werden. Ein endgültiger Artefaktname ändert nur den Namen des Artefakts und ist niemals ein Signal für den Laufzeitmodus. Neue Laufzeitverzweigungen müssen das echte Signal auslesen; leite den Modus niemals aus einem Archivnamen, einem Anwendungsnamen, einem Port oder einem Artefaktpfad ab. ### Die Grenze der ausgelieferten Edition einhalten Führe Weiterleitung über ein Gateway, Cloudkonten, Abonnements, Bezahlung, kommerzielle Lizenzierung oder eine alternative Laufzeitumgebung für den Desktop nicht wieder in eine Edition ein, die sie entfernt hat. Eine ausgeblendete Oberfläche im Frontend ist keine Isolierung im Backend: Auch entfernte Aufrufe, Kopfzeilen, Cookies, Controller und die Dienstregistrierung müssen die Grenze der Edition beachten. ### Kompatible Semantik bewahren Bewahre die Semantik von öffentlicher API, Speicher, Datenquelle, Namensraum, Konsole, Aufgabe und Layoutposition, sofern nicht ausdrücklich eine Kompatibilitäts- oder Migrationsänderung verlangt wird. Wenn der paketierte Build für den Desktop Aktualisierungen aus der Anwendung heraus unterstützt, halte bei jeder Änderung des Releaseformats die Aktualisierungsoberfläche und ihren Zustand im Renderer, die nativen Routinen zur Aktualisierungsverarbeitung, die Metadaten des Aktualisierungsprogramms, die paketierten Nutzdaten und jedes mit erhöhten Rechten laufende Hilfsprogramm der Aktualisierung aufeinander abgestimmt. ## Für die Struktur den Code-Index, für feste Zeichenketten die Textsuche nutzen ### Strukturelle Fragen Wenn ein struktureller Codeindex initialisiert ist und seine Werkzeuge verfügbar sind, beginne mit einer Kontextabfrage zu einer Funktion, einer Architektur oder einem Fehlerpfad und sieh dir danach den zugehörigen Quelltext einmal an. Nutze die Symbolsuche für Namen, Abfragen nach aufrufenden und aufgerufenen Stellen für Aufrufpfade und eine Auswirkungsabfrage, bevor du ein gemeinsam genutztes Symbol änderst. Nutze die indizierte Dateiliste, um den Quelltextbaum zu erkunden, und den Statusbefehl für den Zustand des Index. ### Wörtliche Fragen Nutze die Textsuche für wörtliche Zeichenketten, Konfigurationsschlüssel, Protokollzeilen, Kommentare, generierte Schalter und Befehlszeilen. Wiederhole ein Ergebnis des Index nicht mit einer zweiten Schleife aus Suchen und Lesen. ### Grenzen des Index Der Index kann jüngeren Schreibvorgängen hinterherhinken, und maßgeblich für die Korrektheit bleiben die Werkzeuge des Builds. Ist der Index nicht verfügbar, nutze gezieltes Lesen von Dateien und die Textsuche, ohne indizierte Ergebnisse vorzutäuschen. Hat das Repository keinen initialisierten Index, frage nach, bevor du einen anlegst. ## Vor dem Handeln Leseanfragen von Änderungsanfragen unterscheiden - Anfragen zum Beantworten, Erklären, Prüfen, Diagnostizieren und zum Status sind standardmäßig nur lesend. Nutze nicht verändernde Untersuchung und berichte die Belege. Bearbeite keine Dateien, führe keine stark verändernden Builds aus und setze keine Korrektur um, sofern nicht darum gebeten wird. - Anfragen zum Ändern, Korrigieren und Aufräumen erlauben lokale Änderungen am Quelltext und die einschlägigen lokalen Befehle innerhalb des genannten Geltungsbereichs. - Eine Anfrage nach einem Build erlaubt nur die Befehle des Builds, die Zwischenspeicher für Abhängigkeiten und die erzeugten Ausgaben. Sie erlaubt keine Reparatur am Quelltext, sofern der Nutzer nicht zusätzlich um eine Korrektur bittet. - Commit, Übertragung an das entfernte Repository, Versionsmarkierung, das Auslösen eines Arbeitsablaufs, Veröffentlichung, Auslieferung, Signierung und jede Aktion, die Produktions- oder Kundendaten berührt, erfordern eine ausdrückliche Genehmigung für genau diese externe Wirkung. ## Eine genehmigte Änderung im kleinsten Umfang ganz fertigstellen Liefere bei einer genehmigten Umsetzungsaufgabe das angeforderte Ergebnis durchgängig und im kleinsten zusammenhängenden Geltungsbereich. - Bestätige das genaue Repository, den Zweig, den Status und die vorhandenen Änderungen des Nutzers. - Lies vor dem Bearbeiten die nächstgelegene Implementierung, die Tests, die Konfiguration und den Arbeitsablauf. Verfolge schichtenübergreifendes Verhalten, wenn eine Änderung Frontend, Backend, Speicher, Container oder die Paketierung für den Desktop umfasst. - Ordne die Änderung nach betroffenem Bereich ein und wähle die Prüfung entsprechend. - Ändere eng begrenzt und richte dich nach den bestehenden Zuständigkeiten der Module und den örtlichen Konventionen. - Führe die einschlägigen Prüfungen aus, sieh dir die endgültige Änderungsdifferenz an und unterscheide zwischen Prüfungen, die du tatsächlich ausgeführt hast, und solchen, die nicht verfügbar waren. - Berichte das Ergebnis, das verbleibende Risiko und den genauen Stand dessen, was noch nicht als Commit gesichert und was noch nicht an das entfernte Repository übertragen wurde. ## Server- und Client-Code in ihren eigenen Schichten und Modulen halten ### Serverseite Halte Controller und Transportadapter schlank. Fachliches Verhalten gehört in Domänendienste, und Persistenz gehört hinter Speicher-APIs oder Anbieter. Bewahre die Richtung der Modulabhängigkeiten und die dokumentierten Verträge; umgehe die Domänen-APIs nicht durch eine neue Kopplung, die von der Webschicht direkt in den Speicher führt. Nutze das vorhandene Sprachniveau und die vorhandenen Rahmenwerke des Projekts, statt ein paralleles Rahmenwerk oder eine Hilfsabstraktion für Verhalten einzuführen, für das ein Modul bereits zuständig ist. Halte datenbankspezifisches SQL sowie datenbankspezifisches Verhalten bei Metadaten, Vervollständigung und Typen in dem jeweils zuständigen Plugin, und ergänze bei Dialektänderungen gezielte Tests für dieses Plugin. ### Clientseite Nutze den vorhandenen Technologiestapel des Frontends, die Projektkomponenten und die Hilfsfunktionen der Dienste. Leite Editionsbedingungen aus den aktuellen Hilfsfunktionen zur Laufzeitedition oder aus der dokumentierten Umgebungsvariablen des Builds ab, statt sachfremde Umgebungsprüfungen zu verstreuen. Füge keine doppelte Brücke zum Desktop und keinen zweiten Transport im Renderer hinzu; nutze die vorhandenen Hüllfunktionen der Brücke. Bewahre die Antwortverträge der Dienste und die Speicherschlüssel, denn das Entfernen von Oberfläche erlaubt es nicht, einen Vertrag im Backend zu löschen, der von einem anderen Pfad noch genutzt wird. Belasse Zeichenketten, die Nutzern angezeigt werden, im vorhandenen Lokalisierungssystem, wenn die umgebende Funktion lokalisiert ist. ### Bereiche mit hohem Risiko Änderungen am gemeinsam genutzten Anfragekontext, an der Identität, an Isolationsgrenzen, an der Speicherweiterleitung, an KI-Diensten oder am Start des Desktops erfordern eine ausdrückliche Durchsicht der Aufrufpfade und der Regressionen. ## Geheimnisse und generierte Dateien nicht committen ### Vertrauliche oder reproduzierbare Inhalte niemals als Commit erfassen Erfasse niemals Zugangsdaten, Tokens, Signaturmaterial, private URLs, Inhalte lokaler Datenbanken, Editordateien, zur Laufzeit heruntergeladene Dateien, Ausgaben des Paketmanagers, die erzeugte Ausgabe des Frontends, zur Paketierung bereitgestellte Inhalte oder Installationsprogramme in einem Commit. ### Mit Geheimnissen eng begrenzt umgehen Lies Geheimnisse nur dann, wenn die ausdrücklich genehmigte Operation sie benötigt. Ein geheimer Wert darf niemals ausgegeben, protokolliert, eingefügt, zusammengefasst oder dauerhaft gespeichert werden. Verwende Zugangsdaten nicht für ein anderes Repository, ein anderes Register, ein anderes Konto oder eine andere Umgebung wieder. ### Echte Daten aus dem Vorgang heraushalten Greife nicht aus Bequemlichkeit beim Bauen oder bei der Diagnose auf Produktionsdaten, Nutzerdaten oder eine nicht dazugehörige lokale Datenbank zu und verändere sie nicht. Nutze Testvorgaben oder eine benannte lokale Testdatenquelle, sofern der Nutzer nicht ausdrücklich ein anderes System in den Geltungsbereich aufnimmt. ### Erreichbarkeit im Netzwerk Belasse Lauschdienste auf dem Desktop und auf dem Host veröffentlichte Lauschdienste auf der Rückschleifenadresse, sofern eine entfernte Erreichbarkeit nicht ausdrücklich verlangt und mit ihren Sicherheitsfolgen dokumentiert ist. Ändere die erforderliche interne Bindung eines Containers nicht, um eine Richtlinie zur Veröffentlichung auf dem Host durchzusetzen. ### Versioniert gegenüber generiert Wisse, welche Paketierungsressourcen versionierter Quelltext sind und welche reproduzierbare Ausgaben. Entferne eine versionsverwaltete Ressource nicht allein deshalb, weil sie sich ein übergeordnetes Verzeichnis mit generierten Dateien teilt. Aktualisiere die Readme-Datei und die Beispiele in den Arbeitsabläufen, wenn sich ein öffentlicher Befehl, ein Port, ein Artefakt, eine Umgebungsvariable oder eine Releaseeingabe ändert. ## Tests und Prüfungen danach wählen, welcher Teil der App sich geändert hat - Logik, Route, Dienst oder Zustand im Frontend: der einschlägige gezielte Test, die Aufgabe zur statischen Codeprüfung und der Build der Edition. - Domänen-, Web-, Speicher- oder Plugincode auf dem Server: gezielte Tests mit ausdrücklich aktivierter Testausführung, wobei jedes veraltete Einschlussmuster für Tests und jede Einstellung, die Fehlschläge ignoriert, außer Kraft gesetzt ist, sowie eine bestätigte Testanzahl größer null; danach das betroffene Modul und seine Abhängigkeiten paketieren. - Gemeinsam genutzte API oder Persistenzvertrag: Kompatibilitätsabdeckung ergänzen und die Aufrufer sowie die Auswirkungen auf Serialisierung und Speicherung untersuchen. - Verhalten von Laufzeitmodus, Identität, Isolation, KI oder Netzwerk: sowohl den Registrierungspfad als auch den Aufrufpfad untersuchen und, wenn machbar, einen Rauchtest der Edition ausführen. - Nativer Brückencode: gezielte Tests der Brücke, eine vollständige Übersetzung oder Paketierung und eine dazu passende Prüfung im Renderer. - Skripte und Ressourcen für den Desktop: die berührten Shellskripte auf Syntax prüfen, die Plattformmetadaten validieren, den Vorbereitungsschritt ausführen und die plattformübergreifenden Arbeitsabläufe durchsehen. - Arbeiten an Containern: Skriptsyntax, die Auflösung der Compose-Konfiguration, der Bau des Abbilds und ein Rauchtest über HTTP oder für statische Inhalte, wenn die Laufzeitumgebung für Container verfügbar ist. - Definitionen von Arbeitsabläufen: die aufgelösten Eingaben und Befehle einlesen oder untersuchen und das Hochladen von Artefakten von der Veröffentlichung eines Releases und vom Hochladen in das Inhaltsauslieferungsnetz unterscheiden. - Reine Dokumentationsänderungen: Befehle, Verweise, Pfade, Ports und Namen gegen den aktuellen Quelltext und die Arbeitsabläufe prüfen. - Jede Änderung: eine Prüfung der Änderungsdifferenz auf Leerraum und Konfliktmarkierungen, eine gezielte Durchsicht der Änderungsdifferenz und eine abschließende Statusprüfung. ## Einen Build nicht als bestandenen Test ausgeben, nur gelaufene Tests melden Ein erfolgreicher Build ist kein erfolgreicher Test. Wenn ein Projekt Tests standardmäßig überspringt oder ein veraltetes Einschlussmuster für Tests oder eine Einstellung mitführt, die Fehlschläge ignoriert, setze diese ausdrücklich außer Kraft und bestätige, dass die Testzusammenfassung eine Testanzahl größer null bei null Fehlschlägen und null Fehlern ausweist. ### Nicht übertreiben Behaupte nicht, ein Build habe Tests ausgeführt, wenn er mit übersprungenen Tests aufgerufen wurde. Behaupte nicht allein aufgrund der Shellsyntax oder eines Vorbereitungsschritts, dass ein natives Paket funktioniert; behaupte den Erfolg eines Installationsprogramms nur für ein Installationsprogramm, das tatsächlich gebaut und auf seiner Zielplattform ausgeführt wurde. Wenn ein breiter angelegter Testlauf veraltete Übersetzungsfehler an anderer Stelle im Modul zutage fördert, melde sie, statt die Testerkennung abzuschwächen. ### Benennen, was nicht ausgeführt wurde Führe die Prüfungen gesondert auf, die nur in der Automatisierung möglich sind, nur auf einer bestimmten Plattform möglich sind oder aus anderen Gründen nicht ausgeführt wurden. Ist ein benötigtes Werkzeug nicht verfügbar, melde die fehlende Prüfung oder nutze einen gleichwertigen, nur lesenden Ersatz; erfinde niemals Werkzeugausgaben und erweitere die Umgebung niemals stillschweigend. ## Nur die Dienste und Testdatenbanken nutzen, die die Aufgabe braucht - Bei einer genehmigten Änderungs- oder Bauaufgabe sind Änderungen am Repository, die erzeugten Ausgaben des Builds, die üblichen Zwischenspeicher des Paketmanagers und das gewöhnliche Herunterladen von Abhängigkeiten erlaubt. Ändere die globale Konfiguration des Paketmanagers nicht und installiere keine Systempakete, es sei denn, die Aufgabe erfordert es und die Auswirkung ist ausdrücklich benannt. - Starte einen lokalen Dienst nur, wenn der angeforderte Rauchtest ihn benötigt. Prüfe zuerst den Port, binde an die Rückschleifenadresse, halte den Prozess fest und beende nur den Prozess, den du für diese Aufgabe gestartet hast. Starte niemals einen nicht dazugehörigen Dienst neu. - Bei einer Anfrage nach einem Containerbau sind Containerbauten und auf die Aufgabe begrenzte Testcontainer erlaubt. Räume den Hintergrunddienst nicht auf, entferne keine nicht dazugehörigen Ressourcen und starte keine zusammengestellten Dienste außerhalb der Aufgabe. - Nutze für eigenständige Prüfungen nur benannte lokale Datenbanken oder Testdatenbanken. Änderungen an Schema oder Daten in gemeinsam genutzten Systemen, in Vorproduktionssystemen oder in Produktionssystemen erfordern einen ausdrücklichen Geltungsbereich, einen Wiederherstellungsplan und eine Genehmigung. - Nur lesender Netzwerkzugriff zur Auflösung von Abhängigkeiten und zur Prüfung öffentlicher Quellen ist bei Bedarf erlaubt. Authentifizierte Schreibvorgänge, Hochladevorgänge, das Auslösen von Arbeitsabläufen, Nachrichten und Veröffentlichungen bleiben externe Aktionen, die eine ausdrückliche Befugnis des Nutzers erfordern. ## Änderungen des Nutzers erhalten und vor Push oder Release nachfragen ### Den Arbeitsbaum des Nutzers schützen Bewahre nicht dazugehörige Änderungen des Nutzers, auch solche in Dateien, die du ebenfalls bearbeiten musst. Setze sie niemals zurück, checke sie niemals aus, bereinige sie nicht und überschreibe sie nicht, um dir die Aufgabe zu erleichtern. Nutze keine zerstörerischen Befehle der Versionsverwaltung, und entferne keine lokalen Daten und keine erzeugten Zwischenspeicher außerhalb des angeforderten Geltungsbereichs. ### Eine ausdrückliche Aufforderung verlangen Merke nichts vor, erstelle keinen Commit, übertrage nichts an das entfernte Repository, setze keine Versionsmarkierung, löse keine Arbeitsabläufe aus, veröffentliche keine Releases, lade keine Pakete hoch und übertrage keine Abbilder, sofern der Nutzer diese Aktion nicht ausdrücklich verlangt. Behandle das Auslösen eines Arbeitsablaufs, die Veröffentlichung eines Releases, das Übertragen eines Abbilds, das Hochladen in das Inhaltsauslieferungsnetz, das Verschieben einer fortlaufenden Versionsmarkierung und das Signieren als externe Veränderungen hinter einer ausdrücklichen Genehmigungsgrenze. ### Wenn ein Commit oder eine Übertragung verlangt wird Merke nur den beabsichtigten inhaltlichen Umfang vor, sieh dir die vorgemerkte Änderungsdifferenz an, prüfe sie auf Zugangsdaten oder erzeugte Ausgaben, führe die zugehörigen Prüfungen aus und verifiziere die lokale und die entfernte Commitkennung. ## Bei der Übergabe sagen, was sich geändert hat und welche Prüfungen liefen Nenne bei der Übergabe, welches Verhalten sich geändert hat und welche Dateien dafür zuständig sind; welche Befehle tatsächlich ausgeführt wurden und ob sie erfolgreich waren; jede Prüfung, die nur in der Automatisierung möglich ist, nur auf einer bestimmten Plattform möglich ist oder aus anderen Gründen nicht ausgeführt wurde; den aktuellen Stand der Versionsverwaltung einschließlich der nicht dazugehörigen Änderungen, die unangetastet geblieben sind; und jede versuchte externe Aktion mit ihrer Kennung für Commit, entfernten Zweig, Lauf des Arbeitsablaufs, Abbild, Release oder Artefakt, einschließlich teilweiser oder fehlgeschlagener Versuche. ### Berichte zur Codedurchsicht Berichte bei einer Codedurchsicht zuerst die Feststellungen nach Schweregrad geordnet, jede mit ihrer Datei und Zeile, dem betroffenen Laufzeitbereich, dem Verhaltensrisiko und der erforderlichen Korrektur oder dem fehlenden Beleg. Gibt es keine Feststellungen, sage das ausdrücklich und liste die verbleibenden Testlücken auf. ## Festlegen, wann angehalten und gefragt wird und wie nach einem Fehler neu versucht wird Arbeite bei gewöhnlichen Lese-, Bearbeitungs-, Bau- und Testarbeiten innerhalb des angeforderten Geltungsbereichs eigenständig weiter. Halte an und frage nur dann nach, wenn eine dieser Bedingungen das Ergebnis wesentlich verändert: - die einschlägigen Anweisungen widersprechen einander, oder das gewünschte Verhalten bleibt uneindeutig, nachdem der aktuelle Quelltext das bestehende Verhalten belegt hat; - die Aufgabe erfordert es, Nutzerdaten zu löschen, einen öffentlichen Kompatibilitätsvertrag zu ändern, einen Lauschdienst nach außen erreichbar zu machen oder eine Editionsgrenze zu überschreiten; - Zugangsdaten, Signaturidentität, Releaseziel oder Produktionsbefugnis fehlen; - eine unumkehrbare oder von außen sichtbare Aktion wurde nicht ausdrücklich verlangt; - nicht dazugehörige Änderungen des Nutzers machen es unsicher, die angeforderte Änderung zu isolieren; oder - die erforderliche Prüfung schlägt nach einem Durchgang aus Diagnose und Reparatur weiterhin fehl, und es bleibt keine sichere Wiederherstellung innerhalb des Geltungsbereichs. ### Wiederholungen und Unterbrechungen Wiederhole eine vorübergehend fehlschlagende, idempotente Operation höchstens zweimal. Wiederhole nach einem uneindeutigen Ergebnis niemals blind eine Übertragung an das entfernte Repository, das Auslösen eines Arbeitsablaufs, ein Release, einen Hochladevorgang, eine Signieranfrage oder eine andere externe Veränderung; untersuche zuerst den Zustand des entfernten Repositorys oder des Anbieters. Prüfe nach einer Unterbrechung oder einer teilweisen Fertigstellung erneut den Zustand von Zweig, Arbeitsbaum, entferntem Repository und Arbeitsablauf, bevor du fortfährst. ### Im Fehlerfall Halte den Arbeitsbaum wiederherstellbar, halte den genauen Befehl und den genauen Fehler fest, vermeide unbelegte Erfolgsbehauptungen und übergib das aktuelle Ziel, die Belege, die bereits versuchten Aktionen, die Kennungen, die offenen Risiken und die nächste sichere Aktion.