Claude Code / Codex
Anweisungs-Prompts & Vorlagensammlung

Lies die Anweisungsdatei, die du (dieser Agent) lädst (CLAUDE.md / AGENTS.md usw.),
benenne die Schwachstellen, die KI-Agenten gerne ignorieren, und schreibe sie
dann in eine wirksame Form um.

Worauf zu achten ist:
- Wandle vage Formulierungen in Imperative um (immer X tun / niemals Y tun)
- Füge eine \'Definition of Done\' und Verifizierungsschritte hinzu (lint / test ausführen)
- Mache Verbote konkret bis zum Ziel (Verzeichnisnamen, Befehlsnamen)
- Ist sie zu lang, kürze sie auf den durchzusetzenden Kern

Liste zuerst die Schwachstellen als Aufzählungspunkte auf, gib dann die
vollständige umgeschriebene Version aus und wende sie auf diese Anweisungsdatei an.

Nachdem du die tatsächlichen build- / test- / lint-Befehle dieses Repositorys
ermittelt hast, füge der Anweisungsdatei, die du lädst (CLAUDE.md / AGENTS.md usw.),
einen Abschnitt \'Definition of Done\' hinzu.

Anforderungen:
- Mache daraus eine Checkliste in der Form \'melde nicht fertig, bevor alle
  folgenden Punkte erfüllt sind\'
- Gib die echten lint- und test-Befehle ausdrücklich an
- Schließe ein: keine TODOs oder Debug-Logs in geänderten Dateien hinterlassen
  und das eigene Diff erneut durchlesen

Zerstöre den bestehenden Inhalt nicht; füge nur den Abschnitt hinzu.

Erkenne automatisch die Sprache und das Framework dieses Repositorys und füge
die entsprechenden Best-Practice-Regeln der Anweisungsdatei hinzu, die du lädst
(CLAUDE.md / AGENTS.md usw.).

Beispiele:
- Next.js: Server/Client-Grenze (Standard ist Server, use client minimal halten)
- Laravel: Validierung über Form Requests, Migrations-Konventionen
- Python: Typannotationen, Rohdaten niemals überschreiben oder erfinden

Füge vor dem Anhängen eine einzeilige Notiz zur Grundlage deiner Erkennung hinzu
(aus welchen Dateien du es beurteilt hast). Dupliziere nichts bereits Geschriebenes.

Füge der Anweisungsdatei, die du lädst (CLAUDE.md / AGENTS.md usw.), die folgenden
\'absoluten Regeln\' hinzu, abgestimmt auf das Setup dieses Repositorys.

- Niemals Geheimnisse, .env oder Zugangsdaten committen
- Niemals pushen / force-pushen, sofern nicht angewiesen
- Eingaben an der Grenze validieren / niemals eigenmächtig Authentifizierung
  oder Autorisierung lockern
- Niemals destruktive Befehle (DROP / TRUNCATE / migrate:fresh usw.) auf der
  Produktions-DB ausführen
- Wann immer du das Verhalten änderst, immer Tests hinzufügen oder aktualisieren

Existieren bereits ähnliche Regeln, dupliziere sie nicht; ergänze nur das Fehlende.

Konvertiere den Inhalt dieser `CLAUDE.md` ins `AGENTS.md`-Format für
OpenAI Codex und schreibe ihn aus.

- Erhalte die Bedeutung, gib ihm aber eine für Codex gut lesbare Struktur
  (Überschriften, Aufzählungspunkte)
- Behalte Befehle, absolute Regeln und Definition of Done unverändert bei
- Gib es als `AGENTS.md` im Wurzelverzeichnis aus

Konvertiere den Inhalt dieser `CLAUDE.md` ins Project-Rules-Format von Cursor
(`.mdc`-Dateien unter `.cursor/rules/`).

- Teile die Regeln in sinnvolle Einheiten auf
- Trenne die Regeln, die stets gelten sollen, von den Regeln, die nur für
  bestimmte Dateitypen gelten
