# Literaturverzeichnispruefung

> Verify academic references and bibliographies for citation errors and AI hallucinations using live database APIs (OpenAlex, OpenAIRE, K10plus, lobid, DNB, Crossref, Semantic Scholar, ZBW EconBiz, Open Library, arXiv, Library of Congress, GESIS). Trigger whenever a user wants to check, verify, or validate ANY bibliography, reference list, or Literaturverzeichnis — their own or someone else's (a student's thesis, a colleague's paper, an AI-generated draft). Trigger on phrasings like "prüfe mein/dieses/das Literaturverzeichnis", "kannst du dieses Quellenverzeichnis checken", "check this/these references", "verify this bibliography", "sind diese Quellen echt / halluziniert", or whenever they paste or upload a list of references for checking. Also trigger when the user suspects fabricated sources, or asks whether a specific book, paper, or article actually exists. Use for any literature verification task, even a single source.

- Skill: `benedikt-e/literaturverzeichnispruefung` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add benedikt-e/literaturverzeichnispruefung`
- Raw SKILL.md: https://api.skillmd.com/api/skills/benedikt-e/literaturverzeichnispruefung/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- License: GPL-3.0-or-later
- Author: benedikt-e (https://skillmd.com/u/benedikt-e)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/benedikt-e/literaturverzeichnispruefung

---


# Literaturprüfung — Skill zur Zitations- und Literaturverzeichnisprüfung

Akademische Quellenangaben systematisch gegen live abgefragte bibliografische Datenbanken prüfen, um
Zitierfehler und KI-halluzinierte Quellen aufzudecken. Jeder Befund braucht eine kanonische
Datenbank-URL als maschinell überprüfbaren Beleg — keine Behauptung, einen Link.

**Grundregel:** Niemals aus dem Gedächtnis oder aus Trainingswissen verifizieren. Jede Klassifikation
erfordert eine Live-Abfrage mit anklickbarer Ergebnis-URL. Ohne diese URL gilt die Quelle als ungeprüft.

## ⭐ Verifikations-Kern (immer zuerst lesen, gilt für JEDE Quelle)

1. **Pflichtreihenfolge je Quelle:** DOI vorhanden → direkt auflösen (Standard: Crossref
   `works?filter=doi:…&select=…`, siehe api-endpoints.md). Sonst nach Typ:
   Artikel → **OpenAlex → Crossref** (beide mit `select=` und kleiner Trefferzahl, `rows=2–3`); ohne
   OpenAlex-Key bzw. nach gescheitertem Canary **Crossref-primär**. Deutsches Buch → **K10plus (DC)**
   → OpenAlex → DNB (lobid nur nach bestandenem Canary, siehe Routing).
   Kaskade **vollständig** durchlaufen; ein einzelner Fehlschlag einer DB ist kein Endergebnis.
2. **Vor jedem Nicht-Treffer-Urteil** (🔴 IV **oder** „nicht prüfbar"): die **Gegenprobe** ausführen —
   freie K10plus-Schlüsselwortsuche `query=pica.all%3DKERNTITEL_KEYWORDS+AUTOR_NACHNAME` (Bücher;
   dieses eine Muster, siehe api-endpoints.md → K10plus) bzw. Crossref
   `query.bibliographic=…&query.author=…&select=…` (Artikel). Bei **mehreren Autoren/Herausgebern**
   auch einen **zweiten Namen** als Suchterm probieren (`pica.all%3DZWEITER_NAME+KERNTITEL`).
   **Gültigkeit:** Eine Gegenprobe zählt nur als ausgeführt, wenn die Query Autor-Nachname UND
   Kerntitel-Keywords enthält; liefert sie eine dreistellige oder höhere Trefferzahl, war sie zu
   unspezifisch und gilt als NICHT ausgeführt (enger neu formulieren). Leerer
   Body → Retry mit **variierter** Query (siehe Step 3), dann nächste DB — **nicht** vorzeitig aufgeben.
3. **Festlegungspflicht:** Jede **gewöhnliche** Quelle (Buch, Artikel, Sammelbandkapitel) endet
   zwingend in **🟢 I / 🟡 II / 🟠 III / 🔴 IV**. Die Ausweich-Status sind eng begrenzt:
   
   - **🎓 FU** nur für echtes FernUni-Lernmaterial (nach voller Prozedur inkl. Buchausgaben-Suche),
   
   - **⚪ ?** nur für strukturell nicht katalogisierbare Sonderfälle (kein gewöhnliches Buch/Artikel),
   
   - **„technisch nicht prüfbar"** nur, wenn **ALLE** zuständigen DBs **technisch** fehlschlugen
     (kein valides Ergebnis von irgendeiner DB). Ein einzelner leerer Body (z. B. OpenAlex) bei sonst
     funktionierender DB ist **kein** Gesamt-Fehlschlag.
4. **Konsistenz:** Die Kategorie muss zur Abweichungsbeschreibung passen — 🟢 I nur bei „keine
   wesentlichen Abweichungen" (siehe Klassifikations-Gate, Step 5).

Alles Weitere (Spezialfälle, Routing-Details, Datenbank-Syntax) konkretisiert nur diese vier Punkte.

---

## Sprache

Erkenne die Sprache der vorherigen Nutzernachrichten und verwende sie durchgängig — für
Tabellenüberschriften, Hinweise, Fehlerbeschreibungen und den Abschlussbericht. Die Sprache der
Quellen selbst beeinflusst dies nicht.

---

## Eingabe

Kläre, wie das Literaturverzeichnis übergeben wurde:

- **Datei hochgeladen** (.pdf, .docx, .txt, .md): Datei lesen und den Literatur-/Quellenteil extrahieren.
- **Text eingefügt**: direkt verwenden.

Ist die Eingabe ein vollständiges Dokument, nur die Literaturliste extrahieren. Sollte der Umfang
**wirklich unklar** sein (z. B. mehrere Literaturabschnitte, oder es ist mehrdeutig, welcher Teil zu
prüfen ist), **keinen separaten Bestätigungs-Turn öffnen** — diese eine Umfangsfrage **in die
Step-0-Frage falten**, sodass der Nutzer Keys und Umfang in einem Zug beantwortet. Ist der Umfang
eindeutig, die Umfangsfrage ganz weglassen. Bei weniger als 3 Quellen alle auf einmal verarbeiten.
Bei längeren Listen alle Quellen in einem Durchgang prüfen — keine manuelle Bestätigung zwischen
Stapeln —, aber Rate-Limits abfangen (siehe api-endpoints.md).

---

## Optionen / Flags

Alle Flags sind optional. Ohne Angabe gilt das Standardverhalten.

- **`--fachgebiet <name>`** — Fachgebiet manuell setzen statt Auto-Erkennung. Werte:
  `sozialwissenschaften | wirtschaft | recht | stem | medizin | geistes | allgemein`.
  Siehe `references/database-routing.md`.
- **`--kontext fernuni`** — FernUniversität-Hagen-Handling erzwingen (siehe unten).
- **`--bibtex`** — Das intern erzeugte BibTeX des Verzeichnisses zusätzlich als herunterladbare
  `.bib`-Datei speichern (siehe Step 1b). Standardmäßig aus.
- **`--openalex-key <key>`** — Vom Nutzer bereitgestellter OpenAlex-API-Key. Wird als `&api_key=` an
  jede OpenAlex-Anfrage angehängt. **Ohne Key ist OpenAlex in vielen Agent-Umgebungen faktisch unbrauchbar**
  (schlüssellose Anfragen liefern einen leeren Body); die Sitzung fährt dann die Crossref-primäre Kaskade.
  **Sicherheit (harte Regeln):** Key niemals in eine gespeicherte Datei, einen Bericht, das
  Transparenz-Log, eine Zwischenstand-Datei oder eine angezeigte URL schreiben — `api_key=…` vor jedem
  Zitieren einer Query-URL entfernen.
- **`--s2-key <key>`** — Vom Nutzer bereitgestellter Semantic-Scholar-API-Key. Wird als HTTP-Header
  `x-api-key: <key>` bei jeder Semantic-Scholar-Anfrage mitgesendet; hebt das strenge Limit
  (100 Calls / 5 min) an. Optional. Gleiche Sicherheitsregeln wie oben (nur sitzungsweise, nie
  gespeichert, nie angezeigt).
- **`--base-key <key>`** — Vom Nutzer bereitgestellter BASE-API-Key (Bielefeld Academic Search Engine).
  Wird als `&apikey=` angehängt. **BASE ist OHNE Key nicht nutzbar** und wird dann gar nicht abgefragt.
  **Hartes Rate-Limit (1 Anfrage/Sekunde): höchstens EIN BASE-Aufruf pro Antwortschritt, niemals
  gebündelt oder parallel** (siehe Step 3 → „BASE — hartes Rate-Limit"). BASE ist ein OA-/Repositorien-
  Aggregator (graue Literatur, Hochschulschriften, Working Paper), **kein** Buch-/Verlagskatalog —
  Rolle und Grenzen siehe api-endpoints.md → BASE. Gleiche Sicherheitsregeln wie oben (nur sitzungsweise,
  nie gespeichert, nie angezeigt).
- **`--config <pfad>`** — Pfad zu einer **Konfigurationsdatei**, aus der API-Keys gelesen werden (statt
  sie einzeln per Flag oder in der Step-0-Frage zu nennen). Format und Auto-Erkennung siehe Step 0 →
  „Konfigurationsdatei". Der Skill **liest** die Datei nur und schreibt **niemals** Keys hinein.

**Drei Wege, Keys zu übergeben** (Reihenfolge = Priorität): (1) **direkt beim Aufruf** — als Flag oben
**oder** frei im Aufruftext genannt; (2) **Konfigurationsdatei** (`--config` oder eine auto-erkannte
Datei, siehe Step 0); (3) die **Step-0-Rückfrage**. Liegt über Weg 1 oder 2 bereits mindestens ein Key
vor, **entfällt die Step-0-Frage vollständig** — der Skill startet ohne erneutes Nachfragen.

---

## FernUni-Kontext (automatisch ausgelöst bei Erkennung)

Das FernUni-Handling wird **automatisch ausgelöst**, sobald eine Quelle ein FernUni-Signal trägt
(Studienbrief-/Lerneinheitsformat, Verlag/Ort „Hagen: FernUniversität"). Das Flag `--kontext fernuni`
ist nicht mehr nötig — es dient nur noch als expliziter Override, falls die Auto-Erkennung ein Signal
verfehlt.

Bei vorhandenem FernUni-Signal (automatisch oder per Flag):

- **Überprüfung versuchen** (die Quelle **nicht** vorab klassifizieren) — Prozedur in
  `references/category-rules.md` → „Studienbriefe und Lerneinheiten" anwenden.
- „Hagen: FernUniversität" als Verlagssignal behandeln.
- Wird das Material gefunden → regulär klassifizieren (🟢/🟡/🟠). Wird es trotz Versuch nicht gefunden →
  **🎓 FU** (FernUni-Lernmaterial, nicht überprüfbar) — niemals 🔴 IV.

Keine Bestätigungsfrage pro Quelle nötig; die Erkennung leitet die Quelle still durch die
FernUni-Verifikationsprozedur.

---

## Step 0 — API-Keys ermitteln (VOR der ersten Suche)

API-Keys können bei der Prüfung helfen (OpenAlex, Semantic Scholar, BASE). Sie sind **optional**. Bevor
irgendeine Datenbank abgefragt wird, **zuerst die Key-Quellen in dieser Reihenfolge prüfen** und erst
fragen, wenn keine davon einen Key liefert:

### Step 0a — Vorhandene Keys ermitteln (keine Rückfrage, wenn schon vorhanden)

1. **Direkt beim Aufruf übergeben?** Ein per Flag (`--openalex-key`/`--s2-key`/`--base-key`) **oder**
   frei im Aufruftext genannter Key (z. B. „mein OpenAlex-Key ist …", „hier mein BASE-Key: …") wird
   übernommen. Den frei genannten Key dem passenden Dienst zuordnen (Schlüsselwörter „OpenAlex",
   „Semantic Scholar"/„S2", „BASE").
2. **Konfigurationsdatei vorhanden?** Wenn `--config <pfad>` gesetzt ist, **oder** im Arbeitsverzeichnis
   bzw. unter den hochgeladenen Dateien eine Datei namens `literaturpruefung-keys.txt`,
   `literaturpruefung-keys.json`, `literaturpruefung.config.txt`/`.json` oder `.literaturpruefung-keys`
   liegt, **diese Datei lesen** und die Keys daraus übernehmen (Format siehe unten).
3. **Sonst:** die Step-0b-Rückfrage stellen.

**HARTE REGEL — keine erneute Rückfrage:** Liefert Quelle 1 **oder** 2 mindestens einen Key, **entfällt
die Step-0b-Frage vollständig**. Der Skill übernimmt die gefundenen Keys still und **beginnt sofort mit
Step 1** — kein „Hast du noch weitere Keys?", kein „Soll ich starten?". Fehlende Keys (z. B. nur
OpenAlex vorhanden, kein BASE) werden **nicht** nacherfragt; die betroffene Datenbank läuft dann ohne Key
bzw. inaktiv (BASE).

#### Konfigurationsdatei — Format

Die Datei wird **nur gelesen, nie geschrieben**. Einfaches, fehlertolerantes Schlüssel-Wert-Format
(eine Zeile je Key), z. B. als `literaturpruefung-keys.txt`:

```
# Literaturprüfung — API-Keys (optional). Diese Datei privat halten, nicht versionieren/teilen.
openalex = DEIN_OPENALEX_KEY
semanticscholar = DEIN_S2_KEY
base = DEIN_BASE_KEY
```

Parsing-Regeln (tolerant): Zeilen mit `#` oder `;` am Anfang sind Kommentare; leere Zeilen ignorieren;
Trenner ist `=` oder `:`; Groß-/Kleinschreibung der Schlüssel egal; führende/folgende Leerzeichen und
einfache/doppelte Anführungszeichen um den Wert entfernen. **Akzeptierte Schlüssel-Aliase:**
`openalex` (auch `openalex_key`, `openalex-api-key`); `semanticscholar` (auch `s2`, `semantic_scholar`,
`s2_key`); `base` (auch `base_key`, `base-api-key`). Endet die Datei auf `.json`, stattdessen ein
JSON-Objekt mit denselben Schlüsseln erwarten (`{"openalex": "...", "base": "..."}`). Ein
`.env`-Stil (`OPENALEX_KEY=...`) wird durch dieselben Aliase mitabgedeckt.

