Ein Forschungsagenten-Werkzeug bauen und pflegen, das auf dem eigenen Rechner läuft

## Das Forschungswerkzeug auf dem Rechner der Nutzer laufen lassen und festlegen, was es nicht tut Erstellen Sie eine auf lokalen Betrieb ausgerichtete Forschungsumgebung, die standardmäßig auf dem Rechner des Benutzers läuft, über einen dokumentierten allgemein zugänglichen Weg installiert wird, dauerhaften Zustand in Dateien und der Versionsverwaltung speichert und den vollständigen Forschungszyklus in einem einzigen Projektarbeitsbereich unterstützt. Eine einzige Laufzeitumgebung der Umsetzung muss maßgeblich bleiben, auch wenn ein schlankes Startprogramm oder mehrere Schnittstellen sie zugänglich machen. Nutzen Sie Anweisungen und spezialisierte Fähigkeiten zur Führung der Forschungsarbeit, während ein kleiner Dienst den Zustand speichert, wiederherstellt und weiterleitet. Richten Sie das System auf einen klar begrenzten Kern statt auf eine ständig wachsende Plattform aus, und benennen Sie Nichtziele, sobald ein Vorschlag die Laufzeitumgebung, öffentlich bereitgestellte Werkzeuge oder die Bereitstellungsfläche erweitern würde. ## Aktuellen Dateien und echtem Verhalten mehr trauen als Erinnerung oder alten Plänen Beginnen Sie mit den Dateien, die im aktuellen Arbeitsstand vorhanden sind, nicht mit Erinnerungen oder einem älteren Plan. Lesen Sie die Produktübersicht, das Dokumentationsverzeichnis, die Architekturhinweise für die Pflege, den Entwicklungsleitfaden, die kleinste Menge teilsystemspezifischer Unterlagen, die Umsetzung und die einschlägigen Prüfungen. Wenn Quellen einander widersprechen, bevorzugen Sie das aktuelle Laufzeitverhalten und bestandene Vertragsprüfungen, danach den archivweiten Leitfaden, anschließend die maßgebliche Dokumentation für die Pflege und zuletzt ergänzende Hinweise für Mitwirkende. Berichtigen Sie unzutreffende Dokumentation in derselben Änderung, statt einen veralteten Pfad, eine überholte Funktionsbehauptung oder einen nicht mehr gültigen Arbeitsablauf beizubehalten. Behandeln Sie geplantes und umgesetztes Verhalten als unterschiedliche Aussagen. Beschreiben Sie einen Bestandteil erst dann als verfügbar, wenn Umsetzung, Einstellungen, Einbindung, Dokumentation und Prüfungen diese Aussage gemeinsam stützen. ## Regeln für Mitwirkende am Code von Regeln für die KI im Werkzeug trennen Unterscheiden Sie Anweisungen für Mitwirkende am Versionsarchiv von Anweisungen und Fähigkeiten, die einen innerhalb des Produkts laufenden Agenten steuern. Ein Laufzeitvertrag kann ein bestimmtes öffentliches Werkzeug oder einen eingeschränkten Ausführungsweg verlangen, ohne Pflegenden beim Bearbeiten des Versionsarchivs dieselbe Beschränkung aufzuerlegen. Bewahren Sie diese Grenze, wenn sich das Verhalten von Anweisungen, Fähigkeiten, Befehlen oder Werkzeugen ändert. Deuten Sie einen produktinternen Sicherheitsvertrag nicht als Beitragsregel um, und schwächen Sie den Laufzeitvertrag nicht allein deshalb ab, weil Pflegende über umfassendere lokale Entwicklungswerkzeuge verfügen. ## Jedes Forschungsprojekt in einem Ordner mit Versionsverlauf halten Behandeln Sie jedes Forschungsprojekt als ein einziges versionsverwaltetes Archiv mit genau einem absoluten Projektstammverzeichnis. Bewahren Sie alle dauerhaften Forschungsinhalte in diesem Stammverzeichnis auf, und bilden Sie abweichende Ansätze durch Zweige oder getrennte Arbeitsbäume ab, ohne die Projektgeschichte auf sachfremde Orte aufzuteilen. Pflegen Sie einen ausdrücklichen Arbeitsbereichsvertrag für Aufgabenbeschreibung, Plan, Stand, Zusammenfassung, Arbeitsergebnisse, Vergleichsgrundlagen, Versuche, Literatur, Übergaben, Manuskript, Gedächtnis und privaten Laufzeitzustand. Laufzeit-Zwischenspeicher und Protokolle dürfen außerhalb des Projekts liegen, dürfen aber nicht zur einzigen Kopie von Forschungsnachweisen werden. Wenn sich die Projektstruktur ändert, aktualisieren Sie gemeinsam das Strukturmodell, die Speicherdienste, Zustandsabbilder, API-Verbraucher, Benutzeroberflächen, Prüfungen und Dokumentation. Stellen Sie nicht nur einen Verbraucher um, während die übrigen weiterhin eine überholte Struktur verwenden. ## Das Startprogramm schlank halten und vor dem Neustart prüfen, was tatsächlich läuft Halten Sie die maßgebliche Forschungslaufzeit in einer Umsetzungsschicht, und gestalten Sie Startprogramme der Paketverwaltung als schlanke Vermittler zu dieser Laufzeit und zu vorgefertigten Schnittstellenpaketen. Öffentlich bereitgestellte Installationspakete müssen die zum Start benötigten Dateien und fertig erstellten Bedienprogramme enthalten; der unterstützte Weg darf nicht erst durch eine nachträgliche Erstellung beim Endbenutzer funktionsfähig werden. Prüfen Sie vor der Fehlersuche oder dem Neustart einer laufenden Installation den aktiven Prozess, die wirksamen Einstellungen, die vorhandene Prozessaufsicht oder das Startprogramm, das tatsächlich ausgeführte Laufzeitprogramm und den von einem Zustandsendpunkt gemeldeten Heimatpfad. Leiten Sie das aktive Heimatverzeichnis, die Einstellungen oder den Prozesseigentümer niemals allein aus einem Vorgabeverzeichnis ab. Stimmen Sie Paketmanifeste, Projektmetadaten, öffentliche Dokumentation und die Erwartungen an ausgelieferte Pakete aufeinander ab. Eine Paketvorschau oder ein Probelauf muss den ausgelieferten Dateisatz bestätigen, bevor die Paketierung als abgeschlossen gilt. ## Wenige öffentliche Werkzeuge für die KI behalten und jedes neue begründen Begrenzen Sie die eingebaute öffentliche Werkzeugoberfläche auf wenige beständige Zuständigkeiten: dauerhaftes Gedächtnis, versionierte Arbeitsergebnisse und dauerhafte Befehlsausführung. Halten Sie die Versionsverwaltung hinter der Grenze für Arbeitsergebnisse und die Befehlszeilenausführung hinter der Ausführungsgrenze, statt für jedes Teilsystem einen neuen öffentlichen Namensraum hinzuzufügen. Lassen Sie Anweisungen die Erwartungen an Arbeitsabläufe und Dateisystemverträge festlegen und spezialisierte Fähigkeiten das besondere Ausführungsverhalten bereitstellen. Der Zustandsdienst soll schlank bleiben; verankern Sie keine große zentrale Planung der Ablaufstufen fest im Code, wenn Anweisungs- und Fähigkeitsverträge den Arbeitsablauf klar ausdrücken können. Jeder Vorschlag für ein neues öffentliches Werkzeug muss belegen, dass keine bestehende Zuständigkeit es aufnehmen kann, sein Speicher- und Berechtigungsmodell festlegen, jedes Bedienprogramm aktualisieren und Vertragsprüfungen ergänzen. Bequemlichkeit allein reicht nicht aus. ## Neue Anbindungen über kleine Listen hinzufügen und erst als fertig melden, wenn alles bereit ist Verwenden Sie kleine Register für Ausführungsprogramme für Forschungsaufgaben, Kommunikationskanäle, Anbindungsbrücken, das Auffinden von Fähigkeiten, verwaltete lokale Werkzeuge und wahlweise Anbindungen. Bevorzugen Sie einheitliche Schnittstellen zum Registrieren, Nachschlagen und Auflisten gegenüber großen Verteilzweigen oder teilsystemspezifischen Bedingungen. Bezeichnen Sie eine Einbindung erst dann als umgesetzt, wenn ihre Laufzeitanbindung, Registermetadaten, Einstellungsvorgaben, Gültigkeitsprüfung, Einbindung in Dienst und Befehlszeile, sichtbare Benutzerdokumentation und Prüfungen vollständig vorhanden sind. Fehlt eine Schicht, ist die Einbindung nur teilweise umgesetzt. Halten Sie wahlweise Anbindungen außerhalb des Kernwegs und weisen Sie ausdrücklich auf ihr Fehlen hin. Ein Registereintrag soll Fähigkeiten und Verträglichkeit offenlegen, ohne stillschweigend Abhängigkeiten zu installieren, einen externen Dienst aufzurufen oder lokale Einstellungen zu ändern. ## Im Browser und Befehlsfenster denselben Projektstand und dieselbe Verbindung zum Dienst (API) nutzen Verlangen Sie, dass Web- und Terminalschnittstellen dieselbe Dienst-API, dieselben Zustandsabbilder und dasselbe Ereignismodell verwenden. Wenn sich ein API-Pfad oder Ereignis ändert, aktualisieren Sie in derselben Änderung den Dienst, jedes Bedienprogramm, die Annahmen zur Navigation und die Vertragsprüfungen. Bewahren Sie über alle Schnittstellen hinweg beständige projektbezogene Pfade und Kennungen. Benutzeroberflächen dürfen unterschiedliche Anordnungen zeigen, aber weder eigene Zustandsbedeutungen erfinden noch einen Übergang verbergen, den eine andere unterstützte Schnittstelle beobachten muss. Behandeln Sie einen vollwertigen Kommunikationskanal als Umsetzung des allgemeinen Kanal- und Brückenmodells. Lassen Sie eine wichtige Anbindung nicht zu einer getrennten Laufzeit mit eigenen Regeln für Speicherung, Fehlerbehandlung oder Lebenszyklus werden. ## Forschungsstufen von der Suche bis zum Schreiben festlegen, ohne eine starre Reihenfolge zu erzwingen Legen Sie eine kleine maßgebliche Abfolge fest, etwa Erkundung, Ausgangsbasis, Ideenbildung, Experimentieren, Auswertung, Schreiben und Abschluss. Behandeln Sie Entscheidungsfindung als stufenübergreifend, statt vorzugeben, jede wichtige Tätigkeit sei eine einzelne lineare Stufe. Eingangsprüfungen, Vorbereitung von Abbildungen, Begutachtung und Erwiderung dürfen als besondere Tätigkeiten bestehen, gehören aber nur dann in die Vorgabeabfolge, wenn der aktuelle Code und die Anweisungsverträge dies tatsächlich vorsehen. Benannte Stufen müssen mit den aktiven Ankern, Zustandsübergängen und der Benutzerdokumentation des Systems übereinstimmen. Halten Sie das Verhalten der Stufen in der Systemanweisung, gezielten Anweisungsverträgen, der Zusammenstellung der Anweisungen und den Fähigkeiten der Stufen. Verteilen Sie die Bedeutung der Stufen nicht über Dienstfunktionen, Schnittstellencode und fallbezogene Bedingungen. ## Anleitungen für Nutzer von Unterlagen für Entwickler trennen Trennen Sie benutzerorientierte Leitfäden von Architektur- und Entwicklungsunterlagen für die Pflege. Öffentliche Dokumentation soll das aktuelle Verhalten erklären; Dokumente für die Pflege sollen Verträge, Erweiterungspunkte und Anforderungen an abgestimmte Änderungen beschreiben. Legen Sie keine vorläufigen Pläne, flüchtigen Prüflisten, privaten Pfade oder ausschließlich interne Hinweise im öffentlichen Dokumentationsbaum ab. Halten Sie die Namen verknüpfter Dokumente beständig, entfernen Sie Verweise auf gelöschte Dateien und aktualisieren Sie jede gepflegte Übersetzung, wenn sich sichtbares Benutzerverhalten ändert. Wenn eine Änderung nur die interne Pflege betrifft, aktualisieren Sie die maßgeblichen Unterlagen für die Pflege, ohne eine benutzerorientierte Ankündigung zu erfinden. Der Umfang der Dokumentation soll dem Umfang der Verhaltensänderung folgen. ## Passwörter und persönliche Pfade aus geteilten Dateien heraushalten und Forschungsnachweise bewahren Übernehmen Sie keine arbeitsplatzbezogenen absoluten Pfade, Anmeldedaten, Zugriffstoken, lokalen Zwischenspeicher, Abhängigkeitsverzeichnisse, vorübergehenden Erzeugnisse des Erstellungsprozesses oder Prüfzwischenspeicher in die Versionsverwaltung. Erzeugte Schnittstellenpakete gehören nur dann in ein öffentliches Paket, wenn der Paketierungsvertrag dies ausdrücklich verlangt. Bewahren Sie dauerhafte Versuchsaufzeichnungen, Literaturnotizen, Vergleichsgrundlagen, Arbeitsergebnisse und Manuskripte innerhalb der Projektgrenze und unter Versionsverwaltung auf. Sichern Sie die ursprünglichen Nachweise vor ihrer Zusammenfassung, und ersetzen Sie ein reproduzierbares Ergebnis niemals durch eine bloße Zustandsmeldung der Benutzeroberfläche. Prüfen Sie öffentliche Dateien vor der Veröffentlichung auf offengelegte Geheimnisse, veraltete Dokumentnamen, private Verweise und Abweichungen erzeugter Dateien. Ein fehlerfreier Prüflauf rechtfertigt nicht die Veröffentlichung vertraulicher oder nicht reproduzierbarer Inhalte. ## Zuerst den aktuellen Code ansehen und kleine Änderungen machen Prüfen Sie die vorhandene Umsetzung, bevor Sie eine neue Abstraktion vorschlagen. Bevorzugen Sie kleine, zusammenhängende Änderungen gegenüber breiten, vermischten Umstrukturierungen, verwenden Sie zuerst die kleinste einschlägige Dokumentationsmenge und gleichen Sie den Vorschlag mit Code und Prüfungen ab. Wenn Code und Dokumentation auseinanderlaufen, berichtigen Sie beide in einer einzigen klar abgegrenzten Änderung. Bewahren Sie keine veralteten Verweise auf, nur weil sie früher einmal gültig waren, und starten Sie einen laufenden Forschungsdienst erst neu, wenn wirksame Laufzeitumgebung, Prozess, Einstellungen und Heimatverzeichnis ermittelt sind. Trennen Sie Diagnose und Veränderung. Halten Sie das beobachtete Signal, das erwartete Verhalten, die betroffenen angeschlossenen Komponenten und die kleinste Korrektur fest, bevor Sie gemeinsamen Zustand ändern. ## Tests und Doku zusammen mit dem geänderten Code anpassen und Unbeteiligtes nicht anfassen Aktualisieren Sie für das geänderte Teilsystem jede unmittelbar betroffene Schicht: - Projektstruktur oder dauerhafter Zustand: Strukturmodell, Speicherdienst, Zustandsabbilder, API-Verbraucher und Zustandsprüfungen; - Anweisungen oder Fähigkeiten der Ablaufstufen: Anweisungsquellen, Zusammenstellung, Fähigkeitsdefinitionen, gespiegelte Installationsprogramme, Verhaltensprüfungen und Benutzerleitfäden; - Gedächtnis, Arbeitsergebnisse oder Befehlsausführung: Umsetzungen, öffentliche Grenzen, Dienstprüfungen und Vertragsdokumentation; - Ausführungsprogramme für Forschungsaufgaben: Anbindung, Register, Einstellungsvorgaben, Gültigkeitsprüfung, Einbindung in Dienst und Befehlszeile, Leitfäden und Prüfungen; - Kanäle oder Anbindungsbrücken: Vorgaben, Gültigkeitsprüfung, Kanal- und Brückencode, Anbindungsleitfäden und Zusammenspielprüfungen; - verwaltete lokale Werkzeuge: Register, konkrete Anbindung, Verhalten bei Statusabfrage und Auflösung, Pflegeleitfäden und Prüfungen; - gemeinsame API-Oberfläche: Routensteuerung, Bearbeitungsfunktionen, Web-Bedienprogramm, Terminal-Bedienprogramm, Navigation und Vertragsprüfungen; - Paketierung: Manifeste, Projektmetadaten, öffentliche Übersicht, erforderliche Pakete und Prüfung des Paketinhalts. Weiten Sie diese Matrix nicht auf sachfremde Teilsysteme aus. Ihr Zweck ist abgestimmte Vollständigkeit innerhalb der unmittelbar betroffenen Grenze, nicht die Umgestaltung des gesamten Versionsarchivs. ## Vor dem Abschluss die dokumentierte Installation testen Führen Sie die einschlägigen Einzel-, Zusammenspiel-, Vertrags-, Kompilierungs-, Oberflächenerstellungs- und Paketierungsprüfungen für den geänderten Bereich aus. Starten Sie über den dokumentierten allgemein zugänglichen Weg, wenn sich das Verhalten von Startprogramm oder Paketierung ändert, und verwenden Sie den unmittelbaren Dienststart nur zur Diagnose. Prüfen Sie den abschließenden Änderungssatz auf sachfremde Änderungen, veraltete erzeugte Dateien, fehlende übersetzte Dokumentation, nicht gestützte Funktionsbehauptungen und unvollständige Aktualisierungen der Bedienprogramme. Unterscheiden Sie eine lokal erfolgreiche Komponentenprüfung von einem Nachweis, dass der unterstützte Installations- und Schnittstellenweg funktioniert. Verwenden Sie den tatsächlichen Arbeitsstand als letzte maßgebliche Quelle. Wenn eine erwähnte Datei oder ein Verhalten nicht mehr existiert, berichtigen Sie den Verweis und seine Nutzer, statt den Fehler beizubehalten.