LLM-Coding · raifdmueller · Feb 13, 2026 · Feb 13, 2026 · Feb 13, 2026
diff --git a/docs/anchors/_template.adoc b/docs/anchors/_template.adoc
@@ -7,15 +7,17 @@
 
 [%collapsible]
 ====
-*Also known as*: Alternative Name, Other Name
+Also known as:: Alternative Name, Other Name
 
 *Core Concepts*:
 
-* Concept 1
-* Concept 2
-* Concept 3
+Concept 1:: Brief description of concept 1
 
-*Key Proponents*: Author Name ("Book Title"), Another Author
+Concept 2:: Brief description of concept 2
+
+Concept 3:: Brief description of concept 3
+
+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
@@ -4,23 +4,28 @@
 
 [%collapsible]
 ====
-*Full Name*: Architecture Decision Records according to Michael Nygard
+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
-
-*Key Proponent*: Michael Nygard
+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
 
 *When to Use*:
 

diff --git a/docs/anchors/adr-according-to-nygard.de.adoc b/docs/anchors/adr-according-to-nygard.de.adoc
@@ -4,23 +4,29 @@
 
 [%collapsible]
 ====
-*Vollständiger Name*: Architecture Decision Records nach Michael Nygard
+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
-
-*Schlüsselvertreter*: Michael Nygard
+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
 
 *Wann zu verwenden*:
 

diff --git a/docs/anchors/arc42.adoc b/docs/anchors/arc42.adoc
@@ -5,27 +5,41 @@
 
 [%collapsible]
 ====
-*Full Name*: arc42 Architecture Documentation Template
+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.
-
-*Key Proponents*: Gernot Starke, Peter Hruschka
+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
 
 *When to Use*:
 

diff --git a/docs/anchors/arc42.de.adoc b/docs/anchors/arc42.de.adoc
@@ -5,27 +5,42 @@
 
 [%collapsible]
 ====
-*Vollständiger Name*: arc42 Architekturdokumentations-Template
+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.
-
-*Schlüsselvertreter*: Gernot Starke, Peter Hruschka
+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
 
 *Wann zu verwenden*:
 

diff --git a/docs/anchors/bem-methodology.adoc b/docs/anchors/bem-methodology.adoc
@@ -5,29 +5,40 @@
 
 [%collapsible]
 ====
-*Full Name*: Block Element Modifier (BEM) (S)CSS Methodology
+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*:
 
 * Block: `.search-form`
 * 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
@@ -5,29 +5,40 @@
 
 [%collapsible]
 ====
-*Vollständiger Name*: Block Element Modifier (BEM) (S)CSS-Methodologie
+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*:
 
 * Block: `.search-form`
 * 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
@@ -5,24 +5,32 @@
 
 [%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*:
 
-* *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
 
-*Key Proponents*: US Military (Army writing standards), adopted broadly in business and government
+Inverted Pyramid:: Most important information first, supporting details follow
 
-*Historical Context*: Standardized in military communication where rapid decision-making is critical; now standard in business writing (McKinsey, consulting, executive communication)
+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
+
+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 +47,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)
 ====