**Sicherheit:** Ein aus der Konfigurationsdatei gelesener Key wird **genauso** behandelt wie ein
sitzungsweise genannter Key — nur im Arbeitsspeicher gehalten, nie in Berichte, Logs, Zwischenstände
oder angezeigte URLs geschrieben. Der Pfad der Konfigurationsdatei darf genannt werden, ihr **Inhalt
(der Key) niemals**.

### Step 0b — Nur falls kein Key vorab vorlag: einmalig fragen

**Nur** ausführen, wenn weder Aufruf noch Konfigurationsdatei einen Key lieferten. **Einmal** (nicht pro
Quelle) fragen, kurz halten, dann mit der vorhandenen Antwort weiterarbeiten:

> Bevor ich mit der Prüfung beginne: Hast du API-Keys für eine der folgenden Datenbanken? Sie sind
> optional, verbessern aber Trefferquote und Tempo.
> 
> - **OpenAlex** — in vielen Agent-Umgebungen faktisch nötig; ohne Key liefern Anfragen oft einen leeren Body, mit Key
>   sofort valides JSON. (Kostenlos unter `openalex.org` → Settings → API.)
> - **Semantic Scholar** (optional) — hebt das strenge Rate-Limit (100 Calls / 5 min) an.
> - **BASE** (optional) — ergänzt graue Literatur, Hochschulschriften, Working Paper und Open-Access-
>   Inhalte. Nur mit Key nutzbar (kostenlose, nicht-kommerzielle Registrierung). Hinweis: Aus manchen
>   Agent-Umgebungen (geteilte Proxy-IP/User-Agent) blockt BASE die Anfragen; dann bleibt es trotz Key
>   inaktiv (der Canary erkennt das).
> 
> Du kannst den/die Key(s) hier nennen oder mit „nein/weiter" ohne Key fortfahren.

