diff --git a/backend/config.py b/backend/config.py
index 8ace1af..f09be5e 100644
--- a/backend/config.py
+++ b/backend/config.py
@@ -36,6 +36,8 @@ TIMEOUTS = {
     "guide_auswahl": (300, 5),    # pro Baustein im Inventar
     "plan":          (300, 5),
     "plan_judge":    (600, 5),    # Judge liest bis zu 5 Gliederungen, n = Sections
+    "inhalt":        (600, 90),   # Inhalte je Baustein im Chunk identifizieren (Websuche)
+    "inhalt_check":  (300, 10),   # Inhalts-Prüfung je Baustein im Paket
     "writer":        (600, 120),  # pro Section im Chunk
     "lese_check":    (300, 10),   # pro Section im Paket
     "onepager_recherche": (900, 0),
diff --git a/backend/guide.py b/backend/guide.py
index 42a734a..f238d74 100644
--- a/backend/guide.py
+++ b/backend/guide.py
@@ -38,7 +38,7 @@ from textkit import (
 
 log = logging.getLogger("creator.guide")
 
-GUIDE_STEPS = ("Auswahl", "Gliederung", "Schreiben", "Lese-Prüfung")
+GUIDE_STEPS = ("Auswahl", "Gliederung", "Inhalte", "Inhalts-Check", "Schreiben", "Lese-Prüfung")
 
 # Writer skalieren mit der Section-Zahl: 1 Writer je ~30 Sections (gedeckelt).
 # Kleine Pakete vermeiden Lazy-Output bei langen Listen und begrenzen den Schaden
@@ -455,22 +455,128 @@ async def _generate_sections(
             await _fail(guide_id, "Gliederung fehlgeschlagen (Judge ohne gültiges Ergebnis)")
             return None
 
-    # Schritt 2: Schreiben — vorhandene Chunk-Dateien werden übernommen (Resume)
+    # Chunks festlegen — Inhalte, Inhalts-Prüfung, Writer und Lese-Check nutzen
+    # dieselbe Aufteilung: 1 Agent je ~30 Bausteine (gedeckelt).
     total_sections = sum(len(c["nums"]) for c in plan)
     chunks = _split_chunks(plan, min(WRITER_MAX, max(1, math.ceil(total_sections / WRITER_SECTIONS))))
     zuteilungen = [_zuteilung_text(chunk, entries) for chunk in chunks]
     chunk_sizes = [sum(len(c["nums"]) for c in chunk) for chunk in chunks]
-    writer_count = len(zuteilungen)
+    writer_count = len(chunks)
+    idx = _titel_index(entries)
+
+    # Schritt 2: Inhalte je Baustein identifizieren — pro Chunk ein Agent (Marker-Output, Resume).
+    inhalt_paths = [content_path.parent / f"{content_path.stem}.inhalt-chunk-{i}.md" for i in range(1, writer_count + 1)]
+    offen = [i for i, p in enumerate(inhalt_paths) if not p.exists()]
+    if offen:
+        await _set_step(guide_id, 2, f"Sammle Inhalte ({writer_count} Agenten)…" if writer_count > 1 else "Sammle Inhalte…")
+        results = await asyncio.gather(*[
+            run_agent(
+                f"{guide_id}-inhalt-{i + 1}",
+                _prompt(
+                    "Guide-Inhalt",
+                    topic=topic, zuteilung=zuteilungen[i], facts=facts,
+                    out_path=inhalt_paths[i], extra=_extra(instructions),
+                ),
+                _timeout("inhalt", chunk_sizes[i]), provider=provider, role="guide", capabilities="full",
+            )
+            for i in offen
+        ], return_exceptions=True)
+        if is_cancelled():
+            return None
+        if not any(p.exists() for p in inhalt_paths):
+            await _fail(guide_id, _gather_error("Inhalts-Fehler", list(results)))
+            return None
+
+    inhalt_by_num: dict[int, str] = {}
+    for p in inhalt_paths:
+        if not p.exists():
+            continue
+        for sec in _parse_fragment(p.read_text(encoding="utf-8")):
+            num = _titel_aufloesen(idx, sec["titel"])
+            if num is not None and num not in inhalt_by_num and sec["md"].strip():
+                inhalt_by_num[num] = sec["md"]
+    if not inhalt_by_num:
+        await _fail(guide_id, "Keine Inhalte identifiziert")
+        return None
+
+    inhalt_chunk_nums = [[num for ch in chunk for num in ch["nums"] if num in inhalt_by_num] for chunk in chunks]
+
+    # Schritt 3: Inhalte prüfen (pro Chunk ein Check) + beanstandete einmal überarbeiten.
+    check_paths = [content_path.parent / f"{content_path.stem}.inhalt-check-{i}.json" for i in range(1, writer_count + 1)]
+    offen_checks = [i for i, p in enumerate(check_paths) if inhalt_chunk_nums[i] and _lese_probleme_schema(_json_datei(p)) is None]
+    if offen_checks:
+        await _set_step(guide_id, 3, "Prüfe Inhalte…")
+        slots = [{
+            "key": f"{guide_id}-inhalt-check-{i + 1}",
+            "prompt": _prompt(
+                "Guide-Inhalt-Check",
+                topic=topic, format_name=format_name,
+                sections="\n\n".join(f"SECTION: {_titel(entries[num])}\n{inhalt_by_num[num]}" for num in inhalt_chunk_nums[i]),
+                out_path=check_paths[i], extra=_extra(instructions),
+            ),
+            "role": "judge", "capabilities": "files",
+            "payload": (lambda result, p=check_paths[i]: _lese_probleme_schema(_json_datei(p))),
+        } for i in offen_checks]
+        await _race(topic, "Inhalts-Prüfung", slots, len(slots), _timeout("inhalt_check", max(chunk_sizes)), provider, cancelled=is_cancelled)
+        if is_cancelled():
+            return None
+
+    probleme_by_num: dict[int, str] = {}
+    for i, p in enumerate(check_paths):
+        geltung = set(inhalt_chunk_nums[i])
+        for item in (_lese_probleme_schema(_json_datei(p)) or []):
+            num = _titel_aufloesen(idx, item["section"])
+            if num in geltung and num in inhalt_by_num and num not in probleme_by_num:
+                probleme_by_num[num] = item["problem"]
+
+    if probleme_by_num:
+        _log(topic, f"Inhalts-Prüfung: {len(probleme_by_num)} Baustein(e) beanstandet")
+        await _set_step(guide_id, 3, f"Überarbeite {len(probleme_by_num)} Inhalt(e)…")
+        fix_chunks = [[num for num in nums if num in probleme_by_num] for nums in inhalt_chunk_nums]
+        fix_paths = [content_path.parent / f"{content_path.stem}.inhalt-fix-{i + 1}.md" for i in range(writer_count)]
+        fix_offen = [i for i, nums in enumerate(fix_chunks) if nums and not fix_paths[i].exists()]
+        results = await asyncio.gather(*[
+            run_agent(
+                f"{guide_id}-inhalt-fix-{i + 1}",
+                _prompt(
+                    "Guide-Inhalt-Fix",
+                    topic=topic, facts=facts,
+                    auftraege="\n\n".join(
+                        f"SECTION: {_titel(entries[num])}\nPROBLEM: {probleme_by_num[num]}\nAKTUELL:\n{inhalt_by_num[num]}"
+                        for num in fix_chunks[i]
+                    ),
+                    out_path=fix_paths[i], extra=_extra(instructions),
+                ),
+                _timeout("inhalt", len(fix_chunks[i])), provider=provider, role="guide", capabilities="full",
+            )
+            for i in fix_offen
+        ], return_exceptions=True)
+        if is_cancelled():
+            return None
+        for p in fix_paths:
+            if not p.exists():
+                continue
+            for sec in _parse_fragment(p.read_text(encoding="utf-8")):
+                num = _titel_aufloesen(idx, sec["titel"])
+                if num in probleme_by_num and sec["md"].strip():
+                    inhalt_by_num[num] = sec["md"]
+
+    # Schritt 4: Schreiben — Writer formuliert die geprüften Inhalte aus (Resume).
+    def inhalte_text(chunk) -> str:
+        nums = [num for ch in chunk for num in ch["nums"] if num in inhalt_by_num]
+        return "\n\n".join(f"<!-- section: {_titel(entries[num])} -->\n{inhalt_by_num[num]}" for num in nums)
+
     paths = [content_path.parent / f"{content_path.stem}.chunk-{i}.md" for i in range(1, writer_count + 1)]
     offen = [i for i, p in enumerate(paths) if not p.exists()]
     if offen:
-        await _set_step(guide_id, 2, f"Schreibe Sections ({writer_count} Writer)…" if writer_count > 1 else "Schreibe Sections…")
+        await _set_step(guide_id, 4, f"Schreibe Sections ({writer_count} Writer)…" if writer_count > 1 else "Schreibe Sections…")
         results = await asyncio.gather(*[
             run_agent(
                 f"{guide_id}-w{i + 1}",
                 _prompt(
                     "Guide-Writer",
                     topic=topic, format_name=format_name, zuteilung=zuteilungen[i],
+                    inhalte=inhalte_text(chunks[i]),
                     facts=facts, spec=spec, out_path=paths[i], extra=_extra(instructions),
                 ),
                 _timeout("writer", chunk_sizes[i]), provider=provider, role="guide", capabilities="full",
@@ -490,7 +596,6 @@ async def _generate_sections(
             await _fail(guide_id, _gather_error("Writer-Fehler", list(results)))
             return None
 
-    idx = _titel_index(entries)
     by_num: dict[int, dict] = {}
     for p in paths:
         if not p.exists():
@@ -524,7 +629,7 @@ async def _generate_sections(
         check_paths = [content_path.parent / f"{content_path.stem}.lese-check-r{runde}-{i}.json" for i in range(1, writer_count + 1)]
         offen_checks = [i for i, p in enumerate(check_paths) if scope[i] and _lese_probleme_schema(_json_datei(p)) is None]
         if offen_checks:
-            await _set_step(guide_id, 3, f"Prüfe Lesbarkeit (Runde {runde}/{KONSENS_MAX_RUNDEN})…")
+            await _set_step(guide_id, 5, f"Prüfe Lesbarkeit (Runde {runde}/{KONSENS_MAX_RUNDEN})…")
             slots = [{
                 "key": f"{guide_id}-lese-check-r{runde}-{i + 1}",
                 "prompt": _prompt(
@@ -557,7 +662,7 @@ async def _generate_sections(
             break
 
         _log(topic, f"Lese-Prüfung Runde {runde}: {len(probleme_by_num)} Section(s) beanstandet")
-        await _set_step(guide_id, 3, f"Überarbeite {len(probleme_by_num)} Section(s) (Runde {runde})…")
+        await _set_step(guide_id, 5, f"Überarbeite {len(probleme_by_num)} Section(s) (Runde {runde})…")
         fix_chunks = [[num for num in nums if num in probleme_by_num] for nums in chunk_nums]
         fix_paths = [content_path.parent / f"{content_path.stem}.fix-r{runde}-{i + 1}.md" for i in range(writer_count)]
         fix_offen = [i for i, nums in enumerate(fix_chunks) if nums and not fix_paths[i].exists()]
diff --git a/frontend/src/components/TopicSidebar.vue b/frontend/src/components/TopicSidebar.vue
index 4c6fe4b..d9c1b3b 100644
--- a/frontend/src/components/TopicSidebar.vue
+++ b/frontend/src/components/TopicSidebar.vue
@@ -93,7 +93,7 @@ function guideStatus(format) {
 }
 
 // Schritt-Kugeln der Guide-Pipelines
-const GUIDE_STEPS = ['Auswahl', 'Gliederung', 'Schreiben', 'Lese-Prüfung']
+const GUIDE_STEPS = ['Auswahl', 'Gliederung', 'Inhalte', 'Inhalts-Check', 'Schreiben', 'Lese-Prüfung']
 const ONEPAGER_STEPS = ['Recherche', 'Bauen', 'Prüfung']
 
 // Kugeln werden wie bei den Bausteinen immer angezeigt:
diff --git a/recherche.txt b/recherche.txt
new file mode 100644
index 0000000..af7aa2d
--- /dev/null
+++ b/recherche.txt
@@ -0,0 +1,167 @@
+================================================================================
+RECHERCHE: Guide-Generierungskette erweitern
+Ziel: Lernen ohne Angst vor (a) Falschem, (b) fehlenden Infos,
+      (c) nervigem Aufbau, (d) Überforderung durch Struktur/Auswahl/Lesbarkeit.
+Bestehende Kette: Auswahl → Gliederung → Inhalte → Inhalts-Check → Writer → Lese-Check.
+================================================================================
+
+## META-ERKENNTNIS (gilt übergreifend)
+- "Mehr gleiche Agenten" sättigt früh und erzeugt Echo-Kammer: identische Modelle
+  teilen dieselben systematischen Fehler. Voting/Debatte schlagen Single-Agent nur
+  moderat und nicht zuverlässig besser als Self-Consistency.
+- Echte Hebel: HETEROGENITÄT (andere Modelle), EXTERNE ERDUNG (Quellen/Tools/Websuche),
+  ROLLEN-TRENNUNG, GATES zwischen Stufen.
+- Selbst-Korrektur OHNE externes Feedback verbessert Faktualität kaum, kann verschlechtern
+  (CommonSenseQA 75,8 → 38,1 nach 1 Runde). Nur MIT Quelle/Tool/Oracle einsetzen.
+- ~41,8 % der Multi-Agent-Fehler sind System-/Spezifikations-Design, nicht Modell-Fähigkeit
+  (MAST). → Architektur (Rollen, Gates, Stopp-Logik) ist der größte Hebel.
+
+
+================================================================================
+A) GEGEN FALSCHES (faktische Korrektheit)
+================================================================================
+1. RAG / Grounding gegen verlässliche Quellen — stärkster Hebel gegen erfundene Fakten.
+   Generierung auf abgerufene Quell-Passagen beschränken. (Inhalte/Prüfen)
+2. Zitat-Pflicht + Attribution: jeder Fakt braucht Inline-Quelle; gilt nur als belegt,
+   wenn aus dem Zitat ableitbar. Macht Fehler sichtbar/prüfbar. (Schreiben/Prüfen)
+3. Claim-Extraktion + Verifikation (FActScore-Stil): Text in atomare Fakten zerlegen,
+   jeden einzeln gegen Quelle prüfen. Fängt einzelne falsche Sätze. (Prüfen)
+4. SAFE (Search-Augmented Factuality Evaluator): Claims zerlegen → pro Claim Websuche →
+   per Reasoning prüfen. Übertrifft menschliche Annotatoren, ~20x billiger.
+   Ideal, da Websuche schon vorhanden. (Prüfen)
+5. Abstention bei Unsicherheit: unbelegte/inkonsistente Fakten weglassen oder markieren
+   statt raten. Tauscht Coverage gegen Korrektheit — für Lerninhalte oft richtig.
+6. Chain-of-Verification (CoVe): Entwurf → Verifikationsfragen → einzeln beantworten →
+   revidieren. Günstig (reines Prompting). (Prüfen, pro Baustein)
+7. Self-Consistency: mehrere Pfade samplen, Mehrheit wählen. Nur für Varianz-Reduktion,
+   NICHT für Wahrheit (systematische Fehler bleiben). Sweet Spot 10–20 Samples.
+8. Post-hoc Revision (RARR): fertigen Text nehmen, pro Claim Evidenz suchen, widersprechende
+   Claims editieren, Originaltext maximal erhalten. (zwischen Schreiben und Lesbarkeit)
+9. Stärkerer Verifier statt mehr gleicher Agenten: generieren günstig, verifizieren mit
+   stärkerem/anderem Modell. Lohnt bei schwierigen/seltenen Fakten. (Prüfen)
+10. Self-Refine/Reflexion NUR mit externem Feedback (Tool/Quelle). Intrinsisch verschlechtert.
+
+Quellen A:
+- SAFE / Long-form Factuality: https://openreview.net/pdf?id=4M9f8VMt2C
+- FActScore (Primer): https://aman.ai/primers/ai/factuality-in-LLMs/
+- Chain-of-Verification: https://arxiv.org/pdf/2309.11495
+- Grounded Attribution + Refuse: https://arxiv.org/pdf/2409.11242
+- Self-Correction braucht externes Feedback: https://arxiv.org/abs/2310.01798
+- When Can LLMs Self-Correct (TACL): https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00713/125177/
+- RARR: https://aclanthology.org/2023.acl-long.910/
+- Weaver / Generation-Verification-Gap: https://arxiv.org/pdf/2506.18203
+- Abstention-Survey: https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00754/131566/
+
+
+================================================================================
+B) GEGEN LÜCKEN (Vollständigkeit)
+================================================================================
+1. Backward Design (Stufe 0): zuerst Lernziele definieren, DANN Inhalt generieren.
+   3 Schichten: "familiar with" / "important to know" / "enduring understanding".
+2. Lernziele explizit als Anker-Liste (Bloom-Verben). Jeder Abschnitt wird genau einem
+   Lernziel zugeordnet. Ziel ohne Inhalt = Lücke; Inhalt ohne Ziel = Ballast.
+3. Curriculum-Mapping / Alignment-Matrix (Lernziel × Abschnitt × Assessment) als eigene
+   Stufe: prüft Abdeckung, Doppelungen, hängende Ziele gleichzeitig.
+4. "What's missing"-Critic-Agent: bekommt Thema + Guide + Referenzfakten, sucht NUR
+   fehlende korrekte Punkte, bessert minimal nach. Discrimination von Revision trennen.
+5. "Das Wichtige" verlässlich via Mehrquellen-Konsens (Triangulation): Standard-Curricula
+   + mehrere unabhängige Quellen (Schnittmenge = Kern) + LLM-Delphi (Konsens-Topics).
+
+Quellen B:
+- Backward Design: https://fctl.ucf.edu/teaching-resources/course-design/backward-design/
+- Understanding by Design: https://en.wikipedia.org/wiki/Understanding_by_Design
+- GPT-4 Learning Objectives: https://arxiv.org/pdf/2306.17459
+- Curriculum Mapping: https://pce.sandiego.edu/curriculum-mapping/
+- Critique-Guided Improvement: https://arxiv.org/pdf/2503.16024
+- Delphi-Konsens (PMC): https://pmc.ncbi.nlm.nih.gov/articles/PMC8178515/
+
+
+================================================================================
+C) GEGEN ÜBERFORDERUNG (Struktur, Reihenfolge, Lesbarkeit)
+================================================================================
+1. Prerequisite-/Concept-Dependency-Graph: Konzepte = Knoten, "X braucht Y" = Kante.
+   Topologische Sortierung → gültige Reihenfolge (Basics zuerst). LLM extrahiert Kanten,
+   Zyklus-Check. Knoten mit vielen ausgehenden Kanten = Kernkonzepte, früh.
+2. Knowledge-Space-Theorie (Doignon/Falmagne, ALEKS): erlaubte Wissenszustände statt fixer
+   Linie. Validiert Reihenfolge, schließt unmögliche Pfade aus.
+3. Bloom-Progression: Remember → Understand → Apply → Analyze → Evaluate → Create.
+   Jeden Abschnitt taggen, monotone Progression prüfen.
+4. Cognitive Load GLOBAL budgetieren (nicht nur pro Abschnitt): Working Memory ~4–7
+   Einheiten. Neue Konzepte/Abschnitt begrenzen, Spitzen glätten, schwer/leicht abwechseln.
+5. Chunking + einfach→komplex: Teilfertigkeiten zuerst, dann zusammensetzen. Lange
+   Abschnitte automatisch splitten (Max-Chunk-Regel).
+6. Scaffolding mit Fading: anfangs viele Worked Examples, Stütze schrittweise zurücknehmen.
+   Achtung Expertise-Reversal: was Novizen hilft, bremst Fortgeschrittene.
+7. Diátaxis-Struktur: Tutorial / How-to / Reference / Explanation NICHT mischen
+   (häufigste Ursache verwirrender Doku). Für Lern-Guide: Tutorial + Explanation trennen.
+8. Spiral-Curriculum + Spaced Retrieval: Kernideen wiederkehren lassen, aktives Abrufen.
++ Lesbarkeit (frühere Recherche): Ø-Satz ≤ 20 W, keiner > 40; ≤ ~4 neue Begriffe/Abschnitt;
+  eine Idee pro Absatz; Listen statt Aufzählungssätze.
+
+Quellen C:
+- Concept Graph (CMU): https://www.cs.cmu.edu/~hanxiaol/publications/yang-wsdm15.pdf
+- Prerequisite Relations (AAAI): https://ojs.aaai.org/index.php/AAAI/article/view/10550
+- Knowledge Spaces / ALEKS: https://www.aleks.com/about_aleks/Science_Behind_ALEKS.pdf
+- Cognitive Load Strategien: https://www.structural-learning.com/post/cognitive-load-theory-a-teachers-guide
+- Expertise Reversal: https://en.wikipedia.org/wiki/Expertise_reversal_effect
+- Diátaxis: https://diataxis.fr/start-here/
+- Spiral Curriculum: https://www.structural-learning.com/post/the-spiral-curriculum-a-teachers-guide
+
+
+================================================================================
+D) ARCHITEKTUR-METHODEN (Pipeline-Qualität)
+================================================================================
+1. Generator–Critic-Loop NUR mit externer Erdung (Self-Refine ~+20 % bei offenen Aufgaben;
+   intrinsisch ohne Signal verschlechtert). Für Faktenprüfung Tool-Erdung (CRITIC).
+2. Stopp-Kriterien: fast alle Gewinne in Runde 1–2. Stoppen bei Stabilität/Score-Delta<1/
+   Draft-Ähnlichkeit>0,90. Bestes Draft per Validierung wählen, nicht das letzte.
+3. Rollen-Spezialisierung statt Klone: Faktenprüfer ≠ Didaktiker ≠ Lektor ≠ Zielgruppen-
+   Anwalt. Erlaubt kleinere/billigere Modelle pro Teilschritt.
+4. Heterogenität ist der Wirkstoff von Debatte: Gewinn kommt aus VERSCHIEDENEN Modellen,
+   nicht aus dem Mechanismus. Identische Modelle ≈ Self-Consistency, nur teurer.
+5. LLM-as-Judge mit Rubrik, BINÄR (pass/fail) statt 1–5; Multi-Kriterien getrennt; vage
+   Begriffe definieren; niedrige Temperatur; gegen 1 Experten kalibrieren.
+6. Eval-Harness + Regression-Evals (CI-Gate): Golden-Set (25–50 Fälle reichen anfangs),
+   wächst mit jedem Produktionsfehler. PR/Release blockt unter Schwelle.
+7. Diminishing Returns: Voting Sweet Spot 10–20 Samples; Debatte-Plateau ~3 Runden;
+   bei sequentiellen Aufgaben degradiert jede Multi-Agent-Variante um 39–70 %.
+8. Fehler-Akkumulation: 95 %/Schritt × 10 = 59 %; 90 % → 35 %. Verifier-Gate ZWISCHEN
+   die Stufen; zentrale Koordination begrenzt Verstärkung (4,4x statt 17,2x).
+9. Pitfall Sycophancy/Konsens-Bias: Modelle stimmen zu (~42–58 %); Peer-Druck-Flip ~48 %.
+   Fix STRUKTURELL: Mehrheit klein halten (6→3 Agenten senkt Konformität 70 %→33 %),
+   isolierte Selbstkorrektur vor Konsens. Prompt-Nudges ("sei standhaft") wirken NICHT.
+10. Pitfall Self-Preference: Judge bevorzugt eigene Outputs (GPT-4 ~+10 %, Claude ~+25 %).
+    Fix: Judge ≠ Generator-Modell (Cross-Model-Judging), Positionen tauschen+mitteln.
+11. Human-in-the-Loop kalibrierend, NICHT als blindes Reward (OpenAI GPT-4o-Sycophancy-
+    Vorfall April 2025 durch Thumbs-up/down). Experten-Review-Gate behalten.
+12. MAST-Failure-Taxonomie als Architektur-Checkliste (System-Design / Inter-Agent /
+    Verification-Termination).
+
+Quellen D:
+- Self-Refine: https://arxiv.org/pdf/2303.17651
+- CRITIC: https://arxiv.org/abs/2305.11738
+- Multiagent Debate: https://arxiv.org/abs/2305.14325 ; Stop Overvaluing: https://arxiv.org/pdf/2502.08788
+- LLM-as-Judge (MT-Bench): https://arxiv.org/abs/2306.05685 ; G-Eval: https://aclanthology.org/2023.emnlp-main.153/
+- Eval-Prozess (Hamel): https://hamel.dev/blog/posts/llm-judge/
+- Google Scaling Agent Systems: https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
+- Sycophancy: https://arxiv.org/abs/2310.13548 ; Conformity: https://arxiv.org/abs/2505.21588
+- MAST: https://arxiv.org/abs/2503.13657
+- OpenAI Sycophancy-Postmortem: https://venturebeat.com/ai/openai-rolls-back-chatgpts-sycophancy-and-explains-what-went-wrong
+
+
+================================================================================
+EMPFOHLENE NÄCHSTE STUFEN FÜR UNSERE KETTE (priorisiert, größter Nutzen/Aufwand)
+================================================================================
+0. (Stufe ganz vorn) Lernziele definieren (Backward Design) + "das Wichtige" via
+   Mehrquellen-Konsens → ankert Auswahl UND Vollständigkeit.
+1. Reihenfolge: Prerequisite-Graph + topologische Sortierung in/nach der Gliederung
+   (Basics zuerst, keine Vorgriffe).
+2. Faktencheck-Gate (SAFE/CoVe) in der Inhalts-Prüfung — nutzt vorhandene Websuche;
+   Verifier = anderes/stärkeres Modell, BINÄRE Urteile.
+3. Abstention: unbelegte Fakten raus/markieren.
+4. Coverage-/"Was-fehlt"-Critic + Lernziel↔Inhalt-Mapping als Schluss-Gate (zurück bei Lücken).
+5. Cognitive-Load-Pass über den ganzen Guide (neue Begriffe/Abschnitt begrenzen, schwer/leicht mischen).
+6. Architektur-Hygiene: Gate zwischen jeder Stufe (Judge ≠ Generator), Loops nach 1–2 Runden
+   stoppen, Voting 10–20 Samples, kleine Mehrheiten (Konsens-Bias), Golden-Set-Regression-Evals.
+
+WARNUNG: NICHT auf "mehr gleiche Agenten" setzen. Heterogenität + externe Erdung + Gates.
diff --git a/templates/Format/Section.md b/templates/Format/Section.md
index d746e7b..0988003 100644
--- a/templates/Format/Section.md
+++ b/templates/Format/Section.md
@@ -7,11 +7,17 @@ Aufbau je Baustein — drei Beats, fließend ineinander, OHNE Zwischenüberschri
 2. Erklärung — was es ist UND wie/warum es funktioniert. Alltagssprache, von der Intuition zum Detail. Fachbegriffe beim ersten Auftreten in einem Halbsatz auflösen. Eine Analogie oder ein Bild ist erlaubt und oft besser als eine Definition.
 3. Beispiel(e) — das Konzept konkret gemacht (siehe BEISPIELFORMAT).
 
-LÄNGE — so lang wie nötig, so kurz wie möglich:
-- KEIN festes Wort- oder Satzlimit. Die Länge richtet sich nach der Schwierigkeit des Konzepts: ein einfacher Baustein braucht 2–3 Sätze, ein kniffliger einen kurzen Absatz.
-- Verständnis-Test (er entscheidet über die Länge): Versteht ein Anfänger das Konzept allein aus dieser Section? Wenn nein → eine Stufe einfacher erklären, NICHT mehr Fakten stapeln. Wenn ja und kein Satz lässt sich streichen, ohne dass Verständnis verloren geht → genau richtig.
-- Kürze entsteht durch WEGLASSEN von Überflüssigem, nicht durch Verdichten von Nötigem.
-- Weglassen: Füllsätze, Einleitungsfloskeln („In diesem Abschnitt…"), Wiederholungen, Fazit/Zusammenfassung. Nicht jeden Randfall nennen — das Übliche erklären; Varianten gehören in die Beispiele, mehr Tiefe in die Vertiefung.
+LESBARKEIT — wichtiger als Kürze:
+- Kurze Sätze: eine Aussage pro Satz. Richtwert höchstens ~20 Wörter, nie über 25. Keine Schachtelsätze mit mehreren Einschüben (Gedankenstrich-Einschübe vermeiden).
+- Kurze Absätze: eine Idee pro Absatz. Lieber zwei kurze Absätze als ein dichter Block. Keine Textwand.
+- Aufzählungen (Schritte, Optionen, Anforderungen, mehrere gleichrangige Punkte) als Markdown-Liste mit `-`, NIE in einen langen Aufzählungssatz pressen.
+- Wenige neue Fachbegriffe pro Section. Jeden beim ersten Auftreten in Alltagssprache auflösen. Lieber eine Stufe einfacher erklären als mehr Fakten stapeln.
+- Im Zweifel ein Satz mehr und klar — statt verdichtet. Verständlichkeit schlägt Knappheit.
+
+LÄNGE — so lang wie nötig:
+- KEIN festes Wortlimit. Die Länge richtet sich nach der Schwierigkeit des Konzepts.
+- Verständnis-Test: Versteht ein Anfänger das Konzept allein aus dieser Section? Wenn nein → einfacher erklären, NICHT verdichten.
+- Weglassen: Füllsätze, Einleitungsfloskeln („In diesem Abschnitt…"), Wiederholungen, Fazit. Nicht jeden Randfall nennen — das Übliche erklären; Varianten in die Beispiele, mehr Tiefe in die Vertiefung.
 
 BEISPIELFORMAT — am Thema ausrichten, nicht pauschal an Code:
 - Code-/Tool-Thema (Sprache, Framework, CLI, Konfiguration): Codeblock mit Sprachangabe, wenige Zeilen, Minimalbeispiel.
@@ -25,7 +31,7 @@ Jede Section ist ATOMAR: allein verständlich, ohne dass der Leser eine andere S
 
 Tonalität: klares, direktes Deutsch. Du erklärst, du referierst nicht. Praxisorientiert, ohne Füllsätze.
 
-Markdown im Section-Body: erklärende Absätze in normalem Text, `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe NUR für Code-Beispiele — Beispielsätze, Dialoge und Szenarien als normaler Text, NIE in einen Codeblock zwingen. **fett** sparsam für Kernaussagen und Beispiel-Labels. Keine eigenen Überschriften außer `### Beispiel` bzw. `### Beispiele` vor den Beispielen.
+Markdown im Section-Body: erklärende Absätze in normalem Text, Aufzählungen als Markdown-Liste (`-`), `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe NUR für Code-Beispiele — Beispielsätze, Dialoge und Szenarien als normaler Text, NIE in einen Codeblock zwingen. **fett** sparsam für Kernaussagen und Beispiel-Labels. Keine eigenen Überschriften außer `### Beispiel` bzw. `### Beispiele` vor den Beispielen.
 
 Mathematik IMMER als LaTeX schreiben: inline zwischen `$…$` (z. B. `$\Sigma^*$`, `$L \subseteq U$`, `$k = 3$`), abgesetzte Formeln zwischen `$$…$$`. KEINE Unicode-Sonderzeichen als Mathe-Ersatz (nicht `x₁`, `¬`, `∨`, `≤` — stattdessen `$x_1$`, `$\neg$`, `$\lor$`, `$\le$`) und keine nackten Formeln ohne `$`. Außerhalb von Mathe normaler Text.
 
@@ -49,3 +55,20 @@ Im Streit reden zwei oft aneinander vorbei, weil keiner sicher ist, ob er den an
 A: „Nie hältst du dich an Absprachen!"
 B: „Du bist sauer, weil ich den Termin gestern verschoben habe — richtig?"
 B übernimmt nicht das Wort „nie", sondern benennt das konkrete Anliegen. Das öffnet das Gespräch, statt es zu eskalieren.
+
+Beispiel einer fertigen Section mit Aufzählung (Liste statt Aufzählungssatz):
+
+Bevor du Shopware installierst, muss dein Server die Software tragen können. Sonst bricht die Installation ab. Shopware 6 braucht ein paar feste Bausteine:
+
+- **PHP 8.2, 8.3 oder 8.4** — die Sprache, in der Shopware läuft.
+- **MySQL ab 8.0.17** oder **MariaDB ab 10.11** — die Datenbank für deine Artikel und Bestellungen.
+- **Composer ab 2.2** — lädt die PHP-Bibliotheken, die Shopware mitbringt.
+- **Node.js 20+** — baut die JavaScript- und CSS-Dateien zusammen.
+
+### Beispiel
+```bash
+php -v          # PHP-Version prüfen
+composer -V     # Composer-Version
+node -v         # Node-Version
+```
+Stimmt eine Version nicht, aktualisierst du sie zuerst. Eine zu alte Version ist die häufigste Ursache für eine fehlgeschlagene Installation.
diff --git a/templates/Prompt/Guide-Inhalt-Check.md b/templates/Prompt/Guide-Inhalt-Check.md
new file mode 100644
index 0000000..60a66aa
--- /dev/null
+++ b/templates/Prompt/Guide-Inhalt-Check.md
@@ -0,0 +1,19 @@
+Prüfe die gesammelten Inhalte für Bausteine eines Lern-Guides zum Thema "{topic}" (Format: {format_name}). Zielgruppe: Anfänger. Es ist noch kein Guide-Text — nur die Inhalts-Stichpunkte, die später gelehrt werden.
+
+INHALTE:
+{sections}
+
+Prüfe jeden Baustein:
+1. Korrektheit: Sind die Punkte und Fakten sachlich richtig und belegbar? Nichts Halluziniertes, keine erfundenen Werte/Versionen.
+2. Vollständigkeit: Fehlt etwas Wesentliches, das ein Anfänger zum Verständnis des Bausteins braucht?
+3. Scope: Nicht mehr, als der Baustein hergibt — nichts am Rand Erwähntes aufgeblasen; aber auch keine zentrale Lücke.
+
+Du PRÜFST nur und notierst Probleme — du änderst nichts. Nur echte Mängel notieren, keine Geschmacksfragen.
+
+Schreibe NUR die JSON-Datei nach: {out_path}
+
+Format — alles in Ordnung:
+{{"ok": true}}
+Sonst (Baustein-Titel EXAKT wie oben):
+{{"probleme": [{{"section": "Exakter Baustein-Titel", "problem": "…"}}]}}
+{extra}
diff --git a/templates/Prompt/Guide-Inhalt-Fix.md b/templates/Prompt/Guide-Inhalt-Fix.md
new file mode 100644
index 0000000..3bd6324
--- /dev/null
+++ b/templates/Prompt/Guide-Inhalt-Fix.md
@@ -0,0 +1,16 @@
+Überarbeite einzelne Baustein-Inhalte eines Lern-Guides zum Thema "{topic}". Pro Baustein ist ein PROBLEM notiert (Korrektheit, Vollständigkeit oder Scope). Behebe NUR das notierte Problem; was in Ordnung ist, bleibt erhalten.
+
+{facts}
+
+AUFTRÄGE — je Baustein das Problem und der aktuelle Inhalt:
+{auftraege}
+
+Schreibe NUR die Datei {out_path} — pro überarbeitetem Baustein ein section-Marker (Titel EXAKT wie im Auftrag), darunter die korrigierten Punkte:
+
+<!-- section: Exakter Baustein-Titel -->
+- Kernpunkt …
+- Kernpunkt …
+Beispiel: kurze Idee, was das Beispiel zeigt
+
+Die Marker-Zeile exakt so schreiben. Kein Text außerhalb der Sections.
+{extra}
diff --git a/templates/Prompt/Guide-Inhalt.md b/templates/Prompt/Guide-Inhalt.md
new file mode 100644
index 0000000..7acd5aa
--- /dev/null
+++ b/templates/Prompt/Guide-Inhalt.md
@@ -0,0 +1,22 @@
+Identifiziere für jeden zugeteilten Baustein eines Lern-Guides zum Thema "{topic}", WAS ein Anfänger ohne Vorwissen verstehen muss. Du schreibst noch keinen Guide-Text — du sammelst nur die Inhalte, die später gelehrt werden.
+
+Dir zugeteilt sind folgende Kapitel und Bausteine — verbindlich: jeder zugeteilte Baustein muss vorkommen, keine zusätzlichen erfinden:
+{zuteilung}
+
+{facts}
+
+Sammle pro Baustein:
+- Kernpunkte / Lernziele: was muss der Leser begreifen? 3–7 knappe Punkte, jeder eine Aussage.
+- Belegte Fakten (Versionen, Namen, Werte) — nichts Unbelegtes; Unsicheres per Websuche prüfen.
+- Eine konkrete Beispiel-Idee: was soll das Beispiel zeigen?
+- Scope: nur was DIESER Baustein hergibt. Nicht mehr, nicht weniger. Am Rand Erwähntes nicht zum Thema aufblasen.
+
+Schreibe NUR die Datei {out_path} — pro Baustein ein section-Marker (Titel EXAKT aus der Zuteilung), darunter die Punkte:
+
+<!-- section: Exakter Baustein-Titel -->
+- Kernpunkt …
+- Kernpunkt …
+Beispiel: kurze Idee, was das Beispiel zeigt
+
+Die Marker-Zeile exakt so schreiben. Kein Text außerhalb der Sections, kein Fließtext-Guide.
+{extra}
diff --git a/templates/Prompt/Guide-Lese-Check.md b/templates/Prompt/Guide-Lese-Check.md
index 4369f08..4b70e66 100644
--- a/templates/Prompt/Guide-Lese-Check.md
+++ b/templates/Prompt/Guide-Lese-Check.md
@@ -8,9 +8,14 @@ SECTIONS:
 {sections}
 
 Prüfe jede Section:
-1. Lehrt die Section das Konzept für einen Anfänger ohne Vorwissen verständlich — ordnet sie es ein, erklärt sie das Wie/Warum, macht ein Beispiel es konkret? Sie soll so lang wie nötig und so kurz wie möglich sein: kein Roman, keine Füllsätze, keine Einleitungsfloskeln — aber auch nicht so verdichtet, dass nur jemand sie versteht, der das Thema schon kennt.
-2. Sind die Beispiele kurz, simpel, plausibel korrekt — und im themengerechten Format laut Spezifikation (kein Codeblock um Prosa-Beispiele, kein Prosa-Pseudo-Beispiel, wo Code gefragt ist)?
-3. Ist das Markdown sauber (keine abgebrochenen Code-Blöcke, keine Platzhalter, kein Fremdtext)?
+1. Lehrt die Section das Konzept für einen Anfänger ohne Vorwissen verständlich — ordnet sie es ein, erklärt sie das Wie/Warum, macht ein Beispiel es konkret? Nicht so verdichtet, dass nur jemand sie versteht, der das Thema schon kennt.
+2. Lesbarkeit (echte Mängel notieren):
+   - Sätze über ~25 Wörter oder Schachtelsätze mit mehreren Einschüben.
+   - Eine Aufzählung (Schritte/Optionen/Anforderungen) als langer Fließtext-Satz, die eine Markdown-Liste sein sollte.
+   - Textwand: ein dichter Block ohne Absätze, der sich in mehrere teilen ließe.
+   - Mehr als ~4 neue Fachbegriffe ohne Erklärung beim ersten Auftreten.
+3. Sind die Beispiele kurz, simpel, plausibel korrekt — und im themengerechten Format laut Spezifikation (kein Codeblock um Prosa-Beispiele, kein Prosa-Pseudo-Beispiel, wo Code gefragt ist)?
+4. Ist das Markdown sauber (keine abgebrochenen Code-Blöcke, keine Platzhalter, kein Fremdtext)?
 
 Du PRÜFST nur und notierst Probleme — du änderst nichts. Nur echte Mängel notieren, keine Geschmacksfragen.
 
diff --git a/templates/Prompt/Guide-Writer.md b/templates/Prompt/Guide-Writer.md
index 2c6d02e..8d756bf 100644
--- a/templates/Prompt/Guide-Writer.md
+++ b/templates/Prompt/Guide-Writer.md
@@ -5,7 +5,12 @@ Dir zugeteilt sind folgende Kapitel und Bausteine — verbindlich: jede zugeteil
 
 {facts}
 
-Beispiel-Tiefe für dieses Format ({format_name}): MiniGuide = nur die üblichen Varianten eines Bausteins, Guide = die gängigen Varianten, FullGuide = alle relevanten Varianten inkl. Nischenfällen. Eine Variante ist eine eigenständige Verwendungsform des Bausteins — Code-Variante, Satzmuster oder Anwendungsfall.
+Das Format ({format_name}) beeinflusst NICHT, wie ein einzelner Baustein geschrieben wird — nur, wie viele Bausteine das Thema abdeckt. Derselbe Baustein bekommt in MiniGuide, Guide und FullGuide denselben Text. Wie lang und tief ein Baustein ist, richtet sich allein nach SEINER Schwierigkeit (laut Spezifikation): ein einfacher Baustein bleibt kurz, ein kniffliger darf länger sein. Bausteine untereinander sind also verschieden lang — derselbe Baustein über die Formate hinweg aber gleich.
+
+GEPRÜFTE INHALTE je Baustein — das ist verbindlich, was gelehrt werden muss:
+{inhalte}
+
+Nutze diese Inhalte. Erfinde nichts dazu, lass nichts Wesentliches weg. Formuliere sie als lesbaren Lern-Text laut SECTION-SPEZIFIKATION. Keine feste Länge — die Länge folgt den Inhalten. Lehre simpel: kurze Sätze, Listen für Aufzählungen, ein Anfänger versteht es sofort.
 
 SECTION-SPEZIFIKATION:
 {spec}