wiki-ingest

Was macht wiki-ingest?

Implementiert das LLM-Wiki-Ingest-Muster für eine wissenschaftliche Wissensdatenbank. Jeder ingerierte Artikel erzeugt nachvollziehbares, sich akkumulierendes Wissen, nicht nur eine isolierte Notiz.

Vor dem ersten Ingest lies docs/GOTCHAS.md im Kit (betriebliche Fallstricke für Ingest, Synthese und Lint).

Modi

• Standard (Ingest): /wiki-ingest <artikel> erstellt oder aktualisiert die Artikelnotiz und überträgt die Ergebnisse in Konzepte und Methoden (siehe Standard-Workflow unten).
• Verifikationsmodus: /wiki-ingest verify:<ArtikelNotiz> überprüft eine vorhandene Notiz erneut anhand ihres Volltexts und meldet Unterschiede, ohne etwas neu zu generieren oder zu überschreiben (siehe references/VERIFY-DIFF-MODE.md). Schreibgeschützt, es sei denn, der Benutzer bestätigt jede Änderung.

Rolle und Grenzen

Tut: Erstellt oder aktualisiert Artikelnotizen, überträgt Ergebnisse in Konzept- und Methodennotizen, aktualisiert den Index und das Log, meldet jede Änderung.

Tut NICHT: Erfindet Zitate, erstellt Konzeptnotizen für Einmal-Konzepte oder schreibt in eine Datenbank. Alle Schreibvorgänge erfolgen über die Dateiwerkzeuge des Hosts (Lesen/Schreiben/Bearbeiten).

Wo die Dinge liegen

Pfade stammen aus wiki.config.json (Vault-Root, Wiki-Root, Ordnernamen, Sprache, Schwellwerte). Standardeinstellungen:

<vault_root>/
  <wiki_root>/            # Standard: wiki/
    papers/  concepts/  methods/  books/  fields/  debates/
    WIKI_SCHEMA.md        # Frontmatter-Verträge, Benennung, Taxonomie, Ingest-Protokoll
    index.md  log.md
  templates/              # paper.md, concept.md, method.md, book.md, chapter.md, submoc.md, synthesis.md

<kit> unten bezieht sich auf das Science-Wiki-Kit-Checkout, das tools/ (seal.py, pmc_tables.py) enthält. Sein Pfad ist der kit_dir-Schlüssel von wiki.config.json, der vom Installer geschrieben wird; fehlt er, liegt er zwei Ordner über dem Verzeichnis dieses Skills, wenn der Skill aus dem Checkout verlinkt ist.

Lies immer zuerst WIKI_SCHEMA.md. Es definiert die Frontmatter-Verträge, Benennungsregeln und die Feldtaxonomie dieses Wikis.

Verwandte Skills

• wiki-lint: teilt sich wiki.config.json (die Kebab-Case-zu-Title-Case-Feldzuordnung, die bei Indexaktualisierungen verwendet wird). Führe es nach jedem Ingest aus, um zu überprüfen, ob keine Abweichung eingeführt wurde.
• wiki-ingest-book: Begleitskill für Bücher und Kapitel. Dieselben Statusregeln und Index-Routing gelten.
• wiki-synthesize: verbraucht die Notizen, die dieser Skill erstellt.

Entscheidung zum Anfangsstatus (angewendet auf jede neue Notiz)

Setze den status bewusst. Lasse nicht die Vorlagenvorgabe stehen. N unten ist min_distinct_sources_for_final in der Konfiguration (Standard 2).