- Setze am Anfang jeder Datei die passenden Anwendungsbedingungen (globs usw.)

Untersuche die Struktur dieses Monorepos und erstelle die Anweisungsdateien,
die du (dieser Agent) lädst (Claude Code nutzt CLAUDE.md, Codex nutzt AGENTS.md usw.),
wie folgt aufgeteilt.

- Im Wurzelverzeichnis: Regeln, die für das gesamte Repo gelten
  (Commit-Konventionen, Geheimnisschutz, die übergreifende Definition of Done)
- In jedem Paket-/App-Verzeichnis: nur die Regeln und Befehle, die für diesen Stack gelten

Vermeide Duplikate und füge in jedem Paket eine einzeilige Notiz hinzu: \'folge den
gemeinsamen Regeln im Wurzelverzeichnis\'. Berichte am Ende eine Liste, was du in welchem Verzeichnis abgelegt hast.

# Projekt: <name>

## Was das ist
Ein einabsätziger Überblick über die App. Was sie macht, wer sie nutzt und der
Tech-Stack (Sprache, Framework, DB, Runtime).

## Befehle
- Dev-Server: `npm run dev`
- Build:      `npm run build`
- Test:       `npm test`
- Lint:       `npm run lint`

## Konventionen
- Sprache ist TypeScript (strict). Verwende kein `any`.
- Passe dich dem Stil der Datei an, die du gerade bearbeitest. Bestehe Lint immer vor dem Abschluss.
- Halte Änderungen minimal; berühre keine nicht betroffenen Zeilen (keine unzusammenhängende Umformatierung).

## Absolute Regeln (strikt durchgesetzt)
- Bevor du fertig meldest, führe immer die obigen Tests und Lint aus und lass sie bestehen.
- Committe niemals, unter keinen Umständen, Geheimnisse, .env oder Build-Artefakte.
- Bevorzuge das Bearbeiten bestehender Dateien gegenüber dem Erstellen neuer.
- Sind die Anforderungen vage, stelle vor einer großen Änderung genau eine klärende Frage.

## Tabu (sofern nicht anders angewiesen)
- CI-Konfiguration, Abhängigkeitsversionen, Infrastruktur-Setup.

# <name>

- Stack: <z. B. Next.js + TypeScript + PostgreSQL>
- Vor dem Abschluss immer ausführen: `npm run lint` und `npm test` (beide müssen bestehen)
- Passe dich dem bestehenden Stil an. Formatiere keine nicht betroffenen Zeilen um.
- Committe keine Geheimnisse oder .env. Pushe nicht, bis du angewiesen wirst.
- Im Zweifel nicht raten; stelle genau eine Frage.

# Next.js (App Router) + TypeScript

## Stack
Next.js (App Router), TypeScript strict, Tailwind CSS, <your-ORM>

## Befehle
- Dev:   `npm run dev`
- Build: `npm run build`   # muss ohne Typfehler bestehen
- Lint:  `npm run lint`
- Test:  `npm test`

## Architektur-Regeln
- Standardmäßig Server Components. Füge "use client" nur hinzu, wenn State,
  Effekte oder Browser-APIs nötig sind. Halte Client Components klein und an den Blättern.
- Hole Daten in Server Components oder Route Handlers.
  Hole keine initialen Daten in useEffect.
- Platziere Komponenten beim zugehörigen Route-Segment. Gemeinsame UI kommt nach `components/`.
- Validiere externe Eingaben an der Grenze immer per Schema (z. B. Zod).

## Konventionen
- Kein `any`. Gib öffentlichen Funktionen explizite Rückgabetypen.
- Verwende die bestehenden Design-Tokens / Tailwind-Klassen. Füge keine Farben eigenmächtig hinzu.
- Halte `page.tsx` schlank; verlagere Logik in Funktionen und Komponenten.

## Definition of Done
`npm run build`, `npm run lint` und `npm test` bestehen alle mit Exit-Code 0.
Kein `any`, keine ungenutzten Exports, kein übrig gebliebenes console.log.

# React (Vite) + TypeScript

