Ein selbst gehostetes Monorepo zur Zertifikatsautomatisierung ändern, ohne Geheimnisse preiszugeben

## Den Lebenszyklus der Zertifikate und die gespeicherten Geheimnisse verstehen Behandle das System als privates, selbst gehostetes Produkt, das die Beantragung, Erneuerung, Bereitstellung, Überwachung und Benachrichtigung von Zertifikaten sowie API-Integrationen verwaltet. Sein zentraler Ablauf kann Zertifikate über ACME anfordern, DNS-01-, HTTP-01-, CNAME-Proxy- oder anbieterspezifische Prüfungen abschließen, Formate wie PEM, PFX, DER, JKS und P7B exportieren und die Zertifikate auf Servern, Proxys, Clustern, CDNs, Cloud-Diensten oder Bedienfeldern bereitstellen. Das System speichert Zertifikate, Cloud-Zugangsdaten, SSH-Angaben, API-Schlüssel und andere vertrauliche Konfigurationen. Gib lokale Daten oder Geheimnisse niemals durch Quellcodeänderungen, Protokolle, Testvorrichtungen, Bildschirmaufnahmen, Berichte oder erzeugte Metadaten preis. ## Workspaces im Monorepo getrennt halten und Laufzeitdaten nicht anfassen Verwende den vom Repository vorgesehenen Paketmanager, seine Arbeitsbereichsdefinition und seine Sperrdatei; führe keine Sperrdatei eines anderen Paketmanagers ein. Ist ein Paket ein eigenständiger Arbeitsbereich der Versionsverwaltung, prüfe Status und Diff innerhalb dieses Arbeitsbereichs und halte seine Änderungen von den Änderungen am Stamm-Repository getrennt. Ändere Laufzeitdaten, Protokolle, temporäre Ausgaben, erzeugte Metadaten, Distributionen oder exportierte Erweiterungsmanifeste nicht und nimm sie nicht in einen Commit auf, sofern die Aufgabe sie nicht ausdrücklich zum Gegenstand macht. Ein Verzeichnis mit Laufzeitabhängigkeiten darf schreibgeschützt untersucht werden, wenn ein dynamisch installiertes SDK verstanden werden muss. Es ist jedoch kein Quellcode und darf nicht in den Änderungssatz gelangen. ## Jede Änderung in das zuständige Paket oder Plugin legen Bestimme vor der Bearbeitung die Zuständigkeit: Protokollclients verantworten das Verhalten von Konten, Aufträgen und Challenges; Ablaufpakete verantworten Ausführungsmodelle und Aufgabenlebenszyklen; Servermodule verantworten Entitäten, Dienste, Controller, Berechtigungen und Migrationen; Clientmodule verantworten Ansichten, Formulare, Routen und API-Adapter; Anbietererweiterungen verantworten anbieterspezifisches DNS-, Bereitstellungs- und Benachrichtigungsverhalten. Belasse einen Fehler, der nur einen Anbieter betrifft, in dessen Erweiterung. Verschiebe Verhalten nur dann in den Ablaufkern oder eine gemeinsame Erweiterungsbibliothek, wenn es eine wiederverwendbare Semantik ausdrückt, die anbieterübergreifend einheitlich gelten muss. Bevorzuge bestehende Module, Dienste, Komponenten und Erweiterungsmuster gegenüber parallelen Implementierungen. ## Die Befehle des jeweiligen Pakets nutzen und keine zusätzlichen Abhängigkeiten installieren Lies die dokumentierten Befehle, bevor du Prüfungen ausführst. Verwende die paketinternen Unit-Test-, Lint-, Formatierungs- und Build-Befehle des betroffenen Pakets und weite die Prüfungen nur aus, wenn die Änderung eindeutig Paketgrenzen überschreitet. Ersetze eine unterstützte dateibezogene Prüfung weder durch eine bekanntermaßen defekte Typprüfung noch durch ein provisorisches Testskript. Installiere Abhängigkeiten nicht vorsorglich. Wenn fehlende Abhängigkeiten, Terminalanforderungen oder der Netzwerkzugang eine erforderliche Prüfung verhindern, beende diesen Versuch und melde die Einschränkung der Umgebung. Untersuche bei versionsabhängigem SDK-Verhalten die tatsächlich installierte Laufzeitabhängigkeit und deren mitgelieferte Dokumentation, statt dich auf dein Gedächtnis oder eine andere Version zu verlassen. ## Lesbaren Code mit benannten Schritten und Kommentaren zum Warum schreiben Gib Lesbarkeit den Vorrang vor kompakter Syntax. Zerlege komplexe Bedingungen, verschachtelte ternäre Operatoren, lange Aufrufketten, eingebettete Objekte und mehrschichtige Hilfsfunktionsaufrufe in eindeutig benannte Zwischenwerte oder klar abgegrenzte Methoden. Setze einen Methodenaufruf nicht direkt als Argument eines anderen Methodenaufrufs ein, wenn eine aussagekräftige lokale Variable den Übergang sichtbar machen kann. Verwende Objektparameter, wenn eine Methode andernfalls mehr als drei Argumente benötigen würde. Erläutere mit Kommentaren, warum Geschäftsregeln, Kompatibilitätsbeschränkungen, Protokolldetails und verborgene Risiken bestehen. Belasse kleine Logik am Einsatzort, aber extrahiere wiederkehrende Geschäftsregeln, Feldumwandlungen, Berechtigungsprüfungen, Repository-Auswahl, Transaktionsweitergabe oder Berechnungen, wenn mehrere Kopien synchron bleiben müssen. ## Zuerst einen fehlschlagenden Test schreiben, dann die kleinste Korrektur machen Ergänze gezielte Unit-Tests für das wesentliche Geschäftsverhalten. Beginne bei einer neuen Funktion oder Fehlerkorrektur vorzugsweise mit einem Test, der das erwartete Verhalten wiedergibt und vor der Implementierung fehlschlägt. Nimm anschließend die kleinste Änderung vor und führe den paketbezogenen Test erneut aus. Würde ein nachträglich ergänzter Test eine Änderung des bestehenden Verhaltens erfordern, kläre vor der Änderung, ob dieses Verhalten ein Fehler und nicht eine bestehende Anforderung ist. Lege reine Unit-Tests in der Nähe des Quellcodes ab und halte sie aus Produktions-Builds heraus. Verwende für statische ESM-Imports ein geeignetes Werkzeug zur Modulsimulation, statt den Produktionscode nur für einen Test umzustrukturieren. Lege die Unit-Test-Umgebung des Pakets ausdrücklich fest und führe umfassendere Builds nur aus, wenn paketübergreifende Auswirkungen sie erforderlich machen. ## Tabellenänderungen mit SQL-Migrationen versehen und Transaktionen richtig weitergeben Ergänze jede Änderung der Tabellenstruktur um eine ausdrückliche SQL-Migration; verlasse dich niemals auf die Schemasynchronisierung des ORM. Überführe temporäre Upload-Schlüssel vor der dauerhaften Speicherung über den genehmigten Dateidienst und bewahre den erforderlichen Eigentümer sowie die öffentliche oder private Sichtbarkeit. Übergib zur Weitergabe einer Transaktion einen Kontext mit dem optionalen Transaktionsmanager vor dem Anfrageobjekt und verwende die gemeinsamen Repository- und Transaktionshilfen. Füge einfachen Abfragen oder reinen Funktionen keinen Transaktionskontext hinzu. Erzeuge optionale Mandanten- oder Projektprädikate mit der maßgeblichen Abfragehilfe, damit null oder undefined nicht zu einer ungültigen Gleichheitsbedingung werden können. Vermeide Namen und Signaturen von Dienstmethoden, die mit geerbten Basismethoden kollidieren. Wähle konkrete Namen, die den Basisvertrag bewahren und den Umfang der Operation deutlich machen. ## Verwaltungsseiten mit dem vorhandenen CRUD-Framework und Formulardialogen bauen Ermittle vor der Bearbeitung die zuständige Funktionsansicht und ihr API-Modul. Verwende das genehmigte CRUD-Rahmenwerk für gewöhnliche Verwaltung, Datensatzsuche und tabellenbasierte Steuerung. Erstelle eine eigene Liste nur für einfache schreibgeschützte Darstellungen, stark interaktive Oberflächen oder eine dokumentierte Unvereinbarkeit mit dem Standardrahmenwerk. Eingebettete Datenraster benötigen eine stabile Höhe oder eine lückenlose Flex-Kette mit verkleinerbaren Kindelementen. Verwende bestehende entfernte Nachschlagewerke für durchsuchbare Identitätsfelder erneut. Eine einfache Bestätigung darf einen Bestätigungsdialog verwenden; jeder Dialog, der Felder erfasst, Eingaben prüft oder zusätzliche Werte übermittelt, muss dagegen die genehmigte Formulardialog-Abstraktion verwenden. Führe nur den unterstützten Formatierer und Linter für die geänderten Clientdateien aus, wenn bekannt ist, dass die umfassendere Typprüfung oder der Unit-Befehl des Repositorys ungültig ist. ## Zertifikatsprobleme in der richtigen Schicht beheben und Kontoschlüssel schützen Untersuche Anbietererweiterungen, bevor du gemeinsamen Ablaufcode änderst, und prüfe das tatsächlich dynamisch installierte SDK, wenn das Anbieterverhalten von dessen Version abhängt. Ermittle vor einer Korrektur, ob ein Zertifikatsproblem zum ACME-Client, zur Ablaufausführung, zu einem Serverdienst, zu einer Anbietererweiterung, zu einem gemeinsamen Zertifikatswerkzeug oder zum Clientformular gehört. Verwende eine reine Kontenabfrage mit dem bestehenden privaten Kontenschlüssel, wenn der Protokollclient die URL eines vorhandenen Kontos abrufen kann, ohne neues Material für die externe Kontobindung zu verbrauchen. Ändert sich eine Kennung der externen Kontobindung, erzeuge einen neuen privaten Kontenschlüssel, der an diese Kennung gebunden ist. Andernfalls musst du die Ausstellung blockieren und eine Aktualisierung des Kontenschlüssels verlangen. Halte Zugangsdaten aus Code, Protokollen, Tests, Berichten und in Commits aufgenommenen Artefakten heraus. Bewahre die Prüf- und Berechtigungsgrenzen, wenn du Upload-, Bereitstellungs-, Benachrichtigungs- oder offene API-Abläufe erweiterst. ## Alte Einstellungen weiter funktionieren lassen und berichten, welche Prüfungen gelaufen sind Berücksichtige beim Hinzufügen eines Erweiterungsparameters, dass er in gespeicherten Altkonfigurationen fehlen kann, und bewahre das bisherige Verhalten, sofern eine Migration es nicht ausdrücklich ändert. Deute fehlende Werte ohne einen festgelegten Kompatibilitätszweig nicht als neuen Modus um. Prüfe vor dem Abschluss den eingegrenzten Diff, verifiziere den Stamm und jeden eingebetteten Arbeitsbereich getrennt, führe die direkt betroffenen Tests und dateibezogenen Formatierungs- oder Lint-Prüfungen aus und bestätige erforderliche Migrationen. Stelle sicher, dass Laufzeitdaten und erzeugte Ausgaben außerhalb des Änderungssatzes bleiben. Berichte, was geändert wurde, welche Prüfungen erfolgreich waren, welche Prüfungen nicht ausgeführt werden konnten und weshalb umfassendere Prüfungen außerhalb des Umfangs lagen.