Einen KI-Agenten-Dokumentgenerator ändern, ohne aktuellen und alten Stack zu verwechseln

## Zuerst im Code die echten Startbefehle und die Konfiguration finden Beginne mit Paketmetadaten, Konsoleneinstiegspunkten, Konfigurationsladern, der Verarbeitung von Umgebungsvariablen und dem Code, der Laufzeitarbeitsbereiche erstellt. Wenn diese ausführbaren Bestandteile der beschreibenden Dokumentation widersprechen, haben sie Vorrang. - Stelle fest, welcher Befehl die Hauptanwendung startet. - Stelle fest, welcher Befehl einen alten oder MCP-kompatiblen Dienst bereitstellt. - Verfolge jeden Befehl bis zu seinem tatsächlichen Modul und seiner Funktion. - Ermittle Konfigurationsvorlagen und das Standardverhalten des Arbeitsbereichs. - Prüfe, ob jeder genannte Pfad in der aktuellen Arbeitskopie vorhanden ist. Behandle eine veraltete Übersicht als historischen Hintergrund, nicht als Beleg für den aktuellen Startpfad. ## Entscheiden, ob der aktuelle oder der alte Stack für die Änderung zuständig ist Ein Quellcodebestand kann neben dem aktuellen Produktzweig eine Bibliothek älterer Generation enthalten, die weiterhin einen speziellen Endpunkt bedient. Ermittle vor jeder Bearbeitung den zuständigen Systemzweig. Der aktuelle Systemzweig kann zuständig sein für: - die Befehlszeilenschnittstelle und den Einrichtungsablauf; - die Ablaufsteuerung und Mehragentenausführung; - Forschungs-, Erzeugungs- und Gestaltungsagenten; - MCP-artige Werkzeuge für Suche, Reflexion, Umwandlung und Aufgabenverwaltung; - Hilfsfunktionen für Konfiguration, Protokollierung und Arbeitsbereiche; - browsergestützte HTML-Umwandlung und ein Node-Hilfsprogramm; - auf Integration ausgerichtete Tests. Der alte Systemzweig kann weiterhin für vorlagengesteuerte Erzeugung, Ableitung der Anordnung, Syntaxanalyse, Bewertung und einen Kompatibilitätsserver zuständig sein. Gehe nicht davon aus, dass die Änderung eines gemeinsamen Konzepts in einem Systemzweig auch den anderen aktualisiert. ## Das Design mit weniger Sonderfällen und kurzen Funktionen einfach halten Bevorzuge Entwürfe, die Randfälle in gewöhnliche Fälle überführen, statt immer mehr bedingte Verzweigungen anzuhäufen. Löse das tatsächliche Problem im Quellcodebestand und kein hypothetisches Architekturproblem. - Wähle eine direkte, betrieblich schlanke Lösung, wenn sie die tatsächliche Anforderung erfüllt. - Halte Funktionen kurz, klar abgegrenzt und verständlich benannt. - Behandle unnötige Komplexität als Fehler. - Mehr als 3 Einrückungsebenen sind ein Zeichen dafür, den Code neu zu strukturieren. - Verberge gewöhnliche Kontrollabläufe nicht ohne konkreten Fehlermodus in weit gefassten Ausnahmebehandlungen. - Halte Kritik sachlich und richte sie an Code, Entwurf oder Annahmen statt an Personen. Gutes Urteilsvermögen zeigt sich in weniger Sonderfällen, kleineren Änderungsflächen und leicht überprüfbarem Verhalten. ## Typannotationen ergänzen und Abhängigkeiten auf das Nötigste beschränken Wende im gepflegten Systemzweig einheitliche Regeln an: - Ergänze Funktionen und Methoden um Typangaben; - verfasse technische Dokumentation und Codekommentare in der vom Quellcodebestand festgelegten Sprache; - nutze die aktuelle Abhängigkeitsverwaltung, Suchwerkzeuge für den Quellcodebestand, aktuelle Sprachfunktionen und unterstützte Programmierschnittstellen der Bibliotheken; - bevorzuge aktuelle Schnittstellen für Serialisierung und Validierung gegenüber veralteten Formen; - minimiere Abhängigkeiten und den gesamten Codeumfang; - richte die Definition des Stammpakets auf das Hauptprodukt aus; - führe Abhängigkeiten wirklich eigenständiger Teilprojekte in deren lokalen Abhängigkeitsdateien. Verschiebe eine Abhängigkeit nicht allein der Ordnung halber. Trenne sie nur, wenn tatsächlich eine Grenze für Laufzeit und Wartung besteht. ## Eine Änderung durch alle verbundenen Teile verfolgen, auch Python und Node Untersuche den vollständigen Zuständigkeitspfad für das zu ändernde Verhalten: - Untersuche bei Befehlszeilenverhalten die Befehlsdefinitionen, gemeinsamen Befehlshilfen und das Laden der Konfiguration zusammen; - untersuche bei der Ablaufsteuerung den Hauptkoordinator und die betreffende Agentenimplementierung; - entscheide bei MCP-Verhalten, ob die aktuellen Werkzeugserver oder der alte Kompatibilitätsserver zuständig sind; - untersuche bei Export und Umwandlung sowohl die Ablaufsteuerung auf der Python-Seite als auch die Umwandlung auf der Node-Seite; - ändere bei doppelt vorhandenen Erzeugungskonzepten nur den zuständigen Systemzweig, sofern die Aufgabe nicht ausdrücklich beide umfasst. Halte die Änderung eng begrenzt. Überarbeite nicht beide Systemzweige nur deshalb, weil in ihnen ähnliche Namen vorkommen. ## Bestehende Konfigurationsnamen und Workspace-Orte unverändert lassen Vorhandene Konfigurationsschlüssel, Umgebungsvariablen, Einrichtungsverhalten, Beispielkonfigurationen und Orte der Arbeitsbereiche bilden einen Laufzeitvertrag. Behalte ihre Namen bei, sofern die Aufgabe nicht ausdrücklich eine Migration umfasst. Abhängigkeiten von Browsern und Containern können normale Laufzeitanforderungen für Umwandlungspfade sein und keine wahlfreien Entwicklungserweiterungen. Systemnahe Umwandlungswerkzeuge, Modellzugangsdaten, Browserautomatisierung und Containerabbilder können ebenfalls bestimmen, welche Integrationstests ausführbar sind. Beim Ändern eines Laufzeitpfads: 1. Ermittle alle Konfigurationsquellen und Standardwerte. 2. Verfolge, wie Einrichtung und Beispiele diese Werte setzen. 3. Prüfe die aufrufende Python-Komponente und jedes externe Umwandlungshilfsprogramm. 4. Bewahre die Kompatibilität oder stelle einen ausdrücklichen Migrationspfad bereit. ## Alte Doku am Code prüfen und Tests nach ihren Voraussetzungen ordnen Prüfe Aussagen der Dokumentation anhand des aktuellen Dateibaums und der ausführbaren Einstiegspunkte, bevor du dich darauf verlässt. Ältere Dokumente können weiterhin nützliche Konzepte erklären, obwohl sie entfernte Dateien oder veraltete Startabläufe nennen. Ordne Tests nach ihren Voraussetzungen: - Modultests für abgegrenzte Logik; - Parser- oder markierte Tests für besondere Datenpfade; - Integrationstests für abgeschottete Werkzeuge, Browser- oder PDF-Umwandlung, Bildverarbeitung und externe Hilfsprogramme; - modellgestützte Tests, die Zugangsdaten oder vernetzte Dienste benötigen. Ein fehlender Browser, ein fehlendes Containerabbild, ein fehlendes systemnahes Umwandlungsprogramm oder fehlende Modellzugangsdaten schränken die Validierung ein. Sie belegen nicht, dass nicht betroffener Code fehlerhaft ist. ## Die kleinsten sinnvollen Tests ausführen und melden, was nicht laufen konnte Nutze eine eng gefasste Änderungsfolge: 1. Stelle fest, welcher Systemzweig und Einstiegspunkt für das Verhalten zuständig sind. 2. Bearbeite den kleinsten in sich vollständigen Bereich. 3. Führe die kleinste aussagekräftige Testauswahl aus. 4. Erweitere den Umfang nur auf direkt gekoppelte Python-, Node-, Browser-, Container- oder Kompatibilitätspfade. 5. Melde jede Abhängigkeit oder Umgebungsvoraussetzung, die eine Prüfung verhindert hat. Prüfe die abschließenden Änderungen auf unbeabsichtigte Eingriffe in den anderen Systemzweig, umbenannte Konfigurationsverträge, veraltete Dokumentationsverweise, sachfremde Überarbeitungen und ungeprüfte sprachübergreifende Schnittstellen. Melde, was geändert wurde, welcher Pfad ausgeführt wurde, welche Prüfungen erfolgreich waren und welche nicht ausgeführt werden konnten. Behaupte keine vollständige Validierung, wenn eine erforderliche Laufzeitabhängigkeit nicht verfügbar war.