From 540619848e0aaadf5749572df54c204f424d4408 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Thu, 11 Jun 2026 18:23:09 +0200 Subject: [PATCH 1/2] feat: Current Status sections for remaining 20 anchors, rewrite LASR (#603) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Completes the #603 triage. Fourteen versioned/living anchors and five thin-prior anchors get Current Status sections (EN + DE) with fetch-verified sources; the About page states the lexicon positioning (inclusion means precision, not endorsement). LASR is rewritten from scratch: verification revealed the previous entry was a silent substitution on a thin prior — it described a fabricated "lightweight architecture documentation template" with an invented acronym expansion (the AgentSkill catalog carried a second, different invented expansion: "Layers-Aspects-Solution Strategy-Rationale"). The real LASR is the Lightweight Approach for Software Reviews (Stefan Toth & Stefan Zörner, lasr-reviews.org; "Reviewing Software Systems", Leanpub 2023), a streamlined ATAM alternative with four steps (Lean Mission Statement, Evaluation Criteria, Risk-based Review, Quality-focused Analysis). The corrected anchor documents its own failure case as evidence for the thin-prior warning. The catalog.md expansion is fixed accordingly. Other notable verified facts: arc42 v9.0 (July 2025), GitHub Flow's deployment essence is gone from GitHub's current docs, LINDDUN is now a GO/PRO/MAESTRO family, Papers with Code no longer exists, IEC 61508 Ed 3 forecast ~Oct 2026, IOSP's canonical source is Westphal's Substack (clean-code-developer.de has no IOSP page). Refs #603 Co-Authored-By: Claude Fable 5 --- docs/about.adoc | 2 + docs/about.de.adoc | 2 + docs/anchors/arc42.adoc | 6 +++ docs/anchors/arc42.de.adoc | 6 +++ docs/anchors/bem-methodology.adoc | 5 ++ docs/anchors/bem-methodology.de.adoc | 5 ++ docs/anchors/c4-diagrams.adoc | 6 +++ docs/anchors/c4-diagrams.de.adoc | 6 +++ docs/anchors/chain-of-thought.adoc | 6 +++ docs/anchors/chain-of-thought.de.adoc | 6 +++ docs/anchors/crc-cards.adoc | 6 +++ docs/anchors/crc-cards.de.adoc | 6 +++ docs/anchors/diataxis-framework.adoc | 6 +++ docs/anchors/diataxis-framework.de.adoc | 6 +++ docs/anchors/fagan-inspection.adoc | 6 +++ docs/anchors/fagan-inspection.de.adoc | 6 +++ docs/anchors/fowler-patterns.adoc | 6 +++ docs/anchors/fowler-patterns.de.adoc | 6 +++ docs/anchors/github-flow.adoc | 6 +++ docs/anchors/github-flow.de.adoc | 6 +++ docs/anchors/gom.adoc | 6 +++ docs/anchors/gom.de.adoc | 6 +++ docs/anchors/iec-61508-sil-levels.adoc | 6 +++ docs/anchors/iec-61508-sil-levels.de.adoc | 6 +++ docs/anchors/iosp.adoc | 6 +++ docs/anchors/iosp.de.adoc | 6 +++ docs/anchors/lasr.adoc | 50 +++++++++++-------- docs/anchors/lasr.de.adoc | 50 +++++++++++-------- docs/anchors/linddun.adoc | 6 +++ docs/anchors/linddun.de.adoc | 6 +++ docs/anchors/llm-evaluations.adoc | 6 +++ docs/anchors/llm-evaluations.de.adoc | 6 +++ docs/anchors/meaningful-human-control.adoc | 6 +++ docs/anchors/meaningful-human-control.de.adoc | 6 +++ .../anchors/site-reliability-engineering.adoc | 6 +++ .../site-reliability-engineering.de.adoc | 6 +++ docs/anchors/sota.adoc | 6 +++ docs/anchors/sota.de.adoc | 6 +++ docs/anchors/todotxt-flavoured-markdown.adoc | 6 +++ .../todotxt-flavoured-markdown.de.adoc | 6 +++ docs/changelog.adoc | 7 +++ .../references/catalog.md | 2 +- .../references/catalog.md | 2 +- 43 files changed, 287 insertions(+), 42 deletions(-) diff --git a/docs/about.adoc b/docs/about.adoc index 141a0444..b218c5e7 100644 --- 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 index f5a41875..efb70c3d 100644 --- 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 index e9dc324e..3256a5d6 100644 --- 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 index 5bed5fb6..81ef5f10 100644 --- 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 index 3de93888..4a217ca3 100644 --- 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 index 0fcbb04c..d36b122a 100644 --- 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 index 2dd4f559..abcae321 100644 --- 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 index eeb786b2..a4f931d6 100644 --- 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 index 8b9df909..49574e7b 100644 --- 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 index daa37bee..e08c4718 100644 --- 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 index 670dd547..bee4b012 100644 --- 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 * <> - Patterns for assigning responsibilities to classes in OO design * <> - Design patterns that can emerge from CRC-Card sessions * <> - 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 index c1265ac8..48fa0f1e 100644 --- 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 * <> - Muster zur Zuweisung von Verantwortlichkeiten an Klassen im OO-Entwurf * <> - Entwurfsmuster, die aus CRC-Card-Sessions entstehen können * <> - 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 index de342e78..d95c1058 100644 --- 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 index 699f9751..5694ed78 100644 --- 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 index 3b67dc87..9b448039 100644 --- 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 * <> * <> + +[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 index eaf33336..458dc70e 100644 --- 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 * <> * <> + +[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 index aa08b8a6..706ba56f 100644 --- 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" * <> - Complements PEAA with domain modeling approach * <> - Architectural style emphasizing ports and adapters * <> - 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 index 32ace89a..42e03dfd 100644 --- 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 * <> - Ergänzt PEAA mit Domain-Modellierungsansatz * <> - Architekturstil mit Fokus auf Ports und Adaptern * <> - 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 index 380b0858..8b61d89e 100644 --- a/docs/anchors/github-flow.adoc +++ b/docs/anchors/github-flow.adoc @@ -41,4 +41,10 @@ Key Proponent:: Scott Chacon ("GitHub Flow", 2011) * <> * <> + +[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 index daa01b03..56fcb310 100644 --- 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) * <> * <> + +[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 index 567b4b27..9edd6f2a 100644 --- 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 * <> * <> * <> + +[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 index 4af5570c..7131270a 100644 --- 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 * <> * <> * <> + +[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 ==== diff --git a/docs/anchors/iec-61508-sil-levels.adoc b/docs/anchors/iec-61508-sil-levels.adoc index a104eb38..2945d2d6 100644 --- a/docs/anchors/iec-61508-sil-levels.adoc +++ b/docs/anchors/iec-61508-sil-levels.adoc @@ -61,4 +61,10 @@ Key Standard:: IEC 61508 "Functional Safety of Electrical/Electronic/Programmabl * Establishing software development processes for safety applications * Conducting hazard and operability (HAZOP) studies * Implementing functional safety management systems + +[discrete] +== *Current Status*: + +* The prior is trained almost entirely on Edition 2 (2010), which has been the published standard for 15+ years — Ed-2 knowledge (SIL tables, lifecycle phases) is still authoritative +* Edition 3 is in final approval as of mid-2026 (https://webstore.iec.ch/en/publication/5515[IEC forecasts publication around October 2026]), adding cybersecurity alignment with IEC 62443 and guidance on AI/ML in safety functions — when "current edition" matters, check the IEC webstore rather than assuming Ed 3 is out ==== diff --git a/docs/anchors/iec-61508-sil-levels.de.adoc b/docs/anchors/iec-61508-sil-levels.de.adoc index 39e312ee..c97a370f 100644 --- a/docs/anchors/iec-61508-sil-levels.de.adoc +++ b/docs/anchors/iec-61508-sil-levels.de.adoc @@ -60,4 +60,10 @@ Schlüsselstandard:: IEC 61508 "Funktionale Sicherheit sicherheitsbezogener elek * Etablierung von Softwareentwicklungsprozessen für Sicherheitsanwendungen * Durchführung von HAZOP-Studien (Hazard and Operability) * Implementierung funktionaler Sicherheitsmanagementsysteme + +[discrete] +== *Aktueller Stand*: + +* Der Prior ist fast vollständig auf Edition 2 (2010) trainiert, die seit über 15 Jahren der veröffentlichte Standard ist — Ed-2-Wissen (SIL-Tabellen, Lifecycle-Phasen) ist weiterhin maßgeblich +* Edition 3 steht Mitte 2026 in der finalen Freigabe (https://webstore.iec.ch/en/publication/5515[IEC-Prognose: Veröffentlichung um Oktober 2026]), mit Cybersecurity-Anbindung an IEC 62443 und Leitlinien zu KI/ML in Sicherheitsfunktionen — wenn die "aktuelle Edition" zählt, im IEC-Webstore prüfen statt Ed 3 anzunehmen ==== diff --git a/docs/anchors/iosp.adoc b/docs/anchors/iosp.adoc index 2c687b21..1c8e31b1 100644 --- a/docs/anchors/iosp.adoc +++ b/docs/anchors/iosp.adoc @@ -61,4 +61,10 @@ Ralf Westphal ("Integration Operation Segregation Principle (IOSP)", 2022 — su * <> - GRASP's "High Cohesion" and "Low Coupling" are structurally supported by IOSP's tree-like composition * <> - IOSP can replace DIP for the purpose of testability; DIP is retained only for genuine alternative implementations * <> - Layered abstraction at architecture scale mirrors IOSP's function-level separation + +[discrete] +== *Current Status*: + +* The canonical source is Ralf Westphal's own writing — https://ralfwestphal.substack.com/p/integration-operation-segregation["Integration Operation Segregation Principle (IOSP)"] (Substack); note that clean-code-developer.de, often assumed to host it, has no IOSP page +* The prior is thin: the principle originates from a small German Clean Code Developer / Flow Design school, with the inventor's blog posts as primary sources and mostly German-language secondary coverage — state the rule explicitly in the prompt (functions either contain logic or call other functions, never both) ==== diff --git a/docs/anchors/iosp.de.adoc b/docs/anchors/iosp.de.adoc index 958915f0..b621391b 100644 --- a/docs/anchors/iosp.de.adoc +++ b/docs/anchors/iosp.de.adoc @@ -61,4 +61,10 @@ Ralf Westphal ("Integration Operation Segregation Principle (IOSP)", 2022 — su * <> - GRASPs "Hohe Kohäsion" und "Niedrige Kopplung" werden durch IOSP's baumartige Komposition strukturell unterstützt * <> - IOSP kann DIP für den Zweck der Testbarkeit ersetzen; DIP bleibt nur für echte alternative Implementierungen erhalten * <> - Geschichtete Abstraktion auf Architekturebene spiegelt IOSP's Trennung auf Funktionsebene wider + +[discrete] +== *Aktueller Stand*: + +* Die kanonische Quelle ist Ralf Westphals eigenes Schreiben — https://ralfwestphal.substack.com/p/integration-operation-segregation["Integration Operation Segregation Principle (IOSP)"] (Substack); beachte: clean-code-developer.de, oft als Quelle vermutet, hat keine IOSP-Seite +* Der Prior ist dünn: Das Prinzip stammt aus einer kleinen deutschen Clean-Code-Developer-/Flow-Design-Schule, mit den Blogposts des Erfinders als Primärquellen und überwiegend deutschsprachiger Sekundärliteratur — nenne die Regel im Prompt explizit (Funktionen enthalten entweder Logik oder rufen andere Funktionen auf, nie beides) ==== diff --git a/docs/anchors/lasr.adoc b/docs/anchors/lasr.adoc index f22343f8..37a6f369 100644 --- a/docs/anchors/lasr.adoc +++ b/docs/anchors/lasr.adoc @@ -1,47 +1,57 @@ = LASR according to Toth/Zörner :categories: software-architecture -:roles: software-architect, software-developer, technical-writer, team-lead, consultant -:related: arc42, adr-according-to-nygard, c4-diagrams +:roles: software-architect, software-developer, qa-engineer, team-lead, consultant +:related: atam, arc42, quality-attribute-scenario :proponents: Stefan Toth, Stefan Zörner -:tags: architecture-documentation, solution-strategy, interfaces, risks, lightweight, communication +:tags: software-reviews, architecture-review, quality-attributes, risks, lightweight, atam-alternative :tier: 3 [%collapsible] ==== -Full Name:: LASR – Lightweight Architecture Documentation by Toth/Zörner +Full Name:: LASR – Lightweight Approach for Software Reviews (Stefan Toth & Stefan Zörner) -Also known as:: Lightweight Architecture Communication, LASR Template +Also known as:: LASR Reviews [discrete] == *Core Concepts*: -L – Lösungsstrategie (Solution Strategy):: High-level description of how the solution addresses the most important quality requirements and constraints; the central architectural ideas that shape the system +A review method:: LASR is a structured method for efficient software reviews — it uncovers weaknesses in software solutions and challenges technical and architectural ideas. More streamlined than ATAM, but still focused on key quality aspects -A – Architekturüberblick (Architecture Overview):: Key structural and runtime views showing the main building blocks, their responsibilities, and how they interact at runtime +Lean Mission Statement:: Condense the system's vision into a short, shared statement as the review's reference point -S – Schnittstellen (Interfaces):: Definition of all relevant external interfaces (APIs, protocols, data formats) and important internal interfaces between major components +Evaluation Criteria:: Identify the system's top quality attributes — the quantified objectives form the review benchmark -R – Risiken (Risks):: Identification of the most critical technical risks, open questions, and known weaknesses together with proposed mitigation strategies +Risk-based Review:: Identify the most significant risks against those objectives -Lightweight by design:: LASR intentionally focuses on the four most communication-relevant aspects of an architecture, omitting detail that does not aid stakeholder understanding +Quality-focused Analysis:: Analyze the controversial gaps (or their absence) in depth -Living document:: Updated alongside the architecture; meant to communicate current state, not archive history +LASR Result Diagram:: Quantifies the review: the objectives form a benchmark line, the system assessment a second line — the gaps between them drive the deeper analysis -Key Proponents:: Stefan Toth ("Vorgehensmuster für Softwarearchitektur"), Stefan Zörner ("Softwarearchitekturen dokumentieren und kommunizieren") +Workshop format:: A moderated, game-like team event (LASR-Cards, templates and checklists as Print & Play material); works with few people, on site or remote, first results within hours + +Community-driven and free:: Open license, free to use in commercial contexts; supported by embarc + +Key Proponents:: Stefan Toth & Stefan Zörner (https://leanpub.com/reviewing-software-systems["Reviewing Software Systems"], Leanpub, 2023; German edition "Software-Systeme reviewen"); canonical site https://www.lasr-reviews.org/[lasr-reviews.org] [discrete] == *When to Use*: -* Communicating architecture to stakeholders who need a concise overview rather than full documentation -* Agile projects where a lightweight alternative to arc42 is preferred -* Architecture reviews where the four LASR aspects serve as a structured review checklist -* Onboarding new team members to an existing system's key design decisions -* Workshops where teams collaboratively capture the essential architecture decisions +* Reviewing a software system or solution idea when ATAM is too heavyweight +* Validating an architecture against its most important quality attributes +* Uncovering and prioritising technical risks with the whole team in a short workshop +* Establishing a recurring, lightweight review practice [discrete] == *Related Anchors*: -* <> -* <> -* <> +* <> — the heavyweight scenario-based evaluation method LASR streamlines +* <> — the documentation counterpart; LASR reviews what arc42 documents +* <> — a rigorous form the evaluation criteria can take + +[discrete] +== *Current Status*: + +* The canonical sources are https://www.lasr-reviews.org/[lasr-reviews.org] and the book https://leanpub.com/reviewing-software-systems["Reviewing Software Systems"] (Toth & Zörner, Leanpub, 2023) +* The prior is thin — a 2023 self-published method from two German consultants with essentially one community site. LLMs reliably know the name at best, not the method: supply the steps from lasr-reviews.org in the prompt rather than trusting the anchor alone +* A cautionary tale from this catalog itself: an earlier version of this entry confidently described LASR as a "lightweight architecture documentation template" with an invented acronym expansion — silent substitution on a thin prior, exactly the Use-Case-3.0 failure mode. Corrected against the verified sources in June 2026 ==== diff --git a/docs/anchors/lasr.de.adoc b/docs/anchors/lasr.de.adoc index eb494a14..dfe93b55 100644 --- a/docs/anchors/lasr.de.adoc +++ b/docs/anchors/lasr.de.adoc @@ -1,46 +1,56 @@ = LASR nach Toth/Zörner :categories: software-architecture -:roles: software-architect, software-developer, technical-writer, team-lead, consultant -:related: arc42, adr-according-to-nygard, c4-diagrams +:roles: software-architect, software-developer, qa-engineer, team-lead, consultant +:related: atam, arc42, quality-attribute-scenario :proponents: Stefan Toth, Stefan Zörner -:tags: architecture-documentation, solution-strategy, interfaces, risks, lightweight, communication +:tags: software-reviews, architecture-review, quality-attributes, risks, lightweight, atam-alternative [%collapsible] ==== -Vollständiger Name:: LASR – Leichtgewichtige Architekturdokumentation nach Toth/Zörner +Vollständiger Name:: LASR – Lightweight Approach for Software Reviews (Stefan Toth & Stefan Zörner) -Auch bekannt als:: Leichtgewichtige Architekturkommunikation, LASR-Template +Auch bekannt als:: LASR Reviews [discrete] == *Kernkonzepte*: -L – Lösungsstrategie:: Übergeordnete Beschreibung, wie die Lösung die wichtigsten Qualitätsanforderungen und Randbedingungen adressiert; die zentralen Architekturideen, die das System prägen +Eine Review-Methode:: LASR ist eine strukturierte Methode für effiziente Software-Reviews — sie deckt Schwächen in Softwarelösungen auf und hinterfragt technische und architektonische Ideen. Schlanker als ATAM, aber weiterhin auf die wichtigsten Qualitätsaspekte fokussiert -A – Architekturüberblick:: Wesentliche Struktur- und Laufzeitsichten mit den wichtigsten Bausteinen, deren Verantwortlichkeiten und ihrer Interaktion zur Laufzeit +Lean Mission Statement:: Die Vision des Systems zu einer kurzen, gemeinsamen Aussage verdichten — der Referenzpunkt des Reviews -S – Schnittstellen:: Definition aller relevanten Außenschnittstellen (APIs, Protokolle, Datenformate) sowie wichtiger interner Schnittstellen zwischen den Hauptkomponenten +Evaluation Criteria:: Die wichtigsten Qualitätsattribute des Systems identifizieren — die quantifizierten Ziele bilden die Review-Benchmark -R – Risiken:: Identifikation der kritischsten technischen Risiken, offener Fragen und bekannter Schwächen zusammen mit vorgeschlagenen Maßnahmen zur Risikoreduzierung +Risk-based Review:: Die bedeutendsten Risiken gegen diese Ziele identifizieren -Bewusst leichtgewichtig:: LASR konzentriert sich gezielt auf die vier kommunikationsrelevantesten Aspekte einer Architektur und verzichtet auf Details, die das Stakeholder-Verständnis nicht verbessern +Quality-focused Analysis:: Die kontroversen Lücken (oder deren Abwesenheit) vertieft analysieren -Lebendes Dokument:: Wird parallel zur Architektur aktualisiert; dient der Kommunikation des aktuellen Stands, nicht der Archivierung von Geschichte +LASR Result Diagram:: Quantifiziert das Review: Die Ziele bilden eine Benchmark-Linie, die Systembewertung eine zweite — die Lücken dazwischen treiben die vertiefte Analyse -Schlüsselvertreter:: Stefan Toth ("Vorgehensmuster für Softwarearchitektur"), Stefan Zörner ("Softwarearchitekturen dokumentieren und kommunizieren") +Workshop-Format:: Ein moderiertes, spielerisches Team-Event (LASR-Cards, Templates und Checklisten als Print & Play); funktioniert mit wenigen Personen, vor Ort oder remote, erste Ergebnisse in Stunden + +Community-getrieben und frei:: Offene Lizenz, frei auch für kommerzielle Nutzung; unterstützt von embarc + +Schlüsselvertreter:: Stefan Toth & Stefan Zörner (https://leanpub.com/reviewing-software-systems["Reviewing Software Systems"], Leanpub, 2023; deutsche Ausgabe "Software-Systeme reviewen"); kanonische Site https://www.lasr-reviews.org/[lasr-reviews.org] [discrete] == *Wann zu verwenden*: -* Kommunikation der Architektur an Stakeholder, die einen prägnanten Überblick statt vollständiger Dokumentation benötigen -* Agile Projekte, in denen eine leichtgewichtige Alternative zu arc42 bevorzugt wird -* Architektur-Reviews, bei denen die vier LASR-Aspekte als strukturierte Review-Checkliste dienen -* Einarbeitung neuer Teammitglieder in die wesentlichen Entwurfsentscheidungen eines bestehenden Systems -* Workshops, in denen Teams gemeinsam die wesentlichen Architekturentscheidungen erfassen +* Review eines Softwaresystems oder Lösungsentwurfs, wenn ATAM zu schwergewichtig ist +* Validierung einer Architektur gegen ihre wichtigsten Qualitätsattribute +* Technische Risiken im Team in einem kurzen Workshop aufdecken und priorisieren +* Etablierung einer wiederkehrenden, leichtgewichtigen Review-Praxis [discrete] == *Verwandte Anker*: -* <> -* <> -* <> +* <> — die schwergewichtige szenariobasierte Bewertungsmethode, die LASR verschlankt +* <> — das Dokumentations-Gegenstück; LASR reviewt, was arc42 dokumentiert +* <> — eine rigorose Form für die Evaluation Criteria + +[discrete] +== *Aktueller Stand*: + +* Die kanonischen Quellen sind https://www.lasr-reviews.org/[lasr-reviews.org] und das Buch https://leanpub.com/reviewing-software-systems["Reviewing Software Systems"] (Toth & Zörner, Leanpub, 2023) +* Der Prior ist dünn — eine 2023 selbstverlegte Methode zweier deutscher Berater mit im Wesentlichen einer Community-Site. LLMs kennen bestenfalls zuverlässig den Namen, nicht die Methode: Liefere die Schritte von lasr-reviews.org im Prompt mit, statt dem Anker allein zu vertrauen +* Ein warnendes Beispiel aus diesem Katalog selbst: Eine frühere Version dieses Eintrags beschrieb LASR selbstbewusst als „leichtgewichtiges Architekturdokumentations-Template" mit erfundener Akronym-Auflösung — stille Substitution auf dünnem Prior, exakt der Use-Case-3.0-Fehlermodus. Im Juni 2026 gegen die verifizierten Quellen korrigiert ==== diff --git a/docs/anchors/linddun.adoc b/docs/anchors/linddun.adoc index acb3f701..dd530b00 100644 --- a/docs/anchors/linddun.adoc +++ b/docs/anchors/linddun.adoc @@ -46,4 +46,10 @@ Key Proponents:: Kim Wuyts, Riccardo Scandariato, Wouter Joosen (KU Leuven / Dis * <> * <> + +[discrete] +== *Current Status*: + +* The prior likely reflects the original academic LINDDUN of the 2010s: a single heavyweight DFD-based method with the old seven categories including plain "Unawareness" +* Current https://linddun.org/[LINDDUN] (KU Leuven) is a family of three flavors — https://linddun.org/go/[GO] (33-card lightweight deck, 2024 redesign), PRO (systematic), and https://linddun.org/maestro/[MAESTRO] (most thorough) — built on a 2024-updated threat knowledge base where the "U" became "Unawareness & Unintervenability" ==== diff --git a/docs/anchors/linddun.de.adoc b/docs/anchors/linddun.de.adoc index 98428fb8..138bc46a 100644 --- a/docs/anchors/linddun.de.adoc +++ b/docs/anchors/linddun.de.adoc @@ -46,4 +46,10 @@ Schlüsselvertreter:: Kim Wuyts, Riccardo Scandariato, Wouter Joosen (KU Leuven * <> * <> + +[discrete] +== *Aktueller Stand*: + +* Der Prior spiegelt vermutlich das ursprüngliche akademische LINDDUN der 2010er: eine einzelne schwergewichtige DFD-Methode mit den alten sieben Kategorien einschließlich des schlichten "Unawareness" +* Das aktuelle https://linddun.org/[LINDDUN] (KU Leuven) ist eine Familie aus drei Varianten — https://linddun.org/go/[GO] (33-Karten-Deck, Redesign 2024), PRO (systematisch) und https://linddun.org/maestro/[MAESTRO] (am gründlichsten) — auf einer 2024 aktualisierten Threat-Wissensbasis, in der das "U" zu "Unawareness & Unintervenability" wurde ==== diff --git a/docs/anchors/llm-evaluations.adoc b/docs/anchors/llm-evaluations.adoc index 5d295186..cd8ca431 100644 --- a/docs/anchors/llm-evaluations.adoc +++ b/docs/anchors/llm-evaluations.adoc @@ -51,4 +51,10 @@ Key Proponents:: Percy Liang et al. (Stanford, "Holistic Evaluation of Language * <> * <> * <> + +[discrete] +== *Current Status*: + +* The methodology is stable (held-out benchmarks, harnesses, holistic suites); any concrete benchmark list is cutoff-bound — MMLU was already superseded by https://arxiv.org/abs/2406.01574[MMLU-Pro] and https://arxiv.org/abs/2311.12022[GPQA] by 2024, and those will saturate too +* Never trust a model's memorised benchmark numbers or "current leading benchmark" claims: point it at living sources — https://github.com/EleutherAI/lm-evaluation-harness[lm-evaluation-harness] and https://crfm.stanford.edu/helm/[HELM] — and date every score you quote ==== diff --git a/docs/anchors/llm-evaluations.de.adoc b/docs/anchors/llm-evaluations.de.adoc index f596a6b8..6be6fd55 100644 --- a/docs/anchors/llm-evaluations.de.adoc +++ b/docs/anchors/llm-evaluations.de.adoc @@ -50,4 +50,10 @@ Schlüsselvertreter:: Percy Liang et al. (Stanford, "Holistic Evaluation of Lang * <> * <> * <> + +[discrete] +== *Aktueller Stand*: + +* Die Methodik ist stabil (Held-out-Benchmarks, Harnesses, holistische Suiten); jede konkrete Benchmark-Liste ist cutoff-gebunden — MMLU war schon 2024 von https://arxiv.org/abs/2406.01574[MMLU-Pro] und https://arxiv.org/abs/2311.12022[GPQA] abgelöst, und auch die werden saturieren +* Traue nie den memorierten Benchmark-Zahlen oder "aktuell führender Benchmark"-Behauptungen eines Modells: Verweise es auf lebende Quellen — https://github.com/EleutherAI/lm-evaluation-harness[lm-evaluation-harness] und https://crfm.stanford.edu/helm/[HELM] — und datiere jeden zitierten Score ==== diff --git a/docs/anchors/meaningful-human-control.adoc b/docs/anchors/meaningful-human-control.adoc index 8a19bbea..ad328dac 100644 --- a/docs/anchors/meaningful-human-control.adoc +++ b/docs/anchors/meaningful-human-control.adoc @@ -93,4 +93,10 @@ This anchor is classified as *Tier 2 — Needs qualification*. It is not self-st * *Why not Tier 3*: MHC cannot be evaluated without domain-specific context (weapons vs. medical vs. automotive). The same system may satisfy MHC in one domain and fail in another. Sharkey level L3 may be sufficient for cargo ships but not for lethal targeting. * *Why not Tier 1*: MHC is a well-established, multi-source concept with clear definition, consistent usage across domains, attributable origin, and rich conceptual activation. * *Qualification path*: To apply MHC, the user must answer: "Who controls what, with what information, under what constraints, and who is accountable?" The five criteria above operationalize this question. + +[discrete] +== *Current Status*: + +* The canonical reference is Santoni de Sio & van den Hoven, https://doi.org/10.3389/frobt.2018.00015["Meaningful Human Control over Autonomous Systems: A Philosophical Account"] (Frontiers in Robotics and AI, 2018), proposing the "tracking" and "tracing" conditions +* The prior is thin: an academic-only footprint anchored in one open-access philosophy paper (TU Delft ethics group) and a niche AI-ethics literature, with little practitioner coverage — supply the tracking/tracing definitions in the prompt when precision matters ==== diff --git a/docs/anchors/meaningful-human-control.de.adoc b/docs/anchors/meaningful-human-control.de.adoc index 8f5bda78..bc12c7cc 100644 --- a/docs/anchors/meaningful-human-control.de.adoc +++ b/docs/anchors/meaningful-human-control.de.adoc @@ -93,4 +93,10 @@ Dieser Anker ist als *Tier 2 — qualifizierungsbedürftig* eingestuft. Er steht * *Warum nicht Tier 3*: MHC lässt sich ohne domänenspezifischen Kontext nicht bewerten (Waffen vs. Medizin vs. Automotive). Dasselbe System kann MHC in einer Domäne erfüllen und in einer anderen verfehlen. Sharkey-Stufe S3 mag für Frachtschiffe genügen, nicht aber für die Zielbekämpfung mit Waffengewalt. * *Warum nicht Tier 1*: MHC ist ein gut etabliertes, mehrfach belegtes Konzept mit klarer Definition, konsistenter Verwendung über Domänen hinweg, attribuierbarem Ursprung und reicher konzeptueller Aktivierung. * *Qualifizierungspfad*: Um MHC anzuwenden, muss man beantworten: „Wer kontrolliert was, mit welchen Informationen, unter welchen Einschränkungen, und wer trägt die Verantwortung?" Die fünf Kriterien oben operationalisieren diese Frage. + +[discrete] +== *Aktueller Stand*: + +* Die kanonische Referenz ist Santoni de Sio & van den Hoven, https://doi.org/10.3389/frobt.2018.00015["Meaningful Human Control over Autonomous Systems: A Philosophical Account"] (Frontiers in Robotics and AI, 2018), mit den Bedingungen "Tracking" und "Tracing" +* Der Prior ist dünn: ein rein akademischer Fußabdruck, verankert in einem Open-Access-Philosophie-Paper (TU-Delft-Ethikgruppe) und einer Nischen-Literatur zur KI-Ethik, mit wenig Praktiker-Rezeption — liefere die Tracking/Tracing-Definitionen im Prompt mit, wenn es auf Präzision ankommt ==== diff --git a/docs/anchors/site-reliability-engineering.adoc b/docs/anchors/site-reliability-engineering.adoc index 3cb6d12e..1079d818 100644 --- a/docs/anchors/site-reliability-engineering.adoc +++ b/docs/anchors/site-reliability-engineering.adoc @@ -48,4 +48,10 @@ Key Proponents:: Ben Treynor Sloss (coined the term at Google); Betsy Beyer, Chr * <> * <> * <> + +[discrete] +== *Current Status*: + +* The prior serves the canon well: the 2016 SRE Book and 2018 Workbook (SLOs, error budgets, toil, postmortems) remain authoritative, and Google publishes all three books — including "Building Secure and Reliable Systems" (2020) — free at https://sre.google/books/[sre.google/books] +* What moved since the books is the organisational frame: SRE practice increasingly converges with platform engineering, with reliability capabilities embedded into internal platforms rather than delivered solely by standalone SRE teams — reflected in https://cloud.google.com/blog/products/application-modernization/a-guide-to-platform-engineering[Google's own platform-engineering guidance] ==== diff --git a/docs/anchors/site-reliability-engineering.de.adoc b/docs/anchors/site-reliability-engineering.de.adoc index d85723ab..f1a279f8 100644 --- a/docs/anchors/site-reliability-engineering.de.adoc +++ b/docs/anchors/site-reliability-engineering.de.adoc @@ -48,4 +48,10 @@ Schlüsselvertreter:: Ben Treynor Sloss (prägte den Begriff bei Google); Betsy * <> * <> * <> + +[discrete] +== *Aktueller Stand*: + +* Der Prior bedient den Kanon gut: SRE Book (2016) und Workbook (2018) — SLOs, Error Budgets, Toil, Postmortems — bleiben maßgeblich, und Google stellt alle drei Bücher inklusive "Building Secure and Reliable Systems" (2020) frei unter https://sre.google/books/[sre.google/books] bereit +* Bewegt hat sich seitdem der organisatorische Rahmen: SRE-Praxis konvergiert zunehmend mit Platform Engineering — Reliability-Fähigkeiten wandern in interne Plattformen statt in eigenständige SRE-Teams; nachzulesen in https://cloud.google.com/blog/products/application-modernization/a-guide-to-platform-engineering[Googles eigener Platform-Engineering-Anleitung] ==== diff --git a/docs/anchors/sota.adoc b/docs/anchors/sota.adoc index b6d5a01b..92107ce3 100644 --- a/docs/anchors/sota.adoc +++ b/docs/anchors/sota.adoc @@ -59,4 +59,10 @@ Key Proponent:: Widely used in ML/AI research community * Consistent meaning across contexts: "best performing" and "most current" * Concise trigger for comprehensive research behavior * Activates research-oriented response patterns in LLMs + +[discrete] +== *Current Status*: + +* "SOTA" is a timestamp, not a fact: any model's state-of-the-art knowledge is frozen at its training cutoff — and even the reference infrastructure churns: Papers with Code, long the canonical SOTA tracker, now redirects to Hugging Face and no longer exists as a leaderboard site (verified June 2026) +* When writing or reading "SOTA", attach an explicit date and source; for current rankings consult a live leaderboard (e.g. https://lmarena.ai/[lmarena.ai]) at the time of reading rather than any list a model produces from memory ==== diff --git a/docs/anchors/sota.de.adoc b/docs/anchors/sota.de.adoc index 3f1418d5..7e2c5f7a 100644 --- a/docs/anchors/sota.de.adoc +++ b/docs/anchors/sota.de.adoc @@ -58,4 +58,10 @@ Schlüsselvertreter:: Weit verbreitet in der ML/AI-Forschungsgemeinschaft * Konsistente Bedeutung über Kontexte hinweg: "am besten performend" und "aktuellst" * Präziser Trigger für umfassendes Rechercheverhalten * Aktiviert forschungsorientierte Antwortmuster in LLMs + +[discrete] +== *Aktueller Stand*: + +* "SOTA" ist ein Zeitstempel, keine Tatsache: Das State-of-the-Art-Wissen jedes Modells friert am Trainings-Cutoff ein — und sogar die Referenz-Infrastruktur churnt: Papers with Code, lange der kanonische SOTA-Tracker, leitet inzwischen zu Hugging Face um und existiert als Leaderboard-Site nicht mehr (verifiziert Juni 2026) +* Wer "SOTA" schreibt oder liest, hängt Datum und Quelle an; für aktuelle Rankings ein lebendes Leaderboard (z. B. https://lmarena.ai/[lmarena.ai]) zum Lesezeitpunkt konsultieren statt einer Liste aus dem Modellgedächtnis ==== diff --git a/docs/anchors/todotxt-flavoured-markdown.adoc b/docs/anchors/todotxt-flavoured-markdown.adoc index 6dd116d8..41add301 100644 --- a/docs/anchors/todotxt-flavoured-markdown.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.adoc @@ -81,4 +81,10 @@ Key Proponents:: Combines GitHub-flavoured Markdown task lists with Gina Trapani * Remains fully functional in plain text editors * Enables rich metadata without sacrificing readability * Facilitates both manual and automated task tracking + +[discrete] +== *Current Status*: + +* The underlying todo.txt format is alive and canonical at https://todotxt.org/[todotxt.org] (Gina Trapani): one task per line, priorities as `(A)`, projects as `+project`, contexts as `@context` +* The prior is thin twice over: todo.txt itself is a single-maintainer niche ecosystem from the plain-text-productivity scene, and the *Markdown-flavoured* combination this anchor describes is a project-level convention on top — paste the concrete conventions into the prompt rather than relying on the name ==== diff --git a/docs/anchors/todotxt-flavoured-markdown.de.adoc b/docs/anchors/todotxt-flavoured-markdown.de.adoc index 4d992c21..52cc885f 100644 --- a/docs/anchors/todotxt-flavoured-markdown.de.adoc +++ b/docs/anchors/todotxt-flavoured-markdown.de.adoc @@ -80,4 +80,10 @@ Schlüsselvertreter:: Combines GitHub-flavoured Markdown task lists with Gina Tr * Remains fully functional in plain text editors * Enables rich metadata without sacrificing readability * Facilitates both manual and automated task tracking + +[discrete] +== *Aktueller Stand*: + +* Das zugrunde liegende todo.txt-Format ist lebendig und kanonisch unter https://todotxt.org/[todotxt.org] (Gina Trapani): eine Aufgabe pro Zeile, Prioritäten als `(A)`, Projekte als `+projekt`, Kontexte als `@kontext` +* Der Prior ist doppelt dünn: todo.txt selbst ist ein Einzelbetreuer-Nischenökosystem aus der Plain-Text-Produktivitätsszene, und die *Markdown-flavoured*-Kombination dieses Ankers ist eine Projekt-Konvention obendrauf — füge die konkreten Konventionen in den Prompt ein, statt dich auf den Namen zu verlassen ==== diff --git a/docs/changelog.adoc b/docs/changelog.adoc index 2d5dd836..52290a54 100644 --- a/docs/changelog.adoc +++ b/docs/changelog.adoc @@ -4,6 +4,13 @@ A chronological record of all semantic anchors added to the catalog. Community c == 2026-06-11 +*Current Status sections, batch 4 — triage complete (#603):* + +* The remaining 14 versioned/living anchors now carry a *Current Status* section (EN + DE), all facts fetch-verified: arc42 (v9.0, July 2025, Section-10 split), C4 (levels stable, site rewritten 09/2024), Diátaxis (core stable, site grown), GitHub Flow (Chacon's 2011 continuous-deployment original vs GitHub's deploy-free current docs), PEAA (catalog unchanged since 2003, eaaDev frozen since 2006), BEM (definition stable, practice moved to utility-first — State of CSS no longer tracks methodologies), IEC 61508 (Ed 2 still current; Ed 3 forecast ~10/2026), LINDDUN (now a GO/PRO/MAESTRO family; no "MAID"), SRE (books canonical; platform-engineering convergence), SOTA (Papers with Code — the canonical tracker — no longer exists), Chain of Thought (reasoning models internalise it; OpenAI advises against "think step by step"), LLM-Evaluations (MMLU already superseded), Fagan Inspection and CRC Cards (definitions intact, practice moved on). +* The five thin-prior anchors (GoM, IOSP, Meaningful Human Control, todo.txt-flavoured Markdown, LASR) get verified canonical sources plus explicit supply-the-definition advice. +* *LASR rewritten:* verification revealed the previous entry was a silent substitution — it described a fabricated "lightweight architecture documentation template" with an invented acronym expansion (and the AgentSkill catalog carried a second, different invented expansion). The real LASR is the *Lightweight Approach for Software Reviews* (Toth & Zörner, lasr-reviews.org, "Reviewing Software Systems", Leanpub 2023), a streamlined ATAM alternative. The corrected anchor documents its own failure case as evidence for the thin-prior warning. +* The About page now states the lexicon positioning: inclusion means precision, not endorsement. + *Criticism sections, batch 3 (#603):* * The remaining twelve contested anchors from the catalog triage now carry a *Criticism* section (EN + DE), every claim with a named critic and a fetch-verified linked source: 4MAT (learning-styles evidence — Pashler et al. 2008, Kirschner 2017), AIDA (hierarchy-of-effects critique — Heath & Feldwick 2008, Vakratsas & Ambler 1999), Clean Architecture (indirection tax — Bogard, Comartin; alternative: Vertical Slice Architecture), CQRS (author-acknowledged overuse — Fowler, Dahan, Young), DRY (the authors' own "we did a poor job of explaining" concession plus Sandi Metz), Freytag's Pyramid (Jane Alison), GoF Design Patterns (Norvig's 16-of-23, Paul Graham's human compiler), Hero's Journey (folklorists Dundes and Toelken), Jobs To Be Done (the Christensen-vs-Ulwick two-schools problem), Kotter's 8 Steps (no empirical validation of the whole model — Appelbaum et al. 2012; Kotter's own Accelerate revision), MVP (term dilution — NN/g; Kniberg's skateboard corrective), and Save the Cat (Suderman's "Save the Movie!"). diff --git a/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md b/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md index e3aee93c..ca34b74c 100644 --- a/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md +++ b/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md @@ -162,7 +162,7 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Core:** Six-part template that turns a vague quality goal into a testable statement — Source, Stimulus, Artifact, Environment, Response, Response Measure; the Response Measure (a latency, percentile, throughput, recovery time) is what makes it verifiable; expresses arc42 Chapter 10 quality requirements and the leaves of an ATAM utility tree ### LASR by Toth/Zörner -- **Also known as:** Layers–Aspects–Solution Strategy–Rationale +- **Also known as:** Lightweight Approach for Software Reviews - **Proponents:** Stefan Toth, Stefan Zörner - **Core:** Lightweight architecture description framework — describe a system through four lenses: Layers (structural decomposition), Aspects (cross-cutting concerns), Solution Strategy (key technology and design choices), Rationale (documented reasoning behind decisions); pairs naturally with arc42 and ADRs diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md index e3aee93c..ca34b74c 100644 --- a/skill/semantic-anchor-translator/references/catalog.md +++ b/skill/semantic-anchor-translator/references/catalog.md @@ -162,7 +162,7 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Core:** Six-part template that turns a vague quality goal into a testable statement — Source, Stimulus, Artifact, Environment, Response, Response Measure; the Response Measure (a latency, percentile, throughput, recovery time) is what makes it verifiable; expresses arc42 Chapter 10 quality requirements and the leaves of an ATAM utility tree ### LASR by Toth/Zörner -- **Also known as:** Layers–Aspects–Solution Strategy–Rationale +- **Also known as:** Lightweight Approach for Software Reviews - **Proponents:** Stefan Toth, Stefan Zörner - **Core:** Lightweight architecture description framework — describe a system through four lenses: Layers (structural decomposition), Aspects (cross-cutting concerns), Solution Strategy (key technology and design choices), Rationale (documented reasoning behind decisions); pairs naturally with arc42 and ADRs From 8c32adaf46fc7bb28cbf2bd3babbfe8077aa916b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Thu, 11 Jun 2026 18:40:37 +0200 Subject: [PATCH 2/2] fix: replace fabricated LASR Core description in AgentSkill catalog The previous commit fixed the "Also known as" line but left the Core field describing the invented "lightweight architecture description framework" with the fabricated Layers/Aspects/Solution Strategy/Rationale expansion. The Core field now describes the real review method (Lean Mission Statement, Evaluation Criteria, Risk-based Review, Quality-focused Analysis, Result Diagram, workshop format). Found by CodeRabbit review. Refs #603 Co-Authored-By: Claude Fable 5 --- .../skills/semantic-anchor-translator/references/catalog.md | 2 +- skill/semantic-anchor-translator/references/catalog.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md b/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md index ca34b74c..cec8b9c3 100644 --- a/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md +++ b/plugins/semantic-anchors/skills/semantic-anchor-translator/references/catalog.md @@ -164,7 +164,7 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors ### LASR by Toth/Zörner - **Also known as:** Lightweight Approach for Software Reviews - **Proponents:** Stefan Toth, Stefan Zörner -- **Core:** Lightweight architecture description framework — describe a system through four lenses: Layers (structural decomposition), Aspects (cross-cutting concerns), Solution Strategy (key technology and design choices), Rationale (documented reasoning behind decisions); pairs naturally with arc42 and ADRs +- **Core:** Lightweight review method for efficient software reviews — uncovers weaknesses and challenges architectural ideas; more streamlined than ATAM. Key elements: Lean Mission Statement (shared vision), Evaluation Criteria (quantified quality attributes), Risk-based Review, Quality-focused Analysis, LASR Result Diagram (objectives vs. assessment), workshop format (moderated team event with LASR-Cards). Community-driven and free to use (lasr-reviews.org) ### Lehman's Software Classification - **Also known as:** SPE Classification, Lehman's SPE Taxonomy diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md index ca34b74c..cec8b9c3 100644 --- a/skill/semantic-anchor-translator/references/catalog.md +++ b/skill/semantic-anchor-translator/references/catalog.md @@ -164,7 +164,7 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors ### LASR by Toth/Zörner - **Also known as:** Lightweight Approach for Software Reviews - **Proponents:** Stefan Toth, Stefan Zörner -- **Core:** Lightweight architecture description framework — describe a system through four lenses: Layers (structural decomposition), Aspects (cross-cutting concerns), Solution Strategy (key technology and design choices), Rationale (documented reasoning behind decisions); pairs naturally with arc42 and ADRs +- **Core:** Lightweight review method for efficient software reviews — uncovers weaknesses and challenges architectural ideas; more streamlined than ATAM. Key elements: Lean Mission Statement (shared vision), Evaluation Criteria (quantified quality attributes), Risk-based Review, Quality-focused Analysis, LASR Result Diagram (objectives vs. assessment), workshop format (moderated team event with LASR-Cards). Community-driven and free to use (lasr-reviews.org) ### Lehman's Software Classification - **Also known as:** SPE Classification, Lehman's SPE Taxonomy