Härtungsoptionen¶

Härtungsoptionen sind eine Reihe von Techniken in Produktionsqualität, die Sie von der KI in ein Skript integrieren lassen können, das sie generiert oder neu schreibt. Anstatt jedes Mal die gleiche Anweisung („Fehlerbehandlung hinzufügen“, „Wiederausführbar machen“, „Geben Sie ihm einen --help“) von Hand zu schreiben, kreuzen Sie die gewünschten Techniken an und KorTTY wandelt jede einzelne in eine präzise Regel um, die an die KI-Eingabeaufforderung angehängt wird. Das Ergebnis ist ein Skript, das sich wie etwas verhält, das ein sorgfältiger Ingenieur liefern würde: Es schlägt laut statt lautlos fehl, bereinigt sich selbst, protokolliert, was es tut, und kann ohne Überraschungen erneut ausgeführt werden.

Die gleichen elf Optionen werden überall dort verwendet, wo KorTTY ein Skript generiert oder verbessert, sodass sie sich unabhängig von der Ausgangsposition identisch verhalten.

Wo sie erscheinen¶

Das Bedienfeld Härtungsoptionen wird an folgenden Stellen angezeigt:

Jede Option ist standardmäßig aktiviert. Deaktivieren Sie diejenigen, die Sie nicht möchten. Eine deaktivierte Option trägt nichts zur Eingabeaufforderung bei.

Bei Robustheit verbessern und Benutzerdefinierte Verbesserung werden aktive Härtungsregeln auf das vollständige Snippet angewendet, auch wenn Sie nur einen Bereich markiert haben. Dies ist erforderlich, da Optionen wie der strikte Modus, ein Konfigurationsblock, --help und eine abschließende Zusammenfassung den Prolog oder Epilog und nicht nur die ausgewählten Zeilen ändern müssen. Wenn Sie Löschen verwenden und die Eingabe-Härtung deaktiviert lassen, bleibt die normale Verbesserung auf den ausgewählten Bereich beschränkt. Das Complete-Snippet-Ergebnis wird weiterhin in der Vorher-/Nachher-Überprüfung angezeigt und verworfen, wenn die KI unveränderten Code mit einer Auslassungsmarkierung abkürzt.

Unterhalb der Optionen helfen Ihnen drei Schaltflächen bei der Verwaltung der Auswahl:

• Alle – kreuzen Sie jede Option an.
• Clear – alle Optionen deaktivieren (ohne Härtungsregeln generieren/anwenden).
• Speichern – aktuelle Auswahl dauerhaft speichern. Von da an wird jedes Härtungsfenster mit Ihrer gespeicherten Auswahl anstelle der allgemeinen Standardeinstellung geöffnet – Sie können also Ihre bevorzugte Härtung einmal festlegen und sie überall anwenden.

Wie sie angewendet werden¶

Jede aktivierte Option wird zu einer maßgeblichen Härtungsregel, die KorTTY an die an die KI gesendete Anfrage anhängt (unter Diese Härtungstechniken anwenden: im Snippet-Editor oder ZUSÄTZLICHE ANFORDERUNGEN: im Workflow-Generator). Im Anwendungsfluss „Vollständige Codeanalyse“ wird jeder ausgewählten Regel zusätzlich ein eigener obligatorischer Bezeichner zugewiesen: Die KI gibt die von ihr vervollständigten Bezeichner in einer kompakten Liste zurück, und korTTY lehnt die gesamte Antwort ab, wenn ein Bezeichner fehlt. Explizite CLI- und Guard-Literale wie --dry-run, --yes, --help und --verbose müssen ebenfalls vorhanden sein, wenn die entsprechenden Optionen ausgewählt sind. Bei der Workflow-Generierung werden auch die entsprechenden zielsprachlichen Redewendungen hinzugefügt – beispielsweise die Bash-Schreibweise des strengen Modus – nur dann, wenn diese Option ausgewählt ist. Durch Deaktivieren einer Option werden sowohl ihre Regel als auch ihre optionspezifischen Sprachidiome entfernt. Clear sendet daher kein härtendes Verhalten, abgesehen von neutralen Anforderungen, die zum Erstellen gültigen Codes in der gewählten Sprache erforderlich sind.

Der Wortlaut jeder Regel passt sich der Zielsprache an:

