Ein großes Python-Monorepository für Arbeitsabläufe ändern, ohne es zu beschädigen

## Vor dem Bearbeiten das zuständige Paket und seine Anweisungen finden Verwende in Fließtexten die maßgebliche Fachterminologie des Projekts. Bewahre wörtliche Bezeichner, Befehle, Pfade, Konfigurationsschlüssel und Kompatibilitätsnamen exakt so, wie der Code sie verlangt; schreibe sie nicht allein aus stilistischen Gründen um. Vor der Bearbeitung: - Ermittle das zuständige Paket, seine lokalen Anweisungen und den nächstgelegenen Leitfaden zu Architektur oder Tests. - Verwende die vom Projekt verwaltete Aufrufhülle für Entwicklung und Tests, statt Werkzeuge des Hostsystems direkt aufzurufen. - Richte die Einbindungsmechanismen oder Befehlsadapter des Repositorys über das dokumentierte einmalige Einrichtungsverfahren ein. - Lege vorübergehende Hilfsskripte ausschließlich im dafür vorgesehenen eingehängten Entwicklungsbereich ab und entferne sie nach Abschluss der Aufgabe. - Wähle die Prüfungen anhand der tatsächlich geänderten Dateien und Pakete aus. Behandle generierte Sperrdateien für Abhängigkeiten und ähnliche Artefakte als Ausgaben eines offiziellen Generators, niemals als von Hand zu bearbeitenden Quellcode. ## Den Planer keinen Ablaufcode ausführen und Arbeitsprozesse nicht direkt auf die Datenbank zugreifen lassen Verstehe den Datenfluss, bevor du den Orchestrierungscode änderst: 1. Autoren definieren Arbeitsabläufe über das öffentliche SDK. 2. Isolierte Verarbeitungsprozesse analysieren diese Definitionen und speichern serialisierte Arbeitsablaufdaten dauerhaft. 3. Planer lesen serialisierte Daten und dürfen von Autoren bereitgestellten Arbeitsablaufcode nicht ausführen. 4. Arbeitsprozesse führen Aufgaben über das unterstützte SDK oder die unterstützte API aus und dürfen nicht direkt auf die Metadatendatenbank zugreifen. 5. API-Dienste vermitteln die Interaktionen der Benutzeroberfläche und der Clients mit dem dauerhaft gespeicherten Zustand. 6. Dienste zur Ereignisauslösung laufen getrennt von Planern und Arbeitsprozessen. Verwende kurzlebige, eng begrenzte Zugangsdaten zwischen den Komponenten. Softwareprüfungen, die vom direkten Datenbankzugriff abhalten, sind nützliche Schutzvorkehrungen, bilden gegenüber absichtlich bösartigem Code jedoch keine Sicherheitsgrenze. Ordne ein vermutetes Sicherheitsproblem ein, bevor du eine Korrektur vorschlägst: - Eine ausnutzbare Verletzung des dokumentierten Vertrauensmodells ist eine Sicherheitslücke. - Ein Verhalten, das bereits ausdrücklich außerhalb des Vertrauensmodells liegt, ist eine bekannte Einschränkung. - Eine sicherere Bereitstellungsoption, die eine verletzte Zusicherung nicht wiederherstellt, ist eine Härtungsempfehlung. Halte diese Kategorien getrennt, damit Schweregrad und Abhilfemaßnahme dem tatsächlichen Risiko entsprechen. ## Jede Abhängigkeit in das Paket legen, das sie importiert Behandle das Monorepository als eine Gruppe zusammengehöriger Distributionen und nicht als ein einziges undifferenziertes Paket. Kernorchestrierung, öffentliche SDKs, Anbieterintegrationen, Befehlszeilenwerkzeuge, Bereitstellungsvorlagen, Entwicklungswerkzeuge und Skripte können unterschiedlichen Veröffentlichungszyklen und Abhängigkeitsregeln folgen. Für eine gemeinsam genutzte Bibliothek: - Halte ihre API klein und unabhängig. - Statte sie mit einem eigenen Quellbaum, eigenen Tests, eigener Konfiguration und deklarierten Abhängigkeiten aus. - Verwende die vom Repository unterstützten Arbeitsbereichsverknüpfungen, statt Code zu duplizieren. - Teste die Bibliothek selbst und jede direkt betroffene abhängige Komponente. Ordne eine Abhängigkeit der Distribution zu, die sie importiert. Wenn eine Änderung Paketgrenzen überschreitet, prüfe sowohl die Importrichtung als auch die Veröffentlichungszuständigkeit, bevor du Manifeste änderst. Erzeuge Sperrdateien mit dem unterstützten Arbeitsablauf neu und prüfe die daraus entstehende Abhängigkeitsdifferenz auf sachfremde Änderungen. ## Klaren Python-Code schreiben und jede Änderung klein halten Formatiere jede geänderte Python-Datei und unterziehe sie einer Codeprüfung, solange die Änderung noch klein ist. Halte das Produktionsverhalten ausdrücklich fest: - Verwende keine Zusicherungen zur Laufzeitvalidierung oder zur Behandlung behebbarer Fehler. - Verfasse Kommentare, die Einschränkungen oder Absichten erklären, statt den Code nachzuerzählen. - Miss Zeitspannen mit einer monotonen Uhr. - Belasse Importe auf Modulebene, außer in dokumentierten Fällen von zirkulären Abhängigkeiten, verzögertem Laden oder optionalen Abhängigkeiten. - Schirme aufwendige Importe ab, die ausschließlich der Typprüfung dienen, damit sie den Laufzeitstart nicht beeinträchtigen. - Löse die engstmögliche aussagekräftige Ausnahme aus; führe keine weit gefasste Basisausnahme ein, die alles abfängt. - Übersetze Domänenfehler nur an der Transportgrenze in protokollspezifische Antworten. - Benenne Funktionen mit Tätigkeitsverben und behalte den vorgeschriebenen Lizenzkopf bei. Bevorzuge eine kleine, leicht prüfbare Änderung gegenüber einer nebenbei vorgenommenen Umstrukturierung. Wenn eine Bereinigung für das angeforderte Verhalten nicht erforderlich ist, verschiebe sie in eine eigene Änderung. ## In kleinen Stapeln in die Datenbank schreiben, damit der Planer schnell bleibt Funktionen, die eine Datenbanksitzung erhalten, sollen die Transaktion nicht stillschweigend festschreiben. Gestalte die Sitzung als ausschließlich benanntes Argument, sofern der Codebestand dieser Konvention folgt, und überlasse dem Transaktionsverantwortlichen die Entscheidung, wann die Transaktion festgeschrieben oder zurückgerollt wird. Vermeide unbegrenzte Massenschreibvorgänge in Planer- oder Wartungsschleifen: 1. Filtere nach indizierten Spalten. 2. Verarbeite einen begrenzten Stapel. 3. Schreibe die Transaktion zwischen den Stapeln fest oder gib sie frei. 4. Fahre fort, bis keine geeigneten Zeilen mehr vorhanden sind. Dies begrenzt Sperrdauer, Speicherwachstum und das Aushungern anderer Planeraufgaben. Bestätige das Verhalten mit der Standarddatenbank und führe Abdeckungstests mit alternativen Datenbanksystemen aus, wenn die geänderte Abfrage von systemspezifischer Semantik abhängt. Behandle einen zerstörerischen Bereinigungsbefehl niemals als routinemäßige Fehlersuche. Ermittle das genaue Ziel und hole die erforderliche Genehmigung ein, bevor du Datenbanken, Datenträger, Zwischenspeicher oder Benutzerdaten löschst. ## Zuerst einen fehlschlagenden Test schreiben und Tests nur bei Bedarf ausweiten Beginne mit einem Test, der genau das zu ändernde Verhalten ausdrückt, und bestätige, dass er ohne die Umsetzung fehlschlägt. Nimm dann die kleinste Änderung vor, mit der der Test besteht. Verwende die vom Repository bevorzugte Testumgebung und ihre Hilfswerkzeuge: - Bilde die Quellstruktur im Testbaum nach. - Verwende spezifikationsgebundene Testdoppel, damit Abweichungen der Schnittstelle deutlich fehlschlagen. - Verwende die unterstützten Mittel zum Überschreiben der Konfiguration und zur Zeitsteuerung. - Parametrisiere aussagekräftige Varianten von Eingaben und Datenbanksystemen. - Kennzeichne Datenbanktests genau und halte Tests ohne Datenbank unabhängig von der Datenbankeinrichtung. - Prüfe strukturierte Ereignisnamen und -felder statt instabiler, gerenderter Protokolltexte. Teste weder die Standardbibliothek noch eine Abhängigkeit von Dritten für sich allein. Teste das Integrationsverhalten, für das dieser Code verantwortlich ist. Führe zuerst einen gezielten Test aus, danach die Testsammlung des betroffenen Pakets, die statische Typprüfung und die Codeprüfung; führe umfassendere Testsammlungen nur aus, wenn der Abhängigkeitsumfang dies erfordert. ## CI-Regeln und Dokumentation gemeinsam ändern, Versionshinweise nur für sichtbare Änderungen Wenn sich das selektive Verhalten der kontinuierlichen Integration ändert, aktualisiere die Auswahllogik, ihre Tests und ihre Dokumentation gemeinsam. Eine Regel, die nur im Code oder nur im Fließtext besteht, ist unvollständig. Füge Veröffentlichungsmetadaten nur für benutzersichtbare Änderungen in der Distribution hinzu, die das Verhalten ausliefert. Interne Umstrukturierungen, reine Testarbeiten, Entwicklungswerkzeuge und nicht benutzersichtbare Wartung benötigen normalerweise keinen Versionshinweis. Verwende die Projektgeneratoren für Sperrdateien, Befehlsreferenzen, Schemata und andere generierte Dokumentation. Prüfe die generierten Änderungen, aber ändere keine generierten Dateien, um ein Problem in der maßgeblichen Quelle zu verdecken. Führe vor der Übergabe die relevanten Formatierungs-, Code-, Typ-, Test-, Dokumentations- und Auswahlprüfungen aus. Halte jede absichtlich ausgelassene Prüfstufe und den konkreten Grund fest, weshalb sie nicht anwendbar war. ## Den ganzen Diff prüfen und einen Pull Request aus dem eigenen Fork öffnen Prüfe vor der Veröffentlichung den vollständigen Änderungsvergleich der Aufgabe. Stelle sicher, dass Architekturgrenzen, Sicherheitsannahmen, Tests, generierte Ausgaben, Veröffentlichungsmetadaten und lokale Anweisungen miteinander übereinstimmen. Frage nach, bevor du eine umfangreiche paketübergreifende Umstrukturierung vornimmst, eine weitreichende Abhängigkeit hinzufügst, das Verhalten einer zerstörerischen Migration änderst oder eine noch nicht genehmigte externe Veröffentlichung durchführst. Lege niemals Geheimnisse offen, umgehe keine vorgeschriebenen Einbindungsmechanismen, bearbeite keine generierten Dateien von Hand und führe ohne ausdrückliche Genehmigung keine zerstörerischen Befehle der Versionsverwaltung aus. Vor jedem Vorgang mit einem Fernrepository: - Prüfe die konfigurierten Fernrepositorys und stelle fest, welches das maßgebliche Repository und welches die Abspaltung des Beitragsleistenden ist. - Übertrage Änderungen nicht direkt in das maßgebliche Fernrepository oder dessen geschützten Standardzweig. - Frage nach, bevor du Fernrepositorys umbenennst oder umschreibst, wenn ihre Rollen unklar sind. - Suche nach einem vorhandenen Änderungsantrag, damit die Arbeit nicht doppelt ausgeführt wird. - Setze die Änderungen mit dem vom Repository akzeptierten Arbeitsablauf auf dem aktuellen Zielzweig neu auf oder synchronisiere sie auf andere Weise. Verwende einen klar formulierten Titel im Imperativ, der die Auswirkungen für Benutzer beschreibt. Erkläre im Text, warum die Änderung erforderlich ist, lege die Unterstützung durch KI offen, wenn dies vorgeschrieben ist, und füge Verweise auf relevante Vorgänge ein. Führe dich nicht selbst als Mitautor auf und markiere keine Personen, es sei denn, der Benutzer hat dies genehmigt oder sie beteiligen sich bereits an der Diskussion. Wenn eine vollständige Korrektur bereitsteht, bevorzuge den Änderungsantrag, statt einen doppelten Vorgang anzulegen. Ist die Änderung nur eine Übergangslösung, Schadensbegrenzung oder teilweise Korrektur, lege einen Nachverfolgungsvorgang an oder verknüpfe ihn und verweise sowohl im Änderungsantrag als auch in der Nähe des vorübergehenden Codes darauf.