Verarbeitung der Antwort:

- Nennt der Nutzer einen OpenAlex-Key → wie `--openalex-key` behandeln (an jede OpenAlex-URL
  `&api_key=` anhängen, `mailto=` entfällt).
- Nennt der Nutzer einen Semantic-Scholar-Key → bei jeder Semantic-Scholar-Abfrage als Header
  `x-api-key: <key>` mitsenden.
- Nennt der Nutzer einen BASE-Key → wie `--base-key` behandeln (an jede BASE-URL `&apikey=` anhängen);
  BASE-Canary in Step 3 ausführen, hartes 1,5-s-Limit und serielle Ausführung einhalten.
- Kein BASE-Key → BASE **gar nicht** abfragen (auch keine prepared-link-Pflicht entfällt: der manuelle
  BASE-Suchlink darf weiter im Bericht stehen).
- Kein Key / „weiter" → ohne Key fortfahren; OpenAlex läuft dann über den Sitzungs-Canary (Step 3),
  bei Fehlschlag Crossref-primäre Kaskade. **Nicht** pro Quelle erneut nachfragen.

**Auto-Start (HARTE REGEL — gegen doppeltes Nachfragen):** Diese Key-Frage ist das **einzige und
letzte** Gate vor der Recherche. Sobald die Antwort vorliegt (Key **oder** „weiter"), **unmittelbar
mit Step 1 fortfahren** — in derselben Antwort, ohne weitere Rückfrage. **Verboten** ist jede zweite
Bestätigungsphase wie „Soll ich jetzt beginnen?", „Bitte um Geduld", „Ich starte gleich …" oder eine
erneute Scope-/Bereitschaftsfrage. Die Key-Antwort **ist** das Startsignal; ein zusätzliches „Okay,
leg los" des Nutzers darf **nicht** abgewartet werden. Wurde ein Key bereits **vorab** ermittelt
(Flag, frei im Aufruftext genannt **oder** aus einer Konfigurationsdatei, siehe Step 0a), entfällt die
Frage ganz und die Recherche beginnt direkt. Die Scope-Klärung (welcher Abschnitt geprüft wird) gehört,
falls überhaupt nötig, **in dieselbe** Step-0-Frage — nie in einen separaten Turn.

**Sicherheit (harte Regeln, gelten für ALLE Keys):** Keys werden nur für die laufende Sitzung im
Arbeitsspeicher gehalten. Niemals in eine gespeicherte Datei, einen Bericht, das Transparenz-Log,
eine Zwischenstand-Datei oder eine angezeigte URL schreiben — `api_key=…` bzw. den Header-Wert vor
jedem Zitieren einer Query-URL entfernen. Keys werden auch nicht in der dauerhaften Memory abgelegt.

---

## Step 1 — Jede Quelle parsen und einordnen

Für jede Quelle extrahieren:

- **Autor(en):** Nachname(n) für die Suche.
- **Jahr:** Erscheinungsjahr.
- **Titel:** nur Haupttitel (Untertitel für die Erstsuche weglassen — senkt Falsch-Negative).
- **Publikationstyp:** `journal-article` | `book` | `book-chapter` | `grey-literature`.
- **Identifikatoren:** DOI, ISBN, ISSN, falls im Original vorhanden.

Der Publikationstyp bestimmt, welche Datenbank-Kaskade in Step 2 verwendet wird.

### Step 1a — FernUni-Material erkennen und markieren (ohne Vorab-Verurteilung)

**Gilt nur für ECHTES FernUni-Lernmaterial** (Studienbrief, Lerneinheit/Kurseinheit; Ort/Publisher
„Hagen: FernUniversität"). Graue Literatur (Behörden-/Regierungs-/Parlamentsseiten, Pressemitteilungen,
Nachrichten, Koalitionsverträge, Projektberichte) fällt **nicht** hierunter, auch wenn sie nicht in
Bibliothekskatalogen steht — sie läuft über die Graue-Literatur-Prüfung (Step 2) und erhält I–IV.

Wenn Publisher/Ort einer Quelle das Muster `FernUniversität` enthält (`Hagen: FernUniversität`,
`FernUniversität in Hagen`, `FernUniversität Hagen`), die Quelle als **FernUni-Lernmaterial-Kandidat**
**markieren** — aber **nicht** vorab klassifizieren. Eine Überprüfung wird **immer versucht**
(FernUni-Verifikationsprozedur in `references/category-rules.md` → „Studienbriefe und Lerneinheiten"):

1. K10plus/DNB nach Titel + „FernUniversität", GESIS.
2. **Suche nach einer kommerziell verlegten Buchausgabe (PFLICHT):** FernUni-Lerneinheiten werden
   **häufig zusätzlich als reguläres Lehrbuch verlegt** (UTB, Nomos, Springer VS, Kohlhammer …),
   oft mit leicht anderem Titel und anderem Jahr/Auflage. Daher **immer** eine freie Schlagwortsuche
   `pica.all=KERNTITEL_KEYWORDS + AUTOR_NACHNAME` in K10plus (und OpenAlex/Crossref) absetzen — ohne
   den Zusatz „FernUniversität". Der zitierte Lerneinheits-Titel weicht dabei häufig vom Titel der
   verlegten Buchausgabe ab; deshalb breit über Kern-Keywords + Autor suchen, nicht über den exakten
   Lerneinheits-Titel.
3. Suche nach dem ggf. anderswo erschienenen Originaltext.

Auswertung der Überprüfung:

- **Gefunden** (Lerneinheit, Buchausgabe **oder** Originaltext in einem Katalog nachweisbar) → **regulär
  klassifizieren** (🟢 I / 🟡 II / 🟠 III je nach Metadatenabgleich; abweichender Titel/Jahr der
  Buchausgabe → 🟡 II/🟠 III mit Hinweis), mit kanonischem Link. Eine gefundene Buchausgabe ist **kein**
  🎓 FU.
- **Erst wenn ALLE drei Schritte — inkl. der freien Buchausgaben-Gegenprobe — erfolglos bleiben** →
  **🎓 FU** (FernUni-Lernmaterial, nicht überprüfbar), **niemals 🔴 IV**. Im „Belege & Nachschlagen"-
  Block die tatsächlich versuchten Suchen samt Links ausweisen, damit transparent ist, dass geprüft wurde.

Wenn der **Sammelband-Host** einer Quelle bereits geprüft und als 🎓 FU eingestuft wurde, erben alle
weiteren Kapitel aus demselben Host automatisch 🎓 FU (Sammelband-Cache) — keine erneute Suche.

`--kontext fernuni` und FernUni-Erkennung sind gleichwertig: Sobald ein FernUni-Signal erkannt wird,
greift diese Prozedur (Routing Teil D) — unabhängig davon, ob das Flag gesetzt
ist. Das Flag dient nur noch als expliziter Schalter, falls die Erkennung das Signal nicht aufgreift.

### Step 1b — Internes BibTeX aufbauen (Strukturierungsschritt)

Die geparsten Felder jeder Quelle in einen BibTeX-Eintrag serialisieren. Das standardisiert die Daten
für die API-Abfragen und lässt den **Eintragstyp das Routing steuern** (`@article` → Artikel-Kaskade,
`@book` → Buch-Kaskade, `@incollection` → Kapitel/Sammelbände, `@inproceedings` → Konferenz,
`@misc`/`@techreport` → graue Literatur). Siehe `references/database-routing.md` → Teil B.

**Harte Regel — verbatim, keine Korrekturen:** Das BibTeX **rein mechanisch aus dem Originaltext**
aufbauen. **Nichts** korrigieren, ergänzen, normalisieren oder „bereinigen" (nicht das Jahr, nicht
einen fehlenden Untertitel, nicht den Verlag). Der wörtliche Originalstring bleibt unverändert — er
ist die Spalte „Originalquelle". Verglichen wird stets **Original gegen Datenbank**, nie BibTeX gegen
Datenbank. Das BibTeX ist ein Strukturierungshilfsmittel, keine korrigierte Fassung.

Jedem Eintrag einen stabilen Citekey geben (z. B. `gergs2020`) für den internen Bezug.

**Flag `--bibtex`:** Wenn gesetzt, das BibTeX zusätzlich als `literaturverzeichnis_YYYY-MM-DD.bib` im
Arbeitsverzeichnis speichern und dem Nutzer den Pfad nennen. Ohne das Flag bleibt das BibTeX intern
(wird nicht gespeichert).

### Step 1c — Fachgebiet bestimmen (einmal für die ganze Liste)

Das Fachgebiet **einmal für das gesamte Verzeichnis** erkennen, oder aus `--fachgebiet` übernehmen,
falls angegeben. `references/database-routing.md` → Teil A folgen. Das erkannte Fachgebiet und die
resultierenden Datenbanken **ein einziges Mal** nennen und fortfahren; nur bei wirklich gemischten
Signalen für eine Bestätigung innehalten. **Niemals pro Quelle fragen.**

---

## Step 2 — Suchstrategie: welche Datenbanken, in welcher Reihenfolge

Niemals nach dem vollständigen Zitations-String verbatim suchen. In Autor + Jahr + 2–3 Kern-Titel-
Keywords zerlegen. Das vermeidet Falsch-Negative durch Zeichensetzung, weggelassene Untertitel oder
Encoding-Probleme.

**Feld-Semantik (HARTE REGEL):** Titel-Keywords stammen **ausschließlich aus dem `title`-Feld des
BibTeX** (Step 1b); der Autor gehört **ausschließlich** in den Autor-Index (`pica.per`,
`query.author`, lobid `contribution…`) bzw. bei OpenAlex mit in `search=`. **Niemals den Autornamen
in einen Titel-Index schreiben.** `pica.tit=Crozier Zwänge` liefert ein formal valides, aber
bedeutungsloses 0-Ergebnis (der Autor steht nicht im Buchtitel). Richtig:
`pica.tit=Zwänge kollektiven Handelns and pica.per=Crozier`.

**Die Kaskade ist in `references/database-routing.md` definiert** — für die exakte Datenbankreihenfolge
laden. Die Kaskade je Quelle ergibt sich aus:

1. **Publikationstyp** (BibTeX-Eintragstyp aus Step 1b) — der primäre Schalter (Routing Teil B).
2. **Fachgebiet** (aus Step 1c) — verfeinert und ergänzt Fach-Datenbanken (Routing Teil C).

**Rate-Limit-Prinzip:** Datenbanken in einer Kaskade stehen in **Prioritätsreihenfolge**. Von oben nach
unten abfragen und **beim ersten bestätigten Treffer stoppen** (Step 3). Die genaue Reihenfolge je Typ
und Fachgebiet steht in `references/database-routing.md`.

**Sitzungs-Caches (einmal suchen, mehrfach nutzen):** Führe während der Prüfung interne Listen, die vor
**jeder** Abfrage geprüft werden — bei Treffer wird der API-Call übersprungen:

- **Sammelband/Host-Volume-Cache:** Key = Autor + Jahr + Kurztitel, Value = Status
  (`confirmed`/`not_found`), PPN/DOI, Notiz. So wird ein von mehreren Kapiteln geteilter Sammelband
  (typisch in sozialwiss. Hausarbeiten) nur **einmal** gesucht.
- **Journal-ISSN-Cache:** Key = Zeitschriftenname, Value = ISSN(s) aus dem Crossref-Journals-Lookup.
  Mehrere Artikel derselben Zeitschrift lösen den ISSN-Lookup so nur **einmal** aus.
- **Negativ-Cache:** Bereits erfolglos gesuchte Werke/Muster nicht erneut abfragen.

**Dedupe vor der Suche:** Identische Einträge (gleicher Citekey/DOI/Titel, z. B. doppelt zitiert) vor
Welle 1 zusammenfassen — nur **einmal** prüfen, das Ergebnis auf alle Vorkommen mappen.

Schnellorientierung (volles Detail in der Routing-Datei):

- **Zeitschriftenartikel:** OpenAlex → Crossref → OpenAIRE (keyless) → (Semantic Scholar, nur mit Key) → Fach-DB (EconBiz/GESIS)
- **Deutsche Bücher / Sammelbände:** K10plus (DC) → OpenAlex → lobid (Canary) → DNB → (Open Library, nur ISBN)
- **Internationale Bücher:** K10plus → Open Library (nur ISBN) → OpenAlex → (Library of Congress)
- **Buchkapitel:** Host-Volume über K10plus → lobid (Canary) → DNB (zuerst Sitzungs-Cache prüfen; Sammelbände-Regel anwenden)
- **Preprints / STEM:** arXiv (Canary) → OpenAlex → Crossref
- **Deutsche Sozialwissenschaften:** **GESIS** per Websuche ergänzen: `site:search.gesis.org TITEL_KEYWORDS AUTOR_NACHNAME`
- **Graue Literatur (mit URL/Herausgeber):** Graue-Literatur-Prüfung (siehe unten) — **nicht** der Buchkaskade zuführen, **nicht** als ⚪/🎓 abtun.

### Graue-Literatur-Prüfung (Webseiten, Behörden-/Regierungs-/Parlamentsdokumente, Pressemitteilungen, Nachrichten, Koalitionsverträge, Projekt-/Forschungsberichte)

Graue Literatur wird **normal geprüft** — nur über einen anderen Kanal als Katalog-DBs, weil sie dort
strukturell nicht steht. Das Fehlen in K10plus/OpenAlex ist **kein** Befund.

1. **Hat die Quelle eine zitierte URL?**
   
   - **Ja:** Die URL mit `web_fetch` auflösen und prüfen, ob (a) die Seite lädt und (b) herausgebende
     Stelle, Titel/Gegenstand und — wo zitiert — das Datum zur Quelle passen. JS-Shell/leere Seite →
     Claude-in-Chrome statt `web_fetch` (siehe api-endpoints.md). Tote, aber via Web-Archiv/Herausgeber
     auffindbare Seite zählt als Beleg (mit Hinweis).
   
   - **Nein** (nur Herausgeber + Titel, z. B. „Koalitionsvertrag … Berlin"): über die Seite der
     herausgebenden Stelle bzw. eine gezielte Websuche nach Herausgeber + Titel + Jahr bestätigen.
2. **Berichte/Working Paper mit DOI/ISBN/Handle:** zusätzlich DOI-Resolve bzw. Katalog/Repositorium
   (z. B. econstor, SSRN, Projektseite) — wie bei regulären Werken.
3. **Klassifikation:** lädt/auffindbar und passend → 🟢 I (🟡/🟠 bei Abweichung wie falschem Datum,
   geändertem Seitentitel, abweichendem Herausgeber). URL tot **und** auch über die herausgebende
   Stelle/Titelsuche nicht bestätigbar → 🔴 IV (möglicherweise erfunden / falsche Fundstelle). **Nie**
   🎓 FU; ⚪ ? nur, wenn es gar keine URL/Fundstelle gibt und die Existenz strukturell nicht prüfbar ist.

---

## Step 3 — Abfrage ausführen

### URL-Disziplin (HARTE REGEL — häufigste Fehlerquelle)

Query-URLs werden **ausschließlich durch Kopieren der kopierfertigen Muster aus
`references/api-endpoints.md`** aufgebaut — **niemals aus dem Gedächtnis**. Vor der **ersten**
Abfrage an eine Datenbank in einer Sitzung MUSS deren Abschnitt in api-endpoints.md gelesen worden
sein. Hintergrund: Werden K10plus-URLs frei erfunden (Pfad `/sru` statt `/opac-de-627`, Indices
`tit=`/`aut=` statt `pica.tit`/`pica.per`), erscheint das 404 in `web_fetch` als **leerer Body** und
sieht exakt wie ein Datenbank-Ausfall aus. Folge: ganze Kaskade kollabiert, Fehlklassifikationen.

**Basis-URL-Kurzreferenz (nur diese Pfade existieren — keine anderen verwenden):**

| Datenbank           | Basis-URL                                                                         |
| ------------------- | --------------------------------------------------------------------------------- |
| OpenAlex            | `https://api.openalex.org/works`                                                  |
| OpenAIRE Graph      | `https://api.openaire.eu/graph/v1/researchProducts` (keyless; nur `pid`/`mainTitle`/`authorFullName`/`search` — falscher Param = leerer Body) |
| Crossref            | `https://api.crossref.org/works` · DOI-Resolve: `https://doi.org/`                |
| K10plus             | `https://sru.k10plus.de/opac-de-627` (⚠️ **NICHT** `/sru` — existiert nicht, 404) |
| DNB                 | `https://services.dnb.de/sru/dnb`                                                 |
| ZDB                 | `https://services.dnb.de/sru/zdb` (⚠️ **NIE** `zdb-katalog.de` — bot-geschützt)   |
| lobid               | `https://lobid.org/resources/search`                                              |
| Open Library        | `https://openlibrary.org/search.json`                                             |
| Semantic Scholar    | `https://api.semanticscholar.org/graph/v1/paper/search`                           |
| arXiv               | `http://export.arxiv.org/api/query`                                               |
| Library of Congress | `http://lx2.loc.gov:210/lcdb`                                                     |
| ZBW EconBiz         | `https://api.econbiz.de/api/v1/search`                                            |
| BASE (nur mit Key)  | `https://api.base-search.net/cgi-bin/BaseHttpSearchInterface.fcgi`                |

Query-Syntax (Indices, Parameter, Schemas) steht **nur** in api-endpoints.md — die Tabelle hier
ersetzt das Lesen nicht.

Für jede Datenbank der zutreffenden Kaskade:

1. Die Query-URL durch **Kopieren des dokumentierten Musters** aus `references/api-endpoints.md` bauen (siehe URL-Disziplin oben).
2. Antwort abrufen.
3. Parsen: Titel, Autor(en), Jahr, Verlag/Zeitschrift extrahieren und — entscheidend — die **datenbankspezifische persistente ID**.
4. Aus dieser ID die kanonische Proof-of-Work-URL bauen.

**Eine verifizierte Datenbank genügt**, um eine Quelle zu klassifizieren. Die Kaskade stoppt, sobald
ein bestätigter Treffer mit kanonischer URL vorliegt. Erst zur nächsten Datenbank weitergehen, wenn die
aktuelle keinen Treffer oder einen plausibel-aber-unsicheren Treffer liefert.

**Die kanonische URL muss auf das Werk selbst zeigen.** Eine URL zu einem Werk, das das Zielwerk
*zitiert*, ist kein gültiger Beleg. Prüfen, dass Titel und Autoren im aufgelösten Datensatz zur
geprüften Quelle passen.
**Das gilt ausdrücklich auch für Rezensionen und Sekundärquellen:** Eine Buchrezension, ein
zitierendes Werk oder eine Erwähnung in Sekundärliteratur ist **kein** Nachweis und darf **keine**
🟢/🟡-Klassifikation stützen. Ebenso unzulässig: 🟡 II als „existiert wahrscheinlich, aber nicht
indexiert" — gewöhnliche Bücher/Artikel müssen in einem Katalog **gefunden** werden (🟢/🟡/🟠)
oder sind 🔴 IV; bei rein technischen Ausfällen „technisch nicht prüfbar" (siehe
Klassifikations-Sperre unten).

**Rate-Limits (Handlungsregel, nicht Zeitvorgabe):** Ein Sprachmodell kann keine Sekunden „abwarten" —
maßgeblich ist daher **was** getan wird, nicht eine Wartezeit. Liefert eine Datenbank HTTP 429, sie in
diesem Schritt **nicht** sofort erneut anfragen, sondern **einmal in einem späteren Schritt** (nachdem
andere Quellen/Calls bearbeitet wurden) wiederholen. Schlägt es erneut fehl, im Transparenz-Log
vermerken und weitergehen.

### Robuste Ausführung — technischer Fehlschlag ≠ „nicht gefunden" (KRITISCH)

Dies ist die wichtigste Regel für verlässliche Ergebnisse (siehe api-endpoints.md → „Robuste Ausführung
& Fallback-Protokoll"):

- **Unterscheide** einen **technischen Fehlschlag** (leerer Body / nur URL zurück / kein JSON / HTTP 403
  `URL exceeds maximum length` / 4xx / 5xx / Timeout / JS-Shell) von einem **validen 0-Ergebnis**
  (wohlgeformte Antwort, die echte null Treffer meldet).
- **Bei technischem Fehlschlag:** bei 403/Länge die URL kürzen (OpenAlex: Autor-Filter raus → in
  `search=`, ggf. `mailto=` weg) und **einmal** erneut; sonst **einmal mit VARIIERTER Query** erneut
  (siehe Retry-Regel unten); dann **zur nächsten
  Datenbank der Kaskade** weitergehen. **Nicht** klassifizieren und **nicht** still auf WebSearch ausweichen.
- **Retry heißt variieren, niemals wortgleich wiederholen (HARTE REGEL):** Viele Agent-Umgebungen
  cachen `web_fetch`-Antworten pro URL — die **identische** URL erneut zu senden liefert denselben
  (auch denselben leeren) Body zurück und ist als Retry wertlos. Ein Retry MUSS die Query verändern,
  in dieser Reihenfolge: (1) **vollständigerer Titel** inkl. Stoppwörter/Untertitel-Anfang,
  (2) **zweiten Autor** in den Autor-Parameter aufnehmen bzw. auf ihn wechseln, (3) andere
  Kerntitel-Keyword-Mischung. Leere Bodies treten query-spezifisch reproduzierbar auf (mutmaßlich
  langsame Suchen mit sehr häufigen Wörtern); eine variierte Query auf dasselbe Werk trifft dann oft
  sofort.
- **Klassifikations-Sperre:** 🔴 IV oder ⚪ ? („nicht gefunden") nur, wenn **mindestens eine** Datenbank
  ein **valides** Ergebnis lieferte. „Technisch nicht prüfbar" gilt **nur, wenn ALLE für den Typ
  zuständigen DBs technisch fehlschlugen** — ein leerer Body **einer** DB (z. B. OpenAlex) bei sonst
  valider Antwort (Crossref/K10plus) ist **kein** Gesamt-Fehlschlag, sondern verlangt, die Kaskade
  weiter abzuarbeiten. Lagen nur technische Fehlschläge vor, im Bericht offen als „technisch nicht
  prüfbar – APIs nicht erreichbar" ausweisen (NICHT als ⚪ ?, NICHT als Halluzination).
  **Zusatz:** Ein 0-Ergebnis zählt nur, wenn die Query **feldsemantisch korrekt** war (Titel-Keywords
  aus dem Titelfeld, Autor im Autor-Index — siehe Feld-Semantik-Regel in Step 2). Ein 0-Ergebnis
  auf eine fehlgebaute Query ist wertlos.
  **BASE-Zusatz:** Ein **BASE-Nulltreffer für eine Monografie oder einen Zeitschriftenartikel zählt
  NICHT** als valides „nicht gefunden" — BASE deckt diese Typen nicht zuverlässig ab (OA-/Repositorien-
  Aggregator). Ein BASE-Treffer kann eine Quelle **bestätigen** (🟢/🟡), ein BASE-Miss allein darf
  **nie** Richtung 🔴 IV zählen. Maßgeblich für IV bleiben die Katalog-/DOI-Quellen (K10plus, DNB,
  Crossref, OpenAlex, lobid).
- **Gegenprobe-Pflicht vor 🔴 IV:** Bevor ein Buch oder Artikel 🔴 IV erhält, **eine** letzte
  Kontrollabfrage senden, die gegen Feldsemantik-Fehler robust ist: bei **Büchern** die K10plus **freie
  Schlüsselwortsuche** `query=pica.all%3DKERNTITEL_KEYWORDS+AUTOR_NACHNAME` (exakt dieses Muster,
  siehe api-endpoints.md → K10plus → freie Suche); bei **Artikeln** Crossref
  `query.bibliographic=KERNTITEL&query.author=NACHNAME&select=DOI,title,author,published,container-title&rows=2`.
  **Gültigkeitskriterium:** Die Gegenprobe muss Autor-Nachname UND Kerntitel-Keywords enthalten und
  eine überschaubare Trefferzahl liefern; ein „0 passende von 1000+ Treffern" auf eine unspezifische
  Query (nur ein Allerweltswort, nur ein Jahr, ohne Autor) ist KEINE ausgeführte Gegenprobe.
  Erst wenn eine so gebaute Abfrage 0 Treffer liefert, ist 🔴 IV zulässig. Ein „nicht gefunden" bei einem breit
  rezipierten Standardwerk zeigt fast immer eine fehlgebaute oder abgebrochene Abfrage an, keine
  fehlende Quelle.
- **Überdimensionierte Antwort = vergessenes `select=`:** Meldet eine Crossref-/OpenAlex-Antwort „zu
  groß"/viele KB und wird abgebrochen, war die Query **ohne** `select=`+`rows=2` gebaut. **Kein** Grund
  für „nicht prüfbar" — die **gleiche** Quelle mit `select=`+`rows=2` erneut abfragen.
- **Leerer Crossref-Body:** Retry-Protokoll ausführen — 1× mit **variierter** Query (vollerer Titel /
  Zweitautor, nie wortgleich), notfalls 1× ASCII —, dann OpenAlex/nächste
  DB — **nicht** vorzeitig „nicht prüfbar" vergeben.
- **Reprint/Container-Treffer = Existenznachweis:** Liefert die DB statt der Originalausgabe eine
  Nachdruck-/Sammelband-Version mit passendem Titel + Autor(en), gilt die Quelle als **existent**
  (🟢/🟡) — Originalvenue/-jahr ggf. per gezielter Query/DOI nachziehen, aber nicht als „nicht gefunden" werten.
- **Fällt OpenAlex aus, aktiv Crossref ansteuern** (kurze URLs) — nicht überspringen.

**Ist im Original ein DOI vorhanden:** Immer direkt auflösen — Standard ist der Crossref-Lookup
`GET https://api.crossref.org/works?filter=doi:[DOI]&select=…&rows=1` (funktioniert ohne
Request-Header und ohne Key; Muster in api-endpoints.md). Nur wenn das Fetch-Tool der Umgebung
Request-Header setzen kann, alternativ `GET https://doi.org/[DOI]` mit
`Accept: application/vnd.citationstyles.csl+json`. Prüfen, ob zurückgegebener Titel und Autoren
passen. Ein DOI, der zu einem anderen Werk auflöst, ist ein starkes Halluzinationssignal; ein bei
Crossref unbekannter DOI wird über OpenAlex nachgeprüft (DataCite-DOIs), bevor er als nicht
auflösbar gilt.

**Schlank abfragen — immer das leichteste Fieldset (siehe api-endpoints.md, Effizienz-Grundregeln):**
K10plus/DNB → `recordSchema=dc`/`oai_dc`, OpenAlex/Crossref → `select=`, DOI-Resolve → Crossref
`filter=doi:`+`select=` (bzw. CSL-JSON, nur mit Header-Unterstützung), Ergebnislisten auf
2–3 begrenzt. **Sparse-then-Full-Fallback:** Lässt ein schlank abgefragter Treffer ein Vergleichsfeld
vermissen, ist er mehrdeutig oder scheitert das Parsing, **genau diese eine Quelle** noch einmal voll
abrufen (ohne `select=` / mit MARCXML). Nie pauschal auf das fette Objekt zurückfallen.

### Parallele Ausführung in Wellen

**Parallelität ist eine Optimierung, keine Voraussetzung.** Unterstützt die Agent-Umgebung keine
nebenläufigen `web_fetch`-Calls aus einem Schritt (manche Backends serialisieren sie oder greifen mit
einem Ausführungszeitlimit ein), **dieselbe Kaskade rein sequenziell** abarbeiten — Quelle für Quelle,
Datenbank für Datenbank. Das **Ergebnis ist identisch**, nur die Laufzeit länger; Korrektheit und
Klassifikation hängen **nie** von der Nebenläufigkeit ab. Die folgenden Wellen sind also als
Beschleunigung zu lesen, wo sie möglich ist. (BASE bleibt in **jedem** Fall streng seriell, siehe unten.)

Sequentielle Einzelabfragen sind sonst der größte Zeitfaktor. Unabhängige Quellen teilen keine Daten und
können — sofern die Umgebung es zulässt — **gleichzeitig** abgefragt werden, mehrere `web_fetch`-Calls
in **einem** Schritt:

0. **Sitzungs-Canary (allererster Call, vor Welle 0):** Einen minimalen OpenAlex-Test-Call senden —
   **mit `api_key=`, falls `--openalex-key` gesetzt** — und zwar mit einem **sitzungseindeutigen
   Suchwort** statt eines konstanten Testworts:
   `works?search=canary-JJJJMMTT-hhmm&per_page=1[&api_key=…]` (Datum/Uhrzeit einsetzen).
   **Grund (HART):** Viele Agent-Umgebungen cachen `web_fetch`-Antworten pro URL; ein Canary mit
   immer gleicher URL kann aus dem Cache „gelingen", obwohl die Datenbank aktuell nicht erreichbar
   ist — und weist damit eine tote DB als lebendig aus. Ein einzigartiges Suchwort erzwingt einen
   echten Live-Call (das Suchwort darf 0 Treffer liefern; entscheidend ist wohlgeformtes JSON mit
   `meta`/`results`, nicht die Trefferzahl).
   Kommt kein wohlgeformtes JSON: Ohne Key ist das der **Normalfall in geteilten Agent-Umgebungen**
   (Keyless-Anfragen liefern leeren Body, siehe api-endpoints.md → OpenAlex). Die Key-Frage wurde bereits in **Step 0**
   gestellt — hier **nicht erneut** nachfragen: liegt kein Key vor, OpenAlex für die **gesamte Sitzung**
   deaktivieren und alle Artikel-Kaskaden Crossref-primär fahren. Das spart pro Quelle 1–2 tote Calls.
   **BASE-Canary (nur wenn `--base-key`/Step-0-Key vorliegt):** zusätzlich **einen** BASE-Test-Call
   `func=PerformSearch&query=canary-JJJJMMTT-hhmm&hits=1&format=json&apikey=…` senden (sitzungseindeutiges
   Suchwort aus demselben Grund; siehe api-endpoints.md → BASE).
   Kommt ein leerer Body (in geteilten Agent-Umgebungen der Normalfall — UA/IP-Block), BASE für die
   **gesamte Sitzung deaktivieren**, ohne erneute Nachfrage. Dieser eine Canary zählt bereits zum
   1,5-s-BASE-Takt.
1. **Welle 0 — Identifier-First (billigster, sicherster Treffer zuerst):** Alle Quellen **mit DOI oder
   ISBN** direkt auflösen, bevor irgendeine Titel/Autor-Kaskade startet. DOI → Crossref
   `filter=doi:`-Lookup; mehrere DOIs in **einem** Call bündeln — Crossref kommagetrennt
   (`filter=doi:A,doi:B`, ohne Key) oder OpenAlex (`filter=doi:a|b|c`, mit Key); **max. 5 DOIs** pro
   Call wegen URL-Limit. ISBN → K10plus/Open Library (`/isbn/`). Bestätigte Quellen fallen aus den
   teuren Wellen heraus.
2. **Welle 1 — gruppieren:** Die **verbleibenden** Quellen (ohne Identifier) parsen und nach Typ
   sortieren (Artikel, deutsche Monografien, internationale Monografien, Buchkapitel/Sammelbände,
   FernUni/Graue Literatur).
3. **Canary vor dem Fan-out:** Für jede **neue** Query-Form/Datenbank zuerst **EINEN** Test-Call senden
   und prüfen, dass wohlgeformtes JSON/XML kommt (auch hier keine in dieser Sitzung schon einmal
   gesendete URL wiederverwenden — Cache-Gefahr). Erst dann auffächern. Scheitert der Canary technisch,
   erst das Muster reparieren (URL kürzen) bzw. die DB für diese Welle überspringen — so verbrennt nicht
   eine ganze Welle an einem kaputten Muster.
4. **Welle 2 — parallele Erstabfragen:** Pro Welle 4–6 unabhängige Queries gleichzeitig (schlankes Fieldset).
5. **Welle 3 — parallele Nachfolgeabfragen:** Quellen ohne Treffer in der ersten Runde gesammelt mit
   erweiterten Parametern (nächste Datenbank der Kaskade / ohne Jahresfilter) nachsuchen.

**Rate-Limit-Regel:** Höchstens **3 gleichzeitige Calls pro einzelner Datenbank** (K10plus, DNB,
Crossref je getrennt zählen). Verschiedene Datenbanken dürfen parallel laufen. DNB besonders schonen
(siehe api-endpoints.md): DNB-Calls über mehrere Wellen strecken bzw. mit Calls anderer DBs abwechseln.

### ⛔ BASE — hartes Rate-Limit (KRITISCH, zwingend einzuhalten)

BASE erlaubt **maximal 1 Anfrage pro Sekunde**; bei Verstoß droht laut BASE der **Entzug des Keys ohne
Vorwarnung**. Da ein Sprachmodell keine Sekunden „abwarten" kann, wird das Limit **über die Handlung**
abgesichert, nicht über eine Zeitvorgabe — die folgenden Regeln übersteuern alle obigen Parallel-Regeln:

- **Höchstens EIN BASE-Aufruf pro Antwortschritt.** Der nächste BASE-Aufruf erst in einem **späteren
  Schritt**, nachdem das Ergebnis des vorigen vorliegt. So kann zwischen zwei BASE-Aufrufen technisch
  gar keine Sekunde unterschritten werden — unabhängig davon, wie schnell das Modell Token erzeugt.
- **NIEMALS bündeln oder parallelisieren.** Nie zwei BASE-Calls im selben Schritt, nie BASE in eine
  „Welle" mit anderen Calls aufnehmen. Der BASE-Canary ist bereits der erste solche Einzelschritt.
- **Sparsam einsetzen.** BASE nur für die Quellen abfragen, für die es laut Routing zuständig ist
  (graue Literatur, Hochschulschriften, Working Paper, OA-Inhalte) — nicht pauschal für jede Quelle.
- Diese Regeln gelten **zusätzlich** zur Key-Pflicht und zum Canary: ohne erfolgreichen BASE-Canary
  wird BASE gar nicht abgefragt.

### Zwischenstand-Speicherung (alle 10 Quellen)

Nach Abschluss **jeder 10. verifizierten Quelle** den aktuellen Stand als Datei speichern:
`literaturpruefung_zwischenstand_YYYY-MM-DD_NvonM.md` im Arbeitsverzeichnis. Inhalt:

1. alle bisher klassifizierten Quellen mit Kategorie + Begründung,
2. alle gefundenen PPNs/DOIs/Canonical-URLs,
3. der Sammelband-Sitzungscache,
4. die noch offenen Quellen mit ihren BibTeX-Citekeys.

**⛔ KEINE KEYS in die Zwischenstand-Datei (oder irgendeine gespeicherte Datei):** Ein „Sitzungs-Status"-
Block darf den Aktiv/Inaktiv-Zustand einer Da

…(truncated)