Protokoll #12681

{
    "event": "PreToolUse",
    "tool_name": "Read",
    "tool_input": {
        "file_path": "\/var\/www\/docs\/pipeline\/ergänzung.md"
    }
}

{
    "tool_response": {
        "type": "text",
        "file": {
            "filePath": "\/var\/www\/docs\/pipeline\/dokument-import-pipeline.md",
            "content": "## Einleitung\n\nDieses Dokument definiert die verbindliche Phasenfolge zur Verarbeitung von Dokumenten in eine semantische Infrastruktur.  \nDie Phasen sind so beschrieben, dass sie in einer Supervision konkret überprüfbar sind.  \nJede Phase erzeugt klar benennbare Artefakte in drei Systemklassen:\n\n- SQL Datenbank für Text, Struktur und semantische Datensätze  \n- Vektordatenbank für Chunk Embeddings und Ähnlichkeitssuche  \n- Graphspeicher für Entitäten, Relationen, Aussagen, Ontologie und Taxonomie  \n\n---\n\n## Phase 0: Dokumenteingang und Identität\n\n### Ziel\nEin Dokument wird kontrolliert übernommen, eindeutig identifiziert und unverändert archiviert.  \nErgebnis ist ein reproduzierbarer Ausgangszustand für alle späteren Verarbeitungsschritte.\n\n### Eingangskanäle und akzeptierte Formate\n1. Das Dokument wird über einen definierten Eingangskanal übernommen:\n   1. Dateiupload über ein UI  \n   2. Ablage in einem beobachteten Import Verzeichnis  \n   3. Übergabe über eine interne Schnittstelle  \n2. Akzeptierte Formate sind:\n   1. PDF  \n   2. Markdown  \n   3. Plain Text  \n\n### Identität und Versionierung\n3. Vor jeder Verarbeitung wird geprüft, ob das Dokument bereits bekannt ist:\n   1. Primär über einen Content Hash der Originaldatei  \n   2. sekundär über einen externen Schlüssel, falls vorhanden  \n4. Es wird eine globale Dokumenten-ID erzeugt:\n   1. Die ID entsteht im System, nicht aus dem Dateinamen  \n   2. Die ID ist stabil über den gesamten Lebenszyklus  \n   3. Die ID ist unabhängig von der Speichertechnologie  \n5. Wenn derselbe Content Hash bereits existiert, wird keine neue Dokumenten-ID erzeugt.  \n6. Wenn Inhalt abweicht, entsteht eine neue Dokumentenversion, die zur ursprünglichen Dokumenten-ID referenziert.\n\n### Archivierung der Originaldatei\n7. Die Originaldatei wird unverändert archiviert:\n   1. Speicherung als Binärartefakt  \n   2. Speicherung des Content Hash  \n   3. Speicherung der Dateigröße  \n   4. Speicherung der Erfassungszeit  \n8. Das Archivartefakt wird als Quelle für Reprocessing verwendet.  \n9. Das Archivartefakt wird niemals überschrieben. Es kann nur durch eine neue Version ergänzt werden.\n\n### Ergebnisartefakte der Phase\n10. Artefakte nach Abschluss von Phase 0:\n    1. Dokumenten-ID  \n    2. Dokumentenversion  \n    3. Content Hash der Originaldatei  \n    4. Archivierte Originaldatei  \n    5. Eingangskanal und Eingangszeit  \n\n### Prüfbedingungen für Supervision\n11. Prüfpunkte:\n    1. Für jede Dokumenten-ID existiert mindestens eine unveränderte Originaldatei im Archiv.  \n    2. Jede spätere Verarbeitung referenziert exakt diese Dokumenten-ID und Version.  \n    3. Reprocessing mit derselben Originaldatei ergibt identische Content Hash Werte.  \n\n\n\n\n## Phase 1: Primärspeicherung in der SQL-Datenbank\n\n### Ziel  \nDer extrahierte Dokumentinhalt wird vollständig, unverfälscht und reproduzierbar gespeichert.  \nDiese Phase definiert die textuelle Quelle der Wahrheit.  \nAb hier ist der Dokumentinhalt systemisch fixiert und unabhängig von späteren Interpretationen.\n\n### Textgewinnung\n\n1. Aus der archivierten Originaldatei wird Text extrahiert.  \n2. Die Extraktion ist formatabhängig, aber deterministisch.  \n3. Ziel ist ein linearer Textstrom ohne Layoutlogik.  \n4. Es werden keine Inhalte entfernt, zusammengefasst oder interpretiert.\n\n### Normalisierung\n\n5. Der extrahierte Text wird technisch normalisiert:\n   1. Vereinheitlichung von Zeilenumbrüchen  \n   2. Normalisierung von Unicode Zeichen  \n   3. Entfernung rein technischer Steuerzeichen  \n6. Die inhaltliche Bedeutung des Textes bleibt unverändert.  \n7. Normalisierung dient ausschließlich der Vergleichbarkeit und Wiederverarbeitung.\n\n### Metadatenerfassung\n\n8. Metadaten werden strukturiert erfasst:\n   1. Dokumententitel  \n   2. Quelle oder Ursprung  \n   3. Erstellungsdatum, sofern bekannt  \n   4. Sprache  \n   5. Dokumentenversion  \n9. Metadaten werden getrennt vom Text gespeichert.  \n10. Metadaten werden nicht aus späteren semantischen Analysen abgeleitet.\n\n### Speicherung des Volltexts\n\n11. Der vollständige normalisierte Text wird als eine logische Einheit gespeichert.  \n12. Der Text wird exakt der Dokumenten-ID und Version aus Phase 0 zugeordnet.  \n13. Es findet keine Zerlegung, kein Chunking und keine Annotation statt.  \n14. Die Speicherung ist verlustfrei.\n\n### Abgrenzung zur Semantik\n\n15. In dieser Phase findet keinerlei semantische Interpretation statt.  \n16. Es werden keine Entitäten erkannt.  \n17. Es werden keine Relationen abgeleitet.  \n18. Es werden keine Aussagen modelliert.  \n19. Der Text ist reiner Inhalt, keine Bedeutung.\n\n### Rolle der SQL-Datenbank\n\n20. Die SQL-Datenbank ist ab diesem Zeitpunkt Quelle der Wahrheit für:\n   1. den vollständigen Dokumenttext  \n   2. die textuelle Versionierung  \n   3. die Referenzbasis aller folgenden Phasen  \n21. Kein anderes System darf den Dokumentinhalt verändern oder ersetzen.\n\n### Ergebnisartefakte der Phase\n\n22. Artefakte nach Abschluss von Phase 1:\n   1. Normalisierter Volltext  \n   2. Verknüpfung mit Dokumenten-ID und Version  \n   3. Strukturierte Metadaten  \n\n### Prüfbedingungen für Supervision\n\n23. Prüfpunkte:\n   1. Der gespeicherte Text ist vollständig aus der Originaldatei rekonstruierbar.  \n   2. Wiederholte Extraktion aus derselben Originaldatei erzeugt identischen Text.  \n   3. Keine nachgelagerte Phase verändert den gespeicherten Volltext.  \n\n---\n\n## Phase 2: Strukturelle Zerlegung\n\n### Ziel  \nDer gespeicherte Volltext wird in explizite, überprüfbare Struktureinheiten zerlegt.  \nStruktur ist ab dieser Phase ein eigener Datenbestand und nicht mehr implizit im Text verborgen.  \nDiese Phase erzeugt die Grundlage für reproduzierbares Chunking und spätere semantische Verarbeitung.\n\n### Eingangsbasis\n\n1. Grundlage ist ausschließlich der normalisierte Volltext aus Phase 1.  \n2. Es werden keine Informationen aus späteren Phasen vorweggenommen.  \n3. Die Dokumenten-ID und Version bleiben unverändert.\n\n### Seitenzerlegung\n\n4. Der Text wird in Seiten zerlegt, sofern das Ursprungsformat Seiten kennt.  \n5. Die Seitenreihenfolge ist eindeutig und stabil.  \n6. Jede Seite erhält:\n   1. eine Seiten-ID  \n   2. eine Seitenposition  \n   3. eine Referenz auf die Dokumenten-ID  \n7. Seiten enthalten ausschließlich Textausschnitte aus dem Volltext.  \n8. Seiten enthalten keine semantische Interpretation.\n\n### Zerlegung in semantische Abschnitte\n\n9. Der Text wird zusätzlich in semantische Abschnitte zerlegt.  \n10. Semantische Abschnitte sind:\n    1. Kapitel  \n    2. Überschriftenbereiche  \n    3. logisch zusammenhängende Sinnblöcke  \n11. Die Erkennung folgt klar definierten Regeln:\n    1. explizite Überschriftenstrukturen  \n    2. formale Marker im Text  \n    3. klar dokumentierte Heuristiken  \n12. Jede Heuristik ist deterministisch und reproduzierbar.\n\n### Identität und Referenzen\n\n13. Jeder Abschnitt erhält:\n    1. eine Abschnitts-ID  \n    2. eine Positionsangabe  \n    3. eine Referenz auf die Dokumenten-ID  \n14. Abschnitte können eine oder mehrere Seiten referenzieren.  \n15. Seiten und Abschnitte sind voneinander unabhängig, aber eindeutig zuordenbar.\n\n### Explizite Speicherung der Struktur\n\n16. Seiten und Abschnitte werden getrennt vom Volltext gespeichert.  \n17. Die Struktur ist explizit abfragbar.  \n18. Keine Strukturinformation wird aus Textanalyse implizit rekonstruiert.\n\n### Abgrenzung zur Semantik\n\n19. In dieser Phase findet keine semantische Interpretation statt.  \n20. Abschnitte sind strukturelle Einheiten, keine Bedeutungseinheiten.  \n21. Begriffe wie Kapitel oder Abschnitt beschreiben Form, nicht Inhalt.\n\n### Ergebnisartefakte der Phase\n\n22. Artefakte nach Abschluss von Phase 2:\n    1. Seiten mit stabiler Reihenfolge  \n    2. Semantische Abschnitte als Struktureinheiten  \n    3. Referenzen zwischen Seiten, Abschnitten und Dokument  \n\n### Prüfbedingungen für Supervision\n\n23. Prüfpunkte:\n    1. Jeder Textabschnitt des Volltexts gehört mindestens zu einer Seite und einem Abschnitt.  \n    2. Die Zerlegung ist reproduzierbar bei identischem Input.  \n    3. Seiten und Abschnitte können unabhängig voneinander abgefragt werden.  \n\n\n---\n\n## Phase 3: Chunk-Erzeugung\n\n### Ziel  \nAus den strukturellen Abschnitten entstehen technisch handhabbare Verarbeitungseinheiten.  \nChunks sind die kleinste textuelle Einheit, die eigenständig verarbeitet, eingebettet und referenziert wird.  \nChunking ist eine technische Maßnahme, keine semantische Interpretation.\n\n### Eingangsbasis\n\n1. Grundlage sind ausschließlich die semantischen Abschnitte aus Phase 2.  \n2. Seiten dienen nur der Orientierung und Provenienz, nicht der Chunk-Grenze.  \n3. Dokumenten-ID und Dokumentenversion bleiben unverändert.\n\n### Chunking-Regeln\n\n4. Semantische Abschnitte werden deterministisch in Chunks zerlegt.  \n5. Die Chunk-Grenzen folgen klar definierten Regeln:\n   1. maximale Textlänge  \n   2. minimale Textlänge  \n   3. Erhalt vollständiger Sätze  \n   4. optionale Überlappung zur Kontextstabilisierung  \n6. Die Regeln sind dokumentiert und versioniert.  \n7. Identischer Input erzeugt identische Chunks.\n\n### Erzeugung der Chunks\n\n8. Jeder Chunk entsteht aus genau einem Abschnitt.  \n9. Ein Abschnitt kann mehrere Chunks erzeugen.  \n10. Ein Chunk überschreitet niemals die Grenzen seines Abschnitts.  \n11. Chunks enthalten ausschließlich Text aus dem Volltext.\n\n### Identität und Metadaten\n\n12. Jeder Chunk erhält:\n    1. eine stabile Chunk-ID  \n    2. eine Referenz auf die Dokumenten-ID  \n    3. eine Referenz auf die Abschnitts-ID  \n    4. eine Positionsangabe innerhalb des Abschnitts  \n    5. den vollständigen Chunk-Text  \n13. Die Chunk-ID ist unabhängig von der späteren Speicherung in anderen Systemen.\n\n### Semantische Rolle\n\n14. Jedem Chunk wird eine semantische Rolle zugewiesen:\n    1. Fließtext  \n    2. Definition  \n    3. Aufzählung  \n    4. Beispiel  \n    5. Sonstiges  \n15. Die Rolle beschreibt die Textfunktion, nicht die Bedeutung.  \n16. Die Rollenvergabe folgt expliziten Regeln und ist reproduzierbar.\n\n### Speicherung\n\n17. Alle Chunks werden vollständig i... [TRUNCATED-23d122f2515a8085]",
            "numLines": 1077,
            "startLine": 1,
            "totalLines": 1077
        }
    }
}