meldestelle/docs/01_Architecture/Proposals/C-3_Docs-Strukturvorschlag.md

type, status, owner, created, related

type	status	owner	created	related
Proposal	DRAFT	🏗️ 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

1. Phase 1 (dieses Ticket): Inventur, Vorschlag, Abstimmung. Keine Moves, nur Verlinkungen/Indexe ergänzen.
2. Phase 2 (nach Freigabe): Gezielte Moves inkl. Redirect‑Stubs (kurze MD-Dateien mit Verweis), Link-Update in Kern-Docs.
3. 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)