Add LASR nach Toth/Zörner semantic anchor

docs/all-anchors.adoc

@@ -115,6 +115,8 @@ include::anchors/gom.adoc[leveloffset=+2]
 
 include::anchors/hexagonal-architecture.adoc[leveloffset=+2]
 
+include::anchors/lasr.adoc[leveloffset=+2]
+
 include::anchors/madr.adoc[leveloffset=+2]
 
 <<<

docs/anchors/lasr.adoc

@@ -0,0 +1,46 @@
+= 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
+:proponents: Stefan Toth, Stefan Zörner
+:tags: architecture-documentation, solution-strategy, interfaces, risks, lightweight, communication
+
+[%collapsible]
+====
+Full Name:: LASR – Lightweight Architecture Documentation by Toth/Zörner
+
+Also known as:: Lightweight Architecture Communication, LASR Template
+
+[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 – Architekturüberblick (Architecture Overview):: Key structural and runtime views showing the main building blocks, their responsibilities, and how they interact at runtime
+
+S – Schnittstellen (Interfaces):: Definition of all relevant external interfaces (APIs, protocols, data formats) and important internal interfaces between major components
+
+R – Risiken (Risks):: Identification of the most critical technical risks, open questions, and known weaknesses together with proposed mitigation strategies
+
+Lightweight by design:: LASR intentionally focuses on the four most communication-relevant aspects of an architecture, omitting detail that does not aid stakeholder understanding
+
+Living document:: Updated alongside the architecture; meant to communicate current state, not archive history
+
+Key Proponents:: Stefan Toth ("Vorgehensmuster für Softwarearchitektur"), Stefan Zörner ("Softwarearchitekturen dokumentieren und kommunizieren")
+
+[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
+
+[discrete]
+== *Related Anchors*:
+
+* <<arc42,arc42 Architecture Documentation>>
+* <<adr-according-to-nygard,ADR according to Nygard>>
+* <<c4-diagrams,C4 Diagrams>>
+====

docs/anchors/lasr.de.adoc

@@ -0,0 +1,46 @@
+= 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
+:proponents: Stefan Toth, Stefan Zörner
+:tags: architecture-documentation, solution-strategy, interfaces, risks, lightweight, communication
+
+[%collapsible]
+====
+Vollständiger Name:: LASR – Leichtgewichtige Architekturdokumentation nach Toth/Zörner
+
+Auch bekannt als:: Leichtgewichtige Architekturkommunikation, LASR-Template
+
+[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
+
+A – Architekturüberblick:: Wesentliche Struktur- und Laufzeitsichten mit den wichtigsten Bausteinen, deren Verantwortlichkeiten und ihrer Interaktion zur Laufzeit
+
+S – Schnittstellen:: Definition aller relevanten Außenschnittstellen (APIs, Protokolle, Datenformate) sowie wichtiger interner Schnittstellen zwischen den Hauptkomponenten
+
+R – Risiken:: Identifikation der kritischsten technischen Risiken, offener Fragen und bekannter Schwächen zusammen mit vorgeschlagenen Maßnahmen zur Risikoreduzierung
+
+Bewusst leichtgewichtig:: LASR konzentriert sich gezielt auf die vier kommunikationsrelevantesten Aspekte einer Architektur und verzichtet auf Details, die das Stakeholder-Verständnis nicht verbessern
+
+Lebendes Dokument:: Wird parallel zur Architektur aktualisiert; dient der Kommunikation des aktuellen Stands, nicht der Archivierung von Geschichte
+
+Schlüsselvertreter:: Stefan Toth ("Vorgehensmuster für Softwarearchitektur"), Stefan Zörner ("Softwarearchitekturen dokumentieren und kommunizieren")
+
+[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
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<arc42,arc42 Architekturdokumentation>>
+* <<adr-according-to-nygard,ADR nach Nygard>>
+* <<c4-diagrams,C4-Diagramme>>
+====

docs/metadata/roles.yml

@@ -104,6 +104,15 @@ hexagonal-architecture:
     - software-developer
   rationale: "Architectural pattern; architects design, developers implement ports/adapters"
 
+lasr:
+  roles:
+    - software-architect
+    - software-developer
+    - technical-writer
+    - team-lead
+    - consultant
+  rationale: "Lightweight architecture documentation; architects create LASR docs, developers contribute interface and risk sections, tech writers format, team leads use for onboarding, consultants teach the approach"
+
 clean-architecture:
   roles:
     - software-architect
@@ -386,17 +395,17 @@ feynman-technique:
 
 # SUMMARY STATISTICS
 
-# Total anchors mapped: 50
+# Total anchors mapped: 51
 #
 # Roles by frequency:
-#   - software-developer: 25 anchors (50%)
-#   - team-lead: 21 anchors (42%)
-#   - software-architect: 18 anchors (36%)
-#   - consultant: 16 anchors (32%)
-#   - qa-engineer: 14 anchors (28%)
-#   - business-analyst: 13 anchors (26%)
+#   - software-developer: 26 anchors (51%)
+#   - team-lead: 22 anchors (43%)
+#   - software-architect: 19 anchors (37%)
+#   - consultant: 17 anchors (33%)
+#   - qa-engineer: 14 anchors (27%)
+#   - business-analyst: 13 anchors (25%)
 #   - devops-engineer: 10 anchors (20%)
-#   - technical-writer: 9 anchors (18%)
+#   - technical-writer: 10 anchors (20%)
 #   - product-owner: 8 anchors (16%)
 #   - data-scientist: 7 anchors (14%)
 #   - educator: 7 anchors (14%)

website/public/data/anchors.json

@@ -482,6 +482,38 @@
     "tags": [],
     "filePath": "docs/anchors/jobs-to-be-done.adoc"
   },
+  {
+    "id": "lasr",
+    "title": "LASR by Toth/Zörner",
+    "categories": [
+      "software-architecture"
+    ],
+    "roles": [
+      "software-architect",
+      "software-developer",
+      "technical-writer",
+      "team-lead",
+      "consultant"
+    ],
+    "related": [
+      "arc42",
+      "adr-according-to-nygard",
+      "c4-diagrams"
+    ],
+    "proponents": [
+      "Stefan Toth",
+      "Stefan Zörner"
+    ],
+    "tags": [
+      "architecture-documentation",
+      "solution-strategy",
+      "interfaces",
+      "risks",
+      "lightweight",
+      "communication"
+    ],
+    "filePath": "docs/anchors/lasr.adoc"
+  },
   {
     "id": "madr",
     "title": "MADR",
@@ -1034,4 +1066,4 @@
     "tags": [],
     "filePath": "docs/anchors/what-qualifies-as-a-semantic-anchor.adoc"
   }
-]
+]

website/public/data/categories.json

@@ -89,6 +89,7 @@
       "domain-driven-design",
       "gom",
       "hexagonal-architecture",
+      "lasr",
       "madr"
     ]
   },