## Befehle
- Dev:   `npm run dev`
- Build: `npm run build`
- Lint:  `npm run lint`
- Test:  `npm test` (Vitest + Testing Library)

## Regeln
- Nur Funktionskomponenten und Hooks. Verwende keine Klassenkomponenten.
- Halte State minimal, in der Reihenfolge "lokal -> Context -> State-Bibliothek".
  Hebe State nicht unnötig auf Global an.
- Schließe Seiteneffekte in useEffect ein und schreibe das Dependency-Array korrekt.
- Trenne UI von Logik. Bündle das Daten-Fetching in dedizierten Hooks (useXxx).
- Barrierefreiheit: Gib interaktiven Elementen passende Rollen und Tastaturbedienung.

## Konventionen
- Kein `any`. Definiere Props mit Typen.
- Passe dich dem Stil der bestehenden Komponenten und Styles an.

## Definition of Done
`npm run build`, `npm run lint` und `npm test` bestehen mit Exit-Code 0.

# Node.js API (Express / Hono) + TypeScript

## Befehle
- Dev:   `npm run dev`
- Build: `npm run build`
- Test:  `npm test`
- Lint:  `npm run lint`

## Regeln
- Validiere alle Eingaben (body, query, params, headers) an der Grenze per Schema.
- Verschlucke keine Fehler. Gib sie typisiert über einen zentralen Error-Handler zurück.
- Lies Geheimnisse aus Umgebungsvariablen. Hardcode sie nicht im Code.
- Schichte den DB-Zugriff (route -> service -> repository).
- Gib eine konsistente JSON-Form zurück (vereinheitliche Erfolgs- und Fehlerform).

## Absolute Regeln
- Überspringe oder lockere Authentifizierungs-/Autorisierungslogik nicht eigenmächtig.
- Verifiziere stets die Autorisierung, wenn du einen öffentlich zugänglichen Endpunkt hinzufügst.
- Logge keine personenbezogenen Daten, Tokens oder Passwörter.

## Definition of Done
`npm test` (Happy Path + Fehlerfälle) und `npm run lint` bestehen.

# Laravel + PHP

## Befehle
- Serve:   `php artisan serve`
- Migrate: `php artisan migrate`
- Test:    `php artisan test`
- Format:  `./vendor/bin/pint`   # vor dem Abschluss ausführen

## Konventionen (folge dem Laravel-Weg)
- Verwende Eloquent-Relationen. Vermeide rohes SQL ohne klaren Grund.
- Validiere Eingaben in Form-Request-Klassen. Mache es nicht in Controllern.
- Halte Controller schlank. Verlagere Geschäftslogik in Services / Actions.
- Jede Schemaänderung bekommt eine neue Migration. Bearbeite keine bereits ausgeführten.
- Verwende benannte Routes und Route Model Binding.

## Absolute Regeln
- Committe niemals, unter keinen Umständen, `.env` oder echte Zugangsdaten.
- Führe keine destruktiven Befehle wie `migrate:fresh` gegen die Produktions-DB aus.
- Wann immer du das Verhalten änderst, füge immer Tests hinzu oder aktualisiere sie (`php artisan test`).

## Definition of Done
Sowohl `php artisan test` als auch `./vendor/bin/pint --test` bestehen.

# Python / Datenanalyse

## Umgebung
- Verwende das Projekt-venv `.venv`. Installiere nicht global.
- Installation: `pip install -r requirements.txt`
- Ausführen: `python -m src.main`
- Test: `pytest`
- Format: `ruff check .` und `ruff format .`

## Konventionen
- Füge jeder Funktionssignatur Typannotationen hinzu. Führe `mypy src` aus, falls konfiguriert.
- Schreibe keine Logik in Notebooks. Wiederverwendbarer Code kommt nach `src/`.
- Fixiere den Seed für alles, was Zufälligkeit nutzt, damit Ergebnisse reproduzierbar sind.

## Absolute Datenregeln (am wichtigsten)
- Fülle fehlende Werte nicht stillschweigend aus und erfinde sie nicht. Gibt es
  fehlende Werte, melde sie und kläre, wie sie zu behandeln sind.
