gwoe-antragspruefer/docs/protokoll-parser-roadmap.md

Plenarprotokoll-Parser Roadmap pro Bundesland

Stand 2026-04-28. Architektur fertig (ADR 0009), NRW-Parser produktiv, Cron-Infrastruktur (scripts/auto-ingest-protocols.sh) BL-erweiterbar. Pro weiterem BL ist ein eigener Parser zu implementieren — das ist deterministische Reverse-Engineering-Arbeit, keine LLM-Calls, keine Kosten.

Stub-Module + Folge-Issues

Pro BL ein Modul app/protokoll_parsers/<bl>.py mit Recherche-Findings im Docstring und NotImplementedError als Body. Stubs sind nicht in PROTOKOLL_PARSERS registriert — der Auto-Ingest-Cron ueberspringt sie. Sobald ein Parser implementiert ist, verschwindet der NotImplementedError- Body und der Eintrag wird in PROTOKOLL_PARSERS ergaenzt.

BL	Stub-Modul	Tracking-Issue
BUND	bund.py	#148
BB	bb.py	#149
BE	be.py	#150
BW	bw.py	#151
BY	by.py	#152
HB	hb.py	#153
HE	he.py	#154
HH	hh.py	#155
LSA	lsa.py	#156
MV	mv.py	#157
NI	ni.py	#158
RP	rp.py	#159
SH	sh.py	#160
SL	sl.py	#161
SN	sn.py	#162
TH	th.py	#163

Pattern fuer neue BL

1. Sample-PDF/HTML/XML besorgen und Vote-Anchor-Phrasen identifizieren.
2. app/protokoll_parsers/<bl>.py anlegen mit parse_protocol(path) -> list[dict] nach Vertrag aus ADR 0009.
3. Eintrag in PROTOKOLL_PARSERS (in __init__.py).
4. Tests in tests/test_protokoll_parsers_<bl>.py.
5. PROTO_TARGETS in scripts/auto-ingest-protocols.sh ergaenzen.
6. Backfill einmal manuell laufen lassen.

Pro Bundesland: bekannter Stand

NRW ✅ produktiv

• URL: https://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument/MMP{wp}-{n}.pdf
• Format: PDF mit deterministischen Anchor-Phrasen ("Damit ist X angenommen/abgelehnt")
• Parser: app/protokoll_parsers/nrw.py
• Tests: 38 Tests, Fixture-Garantie 19/19 auf MMP18-119

Bundestag (BUND) — anderer Vote-Sprache als NRW

• URL: https://dserver.bundestag.de/btp/{wp}/{wp}{n:03}.pdf (z.B. 20184 = WP20 Sitzung 184)
• Format: PDF, ~1 MB pro Sitzung, ~600k Zeichen Text.
• Vote-Anchor-Phrasen unterscheiden sich von NRW:
  • Bundestag nutzt: „Wer dem Gesetzentwurf seine Zustimmung gibt, den bitte ich, sich zu erheben", „Damit ist der Gesetzentwurf in zweiter Beratung angenommen", „... mit den Stimmen der Koalition gegen die Stimmen der Opposition abgelehnt"
  • „angenommen" und „überwiesen" haeufig in „in zweiter Beratung angenommen" oder „zur federführenden Beratung an den Ausschuss"
• Vote-Daten: bei „namentliche Abstimmung" als separate XML-Datei unter https://dserver.bundestag.de/.../btp{wp}-{n}-namentlich.xml (alternative datenquelle, strukturiert!)
• Empfehlung: Statt PDF-Parsen den XML-Endpoint fuer namentliche Abstimmungen nutzen — dort liegt fraktions-aggregiertes Vote bereits als Struktur vor.
• Aufwand: ~1-2 Tage

MV — ParlDok 8.x SPA

• URL-Pattern: https://www.dokumentation.landtag-mv.de/parldok/dokument/{id}/{slug}.pdf
• Format: PDF, aber {id} ist nicht-vorhersagbar — braucht Listen-API von ParlDok-Suche
• Workaround: Suche via Plenarprotokoll-Filter, Liste der IDs holen
• Aufwand: ~2 Tage (URL-Discovery + Parser-Bau)

Bayern (BY) — Pfad-Pattern noch zu verifizieren

• Format: PDF
• URL aus dokukratie-yml ziehen (nicht direkt dokumentiert)
• Aufwand: ~2 Tage

Brandenburg (BB)

• URL-Pattern: https://www.landtag.brandenburg.de/... mit eigenem Schema
• Format: PDF mit Vote-Tabellen
• Aufwand: ~2-3 Tage (Tabellen-Parsing aufwendiger als reine Text-Anchors)

Berlin (BE)

• Pardok-Plattform (analog LSA, BE)
• URL via Search-API
• Aufwand: ~2 Tage

Bremen (HB), Hamburg (HH), Saarland (SL)

• Stadtstaaten, kleinere Landtage
• Format-Recherche pro Stadt; oft PDFs mit weniger formalen Anchors
• Aufwand: je ~1-2 Tage

Hessen (HE)

• Webseiten-Plenarprotokolle z.T. als HTML strukturiert (semantische Tags pro Beschluss)
• Wenn HTML zugaenglich: einfacher als PDF
• Sample-URL muss recherchiert werden
• Aufwand: ~1-2 Tage

Niedersachsen (NI)

• nilas-Portal Login-protected (siehe feedback_silent_excepts.md)
• Plenarprotokolle ggf. auf eigener Seite ohne Login
• Aufwand: ~2-3 Tage (Login-Workaround pruefen)

Rheinland-Pfalz (RP)

• OPAL_extern, abweichend zu NRW-OPAL
• PDF-URLs dokumentiert in dokukratie-yml
• Aufwand: ~2 Tage

Sachsen (SN)

• ASP.NET-Webforms — Postback-Handling fuer Suche noetig
• Plenarprotokoll-Liste via XML-Export
• Synergie mit bestehendem app/sn_xml_export-Workflow moeglich
• Aufwand: ~1-2 Tage

Sachsen-Anhalt (LSA)

• Padoka-Plattform (analog BE)
• URL via Search-API
• Aufwand: ~2 Tage

Schleswig-Holstein (SH)

• Starfinder-CGI-Backend
• Format: PDF
• Aufwand: ~2 Tage

Thüringen (TH)

• ParlDok-Plattform (analog MV)
• Synergien mit MV-Parser hoch
• Aufwand: ~1-2 Tage (nach MV)

Baden-Württemberg (BW)

• PARLIS-Eigensystem
• Format: PDF
• Aufwand: ~2 Tage

Implementations-Reihenfolge nach Aufwand-Nutzen

1. MV + TH parallel (gleiche ParlDok-Plattform, Synergien)
2. BUND (XML-Endpoint!) — strukturierte Daten leichter als PDF-Parser
3. HE wenn HTML-Plenarprotokolle existieren
4. Rest nach Bedarf

Cron-Erweiterung pro neuem BL

In scripts/auto-ingest-protocols.sh einen PROTO_TARGETS-Eintrag ergaenzen:

PROTO_TARGETS=(
  "NRW|18|https://www.landtag.nrw.de/.../MMP18-{n}.pdf"
  "BUND|20|https://dserver.bundestag.de/btp/20/20{n:03}.pdf"
  ...
)

Format-Spec: BL_CODE|WAHLPERIODE|URL_MIT_{n}_PLACEHOLDER. Das Skript erkennt automatisch das letzte ingestete Protokoll dieses BL/WP und inkrementiert.