Bekannte offene Punkte

Bekannte offene Punkte

Noch offen

• Kein nachgewiesenes Offsite-Backup: Lokale Dumps liegen standardmässig auf demselben Host wie die Datenbank. backup_db.sh unterstützt rclone, ein Remote muss aber organisatorisch ausgewählt, eingerichtet und durch regelmässige Restore-Tests geprüft werden.
• Observability ist überwiegend host- und logbasiert: Healthchecks, Error-Logs und pg_stat_statements existieren, aber zentrale Metriken, Alarmierung und eine definierte On-Call-/Eskalationskette sind noch nicht vollständig dokumentiert bzw. umgesetzt.
• focused-element-editor.tsx ist weiterhin eine sehr grosse Frontend-Datei und ein Kandidat für eine weitere fachliche Aufteilung, wenn sie weiter wächst.
• backend-tests in GitHub Actions bleibt rot (2026-08-28): 3 der 501 Backend-Tests (test_export_pdf_of_empty_protocol_does_not_crash, test_export_pdf_typical_protocol_produces_a_real_pdf, test_export_pdf_end_to_end_still_produces_a_real_pdf_with_batch_titles) schlagen nur auf dem GitHub-hosted Runner fehl, nicht lokal und nicht im echten Docker-Deploy. Ursache: export_service.pys pdflatex-Aufruf läuft mit -cnf-line=openin_any=p (Paranoid-Modus, blockiert \input/\openin ausserhalb des Compile-Verzeichnisses gegen Template-gesteuertes Auslesen beliebiger Dateien) und übergibt Haupt-Datei sowie -output-directory als absolute Pfade. Auf dem Runner (Ubuntu-texlive-Paket) lehnt kpathsea das ab ("Not reading from .../main.tex (openin_any = p)"), auf Debian-Paketen (lokale Docker-Images, Produktions-Image) nicht. Ein Versuch, stattdessen relative Pfade zu übergeben (der Prozess läuft ohnehin mit cwd im Compile-Verzeichnis), hat lokal einen anderen, korrekt-relativen \input-Bezug im generierten main.tex neu kaputt gemacht und wurde verworfen, bevor er auf CI verifiziert war. Braucht direkten Zugriff auf einen GitHub-hosted Runner (oder ein Ubuntu-Image mit exakt demselben texlive-Paketstand) zum Nachvollziehen, nicht nur Vermutungen von aussen.
• Keine E2E-Abdeckung für die öffentliche Abgabebox-Upload-UI (2026-08-28): Der frühere Test dazu (frontend/e2e/abgabebox.spec.ts) wurde entfernt. Beim Reparieren der ansonsten komplett kaputten E2E-Suite (siehe Testprozess) zeigte sich: page.locator('input[type="file"]').setInputFiles(...) setzt die Datei nachweislich korrekt auf DOM-Ebene (input.files.length === 1), aber upload-form.tsxs onChange/handleFileChange feuert trotzdem nicht — selbst ein manuell per dispatchEvent gefeuertes natives, bubbelndes change-Event löst nichts aus. Sieht nach einer React 19/Next-Dev-Mode-Eigenheit beim Datei-Input aus, keinem Test- oder Backend-Bug; ohne echte Browser-DevTools (Komponentenbaum, Breakpoint in handleFileChange) liess sich das nicht weiter eingrenzen. Die restliche Suite (9 verbleibende Szenarien) läuft grün.

Erledigt

• Coverage-Bericht in CI (2026-08-27): Backend und Abgabebox-Backend laufen mit pytest-cov (--cov-report=term-missing), beide Frontends mit vitest run --coverage. Bewusst ohne Schwellenwert-Gate — aussagekräftige Fach- und Sicherheitsfälle sind wichtiger als eine blosse Prozentzahl, das war und bleibt der Massstab. Der Bericht schafft nur Sichtbarkeit auf unbeabsichtigt ungetestete Bereiche.
• Automatisches Audit-Log-Inventar (2026-08-27): backend/scripts/check_audit_coverage.py scannt app/api/routes/*.py statisch nach schreibenden Endpunkten ohne direkt sichtbaren AuditService.log(...)-Aufruf und läuft informativ (nicht blockierend) in CI. Schaut nur eine Ebene tief (nicht in app/services/*.py hinein), ersetzt die manuelle API-Review-Checkliste also nicht, ergänzt sie aber um eine automatische erste Sichtung.
• Doppelte Dokumentationssysteme (2026-08-27): docs-site/docs/technik/* besteht nur noch als kurze Verweisseiten auf dieses Wiki; docs-site/docs/benutzer/ bleibt unverändert bestehen (andere Zielgruppe). Übergangsregeln weiterhin unter Dokumentationspflege.
• Pagination auf List-Endpoints (2026-07-29): Alle Haupt-Listen (Protokolle, Todos, Termine, Finanz-Transaktionen, Bussen, Teilnehmer) laden serverseitig per skip/limit und im Frontend automatisch beim Scrollen nach (useInfiniteScroll-Hook, IntersectionObserver). Dabei einen Bug gefixt: der laufende Kontosaldo wurde clientseitig aus Floats aufsummiert, was mit Pagination sofort falsche Werte gezeigt hätte — jetzt server-seitig per SQL-Window-Function über die volle Kontohistorie berechnet.
• ProtocolEditor aufgeteilt (2026-07-29): von 6214 auf 1124 Zeilen, aufgeteilt in protocol-editor-shared.tsx, matrix-embedded-block-editor.tsx, chart-block-renderer.tsx, focused-element-editor.tsx und session-todos-section.tsx (alle unter frontend/components/protocol/). Reine Verschiebung ohne Logikänderung. AppShell (555 Zeilen) wurde bewusst nicht angefasst, war schon klein genug.
• Keine automatisierten Tests — Backend, Abgabebox, beide Frontends, Migrationen, Deploy-Skripte und zentrale Browserflüsse laufen in CI. Siehe Testprozess.
• Async PDF-Export — bei Überprüfung stellte sich heraus, dass der Export bereits asyncio.create_subprocess_exec nutzt und den Worker-Prozess nicht blockiert.
• Finanzbeträge als float statt Decimal — bei Überprüfung stellte sich heraus, dass die DB-Spalten bereits Numeric(15,2) sind und Pydantic intern mit Decimal rechnet; nur die JSON-Serialisierung rundet zu float (Branchenstandard für die Übertragung, kein Datenintegritätsproblem).
• N+1-Query in FinanceRepository.list_accounts — bei Überprüfung stellte sich heraus, dass bereits eine Subquery-Aggregation in einer einzigen Query verwendet wird.
• Protokoll-Todo-Query mit vielen JOINs — per EXPLAIN ANALYZE gegen die Produktivdaten geprüft: alle Join-Spalten sind sauber indiziert, Ausführungszeit unter 2ms, kein N+1. Bei der aktuellen und absehbaren Datenmenge kein Performanceproblem.

Pflegehinweis: Wenn ein Punkt hier umgesetzt wird, bitte diese Seite entsprechend aktualisieren.