- Überschreibe keine Rohdatendateien. Schreibe die Ausgabe nach `data/processed/`.
- Dokumentiere alle Annahmen (Filter, ausgeschlossene Zeilen, Einheiten) in Code-Kommentaren.

## Definition of Done
`pytest` besteht, `ruff check .` ist sauber, und die Ergebnisse sind aus einem sauberen Zustand reproduzierbar.

# Go

## Befehle
- Build:  `go build ./...`
- Test:   `go test ./...`
- Format: `gofmt -w .` und `go vet ./...`

## Konventionen
- Verschlucke keine Fehler. Behandle sie immer mit `if err != nil` und gib sie
  mit Kontext zurück (`fmt.Errorf("...: %w", err)`).
- Halte die Verschachtelung mit frühen Returns flach.
- Nutze Nebenläufigkeit nur, wenn nötig. Achte auf Goroutine-Leaks und Races
  (lass `go test -race` bestehen).
- Kommentiere exportierte Symbole. Bevorzuge die Standardbibliothek.

## Absolute Regeln
- Füge keine unnötigen Abstraktionen oder Interfaces hinzu (erstelle sie bei Bedarf).
- Bevor du eine Abhängigkeit hinzufügst, prüfe zuerst, ob die Standardbibliothek genügt.

## Definition of Done
`go build ./...`, `go vet ./...` und `go test -race ./...` bestehen alle.

# Rust

## Befehle
- Build:  `cargo build`
- Test:   `cargo test`
- Lint:   `cargo clippy -- -D warnings`
- Format: `cargo fmt`

## Konventionen
- Verwende `unwrap()` / `expect()` in Produktionscode nicht leichtfertig.
  Behandle `Result` / `Option` korrekt mit `?` oder match.
- `unsafe` ist grundsätzlich verboten. Falls wirklich nötig, nenne den Grund in einem Kommentar.
- Folge dem Compiler bei Borrowing und Lifetimes. Überdenke das Design, bevor du
  mit `clone()` ausweichst.
- Mache Fehlertypen mit `thiserror` / `anyhow` usw. aussagekräftig.

## Definition of Done
`cargo build` und `cargo test` bestehen, und
`cargo clippy -- -D warnings` meldet null Warnungen.

# Ruby on Rails

## Befehle
- Serve:   `bin/rails server`
- Migrate: `bin/rails db:migrate`
- Test:    `bin/rails test` (oder `bundle exec rspec`)
- Format:  `bundle exec rubocop -A`

## Konventionen (folge dem Rails-Weg)
- Respektiere \'Konvention vor Konfiguration\'; erfinde keine eigene Struktur.
- Vermeide fette Controller / Models. Verlagere Logik in Services / Concerns.
- Beschränke Eingaben mit Strong Parameters.
- Vermeide N+1 (nutze `includes`).
- Schemaänderungen bekommen eine neue Migration. Bearbeite keine bereits ausgeführten.

## Absolute Regeln
- Committe niemals, unter keinen Umständen, `.env` oder Zugangsdaten.
- Führe keine destruktiven Befehle gegen die Produktions-DB aus.
- Wenn du das Verhalten änderst, füge Tests hinzu oder aktualisiere sie.

## Definition of Done
Tests und `bundle exec rubocop` bestehen.

# SQL / Datenbank-Migrationen

## Absolute Regeln (Datenschutz kommt zuerst)
- Führe keine destruktiven Operationen gegen Produktionsdaten eigenmächtig aus
  (DROP / TRUNCATE / bedingungsloses DELETE oder UPDATE).
- Migrationen müssen eine Rollback-Prozedur bereitstellen, nicht nur die Vorwärtsrichtung.
- Bearbeite keine bereits ausgeführten Migrationen. Füge stets neue hinzu.
- Lösche oder benenne Spalten in Stufen um ("hinzufügen -> migrieren -> stilllegen"); mache es nicht in einem Zug.

