Merge branch 'LLM-Coding:main' into main

Author: JThoennes

docs/all-anchors.adoc

@@ -11,25 +11,83 @@ include::about.adoc[leveloffset=+1]
 
 include::anchors/bluf.adoc[leveloffset=+2]
 
-include::anchors/chatham-house-rule.adoc[leveloffset=+2]
+include::anchors/gutes-deutsch-wolf-schneider.adoc[leveloffset=+2]
 
 include::anchors/mece.adoc[leveloffset=+2]
 
+include::anchors/myers-briggs-type-indicator.adoc[leveloffset=+2]
+
+include::anchors/plain-english-strunk-white.adoc[leveloffset=+2]
+
+include::anchors/problem-space-nvc.adoc[leveloffset=+2]
+
 include::anchors/pyramid-principle.adoc[leveloffset=+2]
 
 <<<
 
 == Design Principles & Patterns
 
-include::anchors/dry-principle.adoc[leveloffset=+2]
-
 include::anchors/fowler-patterns.adoc[leveloffset=+2]
 
+include::anchors/gof-abstract-factory-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-adapter-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-bridge-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-builder-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-chain-of-responsibility-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-command-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-composite-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-decorator-pattern.adoc[leveloffset=+2]
+
 include::anchors/gof-design-patterns.adoc[leveloffset=+2]
 
+include::anchors/gof-facade-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-factory-method-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-flyweight-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-interpreter-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-iterator-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-mediator-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-memento-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-observer-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-prototype-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-proxy-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-singleton-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-state-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-strategy-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-template-method-pattern.adoc[leveloffset=+2]
+
+include::anchors/gof-visitor-pattern.adoc[leveloffset=+2]
+
+include::anchors/solid-dip.adoc[leveloffset=+2]
+
+include::anchors/solid-isp.adoc[leveloffset=+2]
+
+include::anchors/solid-lsp.adoc[leveloffset=+2]
+
+include::anchors/solid-ocp.adoc[leveloffset=+2]
+
 include::anchors/solid-principles.adoc[leveloffset=+2]
 
-include::anchors/spot-principle.adoc[leveloffset=+2]
+include::anchors/solid-srp.adoc[leveloffset=+2]
 
 include::anchors/ssot-principle.adoc[leveloffset=+2]
 
@@ -43,8 +101,16 @@ include::anchors/bem-methodology.adoc[leveloffset=+2]
 
 include::anchors/conventional-commits.adoc[leveloffset=+2]
 
+include::anchors/definition-of-done.adoc[leveloffset=+2]
+
+include::anchors/github-flow.adoc[leveloffset=+2]
+
 include::anchors/mental-model-according-to-naur.adoc[leveloffset=+2]
 
+include::anchors/mikado-method.adoc[leveloffset=+2]
+
+include::anchors/regulated-environment.adoc[leveloffset=+2]
+
 include::anchors/semantic-versioning.adoc[leveloffset=+2]
 
 include::anchors/sota.adoc[leveloffset=+2]
@@ -87,16 +153,18 @@ include::anchors/five-whys.adoc[leveloffset=+2]
 
 include::anchors/morphological-box.adoc[leveloffset=+2]
 
-include::anchors/rubber-duck-debugging.adoc[leveloffset=+2]
-
 <<<
 
 == Requirements Engineering
 
 include::anchors/ears-requirements.adoc[leveloffset=+2]
 
+include::anchors/invest.adoc[leveloffset=+2]
+
 include::anchors/moscow.adoc[leveloffset=+2]
 
+include::anchors/prd.adoc[leveloffset=+2]
+
 include::anchors/problem-space-nvc.adoc[leveloffset=+2]
 
 include::anchors/user-story-mapping.adoc[leveloffset=+2]
@@ -107,8 +175,6 @@ include::anchors/user-story-mapping.adoc[leveloffset=+2]
 
 include::anchors/adr-according-to-nygard.adoc[leveloffset=+2]
 
-include::anchors/cqrs.adoc[leveloffset=+2]
-
 include::anchors/arc42.adoc[leveloffset=+2]
 
 include::anchors/atam.adoc[leveloffset=+2]