website/public/data/metadata.json

@@ -1,15 +1,15 @@
 {
-  "generatedAt": "2026-03-04T12:59:17.826Z",
+  "generatedAt": "2026-03-06T17:54:22.119Z",
   "version": "1.0.0",
   "counts": {
-    "anchors": 54,
+    "anchors": 55,
     "categories": 12,
     "roles": 12
   },
   "statistics": {
-    "averageRolesPerAnchor": "3.33",
+    "averageRolesPerAnchor": "3.36",
     "averageCategoriesPerAnchor": "1.00",
-    "anchorsWithTags": 9,
-    "anchorsWithRelated": 8
+    "anchorsWithTags": 10,
+    "anchorsWithRelated": 9
   }
 }

website/public/data/roles.json

@@ -33,6 +33,7 @@
       "gom",
       "iec-61508-sil-levels",
       "impact-mapping",
+      "lasr",
       "mece",
       "mental-model-according-to-naur",
       "morphological-box",
@@ -144,6 +145,7 @@
       "gom",
       "hexagonal-architecture",
       "iec-61508-sil-levels",
+      "lasr",
       "madr",
       "mece",
       "morphological-box",
@@ -175,6 +177,7 @@
       "fowler-patterns",
       "hexagonal-architecture",
       "iec-61508-sil-levels",
+      "lasr",
       "madr",
       "mental-model-according-to-naur",
       "morphological-box",
@@ -212,6 +215,7 @@
       "fowler-patterns",
       "gom",
       "impact-mapping",
+      "lasr",
       "madr",
       "mental-model-according-to-naur",
       "moscow",
@@ -237,6 +241,7 @@
       "diataxis-framework",
       "docs-as-code",
       "ears-requirements",
+      "lasr",
       "pyramid-principle",
       "todotxt-flavoured-markdown"
     ]