update

templates/Prompt/Bausteine-Block-Gruppieren.md

@@ -0,0 +1,20 @@
+Unten stehen nummerierte Baustein-Kandidaten für das Thema "{topic}". Sie stammen aus einem Ähnlichkeits-Block. Manche bezeichnen DENSELBEN Baustein oder eine Eigenschaft davon, andere sind verschieden. Gruppiere sie.
+
+KANDIDATEN:
+{eintraege}
+
+Regeln:
+- Bilde Gruppen: Nummern, die ZUM SELBEN Baustein gehören, kommen in EINE Gruppe.
+- **Achte auf die Kern-Entität** (das Problem/Objekt): Clique, Vertex Cover, Set Cover, Knapsack, Dominating Set, LPT/List Scheduling … Verschiedene Entität → verschiedene Gruppen, auch bei ähnlichem Satzbau ("Lower Bound Clique" ≠ "Lower Bound Vertex Cover").
+- Echte Paraphrasen ZUSAMMEN, auch bei anderen Worten ("List Scheduling" = "LPT-Algorithmus"; "Set Cover" = "Mengenüberdeckung").
+- **Eigenschaften eines Problems gehören ZUM Problem-Baustein — nicht eigenständig.** Bündle mit dem Problem: seinen Komplexitäts-Status (∈ NP, NP-schwer, NP-vollständig), seinen Verifizierer / Zertifikat / NDTM, "… als Sprache / Definition", seine einzelnen Lower-Bound-Parameter (k / r / |U|).
+  - Beispiel: "Knapsack", "Knapsack ∈ NP", "Knapsack NP-schwer", "Knapsack NP-vollständig", "Verifizierer für Knapsack" → EINE Gruppe (Baustein "Knapsack").
+  - Beispiel: "Hitting Set Lower Bound (k)", "(r)", "(|U|)" → EINE Gruppe.
+- GETRENNT bleiben (eigene Bausteine): verschiedene Probleme (Clique-Member ≠ Clique-Nomember); eine REDUKTION zwischen zwei Problemen ist eine eigene Technik (z.B. "3-SAT ⪯ k-Clique" bleibt eigenständig); verschiedene Verfahren/Sätze mit eigener Aussage.
+- Im Zweifel zwischen zwei verschiedenen Problemen → TRENNEN. Bei Problem + seiner Eigenschaft → BÜNDELN.
+- JEDE Nummer kommt in GENAU EINE Gruppe. Einzelne Bausteine sind eine Gruppe mit einem Element.
+
+Schreibe NUR die JSON-Datei nach: {out_path}
+
+Format (Listen von Kandidaten-Nummern; jede Nummer genau einmal):
+{{"gruppen": [[1, 3], [2], [4, 5]]}}

templates/Prompt/Bausteine-Klaerung.md

@@ -1,15 +1,23 @@
-Zum Thema "{topic}" sind unten Bausteine, die in der Recherche nur EINMAL genannt wurden. Die Quelle wurde vollständig durchsucht. Entscheide jeden Eintrag einzeln.
-
-BEREITS BESTÄTIGTES INVENTAR (nur Kontext — nicht ändern, nicht duplizieren):
-{konsens}
+Zum Thema "{topic}" sind unten Bausteine, die in der Recherche nur EINMAL genannt wurden. Die Quelle wurde vollständig durchsucht. Entscheide für JEDEN Eintrag: ist er ein echter, eigenständiger Baustein → `aufnehmen`, oder nicht → verwerfen (in keine Liste).
 
 EINZELN GENANNTE EINTRÄGE (jeweils entscheiden):
 {rest}
 
