LLM-Coding · rdmueller · Jun 11, 2026 · Jun 11, 2026 · Jun 11, 2026
diff --git a/docs/about.adoc b/docs/about.adoc
@@ -81,6 +81,8 @@ Different people using the same semantic anchor will get *similar, predictable r
 
 Not every term makes a good semantic anchor. We maintain high quality standards:
 
+*Inclusion means precision, not endorsement.* The catalog is a lexicon: an anchor's presence means the term works as a precise pointer to a dense, well-documented concept — not that we recommend the practice. Where a method is contested or its current edition has drifted away from the training-data prior, the anchor says so in a _Criticism_ or _Current Status_ section with named, linked sources.
+
 === Precise
 References a *specific, established body of knowledge* with clear boundaries.
 

diff --git a/docs/about.de.adoc b/docs/about.de.adoc
@@ -110,6 +110,8 @@ Verschiedene Personen, die denselben semantischen Anker verwenden, erhalten *äh
 
 Nicht jeder Begriff eignet sich als semantischer Anker. Wir pflegen hohe Qualitätsstandards:
 
+*Aufnahme bedeutet Präzision, nicht Empfehlung.* Der Katalog ist ein Begriffslexikon: Dass ein Anker enthalten ist, heißt, der Begriff funktioniert als präziser Pointer auf ein dichtes, gut dokumentiertes Konzept — nicht, dass wir die Praxis empfehlen. Wo eine Methode umstritten ist oder ihre aktuelle Edition vom Trainingsdaten-Prior abgedriftet ist, sagt der Anker das in einer _Kritik_- oder _Aktueller-Stand_-Sektion mit benannten, verlinkten Quellen.
+
 === Präzise
 Referenziert einen *spezifischen, etablierten Wissensbereich* mit klaren Grenzen.
 

diff --git a/docs/anchors/arc42.adoc b/docs/anchors/arc42.adoc
@@ -49,4 +49,10 @@ Key Proponents:: Gernot Starke, Peter Hruschka
 * Medium to large software projects
 * When stakeholder communication is critical
 * Long-lived systems requiring maintainability
+
+[discrete]
+== *Current Status*:
+
+* The current release is template version https://arc42.org/download[9.0] (July 2025); the 12-section structure has been stable for many years — v9's main change splits Section 10 into a quality-requirements overview (10.1) and detailed scenarios (10.2)
+* What evolves is the material around the skeleton: help texts, translations, the tips-and-examples site https://docs.arc42.org/home/[docs.arc42.org], and the https://quality.arc42.org/[arc42 quality model (Q42)] — a prior trained on v7/v8 material knows the section structure correctly but misses the Section-10 split and Q42
 ====
diff --git a/docs/anchors/arc42.de.adoc b/docs/anchors/arc42.de.adoc
@@ -49,4 +49,10 @@ Schlüsselvertreter:: Gernot Starke, Peter Hruschka
 * Mittlere bis große Softwareprojekte
 * Wenn Stakeholder-Kommunikation kritisch ist
 * Langlebige Systeme, die Wartbarkeit erfordern
+
+[discrete]
+== *Aktueller Stand*:
+
+* Die aktuelle Version ist Template-Version https://arc42.org/download[9.0] (Juli 2025); die 12-Kapitel-Struktur ist seit vielen Jahren stabil — die Hauptänderung von v9 teilt Kapitel 10 in eine Qualitätsanforderungs-Übersicht (10.1) und detaillierte Szenarien (10.2)
+* Was sich entwickelt, ist das Material um das Skelett herum: Hilfetexte, Übersetzungen, die Tipps-und-Beispiele-Site https://docs.arc42.org/home/[docs.arc42.org] und das https://quality.arc42.org/[arc42-Qualitätsmodell (Q42)] — ein auf v7/v8 trainierter Prior kennt die Kapitelstruktur korrekt, verpasst aber den Kapitel-10-Split und Q42
 ====
diff --git a/docs/anchors/bem-methodology.adoc b/docs/anchors/bem-methodology.adoc
@@ -52,4 +52,9 @@ Key Proponents:: Yandex development team
 * Projects where developers need to quickly understand (S)CSS structure
 * Component-based architectures (React, Vue, Angular)
 