• Imperative Skripte – Bash, Python, Perl, Ruby, PowerShell, Windows-CMD und AppleScript erhalten die imperative Formulierung (Flags, Traps, Exit-Codes, …).
• Deklarative Artefakte – Ansible-Playbooks und Snippets, deren Sprache YAML/YML ist oder ansible enthält, erhalten stattdessen Ansible-idiomatische Formulierungen (block/rescue/always, assert, vars:, Prüfmodus, …).

Die Idee jeder Option ist also überall gleich, aber ein Bash-Skript erhält eine set -euo pipefail-Stilregel, während ein Ansible-Playbook eine assert/failed_when-Stilregel für genau dasselbe Kontrollkästchen erhält.

Die beiden Gruppen¶

Die elf Optionen lassen sich aufgrund ihrer Auswirkung auf das Skript in zwei Gruppen einteilen:

• Verhaltenserhaltende Härtung (die ersten sieben) fügt lediglich Dokumentation, Protokollierung, Struktur und Sicherheitsnetze hinzu. Sie machen das Skript stabiler und leichter lesbar, ohne seine eigentliche Funktion zu ändern. Diese können bei fast jedem Drehbuch bedenkenlos aktiviert bleiben.
• Verhaltens-/interaktive Änderungen (die letzten vier) können den Kontrollfluss ändern oder eine Befehlszeilenschnittstelle hinzufügen – Vorbedingungs-Gates, Erkennung erneuter Ausführung, ein Probelaufmodus, Argumentanalyse. Lassen Sie sie weg, wenn Sie möchten, dass die Umschreibung so nah wie möglich am ursprünglichen Verhalten bleibt.

Optionsreferenz¶

Jede Option unten listet auf, wozu sie dient und welche genaue Regel KorTTY an die KI sendet – für imperative Skripte und für Ansible-Playbooks.

Verhaltenserhaltendes Härten¶

Strikter Modus (Abbruch bei Fehler)¶

• Wofür es ist – Stoppen Sie das Skript, sobald etwas schief geht, anstatt blind in einem halb gescheiterten Zustand fortzufahren.
• Imperative Skripte – Aktivieren Sie den Strict-/Abort-on-Error-Modus der Sprache (z. B. set -euo pipefail in Bash, Set-StrictMode -Version Latest mit $ErrorActionPreference = 'Stop' in PowerShell, use strict; use warnings; in Perl).
• Ansible-Playbooks – Überprüfen Sie die Voraussetzungen mit assert/failed_when, damit die Wiedergabe aufgrund eines fehlerhaften Zustands sofort fehlschlägt.

Fehlerfalle und -bereinigung¶

• Wofür es ist – Gewährleisten, dass ein Fehler klar gemeldet wird und dass jeder temporäre Status (temporäre Dateien, Bereitstellungen, Sperren) bereinigt wird, selbst wenn das Skript abgebrochen wird.
• Imperative Skripte – Fügen Sie einen Fehler-Trap-/finally-/ensure-Block hinzu, der Fehler meldet und den temporären Status bereinigt.
• Ansible-Playbooks – Verwenden Sie block/rescue/always, damit Fehler abgefangen werden und die Bereinigung immer ausgeführt wird.

Aussagekräftige Exit-Codes¶

• Wofür es ist – Lassen Sie denjenigen, der das Skript aufruft (einen Scheduler, einen CI-Job, ein anderes Skript), sagen, warum es fehlgeschlagen ist, nicht nur dass es fehlgeschlagen ist.
• Imperative Skripte – Verwenden Sie unterschiedliche, dokumentierte Exit-Codes ungleich Null für unterschiedliche Fehlerklassen.
• Ansible-Playbooks – Sorgen Sie dafür, dass fehlgeschlagene Aufgaben das Spiel mit einer klaren Botschaft stoppen (any_errors_fatal, wo sinnvoll).

Protokollierung (--verbose)¶

• Wofür es ist – Machen Sie den Fortschritt des Skripts sichtbar und debuggbar, ohne die normale Ausgabe zu überladen.
• Imperative Skripte – Senden Sie zeitgestempelte Protokollnachrichten an stderr und unterstützen Sie ein --verbose/-v-Flag.
• Ansible-Playbooks – Verwenden Sie das Modul debug für die Fortschrittsausgabe (sichtbar mit -v).

Konfigurationsblock für Literale¶

• Wofür es ist – Sammeln Sie die Werte, die Sie am wahrscheinlichsten ändern (Pfade, Hostnamen, Paketnamen), an einer offensichtlichen Stelle, anstatt sie über das Skript zu verteilen.
• Imperative Skripte – Heben Sie alle Literale (Pfade, Hosts, Pakete) in einen klar kommentierten Konfigurationsblock oben.
• Ansible-Playbooks – Heben Sie alle Literale in einen vars:-Block oben.

