diff --git a/backend/config.py b/backend/config.py
index be1731c..0a66931 100644
--- a/backend/config.py
+++ b/backend/config.py
@@ -46,8 +46,8 @@ PROVIDERS = {
     "minimax": {
         "cli": "opencode",
         "guide": "minimax/MiniMax-M3",
-        "fast": "minimax/MiniMax-M3",
-        "quick": "minimax/MiniMax-M3",
+        "fast": "minimax/MiniMax-M2.7-highspeed",
+        "quick": "minimax/MiniMax-M2.7-highspeed",
         "env_key": "MINIMAX_API_KEY",
     },
     "lokal": {
diff --git a/templates/Format/Section.md b/templates/Format/Section.md
index 9a28d26..7228a75 100644
--- a/templates/Format/Section.md
+++ b/templates/Format/Section.md
@@ -3,13 +3,13 @@ SECTION-AUFBAU
 Jeder Baustein wird GENAU eine Section mit:
 1. Titel — der Baustein-Titel (kommt aus dem Marker, nicht in den Body schreiben)
 2. Beschreibung — was es ist, wozu es dient, worauf man achten muss
-3. Beispiel — kurzes, realistisches Code-/Anwendungsbeispiel mit 1 Satz Einordnung. Weglassen, wenn ein Beispiel für diesen Baustein keinen Mehrwert hat.
+3. Beispiele — kurze, realistische Code-/Anwendungsbeispiele mit je 1 Satz Einordnung. Ein Beispiel pro relevanter Variante des Bausteins: simple Bausteine haben eines, variantenreiche mehrere. Geordnet vom Üblichen zum Speziellen — Nischenfälle zuletzt. Weglassen, wenn ohne Mehrwert.
 
 Umfang: so kurz wie möglich, so lang wie nötig — das entscheidet der Baustein, nicht eine Vorgabe. Ein simples Konzept = 2–3 Sätze, ein komplexes darf länger sein.
 
 Tonalität: klares Deutsch, direkt, praxisorientiert. Fachbegriffe beim ersten Auftreten kurz erklären. Keine Füllsätze, keine Einleitungsfloskeln.
 
-Markdown im Section-Body: normale Absätze, `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe, **fett** sparsam für Kernaussagen. Keine eigenen Überschriften außer `### Beispiel` direkt vor dem Beispiel.
+Markdown im Section-Body: normale Absätze, `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe, **fett** sparsam für Kernaussagen. Keine eigenen Überschriften außer `### Beispiel` bzw. `### Beispiele` vor den Beispielen.
 
 Beispiel einer fertigen Section (nur der Body):
 
diff --git a/templates/Prompt/Bausteine-Auswahl.md b/templates/Prompt/Bausteine-Auswahl.md
index 2280d54..417c38d 100644
--- a/templates/Prompt/Bausteine-Auswahl.md
+++ b/templates/Prompt/Bausteine-Auswahl.md
@@ -4,7 +4,7 @@ Drei Recherche-Agenten haben unabhängig voneinander die Bausteine des Themas "{
 
 Regeln:
 - Vereinige die Listen: erkenne gleiche Konzepte unter verschiedenen Titeln und führe sie zu einem Baustein zusammen.
-- KONSOLIDIERE Referenz-Aufzählungen zu Konzepten: einzelne Attribute, Parameter, Varianten oder Untertypen werden zu EINEM Baustein ihres Eltern-Konzepts zusammengefasst (falsch: je ein Eintrag für `height`, `width`, `src`; richtig: ein Baustein "Bild-Attribute").
+- Ein Baustein löst GENAU EIN PROBLEM. Einträge, die Varianten derselben Lösung sind, werden zu EINEM Baustein zusammengefasst (richtig: ein Baustein `<input>` für alle Typen; falsch: je ein Eintrag pro input-Typ, aber auch Sammeleinträge, die mehrere Probleme mischen).
 - Verwirf Bausteine ohne Quelle oder die erfunden wirken. Behalte im Zweifel, was mindestens eine Recherche belegt.
 - KEINE Kategorien, KEINE Bewertung — eine flache, durchnummerierte Liste.
 - Lass die Quellen weg. Titel und Kurzbeschreibung (max. ~12 Wörter) auf DEUTSCH (Code-Bezeichner bleiben original). Jeder Titel muss EINDEUTIG sein.
diff --git a/templates/Prompt/Bausteine-Recherche.md b/templates/Prompt/Bausteine-Recherche.md
index 7863d68..095375f 100644
--- a/templates/Prompt/Bausteine-Recherche.md
+++ b/templates/Prompt/Bausteine-Recherche.md
@@ -3,7 +3,7 @@ Ermittle ALLE Bausteine (Konzepte/Funktionen/Features) des Themas "{topic}" für
 {source}
 
 Regeln:
-- Ein Baustein = ein LEHRBARES KONZEPT, keine Referenz-Aufzählung. Attribute, Parameter, Varianten und Untertypen gehören in den Baustein ihres Eltern-Konzepts — niemals als eigene Einträge (falsch: 21 Einträge für jeden input-Typ; richtig: ein Baustein "Eingabefelder und ihre Typen").
+- Ein Baustein löst GENAU EIN PROBLEM. Varianten derselben Lösung gehören in den einen Baustein, nicht als eigene Einträge (richtig: `<p>` ist ein Baustein, `<input>` mit allen Typen ist ein Baustein; falsch: 21 Einträge für jeden input-Typ, aber auch Sammeleinträge, die mehrere Probleme mischen).
 - KEINE Kategorien, KEINE Bewertung, KEINE Reihenfolge nach Wichtigkeit — nur eine flache, durchnummerierte Liste.
 - Es gibt KEINE Ziel-Anzahl. Höre erst auf, wenn die Recherche nichts Neues mehr hergibt.
 - Erfinde nichts: nimm nur Bausteine auf, die du in der Recherche belegt hast. Notiere pro Baustein die Quelle (URL bzw. Dateipfad).
diff --git a/templates/Prompt/Guide-Writer.md b/templates/Prompt/Guide-Writer.md
index 18b2f82..00a1d47 100644
--- a/templates/Prompt/Guide-Writer.md
+++ b/templates/Prompt/Guide-Writer.md
@@ -5,6 +5,8 @@ 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.
+
 SECTION-SPEZIFIKATION:
 {spec}