Merge branch 'main' into copilot/add-kiss-principle

Author: rdmueller

docs/anchors/grasp.adoc

@@ -0,0 +1,54 @@
+= GRASP
+:categories: design-principles
+:roles: software-developer, software-architect, educator, consultant
+:related: solid-principles, gof-design-patterns, clean-architecture, domain-driven-design
+:proponents: Craig Larman
+:tags: grasp, oop, responsibility-assignment, object-oriented-design, patterns
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: General Responsibility Assignment Software Patterns (or Principles)
+
+Also known as:: GRASP Patterns, Responsibility-Driven Design Guidelines
+
+[discrete]
+== *Core Concepts*:
+
+Information Expert:: Assign responsibility to the class that has the information needed to fulfill it
+
+Creator:: Assign responsibility for creating an object to the class that aggregates, contains, or closely uses it
+
+Controller:: Assign responsibility for handling system events to a non-UI class representing the overall system or a use case
+
+Low Coupling:: Assign responsibilities to minimize dependencies between classes, increasing reuse and reducing change impact
+
+High Cohesion:: Assign responsibilities so that classes remain focused, understandable, and manageable
+
+Polymorphism:: Use polymorphic operations to handle variations in type-based behavior instead of conditionals
+
+Pure Fabrication:: Assign a set of responsibilities to an artificial class not representing a domain concept, to achieve low coupling and high cohesion
+
+Indirection:: Assign responsibility to an intermediate object to mediate between other components, reducing direct coupling
+
+Protected Variations:: Identify points of predicted variation and assign responsibilities to create a stable interface around them
+
+
+Key Proponents:: Craig Larman ("Applying UML and Patterns", 3rd ed., 2004)
+
+[discrete]
+== *When to Use*:
+
+* Designing object-oriented systems and deciding where to assign responsibilities
+* Improving cohesion and reducing coupling in existing codebases
+* Guiding refactoring decisions by evaluating current responsibility assignments
+* Teaching foundational object-oriented design principles
+
+[discrete]
+== *Related Anchors*:
+
+* <<solid-principles,SOLID Principles>> - Complementary OO design principles for maintainable systems
+* <<gof-design-patterns,GoF Design Patterns>> - Patterns that often embody GRASP principles
+* <<clean-architecture,Clean Architecture>> - Architectural style that leverages GRASP-based thinking
+* <<domain-driven-design,Domain-Driven Design>> - Uses responsibility assignment in the domain model
+====

docs/anchors/grasp.de.adoc

