d0f7b9217c
Saarland publiziert keine Wortprotokolle, sondern eigene HTML-Seiten
mit strukturierten Abstimmungsergebnissen pro Sitzung:
<p>Drucksache 17/2076 ... in Erster Lesung mit Stimmenmehrheit
angenommen ... [SPD: dafür; CDU und AfD: dagegen]</p>
Daher Input ist HTML, nicht PDF. Parser nutzt LI-Block-Iteration und
extrahiert pro Block:
- Drucksache aus "Drucksache N/M"
- Status aus "(einstimmig|mit Stimmenmehrheit)? (angenommen|abgelehnt)"
- Vote-Block aus "[SPD: dafür; CDU: dagegen; AfD: Enthaltung]"
- einstimmig=True falls Status enthaelt "einstimmig"
Vote-Bracket-Parser (eigenstaendig vs. Reden-Stil-Parser anderer BL):
- Splits per ; → "Phrase: Status"
- Phrase per Wortgrenzen-Regex auf {SPD,CDU,AfD} matchen
- Status-Map: dafür→ja, dagegen→nein, Enthaltung→enthaltung
URL-Pattern (nicht direkt vorhersagbar wegen Datums-Slug):
https://www.landtag-saar.de/aktuelles/mitteilungen/abstimmungsergebnisse-der-{n}-landtagssitzung-vom-{datum}/
Auto-Ingest via Index-Scrape (analog HH/HE/SH):
- /aktuelles/mitteilungen/ scrape
- WP16-URLs (mit "wahlperiode-vom") ueberspringen
- Pro neue Sitzung: HTML herunterladen, ingest_pdf-API auf .html-Datei
Tests: 18 SL-Tests (Verifikation Sitzung 46 → 18 Votes mit korrekten
JA/NEIN/ENTH-Listen). Stand: 9 produktive Parser
(NRW, BUND, BE, HH, TH, HE, SH, HB, SL).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| adr | ||
| analysen | ||
| archive | ||
| how-to | ||
| reference | ||
| index.md | ||
| protokoll-parser-roadmap.md | ||
| README.md | ||
GWÖ-Antragsprüfer — Dokumentation
Diese Dokumentation folgt dem Diátaxis-Framework und ist nach Funktion (nicht nach Themen) organisiert. Drift-immun durch klare Trennung: Reference wird aus dem Code generiert, ADRs sind immutable, Tutorials/How-to sind manuell gepflegt aber knapp.
Struktur
docs/
├── README.md ← du bist hier
├── adr/ Architecture Decision Records (immutable)
│ ├── README.md ADR-Index + Workflow
│ ├── template.md Template für neue ADRs
│ └── NNNN-titel.md Eine Datei pro Entscheidung
└── archive/ Historische Snapshots, nicht autoritativ
Geplant für später (siehe Issue #62):
docs/
├── reference/ ← mkdocs autodoc-Output (nicht eingecheckt)
├── tutorials/ ← Erst-Schritt-Anleitungen
├── how-to/ ← Aufgaben-orientiert, "wie deploye ich"
└── explanation/ ← Hintergründe, Konzepte
Nicht hier dokumentiert (bewusst)
| Was | Wo |
|---|---|
| API-Reference (Endpoints, Models, Schemas) | Auto-generiert aus FastAPI/Pydantic, nicht in docs/ einchecken |
| Code-Reference (Klassen, Funktionen) | mkdocstrings aus den Docstrings (geplant Phase 2) |
| Aktueller Projekt-Stand / Issues | Gitea Issues — repo.toppyr.de/tobias/gwoe-antragspruefer/issues |
| Onboarding für KI-assisted Coder | CLAUDE.md im Repo-Root |
| Live-System-Status | https://gwoe.toppyr.de/auswertungen (dynamisches Dashboard) |
| Memory der KI-Sessions | ~/.claude/projects/<projekt>/memory/ (privat) |
Gegen Drift
- ADRs sind immutable: nie überschreiben, sondern bei Änderung mit einem neuen ADR superseden, der den alten in seinem Header referenziert.
- Reference wird aus dem Code generiert, nie von Hand gepflegt.
docs/archive/enthält historische Status-Files. Werden gelesen aber nicht aktualisiert. Wenn etwas davon noch wahr ist, gehört es in einen ADR oder in die generierte Reference, nicht in einen neuen Status-Snapshot.