umrechner/AGENTS.md

Zwingende Regeln für jede Code-Interaktion

• Respektiere und fördere die Verwendung von Alpine.js und Tailwind CSS
• Vor Änderungen analysiere den umliegenden Code um Kontext und Muster zu verstehen

Technologie-Stack

Komponente	Vorschrift
Static Site Generator	Hugo (Extended) – ausschließlich im Docker-Build-Image verfügbar; nicht auf dem Host installiert. Alle Hugo-Projektdateien müssen im Ordner hugo/ abgelegt werden (z.B. hugo/content/, hugo/layouts/, hugo/data/).
Interaktivität	Alpine.js 3.x + Alpine AJAX (0.x).
Styling	Tailwind CSS für alle UI-Klassen. Direktes CSS ausschließlich in hugo/input.css.
Fließkomma-Arithmetik	decimal.js-light ist die verbindliche Bibliothek. Keine native JavaScript-Float-Arithmetik für Berechnungen.

Ordner- & Datei-Struktur

• Hugo-Konventionen sind zwingend. Erlaubt unter hugo/: hugo/content/, hugo/data/, hugo/layouts/, hugo/assets/, hugo/static/.
• Verboten: Dateien außerhalb dieser Konventionen zu erstellen oder Hugo-Dateien außerhalb von hugo/ abzulegen.
• Einheiten-Daten gehören nach hugo/data/{slug}.json.
• Direktes CSS nur in input.css. Keine zusätzlichen .css-Dateien für Komponenten-Styles.

Code-Formatierung

• Einrücken mit einem Tab
• Ausnahme: YAML. Dort wird mit 2 Leerzeichen eingerückt.
• Öffnende geschweifte Klammern am Ende der Block-Definitions-Zeile z.B. bei if oder while und Funktionsdefinitionen
• Schließende geschweifte Klammern in einer eigenen Zeile am Ende des Blocks
• Variablennamen und Funktionsnamen in camelCase
• Maximale Zeilenlänge: 80 Zeichen; danach manueller oder automatischer Umbruch.
• Einfache Anführungszeichen ' in JavaScript und Go; doppelte Anführungszeichen " in HTML-Attributen, JSON und YAML.
• Keine trailing spaces am Zeilenende.
• Jede Datei endet mit genau einer Leerzeile (POSIX-Konvention), aber keinem weiteren Whitespace in dieser Leerzeile.
• Keine mehrfachen Leerzeilen hintereinander (maximal eine Leerzeile zur Trennung von Blöcken).
• Kein Leerzeichen vor Komma, Semikolon oder Doppelpunkt; immer ein Leerzeichen danach.
• JavaScript: Keine var-Deklarationen; const als Standard, let nur bei tatsächlicher Re-Assignation.
• JavaScript: Asynchrone Operationen mit async/await; keine verschachtelten .then()-Ketten (Callback Hell).
• JavaScript: Keine verschachtelten ternären Operatoren.
• JavaScript: Arrow-Funktionen mit implizitem Return nur bei Einzeilern; mehrzeilige Arrow-Funktionen benötigen geschweifte Klammern und explizites return.
• Hugo Templates / Go: Keine verschachtelten Template-Logiken über 3 Ebenen hinaus (z. B. {{ if }} in {{ range }} in {{ if }}); komplexere Logik muss in ein Partial ausgelagert werden.

Verbotene Techniken & Anti-Patterns

• Keine Änderungen im app Ordner Der Ordner ist die Vorlage für die Migration und ist für Änderungen tabu.
• Keine leeren catch-Blöcke. Ein leerer catch muss mit einem erklärenden Kommentar versehen sein.
• Keine überlangen Funktionen. > 40 Zeilen signalisieren, dass eine Funktion aufgeteilt werden sollte.
• Keine tiefen Verschachtelungen. > 3 Einrückungsebenen (z. B. if-in-if-in-if) sind zu refactoren.
• Keine magischen Zahlen oder String-Literale. Werte mit semantischer Bedeutung müssen als benannte Konstanten definiert werden.
• Keine ungenutzten Imports, Variablen oder Funktionen. Sie müssen entfernt werden.
• Keine console.log, alert oder debugger im Committeten Code.
• Keine doppelten Negationen. Verwende explizite Boolean-Casts statt !!.
• Keine globalen Variablen. Daten müssen im jeweiligen Scope oder per explizitem State-Management (z. B. Alpine x-data) gehalten werden.

Automatisierte Tests

• Vor Abschluss eines Features oder einer Änderung muss der Docker-Build-Test erfolgreich durchlaufen: ./tests/test-docker-build.sh
• Der Test prüft drei Ebenen: erfolgreicher docker build, existenz wichtiger Artefakte (index.html, css/main.min.css, robots.txt) und ein HTTP-Smoke-Test gegen den laufenden Container.