DiveLogix360 – Projekthandbuch¶
Stand: 12.08.2026 17:31 Branch: main Status: Aktiv
| Datum, Uhrzeit | Version | Änderung | Autor |
|---|---|---|---|
| 12.08.2026 17:31 | 1.1 | Nachweisbereich und automatische Dokumentationsprüfung ergänzt | Codex |
| 12.08.2026 16:55 | 1.0 | Projekthandbuch, Leserführung und verbindliches Dokumentationsmodell eingeführt | Codex |
Zweck: Verständlicher Einstieg für neue und bestehende Projektbeteiligte.
Abgrenzung: Dieses Projekthandbuch fasst führende Quellen zusammen und ersetzt keine fachliche oder technische Detaildokumentation.
Empfohlene Lesereihenfolge¶
- Produktübersicht – Ziel, Nutzen, Zielgruppen und Produktabgrenzung
- Funktionsübersicht – Use Cases und fachliches Zusammenspiel
- Aktueller Projektstand – kompakter Überblick über Fortschritt, Schwerpunkt und nächste Schritte
- Architekturüberblick – technisches Gesamtbild und Architekturprinzipien
- Einstieg für Projektbeteiligte – rollenbezogene Vertiefung und Arbeitsweise
Für Detailfragen führen alle Seiten direkt zu den jeweils massgeblichen Quellen.
Dokumentationsmodell¶
Die Projektdokumentation wird in drei Ebenen gegliedert:
| Ebene | Zweck | Inhalt |
|---|---|---|
| 1 – Projekthandbuch | Verständlicher, kuratierter Überblick für Menschen | Die Seiten unter docs/project/ |
| 2 – Verbindliche Detaildokumentation | Vollständiges fachliches und technisches Abbild des Projekts | Management, Use Cases, API, Architektur, Datenbank und Compliance |
| 3 – Nachweise und Historie | Arbeitsstände, Prüfungen, Migrationen und nicht mehr führende Dokumente | Klassifizierte Inhalte unter docs/evidence/ |
Die dritte Ebene wird kontrolliert und gruppenweise aufgebaut. Dateien verbleiben bis zur dokumentierten Klassifikation und vollständigen Verweisprüfung an ihren bisherigen Ablageorten.
Führende Quellen¶
| Informationsart | Führende Quelle |
|---|---|
| Produktziele, Versionsumfang und Prioritäten | Produkt-Roadmap |
| Aktueller Arbeits-, Spezifikations- und Implementierungsstand | Detaillierter Projektstatus |
| Projektweiter zeitlicher Verlauf | Projekt-Historie |
| Fachliche Regeln und Akzeptanzkriterien | jeweilige Use-Case-Spezifikation gemäss Dokumentationsübersicht |
| Navigation innerhalb eines Use Cases | jeweiliges Use-Case-Dossier |
| Architekturentscheidungen | ADR-Register und einzelne Architecture Decision Records |
| Programmierschnittstellen | API-Dokumentation und verbindliche OpenAPI-Verträge |
| Technisches Datenbankschema | backend/prisma/schema.prisma |
| Datenschutz und organisatorische Anforderungen | Compliance- und Datenschutzdokumente |
| Test-, Review- und Abnahmenachweise | jeweiliger ausgewiesener Prüfnachweis |
Bei einem Widerspruch gilt die für die Informationsart genannte führende Quelle. Der Widerspruch ist dort zu klären; das Projekthandbuch darf ihn nicht eigenständig auflösen.
Prinzip: keine doppelte Wahrheit¶
Das Projekthandbuch darf:
- Inhalte verständlich zusammenfassen;
- Zusammenhänge und Lesereihenfolgen erklären;
- auf führende Detailquellen verweisen;
- einen datierten Überblick über den aktuellen Stand geben.
Das Projekthandbuch darf nicht:
- fachliche Regeln unabhängig von der Use-Case-Spezifikation festlegen;
- einen eigenen detaillierten Aufgabenbestand führen;
- Architekturentscheidungen ausserhalb eines Architecture Decision Records treffen;
- vom Projektstatus abweichende Fortschrittsangaben als verbindlich darstellen;
- technische Schemainformationen als zweite Wahrheit pflegen.
Aktualisierungsregeln¶
Eine Seite des Projekthandbuchs wird geprüft und bei Bedarf in derselben Änderung aktualisiert, wenn sich mindestens einer dieser Punkte materiell ändert:
- Produktziel, Zielgruppe oder Geschäftsmodell;
- Versionsumfang oder Priorität;
- Gesamtstatus oder Schwerpunkt eines Use Cases;
- wesentliche Architektur oder ein für den Überblick relevantes Architecture Decision Record;
- projektweites Risiko, eine Blockade oder ein nächster Hauptschritt;
- Lesereihenfolge oder kanonischer Ablageort.
Reine Implementierungsdetails lösen keine Aktualisierung aus, solange sich die zusammengefasste Aussage nicht ändert.
Aktualitätskontrolle¶
Jede Seite nennt ihren eigenen Stand und die verwendeten führenden Quellen. Die kompakte Statusübersicht nennt zusätzlich ausdrücklich den Stand des zugrunde liegenden detaillierten Projektstatus. Ist die führende Quelle neuer, muss geprüft werden, ob sich die zusammengefasste Aussage geändert hat.
python tools/mkdocs_documentation_check.py prüft die kuratierte Navigation, Dossier-Struktur, zentrale Links, Quellenabgrenzung und den verwendeten Projektstatus. Dieselbe Prüfung läuft vor jedem MkDocs-Build als Hook.
Weiterführende Einstiege¶
| Bedarf | Einstieg |
|---|---|
| Projekt in wenigen Minuten verstehen | Produktübersicht |
| Funktionsumfang und Use Cases verstehen | Funktionsübersicht |
| Aktuellen Fortschritt beurteilen | Projektstand |
| Technische Grundstruktur verstehen | Architekturüberblick |
| Fachlich mitarbeiten | Use-Case-Dokumentation |
| Technisch mitarbeiten | ADR-Register, API und Datenbank |
| Datenschutz und Compliance prüfen | Compliance-Dokumentation |
| Prüfstände und historische Quellen nachvollziehen | Nachweise und Historie |