## Query-Konventionen
- Vermeide `SELECT *`; gib die benötigten Spalten an.
- Bestätige, dass WHERE- / JOIN-Bedingungen einen Index nutzen können.
- Teile große Updates in Batches auf, um die Sperrzeit kurz zu halten.
- Bei destruktiven Verifizierungs-Queries bestätige zuerst die betroffene Anzahl mit einem `SELECT`, bevor du sie ausführst.

## Definition of Done
Sowohl Anwenden als auch Rollback gelingen in einer staging-äquivalenten Umgebung, und du
hast bestätigt, dass es keine unbeabsichtigten Änderungen an bestehenden Daten gibt.

# Testgetriebener Ansatz

Wenn du das Verhalten änderst, folge jedes Mal dieser Schleife:
1. Schreibe zuerst einen \'fehlschlagenden Test\', der das gewünschte Verhalten ausdrückt.
2. Führe den Test aus und bestätige, dass er aus dem richtigen Grund fehlschlägt.
3. Schreibe den minimalen Code, der nötig ist, damit der Test besteht.
4. Führe die gesamte Test-Suite aus und bestätige, dass alles grün ist.
5. Refaktoriere, während du es grün hältst.

## Absolute Regeln
- Lösche oder überspringe keine Tests, damit die Suite besteht.
- Schwäche keine Assertions ab, um Dinge grün zu machen.
- Ist ein Test wirklich falsch, erkläre warum, bevor du ihn änderst.
- Neuer Code ohne Tests ist nicht \'fertig\'.

## Definition of Done
Die gesamte Suite besteht, die Abdeckung ist nicht gesunken, und das Zurücksetzen der
Implementierung lässt den neuen Test fehlschlagen (d. h. er ist ein aussagekräftiger Test).

# Debugging-Ansatz

Gehe in dieser Reihenfolge vor. Korrigiere nicht durch Raten:
1. Stelle die Reproduktionsschritte fest (wie der Bug ausgelöst wird).
2. Schreibe das erwartete Verhalten und das tatsächliche Verhalten aus, je ein Satz.
3. Bilde eine Hypothese. Verifiziere sie mit Logs oder einer minimalen Repro, bevor du korrigierst.
4. Sobald du die Ursache identifiziert hast, wende die minimale Korrektur an.
5. Bestätige nach der Korrektur über die Repro-Schritte, dass der Bug weg ist und dass bestehende Tests bestehen.
6. Füge, wenn möglich, einen Regressionstest hinzu, der diesen Bug abfängt.

## Absolute Regeln
- Ändere nicht mehrere Stellen gleichzeitig, solange die Ursache unbekannt ist.
- Bleibe nicht bei \'es funktioniert erst mal\' stehen. Erkläre, warum es behoben wurde.
- Mische kein unzusammenhängendes Refactoring ins Debugging.

# Refactoring-Ansatz

## Grundprinzip
Ändere kein von außen beobachtbares Verhalten. Ändere für keinerlei Eingabe die
Ausgaben oder Seiteneffekte.

## Schritte
1. Bestätige zuerst, dass für den Zielbereich Tests existieren und grün sind.
   Falls nicht, schreibe zuerst Charakterisierungstests, die das aktuelle Verhalten festhalten.
2. Ändere in kleinen, einzelnen Schritten und führe nach jedem Schritt die Tests aus.
3. Halte einen Commit = eine Art von Verbesserung.

## Absolute Regeln
- Mische keine Feature-Ergänzungen oder Bugfixes ins Refactoring (mache sie zu separater Arbeit).
- Wird ein Test rot, halte sofort an. Fahre nicht fort.
- Ändere keine öffentlichen API-Signaturen eigenmächtig (kläre es bei Bedarf vorher).

## Definition of Done
Alle Tests bleiben grün, und der Code ist lesbarer mit weniger Duplikation.

# Wie man ein Design-Dokument schreibt

Vor dem Implementieren schreibe zuerst Folgendes in Prosa aus (schreibe keinen Code):

