feat: add 'Explaining and Teaching' contract

docs/changelog.adoc

@@ -10,6 +10,10 @@ A chronological record of all semantic anchors added to the catalog. Community c
 * *Event Storming according to Alberto Brandolini* — a collaborative workshop that models a domain as past-tense domain events on a timeline using a fixed colour notation (orange Event, blue Command, yellow Aggregate, lilac Policy, green Read Model, pink External System, red Hotspot) across three levels (Big Picture, Process Modeling, Design Level); surfaces bounded-context seams via pivotal events and makes assumptions explicit as hotspots; Reverse Event Storming reconstructs legacy systems (Alberto Brandolini, 2012/2013; proposed by https://github.com/SidekickJohn[@SidekickJohn] in https://github.com/LLM-Coding/Semantic-Anchors/issues/558[#558])
 * *Bloom's Taxonomy* — the six-level hierarchy of cognitive learning objectives (Remember, Understand, Apply, Analyze, Evaluate, Create) with measurable action verbs per level; pins the Revised 2001 version and its knowledge dimension; complements the teaching cluster (4MAT, Feynman, Socratic) by grading the cognitive *level* a step targets — so "demonstrated understanding" can be set at Apply/Analyze rather than recall (Benjamin Bloom, 1956; Anderson & Krathwohl revision, 2001)
 
+*New contracts:*
+
+* *Explaining and Teaching* — a gated teaching loop for "explain / why / how" requests: explain *and* verify understanding. Composes 4MAT (Why→What→How→What-If), Programming as Theory Building (the why behind the design), Socratic Method (diagnose first), Feynman Technique (explain-it-back), Bloom's Taxonomy (understood = Apply/Analyze, not recall) and Definition of Done (a checklist demonstrated, not nodded at); scales to the size of the question
+
 == 2026-06-01
 
 *New anchors:*

website/public/data/contracts.json

@@ -181,6 +181,17 @@
     "templateDe": "Komplexe Konzepte mit einfacher Sprache und Alltagsanalogien erklären. Wenn die Erklärung schwerfällt, zeigt das Wissenslücken — diese zuerst vertiefen (Feynman-Technik).",
     "category": "communication"
   },
+  {
+    "id": "explaining-teaching",
+    "title": "Explaining and Teaching",
+    "titleDe": "Erklären und Lehren",
+    "description": "How to teach a topic until understanding is verified, not just explained",
+    "descriptionDe": "Wie man ein Thema lehrt, bis das Verständnis geprüft ist — nicht nur erklärt",
+    "anchors": ["4mat", "mental-model-according-to-naur", "socratic-method", "feynman-technique", "blooms-taxonomy", "definition-of-done"],
+    "template": "Teach until the learner genuinely understands — don't just explain. Sequence each unit Why → What → How → What-If (4MAT): motivation before detail. Treat the Why as Naur's program theory — the reasoning, trade-offs, and branches not taken behind the design, not merely what the code does; drill recursively into why. Diagnose first (Socratic Method): have the learner restate their current understanding, then fill the gaps with questions, not answers, adjusting depth on request (ELI5 / ELI-intern). The sharpest check is having them explain it back in plain words (Feynman Technique) — where they stall is the gap. Keep a running, written checklist of what must be grasped — high level (why it matters, what it impacts) and low level (logic, edge cases, design decisions) — a Definition of Done for understanding. After each point, verify by active recall — an open or multiple-choice question, a code walkthrough, the debugger — never \"makes sense?\". \"Understood\" means Bloom's Apply/Analyze level (use it on a new case, trace the edge cases), not recall. Don't advance until the current point is demonstrated, and don't end until the whole checklist is. Scale the ceremony to the size of the question.",
+    "templateDe": "Lehren, bis die lernende Person es wirklich versteht — nicht nur erklären. Jede Einheit in der Reihenfolge Why → What → How → What-If aufbauen (4MAT): Motivation vor Detail. Das Why als Naurs Programm-Theory behandeln — die Begründung, die Trade-offs und die nicht gewählten Alternativen hinter dem Design, nicht bloß was der Code tut; rekursiv ins Warum bohren. Erst diagnostizieren (Socratic Method): die Person ihr aktuelles Verständnis zurückgeben lassen, dann die Lücken mit Fragen statt Antworten füllen und die Tiefe auf Wunsch anpassen (ELI5 / ELI-intern). Die schärfste Probe ist das Zurückerklären in einfachen Worten (Feynman Technique) — wo sie stockt, ist die Lücke. Eine laufende, schriftliche Checkliste führen, was verstanden sein muss — high level (warum es zählt, was es beeinflusst) und low level (Logik, Edge Cases, Design-Entscheidungen) — eine Definition of Done fürs Verständnis. Nach jedem Punkt durch active recall prüfen — eine offene oder Multiple-Choice-Frage, ein Code-Walkthrough, der Debugger — nie \"passt das?\". \"Verstanden\" heißt Blooms Apply/Analyze-Stufe (auf einen neuen Fall anwenden, Edge Cases durchspielen), nicht Abrufen. Nicht weitergehen, bis der aktuelle Punkt demonstriert ist, und nicht enden, bis die ganze Checkliste es ist. Die Zeremonie an die Größe der Frage anpassen.",
+    "category": "communication"
+  },
   {
     "id": "writing-style",
     "title": "Writing Style",