gwoe-antragspruefer/docs
Dotty Dotter 2dec009b5c docs+ops: ADRs 0006/0008, DDD-Bewertung, Zugriffsrechte, Smoke-Test, Cron-Scripts
ADRs:
- 0006 Embedding-Modell-Migration v3->v4 (#123)
- 0008 DDD-Lightweight-Migration (#136)

Analysen:
- ddd-bewertung.md (1237 Zeilen) — vollstaendige DDD-Analyse mit Tages-Roadmap
- protokoll-parser-v6-machbarkeit.md (418 Zeilen) — #106 Phase 2 Vorbereitung

Reference:
- zugriffsrechte.md — 63 Routes x 3 User-Status, UI-Sichtbarkeits-Matrix

Ops:
- scripts/deploy.sh — mit Uptime-Kuma-Wartungsmodus (#149)
- scripts/run-digest.sh — taeglicher Mail-Digest-Cron
- scripts/run-monitoring-scan.sh — Monitoring-Scan-Cron (noch nicht aktiv)
- scripts/smoke-test.sh — Gesamt-Funktionspruefung
- pytest.ini: integration/slow/e2e Markers, addopts not-integration

Tests/integration/: Live-Adapter-Tests + Frontend-XRef + Citation-Substring
                    + Wahlprogramm-Indexed (4 Live-Test-Suites, marker-opt-in)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 20:55:57 +02:00
..
adr docs+ops: ADRs 0006/0008, DDD-Bewertung, Zugriffsrechte, Smoke-Test, Cron-Scripts 2026-04-25 20:55:57 +02:00
analysen docs+ops: ADRs 0006/0008, DDD-Bewertung, Zugriffsrechte, Smoke-Test, Cron-Scripts 2026-04-25 20:55:57 +02:00
archive #62: API-Reference + Datenmodelle + Embeddings-Pipeline (mkdocstrings) 2026-04-10 14:14:15 +02:00
how-to Docs: Keycloak-Setup How-to + ADR-Index aktualisiert 2026-04-10 16:33:52 +02:00
reference docs+ops: ADRs 0006/0008, DDD-Bewertung, Zugriffsrechte, Smoke-Test, Cron-Scripts 2026-04-25 20:55:57 +02:00
index.md #62: API-Reference + Datenmodelle + Embeddings-Pipeline (mkdocstrings) 2026-04-10 14:14:15 +02:00
README.md #62 Phase 1+3: ADRs + Doku-Struktur in webapp/docs/ 2026-04-10 01:38:03 +02:00

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.