Notiztyp	Bedingung	Anfang status
Artikel	Abstract + mindestens 2 belegte Ergebnisse extrahiert	read
Artikel	Nur DOI-/Titel-Metadaten, kein Volltext	stub + > [!warning] Stub: Ausstehender Ingest. Callout
Konzept	Mindestens 2 belegte Ergebnisse aus N oder mehr verschiedenen Quellwerken	final
Konzept	Mindestens 2 belegte Ergebnisse, alle aus einem einzigen Quellwerk	draft (Ein-Quellen-Synthese)
Konzept	Definition + 1 belegtes Ergebnis	draft
Konzept	Nur Definition, keine Kernerkenntnisse	stub + > [!warning] Stub: Noch keine belegten Ergebnisse. Callout
Methode	Definition + N oder mehr verschiedene Quellwerke unter "Papers Using This Method"	final
Methode	Definition und nur 1 Quellwerk	draft (Ein-Quelle)
Methode	Definition, aber keine Quellenzitate	draft
Methode	Nur Grundgerüst	stub

Die Hochstufung auf final erfordert N VERSCHIEDENE Quellwerke. "Verschieden" zählt unabhängige Artikel oder Bücher: Eine Buch-Elternnotiz und ihre eigenen Kapitelnotizen (Author_2025 + Author_2025_Ch01 + Author_2025_Ch02) kollabieren zu einem Werk, ebenso wie mehrere Kapitel desselben Buches. Eine einzelne reichhaltige Quelle (systematischer Review, Lehrbuchkapitel) kann ein Konzept erstellen und mehrere Ergebnisse liefern, aber die Notiz bleibt draft, bis eine zweite unabhängige Quelle es bestätigt. Wenn ein Ergebnis zu einer draft-Notiz hinzugefügt wird, zähle die verschiedenen Werke nach der Bearbeitung, stufe nur hoch, wenn die Anzahl N erreicht, und protokolliere die Hochstufung im Ingest-Bericht. Ein-Quellen-draft-Notizen enthalten einen kurzen "Ein-Quellen-Synthese, bestätige, wenn eine 2. Quelle ingeriert wird"-Hinweis im Textkörper.

Standard-Workflow

1. Schema lesen

Lies WIKI_SCHEMA.md.

2. Die Artikelquelle auflösen

Versuche es der Reihe nach mit dem, was deine Umgebung bietet:

• Referenzmanager (Zotero MCP ist der unterstützte Adapter): Suche, dann Metadaten, dann Volltext. Reihenfolge und Such-Fallstricke in references/INGEST-WORKFLOW.md.
• Publisher-XML-Tabellen (Open-Access in PMC): Wenn die DOI eine PMCID hat, können Tabellen Zelle für Zelle aus Europe PMC JATS extrahiert werden, unabhängig von der PDF-Textschicht: python <kit>/tools/pmc_tables.py <DOI> --out _temp/<stamm>_pmc.md --body (Exit-Code 2 bedeutet keine PMCID). Überprüfe die Tabellennummern mit dem JATS, bevor du die Seitenabbildung öffnest; bei einer JATS-gegen-PDF-Diskrepanz gewinnt die gedruckte PDF und die Diskrepanz wird notiert. Keine PMCID: Verwende die PDF.
• PubMed MCP (Artikel nicht im Referenzmanager): Suche nach Stichwörtern, dann Abruf über PMID (eine DOI kann ein leeres full_text zurückgeben). Speichere die PMID im notes:-Feld der Artikelnotiz. Nur für biomedizinische Artikel und nachdem der Benutzer bestätigt hat, dass er sich nicht in seiner Bibliothek befindet.
• Nur DOI: Notiere es; erfinde keine Metadaten.
• Webartikel (Open-Access-HTML/URL): Konvertiere ihn zuerst mit einem Web-zu-Markdown-Tool (z. B. dem defuddle-Skill) in sauberes Markdown und behandle dann die Ausgabe als Abstract und Textkörper. Verwende die URL als Zitierquelle, wenn es keine DOI gibt.
• Manuell: Der Benutzer fügt Abstract oder Text ein. Extrahiere Metadaten und kennzeichne, was unbekannt ist.

