Module zu einem Go-Server hinzufügen, ohne die Sicherheit zu schwächen

## Sichere Standardeinstellungen bewahren und den Platz jeder neuen Funktion festlegen Behandeln Sie sichere Voreinstellungen als wichtigste Produktanforderung für eine aus dem Internet erreichbare Serverplattform. Entwerfen Sie Funktionen als kombinierbare Module, statt sie eng mit dem Kern zu koppeln. Bevorzugen Sie allgemeine Erweiterungen für eine Klasse von Anwendungsfällen gegenüber Korrekturen für eine einzelne Bereitstellung. Bestimmen Sie, ob eine Änderung zu einer übergeordneten Anwendung, einem wiederverwendbaren Modul, einer Konfigurationsanpassung oder dem Befehlszeilen-Einstiegspunkt gehört. Halten Sie Modulkennungen in Namensräumen, damit unabhängig entwickelte Komponenten nicht miteinander kollidieren. Bewahren Sie ein natives strukturiertes Konfigurationsmodell, auch wenn benutzerfreundliche Adapter verfügbar sind. Prüfen Sie Anfragenverarbeitung, Transportsicherheit, Identität, Zertifikatsverwaltung und Vertrauensgrenzen besonders sorgfältig. Verfolgen Sie sicherheitsrelevantes Verhalten über zugehörige Repositorys oder Pakete hinweg, wenn die Zuständigkeit verteilt ist. Betrachten Sie eine sicherheitskritische Änderung erst dann als zusammenführungsreif, wenn ihre betroffenen Vertrauensgrenzen und Fehlermodi verstanden sind. Halten Sie das Standardmodulverzeichnis ausdrücklich fest, damit ausgelieferte Komponenten auffindbar und prüfbar sind. Stellen Sie sicher, dass Befehlsprogramme die vorgesehene Modulmenge importieren, statt sich auf eine zufällige Registrierung zu verlassen. Dokumentieren Sie die architektonische Einordnung, wenn eine neue Funktion sinnvoll in mehr als einer Schicht liegen könnte. Lehnen Sie Entwürfe ab, die sichere Voreinstellungen nur zur Verringerung des Implementierungsaufwands schwächen. Berücksichtigen Sie die Kompatibilität mit allen unterstützten Betriebssystemen bereits bei der ersten Entwurfsentscheidung. ## Fehler, Namen und Kommentare im üblichen Go-Stil schreiben Kehren Sie bei Fehlern frühzeitig zurück und halten Sie den erfolgreichen Pfad auf der niedrigsten Einrückungsebene. Vermeiden Sie else-Zweige nach einem Zweig, der bereits zurückkehrt. Schreiben Sie gängige Initialwörter einschließlich URL, HTTP und ID in der üblichen Großschreibung. Wählen Sie kurze Empfängernamen, die den Empfängertyp einheitlich widerspiegeln. Beginnen Sie Fehlertexte mit Kleinbuchstaben und verzichten Sie auf abschließende Satzzeichen. Schreiben Sie exportierte Dokumentation als vollständige Sätze, die mit dem deklarierten Namen beginnen. Verwenden Sie einen nil-Slice, wenn ein zugewiesener leerer Slice keinen semantischen Wert besitzt. Geben Sie bei erwarteten Fehlschlägen Fehler zurück, statt einen panic auszulösen. Behandeln Sie Fehler nahe an der Operation, die fehlschlagen kann. Umschließen Sie Fehler nur, wenn der zusätzliche Kontext beim Auffinden der fehlgeschlagenen Operation hilft. Bewahren Sie Fehler in einer Form, die Aufrufer prüfen können, wenn eine programmgesteuerte Behandlung vorgesehen ist. Vermeiden Sie ausgeklügelte Kontrollflüsse, die Ressourcenzuständigkeit oder Bereinigung verschleiern. Führen Sie vor der Prüfung Formatierung und statische Analyse aus. Wenden Sie die im Repository etablierten Konventionen an, auch wenn ein anderer Go-Stil ebenfalls gültig wäre. Verwenden Sie Schnittstellenprüfungen zur Übersetzungszeit für Typen, die Framework-Schnittstellen erfüllen sollen. Halten Sie Empfänger-, Paket- und exportierte Namen stabil, sofern keine bewusste Kompatibilitätsänderung genehmigt wurde. ## Jedes Modul der Reihe nach von der Erstellung bis zum Aufräumen bauen Registrieren Sie jedes Modul über den Standardregistrierungsmechanismus des Frameworks. Geben Sie Metadaten zurück, die eine Modul-ID mit Namensraum und einen Konstruktor für eine neue Instanz enthalten. Halten Sie Konstruktoren frei von umgebungsspezifischen Nebenwirkungen. Behandeln Sie den Lebenszyklus als geordnete Phasen: 1. Erzeugen Sie einen neuen Wert. 2. Dekodieren Sie die Konfiguration in diesen Wert. 3. Stellen Sie Laufzeitabhängigkeiten bereit. 4. Validieren Sie die vollständige Konfiguration. 5. Stellen Sie die Funktion des Moduls bereit oder führen Sie sie aus. 6. Bereinigen Sie die zugehörigen Ressourcen. Führen Sie keine abschließende Validierung durch, bevor Konfigurations- und Bereitstellungsdaten verfügbar sind. Gestalten Sie die Bereinigung nach einer teilweisen Bereitstellung und wiederholten Abschaltsignalen sicher, wenn das Framework sie auf diese Weise aufrufen kann. Verwenden Sie Übersetzungszeitprüfungen für Bereitstellung, Validierung, Konfigurationsanalyse und andere optionale Schnittstellen. Trennen Sie die Zuständigkeiten im Lebenszyklus, damit Konfigurationsfehler von Laufzeitfehlern unterscheidbar bleiben. Geben Sie bei Bereitstellung und Validierung Fehler zurück, die konkrete Abhilfe ermöglichen. Verbergen Sie eine fehlgeschlagene Initialisierung nicht hinter einem nur teilweise nutzbaren Modul. Verwenden Sie Schnittstellen der übergeordneten Anwendung nur für Komponenten, die das Start- und Stoppverhalten tatsächlich verantworten. Halten Sie Modul-IDs stabil, da Konfiguration, Adapter und externe Integrationen von ihnen abhängen können. ## Konfigurationsdateien streng einlesen und Verwaltungsendpunkte schützen Analysieren Sie benutzerorientierte Konfigurationen mit dem Token-Verteiler des Frameworks oder einem gleichwertigen strukturierten Iterator. Verbrauchen Sie den Anweisungsnamen, bevor Sie Argumente in derselben Zeile lesen. Verarbeiten Sie Argumente in derselben Zeile getrennt von verschachtelten Blöcken. Erfassen Sie die aktuelle Verschachtelungsebene und halten Sie an, sobald der Parser diesen Block verlässt. Erkennen Sie unterstützte Unteranweisungen ausdrücklich. Validieren Sie erforderliche Argumente sofort und geben Sie den standardmäßigen Argumentfehler des Parsers zurück. Lehnen Sie unbekannte Unteranweisungen mit einem Fehler ab, der den unerwarteten Wert enthält. Dokumentieren Sie die akzeptierte Syntax neben dem Parser als fortlaufend gepflegten Vertrag. Richten Sie die Adapterausgabe am nativen strukturierten Konfigurationsmodell aus. Beziehen Sie Protokollierung und andere Module während der Bereitstellung über den Framework-Kontext. Verwenden Sie eine strukturierte Protokollinstanz mit Modulbereich und fügen Sie Felder hinzu, statt unstrukturierte Nachrichten zusammenzusetzen. Speichern Sie Anfragen- oder Bereitstellungskontexte nicht in langlebigen Strukturen. Implementieren Sie beim Hinzufügen von Verwaltungsendpunkten die Routing-Schnittstelle des Frameworks. Wenden Sie die von der Verwaltungsoberfläche erwarteten Regeln für Authentifizierung, Autorisierung und Erreichbarkeit an. Validieren Sie die Konfiguration, bevor das Modul mit der Verarbeitung von Datenverkehr beginnt. ## Neue Abhängigkeiten vermeiden und Paketgrenzen klar halten Vermeiden Sie neue Abhängigkeiten, sofern ihr Nutzen die Wartungs-, Sicherheits- und Lieferkettenkosten nicht eindeutig übersteigt. Betten Sie kleine, stabile Funktionen direkt ein, wenn eine geringfügige Abhängigkeit ein unverhältnismäßiges Risiko mit sich brächte. Legen Sie Typen externer Pakete nicht über die öffentliche API des Projekts offen. Kapseln Sie das Verhalten Dritter hinter projekteigenen Schnittstellen und Typen. Verwenden Sie die Modulwerkzeuge der Sprache, um Abhängigkeitserklärungen und Prüfsummen konsistent zu halten. Führen Sie den Abhängigkeitsbereinigungsbefehl aus und prüfen Sie seine Differenz, statt sachfremde Änderungen zu übernehmen. Halten Sie Konfigurationsadapter von Laufzeitmodulen getrennt. Halten Sie Testhilfen von produktiven Einstiegspunkten getrennt. Platzieren Sie Standardmodule in dem Verzeichnis, das der ausgelieferte Befehl verwendet. Importieren Sie optionale Module nicht ohne eine ausdrückliche Produktentscheidung in das Standardprogramm. Bewahren Sie Paketgrenzen um Protokollverarbeitung, Transportsicherheit und Zertifikatsoperationen. Wählen Sie verallgemeinerte Abstraktionen erst, nachdem Sie das wiederkehrende Verhalten bestimmt haben, dem sie dienen. Lehnen Sie spekulative Abstraktionen ab, die eine einfache Implementierung verschleiern. Bewahren Sie bei Umstrukturierungen beobachtbares Verhalten oder dokumentieren und testen Sie jede beabsichtigte Änderung. Prüfen Sie sicherheitskritische Pakete und Abhängigkeitsänderungen eingehender als routinemäßigen internen Code. ## Vor dem Zusammenführen alle Tests, Lint- und Build-Prüfungen bestehen Behandeln Sie jede erforderliche Qualitätsschranke als blockierend und nicht als unverbindlichen Hinweis. Führen Sie die vollständige kurze Testsuite mit aktivierter Erkennung von Datenrennen aus. Führen Sie das konfigurierte statische Prüfwerkzeug mit genügend Zeit für das vollständige Repository aus. Erstellen Sie alle Pakete, um fehlende Schnittstellen, Plattformbeschränkungen und Registrierungsfehler zu erkennen. Führen Sie bei Leistungsänderungen Messläufe mit Speicherverbrauchsmessung aus. Vergleichen Sie die Messergebnisse mit einer geeigneten Ausgangsbasis und berücksichtigen Sie Schwankungen. Führen Sie gezielte Integrationstests für das betroffene Serververhalten aus. Stellen Sie sicher, dass die Tests unter Linux, macOS und Windows bestehen, wenn die kontinuierliche Integration diese Plattformen unterstützt. Untersuchen Sie Warnungen in geänderten Dateien, auch wenn an anderer Stelle sachfremde Warnungen bestehen. Kennzeichnen Sie einen Änderungsantrag nicht als zusammenführungsreif, solange eine erforderliche Test-, statische Prüfungs-, Erstellungs- oder Leistungsmessungsschranke fehlt. Zeichnen Sie Befehle und relevante Ergebnisse auf, damit Prüfer die Nachweise reproduzieren können. Unterscheiden Sie einen Testfehler von einem Umgebungsfehler, bevor Sie produktiven Code ändern. Halten Sie die Verifikation im Verhältnis zur Änderung und decken Sie dennoch jede direkt betroffene Schranke ab. Führen Sie betroffene Schranken nach jeder Codeänderung infolge einer Prüfung erneut aus. Behandeln Sie Berichte über Datenrennen und sporadische Nebenläufigkeitsfehler als untersuchungspflichtige Mängel. ## Tabellengesteuerte Unit-Tests und Servertests mit eigenen Ports schreiben Bevorzugen Sie tabellengesteuerte Tests, wenn mehrere Eingaben dasselbe Verhalten aufweisen. Geben Sie für jeden Fall ausdrücklich Eingabe, erwartete Ausgabe und erwarteten Fehlerzustand an. Prüfen Sie sowohl fehlende erwartete Fehler als auch unerwartet zurückgegebene Fehler. Vergleichen Sie zurückgegebene Werte erst nach angemessener Behandlung der Fehlerbedingung. Nehmen Sie gültige, ungültige, Grenz- und Regressionsfälle auf. Benennen Sie Fälle, wenn Indizes allein die Fehlerdiagnose erschweren würden. Halten Sie Testdaten minimal und deterministisch. Verwenden Sie das Servertestgerüst des Projekts für durchgängiges Konfigurationsverhalten. Initialisieren Sie Testserver mit isolierter Konfiguration und ausdrücklich angegebenen Formaten. Verwenden Sie nicht standardmäßige Ports, um Konflikte mit lokal laufenden Diensten zu vermeiden. Reservieren Sie bei Bedarf getrennte Ports für Verwaltung, unverschlüsselten Datenverkehr und verschlüsselten Datenverkehr. Prüfen Sie Status, Inhalt und anderes von außen beobachtbares Verhalten. Bereinigen Sie Server, Listener, Dateien und Goroutinen, die der Test erstellt hat. Verlassen Sie sich nicht auf die Testreihenfolge oder einen gemeinsam genutzten veränderlichen globalen Zustand. Testen Sie Konfigurationsanalysefehler ebenso wie einen erfolgreichen Serverstart. Fügen Sie plattformspezifische Fälle hinzu, wenn sich Pfade, Sockets, Signale oder Prozessverhalten unterscheiden. Begrenzen Sie Integrationstests so, dass ein Fehler den verletzten Vertrag erkennen lässt. ## Pull-Requests, Sicherheitsberichte und Vereinbarungen einem Menschen überlassen Behandeln Sie Diskussionen zu Problemberichten, Änderungsanträge, Lizenzvereinbarungen und Sicherheitsberichte als externes Handeln unter menschlicher Kontrolle. Ein KI-Assistent darf sich nicht als menschlicher Mitwirkender ausgeben oder im Namen einer Person eine rechtsverbindliche Vereinbarung annehmen. Erstellen oder übermitteln Sie keine externen Problemberichte, Änderungsanträge oder Sicherheitsberichte, sofern die maßgebliche Richtlinie diese Handlung des Agenten nicht ausdrücklich erlaubt. Beschränken Sie die Prüfunterstützung auf die erlaubte Rolle und kennzeichnen Sie die Beteiligung der KI, wenn dies erforderlich ist. Verschweigen Sie die Beteiligung der KI nicht, wenn die Beitragsrichtlinie eine Offenlegung verlangt. Verlangen Sie, dass die menschliche Bedienperson jede eingereichte Zeile versteht und erklären kann. Testen Sie KI-unterstützten Code nach Möglichkeit mit automatisierten Prüfungen und andernfalls mit gründlichen manuellen Prüfungen. Prüfen Sie erzeugten Code auf kopiertes Material, unvereinbare Lizenzen und nicht belegte Behauptungen. Erfinden Sie keine Angaben zu Schwachstellen und reichen Sie keinen ungeprüften Sicherheitsbericht ein. Übersetzungs- oder Bearbeitungshilfe muss die vom menschlichen Autor bestätigten Sicherheitsfakten bewahren. Überlassen Sie ausschließlich Menschen vorbehaltene Unterschriften, Bestätigungen und Vereinbarungen für Mitwirkende der verantwortlichen Person. Wenn eine angeforderte Handlung mit der Beitragsrichtlinie kollidiert, halten Sie diese Handlung an und erläutern Sie die maßgebliche Grenze. Fügen Sie keine täuschenden Dateien, Kommentare oder Einreichungen als Ersatz für eine verbotene externe Handlung hinzu. Erhalten Sie den technischen Nutzen der Änderung, ohne den Gemeinschaftsprozess zu umgehen. Prüfen Sie vor der Genehmigung Offenlegung, Verständnis, Tests und Lizenzierung als getrennte Schranken. Die menschliche Verantwortung bleibt auch dann erforderlich, wenn ein Agent den Großteil der Implementierung erstellt hat.