Was offen ist, und was schon geschah

Matryoshka-Kürzung der Vektoren - VERWORFEN, nicht zurückgestellt.

Warum

Technisch verlockend: text-embedding-3-large trägt den Großteil der Information in den ersten 1024 Dimensionen, Kürzen und Neunormalisieren geht lokal ohne API-Kosten, ergäbe 25 statt 75 MB und dreifach schnellere Suche.

Entschieden

Am 2026-08-05 ausdrücklich verworfen. Der Qualitätsverlust ist für dieses Korpus nicht gemessen, und die Ladezeit löst bereits Aufgabe 17 verlustfrei. Grundsatz des Nutzers: 'wenn Qualität leidet, dann lieber gedulden als Qualität verlieren'. Dieselbe Haltung steht schon in config.py beim VALIDATION_MODEL und in ARCHITECTURE.md bei den Embeddings.

Wo ein Ayet zutrifft, auch den Bezug zur Ehl-i Beyt verständlich machen.

Vom Nutzer gesetzt: "'Muhammed Ali' ist ein tiefer Ausdruck des Tevhid-Gedankens, da diese zur Einheit Allahs führen - nur beide zusammen, wie die zwei Hälften des Apfels, vervollständigen den Einheitsgedanken." Nicht "hierzu gibt es auch einen Kommentar", sondern der inhaltliche Zusammenhang.

Warum

240 Ayets tragen bereits eine Ehl-i-Beyt-Auslegung als Attribut, mit Konfidenzmarker - und sie erreicht weder Dokument noch Prüfdokument. Der Produktivpfad kennt nicht einmal das Flag.

Entschieden

Nicht in den Reasoning-Prompt der bestehenden Stufe - getrennt behandelt. Ob die Erklärung einen eigenen Aufruf braucht, ist offen und kostenrelevant.

Ergebnis

analyzer.ehlibeyt_auslegung(sure, ayet) schlaegt die Auslegung nach dem Treffer nach; node_to_ayet haengt sie an, beide Dokumentformate zeigen sie unter dem Wortlaut. WARUM NACHSCHLAGEN UND NICHT MITSUCHEN: der Kommentartext wandert bewusst NICHT in den eingebetteten Text - sonst wuerde ein Vers ueber seinen Kommentar gefunden statt ueber seinen eigenen Wortlaut. Der Index fuehrt deshalb nur `has_ehlibeyt`, und genau darum kam der Inhalt bis heute nirgends an. Der ANKER wandert mit: 'zitat' heisst, der Ausschnitt sitzt auf der wiedergefundenen Koranstelle, 'referenz' heisst, nur die Seite ist sicher - im Buchformat steht das im Klartext dabei, weil es beim Zitieren zaehlt. 5 Tests, darunter die Gegenprobe, dass der Kommentartext NICHT im Index steht.

Zeilen ohne Ayet-Zuordnung gegen die 6101 Ehl-i-Beyt-Passagen suchen.

Warum

Der größte inhaltliche Hebel. Gemessen am Probelauf: KH_0009 hat 87 % Lücken, SH_0010 72 % - beides Deyişe über die Ehl-i Beyt. Cafer kommt 978-mal im Ehl-i-Beyt-Korpus vor und NULL-mal im Kur'an, Rıza 436/0, Mehdi 407/0, Hayber 31/0. Die Lücken sind korrekt, aber vermeidbar: der Korpus ist gebaut, knowledge_index führt ihn, analyzer.py fragt ihn nie ab.

Entschieden

Nur bei Zeilen OHNE Zuordnung, damit der Kur'an den Vorrang behält und die teuren Stufen nur dort zusätzlich laufen, wo bisher nichts steht.

Noch offen

Darstellung im DOCX (eine Passage ist kein Ayet und darf nicht so aussehen). Kosten: jede zusätzlich gefüllte Zeile kostet Reasoning UND Prüfung.

Ergebnis

Der Rueckfall auf die Zusatzkorpora lief bisher NUR bei Zeilen ohne Ayet. Bei einem Deyis UEBER die Ehl-i Beyt ist die Ayet-Suche aber strukturell chancenlos: 'Cafer' kommt 978-mal im Ehl-i-Beyt-Korpus vor und NULL-mal im Kur'an, 'Riza' 436/0, 'Mehdi' 407/0, 'Hayber' 31/0. Ein Vers ueber diese Personen existiert nicht - die Luecke ist korrekt und trotzdem vermeidbar. Nennt die Strophe eine solche Person (ueber ontology.such_begriffe aus #27), wird der Zusatzkorpus jetzt AUCH DANN gefragt, wenn ein Ayet gefunden wurde. Das ist die eine begruendete Ausnahme vom Vorrang des Kur'an: nicht 'immer alles' - dann stuende neben jedem Ayet eine Passage und das Dokument waere kein Deyis-Kur'an-Vergleich mehr - sondern dort, wo die Wissensbasis nachweislich mehr weiss als der Vergleichstext. NICHT GEMESSEN: wie oft das greift und was es kostet (ein Reasoning-Aufruf je Beleg). Das ist Aufgabe #24.

Eine Zuordnung ist heute ein Eintrag IM Werk, keine eigenständige Beziehung.

Warum

Aus dem Architektur-Audit, schwerster Befund (B1). Die Gegenrichtung ist nicht abfragbar ('welche Verszeilen verweisen auf Sure 24:27?' braucht einen Durchlauf über 517 Werke), es gibt genau einen impliziten Beziehungstyp, und zwei Werke können sich keine Kante teilen. Bei 7 analysierten Werken ist die Migration eine Stunde, bei 517 ein Projekt - der Zeitpunkt läuft ab.

Wie

knowledge/relations.json + relations.py. Der Evidenz- und Prüfblock, den die Zeile schon trägt, zieht mit um. analysis.rows bleibt als Ansicht, damit Dokument und Warteschlange unverändert laufen.

Noch offen

Prüfbar durch: die Gegenfrage wird ohne Werkdurchlauf beantwortet UND das erzeugte DOCX ist unverändert.

Ergebnis

relations.py + build_relations.py: 19914 Kanten, 7477 Knoten, Gegenrichtung und Pfadsuche. analysis.rows unverändert.

Je Passage ein Satz Zusammenfassung, Themen und Kernaussage - als Attribut IM Korpus.

Warum

Vom Nutzer gefordert (2026-08-05): Um in einer Deyiş-Analyse sagen zu können 'İmam Cafer Sadık sagte hierzu...', muss man die Erlebnisse und Aussagen schnell durchsuchen können. enrich_passages.py deckt die Frage 'WO kommt jemand vor' ab (kostenlos, fertig). Offen bleibt 'WORUM geht es', und das kann nur ein Modell beantworten.

Wie

Eine Stufe wie meaning_engine, aber für Prosa: eine Zusammenfassung, 3-5 Themen und die Kernaussage je Passage, geschrieben als 'deutung' in die Passage. Danach ist die Passage über ihr Thema auffindbar UND als Einbettungstext besser (Thema + Wortlaut statt nur Wortlaut).

Noch offen

Freigabe des Nutzers für den Lauf. Vorher an 20 Passagen erproben und die Deutungen ansehen - eine schlechte Zusammenfassung ist schlimmer als keine, weil sie ins Retrieval eingeht.

Ergebnis

Erledigt am 2026-08-07 durch interpret_passagen.py: 6480 von 6482 Passagen gedeutet (2 Luecken), GEMESSEN 1,7155 EUR - je Passage 0,00026 EUR. Je Passage zwei Saetze statt einem: WORUM es geht (macht sie wiederfindbar, ersetzt den incipit-Behelf) und die KERNAUSSAGE dahinter (macht sie mit einem Deyiş vergleichbar). Eingebettet wird nur die Kernaussage - die Zusammenfassung besteht weitgehend aus denselben Woertern wie der Wortlaut und wuerde das Gewicht der Handlung verdoppeln, statt Bedeutung hinzuzufuegen. 353 Apparat-Passagen (Vorwort, Register, Literaturverzeichnis) wurden vorher ausgeschlossen und gar nicht erst bezahlt. Aufgabe 28 und 59 waren dieselbe Arbeit.

Die Kernaufgabe neu gefasst: nicht welche Wörter gleich sind, sondern welche Botschaft geteilt wird.

Warum

Vom Nutzer aus einem Reviewer-Hinweis abgeleitet (2026-08-05) und das wichtigste Prinzip des Projekts: 'Dost' kann göttliche Gegenwart, Hak oder den Weggefährten meinen; 'sevgiyle yürümek' zielt auf Gottesnähe, Barmherzigkeit, Gerechtigkeit, Demut - nicht auf das Wort 'Liebe'. Gesucht werden soll die Lehre, nicht das Vokabular. GEMESSEN am 2026-08-05: von 219 Kandidaten kamen 109 nur über die Originalzeile, 109 nur über die Bedeutung und genau EINER über beide. Die zwei Suchwege überlappen praktisch nicht - weil die Deyiş-Zeile gedeutet wird, der Kur'an aber nur im Wortlaut durchsucht. Verglichen wird Bedeutung mit Wortlaut. Der Nutzer hat genau das benannt: 'dafür braucht man die Interpretationsebene vom Deyiş UND vom Kur'an'.

Wie

Teilweise vorhanden: meaning_engine liefert bereits Bedeutung und Schlagworte, und das Retrieval sucht hybrid über beide. Was fehlt: (a) die Bedeutungsstufe fragt nach Wortsinn, nicht nach ethischer/spiritueller Lehre - der Prompt ist umzuschreiben; (b) gesucht wird gegen den Ayet-WORTLAUT, nicht gegen dessen Botschaft, also braucht auch der Kur'an eine Deutungsebene (dieselbe Stufe wie Aufgabe 28); (c) das Ranking bewertet Passung, nicht geteilte Lehre.

Noch offen

NUR gegen ein gefülltes Golden Set zu ändern (Aufgabe 7). Ohne Messung ist nicht zu unterscheiden, ob eine neue Fassung tiefer trifft oder nur anders danebenliegt.

Ergebnis

Das Prinzip laesst sich nicht durch einen weiteren Umbau erfuellen, sondern nur MESSEN - und zwar an dem, was die Wissensbasis ohnehin mitschreibt. mapping_messen.py zaehlt, wie viele zugeordnete Ayets KEIN inhaltstragendes Wort mit ihrer Verszeile teilen. Bei einem reinen Stichwortsystem waere die Zahl null. MESSUNG an PSA_0001 nach dem Lauf vom 06.08.: 24 von 24 Zuordnungen (100 %) teilen kein Wort. Suchweg: 14x ueber die Bedeutung, 9x ueber die Rohzeile, 1x ueber beide. Beispiel: 'Temennaya geldim erenler size' -> NUR 24:27 ('betretet keine Haeuser ausser euren eigenen, ohne euch bemerkbar zu machen'). Kein gemeinsames Wort, dieselbe Sache. ⚠ Die Zahl beweist NICHT, dass die Zuordnungen richtig sind - nur, dass sie nicht ueber Wortgleichheit zustande kamen. Richtigkeit misst das Golden Set (11 von 21 nach dem Lauf).

Jede Quelle bekommt Verlässlichkeit, Gattung, Ausgabe, Sprache - und das Retrieval berücksichtigt es.

Warum

Punkt 7 der Erweiterung. Heute wiegt eine Passage aus einer wissenschaftlichen Edition genauso viel wie eine aus einem Webseiten-Abzug, und ein Primärtext genauso viel wie Sekundärliteratur. Bei einer wissenschaftlichen Wissensbasis ist das der Unterschied zwischen Beleg und Behauptung.

Wie

Billig zu bauen, weil die Metadaten schon je Band existieren (ehlibeyt_rules, peygamberler_rules, author_rules). Ergänzt werden: kategorie (original/sekundär/akademisch), verlaesslichkeit, ausgabe, jahr, herausgeber. Das Ranking gewichtet damit bei gleichem Ähnlichkeitswert.

Noch offen

Die Einstufung ist eine fachliche Entscheidung und gehört dem Nutzer - der Importer darf sie nicht raten.

Ergebnis

quellen.py ordnet jede der 28 Quellen ein: primaer (1.00), edition (0.95), lexikon (0.90), sekundaer (0.80), abzug (0.70). Die Guete steht als Metadatum AM DATENSATZ - sie gehoert zum Datensatz, nicht zur Anfrage - und ordnet die Belege nach; sie wandert ausserdem ins Ergebnis, damit ein Leser sieht, ob ein Beleg aus einem Primaertext oder aus einem Digitalisat ohne Editionsangabe stammt. ⚠ SIE BLENDET NICHTS AUS. Der Abstand ist bewusst klein (0,30 ueber alle Stufen): ein genau passender Webabzug schlaegt weiter eine nur ungefaehr passende Edition. Wer Quellen unterdrueckt, faelscht den Bestand; wer sie ungewichtet nebeneinanderstellt, faelscht das Urteil. Ein Test verbietet das Filtern. 'unbekannt' (0.75) liegt UEBER 'abzug': eine nicht eingeordnete Quelle ist nicht dasselbe wie eine schlechte - sonst bestraft man die eigene Nachlaessigkeit als Mangel der Quelle. ⚠ Eigener Fehler: die erste Fassung pruefte Werkart und Herkunft in EINER Liste, und weil 'caferilik' im Dateinamen frueher traf, galt die Sahîfe-i Seccâdiye - eine Gebetssammlung des vierten Imams - als blosser Webabzug. Das Digitalisat ist die Ueberlieferungsform, nicht die Gattung. Jetzt zwei Stufen, Werk vor Herkunft.

ayet_relevant verwirft indirekte Bezüge - genau die, die dieses Projekt sucht.

Warum

Am 2026-08-05 als Ursache eines unbemerkten Qualitätsregresses nachgewiesen: PSA_0001 hatte am 3.8. 24 belegte Zeilen, am 4.8. nur noch 8. Alle 16 verlorenen tragen ayet_relevant=False bei Konfidenz 0,78-0,88 - die Prüfung ist sich SICHER, dass das Ayet nicht passt. Sie beurteilt wörtliche Passung. Die als gut bewertete Fassung sagte dagegen ausdrücklich 'birebir geçmez, ancak ... ilişkilendirilebilir' - steht nicht wörtlich da, lässt sich aber verbinden. Das ist keine Schwäche der Zuordnung, sondern ihr Zweck.

Wie

Der Prompt der Prüfstufe (validator.validate_row) trennt heute nicht zwischen 'das Ayet hat mit der Zeile nichts zu tun' und 'das Ayet sagt es nicht wörtlich'. Zwei Kriterien statt einem: wörtliche Entsprechung UND thematisch-ethische Verbindung. Nur das Fehlen von BEIDEM ist ein Ausschlussgrund.

