| type |
status |
owner |
created |
related |
|
|
|
| 🏗️ Lead Architect |
| 🧹 Curator |
|
2026-04-03 |
| docs/01_Architecture/MASTER_ROADMAP.md |
| docs/04_Agents/Roadmaps/Curator_Roadmap.md |
|
C-3: Vorschlag zur Unterordner-Struktur in docs/
Ziel
Überladene/uneinheitliche Verzeichnisse identifizieren und eine klare, skalierbare Struktur vorschlagen, die zu unseren Prinzipien „Docs‑as‑Code“ und „Offline‑First“ passt. Keine Moves im Rahmen dieses PRs – nur Abstimmungsvorlage.
Leitprinzipien
- One purpose per folder: thematische Trennung (Architektur, Domain, Backend, Frontend, Infrastruktur, Prozesse).
- Assets trennen: Binärdateien/Medien unter
assets/ konsolidieren, fachliche Inhalte bleiben textuell in Bereichsordnern.
- Zeitliche Inhalte standardisieren: Tägliche Notizen →
99_Journal/, formelle Auswertungen/Status → 90_Reports/.
- Reversibel: Bestehende Links möglichst stabil halten; bei Moves Redirect-Hinweise (Link-Stub) lassen.
Hotspots (Ist-Zustand)
06_Frontend (20+ Dateien, 10+ Unterordner): Fach-Docs, Logs, Screenshots und ein ZIP (FIGMA) gemischt.
99_Journal: viele Session-Logs – erwartbar groß, aber Index fehlt.
90_Reports: Berichte gemischt ohne Subkategorien.
- Lose Ordner im Doc-Root ohne klare Zuordnung:
BilderSuDo/, ScreenShots/, temp/, OePS/, Neumarkt2026/, Bin/.
Zielstruktur (Top-Level, unverändert wo sinnvoll)
01_Architecture/ – ADRs, Referenzen, Roadmaps, Proposals (neu: dieser Ordner)
02_Guides/ – Setup- & How‑To‑Guides
03_Domain/ – Fachliche Referenzen, Glossar, Regelwerke
04_Agents/ – Playbooks, Roadmaps, Sitzungsdokus der Agenten
05_Backend/ – API, DB‑Schema, Services‑Doku
06_Frontend/ – Patterns, Navigation, Guidelines (+ interner README/Index)
07_Infrastructure/ – Deployment, Ops, Security
80_Assets/ – NEU: Zentrale Medien & Binärartefakte
80_Assets/screenshots/
80_Assets/figma/
80_Assets/exports/ (z. B. HTML‑Templates, generierte Artefakte)
80_Assets/legacy/ (Altbestände wie BilderSuDo)
90_Reports/ – Berichte, gegliedert nach Bereich/Projekt
90_Reports/frontend/
90_Reports/backend/
90_Reports/events/ (z. B. Neumarkt2026/)
99_Journal/ – Chronologisches Journal (täglich), mit monatlichen Indexdateien
_archive/ – Altes/abgelegtes Material (mit READMEs, warum archiviert)
Migrationsmatrix (Quelle → Ziel)
docs/06_Frontend/FIGMA/**/*.zip → docs/80_Assets/figma/
docs/06_Frontend/Screenshots/**/* → docs/80_Assets/screenshots/frontend/
docs/06_Frontend/Logs/**/* → docs/90_Reports/frontend/logs/
docs/06_Frontend/StartErgListen/*.html|*.png → docs/80_Assets/exports/erg-listen/
docs/ScreenShots/**/* → docs/80_Assets/screenshots/
docs/BilderSuDo/**/* → docs/80_Assets/legacy/BilderSuDo/
docs/Neumarkt2026/**/* → docs/90_Reports/events/Neumarkt2026/
docs/OePS/**/* → docs/03_Domain/02_Reference/OEPS/
docs/Bin/**/* → docs/_archive/bin/ (oder platform/tools/ sofern build-relevant; Klärung nötig)
docs/temp/**/* → docs/_archive/_temp/ (oder löschen, falls leer/obsolet)
Phasenplan
- Phase 1 (dieses Ticket): Inventur, Vorschlag, Abstimmung. Keine Moves, nur Verlinkungen/Indexe ergänzen.
- Phase 2 (nach Freigabe): Gezielte Moves inkl. Redirect‑Stubs (kurze MD-Dateien mit Verweis), Link-Update in Kern-Docs.
- Phase 3 (Cleanup): Veraltete Duplikate entfernen oder als
ARCHIVED markieren; monatliche Indizes für 99_Journal einführen.
Offene Punkte für den Architect
Bin/: Enthält es build-relevante Tools? Falls ja, Verlagerung in platform/ statt _archive.
OePS/: Exakter Zielpfad unter 03_Domain/02_Reference/ – Naming „OEPS“ vs. „OePS“ vereinheitlichen.
- HTML‑Templates (
StartErgListen): Bleiben sie als Referenz im Frontend oder als Export/Asset?
- Fallback für große Binärdateien (>50 MB): Soll ein externes Artefakt-Repo genutzt werden?
Auswirkungen
- Klare Trennung zwischen Text‑Doku und Medien → bessere Lesbarkeit, schnellere Diffs.
- Bessere Skalierbarkeit der zeitlichen Inhalte (Reports/Journal) → einfache Auffindbarkeit.
- Geringes Bruchrisiko dank Redirect‑Stubs in Phase 2.
Nächste Schritte
- Review durch 🏗️ Architect
- Nach Freigabe: Migrations-Tickets je Teilbereich (Frontend, Reports, Assets)