@@ -117,6 +183,8 @@ include::anchors/c4-diagrams.adoc[leveloffset=+2]
 
 include::anchors/clean-architecture.adoc[leveloffset=+2]
 
+include::anchors/cqrs.adoc[leveloffset=+2]
+
 include::anchors/domain-driven-design.adoc[leveloffset=+2]
 
 include::anchors/event-driven-architecture.adoc[leveloffset=+2]
@@ -151,6 +219,8 @@ include::anchors/jobs-to-be-done.adoc[leveloffset=+2]
 
 include::anchors/pugh-matrix.adoc[leveloffset=+2]
 
+include::anchors/swot.adoc[leveloffset=+2]
+
 include::anchors/wardley-mapping.adoc[leveloffset=+2]
 
 <<<
@@ -159,17 +229,37 @@ include::anchors/wardley-mapping.adoc[leveloffset=+2]
 
 include::anchors/bdd-given-when-then.adoc[leveloffset=+2]
 
+include::anchors/fagan-inspection.adoc[leveloffset=+2]
+
+include::anchors/gherkin.adoc[leveloffset=+2]
+
 include::anchors/iec-61508-sil-levels.adoc[leveloffset=+2]
 
+include::anchors/linddun.adoc[leveloffset=+2]
+
 include::anchors/mutation-testing.adoc[leveloffset=+2]
 
+include::anchors/owasp-top-10.adoc[leveloffset=+2]
+
 include::anchors/property-based-testing.adoc[leveloffset=+2]
 
+include::anchors/stride.adoc[leveloffset=+2]
+
 include::anchors/tdd-chicago-school.adoc[leveloffset=+2]
 
+include::anchors/tdd-london-school.adoc[leveloffset=+2]
+
+include::anchors/test-double-dummy.adoc[leveloffset=+2]
+
+include::anchors/test-double-fake.adoc[leveloffset=+2]
+
 include::anchors/test-double-meszaros.adoc[leveloffset=+2]
 
-include::anchors/tdd-london-school.adoc[leveloffset=+2]
+include::anchors/test-double-mock.adoc[leveloffset=+2]
+
+include::anchors/test-double-spy.adoc[leveloffset=+2]
+
+include::anchors/test-double-stub.adoc[leveloffset=+2]
 
 include::anchors/testing-pyramid.adoc[leveloffset=+2]
 

docs/anchors/definition-of-done.adoc

@@ -0,0 +1,47 @@
+= Definition of Done
+:categories: development-workflow
+:roles: software-developer, qa-engineer, product-owner, team-lead
+:related: bdd-given-when-then, user-story-mapping, moscow
+:proponents: Ken Schwaber, Jeff Sutherland
+:tags: dod, acceptance criteria, scrum, agile, quality gates, done, sprint, increment
+:tier: 3
+
+[%collapsible]
+====
+Also known as:: DoD, Done Criteria, Acceptance Criteria (team-level)
+
+[discrete]
+== *Core Concepts*:
+
+Shared agreement:: A formal, team-wide checklist of quality criteria that every increment must satisfy before it is declared "done"
+
+Increment quality gates:: Concrete, verifiable conditions — e.g., code reviewed, tests passing, documentation updated, no known defects
+
+Transparency:: Makes the meaning of "done" visible and unambiguous to all stakeholders, preventing hidden technical debt
+
+Sprint-level vs. product-level DoD:: Teams may maintain separate DoD lists for Sprint increments and for releasable product increments
+
+Continuous refinement:: The DoD evolves as the team matures; stricter gates are added over time
+
+Undone work:: Work that does not meet the DoD is not counted as complete; it returns to the Product Backlog
+
+Shared responsibility:: The entire Scrum team (Developers, Product Owner, Scrum Master) owns and respects the DoD
+
+
+Key Proponents:: Ken Schwaber & Jeff Sutherland ("The Scrum Guide", 2020); Mike Cohn ("Succeeding with Agile", 2009)
+
+[discrete]
+== *When to Use*:
+
+* Establishing a consistent quality standard across a Scrum or agile team
+* Onboarding new team members so they understand what "finished" means
+* Reducing rework and late-cycle defects by agreeing on criteria upfront
+* Aligning developers, QA, and product owners on release readiness
+
+[discrete]
+== *Related Anchors*:
+
+* <<bdd-given-when-then,BDD (Behavior-Driven Development)>> - Given-When-Then scenarios that operationalize acceptance criteria
+* <<user-story-mapping,User Story Mapping>> - Planning technique that identifies the scope Definition of Done must cover
+* <<moscow,MoSCoW>> - Prioritization method used to decide which DoD items are must-haves
+====