## 1. Ziel
Das zu lösende Problem und die Bedingungen, unter denen es als erreicht gilt (Erfolgskriterien).

## 2. Aktueller Zustand und Einschränkungen
Das bestehende Setup, die Abhängigkeiten und die zu wahrenden Einschränkungen (Performance, Kompatibilität, Deadline).

## 3. Design-Vorschlag
- Der gewählte Ansatz und die Ansätze, die du erwogen und verworfen hast (und warum).
- Der Datenfluss, die wichtigsten Schnittstellen und die zu ändernden Dateien.

## 4. Risiken und offene Fragen
Was kaputtgehen könnte, die zu bestätigenden Annahmen und die Punkte, die eine Entscheidung erfordern.

## 5. Plan
Zerlege die Implementierung in kleine Schritte, geordnet in verifizierbare Einheiten.

## Regeln
- Beginne nicht mit der Implementierung, bis dieses Design genehmigt ist.
- Liste Unbekanntes unter \'offene Fragen\' auf; fülle sie nicht mit eigenen Annahmen.

# Wie man große Änderungen vornimmt

## Grundprinzip
Vermeide eine einzige riesige Änderung. Teile sie so auf, dass jeder Schritt
unabhängig überprüfbar, testbar und (idealerweise) deploybar ist.

## Schritte
1. Zerlege die zur Endform führenden Änderungen in eine Folge kleiner,
   unabhängiger Schritte und präsentiere sie.
2. Schreibe für jeden Schritt \'was / warum / Auswirkungsbereich\' in 1-2 Zeilen.
3. Führe nach jedem Schritt die gesamte Test-Suite aus und bestätige Grün, bevor du weitergehst.
4. Gehe unter Wahrung der Abwärtskompatibilität vor (hinzufügen -> migrieren -> alten Pfad stilllegen).

## Absolute Regeln
- Schreibe nicht einen breiten Bereich auf einmal um und \'teste alles später zusammen\'.
- Wird ein Schritt zu groß, teile ihn weiter auf.
- Halte jeden Schritt auf einer Granularität, die zurückgesetzt werden kann.

## Definition of Done
Tests sind nach Abschluss aller Schritte grün, und auch jeder Zwischen-Commit ist nicht kaputt.

# Code-Review-Anweisungen

Überprüfe die Änderungen, gruppiere sie nach Schweregrad und berichte in dieser Reihenfolge:
1. CRITICAL - Sicherheitslücken, Datenverlust, Abstürze, defekte Authentifizierung
2. HIGH     - Logikfehler, Race Conditions, fehlende Fehlerbehandlung
3. MEDIUM   - Performance-Probleme, fehlende Tests, verwirrende Namen
4. LOW      - kleinere Stil-Mäkeleien (nur wenn es keine höheren Probleme gibt)

## Wie zu berichten ist
- Für jeden Befund: Datei:Zeile / was falsch ist / warum es wichtig ist / eine konkrete Korrektur.
- Zitiere nur den kleinsten relevanten Ausschnitt. Füge nicht die ganze Datei ein.
- Ist eine Änderung korrekt, sage es ausdrücklich. Erfinde keine Probleme.

## Was nicht zu tun ist
- Vergrabe keine echten Bugs unter einem Haufen LOW-Mäkeleien.
- Schreibe keine ganzen Dateien um. Schlage das kleinste Diff vor.
- Sofern kein echter Schaden besteht, markiere keine Zeilen außerhalb des Diff-Bereichs.

## Ausgabe
Schließe mit einem einzeiligen Urteil ab: APPROVE / REQUEST CHANGES / BLOCK, mit einer Begründung.

# Git- / PR-Regeln

## Commits
- Verwende Conventional Commits: `type(scope): summary`
  type: feat, fix, refactor, test, docs, chore.
- Ein Commit = eine logische Änderung. Halte ihn klein und überprüfbar.
- Schreibe im Body das \'Warum\' statt des \'Was\'.