Abschlusszusammenfassung¶

• Wofür es ist – Schließen Sie mit einem kurzen Bericht ab, damit der Bediener auf einen Blick sehen kann, was passiert ist.
• Imperative Skripte – Drucken Sie eine abschließende Zusammenfassung dessen, was getan wurde (mit Erfolgs-/Misserfolgszählung).
• Ansible-Playbooks – Beenden Sie mit einer debug-Zusammenfassung der Änderungen.

Style-Guide / Linter reinigen¶

• Wofür es ist – Erstellen Sie Code, der den Standard-Linter der Sprache erfüllt, sodass er konsistent liest und häufige Fehler vermeidet.
• Imperative Skripte – Befolgen Sie den Sprachstil-Guide und halten Sie ihn sauber (z. B. ShellCheck-clean für Bash).
• Ansible-Playbooks – Befolgen Sie die ansible-lint-Konventionen und verwenden Sie vollständig qualifizierte Modulnamen.

Verhaltens-/interaktive Änderungen¶

Vorbedingungsprüfungen¶

• Wofür es ist – Machen Sie schnell einen Fehler, bevor Sie irgendetwas anfassen, wenn die Umgebung nicht bereit ist – ein fehlender Befehl, unzureichende Berechtigungen oder kein Netzwerk.
• Imperative Skripte – Überprüfen Sie vor der Arbeit die erforderlichen Befehle, Berechtigungen (root/sudo) und Konnektivität.
• Ansible-Playbooks – Fügen Sie vor jeder Änderung pre_tasks/assert-Prüfungen auf erforderliche Berechtigungen, Pakete und Konnektivität hinzu.

Idempotency (abgeschlossene Schritte überspringen)¶

• Wozu es dient – Machen Sie das Skript sicher für die zweite Ausführung: Schritte, die bereits ausgeführt wurden, werden erkannt und übersprungen, anstatt wiederholt zu werden oder einen Fehler zu verursachen.
• Imperative Skripte – Erkennen Sie bereits abgeschlossene Schritte und überspringen Sie sie, damit das Skript sicher erneut ausgeführt werden kann.
• Ansible-Playbooks – Stellen Sie sicher, dass das Playbook vollständig idempotent ist (sichere Wiederholung; verlassen Sie sich auf Modul-Idempotenz und creates/removes).

Abgesicherter Modus (--dry-run + bestätigen)¶

• Wozu es dient – Lassen Sie den Bediener eine Vorschau dessen anzeigen, was das Skript tun würde, ohne Änderungen vorzunehmen, und bitten Sie ihn um Bestätigung, bevor etwas destruktives geschieht.
• Imperative Skripte – Unterstützt ein --dry-run-Flag, das beabsichtigte Aktionen ohne Ausführung ausgibt und vor destruktiven Vorgängen bestätigt (unterdrückbar mit --yes).
• Ansible-Playbooks – Unterstützt den Prüfmodus (--check) und schützt destruktive Aufgaben, sodass ein Probelauf keine Änderungen vornimmt.

--help & Argumentanalyse¶

• Wofür es ist – Verwandeln Sie das Skript in ein richtiges Befehlszeilentool mit dokumentierten, überschreibbaren Eingaben anstelle von fest codierten Werten.
• Imperative Skripte – Stellen Sie eine --help/usage-Nachricht bereit und analysieren Sie Befehlszeilenargumente für die konfigurierbaren Werte.
• Ansible-Playbooks – Dokumentieren Sie alle Variablen und wie Sie sie über --extra-vars am Anfang der Datei überschreiben können.

Tipps¶

• Beginnen Sie mit den Standardeinstellungen (alle aktiviert) für ein wegwerfbares oder persönliches Skript – die verhaltenserhaltende Gruppe kostet Sie nichts und die interaktive Gruppe macht das Skript benutzerfreundlicher.
• Für eine Umschreibung, bei der Sie den kleinstmöglichen Unterschied wünschen, deaktivieren Sie die vier Verhaltensoptionen und behalten Sie nur die verhaltenserhaltende Gruppe bei.
• Die Optionen sind unabhängig – Sie können jede beliebige Kombination ankreuzen. KorTTY sendet nur Regeln für die angekreuzten Kästchen.