+Was ein Baustein IST: eine eigenständige LERNEINHEIT — ein Konzept, ein Verfahren, ein Problem, eine Definition, ein benannter Satz MIT inhaltlicher Aussage.
+
+Was KEIN Baustein ist (→ verwerfen):
+- Bloße Verweise/Nummern ohne Inhalt: "Satz 7.18", "Bemerkung 7.22", "Lemma 6.2", "D*".
+- Beweis-Fragmente/Zwischenschritte: "Beweis (b) Güte", "Beweis ⊂ Richtung", "Eigenschaft (a)".
+- Zu Vages oder erkennbar Erfundenes.
+
+Beispiele:
+- "Clique-Member — k-Clique, die einen festen Knoten v enthält" → **aufnehmen** (eigenständiges Problem).
+- "Satz 7.18" → **verwerfen** (bloßer Verweis, keine Aussage).
+- "Beweis (b) Güte" → **verwerfen** (Fragment).
+- "Satz 7.8: ΔTSP1 hat Güte 2" → **aufnehmen** (benannter Satz MIT Aussage).
+
 Regeln:
-- Fachlich valider, eigenständiger Baustein und KEINE Dublette/Variante des Inventars → `aufnehmen`.
-- Erfunden, zu vage, oder Dublette/Variante eines Inventar-Bausteins → verwerfen (in keine Liste).
-- Doppelt ein Eintrag inhaltlich einen ANDEREN einzeln genannten Eintrag (gleiche Sache, andere Worte) → nur EINEN aufnehmen, den anderen verwerfen.
+- Im Zweifel an der Eigenständigkeit → eher aufnehmen. Dubletten werden später separat entfernt; hier zählt nur: echter Baustein oder Müll.
 - Übernimm aufgenommene Einträge WÖRTLICH ("Titel — Kurzbeschreibung"), nicht umformulieren.{final}
 
 Schreibe NUR die JSON-Datei nach: {out_path}

templates/Prompt/Bausteine-Paar-Filter.md

@@ -0,0 +1,20 @@
+Zwei Recherchen haben Bausteine für das Thema "{topic}" notiert. Entscheide für JEDES Paar, ob A und B DENSELBEN Baustein bezeichnen (dasselbe Konzept, nur anders formuliert) → **ja**, oder ob es ZWEI UNTERSCHIEDLICHE Bausteine sind → **nein**.
+
+PAARE:
+{paare}
+
+Regeln:
+- **Achte zuerst auf die KERN-ENTITÄT** (das Problem/Objekt, um das es geht): Clique, Vertex Cover, Independent Set, Dominating Set, Set Cover, FVS, Knapsack … Sind die Entitäten VERSCHIEDEN → **nein**, egal wie gleich der Satzbau ist.
+- Gleicher Satzbau täuscht. Diese Paare sind **nein** (verschiedene Entität trotz fast identischer Formulierung):
+  - "Lower Bound **Clique** bzgl. Knoten" ↔ "Lower Bound **Vertex Cover** bzgl. Knoten"
+  - "Lower Bound Clique bzgl. **Knoten**" ↔ "Lower Bound Clique bzgl. **Kanten**"
+  - "Verifizierer für **FVS**" ↔ "Verifizierer für **Knapsack**"
+  - "**Cliquenproblem**" ↔ "**Vertex-Cover-Problem**"
+- **ja** nur bei echter Bedeutungsgleichheit: gleiche Lösung desselben Problems, dieselbe Entität, nur andere Formulierung/Benennung (z. B. "SET COVER" ↔ "Mengenüberdeckungsproblem", "Cliquenproblem" ↔ "k-CLIQUE", "List Scheduling" ↔ "LPT-Algorithmus").
+- **nein** auch bei verschiedenen Aspekten desselben Problems: "Set Cover (Problem)" ↔ "Set Cover ETH-Schranke"; ein Problem ↔ seine Reduktion auf ein anderes; ein Problem ↔ sein Verifizierer.
+- Im Zweifel **nein** — lieber zwei getrennte Bausteine als zwei Konzepte fälschlich verschmelzen.
+
+Schreibe NUR die JSON-Datei nach: {out_path}
+
+Format (jede Paar-Nummer aus der Liste mit "ja" oder "nein"; kein weiterer Text in der Datei):
+{{"paare": {{"1": "ja", "2": "nein"}}}}