Erklaert die acht groessten Veraenderungen seit 1.0 — Buerger:innen-Modus,
Tour mit Sprachausgabe, Stimmverhalten, Aktuelle-Themen-Dashboard, Programme
mit zeitpunkt-genauer Bewertung, Scorecards, Auswertungen und Quellen-Suche
— jeweils mit kurzer Intention und Umsetzungsbeschreibung.
Topbar-Link rechts oben (vor Methodik), Endpoint /was-ist-neu, Template
unter v2/screens/was-ist-neu.html. Eigene neu-* CSS-Klassen analog zu
methodik.html, daher kein neuer Inline-Style-Eintrag.
Vorher waren Container-Name + BACKUP_DIR hardcoded auf prod-Werte
(gwoe-antragspruefer / /opt/gwoe-antragspruefer/backups). Auf dem dev-Server
hat das Skript via git pull deshalb in den prod-Pfad geschrieben und gegen
den prod-Container geredet — dev hatte effektiv keinen eigenen Dump.
Fix:
- Container-Name als optionales $1-Argument (Default: gwoe-antragspruefer)
- BACKUP_DIR aus Skript-Pfad abgeleitet (parent-of-scripts/.../backups)
- Cron auf dev muss mit Argument 'gwoe-antragspruefer-dev' aufrufen
Nach dem 1.x → 2.0-Cut auf prod (siehe v2.0.0-Tag) laeuft prod als sauberer
git-checkout. Tar-Upload-Pfad ist obsolet.
- scripts/deploy.sh: Branch-Guard release/2.0, Pre-flight-Checks (clean +
pushed), Pre-Deploy-DB-Backup, Uptime-Kuma-Wartungsmodus, /health-Check
mit Version-Anzeige nach Deploy
- scripts/major-release-cut.sh: dokumentierter Workflow fuer den naechsten
Major-Cut (z.B. 2.0 → 3.0). Inklusive Bundle-Fallback bei
Gitea-Korruption (war beim 2.0-Cut gebraucht), DB-Wipe-Liste mit
Erhalt der Vote-Daten, Pfad-Switchover und Smoke-Tests
Bisher hatten nur Startseite und Antrag-Detail eigene Touren — die
Fallback-Tour (Logo+Topbar+Sidebar) war für jede andere Page identisch.
User-Wunsch: pro Menüpunkt eigene Tour, die diese Page funktional
erklärt.
Pro Page 3-5 Stationen mit konkreten Selektoren auf die Hauptbereiche:
- Quellen: Volltextsuche, Treffer-Liste, Programm-Karten
- Methodik: TOC, GWÖ-Matrix, Pipeline
- Auswertungen: Tabs (4 Sichten), Filter, Visualisierung
- Stimmverhalten: Stimm-Index, Heuchelei-Quote, Cross-BL — eigene
Variante via {% if v2_active_nav == 'stimmverhalten' %}, da
Stimmverhalten dasselbe Template wie Auswertungen nutzt
- Tags: Tag-Wolke, gefilterte Treffer
- Merkliste: Liste, Empty-State
- Neuer Antrag: BL-Wahl, Drucksachen-Eingabe, Modell, Submit
- Abos: Filter, aktive Abos
- Atom-Feed: Filter, Feed-URL
- Landtag-Suche: BL, Suchbegriff, Treffer + Bewertung anstoßen
- Aktuelle Themen: Top-News, Cluster+Zeitreihe, PM-Generator
Texte ermächtigend formuliert (was-wofür-wie), nicht oberflächlich.
Selektoren mit Fallback-Liste (komma-separiert), damit Templates ohne
exakte Klassennamen die Station trotzdem zeigen können.
Im JS-Kommentar des Topbar-Toggle-Skripts stand wörtlich
{% include "v3/components/tour.html" %} — Jinja parst das auch
innerhalb von /* ... */-Kommentaren und renderte das include ein
zweites Mal. Folge: 4 window.gwoeTourStart-Definitionen, doppeltes
Tour-Overlay-DOM, doppeltes <audio>-Element. Fix: Kommentar
umformuliert ohne Jinja-Tag.
Zwei Bugs:
1) Audio kam nicht durch — die Content-Security-Policy hatte kein
media-src und fiel auf default-src 'self' zurück. data:- (silent-WAV
zum Element-Unlock) und blob:-URLs (ElevenLabs-MP3-Cache) wurden
geblockt. Browser-Fehlermeldung im Console: „Loading media from
‚data:audio/wav;base64,…' violates the following Content Security
Policy directive". Fix: ``media-src 'self' data: blob:;`` ergänzt.
2) Tour war nur auf Startseite + Antrag-Detail eingebunden. User-Wunsch:
auf jeder Page außer Administration. Lösung: Tour-Engine-Include in
v2/base.html, mit ``{% if v2_active_nav not in [admin_*] %}``-Guard.
Pages ohne eigene ``window.GWOE_TOUR_STEPS`` bekommen einen Fallback
mit drei Stationen (Logo+Konzept, Topbar, Sidebar).
Topbar-Tour-Link sichtbar wenn ``window.gwoeTourStart`` existiert
(Engine geladen) — nicht mehr abhängig von Page-eigenen Steps.
Aufräumen: redundante Tour-Includes aus durchsuchen.html und
antrag_detail.html entfernt — die Engine kommt jetzt nur einmal aus
base.html.
Letzter Commit hatte die Daten-Nav für alle sichtbar gemacht, damit der
Tour-Text passte. User-Korrektur: nicht die Berechtigungen erweitern,
sondern den Tour-Text auf das anpassen, was anonyme tatsächlich sehen.
Nav zurück auf den ursprünglichen Stand (Daten-Sektion eingeloggt-only).
Tour-Station „Navigation links" jetzt zwei Varianten via {% if
is_authenticated %} im durchsuchen.html-Template:
- Anonym: erklärt Tags + Quellen (Topbar) und weist auf Login-Mehrwert
hin (Auswertungen / Stimmverhalten / Merkliste sind dann da).
- Eingeloggt: erklärt Auswertungen + Stimmverhalten + Quellen.
Drei zusammenhängende UI-Bugs:
1) Audio kam nicht — Browser-Auto-Play-Block. ``new Audio(blobUrl).play()``
nach einem await zählt nicht mehr als User-Gesture; Safari/Chrome
kassieren mit NotAllowedError. Fix: persistentes <audio>-Element wird
einmal beim Tour-Start (im Click-Handler, synchron) mit einer
1×1-silent-WAV entsperrt. Folgende src-Updates spielen ohne Block.
2) Tour-Bubble „Weiter"-Button sah 90er aus — der lokale CSS-Override
``.gwoe-tour-bubble .v3-action-btn.primary`` hat den modernen
pill-shaped Style ausgehebelt. Override entfernt; nutzt jetzt das
globale ``.v3-action-btn.primary`` (teal-solid, runde Ecken,
weicher Drop-Shadow).
3) Tour erzählt anonymen User:innen über „Auswertungen" und
„Stimmverhalten", die in der linken Nav für Anonyme nicht sichtbar
waren. Aggregierte Daten sind öffentlich — Daten-Nav-Gruppe jetzt für
alle sichtbar (Auswertungen, Stimmverhalten, Aktuelle Themen,
Export-API, Atom-Feed). Persönliche Items (Merkliste, Abos, Neuer
Antrag, Batch) bleiben eingeloggt. Cluster + Landtag-Suche bleiben
eingeloggt/admin (Backend-Routen sind ohnehin require_auth).
DOMContentLoaded-Race: bei manchen Page-Loads war das Event schon
gefeuert, wenn das addEventListener-Script lief — der Listener wurde
nie aufgerufen, der Topbar-Tour-Link blieb hidden. Auf der Startseite
führte das dazu, dass nach Welcome-Banner-Dismiss kein Tour-Einstieg
mehr da war.
Fix: synchroner IIFE-Check, der Skript-Block steht ohnehin nach dem
body_scripts (STEPS sind dort schon gesetzt).
User-Feedback: Tour-Start muss auch nach dem ersten Mal möglich sein,
und die Buttons sahen "sehr 90er" aus.
Permanenter Tour-Zugang:
- Topbar-Link "🧭 Tour" neben Methodik/Quellen, sichtbar auf jeder
Page mit ``window.GWOE_TOUR_STEPS`` (Antrag-Detail + Startseite).
- Per JS in base.html nach DOMContentLoaded sichtbar geschaltet.
- Style: dezente teal-Pille, kein dominanter Button.
Button-Modernisierung:
- ``.v2-chip`` und ``.v3-action-btn`` jetzt pill-shaped (border-radius
999px statt 3px), mit transition + box-shadow on hover und subtle
transform on active. Focus-visible mit klarem outline.
- Primary-Variante: teal-solid mit weichem Drop-Shadow, nicht das alte
dark-Mode-Schwarz.
- Welcome-Banner (Startseite): scharfes ``v2-kasten outline-blue`` weg,
stattdessen weicher gradient-Hintergrund teal→blue mit border 22%
teal-Hauch und subtle box-shadow. Skip-Button als Text-Link
("Später") statt vollwertiger Chip — visuell klar nachgeordnet.
Audio-Backend:
- ``app/tour_audio.py`` ruft ElevenLabs-TTS mit voice_id=Domi
(AZnzlk1XvdvUeBnXmlld) und model=eleven_multilingual_v2. ENV-konfiguriert
via ``ELEVENLABS_API_KEY``, ``ELEVENLABS_VOICE_ID``, ``ELEVENLABS_MODEL_ID``.
- Voice-Settings: stability 0.55, similarity_boost 0.7 (warm, klar, natürlich).
- Caching: SHA-256(text|voice|model) → ``data/tour_audio/<hash>.mp3``.
Folgeabrufe gehen aus dem Datei-Cache, kein API-Quota-Verbrauch.
Endpoint: ``GET /api/tour/voice?text=...`` rate-limited 30/min,
liefert audio/mpeg mit Cache-Control 30 Tage. Bei fehlendem
API-Key 503 — Frontend fällt dann auf ``speechSynthesis`` zurück
(Browser-eingebaute Stimme).
Frontend (tour.html):
- ``speak()`` versucht erst Server-Audio (ElevenLabs), bei 503/Fehler
Fallback auf Web Speech API.
- Session-Cache via Blob-URL: Vor/Zurück-Navigation in der Tour zieht
nicht jedes Mal eine neue Network-Roundtrip.
- ``stopSpeak()`` stoppt beide Audio-Pfade sauber.
Konfiguration für dev: ``ELEVENLABS_API_KEY`` und (optional)
``ELEVENLABS_VOICE_ID`` in ``/opt/gwoe-antragspruefer-dev/.env`` setzen,
dann Container restart.
Drei zusammenhängende UI-Bausteine:
1) Tour-Engine ist jetzt page-agnostisch — sie liest die Stationen aus
``window.GWOE_TOUR_STEPS`` (pro Page hinterlegt), nicht mehr aus einem
eingebauten Konstanten. Tour-Komponente wird per ``{% include %}``
eingehängt; das Page-Template definiert vorher seine eigenen Steps.
Antrag-Detail-Tour wurde entsprechend in das eigene Template gezogen.
2) Startseite (v2/screens/durchsuchen.html): „Du bist neu hier?"-Banner
oben mit zwei Buttons — „🧭 Tour starten" und „Nein, danke". Banner
bleibt sichtbar, bis explizit weggeklickt wird (localStorage-Flag),
oder die Tour gestartet wird. Fünf Stationen für die Startseite:
Marken-Block, Suche, Score-Filter + Sortierung, Antrags-Liste,
linke Navigation.
3) Logo-Klick führt jetzt zur Startseite — sowohl in v2/base.html als
auch in components/appshell.html. ``v2-brand`` und ``v2-brand-sub``
sind in einen ``<a href="/">`` mit Hover-Highlight gewickelt
(``.v2-brand-link``).
Phase 2 (ElevenLabs-Voice) ist der nächste Schritt — bisher läuft das
Audio über die Web Speech API.
Schaltfläche „🧭 Tour" in der userrow neben „Merken". Klick öffnet ein
Spotlight-Overlay mit vier Stationen, ermächtigend statt vereinfachend
formuliert:
1. Die Gemeinwohl-Note (was die Zahl 0–10 sagt, was die Empfehlung ist)
2. Die GWÖ-Matrix (5 Werte × 5 Berührungsgruppen, Farbcodierung)
3. Programm-Treue pro Fraktion (Score + Belege)
4. Stimmverhalten + Marker (Heuchelei ⚠ und Opportunismus !)
Audio: Web Speech API (Browser-eingebaute Stimme), de-DE, möglichst
weibliche Stimme. „Stimme an / aus"-Toggle in der Bubble. Bei
ESC oder Klick auf Overlay-Hintergrund: Tour-Ende, Audio stoppt.
Phase 2 (separate Iteration) wird das Audio-Backend gegen ElevenLabs
tauschen — Tour-Skript + UI bleiben gleich, nur ``speak()`` ruft dann
einen Server-Endpoint, der eine vorgenerierte und gecachte MP3 liefert.
Komponente in ``app/templates/v3/components/tour.html``, included am
Ende von antrag_detail.html. CSS inline in der Komponente (1 ``<style>``-
Block, keine ``style=""``-Attribute — Anti-Regression-Wache aus #184
respektiert).
Nicht alle 1322 Inline-Style-Vorkommen in einer Sitzung migrieren — aber
zumindest verhindern, dass es mehr werden. Drei Bausteine:
1. ``tools/audit_inline_styles.py`` — CLI für Audit (Cluster, Top-Files)
und Baseline-Erzeugung (--baseline → JSON {file: count}).
2. ``tools/inline_styles_baseline.json`` — eingefrorene IST-Zählung pro
Template-Datei. Wird vom Test als obere Schranke gelesen.
3. ``tests/test_inline_styles_baseline.py`` (3 Tests) — pro Datei
und global: aktuelle Anzahl <= Baseline. Schlägt Alarm bei neuen
Inline-Styles und auch bei neuen Templates mit Inline-Styles, die
noch nicht in der Baseline stehen.
Workflow für künftige Migrationen: Inline-Styles in einer Datei nach
benannten Klassen überführen, Baseline neu einfrieren via
``python3 tools/audit_inline_styles.py --baseline > tools/inline_styles_baseline.json``.
Cluster-Verteilung der 1322 Treffer:
- layout: 625, typography: 323, color: 262, sonstige: 112.
Top-Brennpunkte: index.html (463, Classic-UI Legacy),
auswertungen.html (125), antrag_detail.html v2 (119),
aktuelle-themen.html (82).
1220/1220 Tests grün.
Web-Detail zeigt diese Marker bereits — pro NEIN-Fraktion einen ⚠ wenn
der eigene Wahlprogramm-Score ≥ 7/10 ist (Heuchelei: stimmt gegen die
eigenen Versprechen), pro JA-Fraktion einen ! wenn der Wahlprogramm-
Score < 3/10 (Opportunismus: stimmt zu obwohl Antrag inhaltlich nicht
zum eigenen Programm passt). Im PDF fehlten sie bisher.
Daten-Pfad: report.py rechnet die Marker einmal vor (heuchelei_score /
opportunismus_score aus app/marker.py, gefüttert mit umgemappten
fraktions_scores aus assessment.wahlprogramm_scores) und reicht zwei
Maps fraktion → score ans Template. Template macht nur noch Lookup:
``opportunismus_by_fraktion.get(f)`` neben jeder JA-Fraktion,
``heuchelei_by_fraktion.get(f)`` neben jeder NEIN-Fraktion. Plus
kompakte Legende unter dem Vote-Block, falls überhaupt Marker
vorkommen.
Stimmverhalten und Programm-Treue-Begründungen sind im PDF schon da
(verifiziert bei der Code-Inspektion). Damit ist die "PDF auf Augenhöhe
mit Web-Detail"-Liste aus #175 bis auf News-Match abgehakt; News-Match
explizit out-of-scope nach User-Entscheidung.
Drei Mitigations:
1) Admin-Queue-Polling 5s → 15s. Die Queue ändert sich pro Sekunde
ohnehin nicht spürbar; senkt CPU + Network ohne UX-Verlust.
2) ``pagehide``-Listener in admin_queue.html, admin_stand.html und
auswertungen.html. Zerstört Chart.js-Instanzen + cleart setInterval-
Handles, sobald die Page in den Back/Forward-Cache geht oder
geschlossen wird. Bisher hingen sie bis Browser-GC.
3) /auswertungen: zentrales Cleanup für ``_histChart``, alle ``_svCharts.*``
und ``window._zeitreiheModalChart`` beim pagehide. Bisher zerstört
nur die einzelnen Render-Funktionen ihre Vorgänger; beim Page-Verlassen
blieben sie alle stehen.
Was nicht abgedeckt ist (für eventuelle Folge-Iteration mit konkretem
Heap-Snapshot):
- Lazy-Render lange News-/Drucksachen-Listen via IntersectionObserver
- Detaillierte Detached-DOM-Untersuchung pro Seite
Bestehende Maßnahmen (bereits da, hier nicht angefasst): chart.destroy()
vor jedem neuen Chart, sim.stop() in cluster.html, visibilitychange-
Pause für Polling.
Threads-Encoding: rendered Sonderzeichen als ? oder Rauten, weil der
Text mit zerlegten Codepoints (z.B. ``a`` + Combining Diaeresis statt
``ä``) ankam — Threads' Composer kommt damit nicht klar. Fix: NFC-
Normalisierung (``str.normalize('NFC')``) vor encodeURIComponent. Das
vereinigt zerlegte Umlaute und typografische Anführungszeichen.
Instagram-Share auf macOS: bisher versuchten wir auch auf Desktop den
``navigator.share()``-Pfad mit File. Das öffnet das macOS-Share-Sheet,
zeigt aber nur AirDrop / Mail / Notizen — Instagram-App ist auf Desktop
nicht installiert, also nutzlos. Fix: Mobile-Detection via User-Agent
+ maxTouchPoints (für iPad-iOS-13+-Maskierung). Auf Desktop direkt zu
Pfad B (Download + Clipboard) statt OS-Sheet.
Zwei kleine UI-Bugs:
1) Score in Merkliste fehlte. Ursache: /api/assessment liefert ``gwoeScore``
(camelCase), das Merkliste-Template las ``a.gwoe_score`` (snake_case).
Fix: beide Schreibweisen akzeptieren.
2) Metadaten-Zeile im Antrag-Detail rendert mit Whitespace-Müll, weil die
Jinja-If-Blöcke ohne Whitespace-Steuerung Newlines durchlassen, die
der Browser zu Spaces collapst:
- "13.04.2026 , qwen-plus" (Komma mit Leerzeichen davor) statt
"13.04.2026, qwen-plus".
- "NRW-WP18. Wahlperiode" statt "18. Wahlperiode": ``antrag.wahlperiode``
ist der Filter-Key wie "NRW-WP18", nicht die reine Zahl.
Fix: Whitespace-Steuerung ``{%- ... -%}`` an allen relevanten If-Tags
in der Metadaten-Zeile + Byline. Plus neues Feld
``antrag.wahlperiode_zahl`` (nur die Zahl) im _row_to_detail-Mapping,
das bevorzugt vor ``antrag.wahlperiode`` zur Anzeige genutzt wird.
Vorher: NRW · Drs. 18/18246 · Antrag · NRW-WP18. Wahlperiode · eingebracht 18.03.2026
Eingebracht von SPD — Analyse 13.04.2026 , qwen-plus · 5 Zitate verifiziert
Nachher: NRW · Drs. 18/18246 · Antrag · 18. Wahlperiode · eingebracht 18.03.2026
Eingebracht von SPD — Analyse 13.04.2026, qwen-plus · 5 Zitate verifiziert
User-Feedback: vorherige Pillen-Variante zu schmal/dicht. Stattdessen
gewünscht: Layout wie ursprünglich (head + 2 Programm-Reihen), aber
mit weniger Whitespace und ohne Trennlinien — und die Partei in eine
linke Spalte gezogen, damit head und Programm-Rows nebeneinander
sitzen statt stapeln.
Layout: ``.v3-fraktion`` als CSS-Grid mit zwei Spalten:
- links (140px–25%): Fraktion-Name + Pillen vertikal
- rechts (1fr): zwei Programm-Reihen (Wahlprogramm / Parteiprogramm)
ohne border-top zwischen den Reihen, padding 3px statt 10/8,
font kleiner (11px statt 12px).
Pro Fraktion bisher ~137px (Head + Wahlprogramm-Reihe + Parteiprogramm-
Reihe in drei vertikalen Blöcken). Nutzer wollte deutlich kompakter.
Layout: Fraktion-Name + Antragsteller-/Regierungs-Pillen + zwei
Programm-Pillen (WP / PP) jetzt in EINER flex-row. Pro Programm-Pille
ein klickbares <details> mit Mini-Score-Chip; beim Aufklappen fließt
der Body (Begründung + Zitate) dank ``flex-basis: 100%`` unter die
Zeile in voller Breite.
Höhe collapsed: ~40-45px pro Fraktion (von vorher ~137px). Begründung
in der ausgeklappten Box bekommt zusätzlich einen ``Wahlprogramm:``-/
``Parteiprogramm:``-Präfix, da der Programm-Typ aus der Pille nicht
mehr im Body explizit auftaucht.
Doppelte v3-prog-text-Regel im CSS entfernt (war vergessenes Cruft).
Browser-Quirk: in einem <form> blieb der fetch nach Submit hängen,
auch mit preventDefault() im submit-Handler. Status-Text bekam
"Suche läuft …", aber die Response kam nie an — der Browser hat den
fetch durch den Submit-State des Forms blockiert.
Lösung: <form> → <div>, Button auf type="button". Click direkt an
runSearch binden, Enter via keydown auf dem Input. Keine Form-Submit-
Semantik mehr.
Bei E2E-Smoketest mit Playwright reproduzierbar gefixt.
Folge-Fix zu 501f32b: das body_scripts-Skript läuft am Ende des Body,
da ist DOMContentLoaded oft schon vorbei. Der bisherige Wrapper
``document.addEventListener('DOMContentLoaded', ...)`` wurde dann nie
gefeuert, der Submit-Listener nie gebunden — Suchknopf weiter still.
Lösung: IIFE direkt aufrufen + Idempotenz-Marker (``_quellenBound``)
gegen Doppelbindung.
Bug: ``runSearch`` ist async und returnt damit Promise<false>. Im
Inline-Handler ``onsubmit="return runSearch(event)"`` interpretiert der
Browser den Promise als truthy → Default-Form-Submit läuft an, die
Page navigiert, und der gerade abgesetzte fetch bricht mit
"Failed to fetch" ab. Im echten Browser merkt man's beim Klick auf
"Suchen" oder Enter im Suchfeld: Status bleibt auf "Suche läuft …"
hängen, keine Ergebnisse erscheinen.
Fix: Bindung über ``addEventListener('submit', ...)`` mit
``event.preventDefault()`` synchron vor dem async runSearch-Aufruf.
JS-Direktaufruf von ``runSearch()`` (z.B. bei Filter-Wechsel)
funktioniert weiterhin.
Gefunden bei E2E-Browser-Smoketest mit Playwright.
Folge-Schritt zu #222 (Commit bd591b9): Das große Datenliteral in
``embeddings.py`` (~280 Einträge, 712 Zeilen) wird durch einen
Re-Export aus ``programme.PROGRAMME`` ersetzt. Damit existieren die
Programm-Stammdaten endgültig nur noch an einer Stelle.
Schema-Brücke: Die ``chunks``-Tabelle führt ``typ`` als alte Sammel-
Bezeichnung (``wahlprogramm`` oder ``parteiprogramm``).
``programme.PROGRAMME`` differenziert ``grundsatzprogramm-bund`` vs.
``grundsatzprogramm-land``. Beim Re-Export werden beide auf
``parteiprogramm`` gemappt — alte Chunks und neue Indexierungen
tragen denselben typ-String, der Filter in
``get_relevant_quotes_for_antrag`` (typ="parteiprogramm") deckt
beide Grundsatzprogramm-Varianten weiter ab.
embeddings.py schrumpft von 1574 auf 926 Zeilen (−648). Tests
unverändert grün (1217 passed).
Schließt #224. ADR 0013 hat die Datenbasis für historische Bewertung
geschaffen (programme.PROGRAMME mit gueltig_ab/gueltig_bis); jetzt
nutzt der Analyzer sie auch tatsächlich.
Vorher: get_relevant_quotes_for_antrag suchte über ALLE Wahl- und
Grundsatzprogramme einer Partei in einem BL — egal aus welcher WP.
Folge: ein Antrag aus 2018 in NRW konnte Zitate aus dem cdu-nrw-2022
Wahlprogramm (das er noch nicht kennen konnte) zugeordnet bekommen.
Anachronismus-Halluzination.
Nachher: Wenn ``datum`` (ISO YYYY-MM-DD) durchgereicht wird, filtert
``find_relevant_chunks`` die Chunks auf Programme mit
``[gueltig_ab, gueltig_bis)`` ⊇ datum. Programme, die zum
Antragszeitpunkt nicht galten, werden komplett ausgelassen.
Signaturen erweitert (alle additiv, datum=None ⇒ altes Verhalten):
- embeddings.find_relevant_chunks(..., datum=None)
- embeddings.get_relevant_quotes_for_antrag(..., datum=None)
- analyzer.analyze_antrag(..., datum=None)
main.run_drucksache_analysis: reicht doc.datum durch (DIP/OPAL liefern
das Antragsdatum vor dem LLM-Call, kein Zwei-Pass-Workaround nötig).
Tests:
- test_embeddings.test_datum_param_is_passed_through_to_find_relevant_chunks
- test_bug_regressions.test_analyzer_propagates_datum_to_embeddings
1244/1244 Unit-Tests grün.
parteien.py listet 'BiW' als kanonischen Key (Mixed-Case), 'BIW' nur als
Alias. Bestehende HB-Assessments tragen bereits 'BiW' in
wahlprogramm_scores. Beim Block 2.4 hatte ich die historischen BiW-
Wahlprogramme aber mit "BIW" angelegt — Folge: find_relevant_chunks
mit parteien=["BiW"] hätte die 131 Chunks der biw-hb-*-PDFs nicht
gefunden, weil der partei-Filter exakt matcht.
Geändert:
- embeddings.PROGRAMME: 3 biw-hb-* Einträge "partei": "BIW" → "BiW"
- wahlprogramme.WAHLPROGRAMME["HB"]: Key "BIW" → "BiW", "partei" Feld
"BIW Bremen" → "BiW Bremen"
- test_hb_has_five_parteien: erwartete Set entsprechend angepasst
Folge-Schritt: chunks.partei in der embeddings.db muss von 'BIW'
auf 'BiW' migriert werden — die 131 betroffenen Chunks werden beim
nächsten Reindex der biw-hb-* Programme ohnehin überschrieben.
92/92 Programme-Tests grün, 1242 Unit-Tests grün.
Zwei kleine Verbesserungen, die beim Schreiben der Drift-Tests in
bf5400a aufgefallen sind:
1. HB-Datum-Typo: regierungsbildung war 2023-07-04 (Tag der Konstituierung
der 21. Bürgerschaft), korrekt ist 2023-07-05 (Vereidigung Senat
Bovenschulte II). 5 Einträge angepasst (SPD/CDU/GRÜNE/LINKE/BIW).
Kommentar im Header ebenfalls.
2. Helper-Docstrings (regierungsbildung_for, regierungsende_for,
regierung_aktuell) explizit darüber, dass das Datum die ERSTE
Regierung der WP ist, NICHT die aktuell amtierende. Wichtig bei
Sukzessionen wie RP WP18 (Dreyer III 2021-05-18 → Schweitzer I
2024-07-10) — die 2021er Wahlprogramme bleiben wirksam, auch nach
MP-Wechsel. Für aktuell amtierende Regierung gibt es
``legislaturen.aktuelle_regierung``.
92/92 Programme-Tests grün.
ADR 0013 hatte als offene Folge "Doppelter Daten-Bestand zwischen
WAHLPROGRAMME und embeddings.PROGRAMME ist nicht aufgelöst — Risk:
stille Drift". Der invasive Compat-Shim (#222) ist aufwendig; bis
dahin fängt eine neue Test-Klasse die Drift bidirektional ab:
TestWahlprogrammeProgrammeConsistency (4 Tests):
- Jeder WAHLPROGRAMME-Eintrag hat ein passendes aktuelles Programm in
PROGRAMME (sonst liefert aktuelles_wahlprogramm None)
- pdf-Dateinamen müssen übereinstimmen (file == pdf)
- Partei-Kurzform muss übereinstimmen
- Jedes aktuelle Wahlprogramm in PROGRAMME muss auch in WAHLPROGRAMME
registriert sein (orphan-check andere Richtung)
Drift-Funde dabei:
- BIW (Bürger in Wut) HB war in PROGRAMME (biw-hb-2023, biw-hb-2019,
biw-hb-2015), aber NICHT in WAHLPROGRAMME-HB. Bewertungs-Pipeline
hätte BIW-Anträge gegen kein Wahlprogramm geprüft. Eintrag ergänzt:
BÜRGER IN WUT — Programm Bürgerschaftswahl 2023 (26 Seiten).
- Test test_hb_has_four_parteien → test_hb_has_five_parteien.
92/92 Programme-Tests grün.
GET /api/quellen/search?q=&filter=current|all&top_k=&bundesland=&partei=
nutzt text-embedding-v4 für wortunscharfe Suche (Endungen + Synonyme).
Filter:
- filter=current: nur Programme mit gueltig_bis IS NULL (Default)
- filter=all: auch historische Programme
Response liefert pro Treffer name, partei, bundesland, gueltig_ab/bis,
seite, gekürztes Snippet, similarity, plus pdf_url mit Direkt-Sprung
ins highlightete PDF (über /api/wahlprogramm-cite).
UI auf /quellen oben über der BL-Auflistung:
- Suchfeld + Submit
- Radio-Toggle "nur aktuelle Programme" / "auch historische"
- Treffer-Karten mit Partei-Badge, gültig-Pille (grün/grau),
Seite + Relevanz-%, Snippet, Direktlink ins PDF
- Filter-Wechsel triggert automatischen Re-Run
Smoketest dev: "Klimaschutz" liefert 13 Treffer in aktuellen Programmen
mit korrekter Similarity-Sortierung; "Solidarität" mischt Wahl- und
Grundsatzprogramme. Zugriff erfordert keinen Login (read-only).
Security-Audit ergab 3 CRITICAL CVEs im python:3.12-slim-Base
(Debian-Bullseye-Reste, deren Updates erst mit Debian-Bookworm-Bump
kommen). Wechsel auf python:3.12-alpine, das aktuell 0 CRITICAL hat.
Aenderungen:
- FROM python:3.12-slim -> python:3.12-alpine
- apt-get -> apk add (zwei Phasen: runtime + build-deps mit virtual,
build-deps werden nach pip install entfernt)
- adduser-Syntax: Alpine `adduser -D -u 1000` statt Debian-Variante
- Zusaetzliche build-deps fuer C-Extensions: build-base, gcc, musl-dev,
rust+cargo (cryptography), libxml2-dev/libxslt-dev (lxml), openssl-dev
- Runtime-Pakete fuer WeasyPrint: pango, cairo, gdk-pixbuf,
shared-mime-info, fontconfig, ttf-dejavu
Image-Groessen-Effekt: Alpine + alle Build-Deps nach Cleanup
~250 MB statt slim ~480 MB.
Auto-Deploy auf gwoe-antragspruefer-dev rebuilt sich alle 5 Min via
auto-deploy.sh-Cron — Wirksamkeit innerhalb der naechsten 10 Min
sichtbar. gwoe-antragspruefer (prod, eingefroren auf v1.0.2) bekommt
das beim naechsten Release.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 Programme zur LTW NRW 14.05.2017 als historische Wahlprogramme im
Embeddings-Index — erster Datensatz für die zeitpunktige Bewertung
historischer Antraege:
- cdu-nrw-2017 (Laschet, 120 S., 172 chunks)
- spd-nrw-2017 (Kraft, 116 S., 169 chunks)
- gruene-nrw-2017 (131 S., 322 chunks)
- fdp-nrw-2017 (Lindner, 56 S., 92 chunks)
- afd-nrw-2017 (84 S., 78 chunks)
Geltungszeitraum 2017-05-14 (Wahltag WP17) bis 2022-05-15 (Wahltag
WP18, exklusiv). Eintraege liegen NUR in embeddings.PROGRAMME — die
WAHLPROGRAMME[NRW]-Struktur bleibt single-current (cdu-nrw-2022).
programme._migrate_from_legacy hat einen neuen Schritt 2b, der
typ=wahlprogramm-Eintraege aus embeddings.PROGRAMME mit explizitem
gueltig_ab/_bis als historische Wahlprogramme registriert. Damit
liefert wahlprogramm_zum_zeitpunkt() jetzt fuer NRW-Antraege aus dem
Zeitraum 2017-2022 das passende Programm.
Live-Verifikation auf gwoe-antragspruefer-dev:
- 2018-09-01 -> cdu-nrw-2017 (WP17)
- 2024-01-01 -> cdu-nrw-2022 (WP18)
- Grenze: 14.05.2022 -> WP17, 15.05.2022 -> WP18
Tests: 116 gruen, plus neue test_grenze_zwischen_wp17_und_wp18 und
angepasstes test_datum_vor_aktueller_wp_nrw_wp17.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Antwort auf B1 + B2 aus der Roadmap:
- B1: Antrag VOR Regierungsbildung (z.B. NRW WP18-Antrag im Mai 2022,
vor Vereidigung Wuest II am 29.06.2022) bekommt jetzt das passende
Wahlprogramm zurueck — der Geltungsbeginn ist der Wahltag, nicht die
Vereidigung.
- B2: Opposition vs. Regierung wird einheitlich behandelt. Die fruehere
Logik "Geltung ab Regierungsbildung" war fuer Regierungsfraktionen
intuitiv (Koalitionsvertrag wird zu Politik), fuer Opposition aber
willkuerlich. Programme werden zur Wahl beschlossen und sind
Wahlversprechen ab dem Tag der Wahl.
Implementation in programme._migrate_from_legacy:
- gueltig_ab = aktuelle_legislatur(bl)["wahltermin"] (Fallback auf
altes "regierungsbildung" fuer rueckwaerts-kompatible Eintraege)
- ``wahl``-Feld auf Wahltag gesetzt
- ``wp``-Feld aus aktuelle_legislatur ergaenzt
Das ``regierungsbildung``-Feld in WAHLPROGRAMME bleibt erhalten und
versorgt den Bewertungs-Kontext-Block weiterhin mit dem Anzeige-Wert
"Regierung zur Antragszeit" (per legislaturen.regierung_zum_zeitpunkt
laeuft das primaer ueber legislaturen.REGIERUNGEN).
UI-Effekt: im Antrag-Detail liest sich z.B. ein BUND-Eintrag jetzt
"gueltig seit 2025-02-23, 60 S." (BTW-Wahltag) statt "2025-05-06"
(Vereidigung Merz I).
Tests: 115 gruen (test_programme + test_legislaturen + test_wahlprogramme
+ test_embeddings). Tests test_bund_btw_2025_in_uebergangsphase und
test_bund_btw_2025_vor_wahl neu, decken die geaenderte Geltungs-Logik
explizit ab.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Neue Sektion auf /methodik (zwischen "Analyse-Pipeline" und "Stimmverhalten
& Marker"), die transparent macht, gegen welches Wahlprogramm der Prüfer
einen Antrag misst. Erklärt:
- Wahlperiode → Programm-Geltung (Konstituierung, nicht Wahltag)
- Regierung zur Antragszeit (mit Sukzession-Beispiel Dreyer III →
Schweitzer I)
- Wahlprogramm-Liste pro Antragsteller-Fraktion mit Geltungsdatum
- Snapshot-Hinweis (Bewertungsdatum + Modell)
Plus ehrliche Einschraenkung: aktuell nur die jeweils gegenwaertigen
Wahlprogramme im Embeddings-Index. Architektur ist fuer historische
Indexierung vorbereitet (siehe ADR 0013).
Inhaltsverzeichnis-Link ergaenzt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Direkte Test-Abdeckung der zentralen Programm-Registry. Vorher nur
indirekt via test_legislaturen.py (das nicht aus programme.py importiert)
und ueber den Antrag-Detail-Smoke-Test.
Geprueft:
- Migration aus WAHLPROGRAMME + embeddings.PROGRAMME (>80 Eintraege,
alle Pflichtfelder, eindeutige IDs, alle drei Typen vertreten)
- aktuelles_wahlprogramm: NRW/CDU → 2022, BUND/CDU → BTW 2025; XX → None
- wahlprogramm_zum_zeitpunkt: 2024 in NRW gibt cdu-nrw-2022; vor 2025-05-06
in BUND gibt None (BTW-2025-Programme gelten erst ab Regierungsbildung)
- grundsatzprogramm_zum_zeitpunkt: BL-Fallback (CDU NRW → cdu-grundsatz-nrw,
CDU HE → cdu-grundsatz Bund-Fallback); SSW/SH; CSU 2023
- parteien_mit_wahlprogramm: NRW=5, BUND=8
- alle_versionen, get_programm, Edge-Cases
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Erweiterung des Geltungs-Kontext-Blocks (Antrag-Detail):
- Programm-Titel als Link auf das PDF ({titel} klickbar →
/static/referenzen/{pdf}, opens in new tab).
- Seitenzahl als ergaenzende Info: "116 S." neben Geltungsdatum.
- Snapshot-Zeile am Block-Ende: "Diese Bewertung wurde am
{datum} mit {modell} gegen den oben genannten Programm-Stand
erzeugt." — macht klar, dass die Anzeige eine Momentaufnahme der
damaligen LLM-Bewertung ist und nicht "live" gegen heutige
Programme misst.
CSS:
- v3-geltung-pdf: ECG-blauer Link mit dezenter underline-Linie.
- v3-geltung-snapshot: kursiv, getrennt durch hairline-border, gedaempft.
Tests: 88 grün (test_legislaturen + test_wahlprogramme + test_embeddings).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vor der Programm-Treue-Sektion eine kompakte Info-Box, die transparent
macht, was zur Antragszeit fuer das jeweilige Parlament galt:
- **Wahlperiode** (Nummer + Konstituierung-bis-Ende-Spanne) ueber
legislatur_zum_zeitpunkt(bl, antrag_datum)
- **Regierung zur Antragszeit** (Name + Koalitionsparteien + Vereidigung,
ggf. Endedatum bei Sukzessionen wie Dreyer III -> Schweitzer I) ueber
regierung_zum_zeitpunkt(bl, antrag_datum)
- **Bewertet gegen die folgenden Wahlprogramme** (pro Antragsteller-
Fraktion mit gueltig-seit-Datum) ueber wahlprogramm_zum_zeitpunkt
pro Partei
Daten kommen aus den neuen Modulen app/legislaturen.py + app/programme.py.
Helper laufen historisch korrekt — z.B. ein Antrag aus 2020-02-15 in TH
wuerde "Kemmerich I (FDP)" zurueckliefern.
Aktuell zeigen alle Antraege die jeweils "aktuelle" Regierung & das
aktuelle Programm, weil keine historischen Wahlprogramme im Embeddings-
Index sind. Die Architektur ist aber fuer den Tag vorbereitet, wo
historische Programme indiziert werden.
Implementation:
- main.py: _render_antrag_detail laedt geltung_kontext und gibt es ans
Template weiter. ISO-Datum aus row["datum"] (nicht aus dem display-
formatierten antrag["datum"]).
- v3/screens/antrag_detail.html: neue Sektion v3-geltung vor Programm-
Treue-Block.
- static/v3/v3.css: neue v3-geltung-Klassen mit dezentem Doku-Look.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
