update

templates/Prompt/Blocks-Filter-Recheck.md

@@ -0,0 +1,24 @@
+Topic "{topic}". A first pass kept the blocks below, but each was FLAGGED as a likely **fragment** — a property, proof step, remark, bound, or notation that belongs to another block, not its own learning unit. Re-judge each one carefully. This is a focused second opinion; a good learning list has roughly 75–82 top-level blocks, so real fragments here SHOULD be demoted or dropped — but never sacrifice a genuine concept to hit a number.
+
+RE-JUDGE THESE (by their number):
+{survivors}
+
+FULL BLOCK LIST (context — to find a parent number):
+{list}
+
+## Decide each survivor → one of three
+- **demote (→ parent number):** it presupposes another block as its subject — a property/status („X ist NP-vollständig", „X ∈ NP"), a **lower bound** of X, a **bare theorem/remark** about X („Bemerkung: HK auch für gerichtete Graphen" → Hamiltonkreis; „Satz: F erfüllbar ⇔ … 3-dim Matching" → 3-dim Matching), an **approximation-güte facet** („Schärfe der 3/2 Rate" → Christofides), a **proof-example/gadget** („MST in Gegenbeispiel" → the approximation proof), a proof-variable. Put `{{"<nr>": <parent-nr>}}` in `fragments`.
+- **drop:** pure exercise/reference scaffolding with NO real content and NO parent — a bare label („Remark 7.28", „Satz D*"), a one-off notation assignment („r = n + m"). Put its number in `drop`.
+- **keep:** it IS a self-contained concept. Do NOT touch it. (Just omit it.)
+
+## KEEP-guards — these are real blocks, never demote/drop them
+- A **named theorem WITH its own statement or an author**: „Satz 6.24 Cook/Levin — SAT ist NP-vollständig", „Satz von Immerman–Szelepcsényi". KEEP.
+- A **complexity-class (in)equality / open question**: „P = NP?", „NL = coNL". KEEP.
+- Anything headed „**Definition**", a **problem**, an **algorithm**, a **reduction** („3-SAT ≤ Clique"). KEEP.
+
+Judge by the CONTENT (after „—"), not the label. When unsure whether something is a fragment or a concept: if it has an obvious parent in the list → demote; otherwise → keep (never drop on doubt).
+
+Write ONLY the JSON file to: {out_path}
+
+Format (both keys; each may be empty):
+{{"fragments": {{"3": 17, "9": 41}}, "drop": [12]}}

templates/Prompt/Blocks-Filter.md

@@ -23,17 +23,30 @@ A block is self-contained: you can explain it WITHOUT presupposing another block
 ## What is a FRAGMENT (belongs to another block → demote)?
 Self-containment test: does the entry presuppose ANOTHER concept in the list as its subject? Then it is that concept's property/part, not its own block.
 - **Property/status** of a problem X (that is itself in the list): „X ist NP-vollständig", „X ∈ NP", „NP-Schwere von X", „Approximationsgüte von X". → parent = X.
-- **Proof/reduction gadget**: „αEnde", „A-Komponente", „Dummy Items", „Schedule D*", „Knoten z", auxiliary variables. → parent = the theorem/reduction in whose proof it appears.
-- **Pure notation/symbol**: „|x|", „Σ∗", „Güte 2". → parent = the defining definition.
+- **Lower bound / ETH bound** of a problem X: „Lower Bound bzgl. Knoten für VERTEX COVER", „ETH untere Schranke HITTING SET (|U|)", „2^Ω(√|E|) …". → parent = X (the problem the bound is about).
+- **Bare theorem / proof reference**: „Satz 6.12: P ⊆ NP", „Beweis Satz 6.16 (⇒)", „Beweis ⊃ von Satz 6.21", „Satz 7.20 (Sahni)", „Pm||Cmax NP-vollständig (Satz 7.23)" — a restated inclusion/membership or a bare „Satz N"/„Beweis …" is a proof detail. → parent = the problem/algorithm/class it is about (P/NP, Sahni's algorithm, Pm||Cmax …).
+- **Proof/reduction gadget or variable**: „αEnde", „A-Komponente", „Dummy Items", „αu-Variablen", „Variablenungleichungen im ILP", „Austausch-Argument". → parent = the theorem/reduction in whose proof it appears.
+- **Approximation-guarantee facet**: „Güte 2", „Güte 2 − 1/m", „Approximative Güte 2", „List Scheduling Güte (2 − 1/m)". → parent = the algorithm it bounds (List Scheduling, LPT, …).
 - **Runtime/size detail**: „O(|V|⁴) Verifizierer-Laufzeit", „|V'| = |V| bei Reduktion", „Reduktion in O(|E|)". → parent = the algorithm/reduction.
+- **Parent named in the entry's OWN title:** if the title itself contains another block's name („Lower Bound … für **VERTEX COVER**", „**List Scheduling** Güte …", „**Pm||Cmax** NP-vollständig"), that named block IS the parent — demote to it. Do not keep such an entry just because you would scan the whole list; the parent is right there in the title.
+- **Over-specific variant** of a base problem that is itself in the list: „Even-Knapsack", „Subset Sum Cardinality", „Partition (3·Summe)", „SAT3" are exercise-tweaked variants of „Rucksackproblem"/„Subset Sum"/„Partition"/„SAT". → parent = the base problem. (A genuinely different problem with its own theory stays its own block.)
+
+## What is an EXERCISE ARTEFACT (no concept at all → hard-drop)?
+Rare, and applied cautiously. ONLY clear exercise-sheet / cross-reference scaffolding that is neither a learnable concept nor a fragment of one AND has no parent in the list. These forms all count, no matter where the marker sits:
+- a lettered OR **Roman-numbered** sub-claim, in any parenthesization: „Aussage (a): …", „(Aussage i)", „(Aussage ii)", „NP-schwer ≠ P (Aussage ii)", „Teil (b)", „Fall (2)";
+- a bare sheet/task reference: „Blatt 10", „Aufgabe 3", „Übung 7.31";
+- a worked-example / table / figure reference: „Scheduling Beispiel Tab. 7.1", „Beispiel 3.2", „Abbildung 4.5";
+- a one-off framing with no standalone content.
+Put its number in `drop`. NEVER drop anything that names a real problem/method/definition/theorem/reduction — if there is any doubt, keep it (or demote it as a fragment with a parent). A **named theorem WITH its own statement** („Satz 6.24 Cook/Levin — SAT ist NP-vollständig") is a real block, never an artefact. If it has a parent in the list, prefer demoting (fragment) over dropping.
 
 ## Rules
 - A fragment is demoted ONLY if its **parent block is in the list** (give its number). If you find no parent → keep it (don't list it).
 - The doubt concerns STANDALONE-NESS: if it's unclear whether an entry stands on its own → keep it. But a clear property/notation/proof part WITH a parent in the list IS a fragment — don't keep it out of caution.
 - A standalone **reduction between two problems** is a block, NOT a fragment („3-SAT ≤ Clique").
+- A **named theorem WITH its own relational statement** — a biconditional/implication/reduction between two named objects („Satz 6.37: 3-SAT ≤ 3-Färbung … ⇔ …") — is a block; keep it even if it references other blocks. Only a BARE label with no statement („Satz 7.18", „Remark 7.28"), a unary status („X ist NP-vollständig", „X ∈ NP"), or a güte/bound/proof-size facet is a fragment.
 - Judge by the CONTENT (after the „—"), not the title.
 
 Write ONLY the JSON file to: {out_path}
 
-Format (only the fragment numbers from {from_n}–{to_n}, each with its parent number; `fragments` may be empty):
-{{"fragments": {{"12": 5, "13": 5, "27": 19}}}}
+Format — always include `fragments` (fragment number → parent number, may be empty); `drop` is the list of exercise-artefact numbers with NO parent (usually empty). Only numbers from {from_n}–{to_n}:
+{{"fragments": {{"12": 5, "13": 5, "27": 19}}, "drop": [17]}}

templates/Prompt/Blocks-Gruppierung-Completion.md

@@ -0,0 +1,18 @@
+Topic "{topic}". Umbrella blocks were formed, each bundling the constituent parts of ONE model/definition. Some parts were missed and are still listed as standalone blocks. Your job: for each umbrella, find which of the remaining standalone blocks are ALSO constituent parts of that same parent, so the model is complete.
+
+UMBRELLAS (parent — already-collected parts):
+{umbrellas}
+
+REMAINING STANDALONE BLOCKS (numbered):
+{rest}
+
+## Rule — attach a block to an umbrella only if BOTH hold
+1. **Presupposition:** the block's definition **requires the umbrella's parent to already exist** — it makes no sense as a topic on its own without that model (e.g. „Alphabet Σ", „Übergangsfunktion δ", „Konfiguration", „Akzeptierende Berechnung" all presuppose the Turing-machine; „Literale", „Klausel", „Belegung" presuppose the KNF/logic definition). The parent must NOT presuppose the block (directional).
+2. **Not standalone:** the block is a *definitional component / notation*, NOT itself a named **algorithm, problem, theorem, reduction, or complexity class** (those stay their own block — a downstream guard will reject them anyway).
+
+Do NOT attach a block merely because it shares a topic. When unsure → leave it standalone. Most remaining blocks will NOT be attached; a few genuine missed parts will.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (`additions` may be empty; `umbrella` = the UMBRELLA index, `members` = standalone block numbers to attach):
+{{"additions": [{{"umbrella": 0, "members": [8, 12, 34]}}]}}

templates/Prompt/Blocks-Gruppierung.md

@@ -0,0 +1,34 @@
+Topic "{topic}". A previous step produced a flat list of learning blocks that is TOO FINE-GRAINED — several blocks are **constituent sub-definitions / notation of ONE larger definition or model** and should become a single umbrella block. Find these groups. A good run finds several genuine umbrellas AND leaves most blocks standalone; judge each candidate on its merits.
+
+**Propose generously.** A deterministic guard downstream rejects any umbrella that swallows a named algorithm/problem/theorem, so a wrong-but-plausible merge is cheap — a missed umbrella is not. Do NOT withhold a merge merely because the members are lexically dissimilar (facets of one model routinely are) or because you are unsure of the parent's exact name.
+
+CANDIDATES (your starting point):
+{candidates}
+
+FULL BLOCK LIST (you may pull in ANY numbers below that are constituents of the same definition):
+{list}
+
+## Merge test — propose an umbrella when ALL THREE hold
+1. **One parent.** The members are constituent parts/facets of ONE named parent model or definition — each member PRESUPPOSES that parent (you cannot introduce the member without first invoking the parent). TM-model parts (Konfiguration, Übergangsfunktion δ, Alphabet Σ, Akzeptierende Berechnung) presuppose „Turingmaschine"; KNF parts (Literale, Klauseln, Boolesche Variablen) presuppose „Konjunktive Normalform".
+2. **Studied together.** A learner meets them together as one unit.
+3. **No standalone unit among them.** No member is itself a named **algorithm, problem, theorem, reduction/transformation, or complexity class** („List Scheduling", „3-SAT", „Cook/Levin", „3-SAT ≤ Clique", „NP", „NP-Vollständigkeit", „Polynomielle Transformation"). Each of those is its own concept, so a group containing one is a set of SIBLINGS, not the decomposition of one model — keep them separate.
+
+*Note on test 1: „can this be defined at all?" is the WRONG question — Alphabet Σ and DTM CAN be stated in isolation, yet in THIS topic they are parts of the Turing-machine model and belong together. The question is whether the member PRESUPPOSES the shared parent, not whether a standalone sentence exists.*
+
+## Examples
+DO NOT MERGE — distinct named units that merely share a topic:
+- „Greedy-Algorithmus GA" + „ModifiedGreedy" + „Multiple-Choice-Knapsack" → two algorithms + a problem, each standalone (test 3 fails). Keep separate.
+
+MERGE — one definition decomposed (the canonical cases — end here so this is your default lens):
+- „Alphabet Σ" + „NDTM" + „DTM" + „Akzeptierende Berechnung" + „Folgekonfiguration" → ONE umbrella **„Turingmaschine (Modell)"**. (The members are lexically very different from each other — that is EXPECTED for facets of one model and is NOT a reason to keep them apart.)
+- „Klausel" + „Boolesche Variable" + „Erfüllende Belegung" + „KNF" → ONE umbrella **„Aussagenlogik & KNF"**.
+
+## Synthesize each umbrella
+- `title`: the parent concept's name (e.g. „Turingmaschine (Modell)"). A real self-contained definition; must NOT contain „ — " (a reserved separator) — use „(…)" or „:".
+- `description`: **name EVERY merged child explicitly** — the next step recovers the children as sub-points from the source. E.g. „Formales TM-Modell: Konfiguration, Übergangsfunktion δ, Alphabet Σ, Akzeptierende Berechnung, Folgekonfiguration."
+- `members`: the block NUMBERS (from the full list) folded in. At least 2 per umbrella; each number appears in at most one umbrella.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (`umbrellas` may be empty):
+{{"umbrellas": [{{"title": "Turingmaschine (Modell)", "description": "Formales TM-Modell: Konfiguration, Übergangsfunktion δ, Alphabet Σ, Akzeptierende Berechnung, Folgekonfiguration.", "members": [1, 2, 5, 12, 34]}}]}}

templates/Prompt/Blocks-Klaerung.md

@@ -23,7 +23,7 @@ Examples:
 - "Satz 7.18" (no description) → **verwerfen** (mere reference).
 
 Rules:
-- When in doubt about standalone-ness → lean toward including. Duplicates are removed separately later; here only this counts: real block or junk.
+- Decide by the standalone Define test above: an entry that only makes sense INSIDE a specific proof, reduction, or spot in the script is NOT a block → discard it. Include only entries that stand on their own (a concept you could teach on its own); duplicates are removed separately later. This is single-mention material, so hold a firm bar — but never discard a genuine standalone concept hiding behind a reference title (see the rename rule above).
 - Copy included entries VERBATIM ("Title — Kurzbeschreibung"), do not rephrase.{final}
 
 Write ONLY the JSON file to: {out_path}

templates/Prompt/Blocks-Paar-Filter.md

@@ -1,20 +1,36 @@
-Two research passes have noted blocks for the topic "{topic}". For EACH pair, decide whether A and B denote the SAME block (the same concept, just worded differently) → **ja**, or whether they are TWO DIFFERENT blocks → **nein**.
+Two research passes noted blocks for the topic "{topic}" as "Title — description". For EACH pair, decide: do A and B denote the SAME block → **ja**, or TWO DIFFERENT blocks → **nein**?
 
 PAIRS:
 {pairs}
 
-Rules:
-- **Watch the CORE ENTITY first** (the problem/object in question): Clique, Vertex Cover, Independent Set, Dominating Set, Set Cover, FVS, Knapsack … If the entities are DIFFERENT → **nein**, no matter how identical the phrasing.
-- Identical phrasing is deceptive. These pairs are **nein** (different entity despite nearly identical wording):
-  - "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** only on genuine semantic equivalence: same solution to the same problem, the same entity, just different wording/naming (e.g. "SET COVER" ↔ "Mengenüberdeckungsproblem", "Cliquenproblem" ↔ "k-CLIQUE", "List Scheduling" ↔ "LPT-Algorithmus").
-- **nein** also for different aspects of the same problem: "Set Cover (Problem)" ↔ "Set Cover ETH-Schranke"; a problem ↔ its reduction to another; a problem ↔ its verifier.
-- When in doubt **nein** — better two separate blocks than wrongly merging two concepts.
+## How to decide (per pair)
+**STEP 1 — Name the CANONICAL ENTITY of each side.** Strip catalogue numbers („Definition 6.19", „Satz 7.8"), drop generic tags like „(Problem)"/„-Problem", ignore case, spacing and hyphenation. So „HITTING SET" and „HittingSet (Problem)" share one canonical entity; „Definition 6.19 NP" and „NP" both name the entity **NP**; „Algorithmus ΔTSP1" and „ΔTSP1" both name **ΔTSP1**.
+
+**STEP 2 — Same entity, or different?**
+- **DIFFERENT canonical entity → nein**, however identical the wording:
+  - two different problems/objects: „Clique" ≠ „Vertex Cover"; „Lower Bound Clique bzgl. Knoten" ≠ „… bzgl. Kanten" (a different parameter is a different result);
+  - a distinct **variant** is its own entity: „GA" ≠ „ModifiedGreedy (MGA)"; „SAT" ≠ „3-SAT"; „Knapsack" ≠ „Multiple-Choice-Knapsack";
+  - a **reduction between two problems** is its own entity: „Clique" ≠ „3-SAT ≤ Clique";
+  - two reductions/relations that share ONE side but differ on the OTHER (or run in the opposite direction) are DIFFERENT results → **nein**: „SAT ≤ Clique" ≠ „SAT ≤ 3-Dim-Matching", „VertexCover ≤ FVS" ≠ „VertexCover ≤ Δ-Cover". A restriction/special case („3-SAT ≤ X") is NARROWER than the general („SAT ≤ X"), never the same.
+- **SAME canonical entity → ja**, even when A and B emphasize DIFFERENT FACETS of it. Facets of one and the same object include: its **formal definition**, a **mechanism/step** (how it works), a **property** (approximation ratio, a bound, complexity, ∈ NP), a **characterization**, a **naming variant**. Two entries describing different facets of the SAME entity are duplicates.
+
+**STEP 3 — „When in doubt → nein" applies ONLY when STEP 1 is ambiguous** (you genuinely cannot tell whether the two names denote the same object). It does NOT fire merely because the two descriptions differ — differing descriptions of the SAME entity are **ja**.
+
+## Examples
+DUPLICATE (ja) — same entity, different facet/wording:
+- A: „Algorithmus ΔTSP1 — MST, Kanten verdoppeln, Eulerkreis, Abkürzungen"  B: „ΔTSP1 — TSP-Approximationsalgorithmus mit Rate 2" → both = algorithm **ΔTSP1** (steps vs. its ratio) → **ja**
+- A: „Definition 6.19 NP — L ∈ NP ⇔ ∃ NDTM …"  B: „NP — Klasse aller polynomiell verifizierbaren Sprachen" → both = **NP** (definition vs. characterization) → **ja**
+- A: „HITTING SET"  B: „HittingSet (Problem)" → same entity, only naming → **ja**
+- A: „SET COVER"  B: „Mengenüberdeckungsproblem" → **ja**
+
+NOT A DUPLICATE (nein) — different entity:
+- A: „Greedy-Algorithmus GA"  B: „ModifiedGreedy (MGA)" → two different algorithms → **nein**
+- A: „Lower Bound Clique bzgl. Knoten"  B: „Lower Bound Clique bzgl. Kanten" → different parameter → **nein**
+- A: „Clique"  B: „3-SAT ≤ Clique" → a problem vs. a reduction (its own block) → **nein**
+- A: „VertexCover ≤ FVS"  B: „VertexCover ≤ Δ-Cover" → same source, different target → different reductions → **nein**
+- A: „Cliquenproblem"  B: „Vertex-Cover-Problem" → different problems → **nein**
 
 Write ONLY the JSON file to: {out_path}
 
-Format (each pair number from the list with "ja" or "nein"; no other text in the file):
+Format (each pair number from the list with „ja" or „nein"; no other text in the file):
 {{"pairs": {{"1": "ja", "2": "nein"}}}}

templates/Prompt/Blocks-Research.md

@@ -12,14 +12,15 @@ Rules:
   - Pure NOTATION/symbols belong to their definition: „|x|", „Σ∗" — not their own entry.
   - A standalone REDUCTION between two problems, however, is its own block („3-SAT ≤ Clique").
 - NO categories, NO ranking, NO ordering by importance — only a flat, numbered list.
-- There is NO target count. Stop only when the research yields nothing new.
-- Invent nothing: include only blocks you have backed by research. Note the source per block (URL or file path). If there is no individual source, the collective source suffices (handbook chapter, textbook, overview page, directory).
+- Aim for the natural number of genuine learning units for this material — there is no hard quota, but do NOT split hairs to inflate the count (prefer the "families learned together = ONE block" rule above). STOP when the only remaining candidates are exercises, meta-questions, administrative notes, or duplicates of blocks you already listed.
+- **EXCLUDE non-content — these are NEVER learning blocks:** exercise/task/assignment scaffolding ("Aufgabe 3", "Bonusaufgabe", "Übung", "Blatt 11", point values), meta/assessment items ("welche der folgenden…", true/false prompts, hand-in / exam-date notes), administrative & boilerplate (headings, page/room/exam numbers, names, copyright), and any **file names, paths, or URLs** (those are provenance, recorded separately — never a block or part of one).
+- Invent nothing: include only blocks actually supported by the provided material.
 - Write title and description in GERMAN (technical terms/code identifiers stay original).
 - Description at most ~12 words.
 
 Write ONLY the Markdown file to: {blocks_path}
 
-Format: EXACTLY one line per block: `N. Title — Kurzbeschreibung — Source`
-The source (3rd segment) MUST be the exact file name or URL of the crawl page the block comes from — it drives the coverage check.
+Format: EXACTLY one line per block: `N. Title — Kurzbeschreibung`
+Use the em-dash " — " (a space on EACH side) ONLY to separate the title from the short description — never elsewhere in the line, and never inside the title or the description. Do NOT append the source file name, path, or URL to the line — provenance is recorded separately by the pipeline.
 {focus}
 {extra}