Wo die PDF lebt, ist wichtig: Die Notiz darf niemals einen Arbeitsordner (Downloads/, ein temporäres Verzeichnis) zitieren, der bereinigt wird. Organisiere die PDF am Bibliotheksort, den deine Gruppe verwendet, bevor du die Notiz schreibst, und dokumentiere sie in source_verification. Wenn der Artikel nicht in der Bibliothek ist oder die richtige Sammlung unklar ist, frage den Benutzer, bevor du etwas verschiebst.

3. Dateinamen der Artikelnotiz bestimmen

Format: FirstAuthor_Year_Keyword.md

• FirstAuthor = Nachname des Erstautors (nur ASCII, keine Akzente, keine Leerzeichen)
• Year = 4 Ziffern
• Keyword = 1 bis 3 Wörter Beschreibung (CamelCase oder Unterstriche, keine Leerzeichen)
• Beispiel: Smith_2023_Eccentric_Training.md

Duplikats- und Identitätsprüfung (vor jedem Schreibvorgang ausführen; schützt vor stillem Datenverlust):

1. Bestätige die Existenz mit einer Inhaltsuche nach dem Basisnamen oder test -f "<wiki_root>/papers/{filename}.md". Vertraue NICHT einem einzelnen Glob, der "keine Dateien gefunden" zurückgibt: Datei-Glob-Tools haben falsch negative Ergebnisse für vorhandene Notizen geliefert, und ein blindes Write würde danach eine vollständig propagierte Notiz überschreiben. Wenn Write mit "Datei wurde noch nicht gelesen" fehlschlägt, ist das ein Beweis, dass die Notiz existiert: Lese sie und aktualisiere an Ort und Stelle, schreibe niemals von Grund auf neu.
2. Wenn die vorhandene Notiz den Status stub hat, nimm nicht an, dass es derselbe Artikel ist. Stubs, die aus dem Zitierkontext eines anderen Artikels erstellt wurden, tragen vorläufige Metadaten und sind manchmal ein anderer Artikel (falsches Jahr, Artikel vs. Buchkapitel, zwei verwandte Artikel verwechselt). Löse zuerst die echte Quelle auf und vergleiche Autoren, Jahr und Zeitschrift sowohl mit dem Stub als auch mit der Referenzliste der zitierenden Notiz. Wenn es ein anderer Artikel ist, ingeriere ihn als NEUE Notiz und behalte oder verbessere den Stub.
3. Wenn derselbe Artikel bestätigt ist, aktualisiere an Ort und Stelle; erstelle niemals ein Duplikat. Der Dateiname kann sich legitim in ein beschreibenderes Keyword ändern, sobald du den Volltext hast. Wenn ja, verlinke jedes [[OldName]] neu und lösche den verwaisten Stub, führe dann wiki-lint erneut aus, um zu bestätigen, dass keine kaputten Links mehr vorhanden sind.
4. Citekey-Identitätsschutz. Zwei Notizen für denselben Artikel können unterschiedliche Dateinamen tragen, daher beweist eine saubere Basisnamenprüfung nichts über die Identität. Sobald der Referenzmanager das Element aufgelöst hat, durchsuche papers/ nach dem exakten Citekey, den du schreiben willst (grep -l '^citekey: "\?{citekey}"\?$' papers/*.md). Ein Treffer auf einem anderen Dateinamen bedeutet, dass der Artikel bereits ingeriert ist: Aktualisiere diese Notiz stattdessen. Exakter Zeichenfolgenabgleich, also keine Fehlalarme.

4. Artikelnotiz erstellen oder aktualisieren

Schreibe <wiki_root>/papers/{filename}.md aus templates/paper.md. Fülle jedes Frontmatter-Feld aus den aufgelösten Metadaten. Setze last_verified auf das heutige Datum (Ingest ist ein Verifikationsereignis). Weise research_lines aus den Taxonomie-Slugs in WIKI_SCHEMA.md zu.

5. Extrahieren und bewerten

Ein Durchlauf über Abstract, Ergebnisse und Diskussion, wobei alles auf einmal erledigt wird:

• Identifiziere 3 bis 8 Domänenkonzepte (empirische Konstrukte, Variablen) und 1 bis 4 primäre Methoden. Heuristiken in references/INGEST-WORKFLOW.md.
• Klassifiziere evidence_level: das Studiendesign, aus dem kontrollierten Vokabular in WIKI_SCHEMA.md (SR-MA, RCT, cohort, ...). Dies ist die Design-Achse, die die Lebend-Synthese-Schicht gewichtet. Die Messqualitäts-Achse bleibt inline in jedem Ergebnis, wenn relevant ((MRI), (anthropometric estimate)), niemals im Frontmatter.
• Forschungslinien-Routing: Ordne den Artikel den Forschungslinien in WIKI_SCHEMA.md zu. Wenn relevanter Inhalt keine passende Linie hat, füge eine zum Schema hinzu, bevor du propagierst (anhängen eines Slug + Label-Paares; niemals vorhandene Linien umbenennen oder entfernen). Bei Grenzfällen verwende die nächste Linie und markiere es im Bericht.
• Konzept- versus Methoden-Routing: empirische Ergebnisse gehen zu concepts/; statistische Werkzeuge, Studiendesigns und Messprotokolle gehen zu methods/. Entscheide hier.
• Rein methodische Abkürzung: Wenn der Artikel keine empirischen Behauptungen aufstellt, überspringe Schritt 6 und gehe zu Schritt 7.

5b. Evidenztabelle, vor jeder Propagation

Für jedes Ergebnis, das eine Notiz in concepts/ oder methods/ erreicht (einschließlich einer Aussage unter "Papers Using This Method"), schreibe eine Zeile in eine temporäre Datei (niemals im Wiki):

| Zielnotiz | Ergebnis, wie es geschrieben wird | Wörtliches Zitat aus der Quelle | Seite (PDF / gedruckt) | Abschnitt, Tabelle oder Abbildung |

• Die Quelle ist die PDF (oder das JATS für Tabellenzellen). Nur Abstract oder keine PDF: Markiere das Ergebnis als abstract only im Text und sage es im Bericht.
• Jedes Spezifikum braucht sein Zitat: jede Abbildung, Population, jedes Gerät, jeder Mechanismus, jede benannte Entität und jedes Stärkeverb. Teile das Ergebnis auf oder verwende mehrere Zitate, bis alles abgedeckt ist.
• Lies den gesamten Absatz oder die gesamte Tabellenzeile um den Treffer herum, nicht nur die passende Zahl.
• Tabellen, Abbildungen, Vorzeichen, Konfidenzintervalle und ±: Rendere die Seite und schau sie dir an. Textextraktion ist eine Hypothese, das Bild ist der Beweis. Einige PDFs verlieren das Minuszeichen in der Textschicht (-5,2% extrahiert als 25,2%), was eine plausible falsche Zahl erzeugt.
• Abwesenheit erfordert eine positive Suche, sowohl im Layout- als auch im Nicht-Layout-Text und mit Rechtschreibvarianten, bevor etwas als "der Artikel nicht..." geschrieben wird.

5c. Überprüfe die Tabelle vor dem Schreiben

Lies jede Zeile gegen ihr Zitat, bevor eine Notiz berührt wird. Wenn ein Sub-Agent den Artikel extrahiert hat, lies jede Zeile in der PDF erneut, nicht nur Zeilen mit einer Abbildung oder einem Vorzeichen. Fehlerklassen, nach denen zu beurteilen ist: Schlussfolgerung über die Quelle hinaus, Zuschreibungsfehler, falsche Zahl, verlorene Einschränkung, unbegründeter Superlativ, falsche Entität, erfundenes Detail, Auslassung.

• Eine Zeile, deren Zitat sie nicht stützt, wird auf das reduziert, was das Zitat sagt, oder gestrichen. Die Quellnotiz ist kein Beweis: Sie stammt aus derselben Extraktion.
• Behalte die Einschränkung der Quelle ("kann", "es scheint", "könnte an ... liegen") und ihre Population.
• Die eigene Lesart des Wikis wird als die des Wikis gekennzeichnet; schreibe sie niemals als Handlung oder Schlussfolgerung der Quelle.

Nur Zeilen, die bestehen, gehen zu den Schritten 6 und 7.

6. Propagiere zu Konzeptnotizen

Für jedes Konzept aus Schritt 5:

1. Überprüfe, ob concepts/{Concept_Name}.md existiert.
2. Existiert: Hänge das Ergebnis mit einem [[artikel_notiz]]-Backlink unter "Key Findings" an. Aktualisiere related_concepts, wenn neue Verknüpfungen entstehen.
3. Existiert nicht: Wende zuerst die Erstellungsregeln in references/CONCEPT-PROPAGATION.md an.

7. Propagiere zu Methodennotizen

Für jede Methode aus Schritt 5:

1. Überprüfe, ob methods/{Method_Name}.md existiert.
2. Existiert: Füge den Artikel unter "Papers Using This Method" hinzu.
3. Existiert nicht: Erstelle aus templates/method.md.

8. Aktualisiere das Frontmatter der Artikelnotiz

Fülle concepts_touched mit den erstellten oder aktualisierten Konzept- und Methodennotizen.

Überprüfe nach dem Schreiben: JEDER Name in concepts_touched MUSS in einer vorhandenen Notiz in concepts/ oder methods/ aufgelöst werden. Überprüfe nach dem Schreiben jeden Basisnamen erneut. Wenn einer nicht aufgelöst wird, erstelle entweder den fehlenden Stub jetzt oder entferne den Namen. Nicht aufgelöste Referenzen werden zu stiller Lint-Abweichung.

8b. Versiegle die Quellnotiz

Dokumentiere die Verifikation in source_verification der Artikelnotiz (eine Zeile: Referenzmanager-Schlüssel, Datum, was gegen was geprüft wurde). Versiegle dann jedes (Notiz, Werk)-Paar, das ein Ergebnis erhalten hat und dessen Zeilen 5c bestanden haben: Schreibe ein kleines JSON-Spezifikationsfile und führe python <kit>/tools/seal.py spec.json --dry-run, dann ohne --dry-run aus (Format und Regeln in docs/SEALS.md). Ein nur anhand seines Abstracts überprüftes Werk erhält kein Siegel. Nimm Daten von der Systemuhr (date +%F), schätze sie niemals.

9. Abschluss

Drei Bearbeitungen, dann der Bericht. Verwende field_titlecase_map aus wiki.config.json, um den richtigen Unterabschnitt für jedes neue Konzept oder jede neue Methode zu finden; hänge niemals an einen datierten Sammelblock am Ende eines Abschnitts an.

• index.md: Wenn der Index eingebettete Obsidian-Bases-Ansichten einbettet (index_mode: bases in der Konfiguration), pflege NIEMAND per-Notiz-Listen; erhöhe nur die kuratierten ## Quick Stats-Zahlen und die relevante ## Coverage by Field-Zeile, lies dann die Tabellen neu (ein neues Wiki hat keinen dieser Abschnitte: überspringe dies, nichts driftet, bis du sie hinzufügst). Im manual-Modus füge die Notiz in den richtigen alphabetischen Slot ein. Berühre niemals ein eingefrorenes Legacy-Index.
• Sub-MOC-Routing (siehe WIKI_SCHEMA.md, Sub-MOC-Architektur): Löse das field + subfield der Notiz auf, berechne fields/{field-slug}/MOC_{Title_Case_Underscore(subfield)}.md (Kebab-Case zu Title_Case, deterministisch, keine Map erforderlich). Wenn es nicht existiert, erstelle es aus templates/submoc.md und füge eine Zeile zum MOC-Sub-MOCs-Index des Feldes hinzu. Füge die Notiz unter dem richtigen Abschnitt des Sub-MOC hinzu (Konzeptnotizen, Methodennotizen, Artikel, Bücher).

… [für die Übersetzung gekürzt]