update

templates/Prompt/Blocks-Gruppierung-Completion.md

@@ -1,18 +1,17 @@
-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.
+Topic "{topic}". Theme blocks were formed by card-sorting a fine-grained item list. Some items were left unassigned. Your job: attach EACH remaining item to the theme it belongs to, so every item lands in a theme. This is organisation, not judgement — items are never discarded.
 
-UMBRELLAS (parent — already-collected parts):
+THEMES (heading — already-assigned members):
 {umbrellas}
 
-REMAINING STANDALONE BLOCKS (numbered):
+REMAINING ITEMS (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.
+## Rule
+- Attach each remaining item to the ONE theme whose subject it shares — the theme a learner would meet it under (a variable/flag/field/instance/facet of that theme's model, system, setup, tool family, or category).
+- Assign as many as you reasonably can. Only leave an item unassigned if it fits NO theme at all — it then becomes its own single-item block (a genuinely standalone concept).
+- Each item goes into at most ONE theme.
 
 Write ONLY the JSON file to: {out_path}
 
-Format (`additions` may be empty; `umbrella` = the UMBRELLA index, `members` = standalone block numbers to attach):
+Format (`additions` may be empty; `umbrella` = the THEME index, `members` = item numbers to attach):
 {{"additions": [{{"umbrella": 0, "members": [8, 12, 34]}}]}}

templates/Prompt/Blocks-Gruppierung.md

@@ -1,35 +1,23 @@
-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.
+Topic "{topic}". A previous step produced a flat list of learning items that is TOO FINE-GRAINED for a table of contents — single environment variables, single CLI flags, single config fields, near-synonyms. Your job is **card sorting**: group the items into a small set of **theme blocks**, so that EVERY item lands in exactly one theme. Nothing is discarded — grouping never loses an item; it only organises them.
 
-**Propose real umbrellas, judge each on its merits.** Merge when the members are constituent parts of one whole (test 3); keep a member separate when it stands as a full, usable unit on its own. Do NOT withhold a genuine merge merely because the members are lexically dissimilar (facets of one whole routinely are) or because you are unsure of the parent's exact name.
+Think of the result as chapters: ~15–25 themes for a whole topic, each a coherent learning block that a learner meets as one unit. A theme with only one fitting item is fine (a genuinely standalone concept), but prefer pulling related items together over leaving many singletons.
 
-CANDIDATES (your starting point):
+CANDIDATES you may group (your starting point — a pre-clustered neighbourhood):
 {candidates}
 
-FULL BLOCK LIST (you may pull in ANY numbers below that are constituents of the same definition):
+FULL ITEM LIST (you may pull in ANY numbers below that share the theme):
 {list}
 
-## Merge test — propose an umbrella when ALL THREE hold
-1. **One parent.** The members are constituent parts/facets of ONE named parent (a model, system, setup, or definition) — each member PRESUPPOSES that parent: you cannot introduce it without first invoking the parent, and it has no purpose outside it.
-2. **Studied together.** A learner meets them together as one unit.
-3. **No standalone unit among them — autonomy test (decisive).** Remove the OTHER members, then ask of each: does it still stand as a COMPLETE, usable unit with its own goal? YES → autonomous → a SIBLING, keep separate (dropping the others took nothing from it). NO → alone it serves no goal and exists only to build the shared parent → a constituent PART, merge it. Structural containment („X is a file/step/field of Y") is NOT the test — autonomy is: own goal, complete without the siblings. This holds in every domain.
+## How to form a theme
+- **One coherent subject.** The members belong together because a learner would study them as one block — the parts/facets/instances of one model, system, setup, tool family, or category. Examples of the *kind* of grouping (not domain rules): many individual settings/variables/flags of one configuration → one „…-Konfiguration" theme; the parts of one setup → one „…-Setup" theme; a base concept plus its variants/instances → one theme.
+- **Lexical dissimilarity is NORMAL.** Facets of one theme often read very differently — that is not a reason to split them.
+- **Title:** name the theme after the shared subject. A real self-contained heading; must NOT contain „ — " (reserved separator) — use „(…)" or „:".
+- **Description:** name EVERY member explicitly (the next step recovers them as sub-points). E.g. „Environment-Konfiguration: APP_ENV, APP_SECRET, DATABASE_URL, MAILER_DSN, …".
+- **Members:** the item NUMBERS from the full list. Each number goes into exactly ONE theme; do not repeat a number across themes.
 
-*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.
-- „Plugin" + „Plugin-Konfiguration (config.xml)" + „Plugin lifecycle" → „Plugin-Konfiguration" is its OWN unit (authoring config fields, snippets, its own tasks), a SIBLING of „Plugin", not a facet (test 3 fails). Structural containment — the file belongs to the plugin — is NOT the merge test; being studied as one definition is. Keep „Plugin-Konfiguration" standalone.
-
-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.
+Assign as many items as you confidently can. Items you are unsure about you may leave out — a later completion step and a singleton fallback catch them; never force a bad fit.
 
 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]}}]}}
+Format (`umbrellas` = the themes; may be empty if nothing fits together):
+{{"umbrellas": [{{"title": "Environment-Konfiguration", "description": "Konfiguration über Umgebungsvariablen: APP_ENV, APP_SECRET, DATABASE_URL, MAILER_DSN, .env-Dateien.", "members": [1, 2, 5, 12, 34]}}]}}

