marek/creator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
team3
2026-06-30 18:06:06 +02:00
parent a2a5da25df
commit fa718b7d6c
8 changed files with 231 additions and 219 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
templates/Prompt/Blocks-Paar-Filter.md
View File

@@ -1,18 +1,23 @@
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**.
Research has noted block candidates 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**.
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.
- **Watch the CORE ENTITY first** (the object/concept/operation in question). If the entities are DIFFERENT → **nein**, no matter how identical the phrasing. Examples of **nein** despite near-identical wording:
- "Plugin-**Lebenszyklus**" ↔ "App-**Lebenszyklus**" (different object: Plugin vs App)
- "**install()**-Methode" ↔ "**uninstall()**-Methode" (different operation)
- "Lower Bound **Clique**" ↔ "Lower Bound **Vertex Cover**" (different problem)
- "Present **Perfect**" ↔ "Past **Perfect**" (different tense)
- **ja** ONLY on genuine semantic equivalence: the same concept/operation, just different wording, naming, language or abbreviation. Examples:
- "EntityRepository" ↔ "Repository für CRUD-Operationen am DAL"
- "Set Cover" ↔ "Mengenüberdeckungsproblem"
- "List Scheduling" ↔ "LPT-Algorithmus"
- **nein** for different ASPECTS, properties, parts or methods of the same thing — they are their own blocks (a later step folds true fragments back in):
- a concept ↔ one of its properties/details ("DAL" ↔ "DAL-Versionierung")
- a concept ↔ a single method/step of it ("Plugin-Lebenszyklus" ↔ "install()-Methode")
- a thing ↔ its sub-component, its verifier, its reduction to another thing
- When in doubt → **nein**. Better two separate blocks than wrongly merging two concepts.
Write ONLY the JSON file to: {out_path}