gwoe-antragspruefer/docs

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.