update

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.

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}

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}

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}

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.
 

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}