## Absolute Regeln
- Führe `git push` nicht aus, sofern nicht angewiesen.
- Führe auf geteilten Branches / main kein force-push, rebase oder amend aus.
- Committe keine Geheimnisse, .env, Zugangsdaten oder große Binärdateien.
- Füge Dateien namentlich hinzu. Reiße nicht alles mit `git add -A` mit.

## Pull Requests
- Titel innerhalb von 70 Zeichen. Body ist \'Zusammenfassung\' + \'Testplan (Checkliste)\'.
- Vermerke etwaige Breaking Changes.
- Merge nicht. Erstelle den PR und berichte die URL.

# Security-Review-Anweisungen

Prüfe die Änderungen der Reihe nach gegen die folgenden Aspekte und berichte
jedes gefundene Problem mit einer Schweregrad-Bewertung:
- Fehlende Eingabevalidierung (Injection: SQL / Command / XSS / SSRF)
- Lücken bei Authentifizierung/Autorisierung (fehlende Berechtigungsprüfungen, Privilegieneskalation)
- Geheimnis-Offenlegung (hardcodierte Schlüssel/Tokens, Ausgabe in Logs)
- Unsichere Defaults (übermäßige Offenlegung, laxes CORS, unvalidierte Redirects)
- Bekannte Schwachstellen in Abhängigkeiten, unsichere Krypto- / RNG-Nutzung

## Wie zu berichten ist
- Für jeden Befund: Ort / Angriffsszenario (wie es ausgenutzt werden könnte) / eine konkrete Korrektur.
- Markiere Verdachtsfälle, bei denen du dir nicht sicher bist, als \'bedarf der Bestätigung\' (übergehe sie nicht stillschweigend).
- Gibt es kein Problem, gib \'keine Probleme\' zusammen mit den geprüften Aspekten an.

## Was nicht zu tun ist
- Generiere keinen tatsächlichen Angriffscode oder Ausnutzungsschritte (zeige nur Korrekturen).

# Docker- / Infrastruktur-Arbeitsregeln

## Absolute Regeln (Zerstörungsverhütung kommt zuerst)
- Führe keine destruktiven Befehle gegen Produktions- oder geteilte Umgebungen eigenmächtig aus
  (`docker system prune`, Volumes löschen, `down -v` usw.).
- Hefte Images an feste Tags. Verlasse dich nicht auf `latest`.
- Übergib Geheimnisse über Umgebungsvariablen / Secret-Management.
  Backe sie nicht ins Dockerfile oder Image ein.
- Halte offene Ports und Privilegien (privileged usw.) auf das nötige Minimum.

## Konventionen
- Halte Dockerfiles klein mit Multi-Stage-Builds, achte auf Layer-Caching.
- Laufe als Nicht-Root-Benutzer.
- Baue und starte nach Änderungen lokal zur Verifizierung, bevor du berichtest.

## Definition of Done
`docker build` besteht, der Container startet, und der Health Check / grundlegende
Betrieb kann bestätigt werden.

# Abhängigkeitsregeln

## Absolute Regeln
- Bevor du eine Abhängigkeit hinzufügst, prüfe, ob die Standardbibliothek oder eine
  bestehende Abhängigkeit genügt.
- Wenn du eine neue Abhängigkeit hinzufügst, füge eine einzeilige Notiz zu ihrem Zweck,
  zu Alternativen und zum Wartungsstand hinzu.
- Erhöhe keine Major-Versionen eigenmächtig (nur wenn angewiesen).
- Generiere Lock-Dateien (package-lock.json usw.) nicht eigenmächtig neu.
- Vermeide Pakete dubioser Herkunft oder mit extrem wenigen Sternen oder schlechter Wartung.

## Schritte
1. Nenne den Grund für die Ergänzung oder das Update.
2. Bestätige nach dem Hinzufügen, dass Build und Tests bestehen.
3. Bestätige, dass die Lizenz nicht mit deinem Anwendungsfall kollidiert.

## Definition of Done
Build und Tests bestehen nach der Abhängigkeitsänderung, und du kannst das Diff in der Lock-Datei erklären.