@@ -0,0 +1,54 @@
+= GRASP
+:categories: design-principles
+:roles: software-developer, software-architect, educator, consultant
+:related: solid-principles, gof-design-patterns, clean-architecture, domain-driven-design
+:proponents: Craig Larman
+:tags: grasp, oop, responsibility-assignment, object-oriented-design, patterns
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: General Responsibility Assignment Software Patterns (oder Principles)
+
+Auch bekannt als:: GRASP-Muster, Richtlinien für verantwortungsgetriebenes Design
+
+[discrete]
+== *Kernkonzepte*:
+
+Information Expert:: Weise die Verantwortung der Klasse zu, die die benötigten Informationen besitzt
+
+Creator:: Weise die Verantwortung für die Erzeugung eines Objekts der Klasse zu, die es aggregiert, enthält oder eng damit zusammenarbeitet
+
+Controller:: Weise die Verantwortung für die Behandlung von Systemereignissen einer Nicht-UI-Klasse zu, die das Gesamtsystem oder einen Anwendungsfall repräsentiert
+
+Low Coupling (Geringe Kopplung):: Weise Verantwortlichkeiten so zu, dass Abhängigkeiten zwischen Klassen minimiert werden, um Wiederverwendung zu steigern und Änderungsauswirkungen zu reduzieren
+
+High Cohesion (Hohe Kohäsion):: Weise Verantwortlichkeiten so zu, dass Klassen fokussiert, verständlich und überschaubar bleiben
+
+Polymorphismus:: Nutze polymorphe Operationen, um typbasierte Verhaltensvarianten zu behandeln, anstatt Bedingungsanweisungen zu verwenden
+
+Pure Fabrication:: Weise einer künstlichen Klasse, die kein Domänenkonzept repräsentiert, Verantwortlichkeiten zu, um geringe Kopplung und hohe Kohäsion zu erreichen
+
+Indirektion:: Weise einem Zwischenobjekt die Verantwortung zu, zwischen anderen Komponenten zu vermitteln, um direkte Kopplung zu reduzieren
+
+Protected Variations (Geschützte Variationen):: Identifiziere vorhergesagte Variationspunkte und weise Verantwortlichkeiten zu, um eine stabile Schnittstelle darum herum zu schaffen
+
+
+Schlüsselvertreter:: Craig Larman ("Applying UML and Patterns", 3. Aufl., 2004)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Entwurf objektorientierter Systeme und Entscheidung über die Zuweisung von Verantwortlichkeiten
+* Verbesserung von Kohäsion und Reduzierung von Kopplung in bestehenden Codebasen
+* Führung von Refactoring-Entscheidungen durch Bewertung aktueller Verantwortlichkeitszuweisungen
+* Vermittlung grundlegender objektorientierter Entwurfsprinzipien
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<solid-principles,SOLID Principles>> - Ergänzende OO-Entwurfsprinzipien für wartbare Systeme
+* <<gof-design-patterns,GoF Design Patterns>> - Muster, die häufig GRASP-Prinzipien verkörpern
+* <<clean-architecture,Clean Architecture>> - Architekturstil, der GRASP-basiertes Denken nutzt
+* <<domain-driven-design,Domain-Driven Design>> - Nutzt Verantwortlichkeitszuweisung im Domänenmodell
+====

docs/anchors/pert.adoc

@@ -0,0 +1,51 @@
+= PERT
+:categories: strategic-planning
+:roles: product-owner, business-analyst, team-lead, consultant, educator
+:related: moscow, user-story-mapping, impact-mapping
+:proponents: D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar
+:tags: pert, project-planning, estimation, schedule, uncertainty, three-point-estimation, critical-path, network-diagram
+:tier: 2
+
+[%collapsible]
+====
+Full Name:: Program Evaluation and Review Technique
+
+Also known as:: Three-Point Estimation, PERT Network Analysis
+
+[discrete]
+== *Core Concepts*:
+
+Three-Time Estimation:: Each activity requires three duration estimates: Optimistic (O) — best case if everything goes well; Most Likely (M) — realistic expected duration; Pessimistic (P) — worst case if problems arise
+
+PERT Formula:: Weighted average: *E = (O + 4M + P) / 6* — weights the most likely estimate four times more than the extreme estimates
+
+Standard Deviation:: *σ = (P − O) / 6* — quantifies schedule uncertainty per activity; used to calculate confidence intervals for the project completion date
+
+Network Diagram:: Activities are represented as nodes or arrows in a directed acyclic graph; dependencies between activities are modelled explicitly
+
+Critical Path:: The longest path through the network determines the minimum project duration; any delay on the critical path delays the whole project
+
+Float / Slack:: Time an activity can be delayed without affecting the project end date; activities on the critical path have zero float
+
+Probabilistic Scheduling:: Unlike CPM (which uses single-point estimates), PERT treats duration as a random variable, enabling statistical confidence ranges for milestones
+
+Origin:: Developed in 1958 by D.G. Malcolm, J.H. Roseboom, C.E. Clark, and W. Fazar at Booz Allen Hamilton for the US Navy's Polaris submarine missile programme
+
+Key Proponents:: D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar ("Application of a Technique for Research and Development Program Evaluation", 1959)
+
+[discrete]
+== *When to Use*:
+
+* Estimating effort and schedule for projects with significant uncertainty
+* Planning R&D, software development, or any novel work where duration is hard to predict
+* Communicating schedule risk and confidence levels to stakeholders
+* Identifying the critical path to focus risk management and resource allocation
+* Complementing Story Points or T-shirt sizing with a probabilistic time dimension
+
+[discrete]
+== *Related Anchors*:
+
+* <<moscow,MoSCoW>>
+* <<user-story-mapping,User Story Mapping>>
+* <<impact-mapping,Impact Mapping>>
+====

