Promote develop → main (2026-05-09 10:57 UTC) #21
In neuem Issue referenzieren
Einen Benutzer sperren
Branch "develop" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
Automatischer Promote-Trigger via AegisSight Promote-UI. Commits: 15
Bislang liefen factcheck + analyze parallel via asyncio.gather. Folge: Lagebild konnte Aussagen treffen, die der Faktencheck im selben Refresh als contradicted markiert. Inkonsistenz zwischen Lagebild-Tab und Faktencheck- Tab; im PDF/DOCX-Export schon kritisch. Variante 1 aus der Diskussion: strikt sequenziell, mit Fallback bei Faktencheck-Fail (Refresh bricht NICHT ab, Lagebild laeuft dann ohne Faktenkontext wie bisher, ein Logeintrag dokumentiert den Fallback). Aenderungen: - analyzer.build_fact_context_block(): neuer Helper, baut den GEPRUEFTE-FAKTEN-Block aus existing_facts + neuen/aktualisierten Fakten. Status-Domaenen adhoc/research vereinheitlicht zu Bestaetigt / Umstritten / Unbestaetigt / Entwicklung. Max 20 Fakten, sortiert nach Status-Prioritaet desc und sources_count desc. Bei leerer Eingabe leerer String -> Fallback-Pfad. - analyzer.analyze() / analyze_incremental(): neuer Optional-Parameter fact_context_block (default leer, Backward-Compat). 4 Prompt-Templates bekommen {fact_context_block}-Platzhalter sowie eine AUSSAGE-DISZIPLIN- Sektion: bestaetigte Fakten als Geruest, Umstrittenes explizit machen, Unbestaetigtes klar einordnen, kein Spekulieren ueber ungedecktes. - orchestrator: asyncio.gather durch sequenzielle Logik ersetzt. Faktencheck zuerst, Pipeline-Step 6 done direkt nach dem Aufruf (count_value ist Schaetzung; finale DB-Zahlen stehen spaeter). Lagebild danach (Step 7) mit fact_context_block. _do_analysis-Closure um den Parameter erweitert, kein toter Inline-Block. - spaeteres _pipe_done(factcheck) entfernt -- der Step wird jetzt frueher geschlossen, der spaetere Persistierungsblock laesst ihn unberuehrt. UI-Pipeline zeigt automatisch sequenzielle Aktivitaet statt beide Steps gleichzeitig -- keine Frontend-Aenderung noetig. Latenz pro Refresh steigt um die factcheck-Dauer. Bewusst akzeptiert: Konsistenz vor Geschwindigkeit.- src/services/source_classifier.py: classify_source(db, id) ruft Haiku mit strukturiertem Prompt (4 Achsen + state_affiliated + country + Konfidenz) und schreibt Vorschlaege in proposed_*-Spalten. bulk_classify(db, limit) iteriert sequenziell ueber unklassifizierte Quellen. - API-Endpoints (alle hinter Auth, globale Quellen nur fuer org_admin): - GET /api/sources/classification/stats - GET /api/sources/classification/queue - POST /api/sources/{id}/classification/approve (proposed_* -> echte Felder) - POST /api/sources/{id}/classification/reject (proposed_* loeschen) - POST /api/sources/{id}/classification/reclassify (sofort, ~3-5s) - POST /api/sources/classification/bulk-classify (BackgroundTask) - scripts/migrate_sources_classification.py: CLI-Wrapper fuer Bulk-Migration zur einmaligen Erstbestueckung aller Bestandsquellen. Sample-Test auf Staging steht aus. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>