+[discrete]
+== *Current Status*:
+
+* The definition at https://getbem.com/[getbem.com] and https://bem.info/en/methodology/[bem.info] is stable and still accurate — BEM itself is a finished methodology
+* Mainstream practice has shifted: https://2024.stateofcss.com/en-US/tools/[State of CSS 2024] shows Tailwind CSS "far ahead of other, more traditional competitors", and the survey no longer even tracks naming methodologies as it did in https://2020.stateofcss.com/en-US/technologies/methodologies/[2020]; CSS Modules, CSS-in-JS, and native scoping/nesting/cascade layers solve by platform the global-namespace problem BEM solved by convention
 ====
diff --git a/docs/anchors/bem-methodology.de.adoc b/docs/anchors/bem-methodology.de.adoc
@@ -51,4 +51,9 @@ Schlüsselvertreter:: Yandex Entwicklungsteam
 * Projekte, bei denen Entwickler die (S)CSS-Struktur schnell verstehen müssen
 * Komponentenbasierte Architekturen (React, Vue, Angular)
 
+[discrete]
+== *Aktueller Stand*:
+
+* Die Definition auf https://getbem.com/[getbem.com] und https://bem.info/en/methodology/[bem.info] ist stabil und weiterhin korrekt — BEM selbst ist eine fertige Methodik
+* Die Praxis hat sich verschoben: https://2024.stateofcss.com/en-US/tools/[State of CSS 2024] zeigt Tailwind CSS "weit vor den traditionelleren Konkurrenten", und die Umfrage erfasst Naming-Methodologien gar nicht mehr wie noch https://2020.stateofcss.com/en-US/technologies/methodologies/[2020]; CSS Modules, CSS-in-JS und natives Scoping/Nesting/Cascade Layers lösen per Plattform das Global-Namespace-Problem, das BEM per Konvention löste
 ====
diff --git a/docs/anchors/c4-diagrams.adoc b/docs/anchors/c4-diagrams.adoc
@@ -35,4 +35,10 @@ Key Proponent:: Simon Brown
 * Onboarding new team members
 * Architecture documentation and review
 * Replacing or supplementing UML
+
+[discrete]
+== *Current Status*:
+
+* The four levels (System Context, Container, Component, Code) and the supporting diagrams (system landscape, dynamic, deployment) are stable; https://c4model.com/[c4model.com] remains actively maintained by Simon Brown with edits into 2026
+* In September 2024 the site was rewritten from a single long page into a multi-page reference with new guidance (modelling microservices, queues and topics, a review checklist) — a prior trained on the old one-pager misses this guidance and the sharpened https://c4model.com/tooling[diagramming-vs-modelling] framing around tooling such as Structurizr
 ====
diff --git a/docs/anchors/c4-diagrams.de.adoc b/docs/anchors/c4-diagrams.de.adoc
@@ -34,4 +34,10 @@ Schlüsselvertreter:: Simon Brown
 * Onboarding neuer Teammitglieder
 * Architekturdokumentation und -review
 * Ersetzen oder Ergänzen von UML
+
+[discrete]
+== *Aktueller Stand*:
+
+* Die vier Ebenen (System Context, Container, Component, Code) und die ergänzenden Diagramme (System Landscape, Dynamic, Deployment) sind stabil; https://c4model.com/[c4model.com] wird von Simon Brown aktiv gepflegt, mit Änderungen bis in 2026
+* Im September 2024 wurde die Site von einer langen Einzelseite zu einer mehrseitigen Referenz umgebaut, mit neuer Anleitung (Microservices modellieren, Queues und Topics, Review-Checkliste) — ein auf den alten Einseiter trainierter Prior verpasst diese Inhalte und die geschärfte https://c4model.com/tooling[Diagramming-vs-Modelling]-Rahmung rund um Tooling wie Structurizr
 ====
diff --git a/docs/anchors/chain-of-thought.adoc b/docs/anchors/chain-of-thought.adoc
@@ -60,4 +60,10 @@ Let's solve this step by step:
 ...
 Therefore: [Conclusion]
 ----