Noch offen

Jetzt messbar (Golden Set, 22 Einträge). Vorher/Nachher gegen dieselbe Datei - eine Aufweichung, die die Trefferquote hebt und die Genauigkeit senkt, wäre keine Verbesserung.

Ergebnis

Prompt trennt lafzi/kavramsal, evidence.auto_status gibt begrifflichen Bezügen NIE eine automatische Freigabe. Gemessen: 8 -> 23 belegte Zeilen, aber nur 3 von 21 richtig - der Engpass ist das Retrieval.

Der nachgewiesene Engpass: 18 % Trefferquote, und die Lockerung der Prüfstufe half nicht.

Warum

Am 2026-08-05 zweifach gemessen. (a) evaluate_golden_set: 4 von 22 erwarteten Ayets werden gefunden, MRR 0,083. (b) Nach dem Prüfstufen-Umbau bekamen 23 von 24 Zeilen ein Ayet, aber nur 3 von 21 eines, das die menschlich freigegebene Fassung auch nennt. Die Prüfung war nicht zu streng - das Retrieval liefert die falschen Kandidaten. Der found_via-Befund zeigt warum: 109 Kandidaten nur über die Originalzeile, 109 nur über die Bedeutung, EINER über beide. Die Deyiş-Zeile wird gedeutet, der Kur'an nur im Wortlaut durchsucht.

Wie

Aufgabe 28 und 29 zusammen: eine Deutungsebene AUCH für den Kur'an, dann Bedeutung gegen Bedeutung suchen statt Bedeutung gegen Wortlaut. Der Vergleichsmaßstab steht bereit (22 geprüfte Golden-Set-Einträge).

Noch offen

Braucht die Freigabe für den Deutungslauf. Der Kur'an allein sind 6236 Ayets - kürzere Einheiten als die Prosapassagen, also deutlich unter den 2-9 EUR aus Aufgabe 28.

Ergebnis

Kur'an-Deutungsebene gebaut, 6222 von 6236 Ayets (99 %), 0,63 EUR. In den eingebetteten Text aufgenommen, Wortlaut bleibt vorne. GEMESSEN an PSA_0001: 6 richtige Ayets statt 4, Ausbeute 75 % statt 50 %, bei gleichen Kosten. Der erste gemessene Qualitätsgewinn - alle vorherigen Änderungen (Prüfstufe, Strophe, Kandidatenmenge) hatten die Trefferzahl nicht bewegt.

985 Seiten alevitisch-bektaschitisches Fachlexikon - die fehlende Quelle für die Deutungsebene.

Warum

Eingetroffen am 2026-08-05. Geprüft: sauberer Textlayer, alphabetisch, Kolumnentitel tragen den Buchstaben, Einträge im Format 'begriff: Erklärung', mit Deyiş-Zitaten als Belege. Das Projekt hat bisher NUR ein Nebenprodukt-Glossar (96 Begriffe aus der Analyse). Dieses Lexikon ist eine PRIMÄRE Begriffsquelle - genau das, was Layer 4 der neuen Richtung braucht: nicht Wörter erkennen, sondern ihre religiöse Funktion erklären.

Wie

Eigener Importer, aber die atomare Einheit ist der EINTRAG (wie bei esma.json), nicht die Passage. Ziel: knowledge/terminologie.json. Die Einträge fließen dann in die Ontologie (build_ontology) als belegte Konzepte MIT Definition - heute haben 96 von 305 Entitäten eine Beschreibung.

Noch offen

Die Deyiş-Zitate im Lexikon sind ein Nebenschatz: sie belegen, in welchem Vers ein Begriff vorkommt - das sind fertige Kanten für den Graphen.

Ergebnis

4091 Einträge, 490 Querverweise, 532 Belegverse. OFFEN: (a) die Einträge sind noch nicht in der Ontologie - erst damit werden aus 96 beschriebenen Entitäten mehrere tausend; (b) 233 Einträge (5,7 %) haben keine Erklärung, weil ihr Stichwort am Seitenende steht und der Kolumnentitel der Folgeseite dazwischenkommt - KOPFZEILEN von 3 erhöhen; (c) das Lexikon ist weder im Wiki noch im Retrieval. || ABGESCHLOSSEN 2026-08-06: (a) Die Lexikoneintraege sind jetzt in der Ontologie - 673 -> 2947 Entitaeten, davon 2647 aus dem Lexikon. Aufgenommen werden NUR Eintraege mit Erklaerung: ein Stichwort ohne Definition liefert einen Namen, unter dem nichts steht, und Querverweise ('bk. abdal') zeigen auf eine Entitaet, statt eine zu sein. (b) Die fehlenden Erklaerungen sind ueber #61 von 816 auf 9 gesunken, der Rest ist #62. ⚠ FOLGE: 82 Alias-Kollisionen statt 10. Das Lexikon fuehrt 'Cafer-i Sadik' als Stichwort, die Ontologie 'Imam Cafer Sadik'; 'Ali' zeigt jetzt auf zwei Entitaeten. Kollisionen werden gemeldet, nicht aufgeloest - das ist eine Entscheidung, keine Rechenaufgabe: python review_ontology.py export --nur-kollisionen

Der fundamentalste Eingriff der neuen Richtung - und er berührt fast alles.

Warum

Vom Nutzer gefordert (2026-08-05): 'Die Strophe ist die primäre Analyseeinheit, die einzelne Zeile wird nur bei Bedarf analysiert.' Fachlich richtig: ein Beyit ist eine Sinneinheit, eine halbe Aussage ist keine. Und es deckt sich mit dem gemessenen Befund - die zeilenweise Suche hat zu wenig Kontext (Trefferquote 18 %).

Wie

Betroffen sind: analyzer._group_lines (gruppiert heute nach gleichem Ayet, nicht nach Strophe), evidence.line_index_start/end, das Golden Set (22 Einträge je Verszeile), review_queue, relations.knoten('deyis_zeile'), docx_writer. Die Strophengrenze liegt bereits vor: der Importer trennt an Leerzeilen.

Noch offen

GUTER ZEITPUNKT: erst 8 Werke sind analysiert. Bei 517 wäre das ein Projekt. Die 22 Golden-Set-Einträge müssten auf Strophen umgerechnet werden - machbar, weil das Quelldokument die Gruppierung zeigt.

Ergebnis

Suche, Gruppierung und Evidenz laufen strophenweise; Zeilenpositionen bleiben global und lückenlos, kein Zeilenverlust. OFFEN: (a) noch kein Lauf gegen das Golden Set - ob die Trefferquote wirklich steigt, ist unbewiesen; (b) docx_writer und Prüfdokument zeigen weiter Tabellenzeilen, das Buchformat ist Aufgabe 50. GEMESSEN am 6.8.: 3 richtige Ayets wie zuvor, aber 0,12 statt 0,40 EUR je Werk. Kostengewinn Faktor 3,3, kein Qualitätsgewinn. || ABGESCHLOSSEN 06.08.: Das Dokument zeigt die Strophe jetzt als solche - '1. Strophe, Zeilen 1-4' unter jeder Tabellenzeile, mit der Marke [Behelfsteilung] dort, wo die Grenze geraten statt gelesen ist. Vorher sah eine Tabellenzeile aus wie eine willkuerliche Gruppierung, und es war nicht nachpruefbar, WELCHE Verse beurteilt wurden. ⚠ Die Marke steht NACH dem Text: _set_cell_lines leert die Zelle und verwarf eine vorher gesetzte Kopfzeile - lautlos.

Erst bestimmen WAS für ein Deyiş das ist und WOZU es geschrieben wurde - vor jeder Suche.

Warum

Layer 1 und 2 der neuen Pipeline. Heute beginnt die Analyse direkt mit der Bedeutung einzelner Zeilen; die Gattung (Düvaz, Nefes, Erkân, Mersiye, Devriye, Nutuk) und der Zweck (İkrar erklären, auf den Cem vorbereiten, Edep lehren) werden nie bestimmt. Beides ändert, WONACH überhaupt zu suchen ist: ein Düvaz-İmam sucht andere Bezüge als ein Devriye.

Wie

Eine Stufe VOR meaning_engine, ein Aufruf je Werk. Ergebnis als 'gattung' und 'zweck' im Werk. Beides geht als Kontext in alle folgenden Stufen ein.

Noch offen

Kostet einen zusätzlichen Aufruf je Werk (billigstes Modell, ganzes Gedicht als Eingabe - also günstig). Erst nach 46, sonst zweimal umbauen.

Ergebnis

context_engine.py: ein Aufruf je Werk VOR der Bedeutungsstufe, bestimmt Gattung (11 Arten, aus dem Gegenstand heraus - Düvaz, Nefes, Erkân, Devriye, Mersiye, Öğüt, Methiye, Şathiye, Tarihî, Münacaat, Cem), Zweck, Station des Weges, angestrebte Wandlung und Anlass. Das Ergebnis steht NEBEN 'analysis' am Werk, nicht darin: es beschreibt das Gedicht, nicht seinen Abgleich mit dem Kur'an, und überlebt so jedes --no-resume. Ein Wert ausserhalb der Liste wird verworfen statt uebernommen - eine geratene Gattung kaeme in jeder folgenden Stufe als Tatsache an. Kontextzeile geht in PROMPT_ROW und PROMPT_GENEL_IZLENIM ein, sonst waere die Stufe ein Bericht, den niemand liest. Alle 84 Pir-Sultan-Werke bestimmt fuer 0,02 EUR (84 Aufrufe auf gpt-5.6-luna): 53 Oeguet, 21 Nefes, 3 Erkan, 2 Sathiye, 2 Muenacaat, je 1 Cem/Tarihi/Mersiye. OFFEN: 63 % Oeguet ist auffaellig viel und koennte ein Ausweichen des Modells auf die unspezifischste Kategorie sein - pruefbar erst an einem Urteil des Nutzers ueber eine Stichprobe. Nachtragen ohne Neuanalyse: python context_engine.py --author X

meaning_engine liefert Schlagworte - gebraucht werden KONZEPTE mit religiöser Funktion.

Warum

Layer 3 und 4. Der vorhandene Ansatz ist da (bedeutung, schlagworte, semboller), aber er bleibt an der Wortoberfläche: 'Destur' wird als Symbol erkannt, seine Funktion im Erkân nicht erklärt. Der Nutzer: 'Do not merely detect words. Explain their religious function.'

Wie

Zwei Zuflüsse, die schon existieren: die Ontologie (305 Entitäten mit Typ) und - sobald 45 erledigt ist - das Terminologie-Lexikon mit echten Definitionen. Der Prompt fragt dann nicht 'welche Begriffe kommen vor', sondern 'welche Lehre wird hier vermittelt und mit welchen Begriffen der Yol'.

Noch offen

Hängt an 45 (Lexikon) und 46 (Strophe).

Ergebnis

