creator/templates/Prompt/Blocks-Gruppierung.md

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 real umbrellas, but don't force them. A downstream guard only rejects umbrellas that swallow a named theory-of-computation result (algorithm/problem/theorem/complexity class) — it does NOT catch a wrongly-swallowed engineering skill or procedure. So when a member could stand as its own lesson (test 3 below), keep it separate rather than merge on a hunch. But do NOT withhold a genuine 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 a concept a learner would study and be tested on in its OWN right — one with its own exercises or procedure that you could practice without first teaching the parent. Litmus: could this member be its own lesson with its own tasks? If yes, it is a SIBLING, not a facet of the parent — keep it separate. This covers BOTH domains: in theory-of-computation 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"); in engineering a self-contained skill or procedure („Plugin-Konfiguration / config.xml", „PHPUnit-Test-Setup") — each is its own learning object. By contrast, a facet like „Alphabet Σ" or „Übergangsfunktion δ" has NO exercises of its own without the parent model → it stays a member.

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.

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]}}]}}