+
+[discrete]
+== *Current Status*:
+
+* The core finding (Wei et al., https://arxiv.org/abs/2201.11903[NeurIPS 2022]) is stable, but its practical relevance is cutoff-bound: reasoning models (late 2024 onward) internalise chain-of-thought during training — https://platform.openai.com/docs/guides/reasoning-best-practices[OpenAI's own docs] now advise against "think step by step" prompts for those models
+* Treat CoT output as a useful but unreliable window into model reasoning: Turpin et al., https://arxiv.org/abs/2305.04388["Language Models Don't Always Say What They Think"] (2023) and https://www.anthropic.com/research/reasoning-models-dont-say-think[Anthropic's 2025 follow-up] show stated reasoning can be unfaithful to the actual decision factors — not a safety or audit guarantee
 ====
diff --git a/docs/anchors/chain-of-thought.de.adoc b/docs/anchors/chain-of-thought.de.adoc
@@ -59,4 +59,10 @@ Lass uns das Schritt für Schritt lösen:
 ...
 Daher: [Schlussfolgerung]
 ----
+
+[discrete]
+== *Aktueller Stand*:
+
+* Der Kernbefund (Wei et al., https://arxiv.org/abs/2201.11903[NeurIPS 2022]) ist stabil, seine praktische Relevanz aber cutoff-gebunden: Reasoning-Modelle (ab Ende 2024) internalisieren Chain-of-Thought im Training — https://platform.openai.com/docs/guides/reasoning-best-practices[OpenAIs eigene Doku] rät für diese Modelle inzwischen von "think step by step"-Prompts ab
+* CoT-Output ist ein nützliches, aber unzuverlässiges Fenster ins Modell-Reasoning: Turpin et al., https://arxiv.org/abs/2305.04388["Language Models Don't Always Say What They Think"] (2023) und https://www.anthropic.com/research/reasoning-models-dont-say-think[Anthropics Follow-up von 2025] zeigen, dass das geäußerte Reasoning den tatsächlichen Entscheidungsfaktoren untreu sein kann — keine Safety- oder Audit-Garantie
 ====
diff --git a/docs/anchors/crc-cards.adoc b/docs/anchors/crc-cards.adoc
@@ -49,4 +49,10 @@ Key Proponents:: Ward Cunningham, Kent Beck ("A Laboratory For Teaching Object-O
 * <<grasp,GRASP>> - Patterns for assigning responsibilities to classes in OO design
 * <<gof-design-patterns,GoF Design Patterns>> - Design patterns that can emerge from CRC-Card sessions
 * <<domain-driven-design,Domain-Driven Design>> - CRC Cards support ubiquitous language and entity discovery
+
+[discrete]
+== *Current Status*:
+
+* The definition is intact — index cards with Class, Responsibilities, Collaborators, exactly as Beck & Cunningham published at OOPSLA 1989; the https://c2.com/doc/oopsla89/paper.html[original paper] is still hosted on Ward Cunningham's site
+* The technique survives mainly as a teaching and workshop tool for object-oriented thinking — its original stated purpose ("A Laboratory for *Teaching* Object-Oriented Thinking") — and remains a defined entry in the https://agilealliance.org/glossary/crc-cards/[Agile Alliance glossary]; day-to-day design discussion has largely moved to whiteboard sketches and lightweight diagrams
 ====
diff --git a/docs/anchors/crc-cards.de.adoc b/docs/anchors/crc-cards.de.adoc
@@ -49,4 +49,10 @@ Schlüsselvertreter:: Ward Cunningham, Kent Beck ("A Laboratory For Teaching Obj
 * <<grasp,GRASP>> - Muster zur Zuweisung von Verantwortlichkeiten an Klassen im OO-Entwurf
 * <<gof-design-patterns,GoF Design Patterns>> - Entwurfsmuster, die aus CRC-Card-Sessions entstehen können
 * <<domain-driven-design,Domain-Driven Design>> - CRC-Cards unterstützen Ubiquitous Language und Entity-Entdeckung
+
+[discrete]
+== *Aktueller Stand*:
+
+* Die Definition ist intakt — Karteikarten mit Class, Responsibilities, Collaborators, genau wie von Beck & Cunningham auf der OOPSLA 1989 veröffentlicht; das https://c2.com/doc/oopsla89/paper.html[Original-Paper] liegt weiterhin auf Ward Cunninghams Site
+* Die Technik überlebt vor allem als Lehr- und Workshop-Werkzeug für objektorientiertes Denken — ihr ursprünglich erklärter Zweck ("A Laboratory for *Teaching* Object-Oriented Thinking") — und bleibt ein definierter Eintrag im https://agilealliance.org/glossary/crc-cards/[Agile-Alliance-Glossar]; die alltägliche Designdiskussion ist weitgehend zu Whiteboard-Skizzen und leichtgewichtigen Diagrammen gewandert
 ====
diff --git a/docs/anchors/diataxis-framework.adoc b/docs/anchors/diataxis-framework.adoc
@@ -40,4 +40,10 @@ Key Proponent:: Daniele Procida
 * Planning documentation structure
 * Evaluating documentation quality
 * Complementing Docs-as-Code approaches
+
+[discrete]
+== *Current Status*:
+
+* The four-quadrant core (tutorials, how-to guides, reference, explanation) is stable; https://diataxis.fr/[diataxis.fr] is a living, unversioned site — the colophon says the work "continues to be elaborated and explored"
+* The site has grown around the core: a theory section (the map, foundations, quality) and newer practical guidance such as https://diataxis.fr/complex-hierarchies/["Diátaxis in complex hierarchies"] — a prior anchored on the older Divio four-quadrant article (2014–2021) misses these refinements and the points where Procida has since revised his earlier presentation
 ====
diff --git a/docs/anchors/diataxis-framework.de.adoc b/docs/anchors/diataxis-framework.de.adoc
@@ -39,4 +39,10 @@ Schlüsselvertreter:: Daniele Procida
 * Planung von Dokumentationsstruktur
 * Bewertung von Dokumentationsqualität
 * Ergänzung von Docs-as-Code-Ansätzen
+
+[discrete]
+== *Aktueller Stand*:
+
+* Der Vier-Quadranten-Kern (Tutorials, How-to Guides, Reference, Explanation) ist stabil; https://diataxis.fr/[diataxis.fr] ist eine lebende, unversionierte Site — laut Kolophon wird das Werk "weiter ausgearbeitet und erkundet"
+* Die Site ist um den Kern herum gewachsen: ein Theorieteil (Map, Foundations, Quality) und neuere Praxis-Anleitung wie https://diataxis.fr/complex-hierarchies/["Diátaxis in complex hierarchies"] — ein auf den älteren Divio-Artikel (2014–2021) geankerter Prior verpasst diese Verfeinerungen und die Stellen, an denen Procida seine frühere Darstellung inzwischen revidiert hat
 ====
diff --git a/docs/anchors/fagan-inspection.adoc b/docs/anchors/fagan-inspection.adoc
@@ -41,4 +41,10 @@ Key Proponents:: Michael Fagan ("Design and Code Inspections to Reduce Errors in
 
 * <<mutation-testing,Mutation Testing>>
 * <<testing-pyramid,Testing Pyramid>>
+
+[discrete]
+== *Current Status*:
+
+* The definition is intact and unchanged since Fagan's https://doi.org/10.1147/sj.153.0182[1976 paper] (IBM Systems Journal 15(3)): a formal, multi-role inspection with defined phases and measured defect data
+* The formal meeting-based inspection is rarely practiced today; asynchronous, tool-based pull-request review has largely replaced it — a documented shift with its own trade-offs: modern review finds fewer defects per hour of rigor but adds knowledge transfer and team awareness (Bacchelli & Bird, https://sback.it/publications/icse2013.pdf["Expectations, Outcomes, and Challenges of Modern Code Review"], ICSE 2013; https://www.microsoft.com/en-us/research/publication/convergent-software-peer-review-practices/[Rigby & Bird, FSE 2013])
 ====
diff --git a/docs/anchors/fagan-inspection.de.adoc b/docs/anchors/fagan-inspection.de.adoc
@@ -41,4 +41,10 @@ Schlüsselvertreter:: Michael Fagan ("Design and Code Inspections to Reduce Erro
 
 * <<mutation-testing,Mutation Testing>>
 * <<testing-pyramid,Testing Pyramid>>
+
+[discrete]
+== *Aktueller Stand*:
+
+* Die Definition ist intakt und seit Fagans https://doi.org/10.1147/sj.153.0182[Paper von 1976] (IBM Systems Journal 15(3)) unverändert: eine formale Inspektion mit verteilten Rollen, definierten Phasen und gemessenen Defektdaten
+* Die formale, meetingbasierte Inspektion wird heute selten praktiziert; asynchrones, toolgestütztes Pull-Request-Review hat sie weitgehend ersetzt — ein dokumentierter Wandel mit eigenen Trade-offs: Modernes Review findet weniger Defekte pro Stunde Rigorosität, leistet dafür Wissenstransfer und Team-Awareness (Bacchelli & Bird, https://sback.it/publications/icse2013.pdf["Expectations, Outcomes, and Challenges of Modern Code Review"], ICSE 2013; https://www.microsoft.com/en-us/research/publication/convergent-software-peer-review-practices/[Rigby & Bird, FSE 2013])
 ====
diff --git a/docs/anchors/fowler-patterns.adoc b/docs/anchors/fowler-patterns.adoc
@@ -55,4 +55,10 @@ Key Proponent:: Martin Fowler ("Patterns of Enterprise Application Architecture"
 * <<domain-driven-design,Domain-Driven Design>> - Complements PEAA with domain modeling approach
 * <<hexagonal-architecture,Hexagonal Architecture>> - Architectural style emphasizing ports and adapters
 * <<clean-architecture,Clean Architecture>> - Layered architecture pattern with dependency rules
+
+[discrete]
+== *Current Status*:
+
+* The prior reproduces the 2002 catalog (Active Record, Data Mapper, Unit of Work, Repository …) as hand-rolled patterns; Fowler himself notes "many patterns are now implemented by common frameworks" while maintaining they are "still relevant today" (https://martinfowler.com/books/eaa.html[P of EAA book page])
+* The https://martinfowler.com/eaaCatalog/[online catalog] is content-unchanged since its "original 2003 publication", and the planned follow-up volumes (https://martinfowler.com/eaaDev/[eaaDev]) have been "pretty much frozen" since 2006 — the catalog reflects the J2EE/.NET era, not current distributed and frontend-heavy practice
 ====
diff --git a/docs/anchors/fowler-patterns.de.adoc b/docs/anchors/fowler-patterns.de.adoc
@@ -54,4 +54,10 @@ Hauptvertreter:: Martin Fowler ("Patterns of Enterprise Application Architecture
 * <<domain-driven-design,Domain-Driven Design>> - Ergänzt PEAA mit Domain-Modellierungsansatz
 * <<hexagonal-architecture,Hexagonal Architecture>> - Architekturstil mit Fokus auf Ports und Adaptern
 * <<clean-architecture,Clean Architecture>> - Geschichtete Architektur mit Abhängigkeitsregeln
+
+[discrete]
+== *Aktueller Stand*:
+
+* Der Prior reproduziert den Katalog von 2002 (Active Record, Data Mapper, Unit of Work, Repository …) als handgebaute Patterns; Fowler selbst merkt an, "viele Patterns sind heute in gängigen Frameworks implementiert", hält sie aber für "weiterhin relevant" (https://martinfowler.com/books/eaa.html[P-of-EAA-Buchseite])
+* Der https://martinfowler.com/eaaCatalog/[Online-Katalog] ist inhaltlich unverändert seit der "Original-Veröffentlichung 2003", und die geplanten Folgebände (https://martinfowler.com/eaaDev/[eaaDev]) sind seit 2006 "weitgehend eingefroren" — der Katalog spiegelt die J2EE/.NET-Ära, nicht die heutige verteilte und frontend-lastige Praxis
 ====
diff --git a/docs/anchors/github-flow.adoc b/docs/anchors/github-flow.adoc
@@ -41,4 +41,10 @@ Key Proponent:: Scott Chacon ("GitHub Flow", 2011)
 
 * <<conventional-commits,Conventional Commits>>
 * <<semantic-versioning,Semantic Versioning (SemVer)>>
+
+[discrete]
+== *Current Status*:
+
+* The prior most plausibly reproduces Scott Chacon's https://scottchacon.com/2011/08/31/github-flow/[original 2011 formulation], where continuous deployment is the point — "anything in the master branch is deployable", and merged work is deployed immediately, often several times a day
+* GitHub's https://docs.github.com/en/get-started/using-github/github-flow[current official description] has narrowed to a generic branch → PR → review → merge workflow with no deployment step at all — say which of the two you mean
 ====
diff --git a/docs/anchors/github-flow.de.adoc b/docs/anchors/github-flow.de.adoc
@@ -41,4 +41,10 @@ Schlüsselvertreter:: Scott Chacon ("GitHub Flow", 2011)
 
 * <<conventional-commits,Conventional Commits>>
 * <<semantic-versioning,Semantic Versioning (SemVer)>>
+
+[discrete]
+== *Aktueller Stand*:
+
+* Der Prior reproduziert höchstwahrscheinlich Scott Chacons https://scottchacon.com/2011/08/31/github-flow/[Original-Formulierung von 2011], in der Continuous Deployment der Kern ist — "anything in the master branch is deployable", gemergte Arbeit wird sofort deployt, oft mehrmals täglich
+* GitHubs https://docs.github.com/en/get-started/using-github/github-flow[aktuelle offizielle Beschreibung] ist zu einem generischen Branch → PR → Review → Merge-Workflow ohne jeden Deployment-Schritt geschrumpft — sage, welche der beiden Varianten du meinst
 ====
diff --git a/docs/anchors/gom.adoc b/docs/anchors/gom.adoc
@@ -46,4 +46,10 @@ Key Proponents:: Jörg Becker, Michael Rosemann, Rolf Schütte ("Grundsätze ord
 * <<arc42,arc42 Architecture Documentation>>
 * <<c4-diagrams,C4 Diagrams>>
 * <<morphological-box,Morphological Box>>
+
+[discrete]
+== *Current Status*:
+
+* The canonical reference is Becker, Rosemann & Schütte, "Grundsätze ordnungsmäßiger Modellierung", Wirtschaftsinformatik 37(5), 1995, pp. 435–445 — no DOI exists; stable records: https://dblp.org/rec/journals/wi/BeckerRS95.html[dblp] and the https://www.wi.uni-muenster.de/de/forschung/publikationen/3436[University of Münster publication page]
+* The prior is thin: a German-language-only academic paper from the Wirtschaftsinformatik community with virtually no English-language footprint — supply the six principles in the prompt rather than relying on the term
 ====
diff --git a/docs/anchors/gom.de.adoc b/docs/anchors/gom.de.adoc
@@ -45,4 +45,10 @@ Schlüsselvertreter:: Jörg Becker, Michael Rosemann, Rolf Schütte ("Grundsätz
 * <<arc42,arc42 Architekturdokumentation>>
 * <<c4-diagrams,C4-Diagramme>>
 * <<morphological-box,Morphologischer Kasten>>
+
+[discrete]
+== *Aktueller Stand*:
+
+* Die kanonische Referenz ist Becker, Rosemann & Schütte, "Grundsätze ordnungsmäßiger Modellierung", Wirtschaftsinformatik 37(5), 1995, S. 435–445 — ein DOI existiert nicht; stabile Nachweise: https://dblp.org/rec/journals/wi/BeckerRS95.html[dblp] und die https://www.wi.uni-muenster.de/de/forschung/publikationen/3436[Publikationsseite der Uni Münster]
+* Der Prior ist dünn: ein rein deutschsprachiges akademisches Paper aus der Wirtschaftsinformatik mit praktisch keinem englischsprachigen Fußabdruck — liefere die sechs Grundsätze im Prompt mit, statt dich auf den Begriff zu verlassen
 ====