Orchestrator ruft init_db() nie auf — frische ATOMIC_DB_PATH fuehrt zu stillen Best-effort-DB-Warns

[TillQuandel]

Befund aus der realen E2E-Abnahme von PR #227 (2026-07-12, --dry-run mit isolierter ATOMIC_DB_PATH auf frischem Pfad):

[warn] DB-Write fehlgeschlagen: no such table: note_evals

Die DB-Datei wird angelegt (4096 Bytes, nur SQLite-Header), aber kein Schema: generative/orchestrator.py ruft db.init_db() an keiner Stelle auf (per Grep verifiziert — identisch auf master und dem #227-Branch, also KEINE Refactor-Regression). Alle Orchestrator-DB-Writes (pipeline_runs-Insert, note_evals via Stage-8) sind best-effort und degradieren still zu Warnungen — der Lauf „funktioniert", hinterlässt aber keinerlei DB-Buchführung.

Wirkung

• Jeder Lauf gegen eine frische ATOMIC_DB_PATH (E2E-Abnahmen, tests/test_e2e_baseline.py mit tmp-DB, künftige Nutzer-Erstläufe!) verliert seine DB-Zeilen still — dieselbe Fehlerklasse wie die Trace-/DB-Buchführung: Insert-Lücke bei deaktiviertem Inline-Eval, Test-Traces in runs/, total_tokens-Diskrepanz #198-Insert-Lücke (Läufe ohne DB-Zeile verschwinden aus versionsgefilterten Ansichten).
• Für Endnutzer (lokal-first-Tool, Erstinstallation ohne vorhandene DB) wäre das ein echter Datenverlust-Pfad, sobald die DB nicht durch andere Werkzeuge (Dashboard/run_eval) vorab initialisiert wurde.

Fix-Richtung

Idempotenter db.init_db(db.DB_PATH)-Aufruf beim Orchestrator-Start (Schema ist CREATE TABLE IF NOT EXISTS + _add_column-Migrationen — mehrfacher Aufruf kostet nichts). Danach Warn-Pfad beibehalten (echte I/O-Fehler bleiben best-effort). Regressionstest: Orchestrator-Startpfad mit frischer tmp-DB → pipeline_runs/note_evals existieren.

[TillQuandel]

Zweite Facette desselben Root-Cause, mit Produktions-Impact (Fund des Lauf-Kontrolleurs, 2026-07-12 abends):

Nicht nur frische DBs bleiben ohne Schema — auch bestehende DBs bekommen neue Spalten-Migrationen nie, weil der produktive Schreibpfad db.get_db() nutzt und die _add_column-Migrationen nur in db.init_db() laufen. Konkret: Nach dem Merge von PR #220 (neue Spalte n_extracted, heute ~13:30) schlug der pipeline_runs-Insert jedes realen Laufs still fehl:

[warn] DB-Write fehlgeschlagen: table pipeline_runs has no column named n_extracted

Beleg: letzte erfolgreiche pipeline_runs-Zeile 20260712-002220 (v0.3.140); der Lauf 20260712-202536 (v0.3.143, zettelkasten-primer) hat KEINE Zeile — sein Trace ist damit genau die Waisen-Klasse aus #198/#226 (zählt u. a. nicht mehr in die Lifetime-Token-KPI).

Sofort-Behebung durchgeführt (operativ, kein Code): Live-DB per db.init_db(db.DB_PATH) idempotent migriert (Backup vorab: C:/tmp/atomic_analytics-bak-20260712-vor-migration.db; Zeilenzahlen 118/572 unverändert, n_extracted jetzt vorhanden). Folgeläufe buchen wieder korrekt.

Für den Code-Fix heißt das: Der init_db()-Aufruf beim Orchestrator-Start (Fix-Richtung oben) schließt BEIDE Facetten — Erstinitialisierung UND Schema-Nachzug nach Merges. Der Lauf 20260712-202536 bleibt bewusst ohne nachgetragene DB-Zeile (kein Hand-Insert außerhalb des normalen Pfads); falls Buchführung gewünscht: PDF erneut laufen lassen.