docs/anchors/definition-of-done.de.adoc

@@ -0,0 +1,47 @@
+= Definition of Done
+:categories: development-workflow
+:roles: software-developer, qa-engineer, product-owner, team-lead
+:related: bdd-given-when-then, user-story-mapping, moscow
+:proponents: Ken Schwaber, Jeff Sutherland
+:tags: dod, acceptance criteria, scrum, agile, quality gates, done, sprint, increment
+:tier: 3
+
+[%collapsible]
+====
+Auch bekannt als:: DoD, Done-Kriterien, Akzeptanzkriterien (Teamebene)
+
+[discrete]
+== *Kernkonzepte*:
+
+Gemeinsame Vereinbarung:: Eine formelle, teamweite Checkliste von Qualitätskriterien, die jedes Inkrement erfüllen muss, bevor es als „fertig" gilt
+
+Inkrementelle Qualitätsgates:: Konkrete, überprüfbare Bedingungen — z. B. Code reviewed, Tests bestanden, Dokumentation aktualisiert, keine bekannten Defekte
+
+Transparenz:: Macht die Bedeutung von „fertig" für alle Stakeholder sichtbar und eindeutig und verhindert versteckte technische Schulden
+
+Sprint-DoD vs. Produkt-DoD:: Teams können separate DoD-Listen für Sprint-Inkremente und für auslieferbare Produktinkremente pflegen
+
+Kontinuierliche Verfeinerung:: Die DoD entwickelt sich mit der Teamreife weiter; im Laufe der Zeit werden strengere Gates hinzugefügt
+
+Nicht erledigte Arbeit:: Arbeit, die die DoD nicht erfüllt, gilt nicht als abgeschlossen und kehrt in den Product Backlog zurück
+
+Gemeinsame Verantwortung:: Das gesamte Scrum-Team (Entwickler, Product Owner, Scrum Master) besitzt und respektiert die DoD
+
+
+Schlüsselvertreter:: Ken Schwaber & Jeff Sutherland ("The Scrum Guide", 2020); Mike Cohn ("Succeeding with Agile", 2009)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Einrichtung eines konsistenten Qualitätsstandards in einem Scrum- oder agilen Team
+* Onboarding neuer Teammitglieder, damit sie verstehen, was „fertig" bedeutet
+* Reduzierung von Nacharbeit und späten Defekten durch vorherige Einigung auf Kriterien
+* Abstimmung von Entwicklern, QA und Product Ownern auf die Release-Bereitschaft
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<bdd-given-when-then,BDD (Behavior-Driven Development)>> - Given-When-Then-Szenarien, die Akzeptanzkriterien operationalisieren
+* <<user-story-mapping,User Story Mapping>> - Planungstechnik, die den Umfang identifiziert, den die DoD abdecken muss
+* <<moscow,MoSCoW>> - Priorisierungsmethode, um zu entscheiden, welche DoD-Punkte Must-haves sind
+====

docs/anchors/fagan-inspection.adoc