docs/anchors/pert.de.adoc

@@ -0,0 +1,49 @@
+= PERT
+:categories: strategic-planning
+:roles: product-owner, business-analyst, team-lead, consultant, educator
+:related: moscow, user-story-mapping, impact-mapping
+:proponents: D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar
+:tags: pert, project-planning, estimation, schedule, uncertainty, three-point-estimation, critical-path, network-diagram
+
+[%collapsible]
+====
+Vollständiger Name:: Program Evaluation and Review Technique (Programmbewertungs- und Überprüfungstechnik)
+
+Auch bekannt als:: Drei-Punkte-Schätzung, PERT-Netzplananalyse
+
+[discrete]
+== *Kernkonzepte*:
+
+Drei-Punkte-Schätzung:: Jede Aktivität benötigt drei Dauerschätzungen: Optimistisch (O) — bester Fall, wenn alles reibungslos läuft; Wahrscheinlichst (M) — realistisch erwartete Dauer; Pessimistisch (P) — schlimmster Fall bei auftretenden Problemen
+
+PERT-Formel:: Gewichteter Mittelwert: *E = (O + 4M + P) / 6* — die wahrscheinlichste Schätzung wird viermal stärker gewichtet als die Extremwerte
+
+Standardabweichung:: *σ = (P − O) / 6* — quantifiziert die Terminunsicherheit je Aktivität; wird zur Berechnung von Konfidenzintervallen für den Projektabschlusstermin verwendet
+
+Netzplan:: Aktivitäten werden als Knoten oder Pfeile in einem gerichteten azyklischen Graphen dargestellt; Abhängigkeiten zwischen Aktivitäten werden explizit modelliert
+
+Kritischer Pfad:: Der längste Pfad durch das Netzwerk bestimmt die minimale Projektdauer; jede Verzögerung auf dem kritischen Pfad verzögert das gesamte Projekt
+
+Puffer / Schlupf:: Zeit, um die eine Aktivität verzögert werden kann, ohne den Projektendtermin zu beeinflussen; Aktivitäten auf dem kritischen Pfad haben keinen Puffer
+
+Probabilistische Terminplanung:: Im Gegensatz zur CPM (die Einzelpunktschätzungen verwendet) behandelt PERT Dauern als Zufallsvariablen und ermöglicht statistische Konfidenzintervalle für Meilensteine
+
+Ursprung:: 1958 von D.G. Malcolm, J.H. Roseboom, C.E. Clark und W. Fazar bei Booz Allen Hamilton für das Polaris-U-Boot-Raketenprogramm der US Navy entwickelt
+
+Schlüsselvertreter:: D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar („Application of a Technique for Research and Development Program Evaluation", 1959)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Aufwands- und Terminschätzung für Projekte mit erheblicher Unsicherheit
+* Planung von F&E-, Softwareentwicklungs- oder anderen neuartigen Vorhaben, bei denen Dauern schwer vorherzusagen sind
+* Kommunikation von Terminrisiken und Konfidenzwerten gegenüber Stakeholdern
+* Identifikation des kritischen Pfads zur gezielten Risikobewältigung und Ressourcenzuteilung
+* Ergänzung von Story Points oder T-Shirt-Größen um eine probabilistische Zeitdimension
+
+*Verwandte Anker*:
+
+* <<moscow,MoSCoW>>
+* <<user-story-mapping,User Story Mapping>>
+* <<impact-mapping,Impact Mapping>>
+====

docs/anchors/vertical-slice-architecture.adoc

@@ -0,0 +1,49 @@
+= Vertical Slice Architecture (VSA)
+:categories: software-architecture
+:roles: software-architect, software-developer
+:related: clean-architecture, hexagonal-architecture, cqrs
+:proponents: Jimmy Bogard
+:tags: feature slices, vertical slices, VSA, feature cohesion, CQRS
+:tier: 3
+
+[%collapsible]
+====
+Also known as:: VSA, Feature Slices
+
+[discrete]
+== *Core Concepts*:
+
+Vertical slices:: Each feature is organized as an end-to-end slice spanning all layers (request, validation, domain logic, persistence, API)
+
+Feature cohesion:: Code for a feature lives together regardless of technical layer
+
+No horizontal layers:: Avoids traditional layered architecture (controllers, services, repositories) as primary organizing principle
+
+CQRS alignment:: Naturally pairs with Command/Query separation per slice
+
+Thin shared layer:: Minimal shared infrastructure; each slice owns its behavior
+
+Screaming intent:: Folder/namespace structure reflects features, not technical concerns
+
+Independent evolution:: Slices can evolve independently with minimal cross-cutting changes
+
+Reduced coupling:: Changes to one feature rarely affect other features
+
+
+Key Proponents:: Jimmy Bogard
+
+[discrete]
+== *When to Use*:
+
+* Applications with many distinct business features
+* When feature teams own end-to-end delivery
+* To reduce merge conflicts in large teams
+* When traditional layered architecture creates too much coupling across features
+
+[discrete]
+== *Related Anchors*:
+
+* <<clean-architecture,Clean Architecture>>
+* <<hexagonal-architecture,Hexagonal Architecture (Ports & Adapters)>>
+* <<cqrs,CQRS>>
+====

docs/anchors/vertical-slice-architecture.de.adoc

@@ -0,0 +1,48 @@
+= Vertical Slice Architecture (VSA)
+:categories: software-architecture
+:roles: software-architect, software-developer
+:related: clean-architecture, hexagonal-architecture, cqrs
+:proponents: Jimmy Bogard
+:tags: feature slices, vertical slices, VSA, feature cohesion, CQRS
+
+[%collapsible]
+====
+Auch bekannt als:: VSA, Feature Slices
+
+[discrete]
+== *Kernkonzepte*:
+
+Vertikale Schnitte:: Jedes Feature ist als End-to-End-Schnitt organisiert, der alle Schichten umfasst (Request, Validierung, Domänenlogik, Persistenz, API)
+
+Feature-Kohäsion:: Code für ein Feature liegt unabhängig von der technischen Schicht zusammen
+
+Keine horizontalen Schichten:: Vermeidet traditionelle geschichtete Architektur (Controller, Services, Repositories) als primäres Organisationsprinzip
+
+CQRS-Ausrichtung:: Passt natürlich zur Command/Query-Trennung pro Schnitt
+
+Dünne gemeinsame Schicht:: Minimale gemeinsame Infrastruktur; jeder Schnitt besitzt sein eigenes Verhalten
+
+Sprechende Absicht:: Ordner-/Namespace-Struktur spiegelt Features wider, keine technischen Belange
+
+Unabhängige Weiterentwicklung:: Jeder Schnitt kann unabhängig mit minimalen übergreifenden Änderungen weiterentwickelt werden
+
+Reduzierte Kopplung:: Änderungen an einem Feature beeinflussen selten andere Features
+
+
+Schlüsselvertreter:: Jimmy Bogard
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Anwendungen mit vielen verschiedenen Geschäftsfeatures
+* Wenn Feature-Teams die End-to-End-Lieferung verantworten
+* Um Merge-Konflikte in großen Teams zu reduzieren
+* Wenn traditionelle Schichtenarchitektur zu viel Kopplung zwischen Features erzeugt
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<clean-architecture,Clean Architecture>>
+* <<hexagonal-architecture,Hexagonal Architecture (Ports & Adapters)>>
+* <<cqrs,CQRS>>
+====

evaluations/generate-report.py

@@ -35,6 +35,8 @@
 
 def get_model_display(backend, config):
     """Get exact model display name from config."""
+    if backend == "claude" and config.get("claude_model"):
+        return config["claude_model"]
     if backend == "openai" and config.get("openai_model"):
         return config["openai_model"]
     if backend == "mistral" and config.get("mistral_model"):