From 63871728c587879aa5e91d74e9de62adebe6cb15 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Fri, 13 Feb 2026 19:29:09 +0100 Subject: [PATCH 1/2] fix: Handle anchor deep links and fix AsciiDoc definition lists Router fix: - Add handler for /anchor/:id routes - Open anchor modal when navigating to direct anchor link - Reset URL to home when modal is closed - Fixes shared/copied anchor links not opening the modal AsciiDoc linter fix: - Convert non-semantic bold labels (*Label*:) to definition lists (Label::) - Reduces linter errors from 1011 to 789 - Remaining errors are nested lists, will fix in follow-up Co-Authored-By: Claude Sonnet 4.5 --- docs/anchors/_template.adoc | 4 ++-- docs/anchors/adr-according-to-nygard.adoc | 4 ++-- docs/anchors/adr-according-to-nygard.de.adoc | 4 ++-- docs/anchors/arc42.adoc | 4 ++-- docs/anchors/arc42.de.adoc | 4 ++-- docs/anchors/bem-methodology.adoc | 4 ++-- docs/anchors/bem-methodology.de.adoc | 4 ++-- docs/anchors/bluf.adoc | 10 +++++----- docs/anchors/bluf.de.adoc | 10 +++++----- docs/anchors/c4-diagrams.adoc | 4 ++-- docs/anchors/c4-diagrams.de.adoc | 4 ++-- docs/anchors/chain-of-thought.adoc | 6 +++--- docs/anchors/chain-of-thought.de.adoc | 6 +++--- docs/anchors/clean-architecture.adoc | 4 ++-- docs/anchors/clean-architecture.de.adoc | 4 ++-- docs/anchors/control-chart-shewhart.adoc | 8 ++++---- docs/anchors/control-chart-shewhart.de.adoc | 8 ++++---- docs/anchors/conventional-commits.adoc | 2 +- docs/anchors/conventional-commits.de.adoc | 2 +- docs/anchors/cynefin-framework.adoc | 4 ++-- docs/anchors/cynefin-framework.de.adoc | 4 ++-- docs/anchors/devils-advocate.adoc | 6 +++--- docs/anchors/devils-advocate.de.adoc | 6 +++--- docs/anchors/diataxis-framework.adoc | 4 ++-- docs/anchors/diataxis-framework.de.adoc | 4 ++-- docs/anchors/docs-as-code.adoc | 4 ++-- docs/anchors/docs-as-code.de.adoc | 4 ++-- docs/anchors/domain-driven-design.adoc | 4 ++-- docs/anchors/domain-driven-design.de.adoc | 4 ++-- docs/anchors/dry-principle.adoc | 6 +++--- docs/anchors/dry-principle.de.adoc | 6 +++--- docs/anchors/ears-requirements.adoc | 4 ++-- docs/anchors/ears-requirements.de.adoc | 4 ++-- docs/anchors/feynman-technique.adoc | 8 ++++---- docs/anchors/feynman-technique.de.adoc | 8 ++++---- docs/anchors/five-whys.adoc | 6 +++--- docs/anchors/five-whys.de.adoc | 6 +++--- docs/anchors/hexagonal-architecture.adoc | 4 ++-- docs/anchors/hexagonal-architecture.de.adoc | 4 ++-- docs/anchors/iec-61508-sil-levels.adoc | 6 +++--- docs/anchors/impact-mapping.adoc | 4 ++-- docs/anchors/impact-mapping.de.adoc | 4 ++-- docs/anchors/jobs-to-be-done.adoc | 4 ++-- docs/anchors/jobs-to-be-done.de.adoc | 4 ++-- docs/anchors/madr.adoc | 6 +++--- docs/anchors/madr.de.adoc | 6 +++--- docs/anchors/mece.adoc | 4 ++-- docs/anchors/mece.de.adoc | 4 ++-- .../mental-model-according-to-naur.adoc | 6 +++--- .../mental-model-according-to-naur.de.adoc | 6 +++--- docs/anchors/morphological-box.adoc | 6 +++--- docs/anchors/mutation-testing.adoc | 4 ++-- docs/anchors/mutation-testing.de.adoc | 4 ++-- docs/anchors/nelson-rules.adoc | 4 ++-- docs/anchors/nelson-rules.de.adoc | 4 ++-- docs/anchors/problem-space-nvc.adoc | 4 ++-- docs/anchors/problem-space-nvc.de.adoc | 4 ++-- docs/anchors/property-based-testing.adoc | 4 ++-- docs/anchors/property-based-testing.de.adoc | 4 ++-- docs/anchors/pugh-matrix.adoc | 4 ++-- docs/anchors/pugh-matrix.de.adoc | 4 ++-- docs/anchors/pyramid-principle.adoc | 4 ++-- docs/anchors/pyramid-principle.de.adoc | 4 ++-- docs/anchors/rubber-duck-debugging.adoc | 6 +++--- docs/anchors/rubber-duck-debugging.de.adoc | 6 +++--- docs/anchors/semantic-versioning.adoc | 4 ++-- docs/anchors/semantic-versioning.de.adoc | 4 ++-- docs/anchors/socratic-method.adoc | 6 +++--- docs/anchors/socratic-method.de.adoc | 6 +++--- docs/anchors/solid-principles.adoc | 4 ++-- docs/anchors/solid-principles.de.adoc | 4 ++-- docs/anchors/sota.adoc | 4 ++-- docs/anchors/sota.de.adoc | 4 ++-- docs/anchors/spc.adoc | 4 ++-- docs/anchors/spc.de.adoc | 4 ++-- docs/anchors/spot-principle.adoc | 6 +++--- docs/anchors/spot-principle.de.adoc | 6 +++--- docs/anchors/ssot-principle.adoc | 6 +++--- docs/anchors/ssot-principle.de.adoc | 6 +++--- docs/anchors/tdd-chicago-school.adoc | 4 ++-- docs/anchors/tdd-chicago-school.de.adoc | 4 ++-- docs/anchors/tdd-london-school.adoc | 4 ++-- docs/anchors/tdd-london-school.de.adoc | 4 ++-- docs/anchors/testing-pyramid.adoc | 4 ++-- docs/anchors/testing-pyramid.de.adoc | 4 ++-- docs/anchors/timtowtdi.adoc | 6 +++--- docs/anchors/timtowtdi.de.adoc | 6 +++--- docs/anchors/todotxt-flavoured-markdown.adoc | 6 +++--- .../anchors/todotxt-flavoured-markdown.de.adoc | 6 +++--- docs/anchors/user-story-mapping.adoc | 4 ++-- docs/anchors/user-story-mapping.de.adoc | 4 ++-- docs/anchors/wardley-mapping.adoc | 2 +- docs/anchors/wardley-mapping.de.adoc | 2 +- website/src/components/anchor-modal.js | 5 +++++ website/src/utils/router.js | 18 ++++++++++++++++++ 95 files changed, 245 insertions(+), 222 deletions(-) diff --git a/docs/anchors/_template.adoc b/docs/anchors/_template.adoc index 6386a1d..f342d90 100644 --- a/docs/anchors/_template.adoc +++ b/docs/anchors/_template.adoc @@ -7,7 +7,7 @@ [%collapsible] ==== -*Also known as*: Alternative Name, Other Name +Also known as:: Alternative Name, Other Name *Core Concepts*: @@ -15,7 +15,7 @@ * Concept 2 * Concept 3 -*Key Proponents*: Author Name ("Book Title"), Another Author +Key Proponents:: Author Name ("Book Title"), Another Author *When to Use*: diff --git a/docs/anchors/adr-according-to-nygard.adoc b/docs/anchors/adr-according-to-nygard.adoc index e17fa50..6c8a3af 100644 --- a/docs/anchors/adr-according-to-nygard.adoc +++ b/docs/anchors/adr-according-to-nygard.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Architecture Decision Records according to Michael Nygard +Full Name:: Architecture Decision Records according to Michael Nygard *Core Concepts*: @@ -20,7 +20,7 @@ * *Decision archaeology*: Understanding why past decisions were made * *Evolutionary architecture*: Supporting architecture that changes over time -*Key Proponent*: Michael Nygard +Key Proponent:: Michael Nygard *When to Use*: diff --git a/docs/anchors/adr-according-to-nygard.de.adoc b/docs/anchors/adr-according-to-nygard.de.adoc index 0dd796d..6868e6d 100644 --- a/docs/anchors/adr-according-to-nygard.de.adoc +++ b/docs/anchors/adr-according-to-nygard.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Architecture Decision Records nach Michael Nygard +Vollständiger Name:: Architecture Decision Records nach Michael Nygard *Kernkonzepte*: @@ -20,7 +20,7 @@ * *Entscheidungsarchäologie*: Verstehen, warum vergangene Entscheidungen getroffen wurden * *Evolutionäre Architektur*: Unterstützung von Architektur, die sich im Laufe der Zeit ändert -*Schlüsselvertreter*: Michael Nygard +Schlüsselvertreter:: Michael Nygard *Wann zu verwenden*: diff --git a/docs/anchors/arc42.adoc b/docs/anchors/arc42.adoc index ef1046c..7c0e4a5 100644 --- a/docs/anchors/arc42.adoc +++ b/docs/anchors/arc42.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: arc42 Architecture Documentation Template +Full Name:: arc42 Architecture Documentation Template *Core Concepts*: @@ -25,7 +25,7 @@ * *Pragmatic documentation*: Document only what's necessary * *Multiple formats*: AsciiDoc, Markdown, Confluence, etc. -*Key Proponents*: Gernot Starke, Peter Hruschka +Key Proponents:: Gernot Starke, Peter Hruschka *When to Use*: diff --git a/docs/anchors/arc42.de.adoc b/docs/anchors/arc42.de.adoc index 8e5a478..ed76934 100644 --- a/docs/anchors/arc42.de.adoc +++ b/docs/anchors/arc42.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: arc42 Architekturdokumentations-Template +Vollständiger Name:: arc42 Architekturdokumentations-Template *Kernkonzepte*: @@ -25,7 +25,7 @@ * *Pragmatische Dokumentation*: Nur das Notwendige dokumentieren * *Mehrere Formate*: AsciiDoc, Markdown, Confluence, etc. -*Schlüsselvertreter*: Gernot Starke, Peter Hruschka +Schlüsselvertreter:: Gernot Starke, Peter Hruschka *Wann zu verwenden*: diff --git a/docs/anchors/bem-methodology.adoc b/docs/anchors/bem-methodology.adoc index b866c56..01034fb 100644 --- a/docs/anchors/bem-methodology.adoc +++ b/docs/anchors/bem-methodology.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: Block Element Modifier (BEM) (S)CSS Methodology +Full Name:: Block Element Modifier (BEM) (S)CSS Methodology *Core Concepts*: @@ -27,7 +27,7 @@ * Element: `.search-form__input`, `.search-form__button` * Modifier: `.search-form--compact`, `.search-form__button--disabled` -*Key Proponents*: Yandex development team +Key Proponents:: Yandex development team *When to Use*: diff --git a/docs/anchors/bem-methodology.de.adoc b/docs/anchors/bem-methodology.de.adoc index c60e8c9..151326f 100644 --- a/docs/anchors/bem-methodology.de.adoc +++ b/docs/anchors/bem-methodology.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: Block Element Modifier (BEM) (S)CSS-Methodologie +Vollständiger Name:: Block Element Modifier (BEM) (S)CSS-Methodologie *Kernkonzepte*: @@ -27,7 +27,7 @@ * Element: `.search-form__input`, `.search-form__button` * Modifier: `.search-form--compact`, `.search-form__button--disabled` -*Schlüsselvertreter*: Yandex Entwicklungsteam +Schlüsselvertreter:: Yandex Entwicklungsteam *Wann zu verwenden*: diff --git a/docs/anchors/bluf.adoc b/docs/anchors/bluf.adoc index 75912f2..3cfcc4b 100644 --- a/docs/anchors/bluf.adoc +++ b/docs/anchors/bluf.adoc @@ -5,9 +5,9 @@ [%collapsible] ==== -*Full Name*: BLUF (Bottom Line Up Front) +Full Name:: BLUF (Bottom Line Up Front) -*Also known as*: Direct Answer Format, Conclusion-First Communication +Also known as:: Direct Answer Format, Conclusion-First Communication *Core Concepts*: @@ -20,9 +20,9 @@ * *Clarity Over Suspense*: No narrative buildup or delayed conclusions * *One Sentence First*: Ideally, the BLUF itself is a single, clear sentence -*Key Proponents*: US Military (Army writing standards), adopted broadly in business and government +Key Proponents:: US Military (Army writing standards), adopted broadly in business and government -*Historical Context*: Standardized in military communication where rapid decision-making is critical; now standard in business writing (McKinsey, consulting, executive communication) +Historical Context:: Standardized in military communication where rapid decision-making is critical; now standard in business writing (McKinsey, consulting, executive communication) *When to Use*: @@ -39,5 +39,5 @@ * Complements MECE by providing the organizational principle for grouped information * Contrasts with narrative or exploratory writing styles -*Counter-example*: Academic papers (which build to conclusions) or storytelling (which uses suspense) +Counter-example:: Academic papers (which build to conclusions) or storytelling (which uses suspense) ==== diff --git a/docs/anchors/bluf.de.adoc b/docs/anchors/bluf.de.adoc index 9f91157..9b1f5cf 100644 --- a/docs/anchors/bluf.de.adoc +++ b/docs/anchors/bluf.de.adoc @@ -5,9 +5,9 @@ [%collapsible] ==== -*Vollständiger Name*: BLUF (Bottom Line Up Front - Das Wichtigste zuerst) +Vollständiger Name:: BLUF (Bottom Line Up Front - Das Wichtigste zuerst) -*Auch bekannt als*: Direkte Antwortformat, Schlussfolgerung-zuerst-Kommunikation +Auch bekannt als:: Direkte Antwortformat, Schlussfolgerung-zuerst-Kommunikation *Kernkonzepte*: @@ -20,9 +20,9 @@ * *Klarheit statt Spannung*: Kein narrativer Aufbau oder verzögerte Schlussfolgerungen * *Ein Satz zuerst*: Idealerweise ist das BLUF selbst ein einzelner, klarer Satz -*Schlüsselvertreter*: US-Militär (Army writing standards), weithin in Wirtschaft und Regierung übernommen +Schlüsselvertreter:: US-Militär (Army writing standards), weithin in Wirtschaft und Regierung übernommen -*Historischer Kontext*: Standardisiert in militärischer Kommunikation, wo schnelle Entscheidungsfindung kritisch ist; jetzt Standard im Business Writing (McKinsey, Consulting, Führungskommunikation) +Historischer Kontext:: Standardisiert in militärischer Kommunikation, wo schnelle Entscheidungsfindung kritisch ist; jetzt Standard im Business Writing (McKinsey, Consulting, Führungskommunikation) *Wann zu verwenden*: @@ -39,5 +39,5 @@ * Ergänzt MECE durch Bereitstellung des Organisationsprinzips für gruppierte Informationen * Kontrastiert mit narrativen oder explorativen Schreibstilen -*Gegenbeispiel*: Akademische Arbeiten (die zu Schlussfolgerungen aufbauen) oder Storytelling (das Spannung nutzt) +Gegenbeispiel:: Akademische Arbeiten (die zu Schlussfolgerungen aufbauen) oder Storytelling (das Spannung nutzt) ==== diff --git a/docs/anchors/c4-diagrams.adoc b/docs/anchors/c4-diagrams.adoc index f6479d9..afa11d2 100644 --- a/docs/anchors/c4-diagrams.adoc +++ b/docs/anchors/c4-diagrams.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: C4 Model for Software Architecture Diagrams +Full Name:: C4 Model for Software Architecture Diagrams *Core Concepts*: @@ -18,7 +18,7 @@ * *Audience-appropriate*: Different diagrams for different stakeholders * *Supplementary diagrams*: Deployment, dynamic views, etc. -*Key Proponent*: Simon Brown +Key Proponent:: Simon Brown *When to Use*: diff --git a/docs/anchors/c4-diagrams.de.adoc b/docs/anchors/c4-diagrams.de.adoc index 1dd7008..c9f3c2c 100644 --- a/docs/anchors/c4-diagrams.de.adoc +++ b/docs/anchors/c4-diagrams.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: C4-Modell für Software-Architektur-Diagramme +Vollständiger Name:: C4-Modell für Software-Architektur-Diagramme *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Publikumsgerecht*: Verschiedene Diagramme für verschiedene Stakeholder * *Ergänzende Diagramme*: Deployment, dynamische Ansichten, etc. -*Schlüsselvertreter*: Simon Brown +Schlüsselvertreter:: Simon Brown *Wann zu verwenden*: diff --git a/docs/anchors/chain-of-thought.adoc b/docs/anchors/chain-of-thought.adoc index 17f663d..a0f3cff 100644 --- a/docs/anchors/chain-of-thought.adoc +++ b/docs/anchors/chain-of-thought.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: Chain of Thought Prompting +Full Name:: Chain of Thought Prompting *Core Concepts*: @@ -18,9 +18,9 @@ * *Few-Shot CoT*: Provide examples with reasoning chains to guide the model * *Self-Consistency*: Generate multiple reasoning paths and select most consistent answer -*Key Proponents*: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" +Key Proponents:: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" -*Historical Context*: Breakthrough in LLM prompting research, significantly improved performance on reasoning tasks (math, logic, common sense) +Historical Context:: Breakthrough in LLM prompting research, significantly improved performance on reasoning tasks (math, logic, common sense) *When to Use*: diff --git a/docs/anchors/chain-of-thought.de.adoc b/docs/anchors/chain-of-thought.de.adoc index 33abf51..4870d41 100644 --- a/docs/anchors/chain-of-thought.de.adoc +++ b/docs/anchors/chain-of-thought.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: Chain of Thought Prompting (Gedankenketten-Prompting) +Vollständiger Name:: Chain of Thought Prompting (Gedankenketten-Prompting) *Kernkonzepte*: @@ -18,9 +18,9 @@ * *Few-Shot CoT*: Beispiele mit Argumentationsketten bereitstellen, um das Modell zu leiten * *Selbstkonsistenz*: Mehrere Argumentationspfade generieren und konsistenteste Antwort wählen -*Schlüsselvertreter*: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" +Schlüsselvertreter:: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" -*Historischer Kontext*: Durchbruch in der LLM-Prompting-Forschung, deutlich verbesserte Leistung bei Argumentationsaufgaben (Mathematik, Logik, gesunder Menschenverstand) +Historischer Kontext:: Durchbruch in der LLM-Prompting-Forschung, deutlich verbesserte Leistung bei Argumentationsaufgaben (Mathematik, Logik, gesunder Menschenverstand) *Wann zu verwenden*: diff --git a/docs/anchors/clean-architecture.adoc b/docs/anchors/clean-architecture.adoc index dce90f7..7b56908 100644 --- a/docs/anchors/clean-architecture.adoc +++ b/docs/anchors/clean-architecture.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Clean Architecture according to Robert C. Martin +Full Name:: Clean Architecture according to Robert C. Martin *Core Concepts*: @@ -18,7 +18,7 @@ * *Screaming Architecture*: Architecture reveals the intent of the system * *SOLID principles*: Foundation of the architecture -*Key Proponent*: Robert C. Martin ("Uncle Bob") +Key Proponent:: Robert C. Martin ("Uncle Bob") *When to Use*: diff --git a/docs/anchors/clean-architecture.de.adoc b/docs/anchors/clean-architecture.de.adoc index 038224b..a06aa0b 100644 --- a/docs/anchors/clean-architecture.de.adoc +++ b/docs/anchors/clean-architecture.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Clean Architecture nach Robert C. Martin +Vollständiger Name:: Clean Architecture nach Robert C. Martin *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Screaming Architecture*: Architektur offenbart die Absicht des Systems * *SOLID-Prinzipien*: Grundlage der Architektur -*Schlüsselvertreter*: Robert C. Martin ("Uncle Bob") +Schlüsselvertreter:: Robert C. Martin ("Uncle Bob") *Wann zu verwenden*: diff --git a/docs/anchors/control-chart-shewhart.adoc b/docs/anchors/control-chart-shewhart.adoc index 928f032..332608b 100644 --- a/docs/anchors/control-chart-shewhart.adoc +++ b/docs/anchors/control-chart-shewhart.adoc @@ -4,9 +4,9 @@ [%collapsible] ==== -*Full Name*: Shewhart Control Chart +Full Name:: Shewhart Control Chart -*Also known as*: Process Control Chart, SPC Chart +Also known as:: Process Control Chart, SPC Chart *Core Concepts*: @@ -25,9 +25,9 @@ * *In-Control vs. Out-of-Control*: Core decision based on rules (Nelson, Western Electric) * *Normal distribution assumption*: Control limits are based on normally distributed data -*Key Proponent*: Walter A. Shewhart (1920s, Bell Labs / Western Electric) +Key Proponent:: Walter A. Shewhart (1920s, Bell Labs / Western Electric) -*Key Work*: "Economic Control of Quality of Manufactured Product" (1931) +Key Work:: "Economic Control of Quality of Manufactured Product" (1931) *Relationship to Other Anchors*: diff --git a/docs/anchors/control-chart-shewhart.de.adoc b/docs/anchors/control-chart-shewhart.de.adoc index 394b2a6..c494bce 100644 --- a/docs/anchors/control-chart-shewhart.de.adoc +++ b/docs/anchors/control-chart-shewhart.de.adoc @@ -4,9 +4,9 @@ [%collapsible] ==== -*Vollständiger Name*: Shewhart-Regelkarte +Vollständiger Name:: Shewhart-Regelkarte -*Auch bekannt als*: Prozesskontrollkarte, SPC-Karte +Auch bekannt als:: Prozesskontrollkarte, SPC-Karte *Kernkonzepte*: @@ -25,9 +25,9 @@ * *Unter Kontrolle vs. Außer Kontrolle*: Kernentscheidung basierend auf Regeln (Nelson, Western Electric) * *Normalverteilungsannahme*: Kontrollgrenzen basieren auf normalverteilten Daten -*Schlüsselvertreter*: Walter A. Shewhart (1920er, Bell Labs / Western Electric) +Schlüsselvertreter:: Walter A. Shewhart (1920er, Bell Labs / Western Electric) -*Schlüsselwerk*: "Economic Control of Quality of Manufactured Product" (1931) +Schlüsselwerk:: "Economic Control of Quality of Manufactured Product" (1931) *Beziehung zu anderen Ankern*: diff --git a/docs/anchors/conventional-commits.adoc b/docs/anchors/conventional-commits.adoc index 0fc2ba2..fe2651d 100644 --- a/docs/anchors/conventional-commits.adoc +++ b/docs/anchors/conventional-commits.adoc @@ -20,7 +20,7 @@ ** *!* - BREAKING CHANGE (-> SemVer Major) * *BREAKING CHANGE:* introduces a breaking API change -*Key Proponents*: Benjamin E. Coe, James J. Womack, Steve Mao +Key Proponents:: Benjamin E. Coe, James J. Womack, Steve Mao *When to Use*: diff --git a/docs/anchors/conventional-commits.de.adoc b/docs/anchors/conventional-commits.de.adoc index d4c5377..26c1e7a 100644 --- a/docs/anchors/conventional-commits.de.adoc +++ b/docs/anchors/conventional-commits.de.adoc @@ -20,7 +20,7 @@ ** *!* - BREAKING CHANGE (-> SemVer Major) * *BREAKING CHANGE:* führt eine Breaking API-Änderung ein -*Schlüsselvertreter*: Benjamin E. Coe, James J. Womack, Steve Mao +Schlüsselvertreter:: Benjamin E. Coe, James J. Womack, Steve Mao *Wann zu verwenden*: diff --git a/docs/anchors/cynefin-framework.adoc b/docs/anchors/cynefin-framework.adoc index d5a564b..b2c2abe 100644 --- a/docs/anchors/cynefin-framework.adoc +++ b/docs/anchors/cynefin-framework.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Cynefin Framework according to Dave Snowden +Full Name:: Cynefin Framework according to Dave Snowden *Core Concepts*: @@ -20,7 +20,7 @@ * *Decision-making context*: Different domains require different approaches * *Facilitation tool*: Helps teams discuss and categorize challenges -*Key Proponent*: Dave Snowden (1999) +Key Proponent:: Dave Snowden (1999) *When to Use*: diff --git a/docs/anchors/cynefin-framework.de.adoc b/docs/anchors/cynefin-framework.de.adoc index 879e57f..32567d4 100644 --- a/docs/anchors/cynefin-framework.de.adoc +++ b/docs/anchors/cynefin-framework.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Cynefin Framework nach Dave Snowden +Vollständiger Name:: Cynefin Framework nach Dave Snowden *Kernkonzepte*: @@ -20,7 +20,7 @@ * *Entscheidungskontext*: Verschiedene Domänen erfordern verschiedene Ansätze * *Facilitierungs-Tool*: Hilft Teams, Herausforderungen zu diskutieren und zu kategorisieren -*Schlüsselvertreter*: Dave Snowden (1999) +Schlüsselvertreter:: Dave Snowden (1999) *Wann zu verwenden*: diff --git a/docs/anchors/devils-advocate.adoc b/docs/anchors/devils-advocate.adoc index d051409..bb627d1 100644 --- a/docs/anchors/devils-advocate.adoc +++ b/docs/anchors/devils-advocate.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Devil's Advocate (Latin: *Advocatus Diaboli*) +Full Name:: Devil's Advocate (Latin: *Advocatus Diaboli*) *Core Concepts*: @@ -17,9 +17,9 @@ * *Dialectical Reasoning*: Thesis + Antithesis → Synthesis * *Risk Identification*: Surface potential problems proactively -*Key Origin*: Catholic Church canonization process (Promotor Fidei role, formalized 1587), secularized in critical thinking and decision-making +Key Origin:: Catholic Church canonization process (Promotor Fidei role, formalized 1587), secularized in critical thinking and decision-making -*Historical Context*: 400+ years as formalized practice in the Church, adopted widely in law, philosophy, business strategy, and red teaming +Historical Context:: 400+ years as formalized practice in the Church, adopted widely in law, philosophy, business strategy, and red teaming *When to Use*: diff --git a/docs/anchors/devils-advocate.de.adoc b/docs/anchors/devils-advocate.de.adoc index 367f08d..ea0ee45 100644 --- a/docs/anchors/devils-advocate.de.adoc +++ b/docs/anchors/devils-advocate.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Advocatus Diaboli (Anwalt des Teufels) +Vollständiger Name:: Advocatus Diaboli (Anwalt des Teufels) *Kernkonzepte*: @@ -17,9 +17,9 @@ * *Dialektisches Denken*: These + Antithese → Synthese * *Risikoidentifikation*: Potenzielle Probleme proaktiv aufdecken -*Schlüsselursprung*: Katholische Kirche Kanonisierungsprozess (Promotor-Fidei-Rolle, formalisiert 1587), säkularisiert in kritischem Denken und Entscheidungsfindung +Schlüsselursprung:: Katholische Kirche Kanonisierungsprozess (Promotor-Fidei-Rolle, formalisiert 1587), säkularisiert in kritischem Denken und Entscheidungsfindung -*Historischer Kontext*: 400+ Jahre als formalisierte Praxis in der Kirche, weithin übernommen in Recht, Philosophie, Geschäftsstrategie und Red Teaming +Historischer Kontext:: 400+ Jahre als formalisierte Praxis in der Kirche, weithin übernommen in Recht, Philosophie, Geschäftsstrategie und Red Teaming *Wann zu verwenden*: diff --git a/docs/anchors/diataxis-framework.adoc b/docs/anchors/diataxis-framework.adoc index b730fd7..8649192 100644 --- a/docs/anchors/diataxis-framework.adoc +++ b/docs/anchors/diataxis-framework.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Diátaxis Documentation Framework according to Daniele Procida +Full Name:: Diátaxis Documentation Framework according to Daniele Procida *Core Concepts*: @@ -21,7 +21,7 @@ * *Quality criteria*: Each type has specific quality indicators * *Systematic approach*: Framework for organizing any documentation -*Key Proponent*: Daniele Procida +Key Proponent:: Daniele Procida *When to Use*: diff --git a/docs/anchors/diataxis-framework.de.adoc b/docs/anchors/diataxis-framework.de.adoc index 0ef9be3..60ba301 100644 --- a/docs/anchors/diataxis-framework.de.adoc +++ b/docs/anchors/diataxis-framework.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Diátaxis Dokumentations-Framework nach Daniele Procida +Vollständiger Name:: Diátaxis Dokumentations-Framework nach Daniele Procida *Kernkonzepte*: @@ -21,7 +21,7 @@ * *Qualitätskriterien*: Jeder Typ hat spezifische Qualitätsindikatoren * *Systematischer Ansatz*: Framework zur Organisation jeglicher Dokumentation -*Schlüsselvertreter*: Daniele Procida +Schlüsselvertreter:: Daniele Procida *Wann zu verwenden*: diff --git a/docs/anchors/docs-as-code.adoc b/docs/anchors/docs-as-code.adoc index 07ca549..3b71bfb 100644 --- a/docs/anchors/docs-as-code.adoc +++ b/docs/anchors/docs-as-code.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Docs-as-Code Approach according to Ralf D. Müller +Full Name:: Docs-as-Code Approach according to Ralf D. Müller *Core Concepts*: @@ -18,7 +18,7 @@ * *Review process*: Pull requests for documentation changes * *Modular documentation*: Includes and composition -*Key Proponent*: Ralf D. Müller (docToolchain creator) +Key Proponent:: Ralf D. Müller (docToolchain creator) *Technical Stack*: diff --git a/docs/anchors/docs-as-code.de.adoc b/docs/anchors/docs-as-code.de.adoc index 470137a..46bfab7 100644 --- a/docs/anchors/docs-as-code.de.adoc +++ b/docs/anchors/docs-as-code.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Docs-as-Code-Ansatz nach Ralf D. Müller +Vollständiger Name:: Docs-as-Code-Ansatz nach Ralf D. Müller *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Review-Prozess*: Pull Requests für Dokumentationsänderungen * *Modulare Dokumentation*: Includes und Komposition -*Schlüsselvertreter*: Ralf D. Müller (docToolchain-Ersteller) +Schlüsselvertreter:: Ralf D. Müller (docToolchain-Ersteller) *Technischer Stack*: diff --git a/docs/anchors/domain-driven-design.adoc b/docs/anchors/domain-driven-design.adoc index 9b0028a..c168b4e 100644 --- a/docs/anchors/domain-driven-design.adoc +++ b/docs/anchors/domain-driven-design.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Domain-Driven Design according to Eric Evans +Full Name:: Domain-Driven Design according to Eric Evans *Core Concepts*: @@ -19,7 +19,7 @@ * *Tactical Design*: Building blocks (entities, value objects, services) * *Model-Driven Design*: Code that expresses the domain model -*Key Proponent*: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) +Key Proponent:: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) *When to Use*: diff --git a/docs/anchors/domain-driven-design.de.adoc b/docs/anchors/domain-driven-design.de.adoc index 73758a4..86e146e 100644 --- a/docs/anchors/domain-driven-design.de.adoc +++ b/docs/anchors/domain-driven-design.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Domain-Driven Design nach Eric Evans +Vollständiger Name:: Domain-Driven Design nach Eric Evans *Kernkonzepte*: @@ -19,7 +19,7 @@ * *Taktisches Design*: Bausteine (Entities, Value Objects, Services) * *Model-Driven Design*: Code, der das Domänenmodell ausdrückt -*Schlüsselvertreter*: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) +Schlüsselvertreter:: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) *Wann zu verwenden*: diff --git a/docs/anchors/dry-principle.adoc b/docs/anchors/dry-principle.adoc index 162889d..3ddc90e 100644 --- a/docs/anchors/dry-principle.adoc +++ b/docs/anchors/dry-principle.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Don't Repeat Yourself Principle +Full Name:: Don't Repeat Yourself Principle *Core Concepts*: @@ -16,7 +16,7 @@ * *Normalized data*: Apply DRY to data structures and schemas * *Configuration management*: Centralize configuration and avoid scattered settings -*Key Proponent*: Andy Hunt and Dave Thomas ("The Pragmatic Programmer", 1999) +Key Proponent:: Andy Hunt and Dave Thomas ("The Pragmatic Programmer", 1999) *When to Use*: @@ -25,5 +25,5 @@ * Creating maintainable systems where changes are frequent * Establishing coding standards and best practices -*Related Concepts*: SPOT, SSOT, WET (Write Everything Twice - deliberate exception to DRY) +Related Concepts:: SPOT, SSOT, WET (Write Everything Twice - deliberate exception to DRY) ==== diff --git a/docs/anchors/dry-principle.de.adoc b/docs/anchors/dry-principle.de.adoc index 3e0cce1..af77607 100644 --- a/docs/anchors/dry-principle.de.adoc +++ b/docs/anchors/dry-principle.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Don't Repeat Yourself-Prinzip (Wiederhole dich nicht) +Vollständiger Name:: Don't Repeat Yourself-Prinzip (Wiederhole dich nicht) *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Normalisierte Daten*: DRY auf Datenstrukturen und Schemata anwenden * *Konfigurationsmanagement*: Konfiguration zentralisieren und verstreute Einstellungen vermeiden -*Schlüsselvertreter*: Andy Hunt und Dave Thomas ("The Pragmatic Programmer", 1999) +Schlüsselvertreter:: Andy Hunt und Dave Thomas ("The Pragmatic Programmer", 1999) *Wann zu verwenden*: @@ -25,5 +25,5 @@ * Erstellen wartbarer Systeme, bei denen Änderungen häufig sind * Etablieren von Coding-Standards und Best Practices -*Verwandte Konzepte*: SPOT, SSOT, WET (Write Everything Twice - bewusste Ausnahme von DRY) +Verwandte Konzepte:: SPOT, SSOT, WET (Write Everything Twice - bewusste Ausnahme von DRY) ==== diff --git a/docs/anchors/ears-requirements.adoc b/docs/anchors/ears-requirements.adoc index 870a69a..5289267 100644 --- a/docs/anchors/ears-requirements.adoc +++ b/docs/anchors/ears-requirements.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Easy Approach to Requirements Syntax +Full Name:: Easy Approach to Requirements Syntax *Core Concepts*: @@ -16,7 +16,7 @@ * *Structured syntax*: Consistent templates for clarity * *Testability*: Requirements written to be verifiable -*Key Proponent*: Alistair Mavin (Rolls-Royce) +Key Proponent:: Alistair Mavin (Rolls-Royce) *When to Use*: diff --git a/docs/anchors/ears-requirements.de.adoc b/docs/anchors/ears-requirements.de.adoc index 13e4a02..8ee332c 100644 --- a/docs/anchors/ears-requirements.de.adoc +++ b/docs/anchors/ears-requirements.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Easy Approach to Requirements Syntax (Einfacher Ansatz für Anforderungssyntax) +Vollständiger Name:: Easy Approach to Requirements Syntax (Einfacher Ansatz für Anforderungssyntax) *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Strukturierte Syntax*: Konsistente Vorlagen für Klarheit * *Testbarkeit*: Anforderungen so geschrieben, dass sie überprüfbar sind -*Schlüsselvertreter*: Alistair Mavin (Rolls-Royce) +Schlüsselvertreter:: Alistair Mavin (Rolls-Royce) *Wann zu verwenden*: diff --git a/docs/anchors/feynman-technique.adoc b/docs/anchors/feynman-technique.adoc index 8285e76..255c457 100644 --- a/docs/anchors/feynman-technique.adoc +++ b/docs/anchors/feynman-technique.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Feynman Technique (also Feynman Learning Method) +Full Name:: Feynman Technique (also Feynman Learning Method) *Core Concepts*: @@ -17,9 +17,9 @@ * *Active Learning*: Transform passive reading into active teaching * *Metacognition*: Become aware of what you don't know -*Key Attribution*: Richard Feynman (Nobel Prize-winning physicist, 1965), famous for making complex physics accessible +Key Attribution:: Richard Feynman (Nobel Prize-winning physicist, 1965), famous for making complex physics accessible -*Historical Context*: Feynman was renowned for his teaching ability and his belief that deep understanding meant being able to explain simply. The "technique" is a formalization of his learning approach. +Historical Context:: Feynman was renowned for his teaching ability and his belief that deep understanding meant being able to explain simply. The "technique" is a formalization of his learning approach. *When to Use*: @@ -45,5 +45,5 @@ * Elaborative interrogation * Plain language movement -*Quote*: "If you can't explain it simply, you don't understand it well enough." (Often attributed to Einstein, but embodies Feynman's philosophy) +Quote:: "If you can't explain it simply, you don't understand it well enough." (Often attributed to Einstein, but embodies Feynman's philosophy) ==== diff --git a/docs/anchors/feynman-technique.de.adoc b/docs/anchors/feynman-technique.de.adoc index 5aeb55c..cd86dd3 100644 --- a/docs/anchors/feynman-technique.de.adoc +++ b/docs/anchors/feynman-technique.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Feynman-Technik (auch Feynman-Lernmethode) +Vollständiger Name:: Feynman-Technik (auch Feynman-Lernmethode) *Kernkonzepte*: @@ -17,9 +17,9 @@ * *Aktives Lernen*: Passives Lesen in aktives Lehren transformieren * *Metakognition*: Sich bewusst werden, was Sie nicht wissen -*Schlüsselzuordnung*: Richard Feynman (Nobelpreisträger für Physik, 1965), berühmt dafür, komplexe Physik zugänglich zu machen +Schlüsselzuordnung:: Richard Feynman (Nobelpreisträger für Physik, 1965), berühmt dafür, komplexe Physik zugänglich zu machen -*Historischer Kontext*: Feynman war für seine Lehrfähigkeit und seinen Glauben bekannt, dass tiefes Verständnis bedeutet, einfach erklären zu können. Die "Technik" ist eine Formalisierung seines Lernansatzes. +Historischer Kontext:: Feynman war für seine Lehrfähigkeit und seinen Glauben bekannt, dass tiefes Verständnis bedeutet, einfach erklären zu können. Die "Technik" ist eine Formalisierung seines Lernansatzes. *Wann zu verwenden*: @@ -37,5 +37,5 @@ 3. *Lücken identifizieren und überprüfen*: Wo Sie Schwierigkeiten haben, mehr studieren 4. *Vereinfachen und analogisieren*: Ihre Erklärung verfeinern, Beispiele verwenden -*Verwandte Konzepte*: Rubber Duck Debugging, Socratic Method, ELI5 (Explain Like I'm 5) +Verwandte Konzepte:: Rubber Duck Debugging, Socratic Method, ELI5 (Explain Like I'm 5) ==== diff --git a/docs/anchors/five-whys.adoc b/docs/anchors/five-whys.adoc index 78b99ec..211ca61 100644 --- a/docs/anchors/five-whys.adoc +++ b/docs/anchors/five-whys.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Five Whys Root Cause Analysis +Full Name:: Five Whys Root Cause Analysis *Core Concepts*: @@ -17,9 +17,9 @@ * *Avoiding Blame*: Focus on process failures, not individual fault * *Countermeasure Identification*: Once root cause is found, design interventions -*Key Proponent*: Taiichi Ohno (Toyota Production System, 1950s) +Key Proponent:: Taiichi Ohno (Toyota Production System, 1950s) -*Historical Context*: Core tool in Lean Manufacturing and Toyota Production System (TPS), foundational to continuous improvement (Kaizen) +Historical Context:: Core tool in Lean Manufacturing and Toyota Production System (TPS), foundational to continuous improvement (Kaizen) *When to Use*: diff --git a/docs/anchors/five-whys.de.adoc b/docs/anchors/five-whys.de.adoc index 987de12..0444a1d 100644 --- a/docs/anchors/five-whys.de.adoc +++ b/docs/anchors/five-whys.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Five Whys Ursachenanalyse (Fünf-Warums) +Vollständiger Name:: Five Whys Ursachenanalyse (Fünf-Warums) *Kernkonzepte*: @@ -17,9 +17,9 @@ * *Schuldzuweisung vermeiden*: Fokus auf Prozessfehler, nicht individuelle Schuld * *Gegenmaßnahmen-Identifikation*: Sobald Grundursache gefunden, Interventionen entwerfen -*Schlüsselvertreter*: Taiichi Ohno (Toyota-Produktionssystem, 1950er) +Schlüsselvertreter:: Taiichi Ohno (Toyota-Produktionssystem, 1950er) -*Historischer Kontext*: Kernwerkzeug in Lean Manufacturing und Toyota Production System (TPS), grundlegend für kontinuierliche Verbesserung (Kaizen) +Historischer Kontext:: Kernwerkzeug in Lean Manufacturing und Toyota Production System (TPS), grundlegend für kontinuierliche Verbesserung (Kaizen) *Wann zu verwenden*: diff --git a/docs/anchors/hexagonal-architecture.adoc b/docs/anchors/hexagonal-architecture.adoc index d79533b..5c1edfa 100644 --- a/docs/anchors/hexagonal-architecture.adoc +++ b/docs/anchors/hexagonal-architecture.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Also known as*: Ports and Adapters, Onion Architecture (variant) +Also known as:: Ports and Adapters, Onion Architecture (variant) *Core Concepts*: @@ -18,7 +18,7 @@ * *Testability*: Easy to test core logic in isolation * *Symmetry*: All external interactions are treated uniformly -*Key Proponent*: Alistair Cockburn (2005) +Key Proponent:: Alistair Cockburn (2005) *When to Use*: diff --git a/docs/anchors/hexagonal-architecture.de.adoc b/docs/anchors/hexagonal-architecture.de.adoc index 31a6412..23fd8eb 100644 --- a/docs/anchors/hexagonal-architecture.de.adoc +++ b/docs/anchors/hexagonal-architecture.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Auch bekannt als*: Ports and Adapters, Onion Architecture (Variante) +Auch bekannt als:: Ports and Adapters, Onion Architecture (Variante) *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Testbarkeit*: Einfaches Testen der Kernlogik isoliert * *Symmetrie*: Alle externen Interaktionen werden einheitlich behandelt -*Schlüsselvertreter*: Alistair Cockburn (2005) +Schlüsselvertreter:: Alistair Cockburn (2005) *Wann zu verwenden*: diff --git a/docs/anchors/iec-61508-sil-levels.adoc b/docs/anchors/iec-61508-sil-levels.adoc index a892e5f..1ea576a 100644 --- a/docs/anchors/iec-61508-sil-levels.adoc +++ b/docs/anchors/iec-61508-sil-levels.adoc @@ -7,9 +7,9 @@ [%collapsible] ==== -*Full Name*: IEC 61508 Safety Integrity Levels +Full Name:: IEC 61508 Safety Integrity Levels -*Also known as*: Functional Safety Levels, SIL Classification +Also known as:: Functional Safety Levels, SIL Classification *Core Concepts*: @@ -28,7 +28,7 @@ * *Systematic failures*: Focus on preventing design and specification errors * *Random hardware failures*: Statistical analysis and fault tolerance -*Key Standard*: IEC 61508 "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems" (first edition 1998, second edition 2010) +Key Standard:: IEC 61508 "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems" (first edition 1998, second edition 2010) *Related Standards*: diff --git a/docs/anchors/impact-mapping.adoc b/docs/anchors/impact-mapping.adoc index feb1b05..1588acd 100644 --- a/docs/anchors/impact-mapping.adoc +++ b/docs/anchors/impact-mapping.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Impact Mapping according to Gojko Adzic +Full Name:: Impact Mapping according to Gojko Adzic *Core Concepts*: @@ -18,7 +18,7 @@ * *Scope management*: Prevent scope creep by linking to goals * *Roadmap alternative*: Goal-oriented rather than feature-oriented -*Key Proponent*: Gojko Adzic ("Impact Mapping", 2012) +Key Proponent:: Gojko Adzic ("Impact Mapping", 2012) *When to Use*: diff --git a/docs/anchors/impact-mapping.de.adoc b/docs/anchors/impact-mapping.de.adoc index 6b61cf9..01ff659 100644 --- a/docs/anchors/impact-mapping.de.adoc +++ b/docs/anchors/impact-mapping.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Impact Mapping nach Gojko Adzic +Vollständiger Name:: Impact Mapping nach Gojko Adzic *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Scope-Management*: Scope Creep durch Verknüpfung mit Zielen verhindern * *Roadmap-Alternative*: Zielorientiert statt featureorientiert -*Schlüsselvertreter*: Gojko Adzic ("Impact Mapping", 2012) +Schlüsselvertreter:: Gojko Adzic ("Impact Mapping", 2012) *Wann zu verwenden*: diff --git a/docs/anchors/jobs-to-be-done.adoc b/docs/anchors/jobs-to-be-done.adoc index ca4ad73..de6d0a8 100644 --- a/docs/anchors/jobs-to-be-done.adoc +++ b/docs/anchors/jobs-to-be-done.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: Jobs To Be Done Framework (Christensen interpretation) +Full Name:: Jobs To Be Done Framework (Christensen interpretation) *Core Concepts*: @@ -19,7 +19,7 @@ * *Innovation opportunities*: Unmet jobs or poorly served jobs * *Job stories*: Alternative to user stories focusing on context and motivation -*Key Proponents*: Clayton Christensen, Alan Klement, Bob Moesta +Key Proponents:: Clayton Christensen, Alan Klement, Bob Moesta *When to Use*: diff --git a/docs/anchors/jobs-to-be-done.de.adoc b/docs/anchors/jobs-to-be-done.de.adoc index 47f2da7..3876297 100644 --- a/docs/anchors/jobs-to-be-done.de.adoc +++ b/docs/anchors/jobs-to-be-done.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: Jobs To Be Done Framework (Christensen interpretation) +Vollständiger Name:: Jobs To Be Done Framework (Christensen interpretation) *Kernkonzepte*: @@ -19,7 +19,7 @@ * *Innovationsmöglichkeiten*: Unerfüllte Jobs oder schlecht bediente Jobs * *Job Stories*: Alternative zu User Stories mit Fokus auf Kontext und Motivation -*Schlüsselvertreter*: Clayton Christensen, Alan Klement, Bob Moesta +Schlüsselvertreter:: Clayton Christensen, Alan Klement, Bob Moesta *Wann zu verwenden*: diff --git a/docs/anchors/madr.adoc b/docs/anchors/madr.adoc index 9b390e4..ccad84c 100644 --- a/docs/anchors/madr.adoc +++ b/docs/anchors/madr.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: Markdown Any Decision Records +Full Name:: Markdown Any Decision Records *Core Concepts*: @@ -25,9 +25,9 @@ * *Version control*: Stored with code, immutable like other ADRs * *Lightweight yet comprehensive*: Balances completeness with maintainability -*Key Proponents*: Oliver Kopp, Olaf Zimmermann (and MADR community) +Key Proponents:: Oliver Kopp, Olaf Zimmermann (and MADR community) -*Reference*: https://adr.github.io/madr/ +Reference:: https://adr.github.io/madr/ *When to Use*: diff --git a/docs/anchors/madr.de.adoc b/docs/anchors/madr.de.adoc index 101849f..0b4aeac 100644 --- a/docs/anchors/madr.de.adoc +++ b/docs/anchors/madr.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: Markdown Any Decision Records +Vollständiger Name:: Markdown Any Decision Records *Kernkonzepte*: @@ -25,9 +25,9 @@ * *Versionskontrolle*: Mit Code gespeichert, unveränderlich wie andere ADRs * *Leichtgewichtig und dennoch umfassend*: Balanciert Vollständigkeit mit Wartbarkeit -*Schlüsselvertreter*: Oliver Kopp, Olaf Zimmermann (und MADR-Community) +Schlüsselvertreter:: Oliver Kopp, Olaf Zimmermann (und MADR-Community) -*Referenz*: https://adr.github.io/madr/ +Referenz:: https://adr.github.io/madr/ *Wann zu verwenden*: diff --git a/docs/anchors/mece.adoc b/docs/anchors/mece.adoc index 6336ceb..065231d 100644 --- a/docs/anchors/mece.adoc +++ b/docs/anchors/mece.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: MECE (Mutually Exclusive, Collectively Exhaustive) +Full Name:: MECE (Mutually Exclusive, Collectively Exhaustive) *Core Concepts*: @@ -17,7 +17,7 @@ * *Hierarchical application*: Can be applied recursively at multiple levels * *Validation approach*: Check both dimensions independently (exclusivity and exhaustiveness) -*Key Proponent*: Barbara Minto (McKinsey & Company, late 1960s) +Key Proponent:: Barbara Minto (McKinsey & Company, late 1960s) *When to Use*: diff --git a/docs/anchors/mece.de.adoc b/docs/anchors/mece.de.adoc index bb5b130..d0684fc 100644 --- a/docs/anchors/mece.de.adoc +++ b/docs/anchors/mece.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: MECE (Mutually Exclusive, Collectively Exhaustive - Sich gegenseitig ausschließend, gemeinsam erschöpfend) +Vollständiger Name:: MECE (Mutually Exclusive, Collectively Exhaustive - Sich gegenseitig ausschließend, gemeinsam erschöpfend) *Kernkonzepte*: @@ -17,7 +17,7 @@ * *Hierarchische Anwendung*: Kann rekursiv auf mehreren Ebenen angewendet werden * *Validierungsansatz*: Beide Dimensionen unabhängig prüfen (Ausschließlichkeit und Vollständigkeit) -*Schlüsselvertreterin*: Barbara Minto (McKinsey & Company, späte 1960er) +Schlüsselvertreterin:: Barbara Minto (McKinsey & Company, späte 1960er) *Wann zu verwenden*: diff --git a/docs/anchors/mental-model-according-to-naur.adoc b/docs/anchors/mental-model-according-to-naur.adoc index e97f7e4..f444c84 100644 --- a/docs/anchors/mental-model-according-to-naur.adoc +++ b/docs/anchors/mental-model-according-to-naur.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Programming as Theory Building (Mental Model) according to Peter Naur +Full Name:: Programming as Theory Building (Mental Model) according to Peter Naur *Core Concepts*: @@ -18,9 +18,9 @@ * *Ramp-up time*: New team members need time to build the theory * *Code as artifact*: Code is merely a representation of the underlying theory -*Key Proponent*: Peter Naur (Turing Award winner, 1978) +Key Proponent:: Peter Naur (Turing Award winner, 1978) -*Original Work*: "Programming as Theory Building" (1985) +Original Work:: "Programming as Theory Building" (1985) *Application in Software Development*: diff --git a/docs/anchors/mental-model-according-to-naur.de.adoc b/docs/anchors/mental-model-according-to-naur.de.adoc index 967bd02..9af790e 100644 --- a/docs/anchors/mental-model-according-to-naur.de.adoc +++ b/docs/anchors/mental-model-according-to-naur.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Programming as Theory Building (Mental Model) according to Peter Naur +Vollständiger Name:: Programming as Theory Building (Mental Model) according to Peter Naur *Kernkonzepte*: @@ -18,9 +18,9 @@ * *Ramp-up-Zeit*: Neue Teammitglieder brauchen Zeit, um die Theorie aufzubauen * *Code als Artefakt*: Code ist nur eine Repräsentation der zugrundeliegenden Theorie -*Schlüsselvertreter*: Peter Naur (Turing Award Gewinner, 1978) +Schlüsselvertreter:: Peter Naur (Turing Award Gewinner, 1978) -*Originalwerk*: "Programming as Theory Building" (1985) +Originalwerk:: "Programming as Theory Building" (1985) *Anwendung in der Softwareentwicklung*: diff --git a/docs/anchors/morphological-box.adoc b/docs/anchors/morphological-box.adoc index e212c19..95f06b6 100644 --- a/docs/anchors/morphological-box.adoc +++ b/docs/anchors/morphological-box.adoc @@ -7,7 +7,7 @@ [%collapsible] ==== -*Full Name*: Morphological Analysis / Morphological Box (German: Morphologischer Kasten) +Full Name:: Morphological Analysis / Morphological Box (German: Morphologischer Kasten) *Core Concepts*: @@ -20,9 +20,9 @@ * *Complete solution space*: Ensure all possibilities are considered * *Structured creativity*: Systematic approach to innovation and ideation -*Key Proponent*: Fritz Zwicky (1940s-1960s, California Institute of Technology) +Key Proponent:: Fritz Zwicky (1940s-1960s, California Institute of Technology) -*Historical Context*: Developed for aerospace engineering problems (jet engines, spacecraft propulsion), now widely applied in product development, system design, and innovation management. +Historical Context:: Developed for aerospace engineering problems (jet engines, spacecraft propulsion), now widely applied in product development, system design, and innovation management. *When to Use*: diff --git a/docs/anchors/mutation-testing.adoc b/docs/anchors/mutation-testing.adoc index a12751d..8288612 100644 --- a/docs/anchors/mutation-testing.adoc +++ b/docs/anchors/mutation-testing.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Also known as*: Mutation Analysis, Fault-Based Testing +Also known as:: Mutation Analysis, Fault-Based Testing *Core Concepts*: @@ -22,7 +22,7 @@ * *Strong mutation*: Test must produce different final output * *Test adequacy criterion*: "Are tests good enough?" not just "Is coverage high enough?" -*Key Proponents*: Richard Lipton (theoretical foundation, 1971), Richard DeMillo, Timothy Budd +Key Proponents:: Richard Lipton (theoretical foundation, 1971), Richard DeMillo, Timothy Budd *Key Tools*: diff --git a/docs/anchors/mutation-testing.de.adoc b/docs/anchors/mutation-testing.de.adoc index 9242608..f9ad489 100644 --- a/docs/anchors/mutation-testing.de.adoc +++ b/docs/anchors/mutation-testing.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Auch bekannt als*: Mutationsanalyse, Fehlerbasiertes Testen +Auch bekannt als:: Mutationsanalyse, Fehlerbasiertes Testen *Kernkonzepte*: @@ -22,7 +22,7 @@ * *Starke Mutation*: Test muss unterschiedliche finale Ausgabe erzeugen * *Testadäquatheitskriterium*: "Sind die Tests gut genug?" nicht nur "Ist die Abdeckung hoch genug?" -*Schlüsselvertreter*: Richard Lipton (theoretische Grundlage, 1971), Richard DeMillo, Timothy Budd +Schlüsselvertreter:: Richard Lipton (theoretische Grundlage, 1971), Richard DeMillo, Timothy Budd *Wichtige Werkzeuge*: diff --git a/docs/anchors/nelson-rules.adoc b/docs/anchors/nelson-rules.adoc index 68a9d97..a729d78 100644 --- a/docs/anchors/nelson-rules.adoc +++ b/docs/anchors/nelson-rules.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Nelson Rules (Tests for Special Causes) +Full Name:: Nelson Rules (Tests for Special Causes) *Core Concepts*: @@ -21,7 +21,7 @@ * *Zones A/B/C*: Dividing the Control Chart into 6 zones (each 1σ wide) * *False Positive Trade-off*: More active rules = higher sensitivity, but more false alarms -*Key Proponent*: Lloyd S. Nelson (1984, Journal of Quality Technology) +Key Proponent:: Lloyd S. Nelson (1984, Journal of Quality Technology) *Relationship to Other Anchors*: diff --git a/docs/anchors/nelson-rules.de.adoc b/docs/anchors/nelson-rules.de.adoc index 4da29bb..c709647 100644 --- a/docs/anchors/nelson-rules.de.adoc +++ b/docs/anchors/nelson-rules.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Nelson Rules (Tests for Special Causes) +Vollständiger Name:: Nelson Rules (Tests for Special Causes) *Kernkonzepte*: @@ -21,7 +21,7 @@ * *Zonen A/B/C*: Aufteilung der Regelkarte in 6 Zonen (jeweils 1σ breit) * *Falsch-Positiv-Abwägung*: Mehr aktive Regeln = höhere Sensitivität, aber mehr Fehlalarme -*Schlüsselvertreter*: Lloyd S. Nelson (1984, Journal of Quality Technology) +Schlüsselvertreter:: Lloyd S. Nelson (1984, Journal of Quality Technology) *Beziehung zu anderen Ankern*: diff --git a/docs/anchors/problem-space-nvc.adoc b/docs/anchors/problem-space-nvc.adoc index bc6f922..5a3358e 100644 --- a/docs/anchors/problem-space-nvc.adoc +++ b/docs/anchors/problem-space-nvc.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Problem Space in Nonviolent Communication +Full Name:: Problem Space in Nonviolent Communication *Core Concepts*: @@ -16,7 +16,7 @@ * *Separating observation from interpretation*: Avoiding judgment * *Needs-based conflict resolution*: Finding solutions that meet everyone's needs -*Key Proponent*: Marshall Rosenberg +Key Proponent:: Marshall Rosenberg *Application in Software Development*: diff --git a/docs/anchors/problem-space-nvc.de.adoc b/docs/anchors/problem-space-nvc.de.adoc index 30b83a4..9a23370 100644 --- a/docs/anchors/problem-space-nvc.de.adoc +++ b/docs/anchors/problem-space-nvc.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Problem Space in Nonviolent Communication +Vollständiger Name:: Problem Space in Nonviolent Communication *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Trennung von Beobachtung und Interpretation*: Vermeidung von Urteilen * *Bedürfnisbasierte Konfliktlösung*: Lösungen finden, die die Bedürfnisse aller erfüllen -*Schlüsselvertreter*: Marshall Rosenberg +Schlüsselvertreter:: Marshall Rosenberg *Anwendung in der Softwareentwicklung*: diff --git a/docs/anchors/property-based-testing.adoc b/docs/anchors/property-based-testing.adoc index dedd66a..62881e1 100644 --- a/docs/anchors/property-based-testing.adoc +++ b/docs/anchors/property-based-testing.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Also known as*: Generative Testing, QuickCheck-style Testing +Also known as:: Generative Testing, QuickCheck-style Testing *Core Concepts*: @@ -18,7 +18,7 @@ * *Stateful testing*: Testing sequences of operations * *Model-based testing*: Compare implementation against simpler model -*Key Tools*: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) +Key Tools:: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) *When to Use*: diff --git a/docs/anchors/property-based-testing.de.adoc b/docs/anchors/property-based-testing.de.adoc index ee1e182..90bc482 100644 --- a/docs/anchors/property-based-testing.de.adoc +++ b/docs/anchors/property-based-testing.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Auch bekannt als*: Generatives Testen, QuickCheck-artiges Testen +Auch bekannt als:: Generatives Testen, QuickCheck-artiges Testen *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Zustandsbehaftetes Testen*: Testen von Operationssequenzen * *Modellbasiertes Testen*: Implementierung gegen einfacheres Modell vergleichen -*Wichtige Werkzeuge*: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) +Wichtige Werkzeuge:: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) *Wann zu verwenden*: diff --git a/docs/anchors/pugh-matrix.adoc b/docs/anchors/pugh-matrix.adoc index f90cbed..5ec058f 100644 --- a/docs/anchors/pugh-matrix.adoc +++ b/docs/anchors/pugh-matrix.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Pugh Decision Matrix (also Pugh Controlled Convergence) +Full Name:: Pugh Decision Matrix (also Pugh Controlled Convergence) *Core Concepts*: @@ -16,7 +16,7 @@ * *Team decision-making*: Facilitates group consensus * *Hybrid solutions*: Combine strengths of different alternatives -*Key Proponent*: Stuart Pugh +Key Proponent:: Stuart Pugh *When to Use*: diff --git a/docs/anchors/pugh-matrix.de.adoc b/docs/anchors/pugh-matrix.de.adoc index 30b5a6c..9972a09 100644 --- a/docs/anchors/pugh-matrix.de.adoc +++ b/docs/anchors/pugh-matrix.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Pugh Decision Matrix (also Pugh Controlled Convergence) +Vollständiger Name:: Pugh Decision Matrix (also Pugh Controlled Convergence) *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Team-Entscheidungsfindung*: Erleichtert Gruppenkonsens * *Hybridlösungen*: Stärken verschiedener Alternativen kombinieren -*Schlüsselvertreter*: Stuart Pugh +Schlüsselvertreter:: Stuart Pugh *Wann zu verwenden*: diff --git a/docs/anchors/pyramid-principle.adoc b/docs/anchors/pyramid-principle.adoc index a0fcadc..2ca0552 100644 --- a/docs/anchors/pyramid-principle.adoc +++ b/docs/anchors/pyramid-principle.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: The Minto Pyramid Principle according to Barbara Minto +Full Name:: The Minto Pyramid Principle according to Barbara Minto *Core Concepts*: @@ -18,7 +18,7 @@ * *BLUF*: Bottom Line Up Front - lead with the conclusion * *Deductive vs. Inductive Reasoning*: Choose appropriate logic for horizontal grouping -*Key Proponent*: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) +Key Proponent:: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) *When to Use*: diff --git a/docs/anchors/pyramid-principle.de.adoc b/docs/anchors/pyramid-principle.de.adoc index 34df898..08df0d2 100644 --- a/docs/anchors/pyramid-principle.de.adoc +++ b/docs/anchors/pyramid-principle.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: The Minto Pyramid Principle according to Barbara Minto +Vollständiger Name:: The Minto Pyramid Principle according to Barbara Minto *Kernkonzepte*: @@ -18,7 +18,7 @@ * *BLUF*: Bottom Line Up Front - mit der Schlussfolgerung beginnen * *Deduktives vs. Induktives Denken*: Geeignete Logik für horizontale Gruppierung wählen -*Schlüsselvertreterin*: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) +Schlüsselvertreterin:: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) *Wann zu verwenden*: diff --git a/docs/anchors/rubber-duck-debugging.adoc b/docs/anchors/rubber-duck-debugging.adoc index 51e7107..f26183e 100644 --- a/docs/anchors/rubber-duck-debugging.adoc +++ b/docs/anchors/rubber-duck-debugging.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Rubber Duck Debugging +Full Name:: Rubber Duck Debugging *Core Concepts*: @@ -17,9 +17,9 @@ * *Self-Directed Learning*: Often the explainer solves the problem before finishing the explanation * *Teaching to Learn*: Related to the Feynman Technique and learning-by-teaching principle -*Key Origin*: "The Pragmatic Programmer" by Andrew Hunt and David Thomas (1999), referencing earlier programmer folklore +Key Origin:: "The Pragmatic Programmer" by Andrew Hunt and David Thomas (1999), referencing earlier programmer folklore -*Historical Context*: Decades-old practice in programming culture, formalized and named in influential software engineering literature +Historical Context:: Decades-old practice in programming culture, formalized and named in influential software engineering literature *When to Use*: diff --git a/docs/anchors/rubber-duck-debugging.de.adoc b/docs/anchors/rubber-duck-debugging.de.adoc index 3236554..23003bf 100644 --- a/docs/anchors/rubber-duck-debugging.de.adoc +++ b/docs/anchors/rubber-duck-debugging.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Rubber Duck Debugging +Vollständiger Name:: Rubber Duck Debugging *Kernkonzepte*: @@ -17,9 +17,9 @@ * *Selbstgesteuertes Lernen*: Oft löst der Erklärende das Problem, bevor er die Erklärung beendet * *Durch Lehren lernen*: Verwandt mit der Feynman-Technik und dem Lern-durch-Lehren-Prinzip -*Schlüsselursprung*: "The Pragmatic Programmer" von Andrew Hunt und David Thomas (1999), unter Bezugnahme auf ältere Programmiererfolklore +Schlüsselursprung:: "The Pragmatic Programmer" von Andrew Hunt und David Thomas (1999), unter Bezugnahme auf ältere Programmiererfolklore -*Historischer Kontext*: Jahrzehntealte Praxis in der Programmierkultur, formalisiert und benannt in einflussreicher Software-Engineering-Literatur +Historischer Kontext:: Jahrzehntealte Praxis in der Programmierkultur, formalisiert und benannt in einflussreicher Software-Engineering-Literatur *Wann zu verwenden*: diff --git a/docs/anchors/semantic-versioning.adoc b/docs/anchors/semantic-versioning.adoc index ceeeee7..53282a3 100644 --- a/docs/anchors/semantic-versioning.adoc +++ b/docs/anchors/semantic-versioning.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Semantic Versioning Specification +Full Name:: Semantic Versioning Specification *Core Concepts*: @@ -18,7 +18,7 @@ * *Initial development*: 0.y.z for initial development (API unstable) * *Public API declaration*: Once public API declared, version dependencies matter -*Key Proponent*: Tom Preston-Werner +Key Proponent:: Tom Preston-Werner *When to Use*: diff --git a/docs/anchors/semantic-versioning.de.adoc b/docs/anchors/semantic-versioning.de.adoc index 5c6ec28..3d761c8 100644 --- a/docs/anchors/semantic-versioning.de.adoc +++ b/docs/anchors/semantic-versioning.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Semantic Versioning Specification +Vollständiger Name:: Semantic Versioning Specification *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Initiale Entwicklung*: 0.y.z für initiale Entwicklung (API instabil) * *Public API-Deklaration*: Sobald public API deklariert, sind Versionsabhängigkeiten wichtig -*Schlüsselvertreter*: Tom Preston-Werner +Schlüsselvertreter:: Tom Preston-Werner *Wann zu verwenden*: diff --git a/docs/anchors/socratic-method.adoc b/docs/anchors/socratic-method.adoc index 54af87d..ccec3c4 100644 --- a/docs/anchors/socratic-method.adoc +++ b/docs/anchors/socratic-method.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Socratic Method (also Socratic Dialogue, Elenchus) +Full Name:: Socratic Method (also Socratic Dialogue, Elenchus) *Core Concepts*: @@ -18,9 +18,9 @@ * *Assumption Surfacing*: Make implicit beliefs explicit through systematic questioning * *Logical Consistency*: Test ideas for internal coherence and contradictions -*Key Proponent*: Socrates (via Plato's dialogues, ~400 BCE) +Key Proponent:: Socrates (via Plato's dialogues, ~400 BCE) -*Historical Context*: 2400+ years of philosophical tradition, foundational to Western philosophy and critical thinking education +Historical Context:: 2400+ years of philosophical tradition, foundational to Western philosophy and critical thinking education *When to Use*: diff --git a/docs/anchors/socratic-method.de.adoc b/docs/anchors/socratic-method.de.adoc index 32c39f3..436521d 100644 --- a/docs/anchors/socratic-method.de.adoc +++ b/docs/anchors/socratic-method.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Sokratische Methode (auch Sokratischer Dialog, Elenchos) +Vollständiger Name:: Sokratische Methode (auch Sokratischer Dialog, Elenchos) *Kernkonzepte*: @@ -18,9 +18,9 @@ * *Annahmen sichtbar machen*: Implizite Überzeugungen durch systematisches Befragen explizit machen * *Logische Konsistenz*: Ideen auf innere Kohärenz und Widersprüche testen -*Schlüsselvertreter*: Sokrates (via Platons Dialoge, ~400 v. Chr.) +Schlüsselvertreter:: Sokrates (via Platons Dialoge, ~400 v. Chr.) -*Historischer Kontext*: 2400+ Jahre philosophische Tradition, grundlegend für westliche Philosophie und kritisches Denken in der Bildung +Historischer Kontext:: 2400+ Jahre philosophische Tradition, grundlegend für westliche Philosophie und kritisches Denken in der Bildung *Wann zu verwenden*: diff --git a/docs/anchors/solid-principles.adoc b/docs/anchors/solid-principles.adoc index 6af970f..e8254cc 100644 --- a/docs/anchors/solid-principles.adoc +++ b/docs/anchors/solid-principles.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: SOLID Object-Oriented Design Principles +Full Name:: SOLID Object-Oriented Design Principles *Core Concepts*: @@ -14,7 +14,7 @@ * *Interface Segregation Principle (ISP)*: Clients should not be forced to depend on interfaces they do not use * *Dependency Inversion Principle (DIP)*: Depend on abstractions, not concrete implementations -*Key Proponent*: Robert C. Martin ("Uncle Bob") +Key Proponent:: Robert C. Martin ("Uncle Bob") *When to Use*: diff --git a/docs/anchors/solid-principles.de.adoc b/docs/anchors/solid-principles.de.adoc index 3a9ea01..ac0b31e 100644 --- a/docs/anchors/solid-principles.de.adoc +++ b/docs/anchors/solid-principles.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: SOLID Object-Oriented Design Principles +Vollständiger Name:: SOLID Object-Oriented Design Principles *Kernkonzepte*: @@ -14,7 +14,7 @@ * *Interface Segregation Principle (ISP)*: Clients sollten nicht gezwungen werden, von Schnittstellen abzuhängen, die sie nicht nutzen * *Dependency Inversion Principle (DIP)*: Von Abstraktionen abhängen, nicht von konkreten Implementierungen -*Schlüsselvertreter*: Robert C. Martin ("Uncle Bob") +Schlüsselvertreter:: Robert C. Martin ("Uncle Bob") *Wann zu verwenden*: diff --git a/docs/anchors/sota.adoc b/docs/anchors/sota.adoc index 9c6b217..ca8650b 100644 --- a/docs/anchors/sota.adoc +++ b/docs/anchors/sota.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: State-of-the-Art +Full Name:: State-of-the-Art *Core Concepts*: @@ -29,7 +29,7 @@ * "Give me the SOTA approach for semantic search" * "What's the SOTA in transformer architectures?" -*Key Proponent*: Widely used in ML/AI research community +Key Proponent:: Widely used in ML/AI research community *When to Use*: diff --git a/docs/anchors/sota.de.adoc b/docs/anchors/sota.de.adoc index 8d8cc30..9e1111c 100644 --- a/docs/anchors/sota.de.adoc +++ b/docs/anchors/sota.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: State-of-the-Art +Vollständiger Name:: State-of-the-Art *Kernkonzepte*: @@ -29,7 +29,7 @@ * "Gib mir den SOTA-Ansatz für semantische Suche" * "Was ist der SOTA bei Transformer-Architekturen?" -*Schlüsselvertreter*: Weit verbreitet in der ML/AI-Forschungsgemeinschaft +Schlüsselvertreter:: Weit verbreitet in der ML/AI-Forschungsgemeinschaft *Wann zu verwenden*: diff --git a/docs/anchors/spc.adoc b/docs/anchors/spc.adoc index fbf9810..ae74dda 100644 --- a/docs/anchors/spc.adoc +++ b/docs/anchors/spc.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Full Name*: Statistical Process Control +Full Name:: Statistical Process Control *Core Concepts*: @@ -20,7 +20,7 @@ * *Continuous Improvement*: SPC as a foundation for ongoing process improvement * *DMAIC Control Phase*: SPC tools secure improvements within Six Sigma -*Key Proponents*: Walter A. Shewhart (founder), W. Edwards Deming (dissemination), Western Electric Company +Key Proponents:: Walter A. Shewhart (founder), W. Edwards Deming (dissemination), Western Electric Company *Relationship to Other Anchors*: diff --git a/docs/anchors/spc.de.adoc b/docs/anchors/spc.de.adoc index 4b85e4f..a475d8c 100644 --- a/docs/anchors/spc.de.adoc +++ b/docs/anchors/spc.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Vollständiger Name*: Statistical Process Control +Vollständiger Name:: Statistical Process Control *Kernkonzepte*: @@ -20,7 +20,7 @@ * *Kontinuierliche Verbesserung*: SPC als Grundlage für fortlaufende Prozessverbesserung * *DMAIC Control Phase*: SPC-Werkzeuge sichern Verbesserungen innerhalb von Six Sigma -*Schlüsselvertreter*: Walter A. Shewhart (Gründer), W. Edwards Deming (Verbreitung), Western Electric Company +Schlüsselvertreter:: Walter A. Shewhart (Gründer), W. Edwards Deming (Verbreitung), Western Electric Company *Beziehung zu anderen Ankern*: diff --git a/docs/anchors/spot-principle.adoc b/docs/anchors/spot-principle.adoc index 0ec394b..c015c0b 100644 --- a/docs/anchors/spot-principle.adoc +++ b/docs/anchors/spot-principle.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Single Point of Truth +Full Name:: Single Point of Truth *Core Concepts*: @@ -24,7 +24,7 @@ * State management in applications * API design where data flows from a single endpoint -*Difference from SSOT*: SPOT emphasizes the implementation detail of where data lives, while SSOT emphasizes the authoritative, trusted nature of that data source +Difference from SSOT:: SPOT emphasizes the implementation detail of where data lives, while SSOT emphasizes the authoritative, trusted nature of that data source -*Related Concepts*: DRY, SSOT, Normalized databases, Master data management +Related Concepts:: DRY, SSOT, Normalized databases, Master data management ==== diff --git a/docs/anchors/spot-principle.de.adoc b/docs/anchors/spot-principle.de.adoc index b40be38..e4b5ad6 100644 --- a/docs/anchors/spot-principle.de.adoc +++ b/docs/anchors/spot-principle.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Single Point of Truth +Vollständiger Name:: Single Point of Truth *Kernkonzepte*: @@ -24,7 +24,7 @@ * State-Management in Anwendungen * API-Design, wo Daten von einem einzelnen Endpoint fließen -*Unterschied zu SSOT*: SPOT betont das Implementierungsdetail, wo Daten leben, während SSOT die autoritative, vertrauenswürdige Natur dieser Datenquelle betont +Unterschied zu SSOT:: SPOT betont das Implementierungsdetail, wo Daten leben, während SSOT die autoritative, vertrauenswürdige Natur dieser Datenquelle betont -*Verwandte Konzepte*: DRY, SSOT, Normalisierte Datenbanken, Master Data Management +Verwandte Konzepte:: DRY, SSOT, Normalisierte Datenbanken, Master Data Management ==== diff --git a/docs/anchors/ssot-principle.adoc b/docs/anchors/ssot-principle.adoc index 7e12bcc..54d3491 100644 --- a/docs/anchors/ssot-principle.adoc +++ b/docs/anchors/ssot-principle.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Single Source of Truth +Full Name:: Single Source of Truth *Core Concepts*: @@ -34,7 +34,7 @@ * Creating audit trails and ensuring compliance * Resolving conflicts between multiple data sources -*Difference from SPOT*: SSOT emphasizes the authoritative, trusted nature of a data source and is used at the architecture/organizational level, while SPOT focuses on the implementation pattern +Difference from SPOT:: SSOT emphasizes the authoritative, trusted nature of a data source and is used at the architecture/organizational level, while SPOT focuses on the implementation pattern -*Related Concepts*: DRY, SPOT, Event sourcing, Data lakes, Master data management +Related Concepts:: DRY, SPOT, Event sourcing, Data lakes, Master data management ==== diff --git a/docs/anchors/ssot-principle.de.adoc b/docs/anchors/ssot-principle.de.adoc index 2732434..662834b 100644 --- a/docs/anchors/ssot-principle.de.adoc +++ b/docs/anchors/ssot-principle.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Single Source of Truth +Vollständiger Name:: Single Source of Truth *Kernkonzepte*: @@ -34,7 +34,7 @@ * Erstellung von Audit-Trails und Sicherstellung von Compliance * Auflösung von Konflikten zwischen mehreren Datenquellen -*Unterschied zu SPOT*: SSOT betont die autoritative, vertrauenswürdige Natur einer Datenquelle und wird auf Architektur-/Organisationsebene verwendet, während SPOT sich auf das Implementierungsmuster fokussiert +Unterschied zu SPOT:: SSOT betont die autoritative, vertrauenswürdige Natur einer Datenquelle und wird auf Architektur-/Organisationsebene verwendet, während SPOT sich auf das Implementierungsmuster fokussiert -*Verwandte Konzepte*: DRY, SPOT, Event Sourcing, Data Lakes, Master Data Management +Verwandte Konzepte:: DRY, SPOT, Event Sourcing, Data Lakes, Master Data Management ==== diff --git a/docs/anchors/tdd-chicago-school.adoc b/docs/anchors/tdd-chicago-school.adoc index 551e93f..0ec72ca 100644 --- a/docs/anchors/tdd-chicago-school.adoc +++ b/docs/anchors/tdd-chicago-school.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Also known as*: Classicist TDD, Detroit School +Also known as:: Classicist TDD, Detroit School *Core Concepts*: @@ -16,7 +16,7 @@ * *Red-Green-Refactor*: The fundamental TDD cycle * *YAGNI*: You Aren't Gonna Need It - avoid premature abstraction -*Key Proponents*: Kent Beck, Martin Fowler +Key Proponents:: Kent Beck, Martin Fowler *When to Use*: diff --git a/docs/anchors/tdd-chicago-school.de.adoc b/docs/anchors/tdd-chicago-school.de.adoc index 969d476..2756094 100644 --- a/docs/anchors/tdd-chicago-school.de.adoc +++ b/docs/anchors/tdd-chicago-school.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Auch bekannt als*: Klassisches TDD, Detroit School +Auch bekannt als:: Klassisches TDD, Detroit School *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Red-Green-Refactor*: Der fundamentale TDD-Zyklus * *YAGNI*: You Aren't Gonna Need It - vorzeitige Abstraktion vermeiden -*Schlüsselvertreter*: Kent Beck, Martin Fowler +Schlüsselvertreter:: Kent Beck, Martin Fowler *Wann zu verwenden*: diff --git a/docs/anchors/tdd-london-school.adoc b/docs/anchors/tdd-london-school.adoc index 346bd02..3d34efe 100644 --- a/docs/anchors/tdd-london-school.adoc +++ b/docs/anchors/tdd-london-school.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Also known as*: Mockist TDD, Outside-In TDD +Also known as:: Mockist TDD, Outside-In TDD *Core Concepts*: @@ -16,7 +16,7 @@ * *Interface discovery*: Use tests to discover and define interfaces * *Walking skeleton*: Build end-to-end functionality early, then fill in details -*Key Proponents*: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") +Key Proponents:: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") *When to Use*: diff --git a/docs/anchors/tdd-london-school.de.adoc b/docs/anchors/tdd-london-school.de.adoc index b73fc2f..979b80c 100644 --- a/docs/anchors/tdd-london-school.de.adoc +++ b/docs/anchors/tdd-london-school.de.adoc @@ -5,7 +5,7 @@ [%collapsible] ==== -*Auch bekannt als*: Mockist TDD, Outside-In TDD +Auch bekannt als:: Mockist TDD, Outside-In TDD *Kernkonzepte*: @@ -16,7 +16,7 @@ * *Interface Discovery*: Tests nutzen, um Interfaces zu entdecken und zu definieren * *Walking Skeleton*: End-to-End-Funktionalität früh aufbauen, dann Details ausfüllen -*Schlüsselvertreter*: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") +Schlüsselvertreter:: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") *Wann zu verwenden*: diff --git a/docs/anchors/testing-pyramid.adoc b/docs/anchors/testing-pyramid.adoc index 81df412..f49aa23 100644 --- a/docs/anchors/testing-pyramid.adoc +++ b/docs/anchors/testing-pyramid.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: Testing Pyramid according to Mike Cohn +Full Name:: Testing Pyramid according to Mike Cohn *Core Concepts*: @@ -19,7 +19,7 @@ * *Test at the right level*: Don't test through UI what can be tested in isolation * *Confidence gradient*: Balance confidence with execution speed -*Key Proponent*: Mike Cohn ("Succeeding with Agile", 2009) +Key Proponent:: Mike Cohn ("Succeeding with Agile", 2009) *When to Use*: diff --git a/docs/anchors/testing-pyramid.de.adoc b/docs/anchors/testing-pyramid.de.adoc index 536dad4..fbce410 100644 --- a/docs/anchors/testing-pyramid.de.adoc +++ b/docs/anchors/testing-pyramid.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: Testing Pyramid nach Mike Cohn +Vollständiger Name:: Testing Pyramid nach Mike Cohn *Kernkonzepte*: @@ -19,7 +19,7 @@ * *Auf der richtigen Ebene testen*: Nicht durch UI testen, was isoliert getestet werden kann * *Vertrauensgradient*: Balance zwischen Vertrauen und Ausführungsgeschwindigkeit -*Schlüsselvertreter*: Mike Cohn ("Succeeding with Agile", 2009) +Schlüsselvertreter:: Mike Cohn ("Succeeding with Agile", 2009) *Wann zu verwenden*: diff --git a/docs/anchors/timtowtdi.adoc b/docs/anchors/timtowtdi.adoc index f548294..7810a97 100644 --- a/docs/anchors/timtowtdi.adoc +++ b/docs/anchors/timtowtdi.adoc @@ -4,9 +4,9 @@ [%collapsible] ==== -*Full Name*: There Is More Than One Way To Do It +Full Name:: There Is More Than One Way To Do It -*Also known as*: Tim Toady +Also known as:: Tim Toady *Core Concepts*: @@ -19,7 +19,7 @@ * *Pragmatism over purity*: Practical results matter more than theoretical elegance * *Collaborative decision-making*: When working with others, discuss approach rather than assume -*Key Proponent*: Larry Wall (Perl programming language) +Key Proponent:: Larry Wall (Perl programming language) *Contrast*: diff --git a/docs/anchors/timtowtdi.de.adoc b/docs/anchors/timtowtdi.de.adoc index 661395d..19a39a0 100644 --- a/docs/anchors/timtowtdi.de.adoc +++ b/docs/anchors/timtowtdi.de.adoc @@ -4,9 +4,9 @@ [%collapsible] ==== -*Vollständiger Name*: There Is More Than One Way To Do It +Vollständiger Name:: There Is More Than One Way To Do It -*Auch bekannt als*: Tim Toady +Auch bekannt als:: Tim Toady *Kernkonzepte*: @@ -19,7 +19,7 @@ * *Pragmatismus über Reinheit*: Praktische Ergebnisse zählen mehr als theoretische Eleganz * *Kollaborative Entscheidungsfindung*: Bei Zusammenarbeit mit anderen den Ansatz diskutieren, statt anzunehmen -*Schlüsselvertreter*: Larry Wall (Perl Programmiersprache) +Schlüsselvertreter:: Larry Wall (Perl Programmiersprache) *Kontrast*: diff --git a/docs/anchors/todotxt-flavoured-markdown.adoc b/docs/anchors/todotxt-flavoured-markdown.adoc index a6787ea..fe89180 100644 --- a/docs/anchors/todotxt-flavoured-markdown.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.adoc @@ -5,9 +5,9 @@ [%collapsible] ==== -*Full Name*: todo.txt-flavoured Markdown Task Lists +Full Name:: todo.txt-flavoured Markdown Task Lists -*Also known as*: Enhanced Markdown Tasks, Markdown with todo.txt conventions +Also known as:: Enhanced Markdown Tasks, Markdown with todo.txt conventions *Core Concepts*: @@ -40,7 +40,7 @@ - [x] 2024-01-30 Fix bug in authentication +backend @computer ---- -*Key Proponents*: Combines GitHub-flavoured Markdown task lists with Gina Trapani's todo.txt format +Key Proponents:: Combines GitHub-flavoured Markdown task lists with Gina Trapani's todo.txt format *Original References*: diff --git a/docs/anchors/todotxt-flavoured-markdown.de.adoc b/docs/anchors/todotxt-flavoured-markdown.de.adoc index 5908da9..e524a52 100644 --- a/docs/anchors/todotxt-flavoured-markdown.de.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.de.adoc @@ -5,9 +5,9 @@ [%collapsible] ==== -*Vollständiger Name*: todo.txt-flavoured Markdown Task Lists +Vollständiger Name:: todo.txt-flavoured Markdown Task Lists -*Auch bekannt als*: Enhanced Markdown Tasks, Markdown with todo.txt conventions +Auch bekannt als:: Enhanced Markdown Tasks, Markdown with todo.txt conventions *Kernkonzepte*: @@ -40,7 +40,7 @@ - [x] 2024-01-30 Fix bug in authentication +backend @computer ---- -*Schlüsselvertreter*: Combines GitHub-flavoured Markdown task lists with Gina Trapani's todo.txt format +Schlüsselvertreter:: Combines GitHub-flavoured Markdown task lists with Gina Trapani's todo.txt format *Original References*: diff --git a/docs/anchors/user-story-mapping.adoc b/docs/anchors/user-story-mapping.adoc index 27ece0e..955de54 100644 --- a/docs/anchors/user-story-mapping.adoc +++ b/docs/anchors/user-story-mapping.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Full Name*: User Story Mapping according to Jeff Patton +Full Name:: User Story Mapping according to Jeff Patton *Core Concepts*: @@ -18,7 +18,7 @@ * *Big picture view*: See the whole journey, not just backlog items * *Opportunity for conversation*: Stories as placeholders for discussion -*Key Proponent*: Jeff Patton ("User Story Mapping", 2014) +Key Proponent:: Jeff Patton ("User Story Mapping", 2014) *When to Use*: diff --git a/docs/anchors/user-story-mapping.de.adoc b/docs/anchors/user-story-mapping.de.adoc index 169fc46..cfe426f 100644 --- a/docs/anchors/user-story-mapping.de.adoc +++ b/docs/anchors/user-story-mapping.de.adoc @@ -4,7 +4,7 @@ [%collapsible] ==== -*Vollständiger Name*: User Story Mapping according to Jeff Patton +Vollständiger Name:: User Story Mapping according to Jeff Patton *Kernkonzepte*: @@ -18,7 +18,7 @@ * *Big-Picture-Sicht*: Die gesamte Journey sehen, nicht nur Backlog-Items * *Gelegenheit für Konversation*: Stories als Platzhalter für Diskussion -*Schlüsselvertreter*: Jeff Patton ("User Story Mapping", 2014) +Schlüsselvertreter:: Jeff Patton ("User Story Mapping", 2014) *Wann zu verwenden*: diff --git a/docs/anchors/wardley-mapping.adoc b/docs/anchors/wardley-mapping.adoc index 2d6a130..8c0c4f0 100644 --- a/docs/anchors/wardley-mapping.adoc +++ b/docs/anchors/wardley-mapping.adoc @@ -17,7 +17,7 @@ * *Strategic planning*: Visual approach to strategy * *Build-Buy-Partner decisions*: Based on evolution stage -*Key Proponent*: Simon Wardley +Key Proponent:: Simon Wardley *When to Use*: diff --git a/docs/anchors/wardley-mapping.de.adoc b/docs/anchors/wardley-mapping.de.adoc index 154e5a6..f0d3ec2 100644 --- a/docs/anchors/wardley-mapping.de.adoc +++ b/docs/anchors/wardley-mapping.de.adoc @@ -17,7 +17,7 @@ * *Strategische Planung*: Visueller Ansatz zur Strategie * *Build-Buy-Partner-Entscheidungen*: Basierend auf Evolutionsstufe -*Schlüsselvertreter*: Simon Wardley +Schlüsselvertreter:: Simon Wardley *Wann zu verwenden*: diff --git a/website/src/components/anchor-modal.js b/website/src/components/anchor-modal.js index cdb6e32..b0c98b2 100644 --- a/website/src/components/anchor-modal.js +++ b/website/src/components/anchor-modal.js @@ -82,6 +82,11 @@ export function closeModal() { modal.classList.add('hidden') modal.classList.remove('flex') document.body.style.overflow = '' + + // Reset URL to home if we're on an anchor route + if (window.location.hash.startsWith('#/anchor/')) { + window.location.hash = '#/' + } } } diff --git a/website/src/utils/router.js b/website/src/utils/router.js index a62c073..cc0aa6a 100644 --- a/website/src/utils/router.js +++ b/website/src/utils/router.js @@ -47,6 +47,24 @@ export function initRouter() { */ function handleRoute() { const path = getCurrentRoute() + + // Check for anchor route (#/anchor/:id) + if (path.startsWith('/anchor/')) { + const anchorId = path.replace('/anchor/', '') + // Navigate to home first + const homeHandler = routes.get('/') + if (homeHandler) { + currentRoute = '/' + homeHandler() + } + // Then open the anchor modal + // Import dynamically to avoid circular dependency + import('../components/anchor-modal.js').then(({ showAnchorDetails }) => { + showAnchorDetails(anchorId) + }) + return + } + const handler = routes.get(path) if (handler) { From dafa548685787daee971555c78003cd644a90540 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Fri, 13 Feb 2026 19:40:49 +0100 Subject: [PATCH 2/2] refactor: Convert all anchors to semantic AsciiDoc definition lists - Convert 1011 linter violations to proper AsciiDoc syntax - Use definition lists (Label::) instead of bullet lists with bold - Use nested definition lists (:::) for hierarchical structures - Fix explicit numbering (1. 2. 3.) to auto-numbering (. . .) - Remove excessive blank lines - Update template with correct structure All 92 anchor files now pass asciidoc-linter validation. Co-Authored-By: Claude Sonnet 4.5 --- docs/anchors/_template.adoc | 8 ++- docs/anchors/adr-according-to-nygard.adoc | 27 +++++---- docs/anchors/adr-according-to-nygard.de.adoc | 28 +++++---- docs/anchors/arc42.adoc | 44 +++++++++----- docs/anchors/arc42.de.adoc | 45 +++++++++----- docs/anchors/bem-methodology.adoc | 33 ++++++---- docs/anchors/bem-methodology.de.adoc | 33 ++++++---- docs/anchors/bluf.adoc | 24 +++++--- docs/anchors/bluf.de.adoc | 24 +++++--- docs/anchors/c4-diagrams.adoc | 24 +++++--- docs/anchors/c4-diagrams.de.adoc | 24 +++++--- docs/anchors/chain-of-thought.adoc | 24 +++++--- docs/anchors/chain-of-thought.de.adoc | 24 +++++--- docs/anchors/clean-architecture.adoc | 27 ++++++--- docs/anchors/clean-architecture.de.adoc | 27 ++++++--- docs/anchors/control-chart-shewhart.adoc | 46 ++++++++------ docs/anchors/control-chart-shewhart.de.adoc | 46 ++++++++------ docs/anchors/conventional-commits.adoc | 20 ++++--- docs/anchors/conventional-commits.de.adoc | 20 ++++--- docs/anchors/cynefin-framework.adoc | 29 +++++---- docs/anchors/cynefin-framework.de.adoc | 29 +++++---- docs/anchors/devils-advocate.adoc | 24 +++++--- docs/anchors/devils-advocate.de.adoc | 24 +++++--- docs/anchors/diataxis-framework.adoc | 31 ++++++---- docs/anchors/diataxis-framework.de.adoc | 31 ++++++---- docs/anchors/docs-as-code.adoc | 27 ++++++--- docs/anchors/docs-as-code.de.adoc | 27 ++++++--- docs/anchors/domain-driven-design.adoc | 30 ++++++---- docs/anchors/domain-driven-design.de.adoc | 30 ++++++---- docs/anchors/dry-principle.adoc | 21 ++++--- docs/anchors/dry-principle.de.adoc | 21 ++++--- docs/anchors/ears-requirements.adoc | 21 ++++--- docs/anchors/ears-requirements.de.adoc | 21 ++++--- docs/anchors/feynman-technique.adoc | 32 ++++++---- docs/anchors/feynman-technique.de.adoc | 32 ++++++---- docs/anchors/five-whys.adoc | 24 +++++--- docs/anchors/five-whys.de.adoc | 24 +++++--- docs/anchors/hexagonal-architecture.adoc | 27 ++++++--- docs/anchors/hexagonal-architecture.de.adoc | 27 ++++++--- docs/anchors/iec-61508-sil-levels.adoc | 39 +++++++----- docs/anchors/impact-mapping.adoc | 27 ++++++--- docs/anchors/impact-mapping.de.adoc | 27 ++++++--- docs/anchors/jobs-to-be-done.adoc | 27 ++++++--- docs/anchors/jobs-to-be-done.de.adoc | 27 ++++++--- docs/anchors/madr.adoc | 37 +++++++----- docs/anchors/madr.de.adoc | 37 +++++++----- docs/anchors/mece.adoc | 24 +++++--- docs/anchors/mece.de.adoc | 24 +++++--- .../mental-model-according-to-naur.adoc | 27 ++++++--- .../mental-model-according-to-naur.de.adoc | 27 ++++++--- docs/anchors/morphological-box.adoc | 24 +++++--- docs/anchors/mutation-testing.adoc | 60 ++++++++++++------- docs/anchors/mutation-testing.de.adoc | 60 ++++++++++++------- docs/anchors/nelson-rules.adoc | 42 ++++++++----- docs/anchors/nelson-rules.de.adoc | 42 ++++++++----- docs/anchors/problem-space-nvc.adoc | 21 ++++--- docs/anchors/problem-space-nvc.de.adoc | 21 ++++--- docs/anchors/property-based-testing.adoc | 27 ++++++--- docs/anchors/property-based-testing.de.adoc | 27 ++++++--- docs/anchors/pugh-matrix.adoc | 21 ++++--- docs/anchors/pugh-matrix.de.adoc | 21 ++++--- docs/anchors/pyramid-principle.adoc | 27 ++++++--- docs/anchors/pyramid-principle.de.adoc | 27 ++++++--- docs/anchors/rubber-duck-debugging.adoc | 24 +++++--- docs/anchors/rubber-duck-debugging.de.adoc | 24 +++++--- docs/anchors/semantic-versioning.adoc | 24 +++++--- docs/anchors/semantic-versioning.de.adoc | 24 +++++--- docs/anchors/socratic-method.adoc | 27 ++++++--- docs/anchors/socratic-method.de.adoc | 27 ++++++--- docs/anchors/solid-principles.adoc | 15 +++-- docs/anchors/solid-principles.de.adoc | 15 +++-- docs/anchors/sota.adoc | 21 ++++--- docs/anchors/sota.de.adoc | 21 ++++--- docs/anchors/spc.adoc | 42 ++++++++----- docs/anchors/spc.de.adoc | 42 ++++++++----- docs/anchors/spot-principle.adoc | 21 ++++--- docs/anchors/spot-principle.de.adoc | 21 ++++--- docs/anchors/ssot-principle.adoc | 24 +++++--- docs/anchors/ssot-principle.de.adoc | 24 +++++--- docs/anchors/tdd-chicago-school.adoc | 18 ++++-- docs/anchors/tdd-chicago-school.de.adoc | 18 ++++-- docs/anchors/tdd-london-school.adoc | 18 ++++-- docs/anchors/tdd-london-school.de.adoc | 18 ++++-- docs/anchors/testing-pyramid.adoc | 27 +++++---- docs/anchors/testing-pyramid.de.adoc | 27 +++++---- docs/anchors/timtowtdi.adoc | 24 +++++--- docs/anchors/timtowtdi.de.adoc | 24 +++++--- docs/anchors/todotxt-flavoured-markdown.adoc | 27 ++++++--- .../todotxt-flavoured-markdown.de.adoc | 27 ++++++--- docs/anchors/user-story-mapping.adoc | 27 ++++++--- docs/anchors/user-story-mapping.de.adoc | 27 ++++++--- docs/anchors/wardley-mapping.adoc | 30 ++++++---- docs/anchors/wardley-mapping.de.adoc | 30 ++++++---- .../what-qualifies-as-a-semantic-anchor.adoc | 30 ++++++---- ...hat-qualifies-as-a-semantic-anchor.de.adoc | 30 ++++++---- 95 files changed, 1710 insertions(+), 911 deletions(-) diff --git a/docs/anchors/_template.adoc b/docs/anchors/_template.adoc index f342d90..794d288 100644 --- a/docs/anchors/_template.adoc +++ b/docs/anchors/_template.adoc @@ -11,9 +11,11 @@ Also known as:: Alternative Name, Other Name *Core Concepts*: -* Concept 1 -* Concept 2 -* Concept 3 +Concept 1:: Brief description of concept 1 + +Concept 2:: Brief description of concept 2 + +Concept 3:: Brief description of concept 3 Key Proponents:: Author Name ("Book Title"), Another Author diff --git a/docs/anchors/adr-according-to-nygard.adoc b/docs/anchors/adr-according-to-nygard.adoc index 6c8a3af..68ad7ee 100644 --- a/docs/anchors/adr-according-to-nygard.adoc +++ b/docs/anchors/adr-according-to-nygard.adoc @@ -8,17 +8,22 @@ Full Name:: Architecture Decision Records according to Michael Nygard *Core Concepts*: -* *Lightweight documentation*: Short, focused records -* *Standard structure*: -** Title -** Status (proposed, accepted, deprecated, superseded) -** Context (forces at play) -** Decision (what was chosen) -** Consequences (both positive and negative) -* *Immutability*: ADRs are never deleted, only superseded -* *Version control*: ADRs stored with code -* *Decision archaeology*: Understanding why past decisions were made -* *Evolutionary architecture*: Supporting architecture that changes over time +Lightweight documentation:: Short, focused records + +Standard structure:: +* Title +* Status (proposed, accepted, deprecated, superseded) +* Context (forces at play) +* Decision (what was chosen) +* Consequences (both positive and negative) + +Immutability:: ADRs are never deleted, only superseded + +Version control:: ADRs stored with code + +Decision archaeology:: Understanding why past decisions were made + +Evolutionary architecture:: Supporting architecture that changes over time Key Proponent:: Michael Nygard diff --git a/docs/anchors/adr-according-to-nygard.de.adoc b/docs/anchors/adr-according-to-nygard.de.adoc index 6868e6d..6e02803 100644 --- a/docs/anchors/adr-according-to-nygard.de.adoc +++ b/docs/anchors/adr-according-to-nygard.de.adoc @@ -8,17 +8,23 @@ Vollständiger Name:: Architecture Decision Records nach Michael Nygard *Kernkonzepte*: -* *Leichtgewichtige Dokumentation*: Kurze, fokussierte Aufzeichnungen -* *Standardstruktur*: -** Titel -** Status (vorgeschlagen, akzeptiert, veraltet, ersetzt) -** Kontext (wirkende Kräfte) -** Entscheidung (was gewählt wurde) -** Konsequenzen (sowohl positive als auch negative) -* *Unveränderlichkeit*: ADRs werden nie gelöscht, nur ersetzt -* *Versionskontrolle*: ADRs werden mit Code gespeichert -* *Entscheidungsarchäologie*: Verstehen, warum vergangene Entscheidungen getroffen wurden -* *Evolutionäre Architektur*: Unterstützung von Architektur, die sich im Laufe der Zeit ändert +Leichtgewichtige Dokumentation:: Kurze, fokussierte Aufzeichnungen + +Standardstruktur:: +* Titel +* Status (vorgeschlagen, akzeptiert, veraltet, ersetzt) +* Kontext (wirkende Kräfte) +* Entscheidung (was gewählt wurde) +* Konsequenzen (sowohl positive als auch negative) + +Unveränderlichkeit:: ADRs werden nie gelöscht, nur ersetzt + +Versionskontrolle:: ADRs werden mit Code gespeichert + +Entscheidungsarchäologie:: Verstehen, warum vergangene Entscheidungen getroffen wurden + +Evolutionäre Architektur:: Unterstützung von Architektur, die sich im Laufe der Zeit ändert + Schlüsselvertreter:: Michael Nygard diff --git a/docs/anchors/arc42.adoc b/docs/anchors/arc42.adoc index 7c0e4a5..363dbf2 100644 --- a/docs/anchors/arc42.adoc +++ b/docs/anchors/arc42.adoc @@ -9,21 +9,35 @@ Full Name:: arc42 Architecture Documentation Template *Core Concepts*: -* *12 standardized sections*: From introduction to glossary -* *Section 1*: Introduction and Goals -* *Section 2*: Constraints -* *Section 3*: Context and Scope -* *Section 4*: Solution Strategy -* *Section 5*: Building Block View -* *Section 6*: Runtime View -* *Section 7*: Deployment View -* *Section 8*: Crosscutting Concepts -* *Section 9*: Architecture Decisions (ADRs) -* *Section 10*: Quality Requirements -* *Section 11*: Risks and Technical Debt -* *Section 12*: Glossary -* *Pragmatic documentation*: Document only what's necessary -* *Multiple formats*: AsciiDoc, Markdown, Confluence, etc. +12 standardized sections:: From introduction to glossary + +Section 1:: Introduction and Goals + +Section 2:: Constraints + +Section 3:: Context and Scope + +Section 4:: Solution Strategy + +Section 5:: Building Block View + +Section 6:: Runtime View + +Section 7:: Deployment View + +Section 8:: Crosscutting Concepts + +Section 9:: Architecture Decisions (ADRs) + +Section 10:: Quality Requirements + +Section 11:: Risks and Technical Debt + +Section 12:: Glossary + +Pragmatic documentation:: Document only what's necessary + +Multiple formats:: AsciiDoc, Markdown, Confluence, etc. Key Proponents:: Gernot Starke, Peter Hruschka diff --git a/docs/anchors/arc42.de.adoc b/docs/anchors/arc42.de.adoc index ed76934..564686c 100644 --- a/docs/anchors/arc42.de.adoc +++ b/docs/anchors/arc42.de.adoc @@ -9,21 +9,36 @@ Vollständiger Name:: arc42 Architekturdokumentations-Template *Kernkonzepte*: -* *12 standardisierte Abschnitte*: Von Einführung bis Glossar -* *Abschnitt 1*: Einführung und Ziele -* *Abschnitt 2*: Randbedingungen -* *Abschnitt 3*: Kontext und Scope -* *Abschnitt 4*: Lösungsstrategie -* *Abschnitt 5*: Bausteinsicht -* *Abschnitt 6*: Laufzeitsicht -* *Abschnitt 7*: Verteilungssicht -* *Abschnitt 8*: Querschnittliche Konzepte -* *Abschnitt 9*: Architekturentscheidungen -* *Abschnitt 10*: Qualitätsanforderungen -* *Abschnitt 11*: Risiken und technische Schulden -* *Abschnitt 12*: Glossar -* *Pragmatische Dokumentation*: Nur das Notwendige dokumentieren -* *Mehrere Formate*: AsciiDoc, Markdown, Confluence, etc. +12 standardisierte Abschnitte:: Von Einführung bis Glossar + +Abschnitt 1:: Einführung und Ziele + +Abschnitt 2:: Randbedingungen + +Abschnitt 3:: Kontext und Scope + +Abschnitt 4:: Lösungsstrategie + +Abschnitt 5:: Bausteinsicht + +Abschnitt 6:: Laufzeitsicht + +Abschnitt 7:: Verteilungssicht + +Abschnitt 8:: Querschnittliche Konzepte + +Abschnitt 9:: Architekturentscheidungen + +Abschnitt 10:: Qualitätsanforderungen + +Abschnitt 11:: Risiken und technische Schulden + +Abschnitt 12:: Glossar + +Pragmatische Dokumentation:: Nur das Notwendige dokumentieren + +Mehrere Formate:: AsciiDoc, Markdown, Confluence, etc. + Schlüsselvertreter:: Gernot Starke, Peter Hruschka diff --git a/docs/anchors/bem-methodology.adoc b/docs/anchors/bem-methodology.adoc index 01034fb..61a611f 100644 --- a/docs/anchors/bem-methodology.adoc +++ b/docs/anchors/bem-methodology.adoc @@ -9,17 +9,28 @@ Full Name:: Block Element Modifier (BEM) (S)CSS Methodology *Core Concepts*: -* *Motivation*: Solve CSS specificity wars, naming conflicts, and stylesheet maintainability issues in large codebases -* *Block*: Standalone component that is meaningful on its own (e.g., `menu`, `button`, `header`) -* *Element*: Part of a block with no standalone meaning (e.g., `menu__item`, `button__icon`) -* *Modifier*: Flag on blocks or elements that changes appearance or behavior (e.g., `button--disabled`, `menu__item--active`) -* *Naming convention*: `block__element--modifier` structure -* *Independence*: Blocks are self-contained and reusable -* *No cascading*: Avoid deep CSS selectors, use flat structure -* *Explicit relationships*: Clear parent-child relationships through naming -* *Reusability*: Components can be moved anywhere in the project -* *Mix*: Combining multiple BEM entities on a single DOM node -* *File structure*: Often paired with component-based file organization +Motivation:: Solve CSS specificity wars, naming conflicts, and stylesheet maintainability issues in large codebases + +Block:: Standalone component that is meaningful on its own (e.g., `menu`, `button`, `header`) + +Element:: Part of a block with no standalone meaning (e.g., `menu__item`, `button__icon`) + +Modifier:: Flag on blocks or elements that changes appearance or behavior (e.g., `button--disabled`, `menu__item--active`) + +Naming convention:: `block__element--modifier` structure + +Independence:: Blocks are self-contained and reusable + +No cascading:: Avoid deep CSS selectors, use flat structure + +Explicit relationships:: Clear parent-child relationships through naming + +Reusability:: Components can be moved anywhere in the project + +Mix:: Combining multiple BEM entities on a single DOM node + +File structure:: Often paired with component-based file organization + *Naming Examples*: diff --git a/docs/anchors/bem-methodology.de.adoc b/docs/anchors/bem-methodology.de.adoc index 151326f..b32517f 100644 --- a/docs/anchors/bem-methodology.de.adoc +++ b/docs/anchors/bem-methodology.de.adoc @@ -9,17 +9,28 @@ Vollständiger Name:: Block Element Modifier (BEM) (S)CSS-Methodologie *Kernkonzepte*: -* *Motivation*: CSS-Spezifitätskriege, Namenskonflikte und Stylesheet-Wartbarkeitsprobleme in großen Codebasen lösen -* *Block*: Eigenständige Komponente, die für sich allein sinnvoll ist (z.B. `menu`, `button`, `header`) -* *Element*: Teil eines Blocks ohne eigenständige Bedeutung (z.B. `menu__item`, `button__icon`) -* *Modifier*: Kennzeichen auf Blöcken oder Elementen, das Aussehen oder Verhalten ändert (z.B. `button--disabled`, `menu__item--active`) -* *Namenskonvention*: `block__element--modifier` Struktur -* *Unabhängigkeit*: Blöcke sind eigenständig und wiederverwendbar -* *Kein Cascading*: Tiefe CSS-Selektoren vermeiden, flache Struktur verwenden -* *Explizite Beziehungen*: Klare Eltern-Kind-Beziehungen durch Benennung -* *Wiederverwendbarkeit*: Komponenten können überall im Projekt verschoben werden -* *Mix*: Kombination mehrerer BEM-Entitäten auf einem einzigen DOM-Knoten -* *Dateistruktur*: Oft gepaart mit komponentenbasierter Dateiorganisation +Motivation:: CSS-Spezifitätskriege, Namenskonflikte und Stylesheet-Wartbarkeitsprobleme in großen Codebasen lösen + +Block:: Eigenständige Komponente, die für sich allein sinnvoll ist (z.B. `menu`, `button`, `header`) + +Element:: Teil eines Blocks ohne eigenständige Bedeutung (z.B. `menu__item`, `button__icon`) + +Modifier:: Kennzeichen auf Blöcken oder Elementen, das Aussehen oder Verhalten ändert (z.B. `button--disabled`, `menu__item--active`) + +Namenskonvention:: `block__element--modifier` Struktur + +Unabhängigkeit:: Blöcke sind eigenständig und wiederverwendbar + +Kein Cascading:: Tiefe CSS-Selektoren vermeiden, flache Struktur verwenden + +Explizite Beziehungen:: Klare Eltern-Kind-Beziehungen durch Benennung + +Wiederverwendbarkeit:: Komponenten können überall im Projekt verschoben werden + +Mix:: Kombination mehrerer BEM-Entitäten auf einem einzigen DOM-Knoten + +Dateistruktur:: Oft gepaart mit komponentenbasierter Dateiorganisation + *Benennungsbeispiele*: diff --git a/docs/anchors/bluf.adoc b/docs/anchors/bluf.adoc index 3cfcc4b..14de93e 100644 --- a/docs/anchors/bluf.adoc +++ b/docs/anchors/bluf.adoc @@ -11,14 +11,22 @@ Also known as:: Direct Answer Format, Conclusion-First Communication *Core Concepts*: -* *Conclusion First*: State the main point, decision, or recommendation immediately -* *Inverted Pyramid*: Most important information first, supporting details follow -* *Action Orientation*: Lead with what needs to happen or what was decided -* *Busy Reader Optimization*: Enable time-pressed readers to get key information instantly -* *Supporting Evidence Follows*: Detailed rationale, data, and background come after the conclusion -* *Scannable Structure*: Clear hierarchy enables readers to stop at their needed depth -* *Clarity Over Suspense*: No narrative buildup or delayed conclusions -* *One Sentence First*: Ideally, the BLUF itself is a single, clear sentence +Conclusion First:: State the main point, decision, or recommendation immediately + +Inverted Pyramid:: Most important information first, supporting details follow + +Action Orientation:: Lead with what needs to happen or what was decided + +Busy Reader Optimization:: Enable time-pressed readers to get key information instantly + +Supporting Evidence Follows:: Detailed rationale, data, and background come after the conclusion + +Scannable Structure:: Clear hierarchy enables readers to stop at their needed depth + +Clarity Over Suspense:: No narrative buildup or delayed conclusions + +One Sentence First:: Ideally, the BLUF itself is a single, clear sentence + Key Proponents:: US Military (Army writing standards), adopted broadly in business and government diff --git a/docs/anchors/bluf.de.adoc b/docs/anchors/bluf.de.adoc index 9b1f5cf..c8e32c6 100644 --- a/docs/anchors/bluf.de.adoc +++ b/docs/anchors/bluf.de.adoc @@ -11,14 +11,22 @@ Auch bekannt als:: Direkte Antwortformat, Schlussfolgerung-zuerst-Kommunikation *Kernkonzepte*: -* *Schlussfolgerung zuerst*: Nennen Sie den Hauptpunkt, die Entscheidung oder Empfehlung sofort -* *Umgekehrte Pyramide*: Wichtigste Information zuerst, unterstützende Details folgen -* *Handlungsorientierung*: Beginnen Sie mit dem, was passieren muss oder was entschieden wurde -* *Optimierung für beschäftigte Leser*: Ermöglicht zeitgepressten Lesern, Schlüsselinformationen sofort zu erfassen -* *Unterstützende Belege folgen*: Detaillierte Begründung, Daten und Hintergrund kommen nach der Schlussfolgerung -* *Scanbare Struktur*: Klare Hierarchie ermöglicht Lesern, an ihrer benötigten Tiefe zu stoppen -* *Klarheit statt Spannung*: Kein narrativer Aufbau oder verzögerte Schlussfolgerungen -* *Ein Satz zuerst*: Idealerweise ist das BLUF selbst ein einzelner, klarer Satz +Schlussfolgerung zuerst:: Nennen Sie den Hauptpunkt, die Entscheidung oder Empfehlung sofort + +Umgekehrte Pyramide:: Wichtigste Information zuerst, unterstützende Details folgen + +Handlungsorientierung:: Beginnen Sie mit dem, was passieren muss oder was entschieden wurde + +Optimierung für beschäftigte Leser:: Ermöglicht zeitgepressten Lesern, Schlüsselinformationen sofort zu erfassen + +Unterstützende Belege folgen:: Detaillierte Begründung, Daten und Hintergrund kommen nach der Schlussfolgerung + +Scanbare Struktur:: Klare Hierarchie ermöglicht Lesern, an ihrer benötigten Tiefe zu stoppen + +Klarheit statt Spannung:: Kein narrativer Aufbau oder verzögerte Schlussfolgerungen + +Ein Satz zuerst:: Idealerweise ist das BLUF selbst ein einzelner, klarer Satz + Schlüsselvertreter:: US-Militär (Army writing standards), weithin in Wirtschaft und Regierung übernommen diff --git a/docs/anchors/c4-diagrams.adoc b/docs/anchors/c4-diagrams.adoc index afa11d2..88d4e72 100644 --- a/docs/anchors/c4-diagrams.adoc +++ b/docs/anchors/c4-diagrams.adoc @@ -8,15 +8,21 @@ Full Name:: C4 Model for Software Architecture Diagrams *Core Concepts*: -* *Four levels of abstraction*: -** *Level 1 - Context*: System in its environment (users, external systems) -** *Level 2 - Container*: Applications and data stores that make up the system -** *Level 3 - Component*: Components within containers -** *Level 4 - Code*: Class diagrams, entity relationships (optional) -* *Zoom in/out*: Progressive disclosure of detail -* *Simple notation*: Boxes and arrows, minimal notation overhead -* *Audience-appropriate*: Different diagrams for different stakeholders -* *Supplementary diagrams*: Deployment, dynamic views, etc. +Four levels of abstraction:: ++ +Level 1 - Context::: System in its environment (users, external systems) +Level 2 - Container::: Applications and data stores that make up the system +Level 3 - Component::: Components within containers +Level 4 - Code::: Class diagrams, entity relationships (optional) + +Zoom in/out:: Progressive disclosure of detail + +Simple notation:: Boxes and arrows, minimal notation overhead + +Audience-appropriate:: Different diagrams for different stakeholders + +Supplementary diagrams:: Deployment, dynamic views, etc. + Key Proponent:: Simon Brown diff --git a/docs/anchors/c4-diagrams.de.adoc b/docs/anchors/c4-diagrams.de.adoc index c9f3c2c..2c2167e 100644 --- a/docs/anchors/c4-diagrams.de.adoc +++ b/docs/anchors/c4-diagrams.de.adoc @@ -8,15 +8,21 @@ Vollständiger Name:: C4-Modell für Software-Architektur-Diagramme *Kernkonzepte*: -* *Vier Abstraktionsebenen*: -** *Ebene 1 - Kontext*: System in seiner Umgebung (Benutzer, externe Systeme) -** *Ebene 2 - Container*: Anwendungen und Datenspeicher, die das System bilden -** *Ebene 3 - Komponente*: Komponenten innerhalb von Containern -** *Ebene 4 - Code*: Klassendiagramme, Entity-Beziehungen (optional) -* *Hinein-/Herauszoomen*: Progressive Detailoffenlegung -* *Einfache Notation*: Kästen und Pfeile, minimaler Notationsaufwand -* *Publikumsgerecht*: Verschiedene Diagramme für verschiedene Stakeholder -* *Ergänzende Diagramme*: Deployment, dynamische Ansichten, etc. +Vier Abstraktionsebenen:: ++ +Ebene 1 - Kontext::: System in seiner Umgebung (Benutzer, externe Systeme) +Ebene 2 - Container::: Anwendungen und Datenspeicher, die das System bilden +Ebene 3 - Komponente::: Komponenten innerhalb von Containern +Ebene 4 - Code::: Klassendiagramme, Entity-Beziehungen (optional) + +Hinein-/Herauszoomen:: Progressive Detailoffenlegung + +Einfache Notation:: Kästen und Pfeile, minimaler Notationsaufwand + +Publikumsgerecht:: Verschiedene Diagramme für verschiedene Stakeholder + +Ergänzende Diagramme:: Deployment, dynamische Ansichten, etc. + Schlüsselvertreter:: Simon Brown diff --git a/docs/anchors/chain-of-thought.adoc b/docs/anchors/chain-of-thought.adoc index a0f3cff..c6abb54 100644 --- a/docs/anchors/chain-of-thought.adoc +++ b/docs/anchors/chain-of-thought.adoc @@ -9,14 +9,22 @@ Full Name:: Chain of Thought Prompting *Core Concepts*: -* *Step-by-Step Reasoning*: Explicitly show intermediate reasoning steps before reaching a conclusion -* *Reasoning Transparency*: Make the thought process visible, not just the final answer -* *Intermediate Representations*: Break complex problems into smaller, manageable steps -* *Error Reduction*: Exposing reasoning allows detection of logical errors mid-process -* *Complex Task Decomposition*: Handle multi-step problems that cannot be solved in one jump -* *Zero-Shot CoT*: Simple prompt like "Let's think step by step" to trigger CoT behavior -* *Few-Shot CoT*: Provide examples with reasoning chains to guide the model -* *Self-Consistency*: Generate multiple reasoning paths and select most consistent answer +Step-by-Step Reasoning:: Explicitly show intermediate reasoning steps before reaching a conclusion + +Reasoning Transparency:: Make the thought process visible, not just the final answer + +Intermediate Representations:: Break complex problems into smaller, manageable steps + +Error Reduction:: Exposing reasoning allows detection of logical errors mid-process + +Complex Task Decomposition:: Handle multi-step problems that cannot be solved in one jump + +Zero-Shot CoT:: Simple prompt like "Let's think step by step" to trigger CoT behavior + +Few-Shot CoT:: Provide examples with reasoning chains to guide the model + +Self-Consistency:: Generate multiple reasoning paths and select most consistent answer + Key Proponents:: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" diff --git a/docs/anchors/chain-of-thought.de.adoc b/docs/anchors/chain-of-thought.de.adoc index 4870d41..007dc6d 100644 --- a/docs/anchors/chain-of-thought.de.adoc +++ b/docs/anchors/chain-of-thought.de.adoc @@ -9,14 +9,22 @@ Vollständiger Name:: Chain of Thought Prompting (Gedankenketten-Prompting) *Kernkonzepte*: -* *Schrittweises Denken*: Zwischenschritte des Denkprozesses explizit zeigen, bevor eine Schlussfolgerung erreicht wird -* *Transparente Argumentation*: Den Denkprozess sichtbar machen, nicht nur die endgültige Antwort -* *Zwischenrepräsentationen*: Komplexe Probleme in kleinere, handhabbare Schritte zerlegen -* *Fehlerreduzierung*: Offengelegtes Denken ermöglicht Erkennung logischer Fehler im Prozess -* *Zerlegung komplexer Aufgaben*: Mehrstufige Probleme bewältigen, die nicht in einem Schritt gelöst werden können -* *Zero-Shot CoT*: Einfacher Prompt wie "Lass uns Schritt für Schritt denken" löst CoT-Verhalten aus -* *Few-Shot CoT*: Beispiele mit Argumentationsketten bereitstellen, um das Modell zu leiten -* *Selbstkonsistenz*: Mehrere Argumentationspfade generieren und konsistenteste Antwort wählen +Schrittweises Denken:: Zwischenschritte des Denkprozesses explizit zeigen, bevor eine Schlussfolgerung erreicht wird + +Transparente Argumentation:: Den Denkprozess sichtbar machen, nicht nur die endgültige Antwort + +Zwischenrepräsentationen:: Komplexe Probleme in kleinere, handhabbare Schritte zerlegen + +Fehlerreduzierung:: Offengelegtes Denken ermöglicht Erkennung logischer Fehler im Prozess + +Zerlegung komplexer Aufgaben:: Mehrstufige Probleme bewältigen, die nicht in einem Schritt gelöst werden können + +Zero-Shot CoT:: Einfacher Prompt wie "Lass uns Schritt für Schritt denken" löst CoT-Verhalten aus + +Few-Shot CoT:: Beispiele mit Argumentationsketten bereitstellen, um das Modell zu leiten + +Selbstkonsistenz:: Mehrere Argumentationspfade generieren und konsistenteste Antwort wählen + Schlüsselvertreter:: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" diff --git a/docs/anchors/clean-architecture.adoc b/docs/anchors/clean-architecture.adoc index 7b56908..6d7a07c 100644 --- a/docs/anchors/clean-architecture.adoc +++ b/docs/anchors/clean-architecture.adoc @@ -8,15 +8,24 @@ Full Name:: Clean Architecture according to Robert C. Martin *Core Concepts*: -* *The Dependency Rule*: Dependencies only point inward -* *Concentric circles*: Entities → Use Cases → Interface Adapters → Frameworks & Drivers -* *Independent of frameworks*: Architecture doesn't depend on libraries -* *Testable*: Business rules testable without UI, database, or external elements -* *Independent of UI*: UI can change without changing business rules -* *Independent of database*: Business rules not bound to database -* *Independent of external agencies*: Business rules don't know about outside world -* *Screaming Architecture*: Architecture reveals the intent of the system -* *SOLID principles*: Foundation of the architecture +The Dependency Rule:: Dependencies only point inward + +Concentric circles:: Entities → Use Cases → Interface Adapters → Frameworks & Drivers + +Independent of frameworks:: Architecture doesn't depend on libraries + +Testable:: Business rules testable without UI, database, or external elements + +Independent of UI:: UI can change without changing business rules + +Independent of database:: Business rules not bound to database + +Independent of external agencies:: Business rules don't know about outside world + +Screaming Architecture:: Architecture reveals the intent of the system + +SOLID principles:: Foundation of the architecture + Key Proponent:: Robert C. Martin ("Uncle Bob") diff --git a/docs/anchors/clean-architecture.de.adoc b/docs/anchors/clean-architecture.de.adoc index a06aa0b..8c8f6bc 100644 --- a/docs/anchors/clean-architecture.de.adoc +++ b/docs/anchors/clean-architecture.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: Clean Architecture nach Robert C. Martin *Kernkonzepte*: -* *Die Abhängigkeitsregel*: Abhängigkeiten zeigen nur nach innen -* *Konzentrische Kreise*: Entities → Use Cases → Interface Adapters → Frameworks & Drivers -* *Unabhängig von Frameworks*: Architektur hängt nicht von Bibliotheken ab -* *Testbar*: Geschäftsregeln testbar ohne UI, Datenbank oder externe Elemente -* *Unabhängig von UI*: UI kann sich ändern, ohne Geschäftsregeln zu ändern -* *Unabhängig von Datenbank*: Geschäftsregeln nicht an Datenbank gebunden -* *Unabhängig von externen Stellen*: Geschäftsregeln wissen nichts über die Außenwelt -* *Screaming Architecture*: Architektur offenbart die Absicht des Systems -* *SOLID-Prinzipien*: Grundlage der Architektur +Die Abhängigkeitsregel:: Abhängigkeiten zeigen nur nach innen + +Konzentrische Kreise:: Entities → Use Cases → Interface Adapters → Frameworks & Drivers + +Unabhängig von Frameworks:: Architektur hängt nicht von Bibliotheken ab + +Testbar:: Geschäftsregeln testbar ohne UI, Datenbank oder externe Elemente + +Unabhängig von UI:: UI kann sich ändern, ohne Geschäftsregeln zu ändern + +Unabhängig von Datenbank:: Geschäftsregeln nicht an Datenbank gebunden + +Unabhängig von externen Stellen:: Geschäftsregeln wissen nichts über die Außenwelt + +Screaming Architecture:: Architektur offenbart die Absicht des Systems + +SOLID-Prinzipien:: Grundlage der Architektur + Schlüsselvertreter:: Robert C. Martin ("Uncle Bob") diff --git a/docs/anchors/control-chart-shewhart.adoc b/docs/anchors/control-chart-shewhart.adoc index 332608b..4e86a35 100644 --- a/docs/anchors/control-chart-shewhart.adoc +++ b/docs/anchors/control-chart-shewhart.adoc @@ -10,20 +10,29 @@ Also known as:: Process Control Chart, SPC Chart *Core Concepts*: -* *Time series diagram*: Measured value plotted over time -* *Centerline (CL)*: Process mean -* *Upper/Lower Control Limit (UCL/LCL)*: Typically at ±3σ from the mean -* *Zones A/B/C*: Division into 6 areas (each 1σ wide) for pattern recognition -* *Common Cause Variation*: Inherent, random fluctuation of a stable process -* *Special Cause Variation*: Assignable, correctable deviation -* *Chart Types*: -** X-bar Chart: Subgroup means -** R-Chart: Subgroup ranges -** I-MR Chart: Individual values and moving range -** p-Chart: Defect proportions -** c-Chart: Defect counts per unit -* *In-Control vs. Out-of-Control*: Core decision based on rules (Nelson, Western Electric) -* *Normal distribution assumption*: Control limits are based on normally distributed data +Time series diagram:: Measured value plotted over time + +Centerline (CL):: Process mean + +Upper/Lower Control Limit (UCL/LCL):: Typically at ±3σ from the mean + +Zones A/B/C:: Division into 6 areas (each 1σ wide) for pattern recognition + +Common Cause Variation:: Inherent, random fluctuation of a stable process + +Special Cause Variation:: Assignable, correctable deviation + +Chart Types:: +* X-bar Chart: Subgroup means +* R-Chart: Subgroup ranges +* I-MR Chart: Individual values and moving range +* p-Chart: Defect proportions +* c-Chart: Defect counts per unit + +In-Control vs. Out-of-Control:: Core decision based on rules (Nelson, Western Electric) + +Normal distribution assumption:: Control limits are based on normally distributed data + Key Proponent:: Walter A. Shewhart (1920s, Bell Labs / Western Electric) @@ -31,9 +40,12 @@ Key Work:: "Economic Control of Quality of Manufactured Product" (1931) *Relationship to Other Anchors*: -* *Nelson Rules*: 8 rules for pattern recognition on Control Charts -* *<>*: Control Charts are the central tool of Statistical Process Control -* *Six Sigma*: Control Charts are used in the Control phase of DMAIC +Nelson Rules:: 8 rules for pattern recognition on Control Charts + +<>:: Control Charts are the central tool of Statistical Process Control + +Six Sigma:: Control Charts are used in the Control phase of DMAIC + *When to Use*: diff --git a/docs/anchors/control-chart-shewhart.de.adoc b/docs/anchors/control-chart-shewhart.de.adoc index c494bce..9c4fd19 100644 --- a/docs/anchors/control-chart-shewhart.de.adoc +++ b/docs/anchors/control-chart-shewhart.de.adoc @@ -10,20 +10,29 @@ Auch bekannt als:: Prozesskontrollkarte, SPC-Karte *Kernkonzepte*: -* *Zeitreihendiagramm*: Messwert über Zeit aufgetragen -* *Mittellinie (CL)*: Prozessmittelwert -* *Obere/Untere Kontrollgrenze (UCL/LCL)*: Typischerweise bei ±3σ vom Mittelwert -* *Zonen A/B/C*: Aufteilung in 6 Bereiche (jeweils 1σ breit) zur Mustererkennung -* *Variation durch natürliche Ursachen*: Inhärente, zufällige Schwankung eines stabilen Prozesses -* *Variation durch besondere Ursachen*: Zuordenbare, korrigierbare Abweichung -* *Kartentypen*: -** X-bar-Karte: Untergruppenmittelwerte -** R-Karte: Untergruppenbereiche -** I-MR-Karte: Einzelwerte und gleitender Bereich -** p-Karte: Defektanteile -** c-Karte: Defektanzahlen pro Einheit -* *Unter Kontrolle vs. Außer Kontrolle*: Kernentscheidung basierend auf Regeln (Nelson, Western Electric) -* *Normalverteilungsannahme*: Kontrollgrenzen basieren auf normalverteilten Daten +Zeitreihendiagramm:: Messwert über Zeit aufgetragen + +Mittellinie (CL):: Prozessmittelwert + +Obere/Untere Kontrollgrenze (UCL/LCL):: Typischerweise bei ±3σ vom Mittelwert + +Zonen A/B/C:: Aufteilung in 6 Bereiche (jeweils 1σ breit) zur Mustererkennung + +Variation durch natürliche Ursachen:: Inhärente, zufällige Schwankung eines stabilen Prozesses + +Variation durch besondere Ursachen:: Zuordenbare, korrigierbare Abweichung + +Kartentypen:: +* X-bar-Karte: Untergruppenmittelwerte +* R-Karte: Untergruppenbereiche +* I-MR-Karte: Einzelwerte und gleitender Bereich +* p-Karte: Defektanteile +* c-Karte: Defektanzahlen pro Einheit + +Unter Kontrolle vs. Außer Kontrolle:: Kernentscheidung basierend auf Regeln (Nelson, Western Electric) + +Normalverteilungsannahme:: Kontrollgrenzen basieren auf normalverteilten Daten + Schlüsselvertreter:: Walter A. Shewhart (1920er, Bell Labs / Western Electric) @@ -31,9 +40,12 @@ Schlüsselwerk:: "Economic Control of Quality of Manufactured Product" (1931) *Beziehung zu anderen Ankern*: -* *Nelson Rules*: 8 Regeln zur Mustererkennung auf Regelkarten -* *<>*: Regelkarten sind das zentrale Werkzeug der statistischen Prozesskontrolle -* *Six Sigma*: Regelkarten werden in der Kontrollphase von DMAIC verwendet +Nelson Rules:: 8 Regeln zur Mustererkennung auf Regelkarten + +<>:: Regelkarten sind das zentrale Werkzeug der statistischen Prozesskontrolle + +Six Sigma:: Regelkarten werden in der Kontrollphase von DMAIC verwendet + *Wann zu verwenden*: diff --git a/docs/anchors/conventional-commits.adoc b/docs/anchors/conventional-commits.adoc index fe2651d..e03e7d6 100644 --- a/docs/anchors/conventional-commits.adoc +++ b/docs/anchors/conventional-commits.adoc @@ -9,15 +9,17 @@ * A specification for adding human and machine readable meaning to commit messages * Determining a semantic version bump (based on the types of commits landed) * Communicating the nature of changes to teammates, the public, and other stakeholders -* *Schema*: [!][(optional scope)]: + optional body/footer -* *Common Types*: -** *feat:* - introduce new feature to the codebase (-> Semver Minor) -** *fix:* - patches a bug in your codebase (-> SemVer Patch) -** *docs:* - documentation improvements to the codebase -** *chore:* - codebase/repository housekeeping changes -** *style:* - formatting changes that do not affect the meaning of the code -** *refactor:* - implementation changes that do not affect the meaning of the code -** *!* - BREAKING CHANGE (-> SemVer Major) +Schema:: [!][(optional scope)]: + optional body/footer + +Common Types:: +* *feat:* - introduce new feature to the codebase (-> Semver Minor) +* *fix:* - patches a bug in your codebase (-> SemVer Patch) +* *docs:* - documentation improvements to the codebase +* *chore:* - codebase/repository housekeeping changes +* *style:* - formatting changes that do not affect the meaning of the code +* *refactor:* - implementation changes that do not affect the meaning of the code +* *!* - BREAKING CHANGE (-> SemVer Major) + * *BREAKING CHANGE:* introduces a breaking API change Key Proponents:: Benjamin E. Coe, James J. Womack, Steve Mao diff --git a/docs/anchors/conventional-commits.de.adoc b/docs/anchors/conventional-commits.de.adoc index 26c1e7a..668a552 100644 --- a/docs/anchors/conventional-commits.de.adoc +++ b/docs/anchors/conventional-commits.de.adoc @@ -9,15 +9,17 @@ * Eine Spezifikation zum Hinzufügen von menschen- und maschinenlesbarer Bedeutung zu Commit-Nachrichten * Bestimmung eines semantischen Versions-Bumps (basierend auf den Arten von gelandeten Commits) * Kommunikation der Art von Änderungen an Teamkollegen, die Öffentlichkeit und andere Stakeholder -* *Schema*: [!][(optional scope)]: + optionaler Body/Footer -* *Häufige Typen*: -** *feat:* - neue Funktion in die Codebase einführen (-> Semver Minor) -** *fix:* - einen Bug in Ihrer Codebase beheben (-> SemVer Patch) -** *docs:* - Dokumentationsverbesserungen an der Codebase -** *chore:* - Codebase/Repository-Wartungsänderungen -** *style:* - Formatierungsänderungen, die die Bedeutung des Codes nicht beeinflussen -** *refactor:* - Implementierungsänderungen, die die Bedeutung des Codes nicht beeinflussen -** *!* - BREAKING CHANGE (-> SemVer Major) +Schema:: [!][(optional scope)]: + optionaler Body/Footer + +Häufige Typen:: +* *feat:* - neue Funktion in die Codebase einführen (-> Semver Minor) +* *fix:* - einen Bug in Ihrer Codebase beheben (-> SemVer Patch) +* *docs:* - Dokumentationsverbesserungen an der Codebase +* *chore:* - Codebase/Repository-Wartungsänderungen +* *style:* - Formatierungsänderungen, die die Bedeutung des Codes nicht beeinflussen +* *refactor:* - Implementierungsänderungen, die die Bedeutung des Codes nicht beeinflussen +* *!* - BREAKING CHANGE (-> SemVer Major) + * *BREAKING CHANGE:* führt eine Breaking API-Änderung ein Schlüsselvertreter:: Benjamin E. Coe, James J. Womack, Steve Mao diff --git a/docs/anchors/cynefin-framework.adoc b/docs/anchors/cynefin-framework.adoc index b2c2abe..8a21f2a 100644 --- a/docs/anchors/cynefin-framework.adoc +++ b/docs/anchors/cynefin-framework.adoc @@ -8,17 +8,24 @@ Full Name:: Cynefin Framework according to Dave Snowden *Core Concepts*: -* *Five domains*: -** *Clear* (formerly "Simple"): Best practices apply, sense-categorize-respond -** *Complicated*: Good practices exist, sense-analyze-respond -** *Complex*: Emergent practices, probe-sense-respond -** *Chaotic*: Novel practices needed, act-sense-respond -** *Confused* (center): Don't know which domain you're in -* *Domain transitions*: How situations move between domains -* *Safe-to-fail probes*: Experiments in complex domain -* *Complacency risk*: Moving from clear to chaotic -* *Decision-making context*: Different domains require different approaches -* *Facilitation tool*: Helps teams discuss and categorize challenges +Five domains:: ++ +Clear (formerly "Simple")::: Best practices apply, sense-categorize-respond +Complicated::: Good practices exist, sense-analyze-respond +Complex::: Emergent practices, probe-sense-respond +Chaotic::: Novel practices needed, act-sense-respond +Confused (center)::: Don't know which domain you're in + +Domain transitions:: How situations move between domains + +Safe-to-fail probes:: Experiments in complex domain + +Complacency risk:: Moving from clear to chaotic + +Decision-making context:: Different domains require different approaches + +Facilitation tool:: Helps teams discuss and categorize challenges + Key Proponent:: Dave Snowden (1999) diff --git a/docs/anchors/cynefin-framework.de.adoc b/docs/anchors/cynefin-framework.de.adoc index 32567d4..1c7c973 100644 --- a/docs/anchors/cynefin-framework.de.adoc +++ b/docs/anchors/cynefin-framework.de.adoc @@ -8,17 +8,24 @@ Vollständiger Name:: Cynefin Framework nach Dave Snowden *Kernkonzepte*: -* *Fünf Domänen*: -** *Klar* (früher "Einfach"): Best Practices gelten, wahrnehmen-kategorisieren-reagieren -** *Kompliziert*: Gute Praktiken existieren, wahrnehmen-analysieren-reagieren -** *Komplex*: Emergente Praktiken, untersuchen-wahrnehmen-reagieren -** *Chaotisch*: Neuartige Praktiken erforderlich, handeln-wahrnehmen-reagieren -** *Verwirrt* (Mitte): Nicht wissen, in welcher Domäne man sich befindet -* *Domänenübergänge*: Wie Situationen sich zwischen Domänen bewegen -* *Sichere-zum-Scheitern-Sonden*: Experimente in komplexer Domäne -* *Selbstzufriedenheitsrisiko*: Übergang von klar zu chaotisch -* *Entscheidungskontext*: Verschiedene Domänen erfordern verschiedene Ansätze -* *Facilitierungs-Tool*: Hilft Teams, Herausforderungen zu diskutieren und zu kategorisieren +Fünf Domänen:: ++ +Klar (früher "Einfach")::: Best Practices gelten, wahrnehmen-kategorisieren-reagieren +Kompliziert::: Gute Praktiken existieren, wahrnehmen-analysieren-reagieren +Komplex::: Emergente Praktiken, untersuchen-wahrnehmen-reagieren +Chaotisch::: Neuartige Praktiken erforderlich, handeln-wahrnehmen-reagieren +Verwirrt (Mitte)::: Nicht wissen, in welcher Domäne man sich befindet + +Domänenübergänge:: Wie Situationen sich zwischen Domänen bewegen + +Sichere-zum-Scheitern-Sonden:: Experimente in komplexer Domäne + +Selbstzufriedenheitsrisiko:: Übergang von klar zu chaotisch + +Entscheidungskontext:: Verschiedene Domänen erfordern verschiedene Ansätze + +Facilitierungs-Tool:: Hilft Teams, Herausforderungen zu diskutieren und zu kategorisieren + Schlüsselvertreter:: Dave Snowden (1999) diff --git a/docs/anchors/devils-advocate.adoc b/docs/anchors/devils-advocate.adoc index bb627d1..99b1c60 100644 --- a/docs/anchors/devils-advocate.adoc +++ b/docs/anchors/devils-advocate.adoc @@ -8,14 +8,22 @@ Full Name:: Devil's Advocate (Latin: *Advocatus Diaboli*) *Core Concepts*: -* *Systematic Counter-Argumentation*: Present opposing viewpoints even if not personally held -* *Assumption Challenging*: Question premises and surface hidden assumptions -* *Stress-Testing Ideas*: Identify weaknesses before they become problems -* *Steelmanning*: Present the *strongest* version of the opposing argument, not a strawman -* *Intellectual Honesty*: Separate idea evaluation from ego or political concerns -* *Pre-Mortem Thinking*: Imagine failure scenarios to prevent them -* *Dialectical Reasoning*: Thesis + Antithesis → Synthesis -* *Risk Identification*: Surface potential problems proactively +Systematic Counter-Argumentation:: Present opposing viewpoints even if not personally held + +Assumption Challenging:: Question premises and surface hidden assumptions + +Stress-Testing Ideas:: Identify weaknesses before they become problems + +Steelmanning:: Present the *strongest* version of the opposing argument, not a strawman + +Intellectual Honesty:: Separate idea evaluation from ego or political concerns + +Pre-Mortem Thinking:: Imagine failure scenarios to prevent them + +Dialectical Reasoning:: Thesis + Antithesis → Synthesis + +Risk Identification:: Surface potential problems proactively + Key Origin:: Catholic Church canonization process (Promotor Fidei role, formalized 1587), secularized in critical thinking and decision-making diff --git a/docs/anchors/devils-advocate.de.adoc b/docs/anchors/devils-advocate.de.adoc index ea0ee45..8d68c6f 100644 --- a/docs/anchors/devils-advocate.de.adoc +++ b/docs/anchors/devils-advocate.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: Advocatus Diaboli (Anwalt des Teufels) *Kernkonzepte*: -* *Systematische Gegenargumentation*: Gegensätzliche Standpunkte präsentieren, auch wenn nicht persönlich vertreten -* *Annahmen hinterfragen*: Prämissen in Frage stellen und versteckte Annahmen aufdecken -* *Ideen unter Stress testen*: Schwächen identifizieren, bevor sie zu Problemen werden -* *Steelmanning*: Die *stärkste* Version des gegensätzlichen Arguments präsentieren, keinen Strohmann -* *Intellektuelle Ehrlichkeit*: Ideenbewertung von Ego oder politischen Bedenken trennen -* *Pre-Mortem-Denken*: Fehlszenarien vorstellen, um sie zu verhindern -* *Dialektisches Denken*: These + Antithese → Synthese -* *Risikoidentifikation*: Potenzielle Probleme proaktiv aufdecken +Systematische Gegenargumentation:: Gegensätzliche Standpunkte präsentieren, auch wenn nicht persönlich vertreten + +Annahmen hinterfragen:: Prämissen in Frage stellen und versteckte Annahmen aufdecken + +Ideen unter Stress testen:: Schwächen identifizieren, bevor sie zu Problemen werden + +Steelmanning:: Die *stärkste* Version des gegensätzlichen Arguments präsentieren, keinen Strohmann + +Intellektuelle Ehrlichkeit:: Ideenbewertung von Ego oder politischen Bedenken trennen + +Pre-Mortem-Denken:: Fehlszenarien vorstellen, um sie zu verhindern + +Dialektisches Denken:: These + Antithese → Synthese + +Risikoidentifikation:: Potenzielle Probleme proaktiv aufdecken + Schlüsselursprung:: Katholische Kirche Kanonisierungsprozess (Promotor-Fidei-Rolle, formalisiert 1587), säkularisiert in kritischem Denken und Entscheidungsfindung diff --git a/docs/anchors/diataxis-framework.adoc b/docs/anchors/diataxis-framework.adoc index 8649192..64570e8 100644 --- a/docs/anchors/diataxis-framework.adoc +++ b/docs/anchors/diataxis-framework.adoc @@ -8,18 +8,25 @@ Full Name:: Diátaxis Documentation Framework according to Daniele Procida *Core Concepts*: -* *Four documentation types*: -** *Tutorials*: Learning-oriented, lessons for beginners -** *How-to guides*: Task-oriented, directions for specific goals -** *Reference*: Information-oriented, technical descriptions -** *Explanation*: Understanding-oriented, conceptual discussions -* *Two dimensions*: -** Practical vs. Theoretical -** Acquisition (learning) vs. Application (working) -* *Separation of concerns*: Each type serves a distinct purpose -* *User needs*: Different users need different documentation at different times -* *Quality criteria*: Each type has specific quality indicators -* *Systematic approach*: Framework for organizing any documentation +Four documentation types:: ++ +Tutorials::: Learning-oriented, lessons for beginners +How-to guides::: Task-oriented, directions for specific goals +Reference::: Information-oriented, technical descriptions +Explanation::: Understanding-oriented, conceptual discussions + +Two dimensions:: +* Practical vs. Theoretical +* Acquisition (learning) vs. Application (working) + +Separation of concerns:: Each type serves a distinct purpose + +User needs:: Different users need different documentation at different times + +Quality criteria:: Each type has specific quality indicators + +Systematic approach:: Framework for organizing any documentation + Key Proponent:: Daniele Procida diff --git a/docs/anchors/diataxis-framework.de.adoc b/docs/anchors/diataxis-framework.de.adoc index 60ba301..4eb5653 100644 --- a/docs/anchors/diataxis-framework.de.adoc +++ b/docs/anchors/diataxis-framework.de.adoc @@ -8,18 +8,25 @@ Vollständiger Name:: Diátaxis Dokumentations-Framework nach Daniele Procida *Kernkonzepte*: -* *Vier Dokumentationstypen*: -** *Tutorials*: Lernorientiert, Lektionen für Anfänger -** *How-to-Guides*: Aufgabenorientiert, Anleitungen für spezifische Ziele -** *Referenz*: Informationsorientiert, technische Beschreibungen -** *Erklärung*: Verständnisorientiert, konzeptionelle Diskussionen -* *Zwei Dimensionen*: -** Praktisch vs. Theoretisch -** Aneignung (Lernen) vs. Anwendung (Arbeiten) -* *Separation of Concerns*: Jeder Typ dient einem eigenen Zweck -* *Nutzerbedürfnisse*: Verschiedene Nutzer benötigen verschiedene Dokumentation zu verschiedenen Zeiten -* *Qualitätskriterien*: Jeder Typ hat spezifische Qualitätsindikatoren -* *Systematischer Ansatz*: Framework zur Organisation jeglicher Dokumentation +Vier Dokumentationstypen:: ++ +Tutorials::: Lernorientiert, Lektionen für Anfänger +How-to-Guides::: Aufgabenorientiert, Anleitungen für spezifische Ziele +Referenz::: Informationsorientiert, technische Beschreibungen +Erklärung::: Verständnisorientiert, konzeptionelle Diskussionen + +Zwei Dimensionen:: +* Praktisch vs. Theoretisch +* Aneignung (Lernen) vs. Anwendung (Arbeiten) + +Separation of Concerns:: Jeder Typ dient einem eigenen Zweck + +Nutzerbedürfnisse:: Verschiedene Nutzer benötigen verschiedene Dokumentation zu verschiedenen Zeiten + +Qualitätskriterien:: Jeder Typ hat spezifische Qualitätsindikatoren + +Systematischer Ansatz:: Framework zur Organisation jeglicher Dokumentation + Schlüsselvertreter:: Daniele Procida diff --git a/docs/anchors/docs-as-code.adoc b/docs/anchors/docs-as-code.adoc index 3b71bfb..d0e735d 100644 --- a/docs/anchors/docs-as-code.adoc +++ b/docs/anchors/docs-as-code.adoc @@ -8,15 +8,24 @@ Full Name:: Docs-as-Code Approach according to Ralf D. Müller *Core Concepts*: -* *Plain text formats*: AsciiDoc, Markdown -* *Version control*: Documentation in Git alongside code -* *Automated toolchains*: Build pipelines for documentation -* *Single source of truth*: Generate multiple output formats from one source -* *Diagrams as code*: PlantUML, Mermaid, Graphviz, Kroki -* *Continuous documentation*: Updated with every commit -* *Developer-friendly*: Use same tools and workflows as for code -* *Review process*: Pull requests for documentation changes -* *Modular documentation*: Includes and composition +Plain text formats:: AsciiDoc, Markdown + +Version control:: Documentation in Git alongside code + +Automated toolchains:: Build pipelines for documentation + +Single source of truth:: Generate multiple output formats from one source + +Diagrams as code:: PlantUML, Mermaid, Graphviz, Kroki + +Continuous documentation:: Updated with every commit + +Developer-friendly:: Use same tools and workflows as for code + +Review process:: Pull requests for documentation changes + +Modular documentation:: Includes and composition + Key Proponent:: Ralf D. Müller (docToolchain creator) diff --git a/docs/anchors/docs-as-code.de.adoc b/docs/anchors/docs-as-code.de.adoc index 46bfab7..bdd3a79 100644 --- a/docs/anchors/docs-as-code.de.adoc +++ b/docs/anchors/docs-as-code.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: Docs-as-Code-Ansatz nach Ralf D. Müller *Kernkonzepte*: -* *Plain-Text-Formate*: AsciiDoc, Markdown -* *Versionskontrolle*: Dokumentation in Git zusammen mit Code -* *Automatisierte Toolchains*: Build-Pipelines für Dokumentation -* *Single Source of Truth*: Mehrere Ausgabeformate aus einer Quelle generieren -* *Diagramme als Code*: PlantUML, Mermaid, Graphviz, Kroki -* *Kontinuierliche Dokumentation*: Mit jedem Commit aktualisiert -* *Entwicklerfreundlich*: Dieselben Tools und Workflows wie für Code verwenden -* *Review-Prozess*: Pull Requests für Dokumentationsänderungen -* *Modulare Dokumentation*: Includes und Komposition +Plain-Text-Formate:: AsciiDoc, Markdown + +Versionskontrolle:: Dokumentation in Git zusammen mit Code + +Automatisierte Toolchains:: Build-Pipelines für Dokumentation + +Single Source of Truth:: Mehrere Ausgabeformate aus einer Quelle generieren + +Diagramme als Code:: PlantUML, Mermaid, Graphviz, Kroki + +Kontinuierliche Dokumentation:: Mit jedem Commit aktualisiert + +Entwicklerfreundlich:: Dieselben Tools und Workflows wie für Code verwenden + +Review-Prozess:: Pull Requests für Dokumentationsänderungen + +Modulare Dokumentation:: Includes und Komposition + Schlüsselvertreter:: Ralf D. Müller (docToolchain-Ersteller) diff --git a/docs/anchors/domain-driven-design.adoc b/docs/anchors/domain-driven-design.adoc index c168b4e..9b665e2 100644 --- a/docs/anchors/domain-driven-design.adoc +++ b/docs/anchors/domain-driven-design.adoc @@ -8,16 +8,26 @@ Full Name:: Domain-Driven Design according to Eric Evans *Core Concepts*: -* *Ubiquitous Language*: Shared vocabulary between developers and domain experts -* *Bounded Context*: Explicit boundaries where a model is defined and applicable -* *Aggregates*: Cluster of domain objects treated as a single unit -* *Entities*: Objects defined by identity, not attributes -* *Value Objects*: Immutable objects defined by their attributes -* *Repositories*: Abstraction for object persistence and retrieval -* *Domain Events*: Significant occurrences in the domain -* *Strategic Design*: Context mapping, anti-corruption layers -* *Tactical Design*: Building blocks (entities, value objects, services) -* *Model-Driven Design*: Code that expresses the domain model +Ubiquitous Language:: Shared vocabulary between developers and domain experts + +Bounded Context:: Explicit boundaries where a model is defined and applicable + +Aggregates:: Cluster of domain objects treated as a single unit + +Entities:: Objects defined by identity, not attributes + +Value Objects:: Immutable objects defined by their attributes + +Repositories:: Abstraction for object persistence and retrieval + +Domain Events:: Significant occurrences in the domain + +Strategic Design:: Context mapping, anti-corruption layers + +Tactical Design:: Building blocks (entities, value objects, services) + +Model-Driven Design:: Code that expresses the domain model + Key Proponent:: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) diff --git a/docs/anchors/domain-driven-design.de.adoc b/docs/anchors/domain-driven-design.de.adoc index 86e146e..bbf97b3 100644 --- a/docs/anchors/domain-driven-design.de.adoc +++ b/docs/anchors/domain-driven-design.de.adoc @@ -8,16 +8,26 @@ Vollständiger Name:: Domain-Driven Design nach Eric Evans *Kernkonzepte*: -* *Ubiquitous Language*: Gemeinsames Vokabular zwischen Entwicklern und Domänenexperten -* *Bounded Context*: Explizite Grenzen, innerhalb derer ein Modell definiert und anwendbar ist -* *Aggregates*: Gruppe von Domänenobjekten, die als Einheit behandelt werden -* *Entities*: Objekte, die durch Identität definiert sind, nicht durch Attribute -* *Value Objects*: Unveränderliche Objekte, die durch ihre Attribute definiert sind -* *Repositories*: Abstraktion für Objektpersistenz und -abruf -* *Domain Events*: Bedeutende Vorkommnisse in der Domäne -* *Strategisches Design*: Context Mapping, Anti-Corruption Layers -* *Taktisches Design*: Bausteine (Entities, Value Objects, Services) -* *Model-Driven Design*: Code, der das Domänenmodell ausdrückt +Ubiquitous Language:: Gemeinsames Vokabular zwischen Entwicklern und Domänenexperten + +Bounded Context:: Explizite Grenzen, innerhalb derer ein Modell definiert und anwendbar ist + +Aggregates:: Gruppe von Domänenobjekten, die als Einheit behandelt werden + +Entities:: Objekte, die durch Identität definiert sind, nicht durch Attribute + +Value Objects:: Unveränderliche Objekte, die durch ihre Attribute definiert sind + +Repositories:: Abstraktion für Objektpersistenz und -abruf + +Domain Events:: Bedeutende Vorkommnisse in der Domäne + +Strategisches Design:: Context Mapping, Anti-Corruption Layers + +Taktisches Design:: Bausteine (Entities, Value Objects, Services) + +Model-Driven Design:: Code, der das Domänenmodell ausdrückt + Schlüsselvertreter:: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003) diff --git a/docs/anchors/dry-principle.adoc b/docs/anchors/dry-principle.adoc index 3ddc90e..da3c13b 100644 --- a/docs/anchors/dry-principle.adoc +++ b/docs/anchors/dry-principle.adoc @@ -8,13 +8,20 @@ Full Name:: Don't Repeat Yourself Principle *Core Concepts*: -* *Single representation*: Every piece of knowledge should have a single, unambiguous representation -* *Avoid duplication*: Eliminate duplicate code, logic, and knowledge across the system -* *Abstraction*: Extract common patterns into reusable components -* *Maintenance efficiency*: Changes require modification in only one place -* *Knowledge duplication vs. code duplication*: Focus on avoiding duplicate knowledge, not just duplicate code -* *Normalized data*: Apply DRY to data structures and schemas -* *Configuration management*: Centralize configuration and avoid scattered settings +Single representation:: Every piece of knowledge should have a single, unambiguous representation + +Avoid duplication:: Eliminate duplicate code, logic, and knowledge across the system + +Abstraction:: Extract common patterns into reusable components + +Maintenance efficiency:: Changes require modification in only one place + +Knowledge duplication vs. code duplication:: Focus on avoiding duplicate knowledge, not just duplicate code + +Normalized data:: Apply DRY to data structures and schemas + +Configuration management:: Centralize configuration and avoid scattered settings + Key Proponent:: Andy Hunt and Dave Thomas ("The Pragmatic Programmer", 1999) diff --git a/docs/anchors/dry-principle.de.adoc b/docs/anchors/dry-principle.de.adoc index af77607..2c6f92f 100644 --- a/docs/anchors/dry-principle.de.adoc +++ b/docs/anchors/dry-principle.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: Don't Repeat Yourself-Prinzip (Wiederhole dich nicht) *Kernkonzepte*: -* *Einzelne Repräsentation*: Jedes Stück Wissen sollte eine einzelne, eindeutige Repräsentation haben -* *Duplizierung vermeiden*: Duplizierten Code, Logik und Wissen über das System hinweg eliminieren -* *Abstraktion*: Gemeinsame Muster in wiederverwendbare Komponenten extrahieren -* *Wartungseffizienz*: Änderungen erfordern Modifikation an nur einer Stelle -* *Wissensduplizierung vs. Code-Duplizierung*: Fokus auf Vermeidung duplizierter Wissen, nicht nur duplizierter Code -* *Normalisierte Daten*: DRY auf Datenstrukturen und Schemata anwenden -* *Konfigurationsmanagement*: Konfiguration zentralisieren und verstreute Einstellungen vermeiden +Einzelne Repräsentation:: Jedes Stück Wissen sollte eine einzelne, eindeutige Repräsentation haben + +Duplizierung vermeiden:: Duplizierten Code, Logik und Wissen über das System hinweg eliminieren + +Abstraktion:: Gemeinsame Muster in wiederverwendbare Komponenten extrahieren + +Wartungseffizienz:: Änderungen erfordern Modifikation an nur einer Stelle + +Wissensduplizierung vs. Code-Duplizierung:: Fokus auf Vermeidung duplizierter Wissen, nicht nur duplizierter Code + +Normalisierte Daten:: DRY auf Datenstrukturen und Schemata anwenden + +Konfigurationsmanagement:: Konfiguration zentralisieren und verstreute Einstellungen vermeiden + Schlüsselvertreter:: Andy Hunt und Dave Thomas ("The Pragmatic Programmer", 1999) diff --git a/docs/anchors/ears-requirements.adoc b/docs/anchors/ears-requirements.adoc index 5289267..fa54e3b 100644 --- a/docs/anchors/ears-requirements.adoc +++ b/docs/anchors/ears-requirements.adoc @@ -8,13 +8,20 @@ Full Name:: Easy Approach to Requirements Syntax *Core Concepts*: -* *Ubiquitous requirements*: "The shall " -* *Event-driven requirements*: "WHEN the shall " -* *Unwanted behavior*: "IF , THEN the shall " -* *State-driven requirements*: "WHILE , the shall " -* *Optional features*: "WHERE , the shall " -* *Structured syntax*: Consistent templates for clarity -* *Testability*: Requirements written to be verifiable +Ubiquitous requirements:: "The shall " + +Event-driven requirements:: "WHEN the shall " + +Unwanted behavior:: "IF , THEN the shall " + +State-driven requirements:: "WHILE , the shall " + +Optional features:: "WHERE , the shall " + +Structured syntax:: Consistent templates for clarity + +Testability:: Requirements written to be verifiable + Key Proponent:: Alistair Mavin (Rolls-Royce) diff --git a/docs/anchors/ears-requirements.de.adoc b/docs/anchors/ears-requirements.de.adoc index 8ee332c..4e42597 100644 --- a/docs/anchors/ears-requirements.de.adoc +++ b/docs/anchors/ears-requirements.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: Easy Approach to Requirements Syntax (Einfacher Ansatz fü *Kernkonzepte*: -* *Ubiquitäre Anforderungen*: "Das muss " -* *Ereignisgesteuerte Anforderungen*: "WENN , dann muss das " -* *Unerwünschtes Verhalten*: "FALLS , DANN muss das " -* *Zustandsgesteuerte Anforderungen*: "WÄHREND , muss das " -* *Optionale Features*: "WO , muss das " -* *Strukturierte Syntax*: Konsistente Vorlagen für Klarheit -* *Testbarkeit*: Anforderungen so geschrieben, dass sie überprüfbar sind +Ubiquitäre Anforderungen:: "Das muss " + +Ereignisgesteuerte Anforderungen:: "WENN , dann muss das " + +Unerwünschtes Verhalten:: "FALLS , DANN muss das " + +Zustandsgesteuerte Anforderungen:: "WÄHREND , muss das " + +Optionale Features:: "WO , muss das " + +Strukturierte Syntax:: Konsistente Vorlagen für Klarheit + +Testbarkeit:: Anforderungen so geschrieben, dass sie überprüfbar sind + Schlüsselvertreter:: Alistair Mavin (Rolls-Royce) diff --git a/docs/anchors/feynman-technique.adoc b/docs/anchors/feynman-technique.adoc index 255c457..eca99f8 100644 --- a/docs/anchors/feynman-technique.adoc +++ b/docs/anchors/feynman-technique.adoc @@ -8,14 +8,22 @@ Full Name:: Feynman Technique (also Feynman Learning Method) *Core Concepts*: -* *Explain Simply*: Teach the concept in simple language as if to a beginner (traditionally "explain to a 12-year-old") -* *Identify Gaps*: When you struggle to explain, you've found gaps in your understanding -* *Return to Source Material*: Go back and re-learn the parts you couldn't explain clearly -* *Simplify and Use Analogies*: Refine explanation using plain language and concrete examples -* *Iterative Refinement*: Repeat the cycle until you can explain clearly and simply -* *No Jargon Hiding*: Inability to avoid jargon signals lack of true understanding -* *Active Learning*: Transform passive reading into active teaching -* *Metacognition*: Become aware of what you don't know +Explain Simply:: Teach the concept in simple language as if to a beginner (traditionally "explain to a 12-year-old") + +Identify Gaps:: When you struggle to explain, you've found gaps in your understanding + +Return to Source Material:: Go back and re-learn the parts you couldn't explain clearly + +Simplify and Use Analogies:: Refine explanation using plain language and concrete examples + +Iterative Refinement:: Repeat the cycle until you can explain clearly and simply + +No Jargon Hiding:: Inability to avoid jargon signals lack of true understanding + +Active Learning:: Transform passive reading into active teaching + +Metacognition:: Become aware of what you don't know + Key Attribution:: Richard Feynman (Nobel Prize-winning physicist, 1965), famous for making complex physics accessible @@ -32,10 +40,10 @@ Historical Context:: Feynman was renowned for his teaching ability and his belie *Four Steps (Canonical Form)*: -1. *Choose a concept*: Pick the topic you want to understand -2. *Teach it to a child*: Write an explanation in simple terms -3. *Identify gaps and review*: Where you struggle, study more -4. *Simplify and analogize*: Refine your explanation, use examples +. *Choose a concept*: Pick the topic you want to understand +. *Teach it to a child*: Write an explanation in simple terms +. *Identify gaps and review*: Where you struggle, study more +. *Simplify and analogize*: Refine your explanation, use examples *Related Concepts*: diff --git a/docs/anchors/feynman-technique.de.adoc b/docs/anchors/feynman-technique.de.adoc index cd86dd3..4d30752 100644 --- a/docs/anchors/feynman-technique.de.adoc +++ b/docs/anchors/feynman-technique.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: Feynman-Technik (auch Feynman-Lernmethode) *Kernkonzepte*: -* *Einfach erklären*: Das Konzept in einfacher Sprache lehren, als ob für einen Anfänger (traditionell "einem 12-Jährigen erklären") -* *Lücken identifizieren*: Wenn Sie Schwierigkeiten beim Erklären haben, haben Sie Lücken in Ihrem Verständnis gefunden -* *Zurück zum Quellmaterial*: Zurückgehen und die Teile neu lernen, die Sie nicht klar erklären konnten -* *Vereinfachen und Analogien nutzen*: Erklärung mit einfacher Sprache und konkreten Beispielen verfeinern -* *Iterative Verfeinerung*: Den Zyklus wiederholen, bis Sie klar und einfach erklären können -* *Kein Jargon-Versteck*: Unfähigkeit, Jargon zu vermeiden, signalisiert mangelndes echtes Verständnis -* *Aktives Lernen*: Passives Lesen in aktives Lehren transformieren -* *Metakognition*: Sich bewusst werden, was Sie nicht wissen +Einfach erklären:: Das Konzept in einfacher Sprache lehren, als ob für einen Anfänger (traditionell "einem 12-Jährigen erklären") + +Lücken identifizieren:: Wenn Sie Schwierigkeiten beim Erklären haben, haben Sie Lücken in Ihrem Verständnis gefunden + +Zurück zum Quellmaterial:: Zurückgehen und die Teile neu lernen, die Sie nicht klar erklären konnten + +Vereinfachen und Analogien nutzen:: Erklärung mit einfacher Sprache und konkreten Beispielen verfeinern + +Iterative Verfeinerung:: Den Zyklus wiederholen, bis Sie klar und einfach erklären können + +Kein Jargon-Versteck:: Unfähigkeit, Jargon zu vermeiden, signalisiert mangelndes echtes Verständnis + +Aktives Lernen:: Passives Lesen in aktives Lehren transformieren + +Metakognition:: Sich bewusst werden, was Sie nicht wissen + Schlüsselzuordnung:: Richard Feynman (Nobelpreisträger für Physik, 1965), berühmt dafür, komplexe Physik zugänglich zu machen @@ -32,10 +40,10 @@ Historischer Kontext:: Feynman war für seine Lehrfähigkeit und seinen Glauben *Vier Schritte (kanonische Form)*: -1. *Konzept wählen*: Das Thema auswählen, das Sie verstehen möchten -2. *Einem Kind lehren*: Eine Erklärung in einfachen Begriffen schreiben -3. *Lücken identifizieren und überprüfen*: Wo Sie Schwierigkeiten haben, mehr studieren -4. *Vereinfachen und analogisieren*: Ihre Erklärung verfeinern, Beispiele verwenden +. *Konzept wählen*: Das Thema auswählen, das Sie verstehen möchten +. *Einem Kind lehren*: Eine Erklärung in einfachen Begriffen schreiben +. *Lücken identifizieren und überprüfen*: Wo Sie Schwierigkeiten haben, mehr studieren +. *Vereinfachen und analogisieren*: Ihre Erklärung verfeinern, Beispiele verwenden Verwandte Konzepte:: Rubber Duck Debugging, Socratic Method, ELI5 (Explain Like I'm 5) ==== diff --git a/docs/anchors/five-whys.adoc b/docs/anchors/five-whys.adoc index 211ca61..502f704 100644 --- a/docs/anchors/five-whys.adoc +++ b/docs/anchors/five-whys.adoc @@ -8,14 +8,22 @@ Full Name:: Five Whys Root Cause Analysis *Core Concepts*: -* *Iterative Causal Analysis*: Ask "Why?" repeatedly (typically ~5 times) to drill down to root causes -* *Root Cause vs. Symptom*: Distinguish between surface symptoms and underlying causes -* *Causal Chain*: Each answer becomes the subject of the next "Why?" question -* *Actionable Root Cause*: Continue until you reach a cause that can be acted upon -* *Simplicity*: No complex tools or statistical analysis required -* *Team-Based Investigation*: Collaborative exploration of causal relationships -* *Avoiding Blame*: Focus on process failures, not individual fault -* *Countermeasure Identification*: Once root cause is found, design interventions +Iterative Causal Analysis:: Ask "Why?" repeatedly (typically ~5 times) to drill down to root causes + +Root Cause vs. Symptom:: Distinguish between surface symptoms and underlying causes + +Causal Chain:: Each answer becomes the subject of the next "Why?" question + +Actionable Root Cause:: Continue until you reach a cause that can be acted upon + +Simplicity:: No complex tools or statistical analysis required + +Team-Based Investigation:: Collaborative exploration of causal relationships + +Avoiding Blame:: Focus on process failures, not individual fault + +Countermeasure Identification:: Once root cause is found, design interventions + Key Proponent:: Taiichi Ohno (Toyota Production System, 1950s) diff --git a/docs/anchors/five-whys.de.adoc b/docs/anchors/five-whys.de.adoc index 0444a1d..734554e 100644 --- a/docs/anchors/five-whys.de.adoc +++ b/docs/anchors/five-whys.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: Five Whys Ursachenanalyse (Fünf-Warums) *Kernkonzepte*: -* *Iterative Kausalanalyse*: "Warum?" wiederholt fragen (typischerweise ~5 Mal), um zu Grundursachen vorzudringen -* *Grundursache vs. Symptom*: Zwischen Oberflächensymptomen und zugrunde liegenden Ursachen unterscheiden -* *Kausalkette*: Jede Antwort wird zum Subjekt der nächsten "Warum?"-Frage -* *Handlungsfähige Grundursache*: Fortfahren, bis Sie eine Ursache erreichen, auf die gehandelt werden kann -* *Einfachheit*: Keine komplexen Werkzeuge oder statistische Analyse erforderlich -* *Teambasierte Untersuchung*: Kollaborative Erkundung kausaler Beziehungen -* *Schuldzuweisung vermeiden*: Fokus auf Prozessfehler, nicht individuelle Schuld -* *Gegenmaßnahmen-Identifikation*: Sobald Grundursache gefunden, Interventionen entwerfen +Iterative Kausalanalyse:: "Warum?" wiederholt fragen (typischerweise ~5 Mal), um zu Grundursachen vorzudringen + +Grundursache vs. Symptom:: Zwischen Oberflächensymptomen und zugrunde liegenden Ursachen unterscheiden + +Kausalkette:: Jede Antwort wird zum Subjekt der nächsten "Warum?"-Frage + +Handlungsfähige Grundursache:: Fortfahren, bis Sie eine Ursache erreichen, auf die gehandelt werden kann + +Einfachheit:: Keine komplexen Werkzeuge oder statistische Analyse erforderlich + +Teambasierte Untersuchung:: Kollaborative Erkundung kausaler Beziehungen + +Schuldzuweisung vermeiden:: Fokus auf Prozessfehler, nicht individuelle Schuld + +Gegenmaßnahmen-Identifikation:: Sobald Grundursache gefunden, Interventionen entwerfen + Schlüsselvertreter:: Taiichi Ohno (Toyota-Produktionssystem, 1950er) diff --git a/docs/anchors/hexagonal-architecture.adoc b/docs/anchors/hexagonal-architecture.adoc index 5c1edfa..122c5c7 100644 --- a/docs/anchors/hexagonal-architecture.adoc +++ b/docs/anchors/hexagonal-architecture.adoc @@ -8,15 +8,24 @@ Also known as:: Ports and Adapters, Onion Architecture (variant) *Core Concepts*: -* *Hexagonal structure*: Core domain at the center, isolated from external concerns -* *Ports*: Interfaces defining how the application communicates -* *Adapters*: Implementations that connect to external systems -* *Dependency inversion*: Dependencies point inward toward the domain -* *Technology independence*: Core logic doesn't depend on frameworks or infrastructure -* *Primary/Driving adapters*: User interfaces, APIs (inbound) -* *Secondary/Driven adapters*: Databases, message queues (outbound) -* *Testability*: Easy to test core logic in isolation -* *Symmetry*: All external interactions are treated uniformly +Hexagonal structure:: Core domain at the center, isolated from external concerns + +Ports:: Interfaces defining how the application communicates + +Adapters:: Implementations that connect to external systems + +Dependency inversion:: Dependencies point inward toward the domain + +Technology independence:: Core logic doesn't depend on frameworks or infrastructure + +Primary/Driving adapters:: User interfaces, APIs (inbound) + +Secondary/Driven adapters:: Databases, message queues (outbound) + +Testability:: Easy to test core logic in isolation + +Symmetry:: All external interactions are treated uniformly + Key Proponent:: Alistair Cockburn (2005) diff --git a/docs/anchors/hexagonal-architecture.de.adoc b/docs/anchors/hexagonal-architecture.de.adoc index 23fd8eb..79cca86 100644 --- a/docs/anchors/hexagonal-architecture.de.adoc +++ b/docs/anchors/hexagonal-architecture.de.adoc @@ -8,15 +8,24 @@ Auch bekannt als:: Ports and Adapters, Onion Architecture (Variante) *Kernkonzepte*: -* *Hexagonale Struktur*: Kerndomäne im Zentrum, isoliert von externen Belangen -* *Ports*: Schnittstellen, die definieren, wie die Anwendung kommuniziert -* *Adapter*: Implementierungen, die mit externen Systemen verbinden -* *Dependency Inversion*: Abhängigkeiten zeigen nach innen zur Domäne -* *Technologieunabhängigkeit*: Kernlogik hängt nicht von Frameworks oder Infrastruktur ab -* *Primäre/Treibende Adapter*: Benutzeroberflächen, APIs (eingehend) -* *Sekundäre/Getriebene Adapter*: Datenbanken, Message Queues (ausgehend) -* *Testbarkeit*: Einfaches Testen der Kernlogik isoliert -* *Symmetrie*: Alle externen Interaktionen werden einheitlich behandelt +Hexagonale Struktur:: Kerndomäne im Zentrum, isoliert von externen Belangen + +Ports:: Schnittstellen, die definieren, wie die Anwendung kommuniziert + +Adapter:: Implementierungen, die mit externen Systemen verbinden + +Dependency Inversion:: Abhängigkeiten zeigen nach innen zur Domäne + +Technologieunabhängigkeit:: Kernlogik hängt nicht von Frameworks oder Infrastruktur ab + +Primäre/Treibende Adapter:: Benutzeroberflächen, APIs (eingehend) + +Sekundäre/Getriebene Adapter:: Datenbanken, Message Queues (ausgehend) + +Testbarkeit:: Einfaches Testen der Kernlogik isoliert + +Symmetrie:: Alle externen Interaktionen werden einheitlich behandelt + Schlüsselvertreter:: Alistair Cockburn (2005) diff --git a/docs/anchors/iec-61508-sil-levels.adoc b/docs/anchors/iec-61508-sil-levels.adoc index 1ea576a..15ffbc3 100644 --- a/docs/anchors/iec-61508-sil-levels.adoc +++ b/docs/anchors/iec-61508-sil-levels.adoc @@ -13,20 +13,31 @@ Also known as:: Functional Safety Levels, SIL Classification *Core Concepts*: -* *Four Safety Integrity Levels*: -** *SIL 1* (lowest): 10^-2^ ≤ PFD < 10^-1^ (tolerable risk reduction) -** *SIL 2*: 10^-3^ ≤ PFD < 10^-2^ (moderate risk reduction) -** *SIL 3*: 10^-4^ ≤ PFD < 10^-3^ (substantial risk reduction) -** *SIL 4* (highest): 10^-5^ ≤ PFD < 10^-4^ (maximum risk reduction) -* *Risk-based classification*: SIL level determined by hazard analysis and risk assessment -* *Safety lifecycle*: Systematic approach from concept to decommissioning -* *Hardware requirements*: Architectural constraints and systematic capability -* *Software requirements*: Development methods, verification, and validation techniques -* *Probability of Failure on Demand (PFD)*: Key metric for safety function reliability -* *Safety instrumented systems (SIS)*: Protection layers implementing safety functions -* *Verification and validation*: Independent assessment of safety claims -* *Systematic failures*: Focus on preventing design and specification errors -* *Random hardware failures*: Statistical analysis and fault tolerance +Four Safety Integrity Levels:: ++ +SIL 1 (lowest)::: 10^-2^ ≤ PFD < 10^-1^ (tolerable risk reduction) +SIL 2::: 10^-3^ ≤ PFD < 10^-2^ (moderate risk reduction) +SIL 3::: 10^-4^ ≤ PFD < 10^-3^ (substantial risk reduction) +SIL 4 (highest)::: 10^-5^ ≤ PFD < 10^-4^ (maximum risk reduction) + +Risk-based classification:: SIL level determined by hazard analysis and risk assessment + +Safety lifecycle:: Systematic approach from concept to decommissioning + +Hardware requirements:: Architectural constraints and systematic capability + +Software requirements:: Development methods, verification, and validation techniques + +Probability of Failure on Demand (PFD):: Key metric for safety function reliability + +Safety instrumented systems (SIS):: Protection layers implementing safety functions + +Verification and validation:: Independent assessment of safety claims + +Systematic failures:: Focus on preventing design and specification errors + +Random hardware failures:: Statistical analysis and fault tolerance + Key Standard:: IEC 61508 "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems" (first edition 1998, second edition 2010) diff --git a/docs/anchors/impact-mapping.adoc b/docs/anchors/impact-mapping.adoc index 1588acd..712f35d 100644 --- a/docs/anchors/impact-mapping.adoc +++ b/docs/anchors/impact-mapping.adoc @@ -8,15 +8,24 @@ Full Name:: Impact Mapping according to Gojko Adzic *Core Concepts*: -* *Four levels*: Goal → Actors → Impacts → Deliverables -* *Goal*: Business objective (Why?) -* *Actors*: Who can produce or prevent desired impact? (Who?) -* *Impacts*: How can actors' behavior change? (How?) -* *Deliverables*: What can we build? (What?) -* *Visual mapping*: Mind-map style collaborative diagram -* *Assumption testing*: Make assumptions explicit -* *Scope management*: Prevent scope creep by linking to goals -* *Roadmap alternative*: Goal-oriented rather than feature-oriented +Four levels:: Goal → Actors → Impacts → Deliverables + +Goal:: Business objective (Why?) + +Actors:: Who can produce or prevent desired impact? (Who?) + +Impacts:: How can actors' behavior change? (How?) + +Deliverables:: What can we build? (What?) + +Visual mapping:: Mind-map style collaborative diagram + +Assumption testing:: Make assumptions explicit + +Scope management:: Prevent scope creep by linking to goals + +Roadmap alternative:: Goal-oriented rather than feature-oriented + Key Proponent:: Gojko Adzic ("Impact Mapping", 2012) diff --git a/docs/anchors/impact-mapping.de.adoc b/docs/anchors/impact-mapping.de.adoc index 01ff659..290e4f6 100644 --- a/docs/anchors/impact-mapping.de.adoc +++ b/docs/anchors/impact-mapping.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: Impact Mapping nach Gojko Adzic *Kernkonzepte*: -* *Vier Ebenen*: Ziel → Akteure → Auswirkungen → Liefergegenstände -* *Ziel*: Geschäftsziel (Warum?) -* *Akteure*: Wer kann die gewünschte Auswirkung erzeugen oder verhindern? (Wer?) -* *Auswirkungen*: Wie kann sich das Verhalten der Akteure ändern? (Wie?) -* *Liefergegenstände*: Was können wir bauen? (Was?) -* *Visuelles Mapping*: Mind-Map-Stil kollaboratives Diagramm -* *Annahmentesten*: Annahmen explizit machen -* *Scope-Management*: Scope Creep durch Verknüpfung mit Zielen verhindern -* *Roadmap-Alternative*: Zielorientiert statt featureorientiert +Vier Ebenen:: Ziel → Akteure → Auswirkungen → Liefergegenstände + +Ziel:: Geschäftsziel (Warum?) + +Akteure:: Wer kann die gewünschte Auswirkung erzeugen oder verhindern? (Wer?) + +Auswirkungen:: Wie kann sich das Verhalten der Akteure ändern? (Wie?) + +Liefergegenstände:: Was können wir bauen? (Was?) + +Visuelles Mapping:: Mind-Map-Stil kollaboratives Diagramm + +Annahmentesten:: Annahmen explizit machen + +Scope-Management:: Scope Creep durch Verknüpfung mit Zielen verhindern + +Roadmap-Alternative:: Zielorientiert statt featureorientiert + Schlüsselvertreter:: Gojko Adzic ("Impact Mapping", 2012) diff --git a/docs/anchors/jobs-to-be-done.adoc b/docs/anchors/jobs-to-be-done.adoc index de6d0a8..ea6e07d 100644 --- a/docs/anchors/jobs-to-be-done.adoc +++ b/docs/anchors/jobs-to-be-done.adoc @@ -9,15 +9,24 @@ Full Name:: Jobs To Be Done Framework (Christensen interpretation) *Core Concepts*: -* *Job definition*: Progress people want to make in a particular context -* *Functional job*: Practical task to accomplish -* *Emotional job*: How people want to feel -* *Social job*: How people want to be perceived -* *Hire and fire*: Customers "hire" products to do a job, "fire" when inadequate -* *Context matters*: Jobs exist in specific circumstances -* *Competition redefined*: Anything solving the same job is competition -* *Innovation opportunities*: Unmet jobs or poorly served jobs -* *Job stories*: Alternative to user stories focusing on context and motivation +Job definition:: Progress people want to make in a particular context + +Functional job:: Practical task to accomplish + +Emotional job:: How people want to feel + +Social job:: How people want to be perceived + +Hire and fire:: Customers "hire" products to do a job, "fire" when inadequate + +Context matters:: Jobs exist in specific circumstances + +Competition redefined:: Anything solving the same job is competition + +Innovation opportunities:: Unmet jobs or poorly served jobs + +Job stories:: Alternative to user stories focusing on context and motivation + Key Proponents:: Clayton Christensen, Alan Klement, Bob Moesta diff --git a/docs/anchors/jobs-to-be-done.de.adoc b/docs/anchors/jobs-to-be-done.de.adoc index 3876297..93ef6f2 100644 --- a/docs/anchors/jobs-to-be-done.de.adoc +++ b/docs/anchors/jobs-to-be-done.de.adoc @@ -9,15 +9,24 @@ Vollständiger Name:: Jobs To Be Done Framework (Christensen interpretation) *Kernkonzepte*: -* *Job-Definition*: Fortschritt, den Menschen in einem bestimmten Kontext machen wollen -* *Funktionaler Job*: Praktische Aufgabe zu erfüllen -* *Emotionaler Job*: Wie Menschen sich fühlen wollen -* *Sozialer Job*: Wie Menschen wahrgenommen werden wollen -* *Hire and Fire*: Kunden "engagieren" Produkte für einen Job, "feuern" sie, wenn unzureichend -* *Kontext zählt*: Jobs existieren in spezifischen Umständen -* *Neudefinierte Konkurrenz*: Alles, was denselben Job löst, ist Konkurrenz -* *Innovationsmöglichkeiten*: Unerfüllte Jobs oder schlecht bediente Jobs -* *Job Stories*: Alternative zu User Stories mit Fokus auf Kontext und Motivation +Job-Definition:: Fortschritt, den Menschen in einem bestimmten Kontext machen wollen + +Funktionaler Job:: Praktische Aufgabe zu erfüllen + +Emotionaler Job:: Wie Menschen sich fühlen wollen + +Sozialer Job:: Wie Menschen wahrgenommen werden wollen + +Hire and Fire:: Kunden "engagieren" Produkte für einen Job, "feuern" sie, wenn unzureichend + +Kontext zählt:: Jobs existieren in spezifischen Umständen + +Neudefinierte Konkurrenz:: Alles, was denselben Job löst, ist Konkurrenz + +Innovationsmöglichkeiten:: Unerfüllte Jobs oder schlecht bediente Jobs + +Job Stories:: Alternative zu User Stories mit Fokus auf Kontext und Motivation + Schlüsselvertreter:: Clayton Christensen, Alan Klement, Bob Moesta diff --git a/docs/anchors/madr.adoc b/docs/anchors/madr.adoc index ccad84c..ad68e99 100644 --- a/docs/anchors/madr.adoc +++ b/docs/anchors/madr.adoc @@ -9,21 +9,28 @@ Full Name:: Markdown Any Decision Records *Core Concepts*: -* *Structured template*: Well-defined format with specific sections -* *Standard fields*: -** Title (short noun phrase) -** Status (proposed, accepted, rejected, deprecated, superseded) -** Context and Problem Statement -** Decision Drivers (forces influencing the decision) -** Considered Options (alternatives evaluated) -** Decision Outcome (chosen option with justification) -** Pros and Cons of the Options (trade-off analysis) -** Links (related decisions, references) -* *Markdown format*: Uses standard Markdown for wide compatibility -* *Clear structure*: More detailed than basic ADRs, includes explicit alternatives -* *Trade-off documentation*: Explicitly captures pros/cons of each option -* *Version control*: Stored with code, immutable like other ADRs -* *Lightweight yet comprehensive*: Balances completeness with maintainability +Structured template:: Well-defined format with specific sections + +Standard fields:: +* Title (short noun phrase) +* Status (proposed, accepted, rejected, deprecated, superseded) +* Context and Problem Statement +* Decision Drivers (forces influencing the decision) +* Considered Options (alternatives evaluated) +* Decision Outcome (chosen option with justification) +* Pros and Cons of the Options (trade-off analysis) +* Links (related decisions, references) + +Markdown format:: Uses standard Markdown for wide compatibility + +Clear structure:: More detailed than basic ADRs, includes explicit alternatives + +Trade-off documentation:: Explicitly captures pros/cons of each option + +Version control:: Stored with code, immutable like other ADRs + +Lightweight yet comprehensive:: Balances completeness with maintainability + Key Proponents:: Oliver Kopp, Olaf Zimmermann (and MADR community) diff --git a/docs/anchors/madr.de.adoc b/docs/anchors/madr.de.adoc index 0b4aeac..ffd6185 100644 --- a/docs/anchors/madr.de.adoc +++ b/docs/anchors/madr.de.adoc @@ -9,21 +9,28 @@ Vollständiger Name:: Markdown Any Decision Records *Kernkonzepte*: -* *Strukturiertes Template*: Wohldefiniertes Format mit spezifischen Abschnitten -* *Standardfelder*: -** Titel (kurze Nominalphrase) -** Status (vorgeschlagen, akzeptiert, abgelehnt, veraltet, ersetzt) -** Kontext und Problemstellung -** Entscheidungstreiber (Kräfte, die die Entscheidung beeinflussen) -** Betrachtete Optionen (bewertete Alternativen) -** Entscheidungsergebnis (gewählte Option mit Begründung) -** Vor- und Nachteile der Optionen (Trade-off-Analyse) -** Links (verwandte Entscheidungen, Referenzen) -* *Markdown-Format*: Nutzt Standard-Markdown für breite Kompatibilität -* *Klare Struktur*: Detaillierter als einfache ADRs, enthält explizite Alternativen -* *Trade-off-Dokumentation*: Erfasst explizit Vor-/Nachteile jeder Option -* *Versionskontrolle*: Mit Code gespeichert, unveränderlich wie andere ADRs -* *Leichtgewichtig und dennoch umfassend*: Balanciert Vollständigkeit mit Wartbarkeit +Strukturiertes Template:: Wohldefiniertes Format mit spezifischen Abschnitten + +Standardfelder:: +* Titel (kurze Nominalphrase) +* Status (vorgeschlagen, akzeptiert, abgelehnt, veraltet, ersetzt) +* Kontext und Problemstellung +* Entscheidungstreiber (Kräfte, die die Entscheidung beeinflussen) +* Betrachtete Optionen (bewertete Alternativen) +* Entscheidungsergebnis (gewählte Option mit Begründung) +* Vor- und Nachteile der Optionen (Trade-off-Analyse) +* Links (verwandte Entscheidungen, Referenzen) + +Markdown-Format:: Nutzt Standard-Markdown für breite Kompatibilität + +Klare Struktur:: Detaillierter als einfache ADRs, enthält explizite Alternativen + +Trade-off-Dokumentation:: Erfasst explizit Vor-/Nachteile jeder Option + +Versionskontrolle:: Mit Code gespeichert, unveränderlich wie andere ADRs + +Leichtgewichtig und dennoch umfassend:: Balanciert Vollständigkeit mit Wartbarkeit + Schlüsselvertreter:: Oliver Kopp, Olaf Zimmermann (und MADR-Community) diff --git a/docs/anchors/mece.adoc b/docs/anchors/mece.adoc index 065231d..f81e745 100644 --- a/docs/anchors/mece.adoc +++ b/docs/anchors/mece.adoc @@ -8,14 +8,22 @@ Full Name:: MECE (Mutually Exclusive, Collectively Exhaustive) *Core Concepts*: -* *Mutually Exclusive*: Categories have no overlap - each item belongs to exactly one category -* *Collectively Exhaustive*: Categories cover all possibilities - nothing is left out -* *Framework for organization*: Systematic approach to structuring information and problems -* *Prevents duplication*: Mutual exclusivity ensures no redundant coverage -* *Prevents gaps*: Collective exhaustiveness ensures complete coverage -* *Clear boundaries*: Unambiguous categorization with well-defined criteria -* *Hierarchical application*: Can be applied recursively at multiple levels -* *Validation approach*: Check both dimensions independently (exclusivity and exhaustiveness) +Mutually Exclusive:: Categories have no overlap - each item belongs to exactly one category + +Collectively Exhaustive:: Categories cover all possibilities - nothing is left out + +Framework for organization:: Systematic approach to structuring information and problems + +Prevents duplication:: Mutual exclusivity ensures no redundant coverage + +Prevents gaps:: Collective exhaustiveness ensures complete coverage + +Clear boundaries:: Unambiguous categorization with well-defined criteria + +Hierarchical application:: Can be applied recursively at multiple levels + +Validation approach:: Check both dimensions independently (exclusivity and exhaustiveness) + Key Proponent:: Barbara Minto (McKinsey & Company, late 1960s) diff --git a/docs/anchors/mece.de.adoc b/docs/anchors/mece.de.adoc index d0684fc..81c083b 100644 --- a/docs/anchors/mece.de.adoc +++ b/docs/anchors/mece.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: MECE (Mutually Exclusive, Collectively Exhaustive - Sich g *Kernkonzepte*: -* *Sich gegenseitig ausschließend*: Kategorien überschneiden sich nicht - jedes Element gehört zu genau einer Kategorie -* *Gemeinsam erschöpfend*: Kategorien decken alle Möglichkeiten ab - nichts wird ausgelassen -* *Framework für Organisation*: Systematischer Ansatz zur Strukturierung von Informationen und Problemen -* *Verhindert Duplizierung*: Gegenseitiger Ausschluss stellt sicher, dass keine redundante Abdeckung vorliegt -* *Verhindert Lücken*: Gemeinsame Erschöpfung stellt vollständige Abdeckung sicher -* *Klare Grenzen*: Eindeutige Kategorisierung mit klar definierten Kriterien -* *Hierarchische Anwendung*: Kann rekursiv auf mehreren Ebenen angewendet werden -* *Validierungsansatz*: Beide Dimensionen unabhängig prüfen (Ausschließlichkeit und Vollständigkeit) +Sich gegenseitig ausschließend:: Kategorien überschneiden sich nicht - jedes Element gehört zu genau einer Kategorie + +Gemeinsam erschöpfend:: Kategorien decken alle Möglichkeiten ab - nichts wird ausgelassen + +Framework für Organisation:: Systematischer Ansatz zur Strukturierung von Informationen und Problemen + +Verhindert Duplizierung:: Gegenseitiger Ausschluss stellt sicher, dass keine redundante Abdeckung vorliegt + +Verhindert Lücken:: Gemeinsame Erschöpfung stellt vollständige Abdeckung sicher + +Klare Grenzen:: Eindeutige Kategorisierung mit klar definierten Kriterien + +Hierarchische Anwendung:: Kann rekursiv auf mehreren Ebenen angewendet werden + +Validierungsansatz:: Beide Dimensionen unabhängig prüfen (Ausschließlichkeit und Vollständigkeit) + Schlüsselvertreterin:: Barbara Minto (McKinsey & Company, späte 1960er) diff --git a/docs/anchors/mental-model-according-to-naur.adoc b/docs/anchors/mental-model-according-to-naur.adoc index f444c84..fdaa6aa 100644 --- a/docs/anchors/mental-model-according-to-naur.adoc +++ b/docs/anchors/mental-model-according-to-naur.adoc @@ -8,15 +8,24 @@ Full Name:: Programming as Theory Building (Mental Model) according to Peter Nau *Core Concepts*: -* *Theory building*: Programming is creating a mental model, not just writing code -* *Theory of the program*: Deep understanding of why the program works and how it relates to the problem domain -* *Knowledge in people*: The real program exists in developers' minds, not in the code -* *Theory decay*: When original developers leave, the theory is lost -* *Documentation limitations*: Written documentation cannot fully capture the theory -* *Maintenance as theory*: Effective maintenance requires possessing the theory -* *Communication is key*: Theory must be shared through collaboration and conversation -* *Ramp-up time*: New team members need time to build the theory -* *Code as artifact*: Code is merely a representation of the underlying theory +Theory building:: Programming is creating a mental model, not just writing code + +Theory of the program:: Deep understanding of why the program works and how it relates to the problem domain + +Knowledge in people:: The real program exists in developers' minds, not in the code + +Theory decay:: When original developers leave, the theory is lost + +Documentation limitations:: Written documentation cannot fully capture the theory + +Maintenance as theory:: Effective maintenance requires possessing the theory + +Communication is key:: Theory must be shared through collaboration and conversation + +Ramp-up time:: New team members need time to build the theory + +Code as artifact:: Code is merely a representation of the underlying theory + Key Proponent:: Peter Naur (Turing Award winner, 1978) diff --git a/docs/anchors/mental-model-according-to-naur.de.adoc b/docs/anchors/mental-model-according-to-naur.de.adoc index 9af790e..bf345f4 100644 --- a/docs/anchors/mental-model-according-to-naur.de.adoc +++ b/docs/anchors/mental-model-according-to-naur.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: Programming as Theory Building (Mental Model) according to *Kernkonzepte*: -* *Theory Building*: Programmieren ist Erstellen eines mentalen Modells, nicht nur Code schreiben -* *Theorie des Programms*: Tiefes Verständnis, warum das Programm funktioniert und wie es zur Problemdomäne passt -* *Wissen in Menschen*: Das echte Programm existiert in den Köpfen der Entwickler, nicht im Code -* *Theoriezerfall*: Wenn ursprüngliche Entwickler gehen, geht die Theorie verloren -* *Dokumentationsgrenzen*: Schriftliche Dokumentation kann die Theorie nicht vollständig erfassen -* *Wartung als Theorie*: Effektive Wartung erfordert Besitz der Theorie -* *Kommunikation ist Schlüssel*: Theorie muss durch Kollaboration und Konversation geteilt werden -* *Ramp-up-Zeit*: Neue Teammitglieder brauchen Zeit, um die Theorie aufzubauen -* *Code als Artefakt*: Code ist nur eine Repräsentation der zugrundeliegenden Theorie +Theory Building:: Programmieren ist Erstellen eines mentalen Modells, nicht nur Code schreiben + +Theorie des Programms:: Tiefes Verständnis, warum das Programm funktioniert und wie es zur Problemdomäne passt + +Wissen in Menschen:: Das echte Programm existiert in den Köpfen der Entwickler, nicht im Code + +Theoriezerfall:: Wenn ursprüngliche Entwickler gehen, geht die Theorie verloren + +Dokumentationsgrenzen:: Schriftliche Dokumentation kann die Theorie nicht vollständig erfassen + +Wartung als Theorie:: Effektive Wartung erfordert Besitz der Theorie + +Kommunikation ist Schlüssel:: Theorie muss durch Kollaboration und Konversation geteilt werden + +Ramp-up-Zeit:: Neue Teammitglieder brauchen Zeit, um die Theorie aufzubauen + +Code als Artefakt:: Code ist nur eine Repräsentation der zugrundeliegenden Theorie + Schlüsselvertreter:: Peter Naur (Turing Award Gewinner, 1978) diff --git a/docs/anchors/morphological-box.adoc b/docs/anchors/morphological-box.adoc index 95f06b6..58abce4 100644 --- a/docs/anchors/morphological-box.adoc +++ b/docs/anchors/morphological-box.adoc @@ -11,14 +11,22 @@ Full Name:: Morphological Analysis / Morphological Box (German: Morphologischer *Core Concepts*: -* *Multi-dimensional decomposition*: Break complex problem into independent parameters/dimensions -* *Variant enumeration*: Identify possible values/options for each parameter -* *Matrix construction*: Organize parameters and variants in table/box form -* *Combinatorial exploration*: Systematically examine combinations of variants -* *Constraint filtering*: Eliminate infeasible or contradictory combinations -* *Novel solution discovery*: Find non-obvious solutions through systematic recombination -* *Complete solution space*: Ensure all possibilities are considered -* *Structured creativity*: Systematic approach to innovation and ideation +Multi-dimensional decomposition:: Break complex problem into independent parameters/dimensions + +Variant enumeration:: Identify possible values/options for each parameter + +Matrix construction:: Organize parameters and variants in table/box form + +Combinatorial exploration:: Systematically examine combinations of variants + +Constraint filtering:: Eliminate infeasible or contradictory combinations + +Novel solution discovery:: Find non-obvious solutions through systematic recombination + +Complete solution space:: Ensure all possibilities are considered + +Structured creativity:: Systematic approach to innovation and ideation + Key Proponent:: Fritz Zwicky (1940s-1960s, California Institute of Technology) diff --git a/docs/anchors/mutation-testing.adoc b/docs/anchors/mutation-testing.adoc index 8288612..db4b5eb 100644 --- a/docs/anchors/mutation-testing.adoc +++ b/docs/anchors/mutation-testing.adoc @@ -9,18 +9,30 @@ Also known as:: Mutation Analysis, Fault-Based Testing *Core Concepts*: -* *Test quality assessment*: Evaluate how effective tests are at detecting bugs -* *Code mutations*: Deliberately introduce small, syntactic changes (mutants) into source code -* *Mutation operators*: Rules for creating mutants (e.g., change `>` to `>=`, flip boolean, remove statement) -* *Killed mutants*: Mutations caught by failing tests (good) -* *Survived mutants*: Mutations not detected by tests (indicates test weakness) -* *Equivalent mutants*: Mutations that don't change program behavior (false positives) -* *Mutation score*: Percentage of killed mutants: `(killed / (total - equivalent)) × 100%` -* *First-order mutations*: Single atomic change per mutant -* *Higher-order mutations*: Multiple changes combined -* *Weak mutation*: Test only needs to create different internal state -* *Strong mutation*: Test must produce different final output -* *Test adequacy criterion*: "Are tests good enough?" not just "Is coverage high enough?" +Test quality assessment:: Evaluate how effective tests are at detecting bugs + +Code mutations:: Deliberately introduce small, syntactic changes (mutants) into source code + +Mutation operators:: Rules for creating mutants (e.g., change `>` to `>=`, flip boolean, remove statement) + +Killed mutants:: Mutations caught by failing tests (good) + +Survived mutants:: Mutations not detected by tests (indicates test weakness) + +Equivalent mutants:: Mutations that don't change program behavior (false positives) + +Mutation score:: Percentage of killed mutants: `(killed / (total - equivalent)) × 100%` + +First-order mutations:: Single atomic change per mutant + +Higher-order mutations:: Multiple changes combined + +Weak mutation:: Test only needs to create different internal state + +Strong mutation:: Test must produce different final output + +Test adequacy criterion:: "Are tests good enough?" not just "Is coverage high enough?" + Key Proponents:: Richard Lipton (theoretical foundation, 1971), Richard DeMillo, Timothy Budd @@ -44,15 +56,23 @@ Key Proponents:: Richard Lipton (theoretical foundation, 1971), Richard DeMillo, *Practical Challenges*: -* *Computational cost*: N mutations × M tests = expensive -* *Equivalent mutant problem*: Hard to automatically detect functionally identical mutants -* *Time investment*: Can be slow on large codebases -* *Mitigation strategies*: Selective mutation, mutation sampling, incremental analysis +Computational cost:: N mutations × M tests = expensive + +Equivalent mutant problem:: Hard to automatically detect functionally identical mutants + +Time investment:: Can be slow on large codebases + +Mitigation strategies:: Selective mutation, mutation sampling, incremental analysis + *Relationship to Other Practices*: -* *Code coverage*: Mutation testing reveals that high coverage ≠ good tests -* *TDD*: Strong TDD often produces high mutation scores naturally -* *Property-based testing*: Orthogonal but complementary approaches -* *Fault injection*: Similar concept applied to production systems +Code coverage:: Mutation testing reveals that high coverage ≠ good tests + +TDD:: Strong TDD often produces high mutation scores naturally + +Property-based testing:: Orthogonal but complementary approaches + +Fault injection:: Similar concept applied to production systems + ==== diff --git a/docs/anchors/mutation-testing.de.adoc b/docs/anchors/mutation-testing.de.adoc index f9ad489..7fbd882 100644 --- a/docs/anchors/mutation-testing.de.adoc +++ b/docs/anchors/mutation-testing.de.adoc @@ -9,18 +9,30 @@ Auch bekannt als:: Mutationsanalyse, Fehlerbasiertes Testen *Kernkonzepte*: -* *Testqualitätsbewertung*: Bewertung, wie effektiv Tests Fehler erkennen -* *Code-Mutationen*: Absichtliches Einführen kleiner, syntaktischer Änderungen (Mutanten) in Quellcode -* *Mutationsoperatoren*: Regeln zur Erstellung von Mutanten (z.B. `>` zu `>=` ändern, Boolean umkehren, Anweisung entfernen) -* *Getötete Mutanten*: Mutationen, die durch fehlschlagende Tests erkannt wurden (gut) -* *Überlebende Mutanten*: Mutationen, die von Tests nicht erkannt wurden (zeigt Testschwäche an) -* *Äquivalente Mutanten*: Mutationen, die das Programmverhalten nicht ändern (Falsch-Positive) -* *Mutations-Score*: Prozentsatz getöteter Mutanten: `(getötet / (gesamt - äquivalent)) × 100%` -* *Mutationen erster Ordnung*: Einzelne atomare Änderung pro Mutant -* *Mutationen höherer Ordnung*: Mehrere kombinierte Änderungen -* *Schwache Mutation*: Test muss nur unterschiedlichen internen Zustand erzeugen -* *Starke Mutation*: Test muss unterschiedliche finale Ausgabe erzeugen -* *Testadäquatheitskriterium*: "Sind die Tests gut genug?" nicht nur "Ist die Abdeckung hoch genug?" +Testqualitätsbewertung:: Bewertung, wie effektiv Tests Fehler erkennen + +Code-Mutationen:: Absichtliches Einführen kleiner, syntaktischer Änderungen (Mutanten) in Quellcode + +Mutationsoperatoren:: Regeln zur Erstellung von Mutanten (z.B. `>` zu `>=` ändern, Boolean umkehren, Anweisung entfernen) + +Getötete Mutanten:: Mutationen, die durch fehlschlagende Tests erkannt wurden (gut) + +Überlebende Mutanten:: Mutationen, die von Tests nicht erkannt wurden (zeigt Testschwäche an) + +Äquivalente Mutanten:: Mutationen, die das Programmverhalten nicht ändern (Falsch-Positive) + +Mutations-Score:: Prozentsatz getöteter Mutanten: `(getötet / (gesamt - äquivalent)) × 100%` + +Mutationen erster Ordnung:: Einzelne atomare Änderung pro Mutant + +Mutationen höherer Ordnung:: Mehrere kombinierte Änderungen + +Schwache Mutation:: Test muss nur unterschiedlichen internen Zustand erzeugen + +Starke Mutation:: Test muss unterschiedliche finale Ausgabe erzeugen + +Testadäquatheitskriterium:: "Sind die Tests gut genug?" nicht nur "Ist die Abdeckung hoch genug?" + Schlüsselvertreter:: Richard Lipton (theoretische Grundlage, 1971), Richard DeMillo, Timothy Budd @@ -44,15 +56,23 @@ Schlüsselvertreter:: Richard Lipton (theoretische Grundlage, 1971), Richard DeM *Praktische Herausforderungen*: -* *Rechenkosten*: N Mutationen × M Tests = teuer -* *Äquivalente-Mutanten-Problem*: Schwierig, funktional identische Mutanten automatisch zu erkennen -* *Zeitinvestition*: Kann bei großen Codebasen langsam sein -* *Abhilfestrategien*: Selektive Mutation, Mutations-Sampling, inkrementelle Analyse +Rechenkosten:: N Mutationen × M Tests = teuer + +Äquivalente-Mutanten-Problem:: Schwierig, funktional identische Mutanten automatisch zu erkennen + +Zeitinvestition:: Kann bei großen Codebasen langsam sein + +Abhilfestrategien:: Selektive Mutation, Mutations-Sampling, inkrementelle Analyse + *Beziehung zu anderen Praktiken*: -* *Code-Abdeckung*: Mutations-Testing zeigt, dass hohe Abdeckung ≠ gute Tests -* *TDD*: Starkes TDD erzeugt oft natürlich hohe Mutations-Scores -* *Property-based Testing*: Orthogonale, aber komplementäre Ansätze -* *Fault Injection*: Ähnliches Konzept, angewendet auf Produktionssysteme +Code-Abdeckung:: Mutations-Testing zeigt, dass hohe Abdeckung ≠ gute Tests + +TDD:: Starkes TDD erzeugt oft natürlich hohe Mutations-Scores + +Property-based Testing:: Orthogonale, aber komplementäre Ansätze + +Fault Injection:: Ähnliches Konzept, angewendet auf Produktionssysteme + ==== diff --git a/docs/anchors/nelson-rules.adoc b/docs/anchors/nelson-rules.adoc index a729d78..bb55a8d 100644 --- a/docs/anchors/nelson-rules.adoc +++ b/docs/anchors/nelson-rules.adoc @@ -9,25 +9,39 @@ Full Name:: Nelson Rules (Tests for Special Causes) *Core Concepts*: * *8 rules* for detecting non-random patterns in Control Charts -* *Rule 1*: One point beyond 3σ (Outlier) -* *Rule 2*: 9 consecutive points on the same side of the mean (Shift/Bias) -* *Rule 3*: 6 consecutive points steadily increasing or decreasing (Trend) -* *Rule 4*: 14 points alternating up and down (Oscillation) -* *Rule 5*: 2 out of 3 points beyond 2σ on the same side -* *Rule 6*: 4 out of 5 points beyond 1σ on the same side -* *Rule 7*: 15 points within 1σ (suspiciously low variance) -* *Rule 8*: 8 points outside ±1σ, but none beyond ±3σ (systematic oscillation) -* *Common Cause vs. Special Cause*: Distinguishing inherent from assignable variation -* *Zones A/B/C*: Dividing the Control Chart into 6 zones (each 1σ wide) -* *False Positive Trade-off*: More active rules = higher sensitivity, but more false alarms +Rule 1:: One point beyond 3σ (Outlier) + +Rule 2:: 9 consecutive points on the same side of the mean (Shift/Bias) + +Rule 3:: 6 consecutive points steadily increasing or decreasing (Trend) + +Rule 4:: 14 points alternating up and down (Oscillation) + +Rule 5:: 2 out of 3 points beyond 2σ on the same side + +Rule 6:: 4 out of 5 points beyond 1σ on the same side + +Rule 7:: 15 points within 1σ (suspiciously low variance) + +Rule 8:: 8 points outside ±1σ, but none beyond ±3σ (systematic oscillation) + +Common Cause vs. Special Cause:: Distinguishing inherent from assignable variation + +Zones A/B/C:: Dividing the Control Chart into 6 zones (each 1σ wide) + +False Positive Trade-off:: More active rules = higher sensitivity, but more false alarms + Key Proponent:: Lloyd S. Nelson (1984, Journal of Quality Technology) *Relationship to Other Anchors*: -* *Control Chart (Shewhart)*: Nelson Rules are applied to Control Charts -* *<>*: Nelson Rules are a tool within Statistical Process Control -* *Western Electric Rules*: Predecessor; Nelson Rules extend these with Rules 5-8 +Control Chart (Shewhart):: Nelson Rules are applied to Control Charts + +<>:: Nelson Rules are a tool within Statistical Process Control + +Western Electric Rules:: Predecessor; Nelson Rules extend these with Rules 5-8 + *When to Use*: diff --git a/docs/anchors/nelson-rules.de.adoc b/docs/anchors/nelson-rules.de.adoc index c709647..ae3974a 100644 --- a/docs/anchors/nelson-rules.de.adoc +++ b/docs/anchors/nelson-rules.de.adoc @@ -9,25 +9,39 @@ Vollständiger Name:: Nelson Rules (Tests for Special Causes) *Kernkonzepte*: * *8 Regeln* zur Erkennung nicht-zufälliger Muster in Regelkarten -* *Regel 1*: Ein Punkt jenseits von 3σ (Ausreißer) -* *Regel 2*: 9 aufeinanderfolgende Punkte auf derselben Seite des Mittelwerts (Verschiebung/Bias) -* *Regel 3*: 6 aufeinanderfolgende Punkte, die stetig steigen oder fallen (Trend) -* *Regel 4*: 14 Punkte, die abwechselnd auf und ab gehen (Oszillation) -* *Regel 5*: 2 von 3 Punkten jenseits von 2σ auf derselben Seite -* *Regel 6*: 4 von 5 Punkten jenseits von 1σ auf derselben Seite -* *Regel 7*: 15 Punkte innerhalb von 1σ (verdächtig niedrige Varianz) -* *Regel 8*: 8 Punkte außerhalb von ±1σ, aber keiner jenseits von ±3σ (systematische Oszillation) -* *Allgemeine vs. Spezielle Ursache*: Unterscheidung zwischen inhärenter und zuordenbarer Variation -* *Zonen A/B/C*: Aufteilung der Regelkarte in 6 Zonen (jeweils 1σ breit) -* *Falsch-Positiv-Abwägung*: Mehr aktive Regeln = höhere Sensitivität, aber mehr Fehlalarme +Regel 1:: Ein Punkt jenseits von 3σ (Ausreißer) + +Regel 2:: 9 aufeinanderfolgende Punkte auf derselben Seite des Mittelwerts (Verschiebung/Bias) + +Regel 3:: 6 aufeinanderfolgende Punkte, die stetig steigen oder fallen (Trend) + +Regel 4:: 14 Punkte, die abwechselnd auf und ab gehen (Oszillation) + +Regel 5:: 2 von 3 Punkten jenseits von 2σ auf derselben Seite + +Regel 6:: 4 von 5 Punkten jenseits von 1σ auf derselben Seite + +Regel 7:: 15 Punkte innerhalb von 1σ (verdächtig niedrige Varianz) + +Regel 8:: 8 Punkte außerhalb von ±1σ, aber keiner jenseits von ±3σ (systematische Oszillation) + +Allgemeine vs. Spezielle Ursache:: Unterscheidung zwischen inhärenter und zuordenbarer Variation + +Zonen A/B/C:: Aufteilung der Regelkarte in 6 Zonen (jeweils 1σ breit) + +Falsch-Positiv-Abwägung:: Mehr aktive Regeln = höhere Sensitivität, aber mehr Fehlalarme + Schlüsselvertreter:: Lloyd S. Nelson (1984, Journal of Quality Technology) *Beziehung zu anderen Ankern*: -* *Control Chart (Shewhart)*: Nelson Rules werden auf Regelkarten angewendet -* *<>*: Nelson Rules sind ein Werkzeug innerhalb der Statistischen Prozesskontrolle -* *Western Electric Rules*: Vorgänger; Nelson Rules erweitern diese mit Regeln 5-8 +Control Chart (Shewhart):: Nelson Rules werden auf Regelkarten angewendet + +<>:: Nelson Rules sind ein Werkzeug innerhalb der Statistischen Prozesskontrolle + +Western Electric Rules:: Vorgänger; Nelson Rules erweitern diese mit Regeln 5-8 + *Wann zu verwenden*: diff --git a/docs/anchors/problem-space-nvc.adoc b/docs/anchors/problem-space-nvc.adoc index 5a3358e..cf7381d 100644 --- a/docs/anchors/problem-space-nvc.adoc +++ b/docs/anchors/problem-space-nvc.adoc @@ -8,13 +8,20 @@ Full Name:: Problem Space in Nonviolent Communication *Core Concepts*: -* *Observations*: Concrete, objective facts without evaluation -* *Feelings*: Emotions arising from observations -* *Needs*: Universal human needs underlying feelings -* *Requests*: Specific, actionable requests (not demands) -* *Empathic connection*: Understanding before problem-solving -* *Separating observation from interpretation*: Avoiding judgment -* *Needs-based conflict resolution*: Finding solutions that meet everyone's needs +Observations:: Concrete, objective facts without evaluation + +Feelings:: Emotions arising from observations + +Needs:: Universal human needs underlying feelings + +Requests:: Specific, actionable requests (not demands) + +Empathic connection:: Understanding before problem-solving + +Separating observation from interpretation:: Avoiding judgment + +Needs-based conflict resolution:: Finding solutions that meet everyone's needs + Key Proponent:: Marshall Rosenberg diff --git a/docs/anchors/problem-space-nvc.de.adoc b/docs/anchors/problem-space-nvc.de.adoc index 9a23370..5244fe0 100644 --- a/docs/anchors/problem-space-nvc.de.adoc +++ b/docs/anchors/problem-space-nvc.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: Problem Space in Nonviolent Communication *Kernkonzepte*: -* *Beobachtungen*: Konkrete, objektive Fakten ohne Bewertung -* *Gefühle*: Emotionen, die aus Beobachtungen entstehen -* *Bedürfnisse*: Universelle menschliche Bedürfnisse, die Gefühlen zugrunde liegen -* *Bitten*: Spezifische, umsetzbare Bitten (keine Forderungen) -* *Empathische Verbindung*: Verstehen vor Problemlösung -* *Trennung von Beobachtung und Interpretation*: Vermeidung von Urteilen -* *Bedürfnisbasierte Konfliktlösung*: Lösungen finden, die die Bedürfnisse aller erfüllen +Beobachtungen:: Konkrete, objektive Fakten ohne Bewertung + +Gefühle:: Emotionen, die aus Beobachtungen entstehen + +Bedürfnisse:: Universelle menschliche Bedürfnisse, die Gefühlen zugrunde liegen + +Bitten:: Spezifische, umsetzbare Bitten (keine Forderungen) + +Empathische Verbindung:: Verstehen vor Problemlösung + +Trennung von Beobachtung und Interpretation:: Vermeidung von Urteilen + +Bedürfnisbasierte Konfliktlösung:: Lösungen finden, die die Bedürfnisse aller erfüllen + Schlüsselvertreter:: Marshall Rosenberg diff --git a/docs/anchors/property-based-testing.adoc b/docs/anchors/property-based-testing.adoc index 62881e1..3a6c89c 100644 --- a/docs/anchors/property-based-testing.adoc +++ b/docs/anchors/property-based-testing.adoc @@ -8,15 +8,24 @@ Also known as:: Generative Testing, QuickCheck-style Testing *Core Concepts*: -* *Properties*: Invariants that should always hold -* *Generators*: Automatic test data creation -* *Shrinking*: Minimizing failing test cases to simplest form -* *Universal quantification*: Testing "for all inputs" -* *Specification testing*: Testing high-level properties, not examples -* *Edge case discovery*: Finds cases you didn't think of -* *Complementary to example-based*: Works alongside traditional unit tests -* *Stateful testing*: Testing sequences of operations -* *Model-based testing*: Compare implementation against simpler model +Properties:: Invariants that should always hold + +Generators:: Automatic test data creation + +Shrinking:: Minimizing failing test cases to simplest form + +Universal quantification:: Testing "for all inputs" + +Specification testing:: Testing high-level properties, not examples + +Edge case discovery:: Finds cases you didn't think of + +Complementary to example-based:: Works alongside traditional unit tests + +Stateful testing:: Testing sequences of operations + +Model-based testing:: Compare implementation against simpler model + Key Tools:: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) diff --git a/docs/anchors/property-based-testing.de.adoc b/docs/anchors/property-based-testing.de.adoc index 90bc482..3eea633 100644 --- a/docs/anchors/property-based-testing.de.adoc +++ b/docs/anchors/property-based-testing.de.adoc @@ -8,15 +8,24 @@ Auch bekannt als:: Generatives Testen, QuickCheck-artiges Testen *Kernkonzepte*: -* *Properties (Eigenschaften)*: Invarianten, die immer gelten sollten -* *Generatoren*: Automatische Testdatenerzeugung -* *Shrinking (Vereinfachung)*: Minimierung fehlschlagender Testfälle zur einfachsten Form -* *Universelle Quantifizierung*: Testen "für alle Eingaben" -* *Spezifikationstesten*: Testen von High-Level-Eigenschaften, nicht Beispielen -* *Edge-Case-Entdeckung*: Findet Fälle, an die man nicht gedacht hat -* *Komplementär zu beispielbasiert*: Funktioniert neben traditionellen Unit-Tests -* *Zustandsbehaftetes Testen*: Testen von Operationssequenzen -* *Modellbasiertes Testen*: Implementierung gegen einfacheres Modell vergleichen +Properties (Eigenschaften):: Invarianten, die immer gelten sollten + +Generatoren:: Automatische Testdatenerzeugung + +Shrinking (Vereinfachung):: Minimierung fehlschlagender Testfälle zur einfachsten Form + +Universelle Quantifizierung:: Testen "für alle Eingaben" + +Spezifikationstesten:: Testen von High-Level-Eigenschaften, nicht Beispielen + +Edge-Case-Entdeckung:: Findet Fälle, an die man nicht gedacht hat + +Komplementär zu beispielbasiert:: Funktioniert neben traditionellen Unit-Tests + +Zustandsbehaftetes Testen:: Testen von Operationssequenzen + +Modellbasiertes Testen:: Implementierung gegen einfacheres Modell vergleichen + Wichtige Werkzeuge:: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET) diff --git a/docs/anchors/pugh-matrix.adoc b/docs/anchors/pugh-matrix.adoc index 5ec058f..f5791cc 100644 --- a/docs/anchors/pugh-matrix.adoc +++ b/docs/anchors/pugh-matrix.adoc @@ -8,13 +8,20 @@ Full Name:: Pugh Decision Matrix (also Pugh Controlled Convergence) *Core Concepts*: -* *Baseline comparison*: Compare alternatives against a reference solution -* *Criteria weighting*: Assign importance to evaluation criteria -* *Relative scoring*: Better (+), Same (S), Worse (-) than baseline -* *Structured evaluation*: Systematic comparison across multiple dimensions -* *Iterative refinement*: Multiple rounds to converge on best solution -* *Team decision-making*: Facilitates group consensus -* *Hybrid solutions*: Combine strengths of different alternatives +Baseline comparison:: Compare alternatives against a reference solution + +Criteria weighting:: Assign importance to evaluation criteria + +Relative scoring:: Better (+), Same (S), Worse (-) than baseline + +Structured evaluation:: Systematic comparison across multiple dimensions + +Iterative refinement:: Multiple rounds to converge on best solution + +Team decision-making:: Facilitates group consensus + +Hybrid solutions:: Combine strengths of different alternatives + Key Proponent:: Stuart Pugh diff --git a/docs/anchors/pugh-matrix.de.adoc b/docs/anchors/pugh-matrix.de.adoc index 9972a09..96040ae 100644 --- a/docs/anchors/pugh-matrix.de.adoc +++ b/docs/anchors/pugh-matrix.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: Pugh Decision Matrix (also Pugh Controlled Convergence) *Kernkonzepte*: -* *Baseline-Vergleich*: Alternativen gegen eine Referenzlösung vergleichen -* *Kriteriengewichtung*: Wichtigkeit zu Evaluationskriterien zuweisen -* *Relative Bewertung*: Besser (+), Gleich (S), Schlechter (-) als Baseline -* *Strukturierte Evaluation*: Systematischer Vergleich über mehrere Dimensionen -* *Iterative Verfeinerung*: Mehrere Runden zur Konvergenz auf beste Lösung -* *Team-Entscheidungsfindung*: Erleichtert Gruppenkonsens -* *Hybridlösungen*: Stärken verschiedener Alternativen kombinieren +Baseline-Vergleich:: Alternativen gegen eine Referenzlösung vergleichen + +Kriteriengewichtung:: Wichtigkeit zu Evaluationskriterien zuweisen + +Relative Bewertung:: Besser (+), Gleich (S), Schlechter (-) als Baseline + +Strukturierte Evaluation:: Systematischer Vergleich über mehrere Dimensionen + +Iterative Verfeinerung:: Mehrere Runden zur Konvergenz auf beste Lösung + +Team-Entscheidungsfindung:: Erleichtert Gruppenkonsens + +Hybridlösungen:: Stärken verschiedener Alternativen kombinieren + Schlüsselvertreter:: Stuart Pugh diff --git a/docs/anchors/pyramid-principle.adoc b/docs/anchors/pyramid-principle.adoc index 2ca0552..69d9a79 100644 --- a/docs/anchors/pyramid-principle.adoc +++ b/docs/anchors/pyramid-principle.adoc @@ -8,15 +8,24 @@ Full Name:: The Minto Pyramid Principle according to Barbara Minto *Core Concepts*: -* *Governing Thought*: Single key message at the top of the pyramid -* *SCQ Framework*: Situation → Complication → Question → Answer structure for setting context -* *MECE Principle*: Mutually Exclusive, Collectively Exhaustive grouping of ideas -* *Vertical Logic*: Each level answers "Why?" of the level above it -* *Horizontal Logic*: Arguments at the same level grouped deductively or inductively -* *Top-Down Delivery*: Present conclusion first, then supporting arguments -* *Pyramid Structure*: One central idea supported by groups of three supporting ideas -* *BLUF*: Bottom Line Up Front - lead with the conclusion -* *Deductive vs. Inductive Reasoning*: Choose appropriate logic for horizontal grouping +Governing Thought:: Single key message at the top of the pyramid + +SCQ Framework:: Situation → Complication → Question → Answer structure for setting context + +MECE Principle:: Mutually Exclusive, Collectively Exhaustive grouping of ideas + +Vertical Logic:: Each level answers "Why?" of the level above it + +Horizontal Logic:: Arguments at the same level grouped deductively or inductively + +Top-Down Delivery:: Present conclusion first, then supporting arguments + +Pyramid Structure:: One central idea supported by groups of three supporting ideas + +BLUF:: Bottom Line Up Front - lead with the conclusion + +Deductive vs. Inductive Reasoning:: Choose appropriate logic for horizontal grouping + Key Proponent:: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) diff --git a/docs/anchors/pyramid-principle.de.adoc b/docs/anchors/pyramid-principle.de.adoc index 08df0d2..71723c6 100644 --- a/docs/anchors/pyramid-principle.de.adoc +++ b/docs/anchors/pyramid-principle.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: The Minto Pyramid Principle according to Barbara Minto *Kernkonzepte*: -* *Leitgedanke*: Einzelne Kernbotschaft an der Spitze der Pyramide -* *SCQ-Framework*: Situation → Komplikation → Frage → Antwort-Struktur zur Kontextgebung -* *MECE-Prinzip*: Sich gegenseitig ausschließende, gemeinsam erschöpfende Gruppierung von Ideen -* *Vertikale Logik*: Jede Ebene beantwortet das "Warum?" der darüber liegenden Ebene -* *Horizontale Logik*: Argumente auf derselben Ebene deduktiv oder induktiv gruppiert -* *Top-Down-Präsentation*: Schlussfolgerung zuerst präsentieren, dann unterstützende Argumente -* *Pyramidenstruktur*: Eine zentrale Idee, unterstützt durch Gruppen von drei unterstützenden Ideen -* *BLUF*: Bottom Line Up Front - mit der Schlussfolgerung beginnen -* *Deduktives vs. Induktives Denken*: Geeignete Logik für horizontale Gruppierung wählen +Leitgedanke:: Einzelne Kernbotschaft an der Spitze der Pyramide + +SCQ-Framework:: Situation → Komplikation → Frage → Antwort-Struktur zur Kontextgebung + +MECE-Prinzip:: Sich gegenseitig ausschließende, gemeinsam erschöpfende Gruppierung von Ideen + +Vertikale Logik:: Jede Ebene beantwortet das "Warum?" der darüber liegenden Ebene + +Horizontale Logik:: Argumente auf derselben Ebene deduktiv oder induktiv gruppiert + +Top-Down-Präsentation:: Schlussfolgerung zuerst präsentieren, dann unterstützende Argumente + +Pyramidenstruktur:: Eine zentrale Idee, unterstützt durch Gruppen von drei unterstützenden Ideen + +BLUF:: Bottom Line Up Front - mit der Schlussfolgerung beginnen + +Deduktives vs. Induktives Denken:: Geeignete Logik für horizontale Gruppierung wählen + Schlüsselvertreterin:: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987) diff --git a/docs/anchors/rubber-duck-debugging.adoc b/docs/anchors/rubber-duck-debugging.adoc index f26183e..be3598d 100644 --- a/docs/anchors/rubber-duck-debugging.adoc +++ b/docs/anchors/rubber-duck-debugging.adoc @@ -8,14 +8,22 @@ Full Name:: Rubber Duck Debugging *Core Concepts*: -* *Explain to Understand*: Articulating a problem aloud surfaces gaps in understanding -* *Step-by-Step Verbalization*: Force yourself to go through code/logic line by line -* *Assumption Surfacing*: Speaking aloud exposes implicit assumptions that may be wrong -* *No Expertise Required*: The "listener" (rubber duck, colleague, LLM) need not be an expert -* *Slowing Down*: The act of explaining forces a slower, more deliberate thought process -* *External Cognition*: Verbalizing creates an external representation that aids debugging -* *Self-Directed Learning*: Often the explainer solves the problem before finishing the explanation -* *Teaching to Learn*: Related to the Feynman Technique and learning-by-teaching principle +Explain to Understand:: Articulating a problem aloud surfaces gaps in understanding + +Step-by-Step Verbalization:: Force yourself to go through code/logic line by line + +Assumption Surfacing:: Speaking aloud exposes implicit assumptions that may be wrong + +No Expertise Required:: The "listener" (rubber duck, colleague, LLM) need not be an expert + +Slowing Down:: The act of explaining forces a slower, more deliberate thought process + +External Cognition:: Verbalizing creates an external representation that aids debugging + +Self-Directed Learning:: Often the explainer solves the problem before finishing the explanation + +Teaching to Learn:: Related to the Feynman Technique and learning-by-teaching principle + Key Origin:: "The Pragmatic Programmer" by Andrew Hunt and David Thomas (1999), referencing earlier programmer folklore diff --git a/docs/anchors/rubber-duck-debugging.de.adoc b/docs/anchors/rubber-duck-debugging.de.adoc index 23003bf..7fc3460 100644 --- a/docs/anchors/rubber-duck-debugging.de.adoc +++ b/docs/anchors/rubber-duck-debugging.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: Rubber Duck Debugging *Kernkonzepte*: -* *Erklären zum Verstehen*: Lautes Artikulieren eines Problems macht Verständnislücken sichtbar -* *Schrittweise Verbalisierung*: Zwingt dazu, Code/Logik Zeile für Zeile durchzugehen -* *Annahmen sichtbar machen*: Lautes Sprechen legt implizite Annahmen offen, die falsch sein könnten -* *Keine Expertise erforderlich*: Der "Zuhörer" (Gummiente, Kollege, LLM) muss kein Experte sein -* *Verlangsamung*: Der Akt des Erklärens erzwingt einen langsameren, überlegteren Denkprozess -* *Externe Kognition*: Verbalisierung schafft eine externe Darstellung, die beim Debuggen hilft -* *Selbstgesteuertes Lernen*: Oft löst der Erklärende das Problem, bevor er die Erklärung beendet -* *Durch Lehren lernen*: Verwandt mit der Feynman-Technik und dem Lern-durch-Lehren-Prinzip +Erklären zum Verstehen:: Lautes Artikulieren eines Problems macht Verständnislücken sichtbar + +Schrittweise Verbalisierung:: Zwingt dazu, Code/Logik Zeile für Zeile durchzugehen + +Annahmen sichtbar machen:: Lautes Sprechen legt implizite Annahmen offen, die falsch sein könnten + +Keine Expertise erforderlich:: Der "Zuhörer" (Gummiente, Kollege, LLM) muss kein Experte sein + +Verlangsamung:: Der Akt des Erklärens erzwingt einen langsameren, überlegteren Denkprozess + +Externe Kognition:: Verbalisierung schafft eine externe Darstellung, die beim Debuggen hilft + +Selbstgesteuertes Lernen:: Oft löst der Erklärende das Problem, bevor er die Erklärung beendet + +Durch Lehren lernen:: Verwandt mit der Feynman-Technik und dem Lern-durch-Lehren-Prinzip + Schlüsselursprung:: "The Pragmatic Programmer" von Andrew Hunt und David Thomas (1999), unter Bezugnahme auf ältere Programmiererfolklore diff --git a/docs/anchors/semantic-versioning.adoc b/docs/anchors/semantic-versioning.adoc index 53282a3..4def9a2 100644 --- a/docs/anchors/semantic-versioning.adoc +++ b/docs/anchors/semantic-versioning.adoc @@ -8,15 +8,21 @@ Full Name:: Semantic Versioning Specification *Core Concepts*: -* *Version format*: MAJOR.MINOR.PATCH (e.g., 2.4.7) -** *MAJOR*: Incompatible API changes (breaking changes) -** *MINOR*: Backward-compatible functionality additions -** *PATCH*: Backward-compatible bug fixes -** *Pre-release versions*: Append hyphen and identifiers (e.g., 1.0.0-alpha.1) -* *Build metadata*: Append plus sign and identifiers (e.g., 1.0.0+20241111) -* *Version precedence*: Clear rules for version comparison -* *Initial development*: 0.y.z for initial development (API unstable) -* *Public API declaration*: Once public API declared, version dependencies matter +Version format:: ++ +MAJOR::: Incompatible API changes (breaking changes) +MINOR::: Backward-compatible functionality additions +PATCH::: Backward-compatible bug fixes +Pre-release versions::: Append hyphen and identifiers (e.g., 1.0.0-alpha.1) + +Build metadata:: Append plus sign and identifiers (e.g., 1.0.0+20241111) + +Version precedence:: Clear rules for version comparison + +Initial development:: 0.y.z for initial development (API unstable) + +Public API declaration:: Once public API declared, version dependencies matter + Key Proponent:: Tom Preston-Werner diff --git a/docs/anchors/semantic-versioning.de.adoc b/docs/anchors/semantic-versioning.de.adoc index 3d761c8..9968b54 100644 --- a/docs/anchors/semantic-versioning.de.adoc +++ b/docs/anchors/semantic-versioning.de.adoc @@ -8,15 +8,21 @@ Vollständiger Name:: Semantic Versioning Specification *Kernkonzepte*: -* *Versionsformat*: MAJOR.MINOR.PATCH (z.B. 2.4.7) -** *MAJOR*: Inkompatible API-Änderungen (Breaking Changes) -** *MINOR*: Rückwärtskompatible Funktionserweiterungen -** *PATCH*: Rückwärtskompatible Fehlerbehebungen -** *Pre-Release-Versionen*: Bindestrich und Identifikatoren anhängen (z.B. 1.0.0-alpha.1) -* *Build-Metadaten*: Pluszeichen und Identifikatoren anhängen (z.B. 1.0.0+20241111) -* *Versionspriorität*: Klare Regeln für Versionsvergleich -* *Initiale Entwicklung*: 0.y.z für initiale Entwicklung (API instabil) -* *Public API-Deklaration*: Sobald public API deklariert, sind Versionsabhängigkeiten wichtig +Versionsformat:: ++ +MAJOR::: Inkompatible API-Änderungen (Breaking Changes) +MINOR::: Rückwärtskompatible Funktionserweiterungen +PATCH::: Rückwärtskompatible Fehlerbehebungen +Pre-Release-Versionen::: Bindestrich und Identifikatoren anhängen (z.B. 1.0.0-alpha.1) + +Build-Metadaten:: Pluszeichen und Identifikatoren anhängen (z.B. 1.0.0+20241111) + +Versionspriorität:: Klare Regeln für Versionsvergleich + +Initiale Entwicklung:: 0.y.z für initiale Entwicklung (API instabil) + +Public API-Deklaration:: Sobald public API deklariert, sind Versionsabhängigkeiten wichtig + Schlüsselvertreter:: Tom Preston-Werner diff --git a/docs/anchors/socratic-method.adoc b/docs/anchors/socratic-method.adoc index ccec3c4..addc5f5 100644 --- a/docs/anchors/socratic-method.adoc +++ b/docs/anchors/socratic-method.adoc @@ -8,15 +8,24 @@ Full Name:: Socratic Method (also Socratic Dialogue, Elenchus) *Core Concepts*: -* *Guided Discovery*: Lead learners to insights through questions rather than direct instruction -* *Elenchus*: Cross-examination technique to expose contradictions in beliefs -* *Maieutics*: "Midwifery of ideas" – helping others give birth to knowledge they already possess -* *Aporia*: State of productive confusion that motivates deeper inquiry -* *Question Hierarchy*: Progress from clarifying questions to probing assumptions to exploring implications -* *Dialectic Method*: Structured dialogue to arrive at truth through reasoned argument -* *Non-assertive Teaching*: Teacher claims ignorance, guides through questions -* *Assumption Surfacing*: Make implicit beliefs explicit through systematic questioning -* *Logical Consistency*: Test ideas for internal coherence and contradictions +Guided Discovery:: Lead learners to insights through questions rather than direct instruction + +Elenchus:: Cross-examination technique to expose contradictions in beliefs + +Maieutics:: "Midwifery of ideas" – helping others give birth to knowledge they already possess + +Aporia:: State of productive confusion that motivates deeper inquiry + +Question Hierarchy:: Progress from clarifying questions to probing assumptions to exploring implications + +Dialectic Method:: Structured dialogue to arrive at truth through reasoned argument + +Non-assertive Teaching:: Teacher claims ignorance, guides through questions + +Assumption Surfacing:: Make implicit beliefs explicit through systematic questioning + +Logical Consistency:: Test ideas for internal coherence and contradictions + Key Proponent:: Socrates (via Plato's dialogues, ~400 BCE) diff --git a/docs/anchors/socratic-method.de.adoc b/docs/anchors/socratic-method.de.adoc index 436521d..a09577a 100644 --- a/docs/anchors/socratic-method.de.adoc +++ b/docs/anchors/socratic-method.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: Sokratische Methode (auch Sokratischer Dialog, Elenchos) *Kernkonzepte*: -* *Geführte Entdeckung*: Lernende durch Fragen zu Einsichten führen statt direkter Instruktion -* *Elenchos*: Kreuzverhör-Technik zur Aufdeckung von Widersprüchen in Überzeugungen -* *Maieutik*: "Hebammenkunst der Ideen" – anderen helfen, Wissen zu gebären, das sie bereits besitzen -* *Aporie*: Zustand produktiver Verwirrung, der tiefere Untersuchung motiviert -* *Fragenhierarchie*: Fortschritt von klärenden Fragen über Hinterfragen von Annahmen bis zur Erforschung von Implikationen -* *Dialektische Methode*: Strukturierter Dialog, um durch begründete Argumentation zur Wahrheit zu gelangen -* *Nicht-assertive Lehre*: Lehrer gibt Unwissenheit vor, führt durch Fragen -* *Annahmen sichtbar machen*: Implizite Überzeugungen durch systematisches Befragen explizit machen -* *Logische Konsistenz*: Ideen auf innere Kohärenz und Widersprüche testen +Geführte Entdeckung:: Lernende durch Fragen zu Einsichten führen statt direkter Instruktion + +Elenchos:: Kreuzverhör-Technik zur Aufdeckung von Widersprüchen in Überzeugungen + +Maieutik:: "Hebammenkunst der Ideen" – anderen helfen, Wissen zu gebären, das sie bereits besitzen + +Aporie:: Zustand produktiver Verwirrung, der tiefere Untersuchung motiviert + +Fragenhierarchie:: Fortschritt von klärenden Fragen über Hinterfragen von Annahmen bis zur Erforschung von Implikationen + +Dialektische Methode:: Strukturierter Dialog, um durch begründete Argumentation zur Wahrheit zu gelangen + +Nicht-assertive Lehre:: Lehrer gibt Unwissenheit vor, führt durch Fragen + +Annahmen sichtbar machen:: Implizite Überzeugungen durch systematisches Befragen explizit machen + +Logische Konsistenz:: Ideen auf innere Kohärenz und Widersprüche testen + Schlüsselvertreter:: Sokrates (via Platons Dialoge, ~400 v. Chr.) diff --git a/docs/anchors/solid-principles.adoc b/docs/anchors/solid-principles.adoc index e8254cc..8b60573 100644 --- a/docs/anchors/solid-principles.adoc +++ b/docs/anchors/solid-principles.adoc @@ -8,11 +8,16 @@ Full Name:: SOLID Object-Oriented Design Principles *Core Concepts*: -* *Single Responsibility Principle (SRP)*: Each class should have one responsibility -* *Open/Closed Principle (OCP)*: Entities should be open for extension, closed for modification -* *Liskov Substitution Principle (LSP)*: Subtypes must be substitutable for their base types -* *Interface Segregation Principle (ISP)*: Clients should not be forced to depend on interfaces they do not use -* *Dependency Inversion Principle (DIP)*: Depend on abstractions, not concrete implementations +Single Responsibility Principle (SRP):: Each class should have one responsibility + +Open/Closed Principle (OCP):: Entities should be open for extension, closed for modification + +Liskov Substitution Principle (LSP):: Subtypes must be substitutable for their base types + +Interface Segregation Principle (ISP):: Clients should not be forced to depend on interfaces they do not use + +Dependency Inversion Principle (DIP):: Depend on abstractions, not concrete implementations + Key Proponent:: Robert C. Martin ("Uncle Bob") diff --git a/docs/anchors/solid-principles.de.adoc b/docs/anchors/solid-principles.de.adoc index ac0b31e..56c4a43 100644 --- a/docs/anchors/solid-principles.de.adoc +++ b/docs/anchors/solid-principles.de.adoc @@ -8,11 +8,16 @@ Vollständiger Name:: SOLID Object-Oriented Design Principles *Kernkonzepte*: -* *Single Responsibility Principle (SRP)*: Jede Klasse sollte eine Verantwortlichkeit haben -* *Open/Closed Principle (OCP)*: Entitäten sollten offen für Erweiterung, geschlossen für Modifikation sein -* *Liskov Substitution Principle (LSP)*: Subtypen müssen durch ihre Basistypen ersetzbar sein -* *Interface Segregation Principle (ISP)*: Clients sollten nicht gezwungen werden, von Schnittstellen abzuhängen, die sie nicht nutzen -* *Dependency Inversion Principle (DIP)*: Von Abstraktionen abhängen, nicht von konkreten Implementierungen +Single Responsibility Principle (SRP):: Jede Klasse sollte eine Verantwortlichkeit haben + +Open/Closed Principle (OCP):: Entitäten sollten offen für Erweiterung, geschlossen für Modifikation sein + +Liskov Substitution Principle (LSP):: Subtypen müssen durch ihre Basistypen ersetzbar sein + +Interface Segregation Principle (ISP):: Clients sollten nicht gezwungen werden, von Schnittstellen abzuhängen, die sie nicht nutzen + +Dependency Inversion Principle (DIP):: Von Abstraktionen abhängen, nicht von konkreten Implementierungen + Schlüsselvertreter:: Robert C. Martin ("Uncle Bob") diff --git a/docs/anchors/sota.adoc b/docs/anchors/sota.adoc index ca8650b..1bf7801 100644 --- a/docs/anchors/sota.adoc +++ b/docs/anchors/sota.adoc @@ -8,13 +8,20 @@ Full Name:: State-of-the-Art *Core Concepts*: -* *Latest approaches*: Focus on the most current, cutting-edge methods and techniques -* *Research-grounded*: Reference current research papers, benchmarks, and empirical results -* *Comparative analysis*: Compare new approaches with existing or previous methods -* *Performance-focused*: Emphasize benchmark-leading and best-performing solutions -* *Up-to-date information*: Provide current, grounded information rather than outdated practices -* *Evidence-based*: Support claims with recent studies, benchmarks, and real-world implementations -* *Contextual awareness*: Consider the specific domain and timeframe for "state-of-the-art" +Latest approaches:: Focus on the most current, cutting-edge methods and techniques + +Research-grounded:: Reference current research papers, benchmarks, and empirical results + +Comparative analysis:: Compare new approaches with existing or previous methods + +Performance-focused:: Emphasize benchmark-leading and best-performing solutions + +Up-to-date information:: Provide current, grounded information rather than outdated practices + +Evidence-based:: Support claims with recent studies, benchmarks, and real-world implementations + +Contextual awareness:: Consider the specific domain and timeframe for "state-of-the-art" + *Usage Patterns*: diff --git a/docs/anchors/sota.de.adoc b/docs/anchors/sota.de.adoc index 9e1111c..ae52795 100644 --- a/docs/anchors/sota.de.adoc +++ b/docs/anchors/sota.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: State-of-the-Art *Kernkonzepte*: -* *Neueste Ansätze*: Fokus auf die aktuellsten, modernsten Methoden und Techniken -* *Forschungsbasiert*: Referenz auf aktuelle Forschungsarbeiten, Benchmarks und empirische Ergebnisse -* *Vergleichsanalyse*: Vergleich neuer Ansätze mit bestehenden oder früheren Methoden -* *Leistungsorientiert*: Betonung benchmark-führender und best-performanter Lösungen -* *Aktuelle Informationen*: Bereitstellung aktueller, fundierter Informationen statt veralteter Praktiken -* *Evidenzbasiert*: Untermauerung von Behauptungen mit neuesten Studien, Benchmarks und Real-World-Implementierungen -* *Kontextbewusstsein*: Berücksichtigung der spezifischen Domäne und des Zeitrahmens für "State-of-the-Art" +Neueste Ansätze:: Fokus auf die aktuellsten, modernsten Methoden und Techniken + +Forschungsbasiert:: Referenz auf aktuelle Forschungsarbeiten, Benchmarks und empirische Ergebnisse + +Vergleichsanalyse:: Vergleich neuer Ansätze mit bestehenden oder früheren Methoden + +Leistungsorientiert:: Betonung benchmark-führender und best-performanter Lösungen + +Aktuelle Informationen:: Bereitstellung aktueller, fundierter Informationen statt veralteter Praktiken + +Evidenzbasiert:: Untermauerung von Behauptungen mit neuesten Studien, Benchmarks und Real-World-Implementierungen + +Kontextbewusstsein:: Berücksichtigung der spezifischen Domäne und des Zeitrahmens für "State-of-the-Art" + *Nutzungsmuster*: diff --git a/docs/anchors/spc.adoc b/docs/anchors/spc.adoc index ae74dda..0e44512 100644 --- a/docs/anchors/spc.adoc +++ b/docs/anchors/spc.adoc @@ -9,25 +9,39 @@ Full Name:: Statistical Process Control *Core Concepts*: -* *Process monitoring*: Systematic statistical monitoring of running processes -* *Common Cause Variation*: Inherent, random fluctuation — stable and predictable -* *Special Cause Variation*: Assignable cause — unstable, correctable -* *Control Charts*: Central visual tool (see dedicated anchor) -* *Detection rules*: Nelson Rules, Western Electric Rules (see dedicated anchors) -* *Process Capability*: Indices Cp, Cpk (short-term) and Pp, Ppk (long-term) -* *In-Control*: Process exhibits only Common Cause Variation -* *Out-of-Control*: Special Cause detected — intervention required -* *Continuous Improvement*: SPC as a foundation for ongoing process improvement -* *DMAIC Control Phase*: SPC tools secure improvements within Six Sigma +Process monitoring:: Systematic statistical monitoring of running processes + +Common Cause Variation:: Inherent, random fluctuation — stable and predictable + +Special Cause Variation:: Assignable cause — unstable, correctable + +Control Charts:: Central visual tool (see dedicated anchor) + +Detection rules:: Nelson Rules, Western Electric Rules (see dedicated anchors) + +Process Capability:: Indices Cp, Cpk (short-term) and Pp, Ppk (long-term) + +In-Control:: Process exhibits only Common Cause Variation + +Out-of-Control:: Special Cause detected — intervention required + +Continuous Improvement:: SPC as a foundation for ongoing process improvement + +DMAIC Control Phase:: SPC tools secure improvements within Six Sigma + Key Proponents:: Walter A. Shewhart (founder), W. Edwards Deming (dissemination), Western Electric Company *Relationship to Other Anchors*: -* *Control Chart (Shewhart)*: Central tool within SPC -* *Nelson Rules*: Detection rules for Special Causes on Control Charts -* *Six Sigma*: Uses SPC particularly in the Control phase -* *Testing Pyramid*: Conceptual parallel — different levels of quality assurance +Control Chart (Shewhart):: Central tool within SPC + +Nelson Rules:: Detection rules for Special Causes on Control Charts + +Six Sigma:: Uses SPC particularly in the Control phase + +Testing Pyramid:: Conceptual parallel — different levels of quality assurance + *When to Use*: diff --git a/docs/anchors/spc.de.adoc b/docs/anchors/spc.de.adoc index a475d8c..9191708 100644 --- a/docs/anchors/spc.de.adoc +++ b/docs/anchors/spc.de.adoc @@ -9,25 +9,39 @@ Vollständiger Name:: Statistical Process Control *Kernkonzepte*: -* *Prozessüberwachung*: Systematische statistische Überwachung laufender Prozesse -* *Allgemeine Ursachen-Variation*: Inhärente, zufällige Schwankung — stabil und vorhersagbar -* *Spezielle Ursachen-Variation*: Zuordenbare Ursache — instabil, korrigierbar -* *Regelkarten*: Zentrales visuelles Werkzeug (siehe dedizierter Anker) -* *Erkennungsregeln*: Nelson Rules, Western Electric Rules (siehe dedizierte Anker) -* *Prozessfähigkeit*: Indizes Cp, Cpk (kurzfristig) und Pp, Ppk (langfristig) -* *Unter Kontrolle*: Prozess zeigt nur Variation durch allgemeine Ursachen -* *Außer Kontrolle*: Spezielle Ursache erkannt — Intervention erforderlich -* *Kontinuierliche Verbesserung*: SPC als Grundlage für fortlaufende Prozessverbesserung -* *DMAIC Control Phase*: SPC-Werkzeuge sichern Verbesserungen innerhalb von Six Sigma +Prozessüberwachung:: Systematische statistische Überwachung laufender Prozesse + +Allgemeine Ursachen-Variation:: Inhärente, zufällige Schwankung — stabil und vorhersagbar + +Spezielle Ursachen-Variation:: Zuordenbare Ursache — instabil, korrigierbar + +Regelkarten:: Zentrales visuelles Werkzeug (siehe dedizierter Anker) + +Erkennungsregeln:: Nelson Rules, Western Electric Rules (siehe dedizierte Anker) + +Prozessfähigkeit:: Indizes Cp, Cpk (kurzfristig) und Pp, Ppk (langfristig) + +Unter Kontrolle:: Prozess zeigt nur Variation durch allgemeine Ursachen + +Außer Kontrolle:: Spezielle Ursache erkannt — Intervention erforderlich + +Kontinuierliche Verbesserung:: SPC als Grundlage für fortlaufende Prozessverbesserung + +DMAIC Control Phase:: SPC-Werkzeuge sichern Verbesserungen innerhalb von Six Sigma + Schlüsselvertreter:: Walter A. Shewhart (Gründer), W. Edwards Deming (Verbreitung), Western Electric Company *Beziehung zu anderen Ankern*: -* *Control Chart (Shewhart)*: Zentrales Werkzeug innerhalb von SPC -* *Nelson Rules*: Erkennungsregeln für spezielle Ursachen auf Regelkarten -* *Six Sigma*: Nutzt SPC besonders in der Control-Phase -* *Testing Pyramid*: Konzeptuelle Parallele — verschiedene Ebenen der Qualitätssicherung +Control Chart (Shewhart):: Zentrales Werkzeug innerhalb von SPC + +Nelson Rules:: Erkennungsregeln für spezielle Ursachen auf Regelkarten + +Six Sigma:: Nutzt SPC besonders in der Control-Phase + +Testing Pyramid:: Konzeptuelle Parallele — verschiedene Ebenen der Qualitätssicherung + *Wann zu verwenden*: diff --git a/docs/anchors/spot-principle.adoc b/docs/anchors/spot-principle.adoc index c015c0b..72916ac 100644 --- a/docs/anchors/spot-principle.adoc +++ b/docs/anchors/spot-principle.adoc @@ -8,13 +8,20 @@ Full Name:: Single Point of Truth *Core Concepts*: -* *Implementation pattern*: Focuses on where and how data/logic is stored and accessed -* *Centralized location*: Each piece of information resides in exactly one place -* *Reference relationships*: Other locations reference the single point rather than duplicate it -* *Data consistency*: Eliminates synchronization issues and conflicting data -* *Update propagation*: Changes at the single point automatically affect all references -* *Clear ownership*: Explicit responsibility for maintaining each piece of truth -* *Code-level practice*: Applied at the code and system design level +Implementation pattern:: Focuses on where and how data/logic is stored and accessed + +Centralized location:: Each piece of information resides in exactly one place + +Reference relationships:: Other locations reference the single point rather than duplicate it + +Data consistency:: Eliminates synchronization issues and conflicting data + +Update propagation:: Changes at the single point automatically affect all references + +Clear ownership:: Explicit responsibility for maintaining each piece of truth + +Code-level practice:: Applied at the code and system design level + *When to Use*: diff --git a/docs/anchors/spot-principle.de.adoc b/docs/anchors/spot-principle.de.adoc index e4b5ad6..0511bad 100644 --- a/docs/anchors/spot-principle.de.adoc +++ b/docs/anchors/spot-principle.de.adoc @@ -8,13 +8,20 @@ Vollständiger Name:: Single Point of Truth *Kernkonzepte*: -* *Implementierungsmuster*: Fokussiert darauf, wo und wie Daten/Logik gespeichert und abgerufen werden -* *Zentraler Ort*: Jede Information befindet sich an genau einer Stelle -* *Referenzbeziehungen*: Andere Orte referenzieren den einzelnen Punkt, anstatt ihn zu duplizieren -* *Datenkonsistenz*: Eliminiert Synchronisationsprobleme und widersprüchliche Daten -* *Update-Propagierung*: Änderungen am einzelnen Punkt wirken sich automatisch auf alle Referenzen aus -* *Klare Verantwortlichkeit*: Explizite Zuständigkeit für die Pflege jedes Wahrheitsstücks -* *Code-Ebene-Praxis*: Angewendet auf Code- und Systemdesign-Ebene +Implementierungsmuster:: Fokussiert darauf, wo und wie Daten/Logik gespeichert und abgerufen werden + +Zentraler Ort:: Jede Information befindet sich an genau einer Stelle + +Referenzbeziehungen:: Andere Orte referenzieren den einzelnen Punkt, anstatt ihn zu duplizieren + +Datenkonsistenz:: Eliminiert Synchronisationsprobleme und widersprüchliche Daten + +Update-Propagierung:: Änderungen am einzelnen Punkt wirken sich automatisch auf alle Referenzen aus + +Klare Verantwortlichkeit:: Explizite Zuständigkeit für die Pflege jedes Wahrheitsstücks + +Code-Ebene-Praxis:: Angewendet auf Code- und Systemdesign-Ebene + *Wann zu verwenden*: diff --git a/docs/anchors/ssot-principle.adoc b/docs/anchors/ssot-principle.adoc index 54d3491..149dc87 100644 --- a/docs/anchors/ssot-principle.adoc +++ b/docs/anchors/ssot-principle.adoc @@ -8,14 +8,22 @@ Full Name:: Single Source of Truth *Core Concepts*: -* *Conceptual principle*: Focuses on establishing trust and authority for data -* *Authoritative source*: One canonical, trusted location for each piece of data -* *Data integrity*: All consumers reference the same trusted source -* *Version control*: Single source ensures consistent versioning -* *Derived data*: Other representations are derived from the single source -* *Trust and reliability*: The source is the definitive version when conflicts arise -* *System of record*: The primary data store for critical business information -* *Organizational practice*: Applied at the architecture and business process level +Conceptual principle:: Focuses on establishing trust and authority for data + +Authoritative source:: One canonical, trusted location for each piece of data + +Data integrity:: All consumers reference the same trusted source + +Version control:: Single source ensures consistent versioning + +Derived data:: Other representations are derived from the single source + +Trust and reliability:: The source is the definitive version when conflicts arise + +System of record:: The primary data store for critical business information + +Organizational practice:: Applied at the architecture and business process level + *Key Application Areas*: diff --git a/docs/anchors/ssot-principle.de.adoc b/docs/anchors/ssot-principle.de.adoc index 662834b..8fad7a2 100644 --- a/docs/anchors/ssot-principle.de.adoc +++ b/docs/anchors/ssot-principle.de.adoc @@ -8,14 +8,22 @@ Vollständiger Name:: Single Source of Truth *Kernkonzepte*: -* *Konzeptionelles Prinzip*: Fokussiert auf die Etablierung von Vertrauen und Autorität für Daten -* *Autoritative Quelle*: Eine kanonische, vertrauenswürdige Stelle für jedes Datenstück -* *Datenintegrität*: Alle Konsumenten referenzieren dieselbe vertrauenswürdige Quelle -* *Versionskontrolle*: Einzelne Quelle stellt konsistente Versionierung sicher -* *Abgeleitete Daten*: Andere Repräsentationen werden von der einzelnen Quelle abgeleitet -* *Vertrauen und Zuverlässigkeit*: Die Quelle ist die definitive Version bei Konflikten -* *System of Record*: Der primäre Datenspeicher für kritische Geschäftsinformationen -* *Organisationspraxis*: Angewendet auf Architektur- und Geschäftsprozessebene +Konzeptionelles Prinzip:: Fokussiert auf die Etablierung von Vertrauen und Autorität für Daten + +Autoritative Quelle:: Eine kanonische, vertrauenswürdige Stelle für jedes Datenstück + +Datenintegrität:: Alle Konsumenten referenzieren dieselbe vertrauenswürdige Quelle + +Versionskontrolle:: Einzelne Quelle stellt konsistente Versionierung sicher + +Abgeleitete Daten:: Andere Repräsentationen werden von der einzelnen Quelle abgeleitet + +Vertrauen und Zuverlässigkeit:: Die Quelle ist die definitive Version bei Konflikten + +System of Record:: Der primäre Datenspeicher für kritische Geschäftsinformationen + +Organisationspraxis:: Angewendet auf Architektur- und Geschäftsprozessebene + *Hauptanwendungsbereiche*: diff --git a/docs/anchors/tdd-chicago-school.adoc b/docs/anchors/tdd-chicago-school.adoc index 0ec72ca..8157cfe 100644 --- a/docs/anchors/tdd-chicago-school.adoc +++ b/docs/anchors/tdd-chicago-school.adoc @@ -9,12 +9,18 @@ Also known as:: Classicist TDD, Detroit School *Core Concepts*: -* *State-based testing*: Verify the state of objects after operations -* *Minimal mocking*: Use real objects whenever possible; mock only external dependencies -* *Inside-out development*: Start with core domain logic and build outward -* *Simplicity focus*: Emergent design through refactoring -* *Red-Green-Refactor*: The fundamental TDD cycle -* *YAGNI*: You Aren't Gonna Need It - avoid premature abstraction +State-based testing:: Verify the state of objects after operations + +Minimal mocking:: Use real objects whenever possible; mock only external dependencies + +Inside-out development:: Start with core domain logic and build outward + +Simplicity focus:: Emergent design through refactoring + +Red-Green-Refactor:: The fundamental TDD cycle + +YAGNI:: You Aren't Gonna Need It - avoid premature abstraction + Key Proponents:: Kent Beck, Martin Fowler diff --git a/docs/anchors/tdd-chicago-school.de.adoc b/docs/anchors/tdd-chicago-school.de.adoc index 2756094..9dba4b8 100644 --- a/docs/anchors/tdd-chicago-school.de.adoc +++ b/docs/anchors/tdd-chicago-school.de.adoc @@ -9,12 +9,18 @@ Auch bekannt als:: Klassisches TDD, Detroit School *Kernkonzepte*: -* *Zustandsbasiertes Testen*: Zustand von Objekten nach Operationen überprüfen -* *Minimales Mocking*: Echte Objekte verwenden, wann immer möglich; nur externe Abhängigkeiten mocken -* *Inside-Out-Entwicklung*: Mit Kern-Domänenlogik beginnen und nach außen bauen -* *Einfachheitsfokus*: Emergentes Design durch Refactoring -* *Red-Green-Refactor*: Der fundamentale TDD-Zyklus -* *YAGNI*: You Aren't Gonna Need It - vorzeitige Abstraktion vermeiden +Zustandsbasiertes Testen:: Zustand von Objekten nach Operationen überprüfen + +Minimales Mocking:: Echte Objekte verwenden, wann immer möglich; nur externe Abhängigkeiten mocken + +Inside-Out-Entwicklung:: Mit Kern-Domänenlogik beginnen und nach außen bauen + +Einfachheitsfokus:: Emergentes Design durch Refactoring + +Red-Green-Refactor:: Der fundamentale TDD-Zyklus + +YAGNI:: You Aren't Gonna Need It - vorzeitige Abstraktion vermeiden + Schlüsselvertreter:: Kent Beck, Martin Fowler diff --git a/docs/anchors/tdd-london-school.adoc b/docs/anchors/tdd-london-school.adoc index 3d34efe..386e089 100644 --- a/docs/anchors/tdd-london-school.adoc +++ b/docs/anchors/tdd-london-school.adoc @@ -9,12 +9,18 @@ Also known as:: Mockist TDD, Outside-In TDD *Core Concepts*: -* *Mock-heavy testing*: Heavy use of test doubles (mocks, stubs) to isolate units -* *Outside-in development*: Start from the outermost layers (UI, API) and work inward -* *Interaction-based testing*: Focus on verifying interactions between objects -* *Behavior verification*: Test how objects collaborate rather than state -* *Interface discovery*: Use tests to discover and define interfaces -* *Walking skeleton*: Build end-to-end functionality early, then fill in details +Mock-heavy testing:: Heavy use of test doubles (mocks, stubs) to isolate units + +Outside-in development:: Start from the outermost layers (UI, API) and work inward + +Interaction-based testing:: Focus on verifying interactions between objects + +Behavior verification:: Test how objects collaborate rather than state + +Interface discovery:: Use tests to discover and define interfaces + +Walking skeleton:: Build end-to-end functionality early, then fill in details + Key Proponents:: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") diff --git a/docs/anchors/tdd-london-school.de.adoc b/docs/anchors/tdd-london-school.de.adoc index 979b80c..c0f86c8 100644 --- a/docs/anchors/tdd-london-school.de.adoc +++ b/docs/anchors/tdd-london-school.de.adoc @@ -9,12 +9,18 @@ Auch bekannt als:: Mockist TDD, Outside-In TDD *Kernkonzepte*: -* *Mock-heavy Testing*: Intensive Nutzung von Test Doubles (Mocks, Stubs) zur Isolation von Units -* *Outside-In-Entwicklung*: Beginnen von den äußersten Schichten (UI, API) und nach innen arbeiten -* *Interaktionsbasiertes Testen*: Fokus auf Verifikation von Interaktionen zwischen Objekten -* *Verhaltensverifikation*: Testen, wie Objekte zusammenarbeiten, statt Zustand -* *Interface Discovery*: Tests nutzen, um Interfaces zu entdecken und zu definieren -* *Walking Skeleton*: End-to-End-Funktionalität früh aufbauen, dann Details ausfüllen +Mock-heavy Testing:: Intensive Nutzung von Test Doubles (Mocks, Stubs) zur Isolation von Units + +Outside-In-Entwicklung:: Beginnen von den äußersten Schichten (UI, API) und nach innen arbeiten + +Interaktionsbasiertes Testen:: Fokus auf Verifikation von Interaktionen zwischen Objekten + +Verhaltensverifikation:: Testen, wie Objekte zusammenarbeiten, statt Zustand + +Interface Discovery:: Tests nutzen, um Interfaces zu entdecken und zu definieren + +Walking Skeleton:: End-to-End-Funktionalität früh aufbauen, dann Details ausfüllen + Schlüsselvertreter:: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests") diff --git a/docs/anchors/testing-pyramid.adoc b/docs/anchors/testing-pyramid.adoc index f49aa23..2948833 100644 --- a/docs/anchors/testing-pyramid.adoc +++ b/docs/anchors/testing-pyramid.adoc @@ -8,16 +8,23 @@ Full Name:: Testing Pyramid according to Mike Cohn *Core Concepts*: -* *Three layers*: -** *Unit tests* (base): Many fast, isolated tests -** *Integration tests* (middle): Moderate number, test component interaction -** *End-to-end tests* (top): Few, test complete user journeys -* *Proportional distribution*: More unit tests, fewer E2E tests -* *Cost and speed*: Unit tests cheap and fast, E2E tests expensive and slow -* *Feedback loops*: Faster feedback from lower levels -* *Anti-pattern: Ice cream cone*: Too many E2E tests, too few unit tests -* *Test at the right level*: Don't test through UI what can be tested in isolation -* *Confidence gradient*: Balance confidence with execution speed +Three layers:: +* *Unit tests* (base): Many fast, isolated tests +* *Integration tests* (middle): Moderate number, test component interaction +* *End-to-end tests* (top): Few, test complete user journeys + +Proportional distribution:: More unit tests, fewer E2E tests + +Cost and speed:: Unit tests cheap and fast, E2E tests expensive and slow + +Feedback loops:: Faster feedback from lower levels + +Anti-pattern: Ice cream cone:: Too many E2E tests, too few unit tests + +Test at the right level:: Don't test through UI what can be tested in isolation + +Confidence gradient:: Balance confidence with execution speed + Key Proponent:: Mike Cohn ("Succeeding with Agile", 2009) diff --git a/docs/anchors/testing-pyramid.de.adoc b/docs/anchors/testing-pyramid.de.adoc index fbce410..1872cc7 100644 --- a/docs/anchors/testing-pyramid.de.adoc +++ b/docs/anchors/testing-pyramid.de.adoc @@ -8,16 +8,23 @@ Vollständiger Name:: Testing Pyramid nach Mike Cohn *Kernkonzepte*: -* *Drei Schichten*: -** *Unit-Tests* (Basis): Viele schnelle, isolierte Tests -** *Integrationstests* (Mitte): Moderate Anzahl, testen Komponenteninteraktion -** *End-to-End-Tests* (Spitze): Wenige, testen komplette User Journeys -* *Proportionale Verteilung*: Mehr Unit-Tests, weniger E2E-Tests -* *Kosten und Geschwindigkeit*: Unit-Tests günstig und schnell, E2E-Tests teuer und langsam -* *Feedback-Schleifen*: Schnelleres Feedback von unteren Ebenen -* *Anti-Pattern: Eistüte*: Zu viele E2E-Tests, zu wenige Unit-Tests -* *Auf der richtigen Ebene testen*: Nicht durch UI testen, was isoliert getestet werden kann -* *Vertrauensgradient*: Balance zwischen Vertrauen und Ausführungsgeschwindigkeit +Drei Schichten:: +* *Unit-Tests* (Basis): Viele schnelle, isolierte Tests +* *Integrationstests* (Mitte): Moderate Anzahl, testen Komponenteninteraktion +* *End-to-End-Tests* (Spitze): Wenige, testen komplette User Journeys + +Proportionale Verteilung:: Mehr Unit-Tests, weniger E2E-Tests + +Kosten und Geschwindigkeit:: Unit-Tests günstig und schnell, E2E-Tests teuer und langsam + +Feedback-Schleifen:: Schnelleres Feedback von unteren Ebenen + +Anti-Pattern: Eistüte:: Zu viele E2E-Tests, zu wenige Unit-Tests + +Auf der richtigen Ebene testen:: Nicht durch UI testen, was isoliert getestet werden kann + +Vertrauensgradient:: Balance zwischen Vertrauen und Ausführungsgeschwindigkeit + Schlüsselvertreter:: Mike Cohn ("Succeeding with Agile", 2009) diff --git a/docs/anchors/timtowtdi.adoc b/docs/anchors/timtowtdi.adoc index 7810a97..a9d9792 100644 --- a/docs/anchors/timtowtdi.adoc +++ b/docs/anchors/timtowtdi.adoc @@ -10,14 +10,22 @@ Also known as:: Tim Toady *Core Concepts*: -* *Multiple valid approaches*: Acknowledges that problems can be solved in different, equally valid ways -* *Developer freedom*: Trust developers to choose the right approach for their context -* *Expressiveness*: Languages and tools should support diverse problem-solving styles -* *Context-dependent decisions*: The "best" solution depends on constraints, team, and situation -* *No single canonical form*: Resist dogma — flexibility over prescription -* *Trade-off awareness*: Different approaches have different trade-offs; none is universally superior -* *Pragmatism over purity*: Practical results matter more than theoretical elegance -* *Collaborative decision-making*: When working with others, discuss approach rather than assume +Multiple valid approaches:: Acknowledges that problems can be solved in different, equally valid ways + +Developer freedom:: Trust developers to choose the right approach for their context + +Expressiveness:: Languages and tools should support diverse problem-solving styles + +Context-dependent decisions:: The "best" solution depends on constraints, team, and situation + +No single canonical form:: Resist dogma — flexibility over prescription + +Trade-off awareness:: Different approaches have different trade-offs; none is universally superior + +Pragmatism over purity:: Practical results matter more than theoretical elegance + +Collaborative decision-making:: When working with others, discuss approach rather than assume + Key Proponent:: Larry Wall (Perl programming language) diff --git a/docs/anchors/timtowtdi.de.adoc b/docs/anchors/timtowtdi.de.adoc index 19a39a0..0919177 100644 --- a/docs/anchors/timtowtdi.de.adoc +++ b/docs/anchors/timtowtdi.de.adoc @@ -10,14 +10,22 @@ Auch bekannt als:: Tim Toady *Kernkonzepte*: -* *Mehrere valide Ansätze*: Anerkennt, dass Probleme auf unterschiedliche, gleichermaßen valide Weisen gelöst werden können -* *Entwicklerfreiheit*: Vertrauen, dass Entwickler den richtigen Ansatz für ihren Kontext wählen -* *Ausdruckskraft*: Sprachen und Tools sollten diverse Problemlösungsstile unterstützen -* *Kontextabhängige Entscheidungen*: Die "beste" Lösung hängt von Rahmenbedingungen, Team und Situation ab -* *Keine einzelne kanonische Form*: Widerstand gegen Dogmen — Flexibilität über Vorschrift -* *Trade-off-Bewusstsein*: Verschiedene Ansätze haben unterschiedliche Trade-offs; keiner ist universell überlegen -* *Pragmatismus über Reinheit*: Praktische Ergebnisse zählen mehr als theoretische Eleganz -* *Kollaborative Entscheidungsfindung*: Bei Zusammenarbeit mit anderen den Ansatz diskutieren, statt anzunehmen +Mehrere valide Ansätze:: Anerkennt, dass Probleme auf unterschiedliche, gleichermaßen valide Weisen gelöst werden können + +Entwicklerfreiheit:: Vertrauen, dass Entwickler den richtigen Ansatz für ihren Kontext wählen + +Ausdruckskraft:: Sprachen und Tools sollten diverse Problemlösungsstile unterstützen + +Kontextabhängige Entscheidungen:: Die "beste" Lösung hängt von Rahmenbedingungen, Team und Situation ab + +Keine einzelne kanonische Form:: Widerstand gegen Dogmen — Flexibilität über Vorschrift + +Trade-off-Bewusstsein:: Verschiedene Ansätze haben unterschiedliche Trade-offs; keiner ist universell überlegen + +Pragmatismus über Reinheit:: Praktische Ergebnisse zählen mehr als theoretische Eleganz + +Kollaborative Entscheidungsfindung:: Bei Zusammenarbeit mit anderen den Ansatz diskutieren, statt anzunehmen + Schlüsselvertreter:: Larry Wall (Perl Programmiersprache) diff --git a/docs/anchors/todotxt-flavoured-markdown.adoc b/docs/anchors/todotxt-flavoured-markdown.adoc index fe89180..f693e11 100644 --- a/docs/anchors/todotxt-flavoured-markdown.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.adoc @@ -11,15 +11,24 @@ Also known as:: Enhanced Markdown Tasks, Markdown with todo.txt conventions *Core Concepts*: -* *Markdown task lists*: Standard GitHub-flavoured markdown syntax (`- [ ]` uncompleted, `- [x]` completed) -* *Priority markers*: Uses todo.txt priority notation `(A)`, `(B)`, `(C)` where `(A)` is highest priority -* *Project tags*: Prefixed with `+` to group related tasks (e.g., `+website`, `+semantic-anchors`) -* *Context tags*: Prefixed with `@` to indicate location/tool/context (e.g., `@computer`, `@home`, `@research`) -* *Key-value metadata*: Structured data pairs like `due:YYYY-MM-DD`, `priority:high`, or custom fields -* *Date tracking*: Creation dates and completion dates in ISO format (YYYY-MM-DD) -* *Human readability*: Plain text format that remains readable without special tools -* *Tool-agnostic*: Can be processed by both markdown renderers and todo.txt tools -* *Searchable and filterable*: Easy to grep/search by tags, priorities, or metadata +Markdown task lists:: Standard GitHub-flavoured markdown syntax (`- [ ]` uncompleted, `- [x]` completed) + +Priority markers:: Uses todo.txt priority notation `(A)`, `(B)`, `(C)` where `(A)` is highest priority + +Project tags:: Prefixed with `+` to group related tasks (e.g., `+website`, `+semantic-anchors`) + +Context tags:: Prefixed with `@` to indicate location/tool/context (e.g., `@computer`, `@home`, `@research`) + +Key-value metadata:: Structured data pairs like `due:YYYY-MM-DD`, `priority:high`, or custom fields + +Date tracking:: Creation dates and completion dates in ISO format (YYYY-MM-DD) + +Human readability:: Plain text format that remains readable without special tools + +Tool-agnostic:: Can be processed by both markdown renderers and todo.txt tools + +Searchable and filterable:: Easy to grep/search by tags, priorities, or metadata + *Pattern Structure*: diff --git a/docs/anchors/todotxt-flavoured-markdown.de.adoc b/docs/anchors/todotxt-flavoured-markdown.de.adoc index e524a52..8dd9cda 100644 --- a/docs/anchors/todotxt-flavoured-markdown.de.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.de.adoc @@ -11,15 +11,24 @@ Auch bekannt als:: Enhanced Markdown Tasks, Markdown with todo.txt conventions *Kernkonzepte*: -* *Markdown-Aufgabenlisten*: Standard GitHub-flavoured Markdown-Syntax (`- [ ]` unvollständig, `- [x]` vollständig) -* *Prioritätsmarkierungen*: Verwendet todo.txt-Prioritätsnotation `(A)`, `(B)`, `(C)`, wobei `(A)` höchste Priorität ist -* *Projekt-Tags*: Präfix `+` zur Gruppierung verwandter Aufgaben (z.B. `+website`, `+semantic-anchors`) -* *Kontext-Tags*: Präfix `@` zur Angabe von Ort/Tool/Kontext (z.B. `@computer`, `@home`, `@research`) -* *Key-Value-Metadaten*: Strukturierte Datenpaare wie `due:YYYY-MM-DD`, `priority:high` oder benutzerdefinierte Felder -* *Datumsverfolgung*: Erstellungs- und Abschlussdaten im ISO-Format (YYYY-MM-DD) -* *Menschliche Lesbarkeit*: Klartext-Format, das ohne spezielle Tools lesbar bleibt -* *Tool-agnostisch*: Kann sowohl von Markdown-Renderern als auch von todo.txt-Tools verarbeitet werden -* *Durchsuchbar und filterbar*: Einfach durch Tags, Prioritäten oder Metadaten zu grep/suchen +Markdown-Aufgabenlisten:: Standard GitHub-flavoured Markdown-Syntax (`- [ ]` unvollständig, `- [x]` vollständig) + +Prioritätsmarkierungen:: Verwendet todo.txt-Prioritätsnotation `(A)`, `(B)`, `(C)`, wobei `(A)` höchste Priorität ist + +Projekt-Tags:: Präfix `+` zur Gruppierung verwandter Aufgaben (z.B. `+website`, `+semantic-anchors`) + +Kontext-Tags:: Präfix `@` zur Angabe von Ort/Tool/Kontext (z.B. `@computer`, `@home`, `@research`) + +Key-Value-Metadaten:: Strukturierte Datenpaare wie `due:YYYY-MM-DD`, `priority:high` oder benutzerdefinierte Felder + +Datumsverfolgung:: Erstellungs- und Abschlussdaten im ISO-Format (YYYY-MM-DD) + +Menschliche Lesbarkeit:: Klartext-Format, das ohne spezielle Tools lesbar bleibt + +Tool-agnostisch:: Kann sowohl von Markdown-Renderern als auch von todo.txt-Tools verarbeitet werden + +Durchsuchbar und filterbar:: Einfach durch Tags, Prioritäten oder Metadaten zu grep/suchen + *Pattern Structure*: diff --git a/docs/anchors/user-story-mapping.adoc b/docs/anchors/user-story-mapping.adoc index 955de54..ffb3635 100644 --- a/docs/anchors/user-story-mapping.adoc +++ b/docs/anchors/user-story-mapping.adoc @@ -8,15 +8,24 @@ Full Name:: User Story Mapping according to Jeff Patton *Core Concepts*: -* *Narrative flow*: Horizontal arrangement of user activities -* *User activities*: High-level tasks users perform -* *User tasks*: Steps within activities -* *Walking skeleton*: Minimal end-to-end functionality first -* *Release planning*: Horizontal slices for releases -* *Prioritization by value*: Vertical ordering by importance -* *Shared understanding*: Collaborative mapping builds team alignment -* *Big picture view*: See the whole journey, not just backlog items -* *Opportunity for conversation*: Stories as placeholders for discussion +Narrative flow:: Horizontal arrangement of user activities + +User activities:: High-level tasks users perform + +User tasks:: Steps within activities + +Walking skeleton:: Minimal end-to-end functionality first + +Release planning:: Horizontal slices for releases + +Prioritization by value:: Vertical ordering by importance + +Shared understanding:: Collaborative mapping builds team alignment + +Big picture view:: See the whole journey, not just backlog items + +Opportunity for conversation:: Stories as placeholders for discussion + Key Proponent:: Jeff Patton ("User Story Mapping", 2014) diff --git a/docs/anchors/user-story-mapping.de.adoc b/docs/anchors/user-story-mapping.de.adoc index cfe426f..d2d9a9c 100644 --- a/docs/anchors/user-story-mapping.de.adoc +++ b/docs/anchors/user-story-mapping.de.adoc @@ -8,15 +8,24 @@ Vollständiger Name:: User Story Mapping according to Jeff Patton *Kernkonzepte*: -* *Narrativer Fluss*: Horizontale Anordnung von Nutzeraktivitäten -* *Nutzeraktivitäten*: High-Level-Aufgaben, die Nutzer ausführen -* *Nutzeraufgaben*: Schritte innerhalb von Aktivitäten -* *Walking Skeleton*: Minimale End-to-End-Funktionalität zuerst -* *Release-Planung*: Horizontale Scheiben für Releases -* *Priorisierung nach Wert*: Vertikale Ordnung nach Wichtigkeit -* *Gemeinsames Verständnis*: Kollaboratives Mapping baut Team-Alignment auf -* *Big-Picture-Sicht*: Die gesamte Journey sehen, nicht nur Backlog-Items -* *Gelegenheit für Konversation*: Stories als Platzhalter für Diskussion +Narrativer Fluss:: Horizontale Anordnung von Nutzeraktivitäten + +Nutzeraktivitäten:: High-Level-Aufgaben, die Nutzer ausführen + +Nutzeraufgaben:: Schritte innerhalb von Aktivitäten + +Walking Skeleton:: Minimale End-to-End-Funktionalität zuerst + +Release-Planung:: Horizontale Scheiben für Releases + +Priorisierung nach Wert:: Vertikale Ordnung nach Wichtigkeit + +Gemeinsames Verständnis:: Kollaboratives Mapping baut Team-Alignment auf + +Big-Picture-Sicht:: Die gesamte Journey sehen, nicht nur Backlog-Items + +Gelegenheit für Konversation:: Stories als Platzhalter für Diskussion + Schlüsselvertreter:: Jeff Patton ("User Story Mapping", 2014) diff --git a/docs/anchors/wardley-mapping.adoc b/docs/anchors/wardley-mapping.adoc index 8c0c4f0..419cd2b 100644 --- a/docs/anchors/wardley-mapping.adoc +++ b/docs/anchors/wardley-mapping.adoc @@ -6,16 +6,26 @@ ==== *Core Concepts*: -* *Value chain*: Map components from user needs down -* *Evolution axis*: Genesis → Custom → Product → Commodity -* *Movement*: Components naturally evolve over time -* *Situational awareness*: Understanding the landscape before deciding -* *Gameplay patterns*: Common strategic moves -* *Climatic patterns*: Forces that affect all players -* *Doctrine*: Universal principles of good strategy -* *Inertia*: Resistance to change in organizations -* *Strategic planning*: Visual approach to strategy -* *Build-Buy-Partner decisions*: Based on evolution stage +Value chain:: Map components from user needs down + +Evolution axis:: Genesis → Custom → Product → Commodity + +Movement:: Components naturally evolve over time + +Situational awareness:: Understanding the landscape before deciding + +Gameplay patterns:: Common strategic moves + +Climatic patterns:: Forces that affect all players + +Doctrine:: Universal principles of good strategy + +Inertia:: Resistance to change in organizations + +Strategic planning:: Visual approach to strategy + +Build-Buy-Partner decisions:: Based on evolution stage + Key Proponent:: Simon Wardley diff --git a/docs/anchors/wardley-mapping.de.adoc b/docs/anchors/wardley-mapping.de.adoc index f0d3ec2..c1a11f6 100644 --- a/docs/anchors/wardley-mapping.de.adoc +++ b/docs/anchors/wardley-mapping.de.adoc @@ -6,16 +6,26 @@ ==== *Kernkonzepte*: -* *Wertkette*: Komponenten von Nutzerbedürfnissen abwärts kartieren -* *Evolutionsachse*: Genesis → Custom → Product → Commodity -* *Bewegung*: Komponenten entwickeln sich natürlich über die Zeit -* *Situationsbewusstsein*: Die Landschaft verstehen, bevor man entscheidet -* *Gameplay-Muster*: Häufige strategische Züge -* *Klimatische Muster*: Kräfte, die alle Spieler betreffen -* *Doktrin*: Universelle Prinzipien guter Strategie -* *Trägheit*: Widerstand gegen Veränderung in Organisationen -* *Strategische Planung*: Visueller Ansatz zur Strategie -* *Build-Buy-Partner-Entscheidungen*: Basierend auf Evolutionsstufe +Wertkette:: Komponenten von Nutzerbedürfnissen abwärts kartieren + +Evolutionsachse:: Genesis → Custom → Product → Commodity + +Bewegung:: Komponenten entwickeln sich natürlich über die Zeit + +Situationsbewusstsein:: Die Landschaft verstehen, bevor man entscheidet + +Gameplay-Muster:: Häufige strategische Züge + +Klimatische Muster:: Kräfte, die alle Spieler betreffen + +Doktrin:: Universelle Prinzipien guter Strategie + +Trägheit:: Widerstand gegen Veränderung in Organisationen + +Strategische Planung:: Visueller Ansatz zur Strategie + +Build-Buy-Partner-Entscheidungen:: Basierend auf Evolutionsstufe + Schlüsselvertreter:: Simon Wardley diff --git a/docs/anchors/what-qualifies-as-a-semantic-anchor.adoc b/docs/anchors/what-qualifies-as-a-semantic-anchor.adoc index 9f868ac..f4178f7 100644 --- a/docs/anchors/what-qualifies-as-a-semantic-anchor.adoc +++ b/docs/anchors/what-qualifies-as-a-semantic-anchor.adoc @@ -8,11 +8,13 @@ A term qualifies as a semantic anchor when it activates a rich, well-defined con A good semantic anchor is: -* *Precise*: It references a specific, established body of knowledge or methodology with clear boundaries -* *Rich*: It activates multiple interconnected concepts, not just a single instruction or directive -* *Consistent*: Different users invoking it will get similar conceptual activation across contexts -* *Attributable*: It can be traced to key proponents, publications, established practices, or documented standards +Precise:: It references a specific, established body of knowledge or methodology with clear boundaries +Rich:: It activates multiple interconnected concepts, not just a single instruction or directive + +Consistent:: Different users invoking it will get similar conceptual activation across contexts + +Attributable:: It can be traced to key proponents, publications, established practices, or documented standards Semantic anchors exist on a spectrum from domain-heavy to interaction-heavy: @@ -26,9 +28,11 @@ Domain-heavy ◄───────────────────── The distinction isn't a strict category but rather a matter of emphasis. Most anchors have *both* dimensions: -* *Pyramid Principle*: Domain knowledge about structured communication + behavior change in how output is structured -* *TDD, London School*: Domain knowledge about testing + behavior change in how code is written -* *Socratic Method*: Interaction pattern for dialogue + domain knowledge from philosophical tradition +Pyramid Principle:: Domain knowledge about structured communication + behavior change in how output is structured + +TDD, London School:: Domain knowledge about testing + behavior change in how code is written + +Socratic Method:: Interaction pattern for dialogue + domain knowledge from philosophical tradition The quality bar is the same across this spectrum – all anchors must be well-defined, rich, and activatable. @@ -36,13 +40,15 @@ The quality bar is the same across this spectrum – all anchors must be well-de Well-known terms that are *not* semantic anchors because they lack definition depth: -* *"TLDR"*: Underspecified, no defined structure or methodology, vague instruction to "be short" -* *"ELI5"*: Vague target level, no pedagogical framework, no consistent interpretation -* *"Keep it short"*: Pure instruction, no conceptual depth or established methodology -* *"Make it simple"*: Ambiguous directive without reference to specific simplification frameworks +"TLDR":: Underspecified, no defined structure or methodology, vague instruction to "be short" -These terms may be useful in conversation, but they don't activate rich conceptual frameworks the way true semantic anchors do. +"ELI5":: Vague target level, no pedagogical framework, no consistent interpretation + +"Keep it short":: Pure instruction, no conceptual depth or established methodology +"Make it simple":: Ambiguous directive without reference to specific simplification frameworks + +These terms may be useful in conversation, but they don't activate rich conceptual frameworks the way true semantic anchors do. Below is a curated list of semantic anchors useful for software development, architecture, and requirements engineering. Each anchor includes related concepts and practices. diff --git a/docs/anchors/what-qualifies-as-a-semantic-anchor.de.adoc b/docs/anchors/what-qualifies-as-a-semantic-anchor.de.adoc index 307f697..7676265 100644 --- a/docs/anchors/what-qualifies-as-a-semantic-anchor.de.adoc +++ b/docs/anchors/what-qualifies-as-a-semantic-anchor.de.adoc @@ -8,11 +8,13 @@ Ein Begriff qualifiziert sich als semantischer Anker, wenn er ein reichhaltiges, Ein guter semantischer Anker ist: -* *Präzise*: Er referenziert einen spezifischen, etablierten Wissenskörper oder eine Methodologie mit klaren Grenzen -* *Reichhaltig*: Er aktiviert mehrere miteinander verbundene Konzepte, nicht nur eine einzelne Instruktion oder Direktive -* *Konsistent*: Verschiedene Benutzer, die ihn aufrufen, erhalten ähnliche konzeptionelle Aktivierung über Kontexte hinweg -* *Zuordenbar*: Er kann auf Schlüsselvertreter, Publikationen, etablierte Praktiken oder dokumentierte Standards zurückgeführt werden +Präzise:: Er referenziert einen spezifischen, etablierten Wissenskörper oder eine Methodologie mit klaren Grenzen +Reichhaltig:: Er aktiviert mehrere miteinander verbundene Konzepte, nicht nur eine einzelne Instruktion oder Direktive + +Konsistent:: Verschiedene Benutzer, die ihn aufrufen, erhalten ähnliche konzeptionelle Aktivierung über Kontexte hinweg + +Zuordenbar:: Er kann auf Schlüsselvertreter, Publikationen, etablierte Praktiken oder dokumentierte Standards zurückgeführt werden Semantische Anker existieren auf einem Spektrum von domänenlastig bis interaktionslastig: @@ -26,9 +28,11 @@ Domänenlastig ◄──────────────────── Die Unterscheidung ist keine strikte Kategorie, sondern eher eine Frage der Betonung. Die meisten Anker haben *beide* Dimensionen: -* *Pyramid Principle*: Domänenwissen über strukturierte Kommunikation + Verhaltensänderung in der Strukturierung von Output -* *TDD, London School*: Domänenwissen über Testing + Verhaltensänderung beim Schreiben von Code -* *Socratic Method*: Interaktionsmuster für Dialog + Domänenwissen aus philosophischer Tradition +Pyramid Principle:: Domänenwissen über strukturierte Kommunikation + Verhaltensänderung in der Strukturierung von Output + +TDD, London School:: Domänenwissen über Testing + Verhaltensänderung beim Schreiben von Code + +Socratic Method:: Interaktionsmuster für Dialog + Domänenwissen aus philosophischer Tradition Die Qualitätsmesslatte ist über das gesamte Spektrum gleich – alle Anker müssen wohldefiniert, reichhaltig und aktivierbar sein. @@ -36,13 +40,15 @@ Die Qualitätsmesslatte ist über das gesamte Spektrum gleich – alle Anker mü Wohlbekannte Begriffe, die *keine* semantischen Anker sind, weil ihnen Definitionstiefe fehlt: -* *"TLDR"*: Unterspezifiziert, keine definierte Struktur oder Methodologie, vage Instruktion "sei kurz" -* *"ELI5"*: Vages Zielniveau, kein pädagogisches Framework, keine konsistente Interpretation -* *"Keep it short"*: Reine Instruktion, keine konzeptionelle Tiefe oder etablierte Methodologie -* *"Make it simple"*: Mehrdeutige Direktive ohne Bezug zu spezifischen Vereinfachungs-Frameworks +"TLDR":: Unterspezifiziert, keine definierte Struktur oder Methodologie, vage Instruktion "sei kurz" -Diese Begriffe mögen in Konversationen nützlich sein, aber sie aktivieren keine reichhaltigen konzeptionellen Frameworks wie echte semantische Anker. +"ELI5":: Vages Zielniveau, kein pädagogisches Framework, keine konsistente Interpretation + +"Keep it short":: Reine Instruktion, keine konzeptionelle Tiefe oder etablierte Methodologie +"Make it simple":: Mehrdeutige Direktive ohne Bezug zu spezifischen Vereinfachungs-Frameworks + +Diese Begriffe mögen in Konversationen nützlich sein, aber sie aktivieren keine reichhaltigen konzeptionellen Frameworks wie echte semantische Anker. Unten ist eine kuratierte Liste semantischer Anker, nützlich für Softwareentwicklung, Architektur und Requirements Engineering. Jeder Anker enthält verwandte Konzepte und Praktiken.