# 10 Softwareentwicklungsregeln

**1. Dekomposition (Zerlegung):** *Baue einen Block nach dem anderen.*
Zerlege die Arbeit in kleine, isolierte Teile. Entwickle und teste Feature für Feature, Seite für Seite. Wenn du einer KI die ganze App auf einmal gibst, macht sie zu viele Annahmen. Eine modulare Struktur verhindert, dass Fehler unbemerkt das gesamte System destabilisieren.

**2. Don't Repeat Yourself (DRY):** *Schreibe es einmal, nutze es überall wieder.*
Dupliziere keine Logik über mehrere Dateien hinweg, um schneller zu sein. Zentralisiere geteilte Logik, Typen und Komponenten. Wenn ein Muster mehr als zweimal auftritt, erstelle ein wiederverwendbares Utility oder eine Komponente.

**3. Aussagekräftige Benennung:** *Benenne Dinge so, dass jeder sie verstehen kann.*
Verwende klare, auf die Absicht bezogene Namen für Variablen, Funktionen und Komponenten (z. B. `isUserAuthenticated` anstelle von nur `auth`). Dies macht den Code sowohl für Menschen als auch für die KI verständlicher und verhindert, dass die KI raten muss.

**4. Klare Struktur und Organisation:** *Gabeln zu den Gabeln, Teller zu den Tellern.*
Behalte eine konsistente Datei- und Ordnerstruktur bei. Gruppiere verwandten Code nach Feature oder Domäne. Eine saubere Struktur hilft der KI zu verstehen, wo neue Features platziert werden müssen und wo Fehler zu suchen sind.

**5. Strikte Typensicherheit (TypeScript):** *Rechtschreibprüfung für deine Daten.*
Verwende immer strenges Typing und vermeide den Typ `any`. Definiere Datenstrukturen explizit, um Laufzeitfehler zu vermeiden. Dies prüft, ob die durch die App fließenden Daten die richtige Form und das richtige Format haben.

**6. Trennung der Zuständigkeiten (Separation of Concerns):** *Jeder Code-Teil sollte genau eine Aufgabe haben.*
Halte die Trennung zwischen UI, Geschäftslogik und Datenschicht strikt ein. Das Seitenlayout sollte keine komplexen Berechnungen durchführen und ein Button sollte nicht direkt mit der Datenbank kommunizieren.

**7. Fehlerbehandlung (Der Unhappy Path):** *Plane für den Fall, dass Dinge schiefgehen.*
Gehe nicht nur vom Idealfall aus. Implementiere benutzerfreundliche Fehlermeldungen, Ladezustände (Skeleton Screens, Spinner) für alle asynchronen Aktionen und Fallbacks, wenn Daten fehlen oder Netzwerkausfälle auftreten.

**8. Sicherheit (Vertraue niemals dem Client):** *Gib dem Kunden nicht die Schlüssel zum Hinterzimmer.*
Sensible Logik, Datenvalidierung und API-Schlüssel müssen zwingend auf dem Server/Backend (z. B. Edge Functions) verbleiben. Die Frontend-UI darf niemals direkten Zugriff auf sensible Systeme haben.

**9. Barrierefreiheit (Accessibility) und Mobile-First:** *Funktioniert für jeden, auf jedem Gerät.*
Alle Benutzeroberflächen müssen vollständig responsiv und zuerst für mobile Geräte optimiert sein. Baue kleine, isolierte UI-Komponenten mit semantischem HTML, ARIA-Labels und Tastaturunterstützung auf.

**10. Umfassendes Logging:** *Hinterlasse Brotkrumen für die Fehlersuche.*
Implementiere standardmäßig detailliertes Logging, um Observability zu gewährleisten. Protokolliere API-Aufrufe (Requests/Responses), Datenbankoperationen und Authentifizierungsereignisse. Diese Logs sind unerlässlich für das schnelle Finden und Beheben von Fehlern.

## Workflow Constraint
1. Baue zuerst die Frontend-Benutzeroberfläche. Implementiere keine Backend-Integrationen oder Datenbankschemata, bis der Frontend-Nutzerfluss ausdrücklich freigegeben wurde.
2. Wenn du das Frontend implementierst, stelle sicher, dass dies Seite für Seite geschieht, und frage mich ausdrücklich nach der Freigabe für jede Seite.
3. Instruiere mich nach jeder Modul-Implementierung, wie ich die neu implementierte Funktion im Preview-Modus testen kann. Fahre nicht mit der Implementierung des nächsten Moduls fort, bis ich bestätige, dass ich bereit bin.