Der erste Lauf mit den Gegenproben (Lage 64) zeigte, dass der Faktencheck
selbst jetzt ehrlich arbeitet. Der erste Durchgang liess 3 von 10 Behauptungen
offen, also 30 Prozent und damit genau das Niveau des Anthropic-Wegs. Vorher
waren es acht Laeufe hintereinander null.
Danach hob die Nachhak-Runde alle drei wieder auf bestaetigt, und der Lauf
endete erneut ohne eine einzige Unsicherheit.
Ursache war ein Denkfehler im Aufbau. Die zweite Runde war ein Entweder-oder.
Entweder wurde nachbelegt oder es lief die Belastungsprobe. Sobald nachbelegt
wurde, stand am Ende wieder alles auf bestaetigt und niemand prueft das nach.
Jetzt laufen beide Schritte nacheinander. Erst wird nachbelegt, danach greift
die Belastungsprobe, wenn kaum noch etwas offen ist. Sie prueft damit genau die
frisch vergebenen Bestaetigungen. Damit sie wirklich neu sucht, meldet die
Nachhak-Runde ihre Anfragen zurueck und die Belastungsprobe meidet auch diese.
Der Weg ueber die Anthropic-CLI bleibt unveraendert. 254 Pruefungen laufen ohne
Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der EU-Faktencheck bestaetigte praktisch jede Behauptung. Ueber alle Laeufe
seit Lage 42 lag der Anteil offener Punkte bei 6 Prozent, beim Weg ueber die
Anthropic-CLI bei 31 Prozent. In acht aufeinanderfolgenden Laeufen zur
Ceuta-Lage war er exakt null, achtmal zehn Behauptungen, zehnmal bestaetigt.
Bei derselben Lage bewerteten beide Wege dieselben Aussagen verschieden. Der
Anthropic-Weg stufte "22 EU-Laender kritisieren Spanien" mit sechs Quellen als
unbestaetigt ein, der EU-Weg dieselbe Aussage mit vier Quellen als bestaetigt.
Mehr Quellen und trotzdem vorsichtiger, das ist kein Zufall, sondern Bauart.
Drei Ursachen, drei Aenderungen.
1. Die Belegsuche kannte nur Bestaetigung. Alle Anfragen waren stuetzend
formuliert, wer so sucht findet auch nur Stuetzendes. Ein Anteil der
Anfragen (EU_VERIFY_COUNTER_SHARE, Vorgabe 0.3) ist jetzt eine Gegenprobe
und sucht gezielt nach Dementi, Richtigstellung, abweichenden Angaben und
der Darstellung der Gegenseite. Die Treffer sind im Kontext als
[GEGENPROBE] gekennzeichnet.
2. Das Modell konnte Belege nicht wirklich pruefen. Die Belegsuche lief mit
abgeschaltetem Volltext, das Modell sah je Treffer nur Ueberschrift und
Auszug. Ein Artikel zum Thema wurde damit zum Beleg fuer eine konkrete
Zahl. Bis zu EU_VERIFY_FULLTEXT_QUERIES Anfragen holen jetzt den
Artikeltext. Dazu die Ansage, dass ein Treffer, der nur das Thema erwaehnt,
kein Beleg ist, und dass eine Angabe, die praeziser ist als ihre Quelle,
nicht traegt.
3. Die zweite Runde lief nur in eine Richtung. Sie belegte offene Punkte nach,
und wenn nichts offen war, lief sie gar nicht. Ausgerechnet der Fall "alles
bestaetigt" blieb ungeprueft. Jetzt folgt dort eine Belastungsprobe. Sie
sucht ausschliesslich Gegenproben zu den staerksten Behauptungen und darf
Bestaetigungen zuruecknehmen, aber niemals vergeben. Zurueckgestuft wird
bei Widerspruch, bei Dementi, wenn die Belege die konkrete Angabe gar nicht
nennen, wenn die Behauptung praeziser ist als ihre Quellen, oder wenn nur
eine einzige Stelle berichtet. Ausserdem darf die Nachhak-Runde einen Status
jetzt auch absenken, wenn die Nachrecherche der Behauptung widerspricht.
Dabei fiel ein Robustheitsmangel auf. Scheiterte die zweite Runde, etwa weil
die Suche nicht erreichbar war, ging der gesamte Faktencheck verloren statt nur
die Zusatzpruefung. Die zweite Runde ist jetzt gekapselt, das Ergebnis des
ersten Durchgangs bleibt in jedem Fall erhalten.
Der Weg ueber die Anthropic-CLI bleibt unveraendert. Neu sind 26 Pruefungen,
insgesamt laufen 250 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Befunde aus dem Bericht zu Lage 60 vom 02.08.2026, alle in der Semantik
von Faktencheck und Lagebild.
1. Eine Behauptung trug eine Wertung, die das eigene Lagebild widerlegt. Im
Faktencheck stand bestaetigt, die Migranten haetten Ceuta "freiwillig"
verlassen. Drei Zeilen darueber berichtet dasselbe Dokument, dass die
Behoerden zur Umkehr aufforderten, mit Abschiebung drohten und Soldaten
verbliebene Personen zusammentrieben. Wertende Zusaetze gehoeren jetzt nur
in die Behauptung, wenn genau dieser Zusatz belegt ist.
2. Eine korrigierte Zahl stand als Spanne. "Mindestens 57 bis 67 Tote"
praesentiert einen ersetzten und einen aktuellen Stand als gleichwertige
Bandbreite. Der Bericht vom Vortag hatte denselben Sachverhalt noch als
Verlauf aufgeloest, was methodisch richtig ist. Korrigierte Werte werden
jetzt als Zeitreihe dargestellt; eine Spanne bleibt der Fall, in dem
verschiedene Stellen gleichzeitig verschiedene Werte erheben, dann mit
Zuordnung. Die Regel steht auch in den drei Analyse-Vorlagen und in der
Kachel Neueste Entwicklungen, weil die Formulierung dort entsteht.
3. Der Faktencheck bestaetigte zehn von zehn Behauptungen. Ein Raster, das nie
zu einem anderen Ergebnis kommt, transportiert keine Pruefinformation. Der
Auftrag verlangt jetzt, auch strittige, schwach belegte oder unterschiedlich
dargestellte Aussagen aufzunehmen, ohne dazu etwas zu erfinden.
Neu sind 4 Pruefungen, insgesamt laufen 224 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Suchphase endete in jedem beobachteten Lauf mit "Treffer-Obergrenze 60
erreicht" nach Runde 2. Die ersten beiden Runden erfassen breit und fuellten
den Korb, die dritte Runde, die gezielt Luecken schliessen soll, lief damit
nie. Genau diese Runde bringt aber das, was in den Berichten fehlte: die
Position des eigenen Landes, die Reaktion der Institutionen, den rechtlichen
Rahmen.
Der harte Gesamtstopp war eine Ueberkorrektur. Er kam aus einem frueheren Fix
gegen Leerrunden: War der Korb voll, befragte die Schleife weiter das teuerste
Modell, ohne noch etwas aufnehmen zu koennen. Das Problem war aber nicht die
Rundenzahl, sondern dass spaete Runden keinen Platz mehr hatten.
Jetzt drei Aenderungen:
1. Kontingent je Runde (EU_RESEARCH_MAX_NEW_PER_ROUND, Vorgabe 25). Die frueher
Runden koennen den Korb nicht mehr allein fuellen, fuer die spaeteren bleibt
Platz frei.
2. Verdraengung statt Abbruch. Ist der Korb voll und eine spaetere, gezieltere
Runde bringt einen Treffer, weicht der schwaechste Treffer einer frueheren
Runde: ohne Volltext, ohne Textauszug, aus der fruehesten Runde. Treffer mit
Volltext werden nie verdraengt.
3. Abbruch nur noch bei echter Saettigung. Bringt eine ganze Runde keinen
einzigen neuen Treffer, ist das Thema ausgeschoepft und die Schleife endet.
Der Kostenschutz des frueheren Fixes bleibt damit erhalten, ohne die
Vertiefung zu verhindern.
Dazu bekommt die dritte Adhoc-Runde einen eigenen Auftrag. Bisher wiederholte
sie den Text der zweiten ("Luecken schliessen und vertiefen"), jetzt fragt sie
ausdruecklich nach der fehlenden Seite der Lage und verbietet die Wiederholung
des Hauptereignisses.
Neu sind 10 Pruefungen, darunter der Regressionsschutz gegen Leerrunden in
neuer Form. Insgesamt laufen 216 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Vier Befunde aus dem Vergleich vom 02.08.2026, sortiert nach Wirkung.
1. Mehrwort-Suchbegriffe fielen im RSS-Abgleich durch. Dieselbe Lage lieferte
je nach Titel 79 oder 17 Treffer. Die Keyword-Erzeugung liefert bei
politisch formulierten Titeln Phrasen ("migrationskrise spanien",
"aufnahmeverfahren eu"), das Matching verglich sie als starre Zeichenfolge.
Die Schlagzeile "Migrationskrise in Spanien" enthaelt "migrationskrise
spanien" nicht, wegen des Wortes dazwischen. Aus 53 Artikeln wurden so 16.
Eine Phrase trifft jetzt, wenn alle ihre Bestandteile im Text vorkommen,
unabhaengig von Reihenfolge und Abstand. Die Genauigkeit bleibt erhalten,
nur die starre Reihenfolge faellt weg.
Dazu der Auftrag an die Keyword-Erzeugung: Einzelwoerter statt Phrasen, und
die harten Eigennamen der Lage sind Pflicht. Bei den betroffenen Laeufen
fehlte "ceuta" komplett, dafuer stand "europol migration" in der Liste, was
den Europol-Feed anzog und sieben themenfremde Pressemitteilungen
einbrachte, die der Topic-Filter danach wieder aussortieren musste.
2. Dubletten im Quellenverzeichnis. Lage 56 fuehrte 30 Eintraege fuer 28
Adressen, zweimal dieselbe tagesschau-Meldung unter je zwei Nummern.
Ausgerechnet die strittigste Behauptung, der offene Brief der 22 Staaten,
stuetzte sich damit auf "3 Quellen", von denen zwei derselbe Artikel waren.
Gleiche Adresse heisst jetzt ein Eintrag, Verweise auf die entfernte Nummer
werden auf den behaltenen umgebogen. Verglichen wird ohne Schema, www und
Endschraegstrich.
3. Die Zeitleiste wird deterministisch sortiert. Im selben Bericht sprang der
letzte Eintrag von 12:44 zurueck auf 17:47. Der Auftrag verlangt die
Sortierung zwar vom Modell, im prominentesten Kapitel darf sie aber nicht
von dessen Sorgfalt abhaengen. Gegenprobe an Lage 56: 23:23, 22:09, 17:47,
16:58 statt des Sprungs ans Ende.
4. Weiterleitungen zaehlen als ein Beleg. Sie verbergen ihr Zielmedium, also
laesst sich nicht behaupten, dass dahinter verschiedene Redaktionen stehen.
Die bisherige Einzelzaehlung stellte den Anthropic-Weg rechnerisch besser:
in Lage 57 standen 10 ausgewiesene Belege fuer 7 Haeuser, weil vier der elf
Adressen news.google.com-Weiterleitungen waren.
Gegenprobe an beiden gespeicherten Laeufen: Lage 56 zeigt 28 statt 30
Verzeichniseintraege, beide Berichte zaehlen lueckenlos, die Zeitleiste ist
sortiert.
Neu sind 26 Pruefungen, insgesamt laufen 206 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Am 01.08.2026 lieferte Bedrock waehrend eines Laufs ServiceUnavailableException.
Botocore versuchte es dreimal in fuenf Sekunden und gab auf, die
Web-Source-Selektion fiel ersatzlos aus. Im Bericht war davon nichts zu sehen,
der Lauf galt als vollstaendig. Gemessen sind es zwei betroffene Aufrufe bei
rund 340, also 0,6 Prozent, aber jeder Vorfall kostet einen ganzen
Pipeline-Schritt.
Der Fehler ist auch keiner unserer Quote. ServiceUnavailableException ist ein
503, AWS hat also gerade keine Kapazitaet fuer das Modell. Unsere Meldung
sagte trotzdem "Rate-Limit", weil der Code beide Faelle in einen Topf warf.
Aendert sich damit:
1. Geduldiges Wiederholen. Kapazitaets- (503), Kontingent- (429) und
Verbindungsfehler werden nach 5, 15 und 30 Sekunden erneut versucht. Diese
Dellen dauern typischerweise unter einer Minute, unsere bisherigen fuenf
Sekunden lagen genau im ungeguenstigsten Fenster. Stufen ueber
BEDROCK_RETRY_WAITS einstellbar.
2. Zwei Bremsen gegen lange Laeufe. Gewartet wird nur, wenn die Wartezeit ins
Zeitbudget des Aufrufs passt (die Wartezeit zaehlt gegen dasselbe
asyncio-Budget, und die Haiku-Planungsaufrufe haben nur 120 Sekunden), und
nur solange das Wartebudget des Refreshs reicht (BEDROCK_RETRY_BUDGET_S,
Vorgabe 120 Sekunden). Ein Lauf kann sich dadurch um hoechstens zwei
Minuten verlaengern.
3. Ursachen werden getrennt benannt. Im Log steht jetzt "hat keine freie
Kapazitaet" oder "meldet ausgeschoepftes Kontingent" statt pauschal
"Rate-Limit". Nach aussen bleibt beides die Kategorie rate_limit, damit die
Retry-Steuerung des Orchestrators unveraendert greift.
4. Stoerungen werden sichtbar. Waehrend einer Wartezeit meldet die Oberflaeche
"KI-Dienst hat keine freie Kapazitaet, neuer Versuch in 15 Sekunden", sonst
sieht die stehende Anzeige wie ein Haenger aus. Nach dem Lauf steht eine
Zusammenfassung im Refresh-Protokoll, auch wenn der Lauf sonst glatt
durchlief.
5. botocore laeuft im Modus 'adaptive' statt 'standard'. Es bremst sich bei
Drosselung selbst ein und deckt die Sekunden ab, unsere Schleife die
Zehnersekunden.
Zeitliche Wirkung, gemessen am EU-Lauf der Ceuta-Lage (252 Sekunden, 15
Bedrock-Aufrufe): im stoerungsfreien Fall null, im betroffenen Lauf rund eine
Minute mehr. Bei 0,6 Prozent Fehlerrate je Aufruf trifft das etwa jeden
elften Lauf, im Mittel ueber alle Laeufe rund zwei Prozent.
Gegenprobe mit einem echten Bedrock-Aufruf ueber den geaenderten Pfad: Antwort,
Verbrauch und Kosten unveraendert, keine Stoerung protokolliert.
Neu sind 23 Pruefungen, insgesamt laufen 179 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Block 2 der Auswertung des Ceuta-Vergleichs vom 01.08.2026. Der Faktencheck der
EU-Fassung zeigte dort drei Fehler, die alle dieselbe Wurzel haben: Der Status
behauptete eine Belegtiefe, die niemand nachgerechnet hat.
1. Die Zaehlung war kaputt. Das Muster fuer die Quellenzaehlung war
r'https?://' ohne den Rest der Adresse, findall lieferte also eine Liste aus
"https://"-Bruchstuecken und len(set(...)) ergab immer 1 oder 2. Daher stand
im Bericht eine Behauptung als BESTAETIGT mit 1 Quelle, obwohl vier Haeuser
in der Evidenz standen, und der gesamte Faktencheck der Anthropic-Fassung
wies durchgehend 1 bis 2 Quellen aus. Die Adresse wird jetzt vollstaendig
erfasst.
2. Gezaehlt wird nach Medienhaus, nicht nach Fundstelle. Sechs France24-Treffer,
davon vier Videofassungen derselben Meldung, sind ein Haus. Grundlage ist die
registrierbare Domain aus services/media_registry.py. Weiterleitungsportale
bekommen keine gemeinsame Identitaet, hinter news.google.com koennen
beliebige Zeitungen stecken. Nachgerechnet an Lage 53 sinken die Angaben von
9 auf 6, von 8 auf 4 und von 7 auf 5 Belege.
3. Neue Nachbedingung. pruefe_belegtiefe stuft jeden Fakt ab, dessen Status mehr
behauptet als vorliegt: confirmed braucht zwei, established drei unabhaengige
Haeuser. Ein Primaerbeleg (Originalzitat im Interview, amtliche Mitteilung,
Urteil) traegt allein, dafuer liefert das Modell jetzt "evidence_type". Damit
verschwindet auch die Unterkonfidenz der Gegenprobe, in der ein ZDF-Interview
als unbestaetigt galt, obwohl der Kritisierte dort selbst spricht.
4. Die Nachhak-Runde stuft "developing" nicht mehr hoch. Sie hatte die
Behauptung "Der Ausloeser ist weiterhin unklar" auf BESTAETIGT gesetzt, weil
developing in der Statusordnung die niedrigste Stufe ist. Eine Unklarheit
laesst sich nicht bestaetigen. Ausserdem rechnet die Runde die Belegzahl nach
dem Hochstufen neu und nimmt die Stufe zurueck, wenn die Belege sie nicht
decken.
5. Widerspruch und Widerlegung sind getrennt. "contradicted" meint laut Auftrag
Belege, die einander widersprechen, wurde aber als "Widerlegt" angezeigt. Im
Bericht stand deshalb die sachlich zutreffende Spanne von 50.000 bis 60.000
Grenzuebertritten als widerlegt, obwohl die Evidenz woertlich sagt "Die
Zahlen variieren je nach Quelle". Jetzt: contradicted = "Widersprüchlich",
der neue Status "false" = "Widerlegt" und setzt einen entkraeftenden Beleg
voraus. Angepasst in Bericht, Oberflaeche, beiden Sprachdateien, Farben und
Statusordnung.
6. Ein verbindlicher Regelblock haengt an jedem Faktencheck-Auftrag
(bewertungsregeln()): Unabhaengigkeit heisst verschiedene Medienhaeuser,
Agenturuebernahmen zaehlen einmal, unterschiedliche Zahlen verschiedener
Erhebungsstellen sind kein Widerspruch sondern eine Spanne mit Zuordnung,
und Aussagen ueber den Kenntnisstand ("Der Ausloeser ist unklar") sind keine
pruefbaren Behauptungen und gehoeren nicht in den Faktencheck.
Die Aenderungen wirken auf beide Modellwege. Die Fixtures in test_eu_factcheck
liefern jetzt Belege aus mehreren Haeusern, weil eine einzelne Quelle keine
Bestaetigung mehr traegt.
Nachgerechnet an beiden gespeicherten Laeufen: kein Fakt wird durch die neue
Nachbedingung abgestuft, die Belegzahlen werden aber durchgehend ehrlicher.
Neu sind 27 Pruefungen, insgesamt laufen 156 ohne Netzzugriff und ohne Kosten.
Offen: Die Oberflaechen-Aenderungen (components.js, app.js, style.css, i18n)
sind noch nicht in den Lokal-Fork portiert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Recherchebericht der EU-Fassung enthielt seit zwei Laeufen nur noch den
Abschnitt ZUSAMMENFASSUNG, 1513 statt der ueblichen mehreren tausend Zeichen.
Die Abschnitte HINTERGRUND, AKTEURE, AKTUELLE LAGE, EINSCHAETZUNG und
QUELLENQUALITAET fehlten vollstaendig.
Ursache. Das Modell lieferte zuerst ein knappes JSON, bemerkte den Fehler
selbst ("Wait, I need to include the full briefing content in the summary
field. Let me redo this properly with all sections") und haengte danach eine
zweite, vollstaendige Fassung an. Unsere Auswertung nahm das erste Objekt und
verwarf alles danach. Der Bericht war also da, wir haben ihn weggeworfen.
Behoben. json_utils bekommt extract_json_objects und extract_json_arrays, die
alle vollstaendigen Bloecke einer Antwort liefern statt nur den ersten. Der
Analyzer waehlt daraus den Bericht mit dem laengsten summary, der Faktencheck
die Liste mit den meisten Fakten. Beide protokollieren, wenn mehrere Fassungen
auftauchen, damit der Fall sichtbar bleibt. Die bisherigen Einzelabfragen
extract_json_object und extract_json_array bleiben unveraendert, damit sich an
den uebrigen Aufrufstellen nichts aendert.
Gegenprobe an der echten Antwort aus Lauf 50. Vorher 1513 Zeichen mit einem
Abschnitt, jetzt 8189 Zeichen mit allen sechs.
Neu sind 16 Pruefungen, insgesamt laufen 96 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Vergleichslauf zur Innenministerkonferenz (Lage 49) zeigte, dass der
verbesserte Faktencheck zwar zehn Fakten lieferte, davon aber nur drei
uebrig blieben. Die Ursachen lagen in drei nachgelagerten Stellen.
1. Quellenzuordnung stufte alle zehn Fakten herab.
Durch den groesseren Belegblock stuetzt das Modell seine Fakten jetzt
staerker auf die europaeische Suche als auf die gespeicherten Meldungen.
Es zitiert dabei die Belegnummern statt vollstaendiger Adressen. Die
Quellenzuordnung suchte daraufhin vergeblich nach passenden Meldungen und
stufte jeden Fakt herab. Im Vergleich: Lauf 45 hatte null Herabstufungen,
Lauf 44 eine, Lauf 49 zehn von zehn.
Behoben an zwei Stellen. Die Belegsuche gibt die gefundenen Quellen jetzt
einzeln zurueck, der Faktencheck reicht sie an die Zuordnung durch, und
der Auftrag verlangt ausdruecklich die vollstaendige Adresse je Beleg.
2. Duplikatpruefung loeschte sieben von zehn Fakten.
Das Clustering warf inhaltlich verschiedene Beschluesse in eine Gruppe,
weil viele Behauptungen gleich beginnen. Es gab keinerlei Absicherung, bei
kleinen Faktenmengen entschied das Modell sogar voellig allein.
Zwei Sicherungen greifen jetzt. Eine Gruppe, die mehr als 40 Prozent aller
Fakten umfasst, wird verworfen. Und jeder Loeschkandidat muss dem
behaltenen Fakt auch rechnerisch aehnlich sein, Grenze 0,55 im selben Mass
wie im Vorfilter. Beide Werte sind ueber Umgebungsvariablen einstellbar.
3. Leerrunden in der Recherche.
War die Treffer-Obergrenze erreicht, brach nur die innere Schleife ab. Die
Rundenschleife lief bis zum Ende weiter und befragte jedes Mal das teuerste
Modell, ohne noch eine einzige Suche auszufuehren. Das kostete rund 0,17
USD je Durchgang, bei drei Durchgaengen etwa 0,50 USD pro Aktualisierung.
Der Weg ueber die Anthropic-CLI bleibt unveraendert. Neu sind 16 Pruefungen,
darunter der nachgebildete Fall aus Lage 49, insgesamt laufen jetzt 80
Pruefungen ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Faktencheck ueber Bedrock und staan lieferte spuerbar weniger belegte
Fakten als der bisherige Weg ueber die Anthropic-CLI. Ursache war die Bauart.
Der bisherige Weg sucht waehrend der Pruefung selbst und kann bei duenner
Beleglage nachfassen, die EU-Fassung bekam dagegen einen festen, vorab
beschafften Stapel Belege und hatte genau einen Versuch.
Drei Aenderungen schliessen die Luecke.
1. Mehr Belege je Pruefung. Statt 3 Anfragen mit je 3 Treffern laufen jetzt
7 Anfragen mit je 6 Treffern, und bis zu 14 statt 8 Pruefpunkte gehen in
die Planung ein. Gleiche Quellen werden nur einmal in den Kontext gelegt.
2. Punktbezogene Planung. Das planende Modell ordnet jeder Suchanfrage zu,
welche Behauptung sie belegen soll, statt allgemein zum Thema zu suchen.
3. Echte Nachhak-Runde. Bleiben nach der Pruefung mindestens zwei
Behauptungen unbelegt, wird fuer genau diese noch einmal gesucht, mit
anderen Anfragen als zuvor, und nur diese Punkte werden neu bewertet.
Ein Status wird dabei nur angehoben, nie gesenkt, und faellt die Runde
aus, bleiben die Fakten unveraendert.
Die Nachhak-Runde greift in allen drei Pruefwegen, also bei der Erstpruefung,
der inkrementellen Pruefung und der Pruefung in Themengruppen. Gruppen nutzen
kleinere Suchmengen, da sie parallel laufen und je nur ein Teilthema abdecken.
Alle Mengen sind ueber Umgebungsvariablen einstellbar.
Der Weg ueber die Anthropic-CLI bleibt unveraendert, das sichern sechs
Regressionstests ab. Neu sind zwei Testdateien mit zusammen 55 Pruefungen,
die ohne Netzzugriff und ohne Kosten laufen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beobachtet am 31.07.2026 auf Staging: Modelle schliessen deutsche Zitate
gelegentlich mit einem geraden Anfuehrungszeichen, das das JSON an dieser
Stelle bricht. Die Folgen waren still und teuer:
- Lagebild von Lage 47 brach mitten im Satz ab (738 statt ~4000 Zeichen),
weil der Regex-Fallback nur bis zum Stoerzeichen rettete
- ein kompletter Recherche-Durchlauf von Lage 45 ging verloren
- sechs weitere Durchlaeufe fielen auf die verlustbehaftete
Einzelobjekt-Rettung zurueck
Betroffen war vor allem der EU-Weg (Opus 4.6), der CLI-Weg aber ebenfalls.
Neu: src/json_utils.py repariert solche Antworten, indem es beim Durchlauf
mitfuehrt, ob eine Zeichenkette offen ist, und ein Anfuehrungszeichen maskiert,
auf das kein gueltiger JSON-Fortsetzer folgt (Komma nur dann als Ende, wenn
danach wirklich ein Wert oder Schluessel beginnt). Roh eingebettete
Zeilenumbrueche werden ebenfalls maskiert. Repariert wird ausschliesslich als
Rueckfallebene, nachdem der normale Parser gescheitert ist, gueltiges JSON
bleibt unangetastet.
Eingebunden in analyzer, factchecker und researcher. Zusaetzlich meldet der
Analyzer jetzt als ERROR, wenn der letzte Fallback ein erkennbar
abgeschnittenes Lagebild liefert, statt das still hinzunehmen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Im EU-Modus laufen jetzt auch Faktencheck und Lagebild komplett ueber Bedrock,
damit gibt es dort keine CLI-Aufrufe mehr. Der Faktenchecker bekommt vorab
eine gezielte staan-Stuetzsuche (eu_call_with_search: Haiku plant
Verifikations-Queries zu offenen Behauptungen, Treffer wandern als
Kontextblock in den Prompt und werden als Zweitquellen zitiert). Das Lagebild
arbeitet im EU-Modus rein auf dem Meldungsbestand, die EU-Recherche hat
unmittelbar davor gesammelt. Alle fuenf Aufrufstellen (Erst-/inkrementeller
Faktencheck, Gruppen-Verifikation, Erst-/inkrementelle Analyse) haben die
Weiche, der CLI-Modus bleibt unveraendert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
busy_timeout von 5s auf 30s (zwei gleichzeitig schreibende Lanes) und
'database is locked' im Orchestrator als transienter Fehler mit Retry
statt als permanenter Abbruch. Gefunden im Doppelspur-Paralleltest
(Lage-Summary-Update kollidierte mit der Schreiblast der zweiten Lane).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Im EU-Modus laeuft die Recherche jetzt europaeisch: agents/eu_researcher.py
steuert eine Schleife aus Bedrock-Planung (Opus, EU-Profile) und staan-Suchen
(services/staan_client.py, Suche + Volltexte via full_content=markdown,
Pflicht-Domain-Ausschlussliste je Anfrage). Bildet die 4-Phasen-Tiefenrecherche
nach und liefert exakt das JSON der bisherigen CLI-WebSearch, Parsing und
Filter in researcher.search bleiben unveraendert. Anti-Halluzination: nur URLs
aus echten staan-Treffern werden akzeptiert; published_at nur wenn aus Inhalt
oder URL ableitbar (staan liefert keine Daten).
Doppelspur im Orchestrator: Lane-Schluessel ist jetzt (Organisation, Backend),
Aufloesung zentral in _resolve_ai_backend (Lage > Org-Setting > ENV). CLI- und
EU-Lauf derselben Organisation laufen gleichzeitig, gleiche Backends seriell.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zweiter Modellweg ueber AWS Bedrock (EU-Inferenzprofile Frankfurt), umschaltbar
je Lage (incidents.ai_backend) > Organisation (org_setting ai_backend) > global
(ENV AI_BACKEND, Default cli). Neue Datei agents/bedrock_client.py (Converse
API, nur eu.-Profile, Token-zu-USD-Umrechnung ueber BEDROCK_PRICING, gleiche
Fehlerkategorien wie das CLI). Routing zentral in call_claude; Aufrufe mit
WebSearch/WebFetch laufen bis zur staan-Schleife (Phase 2) weiter uebers CLI.
Migration: Spalte incidents.ai_backend. requirements: boto3.
Hinweis Promote: boto3 muss im Live-venv installiert werden.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Portierung aus dem Lokal-Fork (AegisSight-Monitor-Local, Commit d2b9168,
per Cherry-Pick übernommen und an den Server-Stand angepasst).
- Feste Sätze je Aktion (BILLING_MODE=flat) statt echter Kosten geteilt
durch cost_per_credit. Sätze auf die am 23.07.2026 beschlossenen
Verkaufswerte gesetzt. Live-Lauf 45, Recherche je Durchlauf 40,
Studio-Bausteine 12, Chat/Beschreibung/Globe 1. Per ENV überschreibbar,
der alte Modus bleibt als BILLING_MODE=actual erhalten.
- Abrechnungsperiode. licenses.credits_period trennt monthly von total,
träger Monatsreset bei der nächsten Lizenzprüfung, optionaler Übertrag
(credits_rollover, gedeckelt auf ein Monatskontingent). Bestandslizenzen
ohne Periodenmarke behalten ihren Verbrauch.
- Hard-Stop gegen das verfügbare Monatskontingent (Kontingent plus
Übertrag) statt gegen das Lebenszeit-Total.
- Warnschwelle budget_warning_percent (Default 80 Prozent) wird erstmals
ausgewertet, einmalige Meldung an alle aktiven Nutzer der Organisation.
- DB-Migration additiv und idempotent (credits_period, credits_period_start,
credits_rollover, credits_carried, budget_warning_sent, unlimited_budget).
- /api/auth/me liefert credits_available als Bezugsgröße plus
credits_period, das Credits-Widget zeigt "Credits diesen Monat".
- Wortlaut überall Credits (nicht Guthaben/Einheiten), docs/ABRECHNUNG.md
auf den Online-Stand gebracht.
Abweichungen zur Fork-Vorlage. Die Takt-Änderungen (Untergrenze 30 Min,
Kostenvorschau im Anlege-Dialog, Fork-Commit 5b0b578) sind bewusst NICHT
enthalten, die Sätze stehen auf 45/40 statt der Fork-Defaults 24/33.
Getestet gegen eine Kopie der Staging-DB, 20 Prüfungen bestanden.
Migration, Flat-Buchung adhoc/research/chat, Warnschwelle einmalig,
Hard-Stop, Monatsreset, Übertrag gedeckelt, Bestandslizenz ohne Marke.
Die vier Live-Lizenzen stehen auf unlimited_budget und sind unbeeinflusst.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fall-Chat und Ereignis-Timeline, alles ueber Claude, strikt fallorientiert.
incidents.py:
- GET /{id}/events: Aktivitaets-Timeline (article_ingest/refresh/analysis/chat_qa/source_change)
- POST /{id}/ask: Fall-Chat/RAG mit Guardrails:
* tools=None (kein Netz/kein Werkzeug) = zentrale Anti-Exfil-Abwehr (GitLost)
* nur Materialien DIESES Falls (scope=alle entfaellt), [n]-Zitate, strikt aus Materialien
* Claude-Vorauswahl der relevanten Artikel statt lokalem Embedding (kein lokales Modell)
* _escape_prompt_content + Ausgabe-Leak-Filter + EchoLeak-Haertung (externe Bilder/Links/URLs raus)
* Verbotsliste: kein Backend/App/Modell/Anbieter, kein Fremd-Fall
* chat_qa in incident_events protokolliert
- Recherche-Angebot: liefert die Materialien die Frage nicht, haengt der Analyst einen
needs_research-Block an (focus + description_addition, NUR aus der Frage abgeleitet).
- POST /{id}/clarify (nur auf Nutzer-Bestaetigung): Beschreibung ergaenzen + fokussierte
Folge-Recherche AUSSCHLIESSLICH zur Frage (Researcher title=focus/description=frage),
url-dedupliziert in den Fall. Laeuft als Hintergrund-Job (stage_runners.start_job).
stage_runners.py: generischer start_job() fuer Hintergrund-Jobs (run-status-sichtbar).
api.js: clarify(). studio.js + studio.css: Angebot rendern, bestaetigen, run-status pollen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Backend fuer die modularen Studio-Pipeline-Bausteine, alles ueber Claude.
DB (additiv, idempotent):
- Tabellen incident_events + fact_check_runs (+ Indizes)
- Funktion log_incident_event()
- Spalten incidents.summary_at, incidents.executive_summary, articles.geoparsed_at
agents/stage_runners.py (neu): isolierte Bausteine analyze + factcheck auf dem
vorhandenen Bestand, komplett neu, Historie bleibt (Snapshot/fact_check_runs).
orchestrator.py: collect_only in die Lane-Multi-Tenant-Queue eingebaut (enqueue_refresh
4-Tupel, _worker-Entpacken, Multi-Pass-Gate, _run_refresh-Signatur + Analyse/FC-Skip).
Zusaetzlich summary_at beim Schreiben des Lagebilds gestempelt (Studio-Freshness).
incidents.py: Endpunkte POST /{id}/run/{stage} (collect|analyze|factcheck),
GET /{id}/run-status, GET /{id}/freshness, GET /{id}/factcheck-runs[/{run_id}].
Busy-Check auf Online-Orchestrator (_current_tasks), Tenant-Zugriffspruefung.
Kein lokaler LLM-Unterbau, kein lokales Modell. /ask + /events folgen in Phase 3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ersetzt die globale Warteschlange mit einem einzelnen Worker durch
Per-Tenant-Lanes: jede Organisation bekommt eine eigene Queue und einen
eigenen Worker-Task, die unabhaengig und parallel laufen. Lanes werden
lazy angelegt und bei Leerlauf (60s) wieder beendet.
- Skalarer Zustand (_current_task, _cancel_event) -> Maps pro incident_id
(_current_tasks, _cancel_events); _queued_ids/_cancel_requested bleiben
global (IDs sind lane-uebergreifend eindeutig).
- enqueue_refresh/cancel_refresh: Signatur unveraendert, routen intern per
tenant_id in die passende Lane. Oeffentliche Lagen (tenant_id NULL) in
fester PUBLIC_LANE.
- Optionales Ventil ORCHESTRATOR_MAX_PARALLEL (Default 0 = unbegrenzt)
begrenzt bei Bedarf gleichzeitige Recherchen ueber alle Lanes.
- /refreshing-Endpoint auf _current_tasks-Map umgestellt, Response-Format
unveraendert (pro Tenant laeuft weiterhin hoechstens eine Lage).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Folgeregel zum Neu-am-Fix: verbietet Telegramm-Verkuerzungen
(Stichwort + [Nr]) und Auffangbloecke ohne Aussage (Fruehere Belege
[...]). Jede Quellennummer muss an einem vollstaendigen Satz haengen,
am Abschnitts- oder Lagebild-Ende keine reine Quellennummern-Liste.
Der inkrementelle Analyse-Prompt liess das LLM neue Erkenntnisse als
datierte Changelog-Bloecke (Neu am DD.MM.) anhaengen, die nie eingefaltet
wurden. Beim Iran-Lagebild summierten sich so 151 solcher Bloecke. Punkt 3
fordert jetzt das Einarbeiten in den thematischen Abschnitt; zusaetzliche
STRUKTUR-Regel loest bestehende Neu-am-Bloecke auf. Die chronologische Sicht
bleibt der separaten Kachel Neueste Entwicklungen vorbehalten.
Folgefix zu 952df87. Der Translator-Block laeuft post-summary bei jp_demo
40+ Min und war bisher fuer das Frontend unsichtbar und fuer den Watchdog
ein blinder Fleck (kein Pipeline-Step-Eintrag).
Aenderungen:
- pipeline_tracker.py: neuer Step 'translate' zwischen 'summary' und 'qc'
(DE+EN Label/Tooltip). Bewusst conditional sichtbar: erscheint nur, wenn
fremdsprachige Artikel ohne DE-Uebersetzung vorliegen UND
translator_enabled fuer die Org an ist.
- orchestrator.py: Translator-Block umrandet mit _pipe_start('translate')
und _pipe_done('translate', count_value=uebersetzt, count_secondary=
pending). Translator-Fehler schliesst Step trotzdem sauber ab.
Bedingung 'pending_translations and translator_enabled' ersetzt das
alte 'pending_translations' - skipped den Block sauber wenn Org-Override
deaktiviert (war vorher redundant in translate_articles selbst).
- main.py: ORPHAN_IDLE_LIMIT 30->60 Min, ORPHAN_HARD_LIMIT 90->120 Min.
Deckt jp_demo Translator-Phase (beobachtet bis 41 Min) mit Puffer ab,
ohne echte Haenger durchzulassen.
Resultierend: Frontend zeigt den Uebersetzungs-Schritt mit Fortschritt
(uebersetzt/gesamt). Watchdog killt nicht mehr vorzeitig.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
X-Accounts werden analog zu Telegram als Quelle (source_type=x_account)
konfiguriert und pro Lage ueber include_x zugeschaltet. Der Scraper
(feeds/x_parser.py, twscrape) liest Account-Timelines, optional ueber
einen HTTP-Proxy mit Fallback auf direkten Abruf ueber die Server-IP.
- DB-Migration include_x, Pydantic-Modelle, incidents-Router
- Orchestrator-X-Pipeline plus Haiku-Account-Vorselektion
- sources-Router /x/validate, x_account-Typ in Stats und Frontend
- Lage-Einstellungen: X-Toggle neben international und Telegram
- twscrape als Abhaengigkeit
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Damit die Pipeline das aktuelle Bild einfaengt, nicht nur das relevanteste
(oft Monate alt). Bei der Test-Lage Qilin war der neueste Artikel 7 Wochen
alt, die Masse 6-7 Monate — weil Google-News-Volltextsuche nach Relevanz
rankt, nicht nach Datum.
- build_news_search_feeds: neuer Parameter recency_days. Wenn gesetzt, wird
der Google-News-Operator "when:Nd" an die Query gehaengt — der Feed liefert
nur Artikel der letzten N Tage. Eigene Domain-Gruppe '...-recent'.
- orchestrator._rss_pipeline: baut jetzt ZWEI Suchfeed-Saetze — einen
Kontext-Feed (alle Zeiten) und einen Frische-Feed (when:14d). Beide laufen
durch dieselbe Pipeline, Dedup entfernt Ueberschneidungen.
- rss_parser._fetch_feed: relevance_score bekommt einen Aktualitaets-Bonus
(<=3d +0.35, <=14d +0.20, <=60d +0.05) bzw. -Malus (>180d -0.15, >365d
-0.30). Damit ueberleben frische Artikel den Domain-Cap statt von alten
verdraengt zu werden.
Nur adhoc-Pfad betroffen — research-Lagen ueberspringen die RSS-Pipeline
ohnehin und behalten ihre volle historische Tiefe.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Zwei Fixes aus der jp_demo-Verifikation:
1. Geoparsing — Länder mit Centroid statt Hauptstadt
Bisher bekam ein Land die Koordinaten seiner Hauptstadt. Damit landeten
alle "Japan"-Marker exakt auf Tokyo (35.69, 139.69) und die Karte
suggerierte faelschlich ein Ereignis in der Hauptstadt. Neue Tabelle
_COUNTRY_CENTROIDS (37 Laender) verortet ein Land in seiner geografischen
Mitte (Japan: 36.20, 138.25). Laender ohne Centroid-Eintrag fallen auf die
Hauptstadt zurueck.
2. Recall — Eigennamen in den Google-News-Suchfeed erzwingen
Beim ersten Refresh fehlt die Headlines-Historie, daher kamen die GNews-
Such-Keywords aus der Feed-Selektion. Haiku legt Eigennamen (z.B. "Qilin")
in die en-Liste, die ja-Liste hatte nur Allgemeinbegriffe — die ja-Query
suchte ohne "Qilin". build_news_search_feeds stellt nicht-englischen
Sprach-Queries jetzt die 2 wichtigsten en-Keywords voran (Eigennamen
kommen auch in fremdsprachigen Artikeln lateinisch vor). Damit ist schon
der erste Refresh spezifisch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Recall-Problem: Die Pipeline durchsuchte nur ~28 feste site:-RSS-Feeds plus
Claude-WebSearch. Japanische Security-Vendor-Blogs, Fachportale und
Regionalmedien (Cybertrust, ITmedia, INTERNET Watch, Reuters Japan ...)
tauchten in keinem festen Feed auf. Bei der Test-Lage "Qilin Ransomware
Japan" fand die Pipeline 20 Kandidaten — eine generische Google-News-JP-
Suche zum selben Thema liefert 49.
Fix: researcher.build_news_search_feeds baut pro Refresh einen Google-News-
Volltext-Suchfeed je Sprache (news.google.com/rss/search?q=keywords&hl=..&gl=..).
Query = Top-4-Keywords der jeweiligen Sprache aus der Keyword-Extraktion.
Der Orchestrator haengt diese Feeds an die selektierten site:-Feeds an; sie
laufen durch dieselbe Pipeline (Keyword-Match, Pre-Topic-Translate,
Topic-Filter). Precision bleibt, Recall steigt.
- researcher.py: build_news_search_feeds + _GNEWS_LOCALE-Tabelle.
- orchestrator._rss_pipeline: Suchfeeds aus source_language_whitelist
(jp_demo: ['ja']) bzw. output+research_language (normale Orgs) gebaut
und an selected_feeds angehaengt.
- rss_parser._apply_domain_cap: Suchfeeds (domain 'google-news-search-<lang>')
bekommen Cap 25 statt 10 — sie sind der Recall-Treiber, Topic-Filter
uebernimmt die Precision.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vor der Stimmungs-Zusammenfassung laeuft ein separater Haiku-Call, der pro
Forum-Beitrag entscheidet:
- publishable: unveraendert uebernehmen
- redact: thematisch wertvoll, aber PII/Beleidigungen — Haiku liefert eine
bereinigte Kurzfassung
- discard: Hassrede gegen Gruppen, NSFW, glaubhafte Drohungen, reines
Trolling — entfernen
Damit liefert die jp_demo-Org keine ungefilterten 5ch/Hatena/Note-Posts
in die Lagen-Anzeige. Fail-open: Bei API-/Parse-Fehler wird die Original-
liste durchgereicht (Pipeline bricht nicht ab).
- analyzer.moderate_forum_articles: Batch (max 25/Call), JSON-Output, Logging
pro Entscheidungs-Klasse.
- orchestrator: Moderation laeuft vor generate_public_mood, gefilterte Liste
geht in die Stimmungs-Zusammenfassung.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Eigene Pipeline-Stufe nach factcheck, vor summary, die Foren-Artikel
(media_type='forum') zu einer Themen-Zusammenfassung verarbeitet. Wird als
separate Dashboard-Kachel "Öffentliche Stimmung" angezeigt — getrennt von
Lagebild und Faktencheck, damit anonyme Forenposts nicht mit belegter
Faktenlage verwechselt werden.
- DB-Migration: incidents.public_mood (TEXT) + public_mood_updated_at (TS).
- pipeline_tracker: neuer Pipeline-Step "public_mood" (DE/EN-Labels).
- analyzer.generate_public_mood: Haiku-Call der Foren-Beitraege pro Quelle
gruppiert und 3-6 thematische Bullets erzeugt, mit expliziter Quellen-
Herkunft pro Bullet. Bei zu duennem Material gibt's keinen Output.
- orchestrator: neuer Schritt zwischen Factcheck und Summary. Laedt alle
Foren-Artikel der Lage (via JOIN auf sources), uebergibt sie an den
Stimmungs-Agent, speichert den Markdown-Text in incidents.public_mood.
- Topic-Filter (analyzer.filter_relevant_articles) markiert Foren-Quellen
mit [FORUM]-Tag und bekommt im Prompt die Regel, Foren-Artikel weicher
zu bewerten (Lage-Keyword im Titel reicht). Sie sollen in der Stimmungs-
Kachel landen, nicht voreilig verworfen werden.
- IncidentResponse-Modell: public_mood/public_mood_updated_at ergaenzt.
- Frontend: neuer Tab "Öffentliche Stimmung" (nur sichtbar wenn Inhalt da),
eigene Kachel mit Warn-Hinweis "keine Faktenlage". UI.renderPublicMood
als einfacher Bullet-Renderer.
- dashboard.html Cache-Buster fuer components.js + app.js gebumpt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vorbereitung fuer jp_demo-Organisation: drei separate Sprach-Settings statt
einer einzigen output_language.
org_settings.py:
- get_source_language_whitelist: Liste erlaubter Quellsprachen als JSON-Array
(z.B. ["ja"] beschraenkt RSS/Telegram auf japanische Quellen).
- get_research_language: Sprache fuer WebSearch-Prompts (Default: output_language).
- get_translator_enabled: Pro-Org-Override des globalen TRANSLATOR_ENABLED-Flags.
- LANGUAGE_DISPLAY_NAMES um ja/zh/ko/ru/ar/fa/he/fr/es erweitert.
source_rules.py:
- get_feeds_with_metadata filtert nach source_language_whitelist, wenn gesetzt.
- Feeds ohne primary_language fallen bei aktiver Whitelist raus (gewollt).
- SELECT um media_type erweitert, damit es im Feed-Dict ankommt.
orchestrator.py:
- Laedt research_language, source_language_whitelist, translator_enabled aus
den Org-Settings.
- Wenn Whitelist gesetzt: international_sources-Flag wird ignoriert.
- research_language_iso wird an researcher.search() weitergegeben.
- translate_articles bekommt enabled-Parameter aus Org-Setting.
- Geoparsing ueberspringt media_type='forum' Artikel.
- SELECT * FROM articles wird zu JOIN sources, damit media_type beim Reload
am Article-Dict haengt.
researcher.py:
- search() akzeptiert research_language_iso. Asymmetrische Sprach-Auswahl
(Recherche != Output) erzeugt eigene Prompt-Anweisung "primaer in Quell-
sprache, englische Region-Outlets erlaubt".
translator.py:
- translate_articles akzeptiert enabled-Parameter. Ueberschreibt die globale
TRANSLATOR_ENABLED-Konstante pro Aufruf.
factchecker.py:
- _format_articles_text filtert Artikel mit media_type='forum' aus. Anonyme
Foren-Posts gelten nicht als Faktenbeleg.
rss_parser.py:
- _fetch_feed traegt media_type aus feed_config ins Article-Dict ein,
damit downstream Pipeline-Schritte Foren-Quellen erkennen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Beim Aktualisieren von Lage 96 (Verfassungsänderung Japan) ist der Topic-Filter
in den letzten Refreshes auf 2/15, 4/26 bzw. 7/23 zurückgefallen. Die jp-RSS-
Treffer aus Asahi-Politik, NHK-Politik und Mainichi werden offenbar verworfen,
aber ohne Detail-Log lässt sich nicht beurteilen, ob das gerechtfertigt ist.
- analyzer.filter_relevant_articles: pro verworfenem Artikel eine INFO-Zeile
mit laufendem Index, Quelle, Original-Headline und (falls vorhanden) der
englischen Pre-Topic-Übersetzung. Ohne zusätzlichen Claude-Call, nur Logging
des bereits vorhandenen Materials.
- translator._TOPIC_TRANSLATE_CONTENT_MAX von 240 auf 500 erhöht. Bei dichten
Kanji- oder kyrillischen Headlines reichten 240 Zeichen oft nicht aus, um
dem nachgelagerten Topic-Filter den thematischen Kontext zu vermitteln.
Mehrkosten pro Refresh: vernachlässigbar (Haiku, einmal pro Refresh).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Zwei Lücken beim Befund Lage 96 (Verfassungsänderung Japan): die japanische
Asahi-Shimbun-Quelle wurde durch das Sprach-aware Keyword-Matching (#27) und
Pre-Topic-Translate (#28) erstmals durchgereicht, landete aber mit
language='en' und ohne englische Headline in der DB. Damit ist sie im
Frontend nur als Kanji-Headline zu lesen und das Summary-LLM kann den
Treffer nicht aussagekräftig referenzieren.
1. INSERT INTO articles erweitert um headline_en und content_en. Werte
stammen primär vom Translator (headline_en, falls TRANSLATOR_ENABLED den
Pfad einmal in Englisch befüllt), Fallback auf die für den Topic-Filter
angefertigte Mini-Übersetzung (headline_en_for_topic /
content_en_for_topic). So liegt die englische Variante dauerhaft in der
DB statt nur während des Refresh-Laufs im Speicher.
2. RSS- und Telegram-Parser setzen 'language' nun primär aus der Quell-/
Kanal-Konfiguration (primary_language). Vorher war es hart 'de' wenn die
Headline deutsch wirkte, sonst 'en' - mit dem Resultat, dass ein
Kanji-Titel als language='en' landete. Mit dem Fix bekommen Asahi & Co.
korrekt language='ja', russische Telegram-Kanäle 'ru' etc.
- src/agents/orchestrator.py: INSERT erweitert, Kommentar zur Fallback-Logik
- src/feeds/rss_parser.py: language aus feed_config.primary_language
- src/feeds/telegram_parser.py: channel_lang durch _fetch_channel reichen
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Der Topic-Filter (Haiku) hat bisher fremdsprachige Headlines (CJK, Arabisch,
Hebräisch, Kyrillisch) konservativ verworfen, weil er die Sicherheitsregel
"im Zweifel NICHT relevant" auf jeden Text anwandte, den er nicht klar lesen
konnte. Bei Lage 96 (Verfassungsänderung Japan) landeten so 79 von 87
Kandidaten im Papierkorb, darunter alle ja-Quellen mit Kanji-Headlines.
Lösung: ein eigener kleiner Haiku-Batch-Call vor dem Topic-Filter übersetzt
die Headlines (+ erste 240 Zeichen Content) fremdsprachiger Artikel ins
Englische und hängt sie als article["headline_en_for_topic"] /
"content_en_for_topic" an. Der Topic-Filter zeigt sie zusätzlich zum Original
und beurteilt damit ja/zh/ko/ar/he/ru/fa-Artikel fair.
- agents/translator.py: neue Funktion translate_headlines_for_topic_filter,
unabhängig vom TRANSLATOR_ENABLED-Flag (Pflicht für korrekten Topic-Filter).
- agents/analyzer.py: filter_relevant_articles zeigt Übersetzungen mit an;
Prompt-Regel erweitert.
- agents/orchestrator.py: Aufruf direkt vor dem Topic-Filter-Schritt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bisher generierte Haiku Keywords nur in DE/EN/Romaji. Japanische RSS-Feeds
(z.B. MOD-GNews mit "防衛省・自衛隊の宇宙政策") matchten daher nie, weil
"jieitai" ≠ "自衛隊". Arabische/persische Telegram-Channels matchten nur
durch Zufall (lateinische Eigennamen in Hashtags/URLs).
Drei zusammenhängende Änderungen:
1. get_feeds_with_metadata liefert primary_language pro Feed mit.
2. FEED_SELECTION_PROMPT_TEMPLATE und KEYWORD_EXTRACTION_PROMPT verlangen
sprach-gruppierte Keywords ({de:[...], en:[...], ja:[...], ru:[...], ...}).
"en" enthält lateinische Eigennamen (universell). Andere Sprachen werden
nur gegen Feeds derselben Sprache gematcht.
3. RSS- und Telegram-Parser kombinieren pro Feed/Channel die "en"-Universalbegriffe
mit den Keywords der Quellsprache. Die Spezifik-Schwelle (1-Treffer-Match)
greift jetzt auch ab 3 Zeichen bei Non-ASCII (CJK, Arabisch, Kyrillisch).
Backward-kompatibel: flache Keyword-Listen werden weiter akzeptiert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- email_utils/templates.magic_link_login_email + incident_notification_email
nehmen jetzt lang Parameter (de | en).
- routers/auth.request_magic_link zieht Sprache aus der Org des Users und
uebergibt sie ans Template.
- agents/orchestrator._send_email_notifications_for_incident lokalisiert
ebenfalls und gibt lang an incident_notification_email durch.
- DB-Notification-Texte (refresh_summary, new_articles) sind in der
Pipeline org-sprach-relativ (englische Variante: "3 new articles", etc.).
Status-Change-Notifications: Codes (confirmed/contradicted) bleiben, FE
uebersetzt sie in Phase 6.
Phase 5 von 8 (eng_demo / Org-Sprache).
- OUTPUT_LANGUAGE Konstante aus config.py entfernt (jetzt pro Org in
organization_settings).
- Orchestrator laedt output_language einmal pro Refresh aus der Org-Sprache.
- researcher.search(), analyzer.analyze/.analyze_incremental/.generate_latest_developments,
factchecker.check/.check_incremental/.check_incremental_twophase bekommen
output_language als Parameter (Default Deutsch).
- LANG_INTERNATIONAL / LANG_GERMAN_ONLY (+ Deep-Varianten) sind Funktionen,
die je nach output_language die Sprachanweisung erzeugen (Deutsch | English
| Fallback).
- Sprachfilter in researcher.search ist org-relativ: bei nicht-international
werden Artikel mit Sprache != output_language_iso gefiltert.
Phase 2 von 8 (eng_demo / Org-Sprache). Bestandsorgs unveraendert, weil
Default-Setting weiterhin de (siehe Phase-1-Migration).
User-Korrektur: die echte Service-Domain heisst removepaywall.com (Singular).
removepaywalls.com (Plural) liefert HTTP 403 - vermutlich nicht der gleiche
Service oder gar nicht mehr existent.
Betrifft:
- services/source_health.py: REMOVEPAYWALLS_PREFIX-Konstante (Phase 18)
- agents/researcher.py: Claude-Prompts fuer Paywall-Hinweise (zwei Stellen)
Verifiziert mit curl: removepaywall.com -> 200, removepaywalls.com -> 403.
KEYWORD_EXTRACTION_PROMPT explizit erweitert:
- Eigennamen/Tiernamen/Personennamen aus dem THEMA als ZWINGEND markiert.
- Hinweis dass DE und EN identisch sein duerfen (Eigennamen).
- Klar gesagt: bei spezifischen Begriffen (>=7 Zeichen) reicht 1 Treffer in
RSS-Headlines (passt zu rss_parser.py adaptive Schwelle aus a08df3d).
Code-Post-Processing (researcher.py _extract_keywords):
- Nach dem Parser werden Lagentitel-Woerter (>=4 Zeichen, nicht in Stopwords)
ggf. in die Keyword-Liste injiziert, falls Haiku sie weggelassen hat.
- Verhindert konkret den "Buckelwal timmy"-Bug: "timmy" fehlte in Haikus
Liste, damit fielen Headlines mit nur "Buckelwal" durch das min_matches.
Hintergrund: Memory-Eintrag rss_match_und_keyword_bug.md, Bug 2 von 3.
Bug 1 (rss_parser min_matches adaptiv) ist seit Commit a08df3d auf Live.
Bug 3 (international=True default) bleibt offen, ist primaer UX-Frage.
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.
Beim User-Cancel wurde nur refresh_log auf cancelled gesetzt, der zuletzt
aktive refresh_pipeline_steps-Eintrag blieb verwaist. Der
/api/incidents/<id>/pipeline-Endpoint liefert daraus dauerhaft
"Schritt X laeuft" an die UI, auch lange nach dem Cancel.
- pipeline_tracker.cancel_active_steps(): neuer Bulk-Helper, setzt alle
noch active-Schritte eines refresh_log_id auf cancelled mit completed_at
- _mark_refresh_cancelled holt die refresh_log_id, macht das refresh_log-
Update wie bisher und ruft danach cancel_active_steps auf
Reproduziert bei Lage 80 (Bjoern Hoecke), refresh_log 1273. Frontend-
CSS kennt status-cancelled nicht, faellt auf den neutralen Default-Style
zurueck (kein Spinner mehr, kein Haken, korrekt ent-hangen).
- main.py: Auto-Refresh-Filter beruecksichtigt jetzt auch cancelled und error
- orchestrator.py: Queue-Cancels schreiben jetzt einen cancelled-Eintrag ins
refresh_log via _log_queued_cancellation
Wirkung: Nach Cancel oder Error startet die Lage erst beim naechsten
regulaeren Slot wieder. refresh_mode bleibt unveraendert.
(Identisch zu Commit auf main, develop nachgezogen.)
Bisher haben translations als Teil der Analyzer-JSON-Antwort gelebt
("translations": [...]). Bei vielen Artikeln pro Refresh hat das LLM die
Translations regelmaessig weggelassen (Output-Token-Druck), insbesondere
content_de (lange Texte werden zuerst gestrichen). Folge: viele englische
Artikel ohne deutsche Headline/Inhalt im Frontend.
Aenderungen:
- Neuer Agent src/agents/translator.py:
* translate_articles_batch / translate_articles
* Nutzt CLAUDE_MODEL_FAST (Haiku) - billig
* Batch-Size 5 (mit Reserve gegen Output-Truncate)
* Robustes JSON-Parsing: Markdown-Codefence, Truncate-Fallback,
extrahiert auch unvollstaendige Antworten
* Idempotent: Caller filtert auf fehlende headline_de/content_de
- analyzer.py: translations aus 4 Prompt-Templates entfernt (adhoc/research
x analyze/enhance) und Fallback-Return-Dict bereinigt -> Analyzer-Output
wird kompakter und zuverlaessiger
- orchestrator.py:
* Alter Translation-INSERT-Block entfernt (analysis.translations wird
nicht mehr genutzt)
* Nach Analyse + db.commit + cancel-check neuer Translator-Call:
SELECT WHERE language!=de AND (headline_de OR content_de fehlt),
translate_articles, normalize_german_umlauts, COALESCE-UPDATE
* Vor post_refresh_qc -> normalize_umlaut_articles greift auch frische
Uebersetzungen
* Failure-tolerant: Translator-Fehler bricht Refresh nicht ab
Backfill: migrations/migrate_translations_2026-05-03.py im Verwaltungs-Repo.
Fix fuer ASCII-Umlaute in Headlines/Inhalten (Gespraeche statt Gespraeche).
Zwei Quellen des Problems:
1. Quellen wie dpa-AFX, Telegram TASS/RIA liefern Headlines schon ASCII-fiziert
2. LLM-Uebersetzungen drift en gelegentlich zu ae/oe/ue trotz Prompt
Aenderungen:
- rss_parser.py: nach html_to_text auch normalize_german_umlauts auf
title und summary anwenden (sicher, hunspell-Dict ignoriert englische
Woerter wie Boeing/Business)
- orchestrator.py:1418 Translation-INSERT: headline_de und content_de
durch normalize_german_umlauts schicken (LLM-Drift abfangen)
- post_refresh_qc.py: neue Funktion normalize_umlaut_articles als Sicher-
heitsnetz analog zu normalize_umlaut_fields. Behandelt headline_de und
content_de aller Artikel des Incidents; bei language=de zusaetzlich
headline und content_original. Wird in run_post_refresh_qc nach
normalize_umlaut_fields aufgerufen.
Backfill: migrations/migrate_umlauts_2026-05-03.py (im Verwaltungs-Repo)
Die Reputation-Map nutzte veraltete Schlüssel (presseagenturen,
behoerden, nachrichten_de/int), die nirgends in der DB vorkamen — die
DB hat nachrichtenagentur, behoerde, oeffentlich-rechtlich,
qualitaetszeitung, think-tank, regional, telegram, boulevard. Folge
war ein stiller Bug: alle hochwertigen Quellen (Reuters, ZDF,
tagesschau, Spiegel, FAZ, BMI etc.) bekamen den Default-Score 0.4 wie
"sonstige" und wurden in der Relevanz-Sortierung nicht bevorzugt.
Map jetzt vollständig auf aktuelle Kategorie-Werte:
- nachrichtenagentur, behoerde: 1.00
- oeffentlich-rechtlich: 0.95
- qualitaetszeitung, think-tank: 0.85
- fachmedien: 0.80
- international: 0.75
- regional: 0.65
- telegram: 0.50
- sonstige: 0.40
- boulevard: 0.30
Test mit 200 zufälligen Artikeln aus der Live-DB:
155 besser bewertet, 0 schlechter, 45 unverändert.
Stärkster Effekt bei ÖR (+0.165), Nachrichtenagenturen (+0.18),
Qualitätszeitungen (+0.135).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bisher hatten Quellen vom Typ web_source keine praktische Wirkung auf
die Recherche - sie lagen nur als Marker in der DB. Jetzt werden sie
aktiv in den Recherche-Prompt eingebunden.
Ablauf:
1. Vor dem Hauptaufruf an Opus prüft ein günstiger Haiku-Call alle
aktiven Web-Quellen des Tenants (plus globale) und wählt die
thematisch passenden aus. Leere Selektion ist ausdrücklich erlaubt.
2. Die ausgewählten Domains werden dem Recherche-Prompt als
"EINGETRAGENE WEB-QUELLEN" Block beigegeben mit der Empfehlung,
gezielt mit "site:domain query" zu suchen, falls thematisch passend.
3. site: ist Empfehlung, kein Zwang - Claude bleibt flexibel und
ergänzt seine sonstige Recherche.
- source_rules.get_feeds_with_metadata: SELECT um notes-Feld erweitert,
damit der Selektor besseren Kontext zur Quelle hat.
- ResearcherAgent.select_relevant_web_sources: neuer Helper analog zu
select_relevant_feeds, mit Skip-Optimierung wenn ≤3 Quellen.
- WEB_SOURCE_SELECTION_PROMPT: explizite Regel "lieber leer als
pauschal alle", verhindert Token-Verschwendung.
- ResearcherAgent.search: neuer Parameter preferred_sources, beide
Templates (RESEARCH + DEEP_RESEARCH) bekommen optionalen
preferred_sources_block.
- Orchestrator._web_search_pipeline: Vorselektion vor researcher.search,
Token-Usage in usage_acc, Logging der gewählten Domains.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Em-dashes und Umlaut-Umschreibungen aus den Pipeline-Aenderungen
entfernt: Tooltip-Texte, HTML-Empty-State, JS-Kommentare,
Count-Status-Platzhalter, Orchestrator-Kommentare und CSS-Kommentare.
Anstelle von typografischen Gedankenstrichen werden jetzt Kommas oder
Punkte gesetzt, "uebersprungen" -> "uebersprungen" mit echtem Umlaut,
"laeuft" usw. analog. UI-Text "— Refresh starten" wird zu zwei
Saetzen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Neuer Tab "Analysepipeline" zwischen Faktencheck und Quellenuebersicht.
Zeigt 9 Verarbeitungsschritte als n8n-artige Blockkette: Quellen sichten,
Nachrichten sammeln, Doppeltes filtern, Relevanz bewerten, Orte erkennen,
Lagebild verfassen, Fakten pruefen, Qualitaetscheck, Benachrichtigen.
- Backend: refresh_pipeline_steps-Tabelle persistiert pro Refresh+Pass die
Status- und Zahlen-Werte. pipeline_tracker.py kapselt Start/Done/Skip/Error
inkl. WebSocket-Broadcast (Event-Typ pipeline_step). 9 Hooks im Orchestrator
speisen die Anzeige.
- API: GET /api/incidents/{id}/pipeline liefert Definition + letzten Stand
(Zahlen aus letztem Refresh, Multi-Pass-Konsolidierung).
- Frontend: pipeline.js rendert Vollbild-Blockkette mit pulsierendem Glow am
aktiven Block, animierten Pfeilen bei Datenfluss, Haekchen am fertigen Block.
Hover-Tooltip mit Erklaerung in Nutzersprache, Klick oeffnet Detail-Popup.
Bei Research-Lagen leuchtet ein Schleifen-Pfeil pro Mehrfach-Durchlauf auf.
Mini-Variante (nur Icons) im Refresh-Progress-Popup.
- CSS: Light/Dark-Theme-fest, dezenter Circuit-Hintergrund (5% Opacity),
Mobile-vertikale Stapelung unter 900px, prefers-reduced-motion respektiert.
- Uebersprungene Schritte (z.B. Geoparsing ohne neue Artikel) werden
ausgeblendet, brandneue Lagen ohne Refresh zeigen Hinweis.
Tooltips bewusst in normaler Sprache ohne Internas (keine Modellnamen,
keine Toolnamen, keine Phasen-Labels).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Behebt das Symptom, dass Recherche-Lagen wie staging Lage 6 "Friedrich Merz"
trotz erfolgreichem Refresh leer blieben. Claude lieferte nicht-leere Antworten
(1226-2125 Zeichen), die der bisherige Regex-Parser nicht extrahieren konnte —
die Recherche meldete "0 Artikel" und der Refresh wurde stumm als Erfolg
verbucht.
Aenderungen:
- _parse_response, select_relevant_feeds, extract_dynamic_keywords und
select_relevant_telegram_channels nutzen jetzt json.JSONDecoder.raw_decode
ueber Modul-Helper _extract_json_array/_extract_json_object. Damit werden
auch JSON-Bloecke mit Vor-/Nachtext, Markdown-Fences oder verschachtelten
Objekten zuverlaessig erkannt.
- Bei Parse-Fehlschlag wird jetzt ein gekuerztes Sample der Claude-Antwort
geloggt, damit kuenftige Faelle direkt debuggbar sind.
- Neue ResearcherParseError-Exception unterscheidet "echt 0 Treffer" von
"Antwort kaputt". search() gibt zusaetzlich ein parse_failed-Flag zurueck.
- Orchestrator-Multi-Pass: wenn alle 3 research-Durchlaeufe 0 neue Artikel
ergeben UND mindestens einer am Parser scheiterte, wird der Refresh als
Fehler markiert (statt als stiller Erfolg). Der WebSocket-refresh_error
loest dann die sichtbare UI-Meldung aus.
Adhoc-Lagen sind unveraendert: dort fangen RSS und Telegram die kaputte
Claude-Antwort auf, dafuer ist nur die Diagnose im Log neu.
- ENHANCE_PROMPT_ADHOC und ENHANCE_PROMPT_RESEARCH: Umschreibungen durch
echte Umlaute ersetzt (fuer -> fuer, praezises -> praezises, ...). Behebt
den Widerspruch, dass der Prompt "echte Umlaute verwenden" forderte,
die Anweisung selbst aber ae/oe/ue/ss nutzte.
- call_claude() bekommt neuen timeout-Parameter. None = Fallback auf
CLAUDE_TIMEOUT (1800s), sonst Override in Sekunden. asyncio.wait_for
und die cancel-aware Variante nutzen durchgaengig den effective_timeout.
- Enhance-Endpoint ruft call_claude mit timeout=60 auf (Haiku-Single-Shot,
vorher global 1800s).
- chat.py _call_claude_chat: Timeout von 60s auf 120s erhoeht (Chat-Antworten
koennen etwas laenger dauern, haben aber keinen Anspruch auf 30 Min).
