Erweitere einen anpassbaren Go-Dienst um Funktionen und Tests, die Konfigurationsüberschreibungen standhalten

## Finde vor dem Bearbeiten das Paket, das für die Änderung zuständig ist Ordne die Änderung ein und ermittle die maßgebliche Quelle, bevor du Code bearbeitest. - Ermittle den Einstiegspunkt des Befehls, die Fachlogikpakete, die Konfigurationsschicht, die Transport- und Berechtigungsschicht, die Protokollumsetzung, die Ausgabeschicht, die Capability-Registry und die Versionsmetadaten. - Belasse die Geschäftslogik in den dafür zuständigen Quellpaketen statt in der Befehlsverdrahtung oder in Verteilungshüllen. - Behandle Verzeichnisse für Sprachpakete und Installationsprogramme als schlanke Adapter für die Binärverteilung; ändere sie nur für Paketierungs- oder Versionsarbeiten. - Lies die Erstellungsdefinitionen, die Testkonfiguration, benachbarte Umsetzungen und die benutzerbezogene Dokumentation, die den betroffenen Bereich bestimmen. - Unterscheide vor der Bearbeitung manuell erstellte Quellen von erzeugten Dateien und Erstellungserzeugnissen. - Führe alle betroffenen Verarbeitungsfunktionen, öffentlichen Typen, Eintragungsstellen, Konfigurationspfade, Tests, Dokumente und Paketschnittstellen auf. Verwende die bestehende Gliederung und die Namenskonventionen der Projektablage, statt eine parallele Struktur einzuführen. ## Logge über den Kontext-Wrapper, damit Logs mit Traces verbunden bleiben Verwende immer die kontextbezogene Protokollierungshülle der Projektablage, wenn Produktionscode einen Eintrag ausgibt. - Reiche den Anfragekontext bis zu der Stelle weiter, an der die Protokollierung erfolgt; ergänze einen Kontextparameter, wenn die Aufrufkette noch keinen mitführt. - Rufe den grundlegenden Kontextprotokollierer des Rahmenwerks nicht direkt auf, wenn die Hülle Einträge für die Telemetriekorrelation anreichert. - Beginnt eine Funktion einen neuen Abschnitt der Ablaufverfolgung, rufe den kontextbezogenen Protokollierer nach dessen Beginn erneut ab; ein zuvor erfasster Protokollierer behält den älteren Ablaufverfolgungskontext. - Halte strukturierte Werte mit dem aktiven Kontext verknüpft, damit die Protokollierungsbrücke Einträge der richtigen Ablaufverfolgung zuordnen kann. - Prüfe und behandle jeden zurückgegebenen Fehler im Produktionscode, statt ihn zu verwerfen. - Bewahre beim Hinzufügen von Diagnoseinformationen die bestehenden Grenzen der Projektablage für Datenmaskierung, Berechtigung und Beobachtbarkeit. Prüfe Korrelation und Fehlerverhalten anhand beobachtbarer Ergebnisse, statt dich nur auf das Vorhandensein einer Protokollanweisung zu verlassen. ## Füge neue Tools über Handler, Gruppe und Registrierung hinzu Entwirf eine neue Fähigkeit vor ihrer Umsetzung: Bestätige Name, Gruppierung, Eingabeschema, Verhalten und Bewertungsabdeckung. 1. Implementiere die Verarbeitungsfunktion, die für die Logik der Fähigkeit zuständig ist. 2. Definiere den öffentlichen Werkzeug- oder Befehlsvertrag und verbinde ihn mit der Verarbeitungsfunktion. 3. Füge die Fähigkeit der passenden Fähigkeitsgruppe hinzu oder erstelle eine klar abgegrenzte Gruppe, wenn keine geeignet ist. 4. Registriere eine neue Gruppe über den Initialisierungspfad der Projektablage. 5. Aktualisiere Verhaltenstests, Konfigurationsreferenzen, generierte Kataloge und Benutzerdokumentation gemeinsam. Bewahre jede Fähigkeitsgruppe in einem eigenen, dafür vorgesehenen Verzeichnis auf. Vermeide doppelte Registrierungspfade oder Namen, die interne Umsetzungsdetails offenlegen. ## Nutze die festgelegten Build-Targets und deploye nur auf Auftrag Verwende die festgelegten Erstellungsziele der Projektablage, statt Befehle aus dem Gedächtnis nachzubilden. - Kläre vor der Ausführung, welches Erstellungsziel den Quelltext formatiert, Module bereinigt, für eine Plattform kompiliert oder alle unterstützten Plattformen erstellt. - Prüfe den entstandenen Änderungsvergleich, da ein Erstellungsziel Abhängigkeitsmetadaten oder erzeugte Dateien absichtlich neu schreiben kann. - Halte Abhängigkeitserklärungen nach dem Einführen eines Moduls sauber und führe das von der Projektablage versionsgenau festgelegte Ziel für statische Analyse aus. - Bewahre unterstützte lokale und entfernte Ausführungsarten einschließlich der dokumentierten Rangfolge von ausdrücklich gesetzten Befehlsoptionen, Umgebungsvariablen, Standarddateien und Konfiguration innerhalb des Rechenverbunds. - Dokumentiere Test- oder Prüfziele, die bei der ersten Verwendung Werkzeuge oder Umgebungen herunterladen; fehlender Netzzugang kann Einrichtungsfehler statt Codefehler verursachen. - Halte Hüllen der Paketverwaltung schlank und mit dem kompilierten Binärprogramm abgestimmt, statt Dienstlogik zu duplizieren. Behandle Ziele zum Herunterladen, Veröffentlichen, Übertragen oder Ausrollen als Grenzen externer Vorgänge. Prüfe zuerst ihre Verträge und veröffentliche oder rolle niemals aus, sofern die Aufgabe nicht ausdrücklich Veröffentlichungsarbeiten umfasst. ## Teste öffentliches Verhalten und Grenzfälle statt privater Funktionen Behandle die öffentliche API beim Testen als gekapseltes System und bevorzuge, sofern praktikabel, echte Umsetzungen oder Integrationstests. - Strukturiere Tests nach der Sammlungskonvention der Projektablage und gib jeder Testdatei eine zugehörige Testsammlung. - Gruppiere verwandte Fälle mit verschachtelten Untertests und gib jedem Fall einen aussagekräftigen, verhaltensbezogenen Namen. - Im Idealfall weist jeder Fall mit einer gezielten Zusicherung genau ein Verhalten nach. - Decke Erfolgsfälle, Rückruffunktionen, Zustandsänderungen und beobachtbare Ausgaben ab, ohne Tests an private Funktionen zu koppeln. - Ergänze Grenzfälle für nil- oder null-Werte, leere Sammlungen, ungültige Indizes, Typabweichungen, fehlerhaft geformte Eingaben und Fehlerpfade. - Verwende Voraussetzungssicherungen für Einrichtungsvorgänge, die erfolgreich sein müssen, und sichere anschließend erwartete Fehler oder Werte ausdrücklich zu. - Ignoriere niemals einen Fehler, nur um einen Test knapp zu halten. Beginne bei einem Fehler mit einem gezielten, fehlschlagenden Test, führe nach der Korrektur das betroffene Paket oder die betroffene Testsammlung aus und schließe mit dem vorgeschriebenen vollständigen Testziel der Projektablage ab. ## Halte Konfigurationstests grün, wenn Standardwerte und Namen überschrieben werden Konfigurationstests müssen gültig bleiben, wenn nachgelagerte Erstellungen Standardwerte, Funktionsnamen oder aktivierte Fähigkeitsmengen überschreiben. - Beginne gewöhnliche Testsammlungen mit einer überschreibungsfreien Ausgangskonfiguration und lege anschließend testspezifische Einstellungen darüber. - Führe bei einfacher Konfiguration dekodierte Werte mit der vorhandenen Konfiguration der Testsammlung zusammen, damit die bereits vom Testgerüst gesetzten Laufzeitfelder erhalten bleiben. - Speichert ein Abschnitt verzögerte oder primitive Werte, verwende das erforderliche, Metadaten berücksichtigende zweistufige Lesewerkzeug, um diese Abschnitte vollständig einzulesen. - Stelle nach dem vollständigen Einlesen einer Konfiguration ausdrücklich reine Laufzeitfelder wie Verbindungspfade, Ausgabeauswahl und Nur-Lese-Zustand wieder her. - Erzeuge bei Neuladetests den Kandidaten bewusst aus den überschreibungsfähigen Standardwerten des laufenden Dienstes und übernimm anschließend die aktiven Laufzeitfelder. - Hänge erforderliche Fähigkeiten an die bestehende Liste an; ersetze die Liste niemals durch lediglich angenommene vorgelagerte Standardwerte. - Ermittle öffentlich sichtbare Namen, die für Markenänderungen umbenannt werden können, dynamisch, halte aber den wörtlichen Registrierungsschlüssel eines Analyseprogramms fest, wenn dessen Vertrag dies verlangt. - Trage überschreibungsanfällige Standardwerte, öffentliche Namen oder Funktionsmengen niemals fest in Zusicherungen ein. Teste sowohl das Grundverhalten als auch mindestens einen Überschreibungspfad, sobald Konfigurationsänderungen diese Grenzen überschreiten. ## Bündle Test-Helfer an einer Stelle und trenne Setup-Fehler von Produktfehlern Lege allgemeine Testhilfen im gemeinsamen internen Testbereich der Projektablage ab und dokumentiere Zweck, Eingaben und Beispiele eindeutig. - Halte Hilfen unabhängig von einer einzelnen Funktion, damit mehrere Pakete sie wiederverwenden können. - Bevorzuge realistische Benutzer- oder Protokollinteraktionen gegenüber systemnahen Abkürzungen, die das Produktionsverhalten umgehen. - Benenne Testvoraussetzungen ausdrücklich, darunter lokale Rechenverbundsimulatoren, heruntergeladene Umgebungen, Zugangsdaten oder erforderlicher Netzzugang. - Unterscheide in Diagnoseinformationen einen Einrichtungsfehler von einem Produktfehler. - Strebe eine hohe Abdeckung der öffentlichen API an, besonders für Grenzbedingungen und Fehlerpfade, ohne Messwerte mit wenig wertvollen Fällen aufzublähen. - Halte Testkonfiguration, Aliasnamen und erzeugte Testdaten auf das aktive Testausführungsprogramm abgestimmt. Wenn nachgelagerte Anpassungen bestehen, nimm repräsentative Tests für umbenannte Fähigkeiten, geänderte Standardwerte und das Neuladen der Konfiguration auf. ## Aktualisiere Doku über den Generator und halte Pakete auf derselben Version Aktualisiere jede maßgebliche Fläche, die von einer Code- oder Konfigurationsänderung betroffen ist. - Verwende für neue Dokumentation Dateinamen in Kleinbuchstaben, wenn dies der Konvention der Projektablage entspricht. - Aktualisiere Indizes, Konfigurationsreferenzen, Prompts, Protokollierung, Beobachtbarkeit, Authentifizierung und Integrationsleitfäden entsprechend den Auswirkungen der Funktion. - Behandle erzeugte Tabellen und Referenzabschnitte als erzeugten Inhalt; bewahre ihre Markierungspaare und aktualisiere sie mit dem genehmigten Erzeugungsprogramm. - Bearbeite erzeugte Abschnitte nicht direkt und übernimm keine Erstellungserzeugnisse in die Versionsverwaltung, sofern die Richtlinie der Projektablage dies nicht ausdrücklich verlangt. - Halte native Binärprogramme, Container-Abbilder und Hüllen für Sprachpakete mit demselben versionierten Dienstverhalten im Einklang. - Führe die dokumentierten, für die Änderung relevanten Erstellungs-, Test-, Prüf-, Dokumentationserzeugungs- und gezielten Paketierungskontrollen aus. Bestätige vor der Vorstellung der Änderung, dass der abschließende Änderungsvergleich nur beabsichtigte Aktualisierungen an Quelltext, Tests, Dokumentation und Paketen enthält. Führe Release- oder Veröffentlichungsziele nur aus, wenn die Aufgabe sie ausdrücklich umfasst, und melde alle weitergehenden Prüfungen, die bewusst außerhalb des Umfangs blieben.