bundeslaender.py: doku_system-Klassifikation für TH, HB, SN korrigieren #48

New Issue

tobias · 2026-04-08T23:06:54+02:00

tobias commented

2026-04-08 23:06:54 +02:00

Beim Auswerten der dokukratie-YAML-Configs (Annotationen in #19-#30) sind drei Falsch-Einträge in bundeslaender.py aufgefallen, die zu unnötigem Reverse-Engineering-Aufwand führen würden, wenn sie nicht vor den Adapter-Implementierungen korrigiert werden:

Korrekturen

Code	aktuell	korrekt	Begründung
TH	`StarWeb`	`ParlDok`	`dokukratie/th.yml` zeigt Endpoint `parldok.thueringen.de/ParlDok/formalkriterien/` mit ParlDok-typischen Form-Feldern (`DokumententypId`, `LegislaturPeriodenNummer`). Live-System ist möglicherweise schon ParlDok 8.x SPA wie MV — dann sogar `ParLDokAdapter` (#4) direkt wiederverwendbar. Siehe Annotation in #25.
HB	`PARiS`	`StarWeb`	`dokukratie/hb.yml` zeigt PARiS-Endpoint `paris.bremische-buergerschaft.de/starweb/paris/servlet.starweb?path=paris/LISSH.web` — das ist eine StarWeb-Skin, nicht eine eigenständige Engine. PARiS ist nur ein Branding für eine bremische StarWeb-Instanz. Siehe Annotation in #21.
SN	`ParlDok`	`Eigensystem (ASP.NET/EDAS)`	`dokukratie/sn.yml` zeigt EDAS-Endpoint mit `__CALLBACKID`/`__CALLBACKPARAM` — klassische ASP.NET-Webforms-Postbacks, nicht ParlDok-kompatibel. Der `ParLDokAdapter` aus #4 ist hier NICHT wiederverwendbar. Reverse-Engineering der `__VIEWSTATE`-Postback-Mechanik erforderlich. Siehe Annotation in #26.

Was zu tun ist

# bundeslaender.py
"TH": Bundesland(
    ...
    doku_system="ParlDok",  # war: "StarWeb"
    anmerkung="...; Doku-System ist ParlDok (siehe dokukratie/th.yml), eventuell ParlDok 8.x SPA wie MV — vor Implementierung verifizieren via curl.",
    ...
),
"HB": Bundesland(
    ...
    doku_system="StarWeb",  # war: "PARiS"
    anmerkung="...; PARiS ist eine StarWeb-Skin auf paris.bremische-buergerschaft.de, kein eigenständiges System — wiederverwendbar mit dem generischen StarWebAdapter.",
    ...
),
"SN": Bundesland(
    ...
    doku_system="Eigensystem",  # war: "ParlDok"
    anmerkung="...; EDAS auf edas.landtag.sachsen.de basiert auf ASP.NET-Webforms (__CALLBACKID-Postbacks), NICHT auf ParlDok. Eigene Implementierung nötig.",
    ...
),

Akzeptanzkriterien

bundeslaender.py mit den drei korrigierten doku_system-Werten + erweiterten anmerkung-Texten
In project_state.md Memory eintragen: doku_system-Klassifikation immer aus der dokukratie-yml verifizieren, nicht aus Wikipedia/eigener Annahme
Der Patch ist 5 Minuten Arbeit, kann sofort gemacht werden — kein Adapter-Code involviert

Beziehung zu anderen Issues

Blockiert keine, ist aber eine Voraussetzung für die korrekte Schätzung der Restzeit von #25 (TH), #21 (HB), #26 (SN). Wenn dieses Issue NICHT zuerst gefixt wird, läuft jemand möglicherweise in das falsche Adapter-Template.

Beim Auswerten der dokukratie-YAML-Configs (Annotationen in #19-#30) sind drei Falsch-Einträge in `bundeslaender.py` aufgefallen, die zu unnötigem Reverse-Engineering-Aufwand führen würden, wenn sie nicht vor den Adapter-Implementierungen korrigiert werden: ## Korrekturen | Code | aktuell | korrekt | Begründung | |---|---|---|---| | **TH** | `StarWeb` | `ParlDok` | `dokukratie/th.yml` zeigt Endpoint `parldok.thueringen.de/ParlDok/formalkriterien/` mit ParlDok-typischen Form-Feldern (`DokumententypId`, `LegislaturPeriodenNummer`). Live-System ist möglicherweise schon ParlDok 8.x SPA wie MV — dann sogar `ParLDokAdapter` (#4) direkt wiederverwendbar. Siehe Annotation in #25. | | **HB** | `PARiS` | `StarWeb` | `dokukratie/hb.yml` zeigt PARiS-Endpoint `paris.bremische-buergerschaft.de/starweb/paris/servlet.starweb?path=paris/LISSH.web` — das ist eine StarWeb-Skin, nicht eine eigenständige Engine. PARiS ist nur ein Branding für eine bremische StarWeb-Instanz. Siehe Annotation in #21. | | **SN** | `ParlDok` | `Eigensystem (ASP.NET/EDAS)` | `dokukratie/sn.yml` zeigt EDAS-Endpoint mit `__CALLBACKID`/`__CALLBACKPARAM` — klassische ASP.NET-Webforms-Postbacks, **nicht ParlDok-kompatibel**. Der `ParLDokAdapter` aus #4 ist hier NICHT wiederverwendbar. Reverse-Engineering der `__VIEWSTATE`-Postback-Mechanik erforderlich. Siehe Annotation in #26. | ## Was zu tun ist ```python # bundeslaender.py "TH": Bundesland( ... doku_system="ParlDok", # war: "StarWeb" anmerkung="...; Doku-System ist ParlDok (siehe dokukratie/th.yml), eventuell ParlDok 8.x SPA wie MV — vor Implementierung verifizieren via curl.", ... ), "HB": Bundesland( ... doku_system="StarWeb", # war: "PARiS" anmerkung="...; PARiS ist eine StarWeb-Skin auf paris.bremische-buergerschaft.de, kein eigenständiges System — wiederverwendbar mit dem generischen StarWebAdapter.", ... ), "SN": Bundesland( ... doku_system="Eigensystem", # war: "ParlDok" anmerkung="...; EDAS auf edas.landtag.sachsen.de basiert auf ASP.NET-Webforms (__CALLBACKID-Postbacks), NICHT auf ParlDok. Eigene Implementierung nötig.", ... ), ``` ## Akzeptanzkriterien - [ ] `bundeslaender.py` mit den drei korrigierten `doku_system`-Werten + erweiterten `anmerkung`-Texten - [ ] In `project_state.md` Memory eintragen: `doku_system`-Klassifikation immer aus der dokukratie-yml verifizieren, nicht aus Wikipedia/eigener Annahme - [ ] Der Patch ist 5 Minuten Arbeit, kann sofort gemacht werden — kein Adapter-Code involviert ## Beziehung zu anderen Issues Blockiert keine, ist aber eine Voraussetzung für die korrekte Schätzung der Restzeit von #25 (TH), #21 (HB), #26 (SN). Wenn dieses Issue NICHT zuerst gefixt wird, läuft jemand möglicherweise in das falsche Adapter-Template.

tobias referenced this issue

2026-04-08 23:16:34 +02:00

Roadmap: Adapter-Implementierungs-Reihenfolge nach Aufwand/Synergie #49

tobias added the

phase-0

label 2026-04-08 23:16:43 +02:00

tobias referenced this issue from a commit

2026-04-08 23:19:43 +02:00

bundeslaender.py: doku_system-Klassifikation für TH, HB, SN korrigiert (#48)

tobias commented

2026-04-08 23:19:51 +02:00

Erledigt in 5a30ce8. Drei Klassifikations-Einträge in app/bundeslaender.py korrigiert plus Anmerkungs-Texte mit Adapter-Wiederverwendungs-Hinweisen und Verifikations-Schritten für die jeweiligen Live-Systeme. Phase 0 aus #49 abgehakt — Phase 1 (#29 BW) kann beginnen.

Erledigt in 5a30ce8. Drei Klassifikations-Einträge in `app/bundeslaender.py` korrigiert plus Anmerkungs-Texte mit Adapter-Wiederverwendungs-Hinweisen und Verifikations-Schritten für die jeweiligen Live-Systeme. Phase 0 aus #49 abgehakt — Phase 1 (#29 BW) kann beginnen.

tobias closed this issue

2026-04-08 23:19:51 +02:00

Sign in to join this conversation.