{
"event": "PreToolUse",
"tool_name": "Read",
"tool_input": {
"file_path": "\/var\/www\/dev.campus.systemische-tools.de\/docs\/codequality\/richtlinien.md"
}
}
{
"tool_response": {
"type": "text",
"file": {
"filePath": "\/var\/www\/dev.campus.systemische-tools.de\/docs\/codequality\/richtlinien.md",
"content": "# Vollständige Prinzipiensammlung\n## Integriert: klassische Softwareprinzipien plus Senior Engineering Praxis\n\nDieses Dokument enthält **alle relevanten Prinzipien vollständig**, ohne Auslassung.\nEs vereint klassische Architekturprinzipien mit den impliziten Steuerprinzipien,\ndie in sehr reifen professionellen Open Source Projekten faktisch angewendet werden.\n\n---\n\n## 1. Fundamentale Code und Architekturprinzipien\n\n### DRY\nDon’t Repeat Yourself.\nWissen, Logik und Regeln existieren nur an einer Stelle.\nBewusste Redundanz ist nur erlaubt, wenn sie explizit benannt und begrenzt ist.\n\n### CRUD\nCreate, Read, Update, Delete als Grundmodell für Persistenz.\nGeschäftslogik ist kein CRUD.\nValidatoren, Evaluatoren und Entscheidungslogik sind Domain Services, keine Repositories.\n\n### KISS\nKeep It Simple, Stupid.\nDie einfachste Lösung mit klarer Semantik ist vorzuziehen.\nKomplexität wird nicht vorweggenommen.\n\n### YAGNI\nYou Aren’t Gonna Need It.\nKeine Implementierung ohne aktuellen Bedarf.\nZukünftige Möglichkeiten rechtfertigen keinen Code.\n\n### SRP\nSingle Responsibility Principle.\nEine Einheit hat genau einen Grund zur Änderung.\nÜbergangslösungen sind nur mit klaren Eskalationsregeln erlaubt.\n\n### SOLID\nSingle Responsibility.\nOpen Closed.\nLiskov Substitution.\nInterface Segregation.\nDependency Inversion.\nAlle fünf Prinzipien dienen der kontrollierten Evolution von Code.\n\n### Clean Architecture\nTrennung von Domain, Infrastructure und Anwendung.\nDomain kennt keine Infrastruktur.\nAbhängigkeiten zeigen immer nach innen.\n\n---\n\n## 2. Change und Entwicklungsprinzipien\n\n### Small Changes\nÄnderungen sind klein, überschaubar und schnell reviewbar.\nJeder Change ist isoliert verständlich.\n\n### Single Purpose Change\nEin Change löst genau ein Problem.\nRefactoring, Bugfix und Feature werden nicht gemischt.\n\n### Incremental Refactoring\nGroße Umbauten erfolgen in lauffähigen, testbaren Schritten.\nKein Big Bang Refactoring.\n\n---\n\n## 3. API und Schnittstellenprinzipien\n\n### Public API Definition\nEs ist explizit definiert, was öffentlich ist.\nNur öffentliche Schnittstellen haben Stabilitätsgarantie.\n\n### Compatibility First\nAbwärtskompatibilität hat Vorrang.\nBreaking Changes sind selten und begründungspflichtig.\n\n### Semantic Versioning Disziplin\nVersionen transportieren Bedeutung.\nBreaking Change, Feature und Fix sind klar unterscheidbar.\n\n---\n\n## 4. Stabilitäts und Betriebsprinzipien\n\n### Stability as a Deliverable\nStabilität ist ein Liefergegenstand.\nNicht nur Features zählen als Fortschritt.\n\n### Fail Fast\nUngültige Zustände werden sofort erkannt.\nFehler werden früh sichtbar gemacht.\n\n### Fail Safe\nFehler eskalieren nicht.\nEin Defekt darf keinen Systemkollaps auslösen.\n\n### Observability\nSystemzustände sind nachvollziehbar.\nLogs und Fehlermeldungen ermöglichen Rekonstruktion.\n\n---\n\n## 5. Architektur und Abhängigkeitsprinzipien\n\n### Explicit is Better than Implicit\nEntscheidungen sind sichtbar im Code.\nKeine versteckten Defaults.\nKeine impliziten Seiteneffekte.\n\n### Least Surprise Principle\nCode verhält sich so, wie Name und Struktur erwarten lassen.\nKeine Überraschungen.\n\n### Separation of Concerns\nUnterschiedliche Verantwortlichkeiten sind getrennt.\nBreiter als SRP, strukturell wirksam.\n\n### Stable Dependencies Principle\nAbhängigkeiten zeigen von instabil nach stabil.\nShared Code ist stabiler als Anwendungscode.\n\n### Stable Abstractions Principle\nStabile Module sind abstrakt.\nInstabile Module sind konkret.\nKeine Abstraktion ohne Stabilitätsbedarf.\n\n---\n\n## 6. Komplexitätskontrolle\n\n### Cohesion over Coupling\nHohe innere Geschlossenheit.\nGeringe Kopplung nach außen.\n\n### Cyclomatic Complexity Control\nEntscheidungslogik bleibt begrenzt.\nZu viele Verzweigungen erzwingen Zerlegung.\n\n### Law of Demeter\nModule sprechen nur mit direkten Nachbarn.\nKeine tiefen Objektketten.\n\n---\n\n## 7. Testbarkeit und Determinismus\n\n### Deterministic Behavior\nGleicher Input erzeugt gleichen Output.\nKein versteckter globaler Zustand.\n\n### Test Isolation\nTests beeinflussen sich nicht gegenseitig.\nGlobaler Zustand ist kontrolliert oder rücksetzbar.\n\n### Observable Failure\nFehler sind sichtbar, erklärbar und reproduzierbar.\nKein stilles Scheitern.\n\n---\n\n## 8. Entscheidungs und Governance Prinzipien\n\n### Make Trade offs Explicit\nJede bewusste Abweichung ist dokumentiert.\nEinfachheit gegen Performance.\nRedundanz gegen Komplexität.\n\n### One Way to Do It\nEs gibt genau einen erlaubten Weg.\nKeine Parallelpatterns.\nKeine Alternativpfade.\n\n### No Hidden State\nKein impliziter globaler Zustand.\nLebenszyklen sind explizit kontrolliert.\n\n---\n\n## 9. Prinzipien, die bewusst vermieden werden\n\n### Premature Optimization\nOptimierung nur bei messbarem Bedarf.\n\n### Framework First Design\nProblem bestimmt Architektur, nicht Tooling.\n\n### Everything Must Be Abstracted\nKonkreter Code ist erlaubt.\nAbstraktion ist Mittel, kein Selbstzweck.\n\n### Vollständige hexagonale Architektur\nFür kleine bis mittlere Systeme unnötig komplex.\n\n---\n\n## 10. Konsolidierte Prioritätenliste für Dein Projekt\n\n1. Explicit is Better than Implicit \n2. Deterministic Behavior \n3. DRY \n4. Separation of Concerns \n5. Clean Architecture \n6. Stable Dependencies \n7. Fail Fast \n8. Fail Safe \n9. KISS \n10. Make Trade offs Explicit \n11. SRP \n12. YAGNI \n13. Cohesion over Coupling \n14. Test Isolation \n15. Least Surprise Principle \n\n---\n\n## 11. Schlussbemerkung\n\nProfessionelle Senior Projekte zeichnen sich nicht durch viele Prinzipien aus,\nsondern durch **klare Grenzen, explizite Entscheidungen und konsequente Durchsetzung**.\n\nDiese Sammlung bildet ein vollständiges, belastbares Referenzsystem\nfür Architektur, Refactoring und langfristige Wartbarkeit.\n",
"numLines": 224,
"startLine": 1,
"totalLines": 224
}
}
}