@@ -0,0 +1,44 @@
+= Fagan Inspection
+:categories: testing-quality
+:roles: software-developer, qa-engineer, software-architect, team-lead
+:related: mutation-testing, testing-pyramid
+:proponents: Michael Fagan
+:tags: code-review, inspection, defect-detection, formal-review, static-analysis
+:tier: 3
+
+[%collapsible]
+====
+Also known as:: Formal Code Inspection, Software Inspection, Fagan's Inspection Method
+
+[discrete]
+== Core Concepts:
+
+Formal inspection process:: A structured, multi-phase review process for software artifacts (requirements, design, code) with defined roles and entry/exit criteria
+
+Roles:: Moderator (facilitates and logs), Author (created the artifact), Inspectors (reviewers), Recorder (documents defects)
+
+Six phases:: Planning → Overview → Preparation → Inspection Meeting → Rework → Follow-up
+
+Entry and exit criteria:: Explicit conditions that must be met before entering and leaving each phase, preventing premature progression
+
+Defect classification:: Defects are categorized by type (missing, wrong, extra) and severity, enabling process improvement through causal analysis
+
+Metrics-driven:: Inspection data (defect rate, inspection rate) are collected and used to improve both the product and the inspection process itself
+
+Key Proponents:: Michael Fagan ("Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, 1976)
+
+[discrete]
+== When to Use:
+
+* Safety-critical or high-assurance software where defect escape is costly
+* Reviewing requirements, architecture, design, or code artifacts early in development
+* Establishing a culture of quality and shared code ownership in teams
+* When you want measurable, process-level quality improvement over time
+* Regulated environments (medical devices, avionics, finance) requiring documented review evidence
+
+[discrete]
+== Related Anchors:
+
+* <<mutation-testing,Mutation Testing>>
+* <<testing-pyramid,Testing Pyramid>>
+====

docs/anchors/fagan-inspection.de.adoc

@@ -0,0 +1,44 @@
+= Fagan-Inspektion
+:categories: testing-quality
+:roles: software-developer, qa-engineer, software-architect, team-lead
+:related: mutation-testing, testing-pyramid
+:proponents: Michael Fagan
+:tags: code-review, inspection, defect-detection, formal-review, static-analysis
+:tier: 3
+
+[%collapsible]
+====
+Auch bekannt als:: Formale Code-Inspektion, Software-Inspektion, Fagan's Inspektionsmethode
+
+[discrete]
+== Kernkonzepte:
+
+Formaler Inspektionsprozess:: Ein strukturierter, mehrphasiger Prüfprozess für Software-Artefakte (Anforderungen, Design, Code) mit definierten Rollen und Ein-/Ausstiegskriterien
+
+Rollen:: Moderator (leitet und protokolliert), Autor (hat das Artefakt erstellt), Inspektoren (Prüfer), Protokollant (dokumentiert Defekte)
+
+Sechs Phasen:: Planung → Übersicht → Vorbereitung → Inspektionssitzung → Nachbearbeitung → Nachverfolgung
+
+Ein- und Ausstiegskriterien:: Explizite Bedingungen, die vor dem Eintritt in und Austritt aus jeder Phase erfüllt sein müssen, um vorzeitiges Voranschreiten zu verhindern
+
+Fehlerklassifikation:: Fehler werden nach Typ (fehlend, falsch, überflüssig) und Schweregrad kategorisiert, um Prozessverbesserungen durch Ursachenanalyse zu ermöglichen
+
+Kennzahlengetrieben:: Inspektionsdaten (Fehlerrate, Inspektionsrate) werden gesammelt und zur Verbesserung sowohl des Produkts als auch des Inspektionsprozesses genutzt
+
+Schlüsselvertreter:: Michael Fagan ("Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, 1976)
+
+[discrete]
+== Wann zu verwenden:
+
+* Sicherheitskritische oder qualitätsintensive Software, bei der das Entweichen von Fehlern kostspielig ist
+* Frühe Überprüfung von Anforderungen, Architektur, Design oder Code-Artefakten
+* Aufbau einer Qualitätskultur und gemeinsamen Code-Verantwortung im Team
+* Wenn messbare, prozessbasierte Qualitätsverbesserung über die Zeit angestrebt wird
+* Regulierte Umgebungen (Medizinprodukte, Luftfahrt, Finanzen), die dokumentierte Prüfnachweise erfordern
+
+[discrete]
+== Verwandte Anker:
+
+* <<mutation-testing,Mutation Testing>>
+* <<testing-pyramid,Testing Pyramid>>
+====