Die Bedeutungsstufe liefert jetzt `kavramlar` neben `semboller`, und der Unterschied ist der Punkt: `semboller` sind die Begriffe, die IN der Zeile stehen, `kavramlar` ist das, was sie LEHRT. Je Konzept drei Felder - der Begriff, seine ISLEV (Funktion im Erkan: wozu ist er da, wo im Yol steht er) und die OGRETI (die Lehre in einem Satz, so formuliert, dass sie im Kur'an eine Entsprechung haben KANN, aber ohne Ayet zu nennen). Die OGRETI geht in die Suchanfrage ein, und das ist der eigentliche Eingriff: der Vers sagt nicht 'kemerbest', er sagt, was ein Mensch tun soll, bevor er aufgenommen wird. Ohne die Lehre in der Anfrage sucht das System weiter nach dem Wort. Ein Eintrag OHNE ogreti wird verworfen - Begriff und Funktion allein sind ein Woerterbucheintrag, und den liefert lexikon.py belegt statt geraten. Hoechstens drei je Zeile. Ohne Konzepte ist die Anfrage zeichengleich mit der bisherigen, sonst waere kein Vorher/Nachher vergleichbar. 11 Tests.

Identisch mit Aufgabe 44 - der gemessene Engpass, jetzt in der Sprache der neuen Richtung.

Warum

'Never search for identical vocabulary. Search for identical meaning.' GEMESSEN am 2026-08-05: von 219 Kandidaten kamen 109 nur über die Rohzeile, 109 nur über die Bedeutung, EINER über beide - weil die Deyiş-Seite gedeutet wird, die Kur'an-Seite nicht. Und: nach dem Prüfstufen-Umbau bekamen 23 von 24 Zeilen ein Ayet, aber nur 3 von 21 ein RICHTIGES.

Wie

Der Kur'an braucht selbst eine Deutungsebene (Prinzip/Lehre je Ayet), dann Lehre gegen Lehre. 6236 Ayets, kurze Einheiten - deutlich billiger als die 6836 Prosapassagen aus Aufgabe 28.

Noch offen

Braucht die Freigabe für den Deutungslauf. Danach direkt gegen die 22 Golden-Set-Einträge messbar.

Ergebnis

Kur'an-Deutungsebene gebaut, 6222 von 6236 Ayets (99 %), 0,63 EUR. In den eingebetteten Text aufgenommen, Wortlaut bleibt vorne. GEMESSEN an PSA_0001: 6 richtige Ayets statt 4, Ausbeute 75 % statt 50 %, bei gleichen Kosten. Der erste gemessene Qualitätsgewinn - alle vorherigen Änderungen (Prüfstufe, Strophe, Kandidatenmenge) hatten die Trefferzahl nicht bewegt.

4091 Definitionen und 490 belegte Synonyme warten - die Ontologie hat 96 Beschreibungen.

Warum

Der eigentliche Zweck von Aufgabe 45. Heute haben 96 von 305 Entitäten eine Beschreibung, und die stammt aus der eigenen Analyse - also aus derselben Pipeline, die damit beurteilt werden soll. Das Lexikon ist eine PRIMÄRE Quelle. Die 490 'bk.'-Verweise sind zudem belegte Synonyme, genau das, was der Ontologie an Aliasen fehlt und was aus keinem anderen Korpus abzuleiten ist.

Wie

build_ontology bekommt einen fünften Zufluss. Ein Lexikoneintrag wird zur Entität vom Typ konzept/ritual/person - der Typ ist aus dem Definitionstext zu erschließen. Die bk.-Verweise werden zu Aliasen der Zielentität. Belegpflicht wie überall: Band, Seite, Stichwort.

Noch offen

Die Typzuweisung ist die einzige offene Frage - 4091 Einträge von Hand zu typisieren ist zu viel, ein Modell dafür kostet. Ein Zwischenweg: alle als 'konzept' aufnehmen (der Auffangtyp) und nur die typisieren, die im Retrieval auffallen.

Ergebnis

673 Entitäten (von 305), 94 % mit Beschreibung (von 31 %). Filter: nur Begriffe, die eine bekannte Entität beschreiben oder in den Deyişen vorkommen. Die bk.-Querverweise wurden zu Aliasen.

Der Strophen-Umbau hat die Kandidatenmenge auf ein Viertel gesenkt - das ist der Grund für den ausgebliebenen Qualitätsgewinn.

Warum

GEMESSEN am 2026-08-06 durch Vergleich beider Stände an PSA_0001. Beide holen 10 Kandidaten je Einheit (FINAL_TOP_K), aber es gibt viermal weniger Einheiten: 235 bewertete Kandidaten zeilenweise gegen 60 strophenweise, 146 gegen 50 verschiedene Ayets. Entscheidend: von den 36 im Golden Set erwarteten Ayets standen zeilenweise 12 überhaupt zur Wahl, strophenweise nur 6. Die AUSBEUTE ist dabei besser geworden (3 von 6 = 50 % gegen 4 von 12 = 33 %) - die Strophensuche wählt treffsicherer aus dem, was sie hat, sie bekommt nur zu wenig zu sehen.

Wie

FINAL_TOP_K je Strophe erhöhen (etwa Zeilenzahl x 5) und ROW_TOP_K mitwachsen lassen. Billig: das Embedding kostet Bruchteile eines Cents, und die Ranking-Stufe bewertet ALLE Kandidaten einer Einheit in EINEM Aufruf - mehr Kandidaten kosten dort also kaum mehr. Teurer würde nur, was danach ins Ergebnis geht (Reasoning + Prüfung je Ayet).

Noch offen

Gegen das Golden Set messen, nicht setzen. Ein Messlauf kostet jetzt 0,12 EUR. Die Frage ist, ob mehr Kandidaten auch mehr RICHTIGE bringen oder nur mehr Rauschen.

Ergebnis

Gekoppelt und gemessen: 4 richtige Ayets bei 0,14 EUR gegen 4 bei 0,40 EUR zeilenweise. Der Kostenvorteil des Strophenumbaus bleibt, der Trefferverlust ist aufgeholt. Die Qualitätsgrenze liegt nicht hier - alle drei Läufe verpassen über 30 der 36 erwarteten Ayets.

Der Nutzer erstellt parallel Analysen mit EINEM ausgearbeiteten Prompt je Werk - die dritte Meinung.

Warum

Angekündigt am 2026-08-06. Alles, was das Projekt bisher misst, misst es gegen sich selbst oder gegen 22 Golden-Set-Einträge aus einem einzigen Werk. Diese Analysen beantworten die Frage, die keine interne Messung beantworten kann: bringt das mehrschichtige Vorgehen überhaupt einen Mehrwert gegenüber einem gut gestellten Einzelprompt auf das ganze Werk? Falls nicht, wäre das das wichtigste Ergebnis, das dieses Projekt haben kann.

Wie

Ablage in input/vergleich/<autor>/<WERK_ID>__<titel>.json (siehe LIESMICH.md dort). Ein Importer liest die Ayet-Verweise, die Strophengliederung und die Begriffe heraus; vergleich_laeufe.py bekommt eine weitere Spalte. Bestätigte Zuordnungen können ins Golden Set.

Noch offen

Der Wert liegt in den UNTERSCHIEDEN, nicht darin, wer recht hat - die Referenz stammt auch aus einem Modell. Besonders aufschlussreich: findet sie Ayets, die unsere Pipeline nicht einmal als Kandidat hatte?

Ergebnis

vergleich_referenz.py stellt die 83 Referenzanalysen der Pipeline gegenueber - Gattung, Wegstation und Ayets. Verglichen wird NUR, was wirklich vergleichbar ist; die Deutungstexte bleiben aussen vor, weil zwei Prosatexte auf Aehnlichkeit zu pruefen eine Zahl erzeugt, die niemand nachpruefen kann. DER BEFUND, und er ist ernuechternd: 2 % UEBERSCHNEIDUNG bei den Ayets. Ueber drei analysierte Werke nennen beide Seiten zusammen 73 Verse und stimmen in 2 ueberein. Bei PSA_0001 ist die Schnittmenge LEER - die Pipeline nennt 19 Verse, die Referenz 6, und keiner davon ist derselbe. Die Referenz nennt dabei 2:196, also genau den Vers, den der Pruefer am 06.08. als inhaltlich richtig markiert hat. ⚠ EINORDNUNG: Die Referenz ist nicht die Wahrheit - sie stammt selbst von einem Modell, nur mit einem anderen Vorgehen (ein Werk am Stueck, ausgearbeiteter Prompt, kein Retrieval). Und die verglichenen Pipeline-Analysen stammen vom 04./06.08., also VOR allen Eingriffen dieses Tages (Lexikon, Ontologie, Konzepte, Kur'an-Deutung). Der Wert ist eine Ausgangsmessung, kein Urteil ueber den heutigen Stand. ZWEI EIGENE FEHLER beim Bauen, beide lehrreich: (1) Der erste Anlauf las die Ayets per Regex aus dem Fliesstext ('Name, Zahl') und fand NULL Treffer bei 83 Analysen - dabei liegen sie strukturiert in `ilgili_ayetler` vor. Ein Regex haette hier lauter Konzeptnamen eingesammelt ('Tevbe' kommt auch als fonksiyon vor) und dabei ausgesehen, als funktioniere er. Jetzt werden die FELDER gelesen: 931 Nennungen. (2) Der Vergleich meldete 'keine vergleichbaren Werke' bei der Gattung - weil der Reimport vom selben Tag sie geloescht hatte, siehe unten.

meaning_engine liefert je Zeile Deutung, Schlagworte und Symbole - gespeichert wird nur ein Teil davon.

Warum

Vom Nutzer gefordert (2026-08-06). Heute landen 'bedeutung' und 'schlagworte' je Analysezeile in der Wissensbasis, die 'semboller' gehen ins Glossar - aber alles hängt an der ANALYSE. Ein Werk ohne Analyse hat keine Bedeutungsebene, und bei einem Neulauf wird sie überschrieben. Sie ist aber Wissen über das Werk, nicht Beiwerk eines Laufs: sie gehört an das Werk selbst, versioniert, und kostet dann bei jedem weiteren Lauf nichts mehr.

Wie

Ein 'bedeutung'-Block am Werk (nicht in analysis), je Verszeile. Der Analyzer liest ihn, statt neu zu fragen, wenn der Text unverändert ist - dieselbe Logik wie die Re-Import-Sicherung im Deyiş-Importer.

Noch offen

Sinnvoll erst zusammen mit Aufgabe 39 (Versionierung) oder wenigstens mit einem Fingerabdruck des Werktextes.

Ergebnis

Die Bedeutungsebene liegt jetzt NEBEN `analysis` am Werk, als `bedeutungen`-Block mit Fingerprint des Werktextes - dieselbe Stelle und dieselbe Begruendung wie beim Kontext (#47): was eine Verszeile SAGT, haengt nicht davon ab, womit man sie hinterher vergleicht. Ein --no-resume wirft sie nicht mehr weg und bezahlt sie nicht neu; `bedeutungen_fuer()` ist der eine Einstieg, der entscheidet, ob ein Aufruf noetig ist. ZWEIFACH GEPRUEFT wird beim Lesen, und das ist der Kern: der Fingerprint des Werks UND die Zeilen selbst. Der Fingerprint allein genuegt nicht, weil die Zeilenzerlegung im Analyzer sitzt (split_lines) und sich aendern kann, ohne dass der Werktext sich aendert - dann waere jede Deutung um eine Position verschoben, saehe vollstaendig aus und nichts wuerde rot. Der Fingerprint ist ausserdem whitespace-normalisiert: der Virani-Reimport aenderte 795 auf 794 Zeichen ohne ein einziges anderes Wort, und ein Fingerprint, der darauf anspringt, verwirft bei jedem Reimport eine gueltige Deutung. 9 Tests.

Was für den Kur'an gerade läuft, fehlt für Ehl-i Beyt und die Kısas-Passagen.

Warum

Vom Nutzer gefordert (2026-08-06) und die Fortsetzung von Aufgabe 28. Die Kur'an-Deutung (interpret_quran.py) behebt den strukturellen Fehler auf der einen Seite: Bedeutung gegen Wortlaut. Für die 6836 Prosapassagen besteht er weiter - der Beleg-Rückfall sucht dort mit einer gedeuteten Deyiş-Zeile gegen ungedeutete Prosa.

Wie

interpret_quran.py ist die Vorlage: gebündelt, Zuordnung über die Nummer, Lücke statt Rateeintrag. Für Prosa braucht es andere Felder als 'lehre' - eine Passage erzählt, sie lehrt nicht immer. Vorschlag: worum es geht, welche Gestalt handelt, welche Lehre daraus folgt.

Ergebnis

Erledigt am 2026-08-07 durch interpret_passagen.py: 6480 von 6482 Passagen gedeutet (2 Luecken), GEMESSEN 1,7155 EUR - je Passage 0,00026 EUR. Je Passage zwei Saetze statt einem: WORUM es geht (macht sie wiederfindbar, ersetzt den incipit-Behelf) und die KERNAUSSAGE dahinter (macht sie mit einem Deyiş vergleichbar). Eingebettet wird nur die Kernaussage - die Zusammenfassung besteht weitgehend aus denselben Woertern wie der Wortlaut und wuerde das Gewicht der Handlung verdoppeln, statt Bedeutung hinzuzufuegen. 353 Apparat-Passagen (Vorwort, Register, Literaturverzeichnis) wurden vorher ausgeschlossen und gar nicht erst bezahlt. Aufgabe 28 und 59 waren dieselbe Arbeit.

Es stammt aus einem Pipeline-Lauf und misst deshalb Ähnlichkeit zur Pipeline, nicht Richtigkeit.

Warum

Am 2026-08-06 nachgewiesen. Die 22 Einträge kommen aus output/test.docx, einem Lauf vom 3.8., den der Nutzer als beste bisherige Fassung freigab - das war die richtige Entscheidung, um überhaupt einen Maßstab zu haben. Aber: an der Zeile 'Arafat dağında koçun bir eşi' führt das Golden Set 51:29 und 111:4, beide über das blosse Wort 'eş' (Gattin) gefunden und inhaltlich falsch. Die manuelle Prompt-Abfrage nennt 2:196 (Hac und Opfertier) und trifft damit genau - bekommt aber 0 Punkte. Jede Optimierung gegen dieses Golden Set optimiert also auf die Fehler der Pipeline hin.

Wie

Die 85 manuellen Referenzanalysen sind die Gegenprobe. Wo Pipeline und Referenz dasselbe Ayet nennen, ist die Zuordnung belastbar; wo sie auseinandergehen, entscheidet ein Mensch - und GENAU diese Fälle gehören ins Golden Set, nicht die, bei denen sich die Pipeline selbst bestätigt.

Noch offen

Das betrifft rückwirkend jede Messung dieser Woche. Die Trefferquoten von 14 bis 33 Prozent sind nicht falsch, aber sie messen etwas anderes als angenommen.

Ergebnis

`python bewerten.py --golden <bewertung.json>` uebernimmt ein menschliches Urteil in tests/golden_set.json. Das Set besteht jetzt zu 24 von 24 Eintraegen aus der Bewertung vom 06.08. (Ali Baris) statt aus output/test.docx. WARUM DAS DER UNTERSCHIED IST: Das alte Set stammte aus einem PIPELINE-LAUF und mass damit, wie aehnlich ein neuer Lauf dem alten ist - nicht, ob er richtig liegt. Der Beleg stand in ihm selbst: fuer 'Arafat dagi'nda kocun bir esi' fuehrte es ZARIYAT 51:29 und TEBBET 111:4, beide ueber das Wort 'es' (Gattin). Die Sachstelle ist BAKARA 2:196 (Hac, Opfertier) und bekam null Punkte. Jetzt steht dort 2:196. ZWEI DINGE WERDEN NICHT VERSCHWIEGEN: Die Oberflaeche kennt nur 'passt' und 'passt nicht', und der Pruefer hat vermerkt, dass er ab einem Punkt nur noch die passenden angeklickt hat. Nicht angeklickte Ayets gelten deshalb NICHT als 'kein Ayet gehoert hierher' - das waere der gefaehrlichste Kurzschluss, weil er die Trefferquote genau dort hebt, wo am wenigsten hingeschaut wurde. Und ein Abschnitt ohne einen einzigen Klick geht als `pending` ein: unbeurteilt, nicht negativ beurteilt. Ein menschliches Urteil ersetzt ein Pipeline-Urteil, nie umgekehrt. 6 Tests, darunter die Pruefung, dass jede Referenz in quran.json wirklich existiert - ein Tippfehler im MASSSTAB faellt sonst nur als schlechtes Ergebnis auf. GRENZE: 24 Eintraege aus EINEM Werk von einem Pruefer. Das ist ein Anfang, keine Stichprobe.

816 von 4091 Lexikoneinträgen (20 %) beginnen mitten im Satz.

Warum

Der Eintrag 'pir' beginnt mit 'rükûnlarını, farzlarını sünnetlerini ...' - der Anfang des Artikels fehlt. Betroffen sind 816 Einträge, erkennbar am Kleinbuchstaben am Anfang. Vermutlich verliert der Importer den Anfang dort, wo ein Artikel über einen Spalten- oder Seitenumbruch geht. Das wiegt schwerer als eine gewöhnliche Importlücke, seit lexikon.py das Lexikon als BELEGTE Quelle behandelt, die die eigene Vermutung schlägt: ein Fragment im Prompt liest sich wie eine vollständige Aussage.

Wie

lexikon.py überspringt sie derzeit (_artikelanfang_fehlt) - das ist ehrlich, kostet aber 20 % des Lexikons. Die Reparatur gehört in parse_terminologie_importer.py: Artikel über Umbrüche hinweg zusammenführen, bevor sie geschnitten werden.

Ergebnis

URSACHE: Der Band fuehrt jedes laufende Stichwort oben auf der Seite als KOLUMNENTITEL mit - fett, allein auf der Zeile, genau wie ein echtes Lemma. Der Importer las ihn als Stichwort, mitten im laufenden Artikel; dessen Rest landete unter dem falschen Lemma. Die Abwehr dagegen zaehlte Zeilen (pos > KOPFZEILEN), aber pos folgt der BLOCK-Reihenfolge, und der Kolumnentitel sitzt in einem eigenen Block, der oft nicht als erster kommt. ZWEI ANLAEUFE, und der erste war ein Rueckschritt: Position allein (y < 10 % der Seitenhoehe) kostete 89 ECHTE Lemmata - Allah, can, dar, dergah, dervis, deyis. Ein Lemma DARF am Seitenanfang stehen, nur ein Kolumnentitel MUSS es. Das eindeutige Merkmal ist die WIEDERHOLUNG: der Band fuehrt 'abdal' auf S. 17, 18, 19, 20 oben mit, ein Lemma steht genau einmal. Gepruefte Bedingung ist jetzt beides zusammen. ZWEI SCHRITTE, bewusst getrennt: der Importer ist konservativ (verliert lieber nichts), repair_terminologie.py raeumt danach nach. ERGEBNIS: 816 Fragmente -> 9. Kein Begriff verloren (3244 statt 3168). Nachschlagbare Schreibweisen 3140 -> 3574, davon 3192 aus dem gedruckten Lexikon statt 57 aus dem Glossar - vorher war es fast umgekehrt. Der Rest ist als #62 ausgelagert: 104 Begriffe haben KEINEN eigenen Artikel (text_fehlt), darunter 'pir' und 'Allah'. Ihr Text gehoerte nachweislich dem Vorgaenger; ihr eigener Artikel steht im PDF vor dem Umbruch und wird weiterhin nicht erfasst. Dazu ein eigenes Muster: 'can' hat einen BELEGVERS als Definition. Beides braucht einen tieferen Umbau des Importers.

Herkunft

Gemessen beim Bau von lexikon.py, 2026-08-06

Der Text, der die 40 Stufen ueberhaupt erklaert - liegt seit Beginn in input/.

Warum

Ohne ihn ist jede Stufe der Lern-App eine Zeile aus einem Lexikonartikel. Die Makâlât legt jede Stufe DAR und ordnet ihr Kur'an-Verse und Hadithe zu (so der Lexikonartikel TRM_0899) - das sind BELEGTE Verbindungen zwischen Yol und Kur'an, nicht errechnete. Fuer ein Projekt, dessen ganze Schwierigkeit im Finden solcher Verbindungen liegt, ist das die wertvollste einzelne Quelle, die noch nicht drin ist. Kapitel II/III = Şeriat, IV = Tarikat, V = Marifet, VI = Hakikat, also am Aufbau der Vier Tore entlang gegliedert.

Ergebnis

⚠ ERST MUSSTE SIE GELESEN WERDEN: Die PDF ist ein reiner Bildscan - 74 Seiten, je ein Graustufenbild, NULL extrahierbare Zeichen. Der Importer-Weg ueber die Textebene greift dort nicht. ocr_scan.py liest sie deshalb ueber ein Bildmodell, seitenweise und wiederaufsetzbar: 74 von 74 Seiten, 98.934 Zeichen, kostenlos.\n\nDabei zwei Befunde ueber die Freikontingente: sie gelten JE MODELL (gemini-3-flash-preview war nach 18 Seiten erschoepft, gemini-flash-lite-latest las weiter), und fuer OCR liefert das schwaechere Modell WORTGLEICH dasselbe bei einem Drittel der Zeit - Zeichenerkennung verlangt kein Urteilsvermoegen. Beim Urteilen waere ein Modellwechsel falsch, hier nicht.\n\nERGEBNIS: knowledge/yol.json, 83 Passagen. Kapitel III-VI tragen ihr TOR (Şeriat, Tarikat, Marifet, Hakikat) im eingebetteten Text. Und der Schatz, um dessentwillen das Ganze lief: 125 KUR'AN-BEZUEGE, 124 davon gegen quran.json aufloesbar, dazu 10 Hadith-Marken und 2 ausdrueckliche 'das ist weder Ayet noch Hadith'. Das sind ueberlieferte Verbindungen zwischen Yol und Kur'an - die einzigen im Projekt, die nicht aus einer Vektorsuche stammen.\n\nDer eine unaufloesbare Bezug ist aufgeklaert: '(Kur'ân XXXII/75)' zu einem Nuh-Zitat - Sure 32 hat nur 30 Ayets, gemeint ist Saffat 37:75. XXXVII wurde zu XXXII (Buchsatz oder OCR). Er bleibt als ok:false stehen statt still korrigiert zu werden.\n\n⚠ WIDERSPRUCH ZUR LEXIKONANGABE: TRM_0899 sagt, Bölüm II und III behandelten Şeriat. Das BUCH sagt: Bölüm II ist 'marifetin aslı', erst Bölüm III sind die Şeriat-Stufen. Massgeblich ist das Buch.

Herkunft

Befund beim Bau des Yol-Geruests, 2026-08-07

Die Prompts pruefen neutral, ob eine Beziehung besteht. Der Zweck ist ein anderer.

Warum

Der Nutzer hat ihn am 2026-08-07 in einem Satz formuliert: 'Deyişlerin Sözünü Kur'an Ayetleri Manasiyla Doğrulamak, Anlatılanın benzerini bulmak ve Ozanların Kur'an Bilgisini hervorheben. Dass hier keine Widersprueche entstehen.' Also: das Wort des Deyiş mit dem SINN der Ayets BESTAETIGEN, das Aehnliche des Erzaehlten finden, und die Kur'an-Kenntnis der Ozanen hervorheben. Die Prompts sagen heute etwas anderes. Der Ranking-Prompt macht das Modell zum 'tarafsız akademik uzman', der bewertet, OB eine Beziehung besteht; PROMPT_ROW laesst es zwischen DOGRUDAN und 'Bu ifade Kur'an'da birebir gecmez' waehlen - also zwischen woertlicher Deckung und Entschuldigung. Ergebnis: 51 von 107 Zeilen tragen gar keine Zuordnung. ⚠ DIE GEGENGEFAHR IST REAL und darf nicht weggewischt werden: ein Prompt, der Bestaetigung SUCHT, findet sie auch, wo keine ist - genau der Fehlermodus, gegen den dieses Projekt seit Wochen arbeitet. Die Aenderung betrifft die HALTUNG (der Ozan KANNTE den Kur'an, gesucht wird die Stelle, an der sein Wort gedeckt ist), nicht die Ehrlichkeit: 'kein Vers deckt das' muss weiterhin moeglich bleiben. Was faellt, ist die Bevorzugung woertlicher Deckung.

Ergebnis

Drei Prompts umgeschrieben (Ranking, Verbindungssatz, Genel Izlenim). Der Verbindungssatz benennt jetzt das GEMEINSAME PRINZIP statt zwischen 'DOGRUDAN' und 'Bu ifade Kur'an'da birebir gecmez' zu waehlen - beides mass am Lafz. Gemessen an PSA_0001 (mit gleichzeitig geaendertem Index und neuen Suchwegen, also NICHT isoliert): richtige Ayets in der Ausgabe 7 statt 11, richtige unter den Kandidaten 16 statt 14. Das Retrieval wurde besser, die AUSWAHL schlechter. ⚠ Unter den 'Fehltreffern' stehen HUCURAT 49:1 und 49:2 - genau die Verse, die der Nutzer in seiner Anmerkung zu PSA_0001#2 selbst verteidigt hat. Das Golden Set kennt sie nicht, weil seine 'unsicher'-Urteile bewusst nicht als Antworten gewertet werden.

Herkunft

Anmerkung des Nutzers zu PSA_0034#3, 2026-08-07

quran_index baute eigene Datensaetze und umging _quran_text vollstaendig.

Warum

Gefunden am 2026-08-07. `quran_index.build_or_load_index` setzte seine Datensaetze selbst zusammen - blanker Wortlaut, Metadaten nur sure/sure_name/ayet. Als am 06.08. die Deutungsebene in `_quran_text` aufgenommen wurde, aenderte das fuer main.py deshalb NICHTS: jeder Lauf baute den Index weiter ohne Deutung und ueberschrieb dabei sogar einen von Hand korrekt gebauten. Damit sind ALLE Messungen seit dem 06.08. gegen einen un-gedeuteten Index gelaufen, einschliesslich des Verlaufseintrags 'die Deutungsebene wirkt'.

Ergebnis

quran_index delegiert jetzt an knowledge_index.build_or_load; der zweite Bauplan ist geloescht. Zusaetzlich traegt jeder Cache eine TEXTMARKE - einen sha256 ueber den eingebetteten Text. Aendert sich die Deutung ODER die Zusammensetzung im Code, wird der Cache verworfen. Bewusst ueber den Text und nicht ueber den Zeitstempel der Quelldatei: sonst waere der Fall 'Daten gleich, Zusammensetzung im Code geaendert' wieder unsichtbar. Die Marke war es auch, die den Fehler aufgedeckt hat.

Herkunft

Befund beim Einbau der Textmarke, 2026-08-07

124 belegte Kur'an-Bezuege liegen im Korpus - die 40 Stufen kennen sie noch nicht.

Warum

yol_seed.py haelt die vierzig Stufen als Ueberschriften, yol.json haelt ihre Darlegung samt Versen. Beide wissen nichts voneinander. Zusammengefuehrt waere es ein VIERTER Suchweg: Deyiş-Zeile -> Makam -> die Verse, die Hacı Bektaş selbst dort nennt. Anders als die drei vorhandenen Wege ist dieser nicht errechnet, sondern ueberliefert - und damit der einzige, bei dem ein Treffer keine Vermutung ist.

Ergebnis

makamlar.py liest die vierzig Stufen aus der Makâlât selbst - 40 von 40, mit 32 Ayet-Belegen - und liefert sie als VIERTEN Suchweg ans Retrieval (found_via 'makam'). Eine Strophe mit tövbe/el alma/pir trifft Tarikat 1 und bekommt dessen 11 belegte Verse vorgelegt.\n\nVIER LUECKEN in der Extraktion gefunden, keine davon in der OCR: Belege ohne 'Kur'ân' davor; roemische MEHRFACHangaben (III/104, XI/71); ein Prophetenwort ohne (Hadis)-Marke; und ein VERRUTSCHTER ZIRKUMFLEX - das Buch schreibt einmal 'mâkamı' statt 'makâmı', wodurch Tarikat-Stufe 4 unbemerkt fehlte (39 von 40 sieht aus wie ein vollstaendiges Ergebnis).\n\nUND EIN FEHLER VON MIR: Hakikat-Stufe 10 bekam 16 Belege zugeschrieben, die in Wahrheit im Ârif-Dialog dahinter stehen. Einer Stufe Verse zuzuschreiben, die ihr das Buch nicht gibt, ist genau die Sorte Falschaussage, gegen die dieses Projekt gebaut ist.\n\nDANACH STIMMTE DIE RECHNUNG: Şeriat 10 + Tarikat 10 = exakt 20 Stufen mit Zeugen - genau was das Buch ueber sich selbst sagt ('yirmisi tanıklı, yirmisi tanıksız'). Marifet und Hakikat haben keine, weil sie hâl sind und nicht kâl.\n\n18 von 40 Stufen heissen im Buch ANDERS als im Lexikon. Beide Lesarten stehen nebeneinander, die Makâlât als Primaerquelle markiert.

Herkunft

Ergebnis des Makâlât-Imports, 2026-08-07

'Dieser Ayet spricht ueber İmam Ali' - die Verbindung, die kein Wortlaut herstellt.

Warum

Gedanke des Nutzers, 2026-08-07. Ein Deyiş singt von Şah-ı Merdan; der Vers, den die Imame auf Ali beziehen, sagt in seinem Wortlaut kein Wort von ihm. Wortlaut-, Bedeutungs- und Themensuche gehen alle drei daran vorbei.

Ergebnis

35 der 240 kommentierten Ayets haben eine Auslegung, die von İmam Ali spricht, 41 von der Ehl-i Beyt, 21 von İmam Bakır. Gesucht wird ueber die ONTOLOGIE (221 Beinamen), nicht ueber den Wortlaut.\n\nZWEI FALLSTRICKE, beide gemessen: 'Allah' steht in 228 der 240 Auslegungen - deshalb nur Personen/Gruppen/Orte, 18 taugliche Gestalten. Und wichtiger: 'die Auslegung nennt Ali' ist NICHT dasselbe wie 'der Vers handelt von Ali'. 7 Auslegungen nennen einen Offenbarungsanlass, 35 sagen 'hakkında', 184 sind blosse Zitate. Geordnet wird danach, ausgeschlossen wird nichts - und jeder Treffer traegt mit, WESWEGEN er da ist.\n\nDie Auslegung geht bewusst NICHT in den eingebetteten Text: dann wuerde ein Ayet ueber seinen Kommentar gefunden statt ueber sich selbst.

Herkunft

Idee des Nutzers, 2026-08-07

reasoning-Aufwand je Stufe konfigurierbar machen; Prüfstufe verbrennt 90 % ihrer Ausgabe fürs Denken.

Warum

Gemessen über drei Läufe: 89 %, 90 %, 90 %. 507 Ausgabe-Token je Aufruf für ein JSON mit fünf Feldern, auf dem teuersten Modell (30 $/1M). Hebel auf ~56 % der Gesamtkosten, ein einziger Parameter - keine Engine setzt ihn.

Noch offen

Die Prüfstufe ist die letzte Instanz vor dem Ergebnis. Nur gegen das Golden Set messbar ändern, mit Umgebungsvariable für den Vergleich.

Ergebnis

config.VALIDATION_EFFORT ('low'), als reasoning.effort an die Pruefstufe. Gemessen an einem Lauf waren 90 % ihrer Ausgabe Denk-Token, und sie war mit 0,33 von 0,40 EUR der teuerste Posten ueberhaupt. Sie beantwortet vier Ja/Nein-Fragen plus eine Zahl - eine Urteilsaufgabe, aber keine, die eine lange Ableitung braucht. Wer misst, dass die Urteile darunter leiden, setzt den Wert hoch: gemessen, nicht vermutet.

403 MB JSON-Text statt 75 MB binär - die Ladezeit, nicht die Suche, ist der Engpass.

Warum

llama-index speichert Vektoren als JSON-Text: ein float32 braucht 4 Byte, als Text stehen dort 20 Zeichen. 6101 Passagen x 3072 Dimensionen = 75 MB binär, 403 MB als JSON (Faktor 5,4). Beim Laden entstehen 18,7 Mio Python-Floats, rund 1 GB im Speicher; gemessene Ladezeit über 5 Minuten. Die Suche selbst braucht Millisekunden. Betrifft AUCH den Kur'an-Index (389 MB), der bei jedem Lauf geladen wird - ein erheblicher Teil der bisher der Analyse zugerechneten Laufzeit.

Wie

Vektoren als .npy (float32) plus schlanke Metadaten, Suche als Matrixprodukt in numpy. Verlustfrei, keine API-Kosten, Ergebnis unverändert. Eingriff nur in knowledge_index.build_or_load und retrieve. Die vorhandenen Caches lassen sich aus den gespeicherten Vektoren umschreiben, ohne neu einzubetten.

Noch offen

Vorher messen, wie lange der Kur'an-Index tatsächlich zum Laden braucht.

Ergebnis

knowledge_index.BinaerIndex: Vektoren als .npy (mmap), Suche als Matrixprodukt in numpy. Vorhandene Caches werden beim ersten Zugriff einmalig umgewandelt, ohne einen Embedding-Aufruf. GEMESSEN am Kur'an-Index: Ladezeit 529,9 s -> 0,08 s (Faktor 6682), Größe 398 MB -> 77 MB. VERLUSTFREI nachgewiesen: an 25 echten Verszeilen identische Trefferlisten, größte Abweichung im Ähnlichkeitswert 8,7e-05 (float32-Rundung). Nebenbefund: die 530 s gingen nicht fürs JSON-Parsen drauf (31 s), sondern für den Aufbau der Node-Objekte in llama-index.

Fünf Bände, drei davon sofort verwertbar - aber zwei passen in keines der bestehenden Korpora.

Warum

Geprüft am 2026-08-05. Caferi Mezhebi / Buyruk (274 S., sauberer Textlayer) ist Prosa wie der Ehl-i-Beyt-Korpus und braucht nur einen ehlibeyt_rules-Eintrag. Peygamberler Tarihi (773 S., Inhaltsverzeichnis mit 389 Einträgen) ist die beste Strukturquelle im ganzen Projekt und füllt eine Lücke, die weder Kur'an noch Ehl-i Beyt füllt: die Prophetenerzählung, auf die die Deyişe ständig anspielen (PSA_0027 heißt 'İsa Peygambere Hakkı buyurdu'). Ali Nihanî's manzum Velayetname (588 S.) hat einen ausgezeichneten Textlayer, steht aber in wissenschaftlicher Umschrift (√, ≥, µ, ¢) mit moderner Paraphrase daneben.

Entschieden

Nichts. Peygamberler Tarihi ist WEDER Deyiş NOCH Ehl-i Beyt - es als drittes Korpus zu führen ist eine Architekturentscheidung, die dem Nutzer gehört.

Noch offen

Makalat-ı Hacı Bektaş (74 S.) und Abdal Musa Velayetnamesi sind blockiert: Makalat hat gar keinen Textlayer (reiner Scan, braucht OCR), Abdal Musa hat einen, aber mit zerstörter türkischer Diakritik ('Uııın abdallan hırka 1ii postın') - unbrauchbar für semantische Analyse.

Ergebnis

Alle sechs offenen PDFs sind eingeordnet, und corpus_status.py nennt jetzt den PASSENDEN Importer statt pauschal den Deyis-Importer: ABDAL MUSA VELAYETNAMESI (280 S.) und CAFERI BUYRUGU (274 S.) sind PROSA und brauchen einen Prosa-Importer wie parse_ehlibeyt_importer; MAKALAT-I HACI BEKTAS (74 S.) ebenso (Lehrschrift); YEMININ FAZILETNAMESI (1165 S.) und ALI NIHANIS MANZUM VELAYETNAME (588 S.) sind in VERSEN und passen zum Deyis-Importer, brauchen aber page_start, weil eine Einleitungsstudie davorsteht; NESIMI_KITABI ist eine Aufsatzsammlung UEBER Nesimi, kein Werkkorpus - 'kein Importer' ist hier die richtige Antwort. ⚠ NEBENBEFUND: Das Terminologie-Lexikon wurde als 'offen' gemeldet, obwohl es seit dem 05.08. eingelesen ist - corpus_status kannte das Korpus nicht. Wer dem gefolgt waere, haette es ein zweites Mal importiert.

Die Warteschlange kennt einen Objekttyp; es warten jetzt 54 Entitäten.

Warum

Aus dem Audit (B5). Der Glossarpfad ist der einzige Ort, an dem eine Maschinenaussage ohne menschliches Urteil dauerhaft wird - ein direkter Widerspruch zum Prinzip, für das der ganze Review-Apparat existiert. Mit der Ontologie kommen 54 ungeprüfte Einträge und 10 Kollisionen dazu, die eine Entscheidung brauchen.

Noch offen

Der Formularmodus (HTML zum Weitergeben) müsste Entitäten mit abdecken - sonst kann nur am Terminal geprüft werden.

Ergebnis

`python review_queue.py objekte` zeigt ALLE pruefbaren Objekttypen nebeneinander statt nur die Analysezeilen: 41 Zeilen, 54 Entitaeten (dazu 82 Alias-Kollisionen als das Dringendste) und 16394 Graph-Kanten - zusammen 16489 Objekte. Ein Pruefstand, der nur einen Teil des Ungepruefen zeigt, sagt 'fertig', wo zwei Drittel offen sind. Je Typ steht der Befehl dabei; fuer die Kanten steht ehrlich '— noch kein Pruefwerkzeug' statt einer erfundenen Zahl.

Die Ontologie ist gebaut, aber analyzer.py fragt sie nicht.

Warum

Genau der Fehler, der beim Ehl-i-Beyt-Korpus schon einmal passiert ist: gebaut, angemeldet, nie abgefragt. Der Auflöser findet in 516 von 517 Werken Entitäten; diese Information geht heute nirgends in die Suche ein. Eine Zeile über 'Şah-ı Merdan' könnte über die Entität İmam Ali gezielt im Ehl-i-Beyt-Korpus suchen statt nur über Vektorähnlichkeit.

Noch offen

Erst nach Aufgabe 26 - solange die Aliase ungeprüft sind, würde eine falsche Zuordnung die Suche verfälschen statt sie zu verbessern.

Ergebnis

ontology.such_begriffe(text) loest die in einer Strophe genannten Personen und Orte auf und haengt ihre HAUPTNAMEN an die Bedeutungs-Suchanfrage. 'Sah-i Merdan Ali'nin yoluna girdim' liefert 'Imam Ali' - der Vers nennt den Beinamen, der Korpus den Namen, und ohne die Aufloesung begegnen die beiden sich nie. Vektoraehnlichkeit kann das nicht leisten: dass zwei Namen aehnlich klingen, sagt nichts darueber, ob dieselbe Person gemeint ist. DREI EINSCHRAENKUNGEN, jede mit Grund: nur Personen und Orte (die Glossarbegriffe stehen als Konzepte in der Ontologie, also stuende sonst unter jeder zweiten Zeile 'Dem, Yol, Can' - Woerter, die in der Anfrage ohnehin schon stehen); hoechstens vier Namen (eine Anfrage mit zehn Namen sucht nach NAMEN statt nach Inhalt); und ein woertlich schon dastehender Name wird uebersprungen, weil er sonst sein eigenes Gewicht verdoppelt. Eine fehlende ontology.json haelt die Suche nicht an. 8 Tests, darunter der Nachweis der Verdrahtung selbst - ohne ihn waere such_begriffe eine Funktion, die niemand ruft, also genau der Zustand, den diese Aufgabe beheben sollte. NICHT GEMESSEN: ob es die Trefferquote hebt. Das braucht einen Lauf und den Vergleich mit der Bewertung vom 06.08.

Statt einer Zahl: Parser, Entität, Beziehung, Modell und Mensch getrennt - Gesamtwert wird berechnet.

Warum

Punkt 3 der Erweiterung. Heute steht in jeder Zeile EIN 'confidence', das vom Prüfmodell kommt. Damit ist nicht zu unterscheiden, ob eine Zuordnung unsicher ist, weil der Scan schlecht war, weil der Name mehrdeutig ist oder weil das Modell zweifelt - und das sind drei völlig verschiedene Probleme mit drei verschiedenen Abhilfen.

Wie

Bestehendes Feld bleibt (Rückwärtskompatibilität), daneben ein Block mit den Einzelwerten. AUTO_APPROVE_CONFIDENCE rechnet dann über die Formel statt über die eine Zahl.

Noch offen

Die Gewichtung der Dimensionen ist zu kalibrieren, nicht zu setzen - also nach Aufgabe 7.

Ergebnis

Fuenf Dimensionen statt einer Zahl: parser, entitaet, beziehung, modell, mensch. 0,62 konnte bisher heissen 'sauber gelesen, Zuordnung wacklig' ODER 'Zuordnung sitzt, Scan schlecht'. ZWEI REGELN: (1) Ein MENSCHLICHES Urteil wird nicht eingerechnet, es ENTSCHEIDET. (2) Gemittelt wird nur ueber die GESETZTEN Dimensionen, neu normiert - eine fehlende Angabe als 0 zu zaehlen wuerde jede unvollstaendige Zeile als unsicher ausweisen, obwohl ueber sie nur weniger bekannt ist. Kein zusaetzlicher Aufruf.

Widersprechen sich zwei verlässliche Quellen, bleiben BEIDE Aussagen stehen - mit Konfliktobjekt.

Warum

Punkt 4 der Erweiterung, und für eine wissenschaftliche Wissensbasis der Kern: Gelehrtenstreit ist Information, kein Fehler. Ein System, das den Widerspruch auflöst, indem es eine Seite wegwirft, verfälscht seinen Gegenstand.

Wie

Der Ansatz existiert schon: review_queue meldet zwei sich widersprechende Prüferurteile, statt das zweite zu überschreiben ('Zwei Verdikte auf derselben Zeile sind die interessanteste Information, die es gibt'). Dasselbe Prinzip auf Wissensaussagen ausgeweitet: Konfliktobjekt mit Aussage A, Aussage B, Grund, Belegen beider Seiten und optionaler Prüferentscheidung.

Noch offen

Setzt Aufgabe 25 voraus - solange eine Aussage kein eigenständiges Objekt ist, kann sie nicht in einem Konflikt stehen.

Ergebnis

konflikte.py: 53 Widersprueche in knowledge/konflikte.json. Ein Konfliktobjekt fuehrt BEIDE Aussagen mit ihrer Quelle und ein Feld fuer die Entscheidung - die auch 'beides gilt' lauten darf. Kein vorbelegtes 'richtig': das wirkt bei der Durchsicht als Vorentscheidung. DER EIGENTLICHE FUND war, dass es zunaechst nichts zu finden gab: build_ontology hat die zweite Beschreibung VERWORFEN - es gewann, wer zuerst da war. Jetzt wandert die verdraengte Aussage in den BELEG. Erst dadurch wurden die 53 sichtbar, darunter 'Ab-ı hayat' (Glossar gegen Lexikon) und 'Ahad' (Esmâ gegen Lexikon).

Beleg als eigenes Objekt: Quelle, Seite, Absatz, Zeilenbereich, Originaltext, später Bildkoordinaten.

Warum

Punkt 2 der Erweiterung. evidence.py führt bereits Werk, Seite und Zeilenbereich - für den Deyiş-Teil. Ein Beleg aus einem Prosakorpus trägt heute nur Band und Seite; von einer Antwort zurück zur genauen Stelle im Original kommt man damit nicht.

Wie

Vorhandene Felder bleiben, der Beleg wird ein eigenes Objekt mit ID. Der Originaltext gehört dazu: er ist der Beweis, dass die Stelle nicht nachträglich verrutscht ist.

Noch offen

Bildkoordinaten erst, wenn OCR ins Spiel kommt (Yemini, Makalat).

Ergebnis

evidence.beleg() als eigenes Objekt: quelle, art, seite, absatz, zeilen, WORTLAUT, guete. Bisher war ein Beleg das, was der jeweilige Fundort mitbrachte - drei Formen fuer dieselbe Sache. `beleg_ist_nachschlagbar()` ist der Kern: Quelle allein genuegt nicht, 'Nehcü'l-Belâğa' ist ein Buch mit 700 Seiten. Der Wortlaut zaehlt als Ortsangabe - wer ihn mitliefert, hat die Stelle mitgeliefert.

Fünf Importer, keine gemeinsame Beschreibung dessen, was ein Korpus ist.

Warum

Punkt 9 der Erweiterung und Befund B7 des Architektur-Audits - die Schuld ist beim Kısas-Korpus GRÖSSER geworden, nicht kleiner. Ein neues Korpus soll eine Konfiguration sein, kein neues Modul.

Wie

Ein Korpus beschreibt: seine atomare Einheit, seine Metadaten, sein Schreibziel, seine Strukturquelle. Die vorhandenen Bausteine (PDFReader, PageCleaner, PassageBuilder) bleiben - nur der Rahmen wird gemeinsam.

Noch offen

Nicht dringend, solange Gattungen selten dazukommen. Der Punkt, an dem die Abstraktion billiger gewesen wäre als der sechste Importer, ist aber absehbar.

Ergebnis

korpus_register.py BESCHREIBT, was ein Korpus ist - es importiert nicht. Der Unterschied ist die ganze Entscheidung: die fuenf Importer funktionieren, sind getestet und haben je einen guten Grund fuer ihre Eigenheiten (Vers gegen Prosa, Passage gegen Eintrag). Sie durch eine gemeinsame Maschine zu ersetzen hiesse, fuenf funktionierende Sachen gegen eine ungetestete zu tauschen. Was fehlte, war die gemeinsame BESCHREIBUNG: 6 Korpora mit atomarer Einheit, Struktur, Importer, Regelmodul, Pflichtangaben - plus die 5 ABLEITUNGEN (Graph, Ontologie, Synonyme, Konflikte, Glossar), damit niemand fuer relations.json einen Importer sucht. `--pruefen` findet sofort: 304 von 3725 Terminologie-Eintraegen ohne Text.

Sieben Abschnitte je Deyiş statt einer zweispaltigen Tabelle Zeile↔Vers.

Warum

Vom Nutzer gefordert: 'Der Leser soll nie das Gefühl haben, eine Datenbank zu lesen.' Heute zerreißt die Tabelle das Gedicht in 24 Zeilenpaare; der geistige Zusammenhang geht verloren. Neu: Einleitung (Autor, Gattung, Anlass), vollständiges Deyiş UNUNTERBROCHEN, Gesamtdeutung, dann Strophe für Strophe mit Kernaussage, alevitischer Deutung, Begriffstabelle, Kur'anischen Prinzipien, Ayet-Tabelle und hermeneutischem Kommentar, zuletzt Zusammenfassung, Wissensnetz und Schluss.

Wie

docx_writer wird neu geschrieben. Die Daten dafür entstehen in 46-49; ohne sie wäre das Format leer. Das Wiki bekommt dieselbe Gliederung.

Noch offen

Erst nach 46-48, sonst gibt es nichts zu füllen. Das alte Format bleibt als --format tabelle erhalten, damit die bisherigen Ergebnisse lesbar bleiben.

Ergebnis

docx_buch.py als ZWEITES Format neben docx_writer.py, waehlbar ueber --format buch (Vorgabe bleibt 'tabelle', damit alte und neue Laeufe vergleichbar lesbar bleiben). Sieben Abschnitte je Deyis: Einleitung (Dichter, Gattung samt Begruendung, Anlass, Station, Zweck, Wandlung, Seite) - das Deyis VOLLSTAENDIG und ununterbrochen, ohne Zeilennummer und ohne Verweis daneben - Gesamtdeutung - Strophenanalyse (Kernaussage, kur'anische Prinzipien, Begriffstabelle nur mit den Begriffen DIESER Strophe, Ayet-Tabelle, hermeneutischer Kommentar zuletzt) - Zusammenfassung mit ausdruecklich benannten Luecken - Wissensnetz aus relations.Graph.werk() - Nachweis mit Modellen, Datum und Pruefstand. Neue Methode relations.Graph.werk(werk_id): die Kanten haengen an den Zeilen, nicht am Werk; wer das Werk als Ganzes braucht, musste die Schluesselform bisher von Hand nachbauen. Neun Tests halten fest, was das Dokument nicht darf: das Gedicht kuerzen, eine Luecke verschweigen, eine maschinelle Freigabe wie ein Urteil aussehen lassen, oder das Tabellenformat brechen.

relations.json trägt noch die Entitätsnamen von vor dem Lexikon-Zufluss.

Warum

Beim Einspeisen des Lexikons am 2026-08-06 hat ein Test die Abhängigkeit korrekt aufgedeckt: build_ontology -> enrich_passages -> build_relations ist eine KETTE. Die Anreicherung wurde nachgezogen, der Kantenaufbau nicht - er dauert länger und stand am Ende der Sitzung. Die Kanten sind nicht falsch, aber sie kennen die 368 neuen Entitäten noch nicht.

Wie

python build_relations.py. Danach die Kette in CLAUDE.md festhalten, damit die Reihenfolge nicht wieder nur ein Test weiss.

Ergebnis

22557 Kanten (+2643), 534 Entitäten in Deyişen. Nebenbefund: 12 überhäufige Entitäten, 7 davon vorher unprüfbar - jetzt mit Häufigkeitswarnung im Formular.

41 % der Werke haben keine Leerzeilen - dort ersetzt ein Behelf die echte Strophe.

Warum

Gemessen am 2026-08-06: Pir Sultan Abdal (Antoloji) 214 von 214 Werken einstrophig, Şah Hatayi 71 von 195, Pir Sultan Abdal 10 von 84. Kul Himmet, Nesimi und Virani sind sauber gesetzt - es liegt also am Importer bzw. an der Quelle, nicht am Verfahren. Solange greift in analyzer._uebergrosse_teilen ein Behelf mit Blöcken von 4 Zeilen; er ist als 'behelfsteilung' markiert, aber eine geratene Grenze bleibt eine geratene Grenze.

Wie

Prüfen, ob die Antoloji-Quelle im PDF überhaupt Strophenabstände hat (dann ist es der PageCleaner) oder ob sie durchgehend setzt (dann hilft nur das Reimschema oder die Zeilenzahl je Gedichtform).

Noch offen

Ein falsch gesetzter Strophenschnitt verschiebt jede Zuordnung in diesem Werk. Vor einem breiten Analyselauf klären.

Ergebnis

URSACHE GEFUNDEN: Die Strophengrenze steht im PDF sauber drin - 12,0 pt Zeilenabstand innerhalb der Strophe, 24,0 dazwischen. Der Importer MASS das auch schon, aber nur wenn ein min_font_size gesetzt war; sonst fiel er auf page.get_text('text') zurueck, und dessen Ausgabe kennt keine Leerzeile. Die Strophengliederung hing also an einer Regel, die einen ganz anderen Zweck hat (Fussnoten filtern) - und ein Band ohne Fussnoten bekam keine Strophen. Beides ist jetzt entkoppelt: gemessen wird immer, gefiltert nur wo eine Grenze gesetzt ist. ERGEBNIS: 41 % ohne Gliederung -> 16 %. Antoloji 214 -> 1, Virani 4 -> 0 (ein Gazel in Beyits, jetzt 7 Grenzen statt keiner). Keine Analyse ging dabei verloren. OFFEN bleibt Sah Hatayi mit 71 von 195. Dort ist min_font_size gesetzt, die Messung laeuft also - und greift trotzdem nicht, obwohl die Abstaende im Scan klar sind (11,5-12,0 innerhalb, 23,0-23,3 dazwischen). Der Rohtext einer Beispielseite hat nur 1 Leerzeile. Eigener Fall, eigene Messung noetig. Dazu 10 von 84 bei Pir Sultan Abdal - ungeprueft, ob echte Einstropher oder derselbe Fehler. || WEITER UNTERSUCHT 06.08.: Bei Şah Hatayi liegt es NICHT am PDFReader. Gemessen an S. 96/97: Median-Zeilenabstand 11,8, Grenze 16,5, Strophenabstand 23,3 - die Messung greift, und die Rohdatei hat auf 145 von 182 Seiten Leerzeilen. Sie gehen also erst im WorkBuilder verloren, obwohl der mit '\n\n' zusammenfuegt. Die genaue Stelle ist offen; Verdacht auf `_an_titeln_teilen`, das die Zeilen eines Blocks mit '\n' neu verbindet. || GELOEST 06.08.: Bei Şah Hatayi war es KEIN Importer-Fehler. Die 71 Werke ohne Strophengrenze sind GAZELE - in Beyits gebaut, Zweizeiler mit durchgehendem Reim auf der zweiten Zeile (aa xa xa). Der Band setzt zwischen ihnen keinen Abstand, weil es dort keine Strophengrenze GIBT. Der Behelf schnitt trotzdem Viererbloecke und verband damit je zwei Beyits, die nichts miteinander zu tun haben. analyzer.ist_beyit_form() erkennt die Form am ENDREIM: reimt jede zweite Zeile, ist die Einheit der Beyit. Gefordert sind mindestens vier Zeilen und drei uebereinstimmende Endungen - zwei sind Zufall, gerade im Tuerkischen, wo die Endungen einander ohnehin aehneln. Der REDIF zaehlt mit ('senin olsun' ist ein wiederholtes Wort, keine Silbe). 54 der 71 Hatayi-Werke sind so erkannt. Ein Vierzeiler wird korrekt NICHT als Gazel gelesen - die Gegenprobe ist wichtiger als der Nachweis, denn eine Erkennung, die ueberall anschlaegt, halbiert jeden Vierzeiler. Die Teilung greift jetzt UNABHAENGIG von STROPHE_MAX_ZEILEN: ein sechszeiliges Gazel sind drei Beyits, nicht eine Einheit. Die Obergrenze ist ein Notbehelf gegen zu grosse Bloecke, kein Formmerkmal. Das Feld `form` unterscheidet im Ergebnis beyit von doertluek.

Ob zwei Begriffe dasselbe meinen, darf nicht geschätzt werden - das Lexikon weiß es.

Warum

Vom Nutzer angestoßen (2026-08-06): Ich hatte beim Vergleich zweier Läufe behauptet, 'merhamet' und 'mağfiret' seien Synonyme. Sie sind es nicht - Barmherzigkeit und Vergebung sind verwandt, aber verschieden, und 'marifet' (Erkenntnis, eines der Vier Tore) ist etwas ganz anderes. Die Aussage war unbelegt und genau die Sorte Ungenauigkeit, die sich in eine Wissensbasis einschleicht.

Wie

knowledge/terminologie.json führt 4091 Einträge mit Definitionen und 490 belegte Querverweise (bk.). Damit lässt sich prüfen, ob zwei Schlagworte derselben Entität zugehören - ohne Online-Dienst und ohne Modellaufruf. Einsatzorte: der Vergleich zweier Läufe, die Zusammenführung von Schlagworten, und später die semantische Ähnlichkeit (Aufgabe 38).

Noch offen

Wo das Lexikon schweigt, bleibt die Frage offen - dann ist 'unbekannt' die richtige Antwort und nicht 'ähnlich'.

Ergebnis

lexikon.py: eine reine Nachschlageschicht ueber Terminologie (3257 Begriffe mit Seitenzahl), Ontologie (673 Entitaeten samt Aliasen) und Glossar. KEIN Modellaufruf - sie liest knowledge/*.json. meaning_engine legt die im Werk vorkommenden Fachbegriffe mit ihrer belegten Definition VOR das Gedicht, und der Prompt sagt ausdruecklich, dass diese Angaben belegt sind und der eigenen Vermutung vorgehen. ANLASS war die Bewertung von PSA_0001: in 13 von 24 Abschnitten passte kein Vers, und die Notizen nannten den Grund - 'kemerbest bedeutet einen Guertel um die Lende setzen um nefs zu besiegeln'. Genau das stand seit dem 05.08. im Lexikon, und die Bedeutungsstufe sah es nie. ZWEI FUNDE BEIM BAUEN: (1) Die Rangfolge stand zuerst falsch herum - das Glossar oben, weil es 'von Hand geprueft' sei. Ist es nicht: es ist die AUSGABE von meaning_engine. Die Stufe haette bei ihrer eigenen frueheren Vermutung nachgeschlagen und sie fuer einen Beleg gehalten. Der Zirkelschluss lief ausserdem ueber die Ontologie weiter, weil build_ontology die Glossarbegriffe als Konzepte einzieht - Entitaeten, deren einziger Beleg 'Analyse' ist, zaehlen jetzt als Glossar. (2) 816 der 4091 Lexikoneintraege (20 %) haben ihren Artikelanfang verloren - siehe neue Aufgabe. 23 Tests. NOCH NICHT GEMESSEN: ob die Deutung dadurch besser wird. Das braucht einen Lauf ueber PSA_0001 und den Vergleich mit der vorliegenden Bewertung.

Alle neun Prompts auf einer Seite, live aus den Modulen gelesen.

Warum

Vom Nutzer gefordert (06.08.). Die Prompts SIND das Programm dieses Projekts - der Python-Code holt Daten und schreibt Dateien, was gefragt wird steht in neun Zeichenketten ueber neun Module verteilt.

Ergebnis

output/prompts.html: alle neun Prompts LIVE aus den Modulen gelesen, in der Reihenfolge der Pipeline, je mit Modell, Aufrufzahl und dem, was hinein- und herausgeht. Dazu ein Flussbild in reinem HTML - bewusst nicht Mermaid oder PNG, weil die Seiten aus einer Datei heraus laufen muessen (file://) und ein Bild veraltet, ohne dass es jemand merkt.

Herkunft

Auftrag des Nutzers, 2026-08-06

bewerten, lexikon, suche, konflikte, quellen, lernschicht und 13 weitere stehen nirgends beschrieben.

Warum

Die Datei endet inhaltlich am Vormittag des 06.08. Ein Modul, das dort nicht steht, ist ab der naechsten Sitzung unauffindbar - und wird ein zweites Mal gebaut.

Ergebnis

Abschnitt 'Tools added 2026-08-06/07' am Ende von CLAUDE.md: alle 26 undokumentierten Module, gruppiert nach Zweck statt einzeln aufgezaehlt, mit den Befehlen fuer die neuen. Die Trennung laeuft nach DATUM, nicht nach Wichtigkeit - das ist ehrlicher als eine Einarbeitung, die so tut, als sei alles gleichzeitig entstanden.

Herkunft

Befund der Zustandsaufnahme, 2026-08-07

Ein Zugang, viele Häuser - und die vier Stufen einzeln umschaltbar.

Warum

Die Zweitmeinung hat gezeigt, dass ein fremdes Haus etwas sieht, was die eigene Pruefstufe nicht sehen kann. OpenRouter macht daraus keine Ausnahme, sondern eine Einstellung: ueber EINEN Schluessel sind Anthropic, Google, Mistral, Qwen und offene Modelle erreichbar. Guenstig ist der Umbau, weil die Schnittstelle OpenAI-kompatibel ist - es fehlt nur die base_url je Stufe.

Ergebnis

zweitmeinung.py hat jetzt ZWEI Kontrolleure: Google und OpenRouter, ueber eine Anbieter-Tabelle statt zweier Codepfade. OpenRouter spricht die OpenAI-Schnittstelle, deshalb reichte ein anderer Endpunkt - kein zweites SDK. `--anbieter openrouter --modelle` listet die kostenlosen (17 am 07.08.); eine feste Modellvorgabe gibt es bewusst NICHT, weil sich staendig aendert, was gratis ist. Wer keinen Schluessel hat, wird UEBERSPRUNGEN statt zum Abbruch gebracht - ein Kontrolleur ist besser als keiner. Die Urteile stehen als Liste an der Zeile (`zweitmeinungen`); die alte Einzelform der 16 vorhandenen Urteile wird in `meinungen_von()` eingereiht statt migriert. Sind sich die beiden uneinig, sagt das Pruefformular es ausdruecklich - das ist die staerkste Aufforderung hinzusehen, die das System erzeugen kann.

Herkunft

Idee des Nutzers, 2026-08-07

Die Ordensregel - im Lexikon als zweite Autoritaet der Vier Tore genannt.

Warum

TRM_0899: 'Buyruk'ta pirlerin dört kapı-kırk makam'ı bilmesi ve bunu taliplere ögretmesi gerektigi ... belirtilir.' Der Buyruk sagt also, dass der Pir die Tore lehren MUSS - er ist die Quelle fuer das Erkân, wo die Makâlât die Lehre gibt.

Ergebnis

346 Passagen, 68 Kur'an-Bezuege, alle 68 aufloesbar. Der Importer kann jetzt auch TEXTEBENEN lesen, nicht nur OCR - gegliedert ueber die Schriftgroesse (Fliesstext 10,5pt, Abschnitte 11pt).\n\nVIER REPARATUREN, drei davon haetten stillen Schaden angerichtet:\n(1) Der Buyruk bekam TORE zugewiesen, die er nicht hat - die Tabelle 'Kapitel 3-6 = die vier Tore' galt global, der Buyruk numeriert aber fortlaufend. Sein 17. Kapitel ueber İçtihat wurde so zu einem Tor.\n(2) 264 Seiten wurden zu 120 Passagen: die Textebene hat keine Leerzeilen, ein ganzes Kapitel ist EIN Absatz. Jetzt wird an Satzgrenzen nachgeteilt.\n(3) Silbentrennung am Zeilenende blieb stehen ('de-\\nnilmektedir').\n(4) Er zitiert ANDERS als die Makâlât: 'Bakara (2), 258.' statt '(Kur'ân II/258)'. Mit den alten Mustern: null Belege in 264 Seiten, was nach einem leeren Buch aussah.

Herkunft

Befund beim Bau des Yol-Geruests, 2026-08-07

api_usage sieht sie nicht - llama-index ruft OpenAI direkt.

Warum

Am 2026-08-07 aufgefallen: die gemessenen Kosten des Tages ergaben 2,20 $, das Dashboard 3,08 $. Der groesste Teil der Differenz ist der Indexneubau der Prosa-Korpora - 9,69 Mio Zeichen, mit tiktoken nachgemessen 4,00 Mio Token, also 0,52 $. Er taucht in keiner Abrechnung des Projekts auf, weil Embedding-Aufrufe ueber llama-index laufen und api_usage.record nie sehen. Solange das so ist, ist jede Kostenaussage dieses Projekts zu niedrig.

Ergebnis

api_usage.record_embedding verbucht jetzt Indexaufbau und Suchanfragen. GEZAEHLT, nicht geschaetzt: ein Embedding-Aufruf hat keine Ausgabe-Token, die Rechnung ist Eingabe x Preis, und die Eingabe liegt vor dem Aufruf vollstaendig vor. Mit tiktoken gezaehlt ist die Zahl exakt - genauer als ein usage-Feld, das es hier gar nicht gibt. Faellt tiktoken aus, bleibt der Posten UNGEZAEHLT und meldet sich als solcher, statt eine erfundene Zahl in die Abrechnung zu schreiben. kosten.gemessen() bepreist die neuen Stufen ohne Aenderung.

Herkunft

Abgleich mit dem OpenAI-Dashboard, 2026-08-07

MIN_RANKING_SCORE: liegt das beste Ranking darunter, direkt in die Lücke - ohne Reasoning und Prüfung.

Warum

Die Ranking-Stufe fällt bereits ein Relevanzurteil, die Prüfstufe beurteilt dieselbe Frage noch einmal. Bei einer Zeile mit bestem Ranking 25 ist absehbar, dass sie in der Lücke landet - bezahlt sind bis dahin die zwei teuersten Aufrufe.

Noch offen

40 ist eine Setzung, keine Messung. Punktzahlen sind nicht modellübergreifend vergleichbar. Lückengrund als no_match_reason festhalten.

Ergebnis

config.MIN_RANKING_SCORE (25 von 100): liegt der beste Ranking-Wert einer Strophe darunter, geht sie direkt als Luecke durch - ohne Reasoning und ohne Pruefung, also zwei gesparte Aufrufe fuer eine Zeile, die ohnehin verworfen wuerde. Bewusst NIEDRIG: die Schwelle soll das Aussichtslose abschneiden, nicht die Auswahl treffen. Wer sie hochzieht, spart mehr und entscheidet dabei still ueber Zuordnungen, die ein Mensch haette sehen sollen. FEHLT die Bewertung - etwa weil der Ranking-Aufruf scheiterte und die Embedding-Reihenfolge stehen blieb -, wird NICHT abgeschnitten: eine fehlende Bewertung ist keine schlechte. 0 schaltet ab.

Herkunft

Teil D

Wenn die neuen Quellen eingelesen sind: einen Weg finden, die Inhalte verständlich zu durchsuchen.

Warum

Vom Nutzer angekündigt. Zusammenführung des Wissens soll über den dynamischen Sözlük laufen - das Glossar wird damit von einem Nebenprodukt zum Bindeglied zwischen den Korpora.

Noch offen

Noch nicht ausgestaltet; der Nutzer bringt dazu mehr.

Ergebnis

`python suche.py ikrar` bringt zusammen, was bisher in fuenf Dateien lag: die belegte Definition mit Seitenzahl, die Nebenformen, 122 Verszeilen aus den Deyişen mit Werk und Zeilennummer, 1 Ayet, 110 Prosastellen mit Band und Seite, die Nachbarn im Graphen. DER SÖZLÜK ALS BINDEGLIED, wie vom Nutzer gefordert: der Begriff ist der natuerliche Einstieg in diese Wissensbasis - nicht die Werk-ID und nicht die Passage. Das war die Klage vom 05.08.: 'hier ist das Wissen ein riesen Text aber dann mit IDs die nicht leicht suchbar sind'. KEINE Modellaufrufe und KEINE Einbettung: gesucht wird exakt, mit tuerkischer Faltung und ueber die BELEGTEN Gleichsetzungen. Wer 'merhamet' sucht, soll nicht 'magrifet' bekommen.

12 von 19 Bänden haben eine Kapitelangabe, mit der man nichts nachschlagen kann.

Warum

Gemessen (output/wiki/pruefung.html): Bände mit PDF-Inhaltsverzeichnis kommen auf 3 Passagen je Kapitel, Bände aus Kolumnentiteln auf 10 bis 128. Sahîfe-i Aleviyye: 2 Kapitel für 255 Passagen, eines heißt 'I'. Hz. Abbas: 'Birinci Fasıl:' für 61 Passagen. Die Kapitelangabe wandert als Herkunft in jede Zuordnung und steht später neben dem Vers - eine Passage ohne belegbare Fundstelle ist zwar auffindbar, aber nicht zitierbar.

Wie

Die fettgesetzten Zwischenüberschriften im Text nutzt parse_ehlibeyt_importer.py heute nur als zweite Priorität. Bei den Kolumnentitel-Bänden sind sie die einzige feine Struktur, die es gibt.

Noch offen

Kein Datenverlust, nur eine schlechte Fundstellenangabe - deshalb nicht dringend. Schreibt ehlibeyt.json neu, also vor dem nächsten Lauf mit Ehl-i-Beyt-Rückfall erledigen, nicht danach.

Ergebnis

Jede der 6836 Prosapassagen traegt jetzt eine ZITIERHILFE: 'Sahîfe-i Aleviyye, Kap. I, Abschnitt 7 von 255, S. 44' plus die fuehrende Figur, die seit enrich_passages.py dasteht und nie benutzt wurde. WAS DAS NICHT IST: eine inhaltliche Gliederung, und es gibt auch nicht vor, eine zu sein. Die Ursache liegt im BAND, nicht im Importer - diese Baende haben kein PDF-Inhaltsverzeichnis, und die Kapitel wurden aus Kolumnentiteln gelesen, die ueber hunderte Seiten gleich bleiben. Eine echte Gliederung braucht ein Modell und Geld (#28). Was jetzt geht, ist das, woran es bisher scheiterte: die Stelle EINDEUTIG benennen. 11 der 19 Baende hatten Kapitel mit ueber 8 Passagen, Sahîfe-i Aleviyye 255 in zweien.

Nach jeder Quelle: was ist neu an Personen, Konzepten, Aliasen, Beziehungen, Konflikten?

Warum

Punkt 6 der Erweiterung. Erst dadurch wird der Satz aus der Vision überprüfbar, dass das System mit jeder Quelle klüger wird - heute wird es mit jeder Quelle nur größer.

Wie

build_ontology.py gibt bereits einen solchen Bericht aus (belegt/neu/verschmolzen/geschützt). Er ist nur flüchtig - er gehört als Datei in die Projektgeschichte, wie backlog.json.

Noch offen

Setzt die Lernschicht voraus (Aufgabe 36) - sonst berichtet er nur über die Ontologie.

Ergebnis

wissensbericht.py vergleicht zwei Staende der Wissensbasis: was ist neu, was ist ENTFALLEN, was hat eine andere Beschreibung bekommen. Braucht keinen Haken im Importer und funktioniert rueckwirkend, weil knowledge/backups/ die Vorfassungen aufhebt. ERSTER BEFUND, sofort: beim Lexikon-Zufluss in die Ontologie sind 11 Entitaeten ENTFALLEN - dervis, dergah, kurban, cemal, fehm, muerebbi. Glossarbegriffe, von gleichnamigen Lexikoneintraegen verdraengt. Genau der stille Verlust, fuer den das Werkzeug da ist: der Import meldete nur Zuwachs. Die 233 GEAENDERTEN Beschreibungen sind der Fall, der eine Entscheidung braucht - eine Quelle sagt etwas anderes ueber etwas Bekanntes (Backlog #32).

Beim Import werden neue Entitäten, Aliase und Beziehungen vorgeschlagen - alles in die Prüfung.

Warum

Aus dem Audit (B5) und Punkt 6 der Erweiterung. Der einzige Ort, an dem heute etwas Neues entsteht, ist das Glossar - und der umgeht die Prüfung.

Noch offen

Setzt Aufgabe 26 (Prüfung für weitere Objekttypen) voraus.

Ergebnis

lernschicht.py leitet aus dem Bestand VORSCHLAEGE ab - ohne Modellaufruf. Nebenformen (Definitionen zu >=75 % wortgleich, innerhalb desselben Anfangsbuchstabens) und Verbindungen (Begriffe, die >=5x in derselben Passage stehen). DIE REGEL, die das Modul traegt: Eine Quelle SCHLAEGT VOR, sie entscheidet nie. Alle Vorschlaege stehen auf pending. Das ist der Unterschied zwischen einer Wissensbasis, die waechst, und einer, die sich vollsaugt. QUALITAET UNGLEICH: Die Nebenformen treffen ('âb-ı bekâ ≈ âb-ı İskender', beide Nebenformen von âb-ı hayat). Die Verbindungen sind teils Rauschen ('Allah — iki' 254x) - Haeufigkeit allein ist keine Beziehung. Wer sie nutzen will, muss zuerst die haeufigsten Woerter ausschliessen.

Wie wächst die Wissensbasis, was ist offen, wo sinkt die Konfidenz?

Warum

Punkt 13 der Erweiterung. Ansätze existieren: output/wiki/pruefung.html misst die Datenqualität, ontology.statistik() zählt den Bestand. Was fehlt, ist der ZEITVERLAUF - Wachstum, Lernrate, neue Entdeckungen.

Wie

Der Entwicklungsbericht (Aufgabe 35) liefert die Datenpunkte, das Dashboard zeichnet sie.

Noch offen

Erst sinnvoll, wenn es mehrere Messpunkte gibt.

Ergebnis

output/gesundheit.html - Zustand statt Bestand. wissensbasis.html zeigt, WAS da ist; pruefung.html, was an den Korpora falsch ist; diese Seite, was gewachsen ist, wie viel ein MENSCH gesehen hat, und - der wichtigste Block - was GEBAUT, ABER NICHT ABGEFRAGT wird. Das ist der teuerste Fehler dieses Projekts, dreimal gemacht: Ehl-i-Beyt-Korpus (#13), Ontologie (#27), Lexikon (#45/#56). Jedes Mal fiel es erst auf, als jemand zufaellig hinsah, weil nichts kaputtgeht. Aktuell gemeldet: die 133 Namen Gottes (eigene Datei, kein Index) und die fehlende Prosa-Deutung (#28/#59). Keine API-Aufrufe.

Hak ≈ Gerçek, Yol ≈ Tarikat, Can ≈ Mensch - als eigene Beziehungsart.

Warum

Punkt 11 der Erweiterung. Die Ontologie kennt heute nur Aliase (dasselbe Wort für dieselbe Sache). Zwei verschiedene Begriffe, die dasselbe MEINEN, sind etwas anderes und brauchen eine eigene Kantenart - sonst würde die Aliasliste zur Bedeutungssuppe.

Noch offen

Setzt Aufgabe 25 voraus. Und: die Grenze zwischen Alias und Ähnlichkeit ist eine fachliche Entscheidung.

Ergebnis

build_synonyme.py: 320 BELEGTE Gleichsetzungen aus den Querverweisen des Lexikons ('âb-ı bekâ bk. âb-ı hayat'). Das ist keine berechnete Aehnlichkeit, sondern eine ausgesprochene Gleichsetzung eines Fachwoerterbuchs, mit Seitenzahl. ANLASS war die Anmerkung des Nutzers vom 05.08.: 'merhamet und magrifet sind sehr verschieden' - zu einer Gleichsetzung, die ich ohne Beleg behauptet hatte. Ein Test verbietet deshalb ausdruecklich Einbettungen in diesem Modul: zwei Begriffe, deren Vektoren nah beieinanderliegen, sind nicht dasselbe - sie kommen in aehnlichen Saetzen vor. NUTZEN: lexikon.py loest Nebenformen auf. Vorher lieferte ein Vers mit 'âb-ı bekâ' die 'Definition' bk. âb-ı hayat - einen Verweis, der im Prompt wie eine Aussage aussieht. ⚠ Der erste Anlauf fand NICHTS, lautlos: die beiden Module falten unterschiedlich (lexikon macht aus dem Bindestrich ein Leerzeichen, Izafet), 'ab i beka' gegen 'ab-i beka'. Ein Test haelt das fest. 211 Verweise sind unaufloesbar - dasselbe Restmuster wie #62.

Der Graph steht mit 19914 Kanten - er erscheint aber in keinem Ergebnis.

Warum

Layer 6 und Abschnitt 6 des neuen Dokuments. Die Kanten liegen seit heute vor (relations.json), aber weder Dokument noch Wiki zeigen sie. Genau der Fehler, der bei Ehl-i Beyt und der Ontologie schon zweimal passiert ist: gebaut, angemeldet, nie abgefragt.

Wie

Je Deyiş: Hauptkonzepte, verwandte Konzepte, genannte Personen, Rituale, verwandte Deyişe anderer Ozanlar (über gemeinsame Entitäten und Ayets - der Pfad steht in relations.Graph.pfad).

Noch offen

Braucht keine API. Machbar, sobald 50 das Format hat.

Ergebnis

In BEIDEN Formaten. Im Buchformat als Abschnitt 6, im Tabellenformat als eigener Abschnitt unter dem Werk - nicht IN der Tabelle, denn deren zwei Spalten sind Vers und Fund, dazwischen passt keine dritte Sache. Ueber relations.Graph.werk(). Ohne Graph bleibt der Abschnitt WEG statt leer dazustehen: eine Ueberschrift ohne Inhalt liest sich als Befund ('nichts vernetzt'), wo nur die Datei fehlt.

Rest aus #61 - darunter 'pir' und 'Allah'. Womöglich von Hand schneller als per Importer.

Warum

Nach #61 sind 816 Fragmente auf 9 gesunken und kein Begriff ging verloren. Was bleibt, sind zwei Muster, die der Importer nicht mehr auflöst: (1) 104 Begriffe tragen `text_fehlt` - ihr Text gehörte nachweislich dem Vorgänger, ihr eigener Artikel steht im PDF vor dem Umbruch und wird nicht erfasst. Darunter 'pir' und 'Allah', beides zentrale Begriffe. (2) Einzelne Einträge haben einen BELEGVERS als Definition statt der Erklärung ('can'). Beides sind Einzelfälle in einem 985-Seiten-Band, keine Systematik - ein weiterer Importer-Umbau träfe dafür 3725 Einträge, die inzwischen stimmen.

Wie

Vorschlag des Nutzers (06.08.): die Einträge von Hand fix machen. `knowledge/terminologie.json` ist dafür geeignet - die Betroffenen sind über `text_fehlt: true` sauber auffindbar, und lexikon.py überspringt sie bis dahin, statt ein Fragment in den Prompt zu geben. Eine kleine Eingabemaske wie bei der Ontologie-Prüfung wäre denkbar, lohnt aber erst, wenn jemand die Zeit dafür wirklich einplant.

Ergebnis

`python lueckenmaske.py export` erzeugt reports/luecken.html mit 304 Begriffen ohne Artikel, je mit den NACHBAREINTRAEGEN aus dem Lexikon als Anhalt - wer eine Definition eintraegt, sieht den Zusammenhang statt ins Leere zu schreiben. Dieselbe Form wie die anderen Pruefbogen: sendet nichts, haelt Zwischenstaende im Browser, legt am Ende eine JSON ab. Beim Einlesen wird `ergaenzt_von` mitgeschrieben - eine von Hand ergaenzte Definition ist etwas anderes als eine aus dem Band. ⚠ Die erste Fassung lud die Wissensbasis fuer JEDEN Begriff neu und lief in einen Timeout. Bei 304 faellt so etwas auf; bei 5 haette es niemand gemerkt und der Export waere 'etwas langsam' gewesen.

Herkunft

Rest aus #61, ausgelagert auf Wunsch des Nutzers 2026-08-06

Nesimi, Virani, Yemini - jede scheitert aus einem anderen, benannten Grund.

Warum

Nesimi: Übersetzungszeilen stehen unter jedem Beyit und dürfen nicht als Vers eingelesen werden. Virani: 3 Gedichte zwischen Biographie und Webseiten-Navigation. Yemini: 1165 Seiten reiner Scan, braucht OCR.

Noch offen

Der Nutzer hat weitere alevitische Quellen angekündigt - die haben Vorrang vor diesen Resten.

Ergebnis

Zusammen mit #22 erledigt: jede restliche Quelle ist benannt, eingeordnet und mit ihrem Hindernis versehen. Nesimi und Virani sind laengst importiert (8 bzw. 4 Werke); was blieb, war Nesimi_Kitabi (Aufsatzsammlung, kein Werkkorpus) und Yemini (Faziletname, 1165 S., braucht page_start). Fuzuli fehlt als Datei ganz - siehe #23.

Zwei Skripte, die es nicht gibt; Golden-Set-Stand veraltet; zwölf neue Dateien und Fähigkeiten fehlen.

Warum

CLAUDE.md nennt 'python audit_quran2.py' und 'python check_missing_verses.py' als ausführbare Befehle - beide Dateien existieren nicht. Da es keine Testsuite gibt, sind das genau die Befehle, die jemand als Erstes probiert.

Ergebnis

Beide nicht existierenden Skripte auf audit_quran.py berichtigt, Golden-Set-Stand auf 2 von 4, dazu die zwölf neuen Dateien und Fähigkeiten ergänzt: kosten.py, preise.json, analysen.py, die drei Übersichtsseiten, --werke, Laufnummern, page_number_offset, nummer/enthaelt_nummern, Formularmodus, Ablehnungsgründe. Gegenprobe: jedes in CLAUDE.md genannte Skript existiert.

Herkunft

Teil F

66 Duplikate und rund 30 Inhaltsverzeichnisseiten stehen als Passagen drin.

Warum

Ein Inhaltsverzeichnis als Passage ist eine Liste von Kapitelnamen ohne Aussage - sie kann als Treffer erscheinen und wäre dann eine leere Fundstelle. Die Duplikate sind Verlagsvorworte, die in jedem Band gleich stehen (ASK_0007 = BAK_0008); sie kosten nichts außer einem redundanten Treffer.

Wie

Erkennbar an der Satzzeichendichte: unter einem Satzzeichen je 400 Zeichen ist es Verzeichnis, nicht Prosa. Diese Messung steht bereits in export_wiki.befunde_ehlibeyt().

Noch offen

Zusammen mit Aufgabe 20 erledigen - beides schreibt ehlibeyt.json neu.

Ergebnis

97 Passagen markiert und aus dem Index genommen (clean_corpus.py). Arabische Originaltexte werden ausdrücklich ausgenommen.

Nichts wird überschrieben - jedes Objekt führt seine Fassungen mit Datum, Quelle und Prüfer.

Warum

Punkt 1 der Erweiterung. Über Jahrzehnte gedacht ist das richtig: eine Deutung von heute soll die von vor fünf Jahren nicht auslöschen. Teilweise vorhanden ist der Gedanke schon (storage rotiert Backups, menschliche Urteile werden nie überschrieben) - aber als Dateisicherung, nicht als Wissensgeschichte.

Noch offen

Teuer und in alle Richtungen wirksam. Ehrlich: erst sinnvoll, wenn die Objekte selbst stabil stehen (Aufgaben 25, 33) - sonst versioniert man ein Schema, das sich noch ändert.

Ergebnis

storage.fassung_ablegen(): ein Eintrag traegt seine Vorfassungen unter `_fassungen`, juengste zuerst, gedeckelt auf 5. BEWUSST SPARSAM: versioniert wird nur, was ein Mensch oder ein bezahlter Modelllauf erzeugt hat - analysis, kontext, bedeutungen. Nicht der Werktext (kommt aus dem PDF, reproduzierbar) und nicht die Ableitungen (Graph, Ontologie - die baut man neu). Eine Wissensbasis, die jede Fassung ewig mitschleppt, wird unlesbar, und die aelteren stehen ohnehin in knowledge/backups/.

Von der Antwort über Objekte, Beziehungen und Belege bis zum Originalwortlaut.

Warum

Punkt 8 der Erweiterung. Die Bestandteile sind alle da (provenance, evidence, Kandidaten mit Ähnlichkeitswert, found_via) - sie stehen nur nebeneinander statt in einer Kette.

Noch offen

Setzt die Kanten voraus (Aufgabe 25): ein Baum braucht Zwischenknoten.

Ergebnis

`python erklaerung.py PSA_0001#1` zeigt die Kette von der Zuordnung zurueck zum Wortlaut: wie gesucht wurde (found_via, mit welcher Deutung, mit welchen Konzepten), wie gewaehlt (Aehnlichkeit, Bewertung, gegen wie viele Mitbewerber), wie geprueft (vier Kriterien einzeln), wer zugestimmt hat, wo es im Buch steht. DER PUNKT: Jedes Glied ist EINZELN bestreitbar. 'Der Vers passt nicht' ist ein Urteil ueber das Ganze; 'die Bedeutung der Zeile ist falsch erfasst' oder 'die Suche hat den richtigen Kandidaten nie gesehen' sind Aussagen ueber ein Glied - und nur die kann man beheben. Wo nichts hinterlegt ist, steht das da statt einer plausiblen Zahl.

Eine geprüfte Erklärung wird gespeichert und wiederverwendet, statt neu erzeugt zu werden.

Warum

Punkt 12 der Erweiterung. Doppelter Gewinn: Kosten (Reasoning ist eine der beiden teuren Stufen) und Beständigkeit - dieselbe Frage bekommt dieselbe geprüfte Antwort, statt bei jedem Lauf eine neue Formulierung.

Noch offen

Setzt voraus, dass Erklärungen überhaupt geprüft werden - heute wird nur die Ayet-Zuordnung beurteilt, nicht der Verbindungssatz.

Ergebnis

begruendungen.py: eine gepruefte Begruendung wird wiederverwendet. ZWEI GRUENDE, und der zweite wiegt schwerer - Kosten (Reasoning ist eine der teuren Stufen) und BESTAENDIGKEIT: dieselbe Zuordnung soll in zwei Laeufen dieselbe Begruendung bekommen. Heute formuliert jeder Lauf neu, und das sieht aus wie zwei Urteile, wo eines gemeint ist. Der SCHLUESSEL ist eng: (Verszeilen + Ayet-Menge), nicht der Ayet allein - dieselbe Ayet-Menge kann neben zwei verschiedenen Zeilen stehen, und die Begruendung gehoert zur VERBINDUNG. Die Ayets werden sortiert, damit die Reihenfolge des Rankings keinen zweiten Eintrag erzeugt. ⚠ Eine DURCHGEFALLENE Begruendung wird nie gespeichert: das hiesse, einen Fehler haltbar und zugleich billiger zu machen. Am Ende des Laufs meldet main.py, wie viele Aufrufe entfielen.

9 Werke enthalten mehr als ein Gedicht, weil im Scan 11 Trennernummern fehlen.

Warum

Die Werk-IDs stehen ab der ersten Lücke gegen die Nummerierung des Buches versetzt - SH_0004 ist Gedicht 8.

Wie

Zwei Signale ergänzen sich: die Nummernfolge sagt WIE VIELE Gedichte in einem Werk stecken, die MAHLAS (Dichtersignatur in der Schlussstrophe) sagt WO die Grenze liegt. Gemessen: SH_0003 hat 4 Mahlas-Strophen bei 4 erwarteten Gedichten. Deckt 7 der 9 Fälle; für den Rest bleibt das Register des Bandes.

Noch offen

Betroffen: SH_0001, 0003, 0022, 0049, 0097, 0100, 0159, 0179, 0181. Schreibt deyis.json - nicht während eines laufenden Reviews.

Ergebnis

5 von 9 getrennt (split_merged_works.py), 4 gemeldet. Die Mahlas trägt: 91 % der Einzelwerke haben eine, 91 % davon am Schluss.

parse_ehlibeyt_importer.py hat eine zweite Kopie der Diakritika-Faltung aus text_utils.

Warum

Genau das Duplikat, vor dem der Moduldocstring von text_utils warnt. Beim Aufräumen wurden glossary.py und enrich_quran_ehlibeyt.py umgestellt, der Ehl-i-Beyt-Importer übersehen.

Noch offen

Vor dem Ersetzen prüfen, ob dort dieselbe Semantik gebraucht wird - fold() schreibt zusätzlich klein und wirft Apostrophe weg.

Ergebnis

_header_key nutzt jetzt text_utils.fold_letters. Gleichwertigkeit an 1107 echten Kapiteltiteln des Korpus geprüft: 0 Unterschiede - die bestehende Wissensbasis ändert sich nicht.

Herkunft

Teil F

Der sechste der Yedi Ulu Ozan hat keine einzige Datei in input/.

Warum

In der Wissensbasis stehen jetzt 5 der Sieben: Pir Sultan Abdal, Şah Hatayi, Kul Himmet, Nesimî, Vîrânî. Yemini scheitert an fehlender OCR (Aufgabe 11), für Fuzuli gibt es überhaupt nichts - das ist keine technische Hürde, sondern eine fehlende Quelle.

Noch offen

Der Nutzer müsste eine Ausgabe beschaffen. Fuzulis Divan ist gut ediert, ein Textlayer-PDF sollte auffindbar sein.

Ergebnis

BEFUND statt Loesung, weil die Quelle wirklich fehlt: Fuzuli kommt 13-mal im Terminologie-Lexikon vor (unter 'Alevi Bektasi edebiyati', 'Anka', 'Beytullah', 'duerr-i yetim'), aber KEIN einziges seiner Werke liegt in input/. Er ist als Person belegt, sein Werk nicht. Was gebraucht wird: sein Divan oder eine Auswahlausgabe, tuerkisch, als PDF mit Textebene. Ohne die Datei kann kein Importer etwas tun - das ist keine Programmieraufgabe.

İkrar von der ersten Erwähnung über Buyruk und Pir Sultan bis in die heutige Literatur.

Warum

Punkt 15 der Erweiterung und das weiteste Ziel des Projekts: nicht Dokumente finden, sondern zeigen, wie eine Idee durch die Quellen wandert.

Noch offen

Braucht fast alles darüber: Kanten, Quellenqualität mit Datierung, semantische Ähnlichkeit. Steht hier, damit die Richtung festgehalten ist - nicht als nächster Schritt.

Ergebnis

begriffsgeschichte.py ordnet die Fundstellen eines Begriffs nach der SCHICHT ihrer Quelle: Kur'an, Prophetennarrative, Ehl-i-Beyt-Ueberlieferung, Deyişe der Ulu Ozan, heutiges Fachlexikon. Das ist eine Ordnung nach ART der Quelle, KEINE Datierung - die Wissensbasis kennt keine Jahreszahlen, und das steht ausdruecklich da, damit niemand es dafuer haelt. 'ikrar' ergibt 122 Verszeilen, 103 Prosastellen, 1 Ayet, 2 Lexikoneintraege. Eine LEERE Schicht ist ein Befund: der Begriff gehoert ihr nicht an, oder die Quelle benutzt ein anderes Wort. Dazu die BEGLEITBEGRIFFE - ein Begriff zeigt sein Feld in seiner Gesellschaft, nicht in seiner Definition. Gezaehlt wird nur, was das Lexikon als Begriff kennt, sonst stuenden dort 'bir' und 'olan'.

VALIDATION_MODEL steht als einziges aktives noch auf gpt-5.5; gpt-5.6-sol kostet exakt dasselbe.

Noch offen

config.py begründet die 5.5-Wahl damit, dass erzeugendes und prüfendes Modell nicht identisch sein sollen. Terra und Sol wären zwei verschiedene Modelle, aber aus derselben Familie - eine Bewertungsfrage, keine technische. Zudem gibt die 5.6-Reihe die Pinnung auf (keine Snapshots).

Ergebnis

VALIDATION_MODEL von gpt-5.5-2026-04-23 auf gpt-5.6-sol. Es war das einzige aktive Modell auf der alten Generation; sol kostet laut preise.json exakt dasselbe. Die Pruefstufe ist ausserdem die Stelle, an der ein Fehler am teuersten ist.

Beim Ablehnen nach dem Grund fragen; nur 'keine Entsprechung' als leere Erwartung ins Golden Set.

Ergebnis

evidence.REJECT_*, Nachfrage im review-Befehl samt Auswahl des richtigen Ayets aus den Kandidaten, _golden_entries_for unterscheidet vier Fälle. evaluate_golden_set misst die Schwelle jetzt an ENTSCHEIDUNGEN statt an Einträgen.

Herkunft

Teil A

api_usage liest cached_tokens und reasoning_tokens, Bericht zeigt beide Anteile.

Ergebnis

Ergebnis: Caching greift NIE (0 %), dafür sind 90 % der Prüfstufen-Ausgabe Denk-Token. Damit ist die Grundlage für Aufgabe 12 und die Absage an Aufgabe 3 als Sparmaßnahme gelegt.

Herkunft

Teil B

FINAL_TOP_K, Embeddings und VALIDATION_MODEL als bewusst nicht gezogene Hebel festhalten.

Ergebnis

Neuer Abschnitt OPEN OPTIMISATIONS in ARCHITECTURE.md, mit der Messtabelle. Dabei auch der veraltete DEFERRED-Abschnitt zu Hatayi und Antoloji berichtigt.

Herkunft

Teil E

Jeden Punkt mit Datei- und Funktionsnamen belegen, nichts nachträglich umsetzen.

Ergebnis

43 umgesetzt, 4 teilweise, 2 Befunde. Die drei Lücken wurden zu den Aufgaben 14 und 15.

Herkunft

Teil F