[MITTEL] Seitenanker systematisch um ~4-6 PDF-Seiten verschoben — auch bei perfekten Eval-Werten

[TillQuandel]

Prio: MITTEL

Befund: Die PDF-Seitenangaben in Fußnoten-/#page=-Ankern generierter Notes sind systematisch um ~4–6 Seiten zu niedrig — pipeline-weit, unabhängig von der Eval-Qualität der Note. Belege aus dem Data-Governance-Lauf 2026-07-17 (Klingenberg/Weber 2025, 90.619 Wörter, Run 20260717-131248, Notes im OneDrive-Ordner „2026-07-17 Data-Governance-Lauf" + C:\tmp\wt-run-dg\generative\.cache\eval\baseline\...):

1. vault__Datenanforderungsmanagement.md: Note zitiert „S. 206"; die wörtliche Fundstelle („Der oder die fachliche Data Steward ist die zentrale Kontaktstelle…") steht real auf PDF-S. 211 (Bild 7.19). PDF-S. 206 behandelt einen anderen Abschnitt (Bild 7.16, Datenmanagement-Organisation).
2. vault__Datenprinzipien.md (beste Note des Laufs: 0 % Halluzination, 100 % Coverage): Fußnoten nennen PDF-S. 164–167, der reale Abschnitt 7.2.2 „Datenprinzipien" liegt auf PDF-S. 170–172.

Wichtig zur Einordnung: Die Quelle hat keine /PageLabels, die Notes tragen korrekt das [physical-pages]-Flag („Seiten als PDF-Position"). Der zitierte Wert ist aber weder die korrekte PDF-Position (211) noch die gedruckte Seite (197) — sondern ein dritter, zu niedriger Wert. Der Versatz ist nicht konstant (~4–6 Seiten in verschiedenen Notes).

Wirkung: Alle Seitenanker generierter Notes sind unzuverlässig — für Tills Zitier-Workflow (BA-Kontext, Nachschlagen von Belegstellen) der kritischste Fehlertyp, weil er auch bei perfekten Eval-Werten auftritt: Das Eval prüft Content-Treue gegen den Volltext, nie ob die angegebene Seite die Fundstelle ist. Deshalb blieb der Fehler in allen bisherigen Serien unentdeckt.

Fix-Richtung: Ursache im Anker-Seiten-Mapping lokalisieren (Kandidaten: _page_at_word_map/Seiten-Marker-Zuordnung im Fenster-Snippet-Bau, anchor_page_numbers-Pfad, frontmatter-strip-Offset — bei einem 90k-Wörter-Dokument mit 418 Chunks kumulieren Mapping-Fehler). Repro-Basis: die zwei o.g. Notes mit exakten Soll/Ist-Seiten. Danach prüfen, ob eine Seiten-Korrektheits-Stichprobe eval-seitig sinnvoll ergänzbar ist (separates Follow-up, kein Muss).

Quelle: Quellentreue-Kontrolle Data-Governance-Lauf 2026-07-17 (Stichprobe 4 Notes gegen PDF, pdftotext-verifiziert).

[TillQuandel]

Konkrete Ausgangshypothese aus der #345/#346-Planungsanalyse (2026-07-18), zweifach code-verifiziert (Plan-Agent + Codex-Review + unabhängiger Fable-Review):

pdf_to_pages() (generative/pipeline/pdf_chunker.py:181-185) verwirft ohne nutzbare /PageLabels leere Seiten VOR der Marker-Nummerierung — der [S. N]-Marker im Text ist damit die Position unter den nicht-leeren Seiten. anchor_page_numbers()/physical_pages_by_anchor() (pdf_chunker.py:123-142, genutzt von der Eval- und Anker-Seite) nummerieren dagegen über den physischen Seitenindex (num = i+1). Die Divergenz wächst mit jeder übersprungenen Leerseite — das erklärt einen nicht-konstanten, mit der Dokumenttiefe wachsenden Versatz, exakt das hier gemeldete Symptom (~4-6 Seiten, keine feste Konstante).

Verschärfend beim Klingenberg-Referenz-PDF (Fable-Review, empirisch): _usable_page_labels liefert None wegen des römisch nummerierten Frontmatters — das Buch fällt also genau in den divergenten No-Labels-Pfad, zusätzlich zum ~14-Seiten-Frontmatter-Offset zwischen gedruckter und physischer Zählung.

Repro-Vorschlag: Für die zwei belegten Fälle aus dem Issue (Datenanforderungsmanagement „S. 206"→real PDF-S. 211; Datenprinzipien „S. 164-167"→real 170-172) die Zahl der von pdf_to_pages verworfenen Leerseiten vor der jeweiligen Fundstelle zählen — stimmt sie mit dem Versatz überein, ist die Hypothese bestätigt und der Fix klar (einheitlicher Seiten-Namespace zwischen Text-Markern und Anker-Auflösung).

Hinweis: Der #345-Plan (Outline-Anker) umgeht diesen Bug bewusst per expliziter Namespace-Konvertierung, fixt ihn aber nicht — Scope-Disziplin, der Fix gehört hierher.