Der Knopf griff auf die Variable --accent-primary zu, die es im Stylesheet
nicht gibt: fuenf Verwendungen, null Definitionen. Die Akzentfarbe heisst
--accent.
Wirkung im Hover. `background: var(--accent-primary)` ist damit ungueltig und
faellt auf den Anfangswert transparent zurueck, waehrend `color: #fff`
gueltig bleibt. Auf der weissen Modalflaeche des Hellmodus stand also weisse
Schrift auf weissem Grund, der Knopf war unsichtbar. Im Dunkelmodus fiel es
nicht auf, weil die Flaeche dort dunkel ist.
Im Ruhezustand war nur die Farbe betroffen: Schrift und Rahmen waren nicht
gold, sondern geerbt. Deshalb faellt der Fehler erst beim Hover auf.
Alle fuenf Fundstellen sind auf --accent umgestellt, betroffen waren neben
dem Knopf auch die Durchlauf-Anzeige im Fortschrittsfenster und der kleine
Lade-Ring, die beide ihre Akzentfarbe nicht bekamen.
Hinweis zum Kontrast: Weiss auf Gold (#96791A) liegt bei rund 4,1 zu 1 und
damit knapp unter der WCAG-AA-Schwelle fuer kleine Schrift. Das ist dieselbe
Kombination, die .btn-primary im ganzen Dashboard verwendet, deshalb hier
bewusst konsistent gehalten statt einzeln abweichend geloest.
Offen: Die Aenderung ist noch nicht in den Lokal-Fork portiert.
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>
Nachtrag zum Quellenverzeichnis, aufgefallen am Export der EU-Lage 53 vom
01.08.2026.
1. Lueckenlose Zaehlung im Bericht. Das Modell nummeriert alle vorgelegten
Meldungen durch, zitiert aber nur einen Teil. Das Verzeichnis sprang
dadurch von 20 auf 22, 24, 26, was fachlich stimmt, beim Leser aber wie
ein Fehler aussieht. Export und Text werden jetzt gemeinsam auf 1 bis n
umgeschrieben. Die gespeicherten Nummern bleiben unangetastet, damit sie
ueber Folge-Refreshes stabil bleiben. Verweise, fuer die es keinen
Verzeichniseintrag gibt, werden dabei entfernt statt verschoben: nach einer
Umnummerierung wuerden sie sonst auf einen fremden Eintrag zeigen.
2. Der kuratierte Medienname schlaegt den Feed-Namen. Bisher gewann der
haeufigste gelieferte Name, und das war der Name des RSS-Feeds. Im Bericht
stand deshalb "Guardian World", "NYT Top Stories", "BBC Europe" und
"FT Europe". Jetzt: The Guardian, New York Times, BBC, Financial Times.
3. Weiterleitungsportale werden nicht mehr zusammengefasst. Die Gruppierung
nach Domain warf in der Anthropic-Fassung vier Zeitungen zusammen, weil
Deutschlandfunk, Kurier, SZ.de und tagesschau.de dort alle als
news.google.com-Link vorliegen. Der Umweg wird jetzt in der Statistik
offen ausgewiesen, statt die Medien zu verschmelzen.
4. Ein Quelleneintrag zerfaellt nicht mehr ueber die Seitengrenze. Nummer und
Name standen am Fuss der einen, die Adresse am Kopf der naechsten Seite.
Gegenprobe an beiden Laeufen des Ceuta-Vergleichs: Lage 53 zeigt 25 Quellen
lueckenlos von 1 bis 25, Lage 52 22 von 1 bis 22, in beiden Faellen loest
jeder Verweis im Text auf und kein Eintrag zerfaellt ueber eine Seite.
Neu sind 11 Pruefungen, insgesamt laufen 129 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Vergleich zweier Berichte zur selben Lage (Ceuta, 01.08.2026) zeigte in
beiden Fassungen Textverweise, die im gedruckten Verzeichnis nicht auftauchten.
Die EU-Fassung zitierte bis [28] bei 25 aufgefuehrten Quellen, die
Anthropic-Fassung bis [29] bei 22.
Ursache war nicht die Analyse. In der Datenbank passen Text und Liste in beiden
Laeufen exakt zusammen, keine einzige Referenz ohne Eintrag. Das PDF-Template
druckte jedoch die laufende Zeilennummer (loop.index) statt der Quellennummer
aus dem Lagebild (src.nr). Sobald die Nummern Luecken haben, und das ist der
Normalfall, weil nicht jede gesammelte Meldung zitiert wird, verschiebt sich
ab der ersten Luecke jeder Beleg. Lage 53 hat die Nummern 1 bis 20, 22, 24, 26,
27, 28: gedruckt wurde 1 bis 25, aus Quelle 28 wurde Zeile 25.
Behoben:
1. Das Verzeichnis druckt src.nr. Gegenprobe an den echten Daten beider Laeufe:
vorher fehlten in Lage 53 die Verweise [22] bis [28], jetzt loest jede der
25 Referenzen auf, in Lage 52 alle 22.
2. Keine Kappung des Verzeichnisses mehr. Im Umfang "Bericht" wurde bei 30
Eintraegen abgeschnitten, hoehere Referenzen im Text waren damit
grundsaetzlich unaufloesbar.
3. Die Word-Ausgabe bekommt ueberhaupt erst ein Quellenverzeichnis. Bisher
verwies der Text dort auf [1], [2], ohne dass die Datei die Nummern
irgendwo aufloeste.
4. Die Quellenstatistik bezieht sich jetzt auf dieselbe Grundmenge wie das
Verzeichnis. Vorher zaehlte sie alle gesammelten Artikel (49) und stand
damit neben einem Verzeichnis mit 25 Eintraegen, was wie eine Aufwertung
der Quellenbasis wirkte. Die Summe der Spalte Belege entspricht jetzt der
Zahl der Eintraege, ein Hinweis nennt zusaetzlich die insgesamt
ausgewerteten Meldungen.
5. Ein Verlag wird unter einem Namen gefuehrt. Bisher trennte der Bericht
"Guardian UK", "Guardian World" und "The Guardian" oder "tagesschau" und
"tagesschau.de" in eigene Zeilen und blaehte damit die Vielfaltsstatistik
auf. Die neue services/media_registry.py bestimmt die Identitaet ueber die
registrierbare Domain und waehlt den haeufigsten Namen. Aus 20
Statistikzeilen der EU-Fassung werden so 11 echte Medien. Sie kennt
ausserdem Weiterleitungsportale und liest die Sprache aus der Adresse,
sodass english.elpais.com nicht mehr als DE gefuehrt wird.
Neu sind 22 Pruefungen, insgesamt laufen 118 ohne Netzzugriff und ohne Kosten.
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>
Bisher zeigte nur der EU-Weg ein Kennzeichen, Lagen auf dem Anthropic-Weg
blieben unbeschriftet und waren dadurch nicht von der Standardvorgabe zu
unterscheiden. Jetzt tragen beide ausdruecklich gesetzten Wege ein Kennzeichen
(gruen 'EU', grau 'Anthropic'), sowohl in der Lagen-Kopfzeile als auch in der
Seitenleiste. Ohne ausdrueckliche Wahl bleibt es unbeschriftet, dort gilt die
Vorgabe der Organisation.
Cache-Stempel von app.js UND components.js hochgezaehlt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Der KI-Weg-Umschalter kam beim Anlegen nicht an: das Formular war neu, der
Browser lieferte aber die zwischengespeicherte alte app.js aus, weil der
Cache-Buster unveraendert blieb. Dadurch wurde ai_backend nicht mitgesendet
und Lagen landeten still auf dem Standard.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Im Anlege- und Bearbeiten-Dialog einer Lage laesst sich jetzt waehlen, ob sie
ueber den heutigen Weg (Anthropic) oder den EU-Weg (Bedrock Frankfurt + staan)
laeuft; Standard bleibt die Vorgabe der Organisation. Dazu ai_backend in den
Schemas und den Lagen-Endpunkten (Create, Update, Ausgabe), Leerstring setzt
bewusst auf Standard zurueck. In der Lagen-Kopfzeile zeigt ein Kennzeichen
'EU' an, dass die Verarbeitung europaeisch laeuft.
UI-Sync: bewusst NUR online. Der Lokal-Fork hat kein Bedrock-Backend, dort
waere das Feld funktionslos (wie X-Zugaenge und Studio-Gating).
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>
Das AWS-Konto darf die neuesten Modelle (Opus 4.7/5, Sonnet 5) auf Bedrock
noch nicht aufrufen (AccessDeniedException, separate Freischaltung noetig).
Die EU-Recherche laeuft deshalb auf Opus 4.6 (gleicher Listenpreis). Nach der
Freischaltung genuegt BEDROCK_PROFILE_STANDARD in der .env.
Ausserdem akzeptiert der staan-Client jetzt HTTP 201 (POST-Antwort der API).
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>
Produktentscheidung 07/2026: ungenutzte Credits verfallen zum
Periodenende, es gilt der harte Monatsdeckel wie verkauft. Der
Uebertrag (credits_rollover/credits_carried) fliegt komplett raus:
roll_credit_period setzt nur noch Verbrauch + Warnflag zurueck,
check_license rechnet verfuegbar = credits_total, die Migration legt
die beiden Spalten gar nicht erst an (Live hat sie nie bekommen, die
Promote-Warteschlange enthielt sie noch). ABRECHNUNG.md angepasst.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ergaenzt phone im telegram_session-Status, damit das Portal die
Telegram-Zeile im Reiter Recherche-Zugaenge vollstaendig fuellen kann.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Key-Value-Tabelle system_status (idempotente Migration). Der Monitor
prueft die Telethon-Session beim Start und taeglich um 04:30 (eigener
Scheduler-Job) und schreibt ok/account/error unter dem Key
telegram_session. Das Verwaltungsportal zeigt den Eintrag im Reiter
Recherche-Zugaenge an, damit ein Session-Ausfall sichtbar wird statt
nur im Server-Log zu stehen. Fehler beim Pruefen stoeren den Betrieb
nie (try/except, eigene DB-Connection wie beim Health-Nachtjob).
Promote-Reihenfolge wie gehabt: Monitor VOR Verwaltung (Migration).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bisher fiel eine 0 durch das or-80-Muster still auf die Voreinstellung
zurück, ein Abschalten der Warnung war unmöglich. Jetzt gilt, 0 = aus,
NULL = Voreinstellung 80, alles andere wie gehabt. Das Verwaltungsportal
bietet die 0 in seinen Formularen an.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Tabelle user_activity_days (user_id, day, tenant_id, ein Eintrag je
Nutzer und Kalendertag), angelegt per idempotenter Startup-Migration.
Geschrieben wird sie in get_current_user bei jeder authentifizierten
Nutzung, ein In-Memory-Tagesmerker begrenzt das auf einen INSERT OR
IGNORE je Nutzer und Tag, Fehler werden geschluckt und blockieren nie
eine Anfrage. Gelesen wird die Tabelle nur vom Verwaltungsportal für
die neue MAU/DAU-Statistik. Ein reines Login-Protokoll wäre zu grob,
weil das JWT 24 Stunden hält.
Getestet gegen eine DB-Kopie, Tabelle entsteht, je Nutzer und Tag
genau ein Eintrag trotz Mehrfachaufruf.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die Credits-Sätze je Aktion stehen jetzt in der geteilten Tabelle
billing_tariff statt nur in der Konfiguration. Die Migration legt die
Tabelle an und befüllt sie einmalig mit den wirksamen CREDIT_TARIFF-
Werten, danach liest _charge_credits() bei jeder Buchung die Tabelle,
fehlende Schlüssel oder eine fehlende Tabelle fallen auf die
Konfiguration zurück. Damit können Monitor und Verwaltungsportal
dieselben Sätze anzeigen und das Portal kann sie künftig pflegen,
eine Preisänderung braucht keinen Server-Eingriff mehr.
Getestet gegen eine Kopie der Staging-DB. Seed mit 7 Sätzen (45/40/
12/12/1/1/1), Buchung nach Tabelle, Tabellenänderung greift sofort,
Rückfall auf die Konfiguration ohne Tabelle.
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>
Der Knopf für den Ansichtswechsel steht jetzt links neben "Abmelden" am
Ende der Kopfzeile statt an erster Stelle. Reihenfolge oben rechts damit
Barrierefreiheit, Theme, Konto, Klassische Ansicht, Abmelden.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Portierung aus dem Lokal-Fork (AegisSight-Monitor-Local, Commit 9613610).
Vier Angleichungen an das klassische Dashboard.
1. "Klassische Ansicht" ist jetzt derselbe Knopf wie "Studio-Ansicht" im
Dashboard, mit Symbol, an erster Stelle im rechten Kopfzeilen-Block.
2. Oben rechts fehlten Barrierefreiheit, Konto-Menü und Abmelden. Der
A11yManager liegt jetzt in js/a11y.js und wird von beiden Oberflächen
eingebunden, denn das Studio lädt app.js nicht. Konto-Menü (Organisation,
Lizenz, Credits, Über KI-Inhalte) und Abmelden nachgezogen, der
Theme-Schalter ist derselbe Schiebeschalter wie im Dashboard.
3. Die Fall-Liste hat jetzt die Umschaltung "Alle" / "Eigene" in der
Knopf-Optik der klassischen Seitenleiste, der Reiter-Zähler zieht mit.
4. Der Hinweis "Wähle links einen Fall aus" endet vor der Bausteine-Spalte
statt am Fensterrand, im gestapelten Layout nimmt er die volle Breite.
Das info@-Gating des Studios bleibt unverändert bestehen.
Versionsmarker der angefassten Dateien auf 20260725a angehoben.
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>
Das blockierende Fortschritts-Overlay (.progress-overlay.blocking) liegt
position:fixed über dem gesamten Viewport und schluckt damit auch die
Klicks auf den globalen Header. Beim ersten Durchlauf eines Falls waren so
Barrierefreiheit, Theme-Wechsel, Konto-Menü inkl. Org-Switcher und
Abmelden nicht erreichbar.
Neue Body-Klasse first-refresh-blocking hebt den Header per z-index über
das Overlay, solange dieses blockierend sichtbar ist. UI._syncHeaderAccess()
spiegelt den Overlay-Zustand an allen Stellen, die das Overlay ein- oder
ausblenden.
Die fallbezogenen Aktionen (Aktualisieren, Bearbeiten, ...) bleiben
unverändert gesperrt: dafür sorgen weiterhin #incident-view.refresh-blurred
und .incident-header-actions.first-refresh-locked.
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>
Die IONOS-Farm (smtp.ionos.de, 10 Backends im DNS-Round-Robin) hatte am
10.07. teils tote/lahme Backends - ein einzelner Sendeversuch schlug dann
fehl (Timed out waiting for server ready message). Jeder Retry oeffnet
eine neue Verbindung und trifft per Round-Robin ein anderes Backend.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Live-Monitoring-Lagen (adhoc) zeigten im Export die Entwicklungen als
Bullet-Liste mit "[DD.MM. HH:MM] Text" und Quellen-Links. Jetzt:
- Abschnitt heisst "Neueste Entwicklungen" statt "Zusammenfassung"
(Ueberschrift, Inhaltsverzeichnis). Title folgt dem Inhalt.
- Pro Eintrag eigene Datum/Uhrzeit-Zeile (TT.MM.JJ, HH:MM Uhr),
darunter als eigener Absatz der Meldungstext.
- Keine Links: Quellen-Klammern {Name|URL} und [N]-Zitate werden entfernt.
- Gilt fuer PDF und DOCX. Research-Lagen und KI-Executive-Summary
unveraendert.
Nebenbei: DOCX-Export crashte bei Beschreibungen ueber 255 Zeichen
(python-docx Core-Property "subject" Limit). Subject wird jetzt gekappt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mindest-Aktualisierungsintervall im Lage-Modal: 30 Minuten Basis, 45 bei X oder Telegram, 60 bei X und Telegram zugleich (internationale Quellen ohne Einfluss). Minutenwerte darunter sind im UI nicht mehr einstellbar (min-Attribut, Clamp am Feld und beim Speichern). Beim Umstellen von Stunden auf Minuten wird das Minimum gesetzt und als Hinweis angezeigt. Gilt für Anlegen und Bearbeiten.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Die Typ-Auswahl (Live-Monitoring/Recherche) steht jetzt als erstes Feld vor Titel und Beschreibung, beim Anlegen und beim Bearbeiten (gemeinsames Modal modal-new). Auf ausdrücklichen Wunsch direkt auf main aufgespielt, Staging-Zyklus umgangen.
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>
Der bisherige Watchdog markierte jeden running-Refresh nach 15 Min als
verwaist. Bei jp_demo-Lagen laeuft nach summary aber noch der Translator
(synchron, ~20 Min bei 200+ Artikeln), der den Refresh legitim ueber das
Limit traegt - er wurde dann faelschlich abgebrochen und der Orchestrator
hing in-memory weiter mit incident in _current_task.
Neuer Watchdog:
- ORPHAN_IDLE_LIMIT (30 Min): wird der Refresh nur als verwaist markiert,
wenn seit dieser Zeit kein refresh_pipeline_steps-Eintrag Fortschritt
zeigte (started_at oder completed_at)
- ORPHAN_HARD_LIMIT (90 Min): absolute Obergrenze gegen echte Haenger
- Wenn ueberhaupt keine Pipeline-Steps existieren -> als verwaist markieren
Folge: Long-Running-Refreshes (Translator-Block) laufen sauber durch,
nur echte Haenger werden bereinigt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Der Export-Dialog hat ein neues optionales Feld "Ersteller". Ist es
gefuellt, wird dieser Name im Bericht als Ersteller verwendet; bleibt es
leer, gilt wie bisher die E-Mail des Lage-Erstellers.
- export_incident: optionaler Query-Parameter creator, hat Vorrang vor
der E-Mail-Ableitung
- exportReport (api.js) haengt creator an die Export-URL
- submitExport (app.js) liest das neue Feld aus
- Eingabefeld im Export-Modal (dashboard.html)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Die Branding-Auswahl im Export blieb wirkungslos, weil der
Browser die alten gecachten app.js/api.js weiterverwendete.
Versions-Query der beiden Skripte angehoben.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Beim Bericht-Export lässt sich im Modal nun zwischen "Mit
AegisSight-Branding" und "Ohne Firmen-Branding" wählen. Im
neutralen Modus entfallen Logo, AegisSight-Zeile auf dem
Deckblatt und Branding-Footer; die Datei-Metadaten werden
neutralisiert. Das Deckblatt mit Titel, Stand und Ersteller
bleibt erhalten. Betrifft PDF und DOCX.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SOURCE_TYPE_PATTERN kannte kein x_account und SOURCE_CATEGORY_PATTERN
kein x. Dadurch schlug das Speichern einer X-Quelle ueber die Monitor-
Oberflaeche mit HTTP 422 fehl: bei neuen X-Quellen am source_type, beim
Bearbeiten bestehender X-Quellen an der Kategorie x. Beide Patterns
ergaenzt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Die Filter-Chips wurden nur eingeblendet, wenn ein Fall Telegram- oder
X-Quellen hatte. Bei reinen Web-Faellen (z.B. in der Org jp_demo) fehlte
die Filterleiste damit komplett. Sie wird jetzt immer angezeigt, sobald
Quellen vorhanden sind, und zeigt zugleich, welche Quellentypen der Fall
enthaelt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Die Quellenuebersicht innerhalb einer Lage zeigt jetzt Filter-Chips
(Alle / Web / Telegram / X) und blendet die Quellen-Boxen nach
Quellentyp ein und aus. Die Chips erscheinen nur, wenn neben Web auch
Telegram- oder X-Quellen vorkommen.
- sources-summary-Endpoint liefert pro Quelle einen source_type,
abgeleitet aus dem source-Praefix (X: / Telegram: / sonst Web)
- Filter-Chips und data-type in renderSourceOverviewFromSummary
- App.filterSourceOverview blendet die Boxen nach Typ
- Chip-Styles in style.css
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Der Typ-Filter im Quellen-Modal kennt jetzt auch podcast_feed, damit
alle Quellentypen (RSS, Web, Telegram, X, Podcast) filterbar sind.
Zusaetzlich zeigt jede Quelle ein korrektes Typ-Badge -- vorher zeigten
Telegram, X und Podcast faelschlich "Web".
- podcast_feed im sources-filter-type-Dropdown
- _sourceTypeLabel-Helfer, korrekte Typ-Badges im Gruppen-Header und in
den Feed-Zeilen, x_account im Info-Tooltip-typeMap
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>
Google-News-Feeds (Site-Search wie auch der neue Volltext-Suchfeed) buendeln
Artikel vieler echter Publisher unter einer Feed-URL. Bisher bekamen alle
Artikel den generischen Feed-Namen als 'source' — der Faktencheck zaehlte
damit 25 Artikel verschiedener Zeitungen als EINE Quelle, und die
Quellenuebersicht war unbrauchbar.
Fix: Bei news.google.com-Feeds wird der echte Publisher aus dem <source>-Tag
des Feed-Items uebernommen (feedparser: entry.source.title). Fallback: der
Publisher-Teil hinter dem letzten ' - ' im Google-News-Titel.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