templates/Prompt/Subblock-Anreichern.md

@@ -0,0 +1,32 @@
+The block below (topic "{topic}") is ALREADY decomposed into its subblocks — the list is FIXED. Your job is NOT to find subblocks, but to extract for EACH given subblock its learning facts from the material. A later guide writes a short text PER subblock; the facts are the binding basis for guide text, levels, and exam questions — they must be **correct**.
+
+BLOCK:
+{block}
+
+FIXED SUBBLOCKS (numbered — return one entry per subblock, in this order):
+{subs}
+
+{source}
+
+HARD RULES:
+- Return EXACTLY these subblocks — do NOT add, remove, split, merge or rename any. Copy each `title` VERBATIM from the list above (code identifiers stay original).
+- One entry per given subblock, same order. If the material barely covers a subblock, still return it with whatever is backable (empty fields are fine) — never drop it.
+
+Per subblock, collect ONLY the essentials (all field content in GERMAN; technical terms/code identifiers stay original):
+- **level**: beginner | advanced | expert — difficulty within this block.
+- **relevance**: relevant (core of the topic) | peripheral (edge knowledge).
+- **key_points**: 1–3 concise statements — what must one understand?
+- **prerequisites**: what must one know beforehand (a half-sentence)? Empty if nothing.
+- **hurdles**: typical beginner misconception (a half-sentence). Empty if none.
+- **cited_facts**: hard facts (definitions, formulas, values, names) — **only what the excerpts back**, each with the location (e.g. „Skript Def. 6.3, Z.66"). Invent no values, compute nothing yourself.
+- **example_idea**: ONE example that carries understanding — freely phrased. Empty if an example adds nothing.
+
+HARD SEPARATION: `cited_facts` = only backable material. A worked example, an invented sentence, a constructed case → `example_idea`, NEVER `cited_facts`. When in doubt: better to leave a field empty than to claim falsely.
+
+Reply with ONLY the JSON as your final message — no code fences, no other text. EXACTLY this format:
+{{"subs": [
+  {{"title": "…", "level": "beginner|advanced|expert", "relevance": "relevant|peripheral",
+    "key_points": ["…"], "prerequisites": "…", "hurdles": "…",
+    "cited_facts": [{{"text": "…", "source": "…"}}], "example_idea": "…"}}
+]}}
+{extra}

templates/Prompt/Subblock-Verify.md

@@ -1,26 +1,18 @@
-You are auditing the decomposition of ONE block of the topic "{topic}" into subblocks. Below are the numbered subblocks with their captured facts, then source excerpts. Apply the 100%-decomposition test: no entry removable without a gap, none addable without duplication — and verify the facts.
+You are auditing ONE block of the topic "{topic}". Its subblocks are FIXED (already decomposed and deduplicated upstream) — you do NOT add, remove, merge or split them. You only verify the captured FACTS against the source and correct the level/relevance classification.
 
 BLOCK: {block}
 
 SUBBLOCKS (numbered; key points indented):
 {subs}
-{unsicher}
 {source}
 
-Judge ALL of the following (use the numbers):
-1. **gruppen** — entries that state the SAME thing or where one is a subset of the other: group them and name the number that should remain (`haupt` = the base statement, not the detail).
-2. **kataloge** — pure enumeration entries of ONE kind (e.g. five option rows): bundle them under ONE short GERMAN collective title.
-3. **fremd** — entries off-topic for the topic "{topic}" (not this block — the TOPIC).
-4. **luecken** — essential aspects of THIS block that the excerpts cover but no entry captures (short German phrases). Only real gaps, no nice-to-haves.
-5. **uebernehmen** — for each UNSICHER-numbered entry: "ja" if the excerpts back it and it fills a real spot, else "nein".
-6. **facts_probleme** — entries whose facts contain something wrong or unbackable: `discard: true` ONLY if the entry as a whole is unsupportable in substance; otherwise `discard: false` with a short `hinweis` what to correct.
-7. **levels** / **relevanz** — ONLY entries whose level (beginner/advanced/expert) or relevance (relevant/peripheral) is clearly wrong: number → correct value.
+Judge from the excerpts only, using the numbers:
+1. **facts_probleme** — entries whose captured facts contain something wrong or unbackable: give a short `hinweis` what to correct (keep `discard: false` — the subblock itself always stays; only its facts get fixed).
+2. **levels** / **relevanz** — ONLY entries whose level (beginner/advanced/expert) or relevance (relevant/peripheral) is clearly wrong: number → correct value.
 
-Judge ONLY from the excerpts. If everything is fine, return empty lists/objects.
+If everything is fine, return empty lists/objects.
 
 Reply with ONLY the JSON — no code fences, no other text. Format:
-{{"gruppen": [{{"haupt": 1, "weitere": [4]}}], "kataloge": [{{"titel": "…", "mitglieder": [2, 5]}}],
- "fremd": [7], "luecken": ["…"], "uebernehmen": {{"9": "ja"}},
- "facts_probleme": [{{"nr": 3, "discard": false, "hinweis": "…"}}],
+{{"facts_probleme": [{{"nr": 3, "discard": false, "hinweis": "…"}}],
  "levels": {{"2": "expert"}}, "relevanz": {{"5": "peripheral"}}}}
 